12.3.2 Relaatiomalli
Jos tiedot on talletettu relaatiomallin mukaan, voi olla kannattavaa tehdä
myös sisäinen tietorakenne vastaavaksi. Vaikka jatkossa emme
toteutakaan kerhoon vielä harrastuksia, teemme tietorakenteen ja oliot
sellaisiksi, että harrastusten käsittely jälkeenpäin olisi
mahdollisimman helppoa.
Toteutettavaa ohjelmaa ajatellen tästä valinnasta seuraa yksi
byrokratiaporras (cKerho <-> cJasenet) lisää, joka
aluksi saattaa tuntua turhalta. Valinta maksaa itseään takaisin
vasta ongelman monimutkaistuessa. Tähän samaan
monimutkaistumisongelmaan tulemme törmäämään
jatkossakin. Yksinkertaisin mahdollisuus, jolla vaadittu toimenpide juuri ja
juuri voidaan suorittaa, johtaa usein jatkoa ajatellen umpikujaan.
- Kirjoita algoritmi uuden harrastuksen lisäämiseksi. (Ks. alla
oleva kuva)
- Kirjoita algoritmi, joka vastaa kysymykseen "Mitä henkilö N
harrastaa?"
- Kirjoita algoritmi, joka vastaa kysymykseen: "Ketkä harrastavat
harrastusta H?".
- Kirjoita algoritmi harrastuksen poistamiseksi.
- Kirjoita algoritmi, joka poistaa jäsenen jonkin nimi on N.
- Kirjoita algoritmi, joka poistaa "roskaharrastukset", eli ne harrastukset,
joille ei löydy "omistajaa". Tällaiseen tilanteeseen
hyvässä ohjelmassa ei tietenkään koskaan
päädytä.
- Jos harrastusten nimet ovat kovin pitkiä ja harrastuksista talletetaan
vielä kuhunkin harrastukseen liittyvää lisätietoa, niin
edellä mainittu rakenne käy tehottomaksi heti kun löytyy useita
saman lajin harrastajia. Esitä ratkaisu, jossa hukkatilaa (mm. saman
harrastuksen nimen toistamista) ei esiinny, mutta jolla voidaan tehdä
kaikki samat tehtävät, kuin esitetyllä ratkaisulla.
Kuva 12.8 Harrastukset relaation avulla