Ástæðan fyrir því að ég valdi MySQL sem viðfangsefni var sú að kerfið er vinsælt í vefsíðugerð auk annarra þátta: MySQL kostar ekkert fyrir námsfólk og þar sem búnaðurinn tilheyrir opnum lind­um (e. Open Source) er auðvelt bæði að nálgast hugbúnaðinn og upplýsingar um samsetningu hans.

Um mitt árið 2003 sótti ég um og fékk ég styrk frá Menntamálaráðuneytinu til verksins en vegna annarra verkefna dróst að ég hefði tíma til að ljúka verkinu það ár. Úr því rættist sumarið 2004 að ég hafði aðstæður til að sinna því af þeirri athygli sem verkið verðskuldar.

Aðaláhersla er lögð í bókinni á gagna­grunns­fræði sem nálgun og SQL málið sem útfærslu. Því sterkari sem notandinn er í notkun þessara fræða, því betur á hann með að tileinka sér þau kerfi sem byggja á þeim. Fullyrði ég af reynslu minni í kennslu að því meir sem nemandinn tekst hlutlægt á við þessi fræði breikkar hann og dýpkar getu sína og færni án þess að vera háður einu vörumerki öðru fremur.

Bókina ber því fyrst og fremst að lesa sem gagna­grunnsbók með MySQL sem fararskjóta. Hún er aðgengilegt frítt sem á PDF sniði á slóðinni shop.not.is/old.

Fyrsti kafli bókarinnar einblínir á gagnagrunns hugsunarhátt og þau hugtök sem þar að lúta. Því næst er stutt yfirferð sem stiklar á stóru með sýnidæmum sem allir gagnagrunns notendur og hönnuðir þurfa að skilja og kunna. Næstu kaflar þar á eftir er handbók og uppflettirit yfir þætti sem MySQL styður.

Gagna-skilgreiningarmál, á ensku Data Definition Language (DDL) eru notuð til að skilgreina gagnageymslur. Gagnageymslur fjalla um hvernig gagnagrunnurinn eða gagnasafnið skuli uppbyggt.

Gagna-meðhöndlunarmál, á ensku Data Manipulation Language (DML) er málfræði til að meðhöndla upplýsingar. Þessi málfræði tiltekur hvernig gögn eru send inn í töflur og sóttar úr þeim einnig hvernig þeim er breytt eða eytt.

SQL staðallinn er því vel útfærð og hnitmiðuð málfræði sem nærri allir framleiðendur gagnasafns-umsjónarkerfa hafa orðið ásáttir um.

Í dag eru það stofnanirnar ANSI (American National Standards Institute) og ISO (International Standards Organisation) sem gefa staðalinn út. Fjöldi framleiðanda hafa kosið að fylgja staðlinum en flestir ef ekki allir gera það á sinn eigin hátt. Þannig má læra SQL í hvaða SQL-samhæfðu kerfi sem er og á skjótum tíma tileinka sér næsta kerfi því þekkingin er yfirfæranleg.

Öll þessi kerfi kosta einnig mikið í vinnslu (e. Resource intensive). Bæði er að kerfin eru kostnaðarsöm í notendaleyfum auk þess að til þurfti öflugustu vélar undir þau.

Helsti tölvukosturinn voru tölvur á borð við Digital Alpha RISC System, Sun SPARC  eða sambærilegar vélar sem eingöngu voru notaðar með UNIX stýrikerfum oft sérhönnuðum fyrir hvern verkvang fyrir sig.

Stór fyrirtæki og stærri háskólar áttu auðvelt með að eyða milljónum í notendaleyfi og vélbúnað en smærri aðilar og einstaklingar höfðu um fátt að velja nema þá helst veigaminni skjáborðsforrit á borð við dBase, Paradox og síðar MS Access.

Þó eitthvað væri í boði af ódýrum miðlara/biðlara lausnum þá studdu þau síður við SQL staðalinn en buðu frekar eigin lausnir.

Upprunalegur höfundur MySQL, Michael „Monty“ Widenius, hafði unnið við gagnagrunnsþróun hjá sænska fyrirtækinu TcX frá árinu 1979 og meðal annars þróað þar gagnasafns-umsjónarkerfið UNIREG til notkunar innanhúss. Árið 1994 hóf TcX þróun á vefværum hugbúnaðarlausnum og notaði UNIREG gagnagrunna sem gagnatrog.

Hönnuðirnir hjá TcX litu til SQL, tískuyrðis sem átti vaxandi vinsældum að fagna og gæti hentað sem framhlið á lágtækni stefjusöfnin (e. Low Level Libraries) sem þeir notuðu. Við fyrstu sýn virtist sem mSQL gæti hentað en við frekari eftirgrennslan og rannsóknir var ljóst að þörf var á að kóta SQL vél (SQL Engine) frá grunni.

Fyrst höfðu þeir farið þá leið að geyma grunna í mSQL vél og hannað forrit til samskipta við hana en skiptu svo út gagnagrunns-vélinni án þess að skipta út forritunum. Þetta gerði þeim kleyft að spara sér heilmikla vinnu. Eins og fyrir algjöra tilviljun stóðu þeir uppi með söluhæfan gagnagrunns miðlara byggðan á SQL tækni.

Fljótlega var tekin sú ákvörðun að gefa MySQL út í samræmi við hugmyndir Peter Deutsch hjá Aladdin Enterprises, sem hafði áður gefið út Ghostscript. Hugmyndin virkar þannig að útgefandi á allan höfundar- og útgáfurétt og leyfir öðrum að nota forritið svo fremi þeir selji það ekki sem hluta af sinni lausn.

MySQL sló fljótt í gegn í tölvuvinnslu um allan heim. Einstaklingar og smærri fyrirtæki, að ekki sé minnst á skóla, gátu sótt og sett upp hraðvirkan og einfaldan gagnagrunnsmiðlara fyrir Unix og Windows umhverfi (og Mac) og þróað grunna sem að mestu voru samhæfðir útfærslum stærri og dýrari kerfa.

Kerfið varð fljótt hluti af Linux dreifingum (Distros) og undantekningarlaust í boði hjá vefhýsingarfyrtækjum og þá frítt. Sá dagur kom að MySQL vörumerkið og fyrirtækið sem rak hann var keypt af Sun Microsystems. MySQL AB í Svíþjóð hafði ávallt boðið uppá þjónustu við aðila sem vildu reka grunna á MySQL kerfum en voru tilbúnir að greiða fyrir þjónustu.

Ekki löngu eftir eigendaskiptin var Sun Microsystems keypt af Oracle og rannþá MySQL inn í eignasafn Oracle. Fljótlega upp úr því komst Monty Widenius að þeirri niðurstöðu að honum mislíkaði hvernig Oracle ætlaði að viðhalda hugbúnaðinum og stofnaði Maria DB sem hóf áframhaldandi þróun opins hluta kerfisins.

Síðan MariDB hóf starfsemi hefur það kerfi notið viðlíka velgengni og MySQL áður. Flest vefhýsingarfyrirtæki bjóða MariaDB sem möguleika og það kerfi keyrir hnökralaust þá grunna sem áður voru hannaðir fyrir MySQL.

Til þess að nota MySQL með ýmsum forritunarmálum þarf forritunarskil (API) og frá upphafi hefur miðlarinn verið gefinn út með C og Perl forritunarskilum. Síðan hafa komið út fleiri söfn (Libraries) sem öll utan Java safnsins byggja á C söfnum.

Slíkt veitir forriturum greiðan aðgang að því að smíða eigin forrit og biðlara útgáfur sem nota MySQL grunna. Til dæmis eru PHP forritunarskilin sem vinsæl eru í gagna­grunnsmiðlun á Vefnum byggð á C safninu. Sá sem þekkir til notkunar PHP safnsins mun þekkja notkun þess ef sá sami vildi forrita aðgang að grunnum sinum í C málinu.

Þegar kerfið var orðið þokkalega heillegt kom upp þörfin á að afkastaprófa (e. Benchmarking) miðlarann og bera hann saman við önnur sambærileg kerfi. Leit var hafin að afkastaprófunum sem gætu hentað en í ljós kom að flestar slíkar prófanir s.s. TCP-afkastaprófanir[2] skoða afkastagetu SQL miðlara byggða eftir viðmiðuninni færslur-á-sekúndu (e. Transaction pr. Second) og þá sem ein lokatala.

Hönnuðir MySQL litu svo á að slík prófun væri þeim gagnslaus m.a. af þeim sökum að fáir notendur inna (e. Execute) forrit sín eftir sömu formerkjum og þessar prófanir svo nærri vonlaust þykir að dæma heildar virkni eftir þeim. Auk þess að MySQL bauð ekki upp á færslu (e. Transactions) möguleika á þessum tíma.

MySQL afkastaprófanirnar eru hannaðar til að sýna fram á hversu hraðvirkur SQL gagna­grunns­miðlari er í algengum aðgerðum (e. Operation), s.s. að afla tengingar (e. Connection) við miðlarann, framkvæma einföld innskot[3] (e. Inserts) eða samtvinnun[4] (e. Join) tveggja taflna með lyklun (e. Key). Þetta leyfir þeim einnig að mæla álag (e. Load) á vefsíðu þegar aðgerðablöndunin (e. Mix of operations) er þekkt. Að sjálfsögðu krefjast slíkar mælingar þess að forritarinn skilji eðli forrita sinna þegar slíkar prófanir eru framkvæmdar.

Eftir því sem tímar liðu komu fram auknar kröfur á MySQL póstlistanum (e. Mailing list) varðandi MySQL eiginleika (e. Features) og hvernig þeir væru í samanburði við aðra miðlara. Aðalhönnuði miðlarans, Monty, leist illa á að grafa í gegnum gömul tilvísana söfn (e. Reference material) sem oft voru úrelt til að finna slíkar upplýsingar. Hann upphugsaði því forrit sem gæti sjálfkrafa (e. Automatic) fundið út hvaða getu gagnagrunnsmiðlarar hefðu upp á að bjóða. Honum datt í hug að slíkt forrit væri einnig öflug prófun á getu MySQL miðlarans þegar honum væru sendar margar afbrigðilegar fyrirspurnir (e. Abnormal Queries).

Til þess að framkvæma slíka prófun þurfti einhverja hugmynd um getu þeirra miðlara sem prófaðir voru en vinna við að fletta slíku upp og kóta er mjög seinleg. Því var búið til forrit sem gat fundið slíkt út sjálfkrafa. Við fyrstu prófanir tólsins kom ýmislegt óvænt í ljós, miðlararnir sem prófaðir voru hrundu (e. Crash) við mikið álag og var slíkt svo algengt að forritið var nefnt „crash-me.“ Svo ágengt er forritið að eini gagnagrunns miðlarinn sem hefur verið prófaður með því án þess að hrynja er Oracle. Við prófanir hafa að sjálfsögðu komið fram ótal lýs (e. Bugs, í. pöddur) í MySQL sem hafa allar verið lagaðar.

Forritið crash-me og afkastaprófanirnar eru útfærðar (e. Implemented) sem Perl DBI/DBD forskriftir (e. Scripts). Forrit þessi gera þúsundir fyrirspurna á valinn gagnagrunns miðlara til að finna út hvernig hann virkar við raunverulegar aðstæður. Við keyrslu koma þá upp helstu mörk (e. Limits) á vinnslu miðlarans. Einn kostur forritsins er sá að gagnagrunns hönnuður getur hannað SQL grunna sína á færan­legri (e. Portable) máta. Hann getur t.d. með aðstoð þeirra fundið út mörk þess miðlara sem myndi geyma grunnana.

Algengustu aðgerðategundir sem crash-me prófar eru INSERT, UPDATE, DELETE og SELECT, aðgerðir sem fylgt er eftir með að velja eða smíða töflur og atriðaskrár. Dæmi um þá gagnagrunns miðlara sem hafa verið prófaðir með tólinu eru: Adabas-D, Access, DB2, Impress, Informix, MS-SQL Server, MySQL, Oracle, PostgreSQL, Solid og Sybase.

Þær afkastaprófanir sem gerðar eru eiga að gefa nokkuð góða mynd af þeim hraða sem hver miðlari ber í það og það sinnið. Heildarniðurstöður á prófunum á milli miðlarategunda geta þó verið villandi og ber að varast að bera þær grimmilega saman. Sum próf eru keyrð mismunandi oft, með mismunandi skilyrðum og mismunandi fjölda lína (færslna). Einn SQL miðlari gæti verið mjög lélegur í sumum ómerki­legum (e. Unimportant) aðgerðum en afbragðs góður í öðrum sem gætu verið einmitt þær sem hönnuðurinn þarfnast.

Ágætt er að bera saman niðurstöður sama gagnagrunns miðlarans eftir verkvöngum (eða stýrikerfum) og útgáfunúmerum. Til dæmis hafa samanburðar-prófanir á MySQL miðlaranum sjálfum leitt í ljós ýmsar niðurstöður:

• Linux 2.2. er mun hraðvirkari en Linux 2.0 á fjölörgjörva tölvum. Þetta má meðal annars rekja til þess að Perl túlkurinn og MySQL miðlarinn ná að keyra á sitt hvorum örgjörvanum og SMP[5] kóti keyrist hraðar.
• Linux gefur 7% hraðvirkari vinnslu en Windows 98 og 49% hraðvirkari en Windows NT á samskonar tölvu.
• Windows 98 gefur 27% meiri hraða en Windows NT á samskonar tölvu.
• MySQL á Pentium II 400Mhz tölvu og Linux 2.2 stýrikerfi er miklum mun hraðvirkari en Sun Ultrasparc 400 Mhz tvíörgjörva tölva með Solaris 2.7 stýrikerfi. Þessar niðurstöður gætu orðið allt aðrar undir auknu álagi (e. Higher Load).
• Ef framkvæmd eru mörg innskot (e. Inserts) á Solaris tölvu má ná 22% hraðaaukningu með því að auka örgjörva aflið um 100%.
• Yfirbyggingin (e. Overhead) fyrir notkun MyODBC, og líklega fyrir flesta ODBC rekla er minnst 19%.
• Meðan prófanirnar voru framkvæmdar var auðvelt að vinna aðra vinnu á Linux vélinni á meðan en á NT var nánast ómögulegt að framkvæma neina aðra vinnu. Að opna kvaðningar-­glugga (DOS glugga) tók 30 falt lengri tíma og við vélritun tók u.þ.b 10 sekúndur fyrir bókstafi að birtast á skjánum.

Heilmargt er að gerast í afkastaprófunum hjá MySQL og fylgjast má með hvað þar gerist á slóðinni http://dev.mysql.com/tech-resources/benchmarks/ (Ath. ný slóð). Hér til gaman birtist mynd af samanburðargrafi frá eWeek sem sýnir niðurstöður úr prófunum.

Niðurstöður samanburðar prófana eru skemmtilegar fyrir notendur sem nota einfalda grunna t.d. fyrir vefsíður undir litlu álagi. Þær eru hins vegar nauðsynlegar forriturum sem starfa við þróun gagnasafns-umsjónarkerfa og þá til samanburðar. Samanburðar t.d. á getu eigin kerfis gagnvart getu samkeppnis kerfa auk lúsarleitunar og annarra kerfisþátta eins og þeir hjá MySQL AB hafa gert. Einnig henta slíkar prófanir vel fyrir kerfisstjóra sem e.t.v. reka blandað miðlara umhverfi eins og gert er hjá hýsingar fyrirtækjum t.d. gagnavöruhúsum.

Þess má að lokum geta að þeir hjá TcX nota gagnagrunna sem innihalda yfir 50 milljón færslur, og ekki má gleyma að miðlarinn var í upphafi þróaður til utanumhalds þeirra eigin grunna, sem skýrir að hann hefur frá upphafi borið þess merki: eiginleikar eru eitthvað færri en SQL staðallinn krefst en rekstur er kostnaðarlítill og hraði (og væntanlega öryggi) er í hámarki.

Sumir telja MySQL einnig til tekna að kótinn miðlarans er nær eingöngu gerður af einum og sama manninum sem jafnframt býr yfir margra ára reynslu í kótun. Þess vegna sé lítið af um­fremdar (e. Redundant) kóta í kerfinu. Megnið af algrímunum[1] sem kótinn er byggður á voru gerð á tímabili þegar tölvur voru frekar hægvirkar (miðað við hraðvirkari vélar nútímans) með takmörkuðu vinnsluminni.

Helstu breytingarnar kótans í gegnum árin taka tillit til aukins vinnsluminnis með því að nýta sér hluta þess sem skyndiminni. Af þessum sökum voru algrímin í upphafi þróuð til að vera hraðvirk án þess að krefjast mikils af vélbúnaðinum.

Líta má á að kótinn hafi aðeins orðið skilvirkari með árunum. Miðað við þær vinnureglur sem hér koma fram þá mega notendur MySQL treysta því að nýir eiginleikar sem birtist í kerfinu eigi ekki að koma niður á hraða, því hraði og áreiðanleiki hafa jafnan verið aðal vörumerki miðlarans.

Þegar MySQL var fyrst hannaður, og allar götur síðan, hefur aðal krafan verið hraði og aftur hraði, miklu háværari krafa en krafan um fjölda eiginleika (e. Feature quantity). Þess vegna hefur verið sneitt hjá þróun dýrra[2] eiginleika sem eftir sem áður má setja upp með forrits-rökum. Í greinum eftir höfunda og í kóta dæmum hefur verið sýnt fram á að þetta stenst vel og m.a. er hægt að framkvæma færslur (e. Transactions) og ákvæði framandlykla algjörlega með forrits-rökum og nýta þar bæði þrædda vinnslu þjónsins og læsingu á töflum.

Á aðal vefsetri miðlarans (www.mysql.com) er að finna efni af þessu tagi auk langra lista yfir alla þá þætti sem miðlarinn styður. Það sem helsta athygli vekur við þann lestur er að þróun kerfisins hefur verið mjög hröð og í dag (útgáfa 5.0) eru nærri allir þættir, sem hefur skort hingað til, komnir á hlaðborðið (salat barinn). Bækur sem hafa tekið síðupláss í að telja upp hvað hægt er að gera og hvað ekki hægt að gera úreldast því hraðar.

Fyrir það að MySQL hönnuðirnir völdu í upphafi þá hluta SQL staðalsins sem þeim hentaði er ekki hægt að segja að forritið sé samhæft staðlinum í öllum atriðum. Þetta er þó álitamál því allar aðgerðir þjónsins fylgja staðlinum að einhverju leyti og í því helsta sem máli skiptir. Forritari sem kann skil á SQL getur því unnið með gagnagrunna í miðlaranum áreynslulítið. Auk þessa er það stefna MySQL AB að þjónninn verði í náinni framtíð al-samhæfður við ANSI SQL 92 staðalinn. Allt virðist líka stefna að þeim brunni að þetta muni standast.

Eins og fram hefur komið er MySQL gefið út með samskonar hætti og Aladdin Ghostscript, sem merkir að uppruna-kótinn (e. Source code) er opinber, miðlarinn og biðlaraforritin eru frí fyrir  UNIX (og Linux). Auk þess eru eldri (úreltar) útgáfur algjörlega opnar með GPL leyfi.

Þetta merkir að sé MySQL miðlarinn notaður á UNIX/Linux verkvangi, hvort heldur í persónuþágu eða viðskipta kostar hann ekki neitt. Þó eru sett mörk á þessa skilgreiningu og óskað leyfisgreiðslu ef:

•  MySQL miðlarinn er seldur til þriðja aðila eða sem hluti annars hugbúnaðar eða þjónustu.
• Notandi krefjist greiðslu fyrir t.d. vinnu við að setja upp og viðhalda MySQL þjóni fyrir viðskiptavini.
• MySQL miðlaranum er dreift á miðli í útgáfu (t.d. söluútgáfu eða á disk) og tekin er greiðsla fyrir miðilinn (þó ekki sé nema að hluta).
• MySQL er notaður á Win32 (Windows 95, 98, NT, 2000, XP, 2003) kerfi.

Við þær aðstæður að notendaleyfis er krafist þarf aðeins eitt leyfi fyrir þá vél sem keyrir miðlara forritið „mysqld“. Eitt leyfi dugar fyrir vélina þó hún hafi fleiri örgjörva og þó hún keyri mörg tilvik (e. Instance) þjónsins, einnig er eitt leyfi nóg án tillits til fjölda þeirra biðlara sem tengjast grunnum þjónsins.

Eftirfarandi heimspeki er lögð til grundvallar MySQL notendaleyfinu:

• SQL biðlara safnið (e. Client library) skal vera frítt svo það megi innifela í söluvöru án takmarkana.
• Fólk sem vill hafa frían aðgang að hugbúnaðinum, sem útgefendur hans hafa lagt mikla vinnu í, geti fengið hann að því tilskyldu að þeir séu ekki að hagnast beinlínis á honum m.a. með dreifingu.
• Fólk sem vill nota hugbúnaðinn í eigin kerfum, sem jafnframt séu til sölu í hagnaðarvon, getur fengið það en ættu að greiða fyrir afnotin.
• Venjuleg innanhúss notkun sé ókeypis. Hins vegar vilji einhver nota miðlarann í hagnaðarskyni, gæti sá sami aðstoðað við þróunarkostnaðinn með því að kaupa þjónustu samning, með þátttöku í skjölun, kóta-dæmum eða á einhvern annan hátt.
• Stefnan er sú að enginn ætti að þurfa að greiða fyrir hefðbundnar uppfærslur en þó gæti komið fyrir að greiðslu væri óskað fyrir meiriháttar uppfærslur með nýjum eiginleikum s.s. færslu stuðningi (e. Transaction support).

Þannig ætti MySQL að vera góð fjárfesting miðað við aðrar lausnir.

Win32 verkvangurinn (Windows 95 og yngri Windows útgáfur) er stýrikerfi selt í hagnaðarskyni (e. Commercial system) og öll þróunar tól og forritunar umhverfi fyrir það eru dýr. Þess vegna sér MySQL AB sér ekki fært annað en að krefjast greiðslu fyrir notkun miðlarans í því umhverfi.

Hvað varðar verð á notendaleyfi, þ.e. við þær aðstæður þar sem þeirra er krafist er best að lesa skjalasafn útgefanda sem nálgast má á framangreindri slóð. Verðið fyrir eitt notendaleyfi var um árabil aðeins 200 USD (dollarar) en virðist hafa hækkað í 495 USD þegar þetta er ritað.

Hjá MySQL AB er boðin ágæt notendaþjónusta gegn vægu gjaldi, og er framsett í mismunandi verð­flokkum. Án efa hentar slík þjónusta vel fyrir þá sem reka MySQL í viðskiptatilgangi eða undir miklu álagi.

Gagna­grunnur eða Database er skipulagt safn upplýsinga sem geymt er eftir skilgreindu kerfi eða markaðri hugsun. Gögnin eru þá grunnurinn sem mynda upplýsingar í grunninum og er þá kominn gagnagrunnur. Bankareikningur er gagna­grunnur og líta má á allar upplýsingar sem geymdar eru eftir skipulögðu kerfi sem gagnagrunn, hvort sem hann er í tölvu eða ekki.

Bókhaldarar geyma til dæmis bókhald sitt í gatamöppu. Flest ef ekki öll bókasöfn geyma upplýsingar um bókaeign sína á sérstökum spjöldum, eða í spjaldskrá.

Þannig mætti lengi telja upp gagnagrunna sem geymdir eru á annars konar miðlum en í tölvu. Þeir eru þó allir skipulagðir eftir skilgreindu kerfi og má bæði sækja upplýsingar í þá og setja upplýsingar inn í þá eftir skipulögðum reglum.

Greinilega setur það gagnagrunni nokkrar skorður ef hann er aðeins aðgengilegur í prentuðu formi, samanber símaskrána. Myndi það auka notagildi grunnsins ef hægt væri að fletta upp t.d. öllum númerum sem enda á 343 eða öllum eigendum símanúmera á Aflagrund 40.

Slíkt er ekki framkvæmanlegt í prentaðri útgáfu en þarfir af slíku tagi hafa ýtt við þróun gagnagrunna í tölvutæku formi sem hafa slíkan sveigjan­leika.

Gagnasafns-umsjónarkerfi eða Database Software er hugbúnaður sem bíður upp á aðferðir til að skipuleggja gagnasöfn í tölvum. Með öðrum orðum; Forrit sem leyfa skipulagningu gagnasafna með aðstoð tölvu. Slík kerfi nefnast á ensku Database Management Systems (DBMS), hér þýtt sem gagnasafns-umsjónarkerfi, stundum uppnefnt gagnagrunns-kerfi.

Hugtakið gagnagrunns-kerfi ætti þó frekar við þegar gagnagrunnurinn hefur verið hannaður og einhver forrit smíðuð til að meðhöndla hann. Þannig eru hvoru tveggja Microsoft Access og MySQL aðeins gagnasafns-umsjónarkerfi.

Þegar gagnagrunnur er aðgengilegur á Vefnum þýðir það að tölvan sem miðlar vefsíðum með gögnum úr gagnagrunni hafi aðgang að gagnagrunns miðlara eða Database Server og geti miðlað þeim gögnum sem sá miðlari geymir.

Gagnagrunns hugbúnaður

Gagnagrunns umsjónarkerfi, eða gagnagrunns hugbúnaður nefnist á ensku „Database Management System,“ skammstafað DBMS. Slíkur hugbúnaður þá ætlaður til að skilgreina og geyma gagnagrunna eftir einhverju kerfi og sníða mismunandi aðgengi að þeim gögnum sem grunnarnir geyma.

Yfirleitt er ætlast til þess að gagnagrunns hugbúnaður leyfi hönnuði grunnsins að sníða hann eftir eigin kröfum, hvort heldur gagnagrunninn sjálfan eða aðgengi að gögnum hans.

Flest slík kerfi bjóða forritunar skil (Application Programming Interface eða API) sem leyfa að gerð séu sérsniðin forrit er geti tengst við grunnana. Gott dæmi um slíkt er einmitt vefsíða sem vinsar upplýsingar úr gagnagrunni. Annað dæmi gæti verið Microsoft Access sem leyfir að smíðað sé forrit utanum grunninn.

Til eru ýmsar tegundir slíkra gagnasafns-umsjónarkerfa en vinsælust eru kerfi fyrir venslaða gagnagrunna (Relational Databases). Best þekktu dæmin fyrir einstaklings notkun og smærri fyrirtæki eru Microsoft Access, dBase og Borland Paradox. Þessi kerfi eru þó smápeð við hlið stóru gagnagrunns miðlaranna s.s. Oracle, Microsoft SQL Server, IBM DB2, PostgreSQL, SAP og MySQL, svo fáein vel þekkt nöfn séu nefnd.

Miðlara/biðlara vinnsla

Yfirleitt er gert ráð fyrir því þegar um gagnagrunns miðlara er að ræða að gagna­grunnurinn sé geymdur á sérstakri tölvu og þar sé keyrður sérstakur hugbúnaður, oftast sem púki eða Daemon sem stjórni öllum aðgangi að grunninum og þeim gögnum sem hann geymir. Slík uppsetning er jöfnun höndum nefnd miðlari eða þjónn (Server).

Miðlarinn sér um að miðla gögnum í grunninum til notendaforrita sem nefnast þá biðlarar (Clients) samkvæmt einhverri aðgangsstýringu (e. Access Control) og skammta notenda aðgengi (e. User Access).

Mikilvægt er þegar hér er komið að gefa aðgangsstýringu og notenda aðgengi góðan gaum.

Þegar gagnagrunnur er hannaður er ekki aðeins ákvarðað hvaða gögn séu geymd og hvernig heldur einnig hverjir geti séð hvaða gögn, hvernig þeir geti séð þau, og síðast en ekki síst hverjir mega eyða gögnum, bæta nýjum við eða dagrétta þau sem fyrir eru. Allt þetta er framkvæmt í miðlaranum en ýmist umbeðið eða skoðað gegnum biðlara.

Gagnagrunnsþjónar eða Database Servers miða ætíð að því að gögnin séu á netþjóni og biðlari sæki í aðgang að gögnunum gegnum nettengingu eftir atvikum. Þá er gert ráð fyrir að gögnin fái þeir einir séð sem hafa til þess tiltekin leyfi eða aðgang.

Yfirleitt er þannig gert ráð fyrir að mismunandi notendur með mismunandi aðgangsheimildir sjái misýtarleg gögn. Í slíkum tilfellum er einmitt mjög gott að hafa einhvers konar forritunarskil til að geta saumað aðgangsstýringar betur eftir þörfum. Sem dæmi væri grunnur sem leyfir starfsfólki að fletta upp vörum og gera tilboð en yfirmönnum að stofna nýjar vörur og skilgreina grunnverð.

Dr. E. F. Codd (f. 1923 d. 2003) var breskur stærðfræðingur sem vann að rannsóknum hjá IBM mest allan sinn starfsferil. Á sjöunda áratugnum hafði hann unnið allnokkuð við rannsóknir á gagna­grunnum og gagna­grunns notkun þess tíma. Um 1970 birti hann grein um venslaða gagnagrunna sem hefur gjörbylt allri hugsun varðandi gagnagrunns vinnslu síðan. Hann hafði komist að þeirri niðurstöðu að gagnagrunnar þess tíma og vinnsla með þau gögn sem þeir geymdu leiddi tíðum til skekkja (e. Errors) og umfremdar[1] (e. Redundancy). Árið 1953 flutti hann búferlum frá Bandaríkjunum til Kanada og bjó þar í um tíu ár, í mótmælum við baráttu McCarthy öldunga­deildar­þingmanns gegn Kommúnisma.

Ted Codd
birt með leyfi IBM

Greinina nefndi hann „A Relational Model of Data for Large Shared Data Banks“ (í. Venslað gagnalíkan fyrir stóra samnýtta gagnabanka). Þar kynnti hann til sögunar gagnalíkan og aðferðir til gagnageymslu sem átti að leysa öll þau helstu vandamál sem á þeim tíma tröllreið allri gagnagrunns vinnslu. Grein hans má finna á slóðinni http://www.acm.org/classics/nov95/toc.html.

Á þessum tíma var mikið um Hierarchical Databases og Networked Databases. Umfjöllun um þau gagnalíkön er utan bókarsviðsins en vert væri að benda á að fletta hugtökunum upp í http://www.hyperdictionary.com/dictionary/ eða í http://computing-dictionary.thefreedictionary.com/.

Árið 1974 hóf IBM þróun á kerfi sem nefndist System/R sem átti að sanna kenningu Codds um venslaða gagnagrunna. Þessi þróun leiddi til fyrstu útgáfu á fyrirspurnamáli sem notað var til að vinna með gögn í gagnagrunnunum sem System/R vann á. Fyrirspurna málið var nefnt SEQUEL sem er skammstöfun á „Structured English Query Language.“ Síðar var málið endurnefnt sem „Structured Query Language“ (skammstafað sem SQL) af lagalegum ástæðum og síðar var það gert að opinberum staðli á vegum American National Standards Institute (ANSI). Árið 1978 voru útgáfur af System/R í notkun hjá ýmsum viðskiptavinum IBM. Árið 1979 var verkefnið lagt niður með þeirri niðurstöðu að venslaðir gagnagrunnar væru vænleg nálgun á gagnagrunns vinnslu.

Það var ekki fyrr en 13 árum eftir að grein Codds kom fyrst út að IBM tók þá ákvörðun að framleiða gagnasafns-umsjónarkerfi sem byggði á kenningum hans og nefndi DB2. Þá hafði Lawrence „Larry“ J. Ellison þegar framleitt Oracle gagnasafns-umsjónarkerfi sitt frá 1977 og öðlast forskot sem hann heldur enn. Larry Ellison hafði í fyrstu ætlað sínu kerfi að vera samhæft System/R kerfinu en IBM leyfði fremur tak­markaðan aðgang að System/R sem leiddi til þess að Ellison þróaði sitt kerfi fullvaxið.

Gagnasafns-umsjónarkerfi á þessum árum þóttu aðeins eiga erindi í stærri tölvukerfum og vert er að hafa í huga að þegar IBM hóf þróun á „IBM PC“samhæfðu einkatölvunni 1979-80 var almennt talið að enginn myndi hagnast á slíku ævintýri. Í dag 25 árum síðar má finna gagnasafns-umsjónarkerfi í einhverri mynd á allflestum tölvum og í notkun alls staðar þar sem tölvur eru notaðar í einhverri mynd.

Þegar leitað er að efni á Vefnum með leitarvél er flett upp í gagnagrunni. Þegar debet korti er rennt í gegnum posavél er tengst við gagnagrunn. Þegar pantaður er flugmiði, bókað hótelherbergi eða vörur pantaðar eru höfð samskipti við gagnagrunna.

Raunin er sú að hér er á ferðinni ein elsta tegund af geymslusvæðum í tölvum en einnig er þetta nokkuð vel skipulagður gagnagrunnur! Tölvunotendur eru svo vanir að vinna með slíkar upplýsingar að þeir meðhöndla þær yfirleitt sem áþreifanlega hluti frekar en skipulagðar upplýsingar og gögn.

Skráasafn á Linux tölvu séð
með Bash skel í Linux.

Myndin hér á eftir eru sömu upplýsingar og á myndinni fyrir framan, eini munurinn er sá að nú er notað grafískt viðmótsforrit (e. Graphical User Interface) til að skoða gögnin. Grafíska forritið hefur samband við stýrikerfi tölvunnar og fær sama lista og áður en unnið er úr gögnunum svo að þau birtast notandanum sem mynd með táknum. Notandinn fær síðan í hendurnar tól sem leyfa honum að vinna með gögnin t.d. mús og hnappa.

Skrásafn á Linux tölvu séð
með FTP forriti í Windows

Myndin hér á eftir er sama eðlis og áður nema gagnalistinn er á skráakerfi tölvu með Windows stýrikerfi. Mappa í Windows er samskonar fyrirbæri og skráasafn eða Directory á Linux.Áður en Windows kom til sögunnar í PC heiminum var DOS stýrikerfið ráðandi sem einnig notaði hugtakið Directory. Bæði hugtökin eru notuð í þessari bók og eiga við sama fyrirbærið.

Ein mappa í trénu er opin svo hægra megin birtast öll þau skjöl sem í henni eru, hvert skjal er greinilega tagmerkt í stýrikerfinu fyrir stærð, heiti móðurforrits skjalsins og dagsetningu sköpunar eða breytingar skjalsins. Greinilega er hér á ferðinni vel skipulagt gagnasafn.

Notendahannað möpputré á Windows skráakerfi
séð með Windows Explorer

Það sem gerir þennan tiltekna gagnagrunn athyglisverðan er að hann býður beinlínis upp á sum þau vanda­mál sem Codd glímdi við í grein sinni. Engin regla í gagnasafninu getur komið í veg fyrir að skjöl með sama heiti séu geymd á mörgum stöðum. Slíkt kemur oft fyrir þegar unnið er með gögn t.d. að fyrsta útgáfa skjals er geymd á einum stað, næst þegar skjalinu er breytt gæti það hafa verið vistað (í afritunarskyni) á annan stað o.s.frv. Við slíkar aðstæður er nærri því vonlaust að hafa yfirsýn yfir hvaða skjal er réttast eða hefur nýjastar upplýsingar. Væru skjölin mörg og sérstaklega ef margir notendur hefðu samtímis aðgang að þeim, væri útilokað að hafa yfirlit yfir hvort óþarfa gögn væru geymd í mismunandi skjölum eða upplýsingar margendurteknar, s.s. umfremdar- eða umframgögn (e. Redundancy).

Tafla 1a

Nafn   Heimilisfang  Sími   Netfang       Veffang

Grjóti Stefsson      Aflatröð 5    599-1234      grjoti@aflatradir.net      www.aflatradir.net/grjoti

Jóndi Bullsson       Boðatröð 6    599-2341      jondi@bodatradir.net www.bodatradir.net/jondi

Gudda Karlsdóttir    Grandatröð    599-3412      gudda@grandatradir.net     www.grandatradir.net/gudda

Þessi skrá er mjög einföld aðeins fimm dálkar og afmörkun dálkanna er með dálka-merki (e. Tab delimited). Einnig mætti afmarka dálkana með öðrum afmarkara (þ.e. lesstaki) s.s. semíkommu (;) og einnig mætti afmarka gildi dálkanna sjálfra með tvíhöggi, samanber:

Tafla 1b

“Nafn”;”Heimilisfang”;”Sími”;”Netfang”;”Veffang”

“Grjóti Stefsson”;”Aflatröð 5”;”599-1234”;”grjoti@aflatradir.net”;”www.aflatradir.net/grjoti”

“Jóndi Bullsson”;”Boðatröð 6”;”599-2341”;”jondi@bodatradir.net”;”www.bodatradir.net/jondi”

“Gudda Karlsdóttir”;”Grandatröð”;”599-3412”;”gudda@grandatradir.net”;”www.grandatradir.net/gudda”

Þessi gögn eru e.t.v. ekki falleg á að líta eða fljótlesin enda ekki ætlast til þess. Tilgangur allra gagnagrunna, hvort heldur settir upp í einföldum textaskrám eða á annan máta er að tölvan geti lesið gögnin eftir einhverju kerfi. Fyrir þessa skrá mætti forrita fremur einfalt forrit sem a) læsi skrána og b) þáttaði (e. Parse) hana í línur, þar sem fyrsta línan hefði dálkaheiti, c) aðgreindi gildin og raðaði upp í línur og dálka eða raðaði upp á spjöld sem notandi grunnsins gæti síðan lesið, breytt, bætt inn eða eytt út og d) gæti skrifað í skrána hafi gögnin breyst eða hreinlega yfirritað hana. Einfalt ekki satt. Nú mætti bæta við forritið fáeinum notadrjúgum aðgerðum s.s. að raða nafnalistanum í stafrófsröð eða eftir heimilisföngum. Notandi gæti þá flett upp á notanda með því að leita eftir símanúmerum eða öðrum mismunandi skilyrðum.

Nú vandast málið ef sú þörf kemur upp að fleiri en einn notandi þurfi aðgang að skránni t.d. á Neti. Hvernig á að bregðast við ef tveir eða fleiri notendur eru að breyta upplýsingum og vista á sama sekúndubroti eða ef sömu línunni er breytt á sama tíma. Þetta mætti leysa þannig að forritið sem les skrána gæti læst aðgangi að henni á meðan hún er lesin í minni og aftur á meðan hún er skrifuð út, sem aftur getur hamlað vinnsluhraða ef t.d. 100 notendur væru að vinna með skrána á sama tíma. Augljóslega getur forritunar vinna vegna einfaldra gagna vaxið og vaxið.

Gott er að hafa hér í huga að 1970 þegar Codd er að birta hugleiðingar sínar um venslaða gagnagrunna með aðferðum „Vensla-algebru“ (e. Relational Algebra) – ekki má gleyma að Codd var fyrst og fremst stærðfræðingur – var öll tölvuvinnsla miðuð við tölvur af stórtölvu og millitölvu gerð og notendur tengdust tölvum sínum yfirleitt með einföldum-útstöðvum (e. Dumb terminals). Einstaklings tölvan sem hugtak þótti fáránleg og algengt var að notendur ynnu margir í einu með sömu gögnin.

Notendur Lýðnetsins eru bundnir að miklu leyti við samskonar vinnuhugmynd og þá var venja. Þegar notandi sækir og les vefsíðu, t.d. gagnagrunnstengdar upplýsingar á innankerfis (e. Online) pöntunarvef, er allt eins víst að hundruð og jafnvel þúsundir notenda séu að sækja sömu upplýsingarnar og hugsanlega á sama tíma. Aðal munurinn á þeim aðstæðum frá því sem var á blómatíma Codds, er að miðlarinn (eða stórtölvan) geta sent gögnin hrá til ráparans (e. Browser) sem getur þá tekið þátt í útlitsmótun upplýsinganna en slíkt er utan viðfangsefnis þessarar bókar.

Það sem þörf er á hér er öflugri lausn en skráakerfi stýrikerfisins geymsluvélarinnar. Lausnin gæti verið púki (e. Daemon) sem er vakandi í vinnsluminni geymslutölvunnar og stjórnar öllum aðgangi að skránni.

Púkinn gæti þá haft yfir að ráða stefjum og geymsluaðferðum sem þáttuðu gögnin  fyrir notendaforritið og tækju við þeim aftur til geymslu. Slíkur púki gæti hugsanlega sinnt þörfum fleiri biðlara forrita samtímis án þess að þau yrðu sérstaklega vör við tafir vegna læsingu á skráaaðgangi.

Gögnin í gagnasafninu gætu þá litið út gagnvart notendaforritunum eitthvað svipað því sem birtist í eftirfarandi töflu. Hér mætti hugsanlega miðla gögnunum þannig til notenda að þeir geti aðeins átt við gildi í einni línu í senn þannig að séu fleiri notendur að vinna með gögnin samtímis, finni þeir ekkert fyrir því svo fremi þeir séu að vinna með ólíkar línur.

Tafla 1c

Ennfremur væri sætt ef púkinn gæfi biðlurunum leyfi til að sækja takmarkaðan hluta gagnanna án þess að forritarinn þyrfti að hafa sérstaklega fyrir þáttun og frekari forskriftun (e. Scripting). Til að mynda mætti sækja öll gögn í töflunni þar sem heimilisfang væri „Aflatröð“ og raða í hækkandi röð eftir símanúmerum, eða í stafrófsröð eftir gildunum í nafn o.s.frv. Slík tækni myndi sérstaklega vera mikilvæg ef gagnaskráin innihéldi t.d. 500.000 línur og notandi gagnanna þyrfti aðeins að vinna með þær 50 línur sem hugsanlegt er að framangreint skilyrði gæfi af sér.

Þetta er þó ekki nóg. Aðal ástæða þess að Dr. Codd vann að hugmyndafræði sinni um venslaða gagna­grunna var, eins og fram hefur komið, að gagnagrunnskerfi þess tíma buðu upp á skekkjur og umfremdir. Ennfremur rakst Codd á ýmis frábrigði[1] (e. Anomalies) sem gátu komið upp við ýmsar aðstæður í gagnavinnslu. Greinin sem hann ritaði árið 1970 voru í raun niðurstöður rannsókna hans sem áttu að sýna með aðferðum stærðfræðinnar hvernig forðast mætti frábrigði, koma í veg fyrir skekkjur (e. Errors) og útrýma umfremdum.

Í viðtölum við samstarfsmenn Codd frá þessum tíma hefur komið í ljós að fyrstu viðbrögð manna við niðurstöðum hans voru að hrista hausinn og segja sem svo „hver nema stærðfræðingur kemur fram með svona?“ Aðrir svo sem Larry Ellison lásu hinsvegar grein Codds og komust að raun um að lausn hans er afar einföld, ekki nóg með það hún svínvirkar. Svo rækilega virkar hún að Larry Ellison er einn ríkari manna samtímans og þú ert að lesa þessa bók. Ekki nóg með það heldur eru allar líkur til þess að þú notir daglega gagnasafns-umsjónarkerfi í einhverri mynd.

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.

Einindi samkvæmt Tölvuorðasafninu er: „Sérhvert hlutrænt eða hugrænt fyrirbæri sem er til, hefur verið til eða gæti orðið til, þar með talin tengsl milli fyrirbæranna. [dæmi] Persóna, hlutur, atburður, hugmynd, ferli o.s.frv. [skýr.] Einindi er til, hvort sem gögn um það eru tiltæk eða ekki.“

Samkvæmt þessari skilgreiningu má því líta á fyrirtæki sem sérstakt hugsanlegt einindi. Maður er einindi, borð er einindi. Einindi sem til er í hlutveruleikanum er oft nefnt tilvik ímyndaðs einindis. Þannig ímyndum við okkur hvernig borð lítur út og hvaða eiginleika það hefur. Raunverulegt borð er þá hlutgert tilvik þeirrar hugmyndar. Hvorutveggja, tilvikið og hugmyndin, geta verið einindi.

Hugsanlegt fyrirtækis einindi hefur nafn, heimilisfang og samskipta gáttir s.s. síma, fax, veffang ofl. Einindið fyrirtæki er þannig almenn lýsing á fyrirtækjum sem hægt er að máta við raunveruleg fyrirtæki. Fyrirtækið Hugbrjótur ehf. er þá tilvik af einindinu fyrirtæki. Hugbrjótur ehf. er þannig einindi líka. Einskonar holdgerving hugmyndar sem lýst hefur verið.

Sé þessari hugsunar-aðferð beitt á Töflu 2a má sjá að hún geymir tvö skýr einindi, Fyrirtæki og Tengiliður. Fyrirtæki hefur heiti, staðsetningu og samskiptagáttir. Tengiliður hefur nafn, titil, heimilisfang og samskiptagáttir. Einnig má greina tvö önnur einindi þegar betur er að gáð en það eru Heimilisfang og Svæði.

Einindi er þannig hugtak (eða aðferð) til að lýsa einhverju sem getur átt sér sjálfstæða tilvist.

Þegar þessari aðferð er beitt á töflur koma upp á yfirborðið spurningar á borð við: „Hversu smá­muna­samlega þarf ég að skipta töflunni upp í einindi?“ Tökum sem dæmi einindið Svæði. Svæði hefur aðeins tvö atóms-gildi, númer og heiti. Ágóðinn af að klippa Svæði út úr töflunni og smíða sérstaka töflu fyrir það er ótvíræður af sömu ástæðum „dagréttinga-frávika“ og áður hafa komið fram.

Nú myndi það spara vinnu við innslátt ef upplýsingar um póstsvæði væru fluttar í sérstaka töflu, í stað þess að slá inn „0210 Garðabæ“ (og stöku sinnum slá inn skekkjuna Garðabær) t.d. 100 sinnum fyrir hundrað einstaklinga eða fyrirtæki í Garðabæ, væri nóg að slá inn númerið sjálft, 0210[2]. Þegar flett væri upp á tilteknu fyrirtæki mætti nota póstnúmerið til að fletta upp heiti þess í viðkomandi töflu.

Tilvik eininda (e. Instance, Entity instance, Instance of Entities) er þegar tafla fær áþreifanlegar (e. Concrete) upplýsingar um einindi sem raunverulega er til í viðfangs?veruleikanum[3] (e. Universe of discourse) sem gagna­grunnurinn nær til. Viðfangs-veruleiki er einnig nefndur raunheimur. Gagna­grunnurinn geymir með öðrum orðum upplýsingar um raunveruleg einindi sem til eru í raunheimi, eða viðfangs-veruleika. Samkvæmt framangreindu má líta á hugsanlegt fyrirtæki sem ákveðið einindi en þegar tiltekið fyrirtæki sem raunverulega er til er fært inn í töfluna má líta á þá færslu sem raunverulegt tilvik einindis. Fyrirtækið er til í raunheimi.

Smá innskot

Ég geri mér vel ljóst að byrjendum í svona umfjöllun líður ekkert voða vel þegar hingað er komið. Ég hef sjálfur verið í þeim sporum. Eitt sinn fékk ég viðamikla sýnikennslu í notkun gagnagrunna og var dálítið vankaður á eftir. Síðar þurfti ég að vinna með gögn og skipuleggja smærri gagnasöfn fyrir lítinn rekstur. Mjög fljótt varð ég var við, eftir því sem reynslan jókst, að þessi grunnur sem hér er framsettur styður við þessa reynslu og gerir hana ánægjulegri eftir því sem líður á. Í rauninni myndi ég hvetja byrjendur til að lesa kaflann hratt yfir, æfa sig í sýnidæmunum í næsta kafla og lesa þennan kafla aftur síðar.

Atómgildi og gildamengi

Atómgildi er gildi sem ekki verður brotið upp í einingar. Heiltalan 10 er atóm-gildi og mannsnafnið Adam er atómgildi (þó það sé samsett úr rittáknum). Mannsnafnið „Adam Alfreð Atlason“ er ekki atómgildi því það er samsett úr þrem stökum gildum. Atómgildi getur þó verið nokkuð teygjanlegt því við gætum þurft að líta svo á að fornafn-föðurnafn sé atóms-gildi eftir atvikum við hönnun tiltekins gagnasafns. Hérlendis eru einstaklingar yfirleitt skráðir með fullu nafni eða fornafn og föðurnafn saman en millinöfn sér. Erlendis er algengt að fornafn og föðurnafn/ættarnafn sé skrásett sitt í hvoru lagi.

Einindi er samsett úr atómgildum[4] (e. Atomic Values). Þetta þýðir t.d. fyrir einindið Fyrirtæki að ekki er hægt eða raunhæft að skipta nafni þess upp í einingar og ekki heldur númeri línunnar (eða færslunnar). Númer færslunnar fyrir Hugbrjótur ehf. er talan 1 sem er heiltala. Nafn fyrirtækisins í dálkinum (eða sviðinu) Fyrirtækisnafn er „Hugbrjótur ehf.“ sem er bókstafa-strengur. Orð og orðasambönd í tölvunar- og gagnagrunnsfræðum eru jafnan nefnd Strengir. Strengir eru röð rittákna sem lesin eru saman í einu lagi. Stakir stafir eru venjulega nefndir stafir, tákn eða rittákn. Þessi tvö svið má þannig skilgreina sem „Nr“ af taginu (e. Type) heiltala (e. Integer) og „Fyrirtækisnafn“ af taginu strengur (e. String).

Þegar einindum er skipt upp í atómgildi sín þá er hvert gildi sett innan ákveðins gildissviðs, t.d. hlýtur röð bókstafa að lenda innan gildissviðs strengja, tölur sem ekki innihalda brotatölur lenda innan gildissviðs heiltalna og tölur sem geta innihaldið brot innan gildissviðs rauntalna. Gildi sem gefa til kynna satt/ósatt, rétt/rangt, já/nei, af/á eru rökgildi á ensku nefnd „Boolean values“ eftir Ensk?Írska stærð­fræðingnum Boole. Í gagnagrunnsfræðum eru slík gildi yfirleitt táknuð með 0 (ósatt) eða 1 (satt).

Gildistegundir í gagnagrunns fræðum eiga sér gildamengi[5] (e. Domain). Með gildamengi er átt við að t.d. heiltölur geta verið heilar jákvæðar eða neikvæðar tölur eða núll. Strengir hafa það gildamengi að geta verið röð rittákna sem rita má með eðlilegu ritmáli eða tómur strengur. Brotatölur (eða kommutölur) séu tölur sem geta haft aukastafi eða brot.

Gildismengið tiltekur jafnan hversu langt það getur verið. Til dæmis getur mannsnafn verið í þjóðskrá Íslands allt að 31 staf og nafn einstaklings getur ekki verið ekkert (NULL). Mánaðafjöldi í almennu dagatali getur verið frá 1 og upp í 12 og getur ekki verið ekkert því alltaf er til mánuður[6].

Mannsnafn myndi falla undir gildamengið strengur og mánaðafjöldi undir heiltölu. Auk þess má tilgreina gildissvið mengisins. Streng má tilgreina að hann geti verið hámark 31 stafur og velja má að mánaðafjöldi sé innan gildissviðsins mjög-lítil-heiltala (e. Tiny-Integer eða TINYINT) sem í MySQL er á gildissviðinu ?128 til 127.

Gildamengi er aðeins hugtak til að tilgreina hvers konar gildi séu gefin á einindi. Ef við t.d. skoðum einindið „Adam Atlason fæddur 1.1.1970.“ Þetta einindi á tvo eiginleika (e. Attributes), nafn og fæðingardag. Við getum geymt nafnið sem streng (gildamengi strengja) og fæðingardag sem dagsetningu. Gildamengi dagsetningarinnar sé þá Gregoríanskt dagatal? Með öðrum orðum þá er gildamengi aðeins reglur til að skilreina eðli þeirra eiginleika þ.e. eiginda, sem einindin hafa.

Einindið Hugbrjótur ehf. hefur þannig eigindin Nr, Nafn, Heimilisfang, Svæði, Aðalsíma, o.s.frv. Hvert eigindi sem slíkt dvelur innan ákveðins gildissviðs t.d. getur Nr. verið frá 0, 1, 2,  og uppúr en ekki  ?1 og niðurúr, allt í heilum tölum.

[1] Þess er gætt eins og kostur er í hugtakaskilgreiningum að notast við Tölvuorðasafn Íslenskrar málnefndar. Sakir skammleika (e. Brevity) er ekki hægt að gera öllum enskum hugtökum nægilega góð skil svo enskum hugtökum er dreift hér og þar í texta bókarinnar. Lesendur eru hvattir til að nota ágæta leitarvél Tölvuorðasafnsins á http://ismal.hi.is/ til að fletta þeim upp.

[2] Póstnúmer á íslandi eru númeruð frá 101 til 902 en í þessari bók hefur verið bætt tölunni 0 framan við póstnúmerin. Þetta er gert til tákns um að allar upplýsingar í gagnagrunnum bókarinnar eru skáldaðar og skrefi frá raunverulegum (almennum, íslenskum) gagnagrunnum. Búast má við af þessum sökum að ýmis póstnúmerasvæði í grunnum bókarinnar séu ekki til á íslandi. Sama afstaða er tekin t.d. til kennitalna, engin raunveruleg kennitala mun finnast í þessari bók.

[3] Margar gagnagrunnsbækur enskar, nefna viðfangs-veruleika eða Universe of Discourse þann veruleika sem við viljum geyma upplýsingar um. Viðfangs-veruleiki getur verið félagaskrár, þjóðskrár eða einkunnatöflur.

[4] Tölvuorðasafnið hefur ekki komið með tillögu fyrir gagnagrunns, og forritunarhugtakið, „Atomic value.“ Atómgildi, eða atómlegt-gildi verður því notað í bókinni.

[5] Þegar þetta er ritað hefur Tölvuorðasafnið ekki gefið út tillögu fyrir þýðingu á gagnagrunns hugtakinu Domain. Domain merkir á öðrum sviðum ýmist lén, umdæmi eða sérsvið. Hér hefur verið valin merkingin gildamengi sem merkir á ensku „set of values.“

[6] Heimspeki er utan efnissviðs bókarinnar, en er mánuður yfirleitt til nema sem hugtak?

Hverri töflu sé skipt upp í dálka (Column) sem nefnast svið (Field). Fyrsta lína töflunnar geymir heiti sviðanna en þessi lína er ekki meðhöndluð sem gögn heldur sem lýsing á hinu hugsanlega einindi.

Hvert einindi sem til er í viðfangs veruleikanum er skráð inn í töfluna og kallast þá tilvik einindis (Instance of entity).

Einindi eru stundum samsett úr upplýsingum sem tilheyra annars konar einindum. Það eru upplýsingar í öðrum töflur en hægt er að tengja þau saman og fletta þeim upp eftir einhverju sameiginlegu gildi. Þannig pörum við skyld einindi eftir skyldleikum sínum eða venslum.

Hið sameiginlega gildi er því skyldleiki beggja eininda.

Ef fyrirtækið Hugbrjótur ehf. inni­heldur atómsgildið 0210 fyrir póstsvæði þá má fletta því upp í töflunni Póstsvæði og finna þar heiti póstsvæðis nr. 0210 sem gæti verið Garðabær. Hér er kominn skyldleiki eða vensl á milli fyrirtækis töflunnar og póstsvæða töflunnar. Öll fyrirtæki búa á póst­númeruðu svæði og öll póstnúmeruð svæði eiga sér heiti.

Töfluheiti: Fyrirtæki.

Hér birtast tvær töflur annars vegar Fyrirtæki og hins vegar Einstaklingar. Við viljum sækja lista yfir tengiliði t.d. hjá Hugbrjóti ásamt  símanúmeri tengiliðs;

Gætum við þá gert venslaða fyrirspurn á báðar töflur í einu þar sem parað er saman sviðið „Nr“ í Fyrirtæki og „Fyrirt nr“ í Einstaklingar og sett sem skylirði að sýna eingöngu færslur þar sem Nr er 1. og fengjum þá upplýsingar um Grjóta og Fríðu.

Töfluheiti: Einstaklingar.

Eins og sjá má þá er hver tafla í raun mengi (Set) yfir þau átómsgildi sem lýsa tilteknu einindi og þó sum einindi eigi hugsanlega samskonar gildamengi þá þarf hvert mengi að lýsa með auðskildum hætti því einingi (Entity) sem um ræðir.

Þó Fyrirtæki og Einstaklingar eigi heimilisföng og samskiptagildi þá er klárlega um ólík einindi að ræða en þó skild eða vensluð. Fyrirtæki geta haft starfsmenn en einnig geta sumir einstaklingar verið eigendur fyrirtækja og þá vaknar sú spurning hvort smíða þurfi sér töflu til að skilgreina Eigendur en líklega væri nóg að hafa þar tvo dálka og þá lyklaða sem eina heild.

Í töflunum, Fyrirtæki og Einstaklingar er listi af aðilum sem hafa heimilisföng sem götuheiti og póstsvæði. Póstsvæði er samsett gildi úr póstnúmeri og heiti svæðis og geymt í töflunni Póstsvæði.

Nú er gerð fyrirspurn sem sækir upplýsingar um Hugbrjótur ehf. og alla tengiliði sem við höfum við það fyrirtæki, ásamt póstsvæðum: „Veldu allar færslur um einindi í töflunum Einstaklingar og Fyrirtæki, þar sem númer fyrirtækis er 1 og fyrirtækis númer einstaklings sé líka 1, birtu einnig upplýsingar um póstsvæði í niðurstöðunni.“

Á gagna­grunns­máli væri þetta orðað þannig:

select * from einstaklingar, fyrirtaeki, postsvaedi
 where fyrirtaeki.fyrirt_nr = 1
 and fyrirtaeki.fyrirt_nr = einstaklingar.fyrirt_nr
 and fyrirtaeki.postnumer = postsvaedi.postnr;

Gagnagrunns kerfið myndi skila eftirfarandi gögnum:

Einnig mætti setja sömu fyrirspurn upp þannig að færri dálkar kæmu fram í  niðurstöðunum samanber eftirfarandi:

select e.einst_nr, e.fyrirt_nr, e.nafn, e.starfstitill,
 f.fyrirt_nr, f.fyrirt_nafn, f.fyrirt_heim, f.postnumer,
 f.adalsimi, p.postnr, p.heiti
 from einstaklingar as e, fyrirtaeki as f, postsvaedi as p
 where f.fyrirt_nr = 1
 and f.fyrirt_nr = e.fyrirt_nr
 and f.postnumer = p.postnr;

Niðurstöðurnar væru þá ögn læsilegri í framsetningu:

Myndin hér á eftir sýnir hvernig grunnurinn finnur línu í fyrirtækis töflunni þar sem fyrirtækis númerið er 1. Tvær línur í einstaklings töflunni þar sem fyrirtækis númerið er líka 1. Póstnúmer og heiti svæðis í póstsvæðis töflunni þar sem póstnúmerið er hið sama bæði í póstnúmeratöflunni og fyrirtækistöflunni.

Myndræn framsetning á fyrirspurnunum hér fyrir framan.