Vöruhús GagnaSkilgreining á hugtökum, praktískt ráð ogreynslusögur.Gagnasafnsfræði Haust 2008

Lestrarlisti Í bók

◦ 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ögunGerfilyklar

Æ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)

◦ 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 þess1. Yfirskrifa gömlu gildin í viðkomandi línu.2. 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.

3. 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.

Exctract Transform Load

Vöruhúsarferlið

Chasm og Fan gildrur

Chasm-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/catalog/web_intelligence/

Ef tími gefst tilTeikna 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ð.