Toteutettava ratkaisumalli

Kuva 1: Toteutettava kaavio

Kuvaus

Tämä 10. projektipalaverissa 21.11. toteutettavaksi päätetty ratkaisu minimoi olemassaolevaan sovelluslogiikkaan tehtävien muutosten tarpeen. Oleellista on, että CourseInstance- ja EventGroup-taulujen välinen suhde säilytetään entisentyyppisenä. Se edellyttää sitä, että sallitaan EventGroup-taulun CourseInstanceID-kentän NULL-arvot. Samoin menetellään Event- ja EventGroup-taulujen välillä.

Sovelluspuolella tietokantaa käsitellään ikäänkuin kullekin yksittäiselle henkilölle olisi kirjattu oma ryhmänsä, jonka ainoana jäsenenä hän toteuttaa henkilökohtaisia ajanvarauksiaan.

• Rekursiivinen M-M-suhde itseensä, joka mahdollistaa ryhmien muodostamisen osaryhmistä.
• Kenttä ValidUntil, joka ilmoittaa mihin saakka ryhmä on voimassa, helpottaa kannan ylläpitoa. (triggeri joskus?)
• CourseInstanceID-kentän arvo voi olla NULL, tällöin EventGroup ei liity mihinkään kurssiin.

• EventGroupID-kentän arvo voi olla NULL, jolloin Event ei liity mihinkään EventGroup'iin.
• Kenttä VisibilityID, joka liittää tapahtuman Visibility-tauluun.
• Kenttä PriorityID, joka liittää tapahtuman Priority-tauluun.

• Deleted-kenttä ilmaisee, onko näkyvyysarvo poistettu.
• VisibilityID-kenttä on taulun perusavain.
• Name-kenttä ilmaisee näkyvyyden arvon.

• Deleted-kenttä ilmaisee, onko prioriteetti poistettu.
• PriorityID-kenttä on taulun perusavain.
• Name-kenttä ilmaisee prioriteetin arvon.

• Deleted-kenttä ilmaisee, onko muistilappu poistettu.
• EventID-kenttä liittää muistilapun tiettyyn tapahtumaan.
• PersonID-kenttä liittää muistilapun henkilöön, joka sen on jättänyt.
• Time-kenttä kertoo ajankohdan, jolloin muistilappu on jätetty (TimeStamp-muodossa).
• Message-kenttä kertoo muistilapun sisältämän viestin.
• Title-kenttä kertoo muistilapun otsikon.

• Deleted-kenttä ilmaisee onko kommentti poistettu.
• CommentID-kenttä on perusavain.
• Comment sisältää kommentin sanallisena.

• CommentID on ryhmän luonnin yhteydessä siihen liitettävien kommenttien tunniste.
• UserLevel on ryhmään kuuluvan henkilön oikeudet esim. ryhmän muokkauksessa. Voi olla, että tästä joudutaan tekemään oma taulu.

Tulevaisuudessa saattaa tulla tarvetta henkilö- ja tapahtumaryhmän käsitteiden erottamiselle toisistaan jo tietokannan tasolla hylätyn mallin mukaisesti. Siksi kaikki sovelluslogiikka, joka viittaa nykyiseen tietokantarakenteeseen (esim. hakulauseet) tulisi kapseloida esimerkiksi omaksi JavaBean-luokakseen, josta käsin sitä on helpompi muuttaa muuttuneita tarpeita vastaavaksi.

Toteutettavan rakenteen hyvä puoli sen lisäksi, että se on säästeliäs olemassaolevan koodin suhteen, on sen ilmeisesti kohtuullinen nopeus. Huonoihin puoliin lukeutuu taulujen (erityisesti taulut Event ja EventGroup) kasvaminen kohtuuttoman isoiksi. Siksi onkin syytä karsia ajanmittaan vanhentuneet tai muulla tavoin turhat rivit kannasta.

Toistaiseksi hylätty ratkaisumalli

Kuva 2: Vaihtoehtoinen kaavio

Kuvaus

Tässä mallissa henkilö- ja tapahtumaryhmät on erotettu rakenteellisesti toisistaan. Se on tehty halkaisemalla EventGroup-taulu kahtia tauluiksi Group ja Eventgroup. Tämä mahdollistaa sen, että mikäli samojen henkilöiden muodostamaa ryhmää tarvitaan useissa eri yhteyksissä (esim. Harjoitustyöryhmä, vapaa-ajan toiminta...), ei ryhmää tarvitse muodostaa ja tallentaa kuin kerran.

Vaikka olemassaolevaa koodia paikkailtaisiinkin, on koodi sen jälkeenkin hitaampaa, sillä hakuja tulee enemmän. Päivitysbyrokratia on lisäksi hankalampaa. Esimerkiksi, jos samaa ryhmää käytetään kahdessa yhteydessä ja vain toisessa yhteydessä sen kokoonpanoa halutaan muuttaa, pitää tässä tapauksessa luoda uusi ryhmä tätä muuttunutta tarvetta varten ja halkaisulla saavutettu säästö menetetään. Eli tilanne vastaa vähän ohjelmoinnista tuttua viitelaskureilla varustetun tiedon muuttoa (s.o. saa muuttaa, jos vain yksi viittaus, muuten pitää tehdä oma kopio). Lisäksi nämä tismalleen samanlaiset ryhmät lienevät järjestelmässä aika harvinaisia, joten nähtäisiin paljon vaivaa minimaalisen hyödyn eteen.