Hej!

Funderar på hur ni definierar datawarehouse.

/Rickard

Ett arkiv av data från flera olika källor sparat i en enhetlig databasstruktur på en plats.

Definition enligt mig :)

En databas som innehåller information från flera olika källor, konsoliderat till ett homogent format. Databasen är optimerad för läsning (OLAP) och uppdateras oftast i batch. Ofta används den för skapande av Data Marts, som resulterar i OLAP-kuber.

Informationen används ofta till uppföljning, Management Reporting etc.

/Kalle

Min definition: buzzword utan egentlig mening, skapat av personer utan fundamental kunskap om databasteori.

Åjo, teorier kring DW finns det allt. Sen kan jag hålla med om att det hypas en hel del. Dock får man väl se det som diverse leverantörers inlägg för att sälja mer. Läs CS så förstår du nog vad jag menar :-).

Sedan är det ju så att själva teorierna bakom att designa och bygga DW inte är alltför komplicerade och till största delen bygger på att denormalisera datat och bygga upp faktatabeller kopplat till olika dimensioner på olika sätt.

Att bygga verktygen som skall hantera miljontals records och Terrabyte data är definitivt inte trivialt.

Jag kan rekommendera en alldeles utomordentlig artikel i ämnet:
http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_dwdesign.asp?frame=true

B#

> Åjo, teorier kring DW finns det allt.

Jo, visst finns det teorier. Från de som inte riktigt förstått fundamental databasteori, specifikt relationsmodellen. Som frågeställaren ovan frågade, vad är definitionen av ett datawarehouse?

> Sen kan jag hålla med om att det hypas en hel del. Dock får man väl se det som diverse leverantörers inlägg för att sälja mer. Läs CS så förstår du nog vad jag menar :-).

Nej tack, CS håller jag mig gärna ifrån. Om det inte är Counterstrike då förstås. ;)

> Sedan är det ju så att själva teorierna bakom att designa och bygga DW inte är alltför komplicerade och till största delen bygger på att denormalisera datat och bygga upp faktatabeller kopplat till olika dimensioner på olika sätt.

Och där i ligger grundfelet. Vad är denormalisering? En riktig relationsdatabashanterare (och relationsmodellen i sig förstås) skulle klara av att besvara alla de frågor som de system som normalt benämns som datawarehouse används för, men den klarar också av att besvara alla andra typer av frågor för vilken typ av data som helst, något s k datawarehouse-produkter inte är i närheten av att göra.

För mig handlar det mest om att definiera vad databasen skall användas till... För nog måste du hålla med om att det går att optimera för olika saker?

Lösningar där det nästan enbart skall hämtas data, där är det ju lämpligt med denormalisering och tunga index. Däremot vid transaktionsintensiva lösningar är ju tunga index rena döden...

Nej, det håller jag inte med om. Till att börja med har denormalisering (vad det nu är för något, även det ordet saknar ju en exakt definition, till skillnad från normalisering) och normalisering ingenting med prestanda att göra. De är logiska begrepp, medan prestanda är ett fysiskt begrepp (dvs det påverkas endast av den fysiska implementationen). Man kan alltså inte denormalisera för att få bättre prestanda.

Om vi går vidare till optimering och databaser, så missar man den grundläggande orsaken till att man har ett databassystem och databaser (och specifikt ett baserat på relationsmodellen):

Att ha en centraliserad hantering av data, vilken ger en fördelarna att man undviker redundant och/eller inkonsistent data, man kan upprätthålla integritet, och att datan kan delas <b>mellan olika applikationer, nuvarande och framtida sådana</b>.

OK... Du svävar runt i teorins drömvärld... :)

Håller med om att det i teorin inte finns någon anledning att denormalisera (dvs bryta mot ex. 3NF för att få en prestandavinst). Men i praktiken finns det.

I verkligheten är olika databaser optimerade för olika uppgifter. Alla implementationer av relationsdatabaser som jag har sett kan optimeras för olika saker.

>OK... Du svävar runt i teorins drömvärld...

Typiskt dåligt argument tycker jag. Hade man i praktiken följt teaorin från början hade det inte funnits någon anledning att uppfinna ett buzzword som datawarehousing eller definiera vad det är. Det var ju från detta resonemang jag började med att säga att min definition av datawarehouse är att det är ett buzzword utan egentlig definition.

>Håller med om att det i teorin inte finns någon anledning att denormalisera (dvs bryta mot ex. 3NF för att få en prestandavinst). Men i praktiken finns det.

Återigen, nej, det gör det inte. Denormalisering är en logisk operation, däremot är SQL och de databashanterare som bygger på det felaktigt implementerade och skiljer inte tillräckligt mellan den logiska och fysiska nivån. Eftersom de inte följer reglerna om data independence (i brist på svenskt ord, dvs att skilja mellan logisk och fysisk implementation) så kan dock en förändring i den logiska nivån, en denormalisering i det här fallet, leda till en förbättring i den fysiska implementationen och därmed bättre prestanda. Observera dock att det inte är säkert att det gör det, andra faktorer som spelar in på prestanda kan påverkas negativt av det (I/O t ex) och därmed upphäva den ev prestandavinst det (felaktigt) genererade. Dessutom är den ev prestandavinsten precis som du själv säger fullständigt vinklad till en viss applikation och/eller användningsområde. Andra applikationer, nuvarande eller framtida, kan (och kommer nästan säkert) att påverkas negativt av förändringen.

I vilket fall som helst väljer man när man denormaliserar (och möjligen får viss prestandavinst på köpet) att bortse från de viktigaste funktionerna en databas erbjuder, nämligen <b>att undvika redundant och inkonsistent data samt upprätthållandet av integriteten i denna data</b>.

>I verkligheten är olika databaser optimerade för olika uppgifter. Alla implementationer av relationsdatabaser som jag har sett kan optimeras för olika saker.

Vilket som jag sagt flera gånger beror på att de inte är en bra implementation av relationsmodellen.

>Vilket som jag sagt flera gånger beror på att de inte är en bra implementation av relationsmodellen.

OK jag håller med dig om allt det du säger :)

Men "wake up and smell the coffee", det finns inga perfekta implentationer av relationsdatabaser, så vi får leva med vad vi har.

det är väll klart att en relationsmodell ska kunna hämta och visa data på alla tänkbara sätt..

men det är ju inte det det handlar om..

det handlar om optimering , man vill kunna hämta data på ett snabbt sätt.
sql server tex cachar ju frågor , och det är ju inte annorlunda med detta , se de denormaliserade tabellerna som en stor fet cache som går snabbt att hämta från..

det är ju rätt uppenbart att det går snabbare att läsa från en lookuptabell än att utföra en komplex fråga som läser från kanske 6 tabeller.


och :

<b>
I vilket fall som helst väljer man när man denormaliserar (och möjligen får viss prestandavinst på köpet) att bortse från de viktigaste funktionerna en databas erbjuder, nämligen att undvika redundant och inkonsistent data samt upprätthållandet av integriteten i denna data
</b>

är väll inte ett argument... i vissa fall kan det ju vara så att man får en sådan extrem prestandaökning att man kan acceptera att det data man tittar på är 15 timmar gamalt..

man kanske vill göra en analys som täcker flera år av data , och man kanske skiter fullständigt i om de sista 15 timmarna finns med i datat..



//Roger

>men det är ju inte det det handlar om..
>det handlar om optimering , man vill kunna hämta data på ett snabbt sätt.

Nej, det är inte alls vad det handlar om. Detta är vad det handlar om:

>>Funderar på hur ni definierar datawarehouse.

Jag bara försvarar/argumenterar för mitt svar att DW är ett buzzword och en (något odefinierad) teknologi för att behandla data på ett vis som man istället borde använt en korrekt implementerad relationsdatabas för att behandla. Alltså är det skapat av folk som inte förstår fundamental databasteori, för hade de gjort det hade de insett vilken dum lösning det är de försöker sälja. Samma sak gäller för XML, ODBMS, object-relational DBMS, multi-value databaser och alla andra buzzwords utan teoreisk grund och substans.

>sql server tex cachar ju frågor , och det är ju inte annorlunda med detta , se de denormaliserade tabellerna som en stor fet cache som går snabbt att hämta från..

Nej, det är absolut inte samma sak. En cache är en temporär kopia av något, en fysisk implementation vilken gör ett utmärkt jobb för att bättra prestandan i en databashanterare. Den har inget med logisk implementation att göra och den innebär inget som helst problem för dataintegritet. Tvärtom är det ett sätt hur de 'problem' som så ofta löses genom denormalisering kunde lösts. Databashanteraren skulle själv inse (alt. med lite hjälp av en DBA) att en cache av viss information skulle hjälpa vissa frågor och därför skapa den automagiskt. En denormaliserad tabell innebär att man släpper på kraven att upprätthålla dataintegriteten i en databas.

Det ska vara DBMS och dess fysiska implementation som ska se till att behandlingen av datan som lagrats i den ska få bra prestanda, inte användarna. Användarna å sin sida ska se till att designa sina databaser så att databashanteraren kan upprätthålla integriteten i databasen samt optimera databehandlingen utifrån de förutsättningar den anser vara gynnsammast.

så det är så det är alltså ?,
kan du inte berätta det för killarna på Oracle oxo , så de slipper slösa mer tid på sina olap grejjor...

det kan ju vara värt massor för dem...

//Roger

Vi kanske skulle definiera ordet buzzword också?

/B#

Nja, jag tror tyvärr inte de skulle lyssna så mycket på mig när de inte lyssnar på auktoriteter som C J Date, E F Codd eller Fabian Pascal. Och de slösar väl inte tid, folk betalar ju för det och då är väl de nöjda.

Visst vore det värt massor för dem ja om de skulle utveckla en riktig relationsdatabashanterare, då skulle jag definitivt direkt bytt från de jag använder idag, och jag tror nog många med mig hade gjort det. Men et skulle ju å andra sidan göra att de ser lite dumma ut, med tanke på att det isf är tydligt att de under en lång tid inte fattat vad det handlar om.

Fabian Pascal hade jag aldrig hört talas om innan, men det verkar ju vara en skärpt kille (liksom de andra två) :)

Då ska du få ett boktips här, en mycket bra och tänkvärd bok:

http://www.amazon.com/exec/obidos/tg/detail/-/0201485559/qid=1062399900/sr=8-1/ref=sr_8_1/002-8468600-4963236?v=glance&s=books&n=507846