Frávik og fleiri þættir

Markmið Codds var að nálgast „áreiðanlegt upplýsinga líkan“ (e. Dependable Information Model). Allar geymslu aðferðir sem í boði voru buðu upp á vandamál sem hann kallaði frávik, á ensku Anomalies. Hann flokkaði þessi frávik í þrjá flokka: „dagréttinga frávik“ (e. Update Anomaly), „Eyðingar frávik“ (e. Delete Anomaly) og „Innskots frávik“ (e. Insert Anomaly).

Dagréttinga frávik

Gefum okkur að púkinn sem áður var talað um sé fyrir hendi og nú sé hægt að færa inn töflur með upplýsingum og að hann leyfi aðgengi margra notenda í senn að gögnunum. Næsta skref væri þá að ákveða, eða tilgreina, hvernig gögnin skuli geymd, þau sótt og dagréttuð.

Gefum okkur að við séum að störfum hjá fyrirtæki og að það geymi upplýsingar um önnur fyrirtæki sem það sé í viðskiptum við. Margir starfsmanna okkar þurfa aðgang að þessum upplýsingum, sem gætu litið þannig út:

Tafla 2a

Við fyrstu sýn virðist ekkert vandamál vera hér á ferðinni. Auðvelt er að fá upp allar færslur (e. Records) eða línur (e. Tuples) töflunnar og vinsa úr stakar færslur. Stakar færslur gætu verið t.d. „Allar færslur sem innihalda Hugbrjótur ehf. í sviðinu (e. Field) Fyrirtækisnafn.“ Slík fyrirspurn myndi gefa upplýsingarnar í línu 1 og 2, eftir atvikum (e. Respectively).

Segjum nú að fyrirtækið Hugbrjótur ehf. flytji á heimilisfangið „Gagnagarðar 66, 0112 Reykjavík.“ Þá þarf að dagrétta heimilisfang þess í töflunni. Eins og hún lítur út núna væri það tiltölulega auðvelt þar sem aðeins er um tvær færslur að ræða, en hvað ef tengiliðir fyrirtækisins væru orðnir 30? Vissulega mætti þá kalla upp allar færslurnar 30 og breyta gildunum í Fyrirt-heima og Svæði.

Hér kemur fyrsta „dagréttinga frávikið“, breyta þarf gildum fyrir eitt ákveðið fyrirtæki á fleiri stöðum en einum.

Einnig koma hér upp hugsanleg skekkju frávik. Segjum að ritarinn, sem falin er sú ábyrgð að dagrétta breytingarnar, misriti heimilisfangið í einni færslunni og riti „Gagnagarðat 66“ af misgáningi. Niðurstaðan yrði þá 29 réttar færslur og 1 röng. Segjum sem svo að við höfum ritað forrit sem vinsar út öll fyrirtæki eftir heimilisföngum og ritar hvert fyrirtæki á sérstaka síðu. Fyrirtækið Hugbrjótur myndi í þessu tilviki fá tvær aðgreindar síður, eina með 29 færslum og aðra með 1 færslu.

Segjum sem svo að fyrirtæki okkar þyrfti að skipta markaðssókn sinni þannig að „markaðsstjóri stærri[1] viðskiptavina“ fengi ábyrgð á samskiptum við öll fyrirtæki sem hafa tvo eða fleiri tengiliði en „markaðsstjóri minni viðskiptavina“ fengi ábyrgð á samskiptum við þau fyrirtæki sem hafa aðeins einn tengilið. Listaforritið okkar sendir markaðsstjórunum sjálfvirkt niðurstöðurnar en markaðsdeildirnar deila ekki húsnæði. Nú höfum við sent upplýsingar um sama fyrirtækið í tvær gagnstæðar áttir og höfum enn minni tækifærisgátt (e. Window of opportunity) til að laga skekkjuna. Skekkju frávikið vex, tvær markaðsdeildir hafa nú aðgang að sama viðskiptavininum í einu.

Vel mætti hugsa sér fleiri skekkjumörk. Segjum að ritarinn færi öll heimilisföngin rétt en næst þegar nýr tengiliður bætist í hóp viðskiptavina frá Hugbrjóti ehf. misritist nafn fyrirtækisins sem Hugbrjotur ehf. Sex mánuðum síðar breytir fyrirtækið um nafn og verður að Hugkvarnir ehf. Nú keyrum við lítið smáforrit á gagnagrunninn sem breytir öllum færslum með Fyrirtækisheitinu Hugbrjótur ehf. í Hugkvarnir ehf. Nú yrði eftir ein færsla með fyrirtækinu Hugbrjotur ehf. og í hinni ímynduðu markaðsskiptingu okkar er áframhaldandi skekkja. Sex mánuðum síðar hætta Hugkvarnir ehf. störfum, öllum færslum þess er eytt en Hugbrjotur ehf. er ennþá til í viðskiptafærslum okkar!

Besta leiðin til að greiða úr þessum flækjum og frávikum væri að skipta gögnunum upp í tvær töflur sem síðar tengjast saman á skyldleikum sínum. Þetta er einmitt niðurstaða Codds og efni þessarar bókar er að sýna hversu auðvelt þetta er allt saman.

Eyðingar frávik

Segjum nú sem svo að eyða þurfi Guddu Karlsdóttur úr grunninum, sem í sjálfu sér er einfalt. Línunni er eytt út. Því næst koma upp kröfur um að gera lista yfir öll fyrirtæki sem átt var viðskipti við á síðustu 12 mánuðum. Nú var línu 4 eytt þegar upplýsingarnar um Guddu voru fjarlægðar og þar með eru horfnar upplýsingarnar um Kerfagutl ehf.

Þetta eru „eyðingar frávik“ sem Codd nefndi á ensku „Deletion anomaly.“ Þegar eyða þarf gögnum er hætta á að önnur gögn eyðist með eða ekki sé hægt að eyða þeim sem eyða þarf vegna þess að önnur, tengd, gögn leyfi það ekki.

Sé upplýsingunum skipt upp í tvær töflur, fyrirtæki geymd sér og einstaklingar geymdir sér þá hefði verið nóg að eyða línunni með Guddu út úr einstaklings töflunni án þess að fyrirtækinu væri eytt sérstaklega.

Innskots frávik

Segjum nú sem svo að við þyrftum að bæta við nýjum einstakling í grunninn en vitum ekki hjá hvaða fyrirtæki hann er tengiliður. Þá væri óhægt um vik að skrá hann nema skrá fyrirtækið einnig. Hið sama gæti komið upp þegar skrá þarf inn nýtt fyrirtæki en við vitum ekki hver tengiliðurinn er.

Þessar aðstæður nefndi Codd „Innskots frávik“ eða „Insert Anomaly,“ þegar ekki er hægt að setja gögn inn í grunninn vegna þess að ónógar upplýsingar eru fyrir hendi eða skorður (e. Constraints) á innskotum krefjast þess.

Aftur er lausnin fólgin í því að skipta upplýsingunum upp í tvær töflu, fyrirtæki í sérstaka töflu og einstaklinga í aðra. Þá gætum við bætt nýjum einstaklingum inn sérstaklega og fyrirtækjum sérstaklega.

1. Jólakortagrunnur

Þú færð það verkefni að útbúa jólakortagrunn fyrir fjölskylduna. Þú þarft að geyma upplýsingar um alla aðila sem a) þín fjölskylda sendir jólakort og b) alla þá sem hafa sent fjölskyldunni jólakort. Þú vilt vita hver sé tengiliður við þessa aðila t.d. gæti húsbóndinn á heimilinu verið tengiliður við „Jóa frænda“ sem býr fyrir Norðan, því þeir eru skyldir. Húsmóðirin er tengiliður við gamla vinkonu sína sem einnig er fjölskylduvinur. Grunnurinn þarf að geta birt frá hverjum komu jólakort í fyrra en fengu ekki kort á sama tíma. Merkja þarf við hverjir hafa ekki sent jólakort undanfarið.

Hvernig myndir þú leysa þessa kröfu?

1. Listaðu upp alla þætti sem hér er lýst án þess að hafa áhyggjur af töflunni. Endurtaktu listann allt að tvisvar sinnum, þú munt örugglega rekast á eitthvað sem þér yfirsást í fyrstu atrennu. Þessi atriði eru gildin sem þú þarft að geyma.
2. Rissaðu upp tvær til þrjár töflur, eftir þínum hentugleika, og raðaðu gildunum inn í töflur og hópaðu saman í viðeigandi línur. Þetta eru töflurnar með færslum. Endurtaktu þetta tvisvar.
3. Reyndu nú að greina hvaða gildi gera töflurnar skyldar innbyrðis. Hikaðu ekki við að endurhanna þær eina ferðina enn. Þú vilt ekki þurfa þess þegar þú byrjar að forrita[2] lausnina..

[1] Hér eru minni og stærri notað í þeirri merkingu að hver tengiliður eigi viðskipti við okkur og magn viðskipta sé stærðarvirki (e. Quantifyer) á stærð viðskiptavinar.

[2] Þó að þessi bók kenni ekki forritun þá muntu örugglega fá áhugann á slíku von bráðar og hver veit, kannski skrifa ég bráðum haug af skemmtilegum forritunarbókum.