Vöruhús Gagna Skilgreining á hugtökum, praktískt ráð og reynslusögur. Gagnasafnsfræði Haust 2008

Lestrarlisti Í bók Á netinu Biblían Verkefni kynnt á föstudaginn Kafli 25 25.1, 25.2, 25.21, 25.3, 25.5.1, 25.6, 25.6.1, 25.6.2, 25.7, 25.7.1, 25.8, 25.8.1, 25.8.2, 25.9, sleppa öðru Athugið að Postgres virðist ekakert styðja SQL-1999 staðalinn sérlega vel þegar það kemur að vöruhúsarfyrirspurnum. Sjálfur hef ég komist mjög langt á að nota bara SQL-92 og sýnir. Á netinu http://en.wikipedia.org/wiki/Data_Warehousing http://download.oracle.com/docs/cd/B10501_01/server.920/a96520/concept.htm http://en.wikipedia.org/wiki/Snowflake_schema http://en.wikipedia.org/wiki/Star_schema http://en.wikipedia.org/wiki/Extract,_transform,_load http://en.wikipedia.org/wiki/Data_mart http://en.wikipedia.org/wiki/Operational_data_store Biblían Ralph Kimball,The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling http://www.amazon.com/Data-Warehouse-Toolkit-Complete-Dimensional/dp/0471200247/ref=pd_sim_b_2/189-6860596- 0925651 Fyrir þá sem vilja fara alla leið, alls ekki partur af námskeiðinu Verkefni kynnt á föstudaginn Verkefnið er leysanlegt á Postgres kerfi. Krefst þess að nota Java og JDBC. 4 töflur í upphafi, 15000 línur, 50000 línur, 18 línur og 5000 línur eða c.a 15mb af gögnum sem þið þurfið að vinna með.

OLTP (On-line Transaction Processing) Það efni sem hefur verið hingað til í námskeiðinu Bein hreyfingavinnsla Normalizeraðar töflur Fyrirspurnir sérhæfðar og skrifaðar af forriturum Hannað fyrir daglegan rekstur og oftast fyrir sértækt umdæmi gagna. Litlar og stuttar hreyfingar. Ein lína inn í nokkrar töflur og nokkrar línur út til birtingar. Kallað “transactional gagnagrunnar” dags daglega.

OLAP (On-line Analytical processing) Vöruhúsaaðferðin í gagnasafnsfræði Hentar betur til greininga á gögnum og til stuðnings ákvörðunartöku. Hægt að spyrja flókinna spurninga á einfaldan hátt. Gögn koma víða að yfir langan tíma Úttakið er vanalega fylki af samanteknum gögnum sem er svo notað í skýrslur, línurit, kökurit og þessháttar framsetningu. Hugmyndafræðin byggir á töflureikningslíkani frekar en venslalíkani. Uppfærsla gagna sjaldan tíðari en 1x per sólahring. Förum dýpra í þetta. OLAP er að mörgu leiti hugtak til markaðsetningar, hálfgerður frasi.

Vöruhús v.s Codd skipulagning gagna Í vöruhúsi erum við með gagnatöflur sem innihalda staðreyndir og eru vanalega tölulegar upplýsingar og svo vensl á víddir sem gefa þessum staðreyndum merkingu. Þá er auðveldara að átta sig á gagnaskipulaginu og fyrirspurnir verða almennt einfaldari og fljótari. Vöruhús er gert til þess að vera öflugt og snöggt við að svara fyrirspurnum en er hinsvegar hægt og þunglamalegt við innsetningu gagna. Það er hinsvegar erfitt að breyta högun vöruhúss eftir á og það krefst töluverðar vinnu að tryggja að gögnin séu rétt sett inn í það, enda eru sömu upplýsingarnar margt oft endurteknar. Codd skipulagning í c.a 3 bcnf er almennt það sem hefðbundin skipulagning gagna endar í. Þá er mun auðveldara að tryggja að gögn séu rétt sett inn í gagnasafnið, endurtekning upplýsinga er nær engin og það tekur stuttan tíma að setja inn nýja línu í viðkomandi töflu. Hinsvegar getur það tekið langan tíma að gera flóknar fyrirspurnir á slíka gagnahögun og hún brotnar ef að allar töflur þurfa að hafa tímastimpla. Semsagt, högun vöruhúss er meira einsog töflureikningslíkan heldur en venslalíkan.

Vöruhús Gagna (Data Warehouse) Samræmt safn gagna frá mörgum stöðum á einn stað. Uppfærsla á reglulegum fresti. Gögn flokkuð eftir merkingu. Öll gagnastök sem tengjast sama viðburði eða hlut eru vensluð saman í vöruhúsinu. Athugið að í dag er frekar notast við Data Marts til að safna saman gögnum eftir merkingum og síðan eru þessi fyrirbæri sett saman í Vöruhúsið eða öllu er safnað saman í Vöruhúsið og rétt venslað saman og svo eru hlutir dregnir út úr því í minni vöruhús sem Data Marts eftir merkingu. Gögn samhæfð og hreinsuð Gögn geymd til framtíðar Gögn oftast tímatengd Minni þörf á samhliða vinnslu Best að tryggja að skrifaðgerðir gerist aldrei nema á þeim tíma sem enginn lestur á sér stað. Skrifa inn á næturnar Skýrslugerð og gagnanám á daginn Vöruhúsið má ekki hafa áhrif á afköst þeirra OLTP kerfa sem það neytir gagna frá.

Samræmt safn gagna Við höfum mismunandi gögn á mismunandi stöðum. Það er ekki til neitt ‘ríkis’ skipulag á því hvernig viðkomandi gögn eiga að vera vensluð. Viljum eitt sameiginlegt gagnalag yfir þær upplýsingar sem fyrirtæki/stofnun hefur í mörgum mismunandi kerfum Flestar stofnanir og fyrirtæki hafa nokkur kerfi, sum þessara kerfa eru að halda utan um eða nota sömu eða svipaðar upplýsingar. Sérstaklega þjóðskrá, símaskrá, póstnúmeraskrá og önnur stofngögn Hvað á að gera ef að þörf skapast fyrir því að gera skýrslur þvert yfir þessi kerfi sem eru til og eru í rekstri hjá viðkomandi fyrirtæki? Sum gögn eru jafnvel ekki í gagnagrunni, þau geta verið geymd í textaskrá, náð í þau í gegnum vefþjónustu, eða jafnvel eru upplýsingarnar aðeins sýnilegar og reiknaðar út í ákveðnu viðmóti í ákveðnu kerfi og hvergi skráð niður og vistað! Það er því mikill kostur að geta samræmt öll þessi gögn til upplýsingar á einn stað. Það er annaðhvort gert með að búa til eitt stórt módel úr öllum þessum gögnum sem byggir á því hvernig stofnunin/fyrirtækið er skipað. (Top-down) Eða með því að draga út helstu upplýsingar eftir samhengi og vinna svo sameiginlegt lag ofan á það. (Bottom-up).

Uppfærsla á reglulegum fresti Yfir einn dag getur gagnamódel fyrir ákveðið kerfi í rekstri breyst töluvert. Nýjar sölur skráðar, nýjar pantanir, pantanir afkallaðar, sölum breytt, lagerstaða breyst, o.s.fv. Það er því í sjálfu sér aldrei til nein ákveðin staða í gagnasafninu fyrir gefin tímapunkt því kerfi eru oftast gerð til þess að sýna sannleikann í núinu. Með því að taka gögn úr svona transactional kerfum á reglulegum fresti, sem er oftast í lok hvers vinnudags eða á næturnar, þá má búa til stöðu sem heyrir til ákveðinnar dagsetningar. Það má svo nýta sér tíðni uppfærslu til frekari skýrslugerðar. T.d er þá hægt að sjá breytingu í sölu milli daga, fjölda breytinga að meðaltali í pöntunarferli eftir viðskiptavini og fjöldan allan af öðrum afleiddum upplýsingum sem transactional kerfið sjálft getur ekki boðið upp á.

Gögn samhæfð og hreinsuð Upplýsingar um sama hlutinn geta komið frá mörgum stöðum. Í sumum tilfellum eru þessar upplýsingar eins, í öðrum getur eitt kerfi komið með frekari upplýsingar um sama hlutinn. T.d hefur Lánstraust upplýsingar um það hvort að einstaklingur sé á vanskilaskrá. Þá er rakið að merkja 0 eða 1 í dálk í þjóðskránni hvort að viðkomandi sé í vanskilum, eða viðhalda viðskiptavinavídd með sérstakri vanskilauppflettingartöflu. Hér þyrfti þá ávalt að tryggja að upplýsingarnar væru réttar m.t.t tíma. Í öðrum tilfellum geta verið fleiri raðir um sama hlutinn frá einu kerfi miðað við annað. Versta tilfellið er þegar að kerfi eru ekki sammála. Þá þarf að rannsaka mismuninn á milli kerfanna og búa til réttar reglur við samhæfingu þeirra. T.d getur eitt kerfi troðið erlendum viðskiptavinum í íslenska þjóðskrá en annað kerfi er með hreina þjóðskrá frá Hagstofunni og sérstaka töflu fyrir erlenda viðskiptavini. Kerfi og gögn geta innihaldið gallaðar upplýsingar. Best er auðvitað að laga kerfin svo það gerist ekki, en ef það er ekki hægt, þá þarf að hafa síur sem að tryggja að gögn séu hrein og rétt.

Gögn geymd til framtíðar Þegar gögn eru tekin úr kerfum í rekstri þá er vænlegast að haga því þannig að þau séu geymd til framtíðar. Gott er að hafa afrit af gögnunum í svokölluðum staging gagnagrunni þar sem tímastimpill er á hverri línu sem tekin er úr kerfinu. Svo er nánast algjörlega öruggt að gagnatöflur sem sífellt bæta við sig línum í vöruhúsinu séu tímaháðar. Það er hægt að nýta þennan eiginleika til þess að læsa gögnum sem eru orðin ákveðið gömul og setja þau í sérstakt afritunarferli. Vöruhúsið og afurðir þess eru þá orðið skjalasafn þess sem það á. Afrit úr öðrum kerfum verða ekki jafn krítísk ef þetta er rétt gert. Auðvelt verður þá að skoða breytingar milli tímabila, daga, ára og þessháttar sem og að sannreyna og endurreikna mikilvægar stærðir sem byggjast á gögnum sem ekki eru lengur til í viðkomandi kerfum. Það er mjög mikilvægt að reikna út stækkunarþörf vöruhúss sem fall af tíma. Hvað er að koma mikið inn af gögnum á hverjum degi? Hver er vöxturinn á gagnamagni á mánuði? Er til nóg diskapláss í nákominni framtíð til þess að vöruhúsið geti verið áfram í rekstri án áhættu. Oft eru mjög gömul gögn tekin og þjöppuð saman svo ekki verður lengur til upplýsingar um hverja línu í gagnatöflu heldur bara summur, meðaltöl og þessháttar eftir helstu víddum. Þetta sparar pláss og getur aukið afköst en er í sjálfu sér stórhættuleg aðgerð m.t.t mikilvægi gagna og hversu ódýrt það er að kaupa meira diskapláss.

Star-Schema

Snowflake-Schema

Galaxy Schema

Högun Vöruhúsagagna Gagnatafla (e. Fact Table) Inniheldur gögnin niður á fínasta greiningarstig. Hver lína inniheldur oftast einhver gildi (e. measures) og svo dálka sem venslast við víddartöflur. Eina leiðin til að fá aðeins eina línu úr fyrirspurn á gagnatöflu er að skorða hana með öllum þeim víddartöflum sem hún er háð. Víddartafla (e. Dimension Table) Fyrir hverja vídd er til ein tafla sem gagnataflan venslast við. Þessi tafla inniheldur svo frekari upplýsingar um víddina. Í hefðbundni Star-schema hönnun er aðeins ein tafla per vídd. Í Snow-flake-schema er víddin oft normalizeruð og vensluð við fleiri töflur en bara gagnatöfluna. Þó er áfram bara einn lykill í víddinni sem að gagnataflan venslast við. Hér er hætta á að fyrirspurnir geti haft Chasm og Fan gildrur.

Atriði varðandi högun Gerfilyklar Æskilegast er að nota gerfilykil (e. Surrogate key) fyrir hverja línu í gagnatöflu og í hverja línu í víddartöflu til að hraða fyrirspurnum og draga úr gagnamagni vöruhúss. Í sumum tilfellum geta margir dálkar í gagnatöflu venslað í sömu víddina, en þá hafa venslin mismunandi merkingu. T.a.m getur áskrift hafist á ákveðnum tímapunkti og endað á öðrum tímapunkti. Gagnatöflur eru vanalega grannar með mikið af línum en víddartöflur eru vanalega víðar með færri línur. Víddartöflur geta verið frá því að vera með fleiri línur (e. rows) en gagnataflan út í það að hafa aðeins nokkrar línur. Það er sjaldgjæft að víddir hafi þó fleiri línur en gagnatöflur og bendir frekar þá til lélegrar útfærslu.

Hlé

Víddir

Skýrslur

OLAP fyrirspurnir Hópun (e. Aggregation) Rúlla upp (e. Roll-up) Nánast án undartekningar er hópun beitt á fyrirspurnir í gagnatöflu. Eina skiptið þar sem ekki er verið að nota hópun er þegar allar skorður á gagnatöflu eru notaðar í fyrirspurn. Rúlla upp (e. Roll-up) Hópað upp á hærra stigveldi víddar. T.a.m væri farið úr að skoða sölur á mánuði yfir í sölur á ári. Bora niður (e. Drill-Down) Skorðu bætt við gagnatöflu þannig að verið er að skoða hluti í fínara samhengi. T.a.m er upphafleg skýrsla útlán eftir útibúum en með að smella á ákveðið útibú er farið að skoða útlán eftir útlánategundum hjá því útibúi. Vendiárferð (e. Pivoting) Skoða niðurstöður þar sem dálkar verða línur og öfugt. Fara úr því að sjá summur gilda fyrir ár (línur) á móti t.d verslunum (dálkar) í summur gilda fyrir vörur (línur) á móti árum (dálkar). Skera og hluta (e. Slice and Dice) Velja eftir einhverri vídd (T.d Árið = 2008). Einnig að minnka fjölda dálka fyrir sértækar skýrslur eða til að búa til línurit.

Slowly-changing dimensions vandamálið Gögn víddum geta breyst hægt og rólega eftir því sem tíminn líður. Dæmi – Einstaklingur flytur og því breytist heimilisfang hans í þjóðskrárvíddinni. Hvernig á að takast á við þetta vandamál? Ralph Kimball telur upp 3 almennar leiðir til þess Yfirskrifa gömlu gildin í viðkomandi línu. Bæta við nýrri línu með nýju upplýsingunum og hafa þá aðferð, oftast tímastimpla, sem segir til um það hvenær hver lína er gild. Bæta við nýju eigindi við þá línu sem þegar er fyrir.

ETL (Extract, Transform, Load) Ferlið við að ná í gögn og setja inn í Vöruhús er oft kallað ETL. Það þarf að ná í gögn einhvert (extract), umbreyta þeim oft (transform) og hlaða inn í vöruhúsið (load). Extract Gögn eru ekki alltaf endilega aðgengileg í sama gagnagrunnskerfi og Vöruhúsið keyrir á. Það gæti þurft að opna skrá sem kemur inn á FTP þjón, nú, smíða sérstaka sýn á gögn, o.s.fv og koma þeim á stað þar sem hægt er að vinna með þau frekar. Transform Gögnin geta í senn verið óhrein, of normalizuð, vantar að bæta við öðrum upplýsingum við hverja línu, summera upp, o.s.fv. Umbreytingin gerir gögn tilbúin til innsetningar í vöruhúsið. Load Gögnin þurfa að fara inn í réttar töflur og dálka í vöruhúsinu. Þau þurfa að fara inn í réttri röð. Tímasetning innsetningar skiptir líka miklu máli. Það þarf að tryggja að villur við innsetningu hafi engin slæm áhrif á vöruhúsið og hægt sé að halda áfram innsetningu ef eitthvað kom upp á með lágmarks tilkostnaði.

Vöruhúsarferlið Exctract Transform Load

Chasm og Fan gildrur Chasm-gildra Fan-gildra Ef að skýrsla er gerð þar sem tvö 1:n vensl fara á sömu töfluna og það vantar niðurstöður úr þeirri töflu þá þarf að hafa gætur á hvernig farið er að því. Í sumum tilfellum er betra að endurskilgreina vensl í módelinu, eða bjóða upp á bæði venslin. Fan-gildra Ef að skýrsla er gerð þar sem ein vídd venslast á aðra vídd sem svo venslast á gagnatöfluna. Þ.e.a.s 1:n vensl á 1:n vensl og við höfum ekki réttar skorður á efsta stigveldinu, þá getur skýrslan innihaldið n-falt of mikið af línum. Það sama getur einnig gerst ef að seinni 1:n venslin ættu að vera aðeins af einni tegund. Þar sem skýrslur eru oftast hópaðar eftir víddargildum þá getur verið erfitt að taka eftir þessum vandamál. Þó myndi þetta t.a.m oft sýna sölur upp á milljarða í stað þúsundkalla í söluvöruhúsi o.s.fv.

Frá gögnum að ákvörðun

ETL ferli í SSIS

Business Objects skýrslugerð Sýna demo http://www.businessobjects.com/product/catal og/web_intelligence/

Ef tími gefst til Teikna upp vöruhúsarskema fyrir forsetakosningar í Bandaríkjunum.

Verkefnið www.hi.is/~johagu/DWVerkefni.zip PDF Skjal sem lýsir verkefninu Skila skal verkefninu sem PDF skjali, einn yfir kafli fyrir hvern verkefnisþátt og undirkaflar eftir þörfum. Lagfæringar á vöruhúsinu og breyting yfir í snow-flake skemu (20%) Skýrslur (30%) Skýrsluniðurstöður Sýniskóði og hvernig kallað er á sýn fyrir hverja skýrslu Innkeyrsla gagna (30%) Ferlislýsing Forritskóði Vandamál ef einhver Rökstuðningur fyrir að gögn fóru rétt inn (10%) Skýrslur keyrðar aftur (10%) Hér þarf bara að sjá skýrsluniðurstöður Verkefnisþættir eru háðir því að verkefni á undan hafi verið lokið.