BI betyder Business Intelligence. Det finns ingen bra svensk översättning. Närmast kommer nog ordet beslutsstöd.
DW betyder Data Warehouse. På svenska brukar det kallas för datalager, men många använder den engelska termen.
Innan informationsålderns start i det sena 1900-talet kunde företag ej använda automatik för att förstå sin verksamhet. Man också saknade ofta resurser att sammanställa och analysera tillgänglig information, vilket innebar att affärsbeslut huvudsakligen grundade sig på intuition.
I och med att man började att automatisera olika system blev mer data tillgängligt. Men sammanställningen och analysen förblev länge en utmaning eftersom det saknades metoder och infrastruktur, samtidigt som systemen ofta var inkompatibla. Det kunde ta månader att sammanställa och analysera viktig information. Det innebar att den endast kunde användas för långsiktiga strategiska beslut, medan kortsiktiga taktiska beslut fortfarande fortfarande måste baseras på intuition.
Detta ledde fram till behovet av Business Intelligence. En term och definition som myntades redan i oktober 1958 när Hans Peter Luhn skrev en artikel i IBM Journal som hette A Business Intelligence System.
Enligt honom är en verksamhet (business) en samling av aktiviteter för något speciellt syfte, som tex kan vara vinstsyfte, forskning, regering, rätt, militär etc. Intelligens (intelligence) definieras som möjligheten att förstå förhållanden mellan framlagda fakta på ett sådant sätt att det kan vägleda handlingar i avsikt att uppnå ett önskat mål (the ability to apprehend the interrelationships of presented facts in such a way as to guide action towards a desired goal). Han menar att ett system som tillhandahåller en sådan tjänst kan kallas för ett Business Intelligence System.
Sedan dess har utvecklingen medfört att datamängderna formligen har exploderat, vilket skapat behovet av datalager vars syfte är att sammanställa och presentera datamängderna på ett effektivt sätt.
Business Intelligence har idag (2007) förvandlats till konsten att vada genom stora datamängder för att hitta betydelsefull information som kan omvandlas till underlag till att fatta beslut.
För att klara det behöver man inte bara ett datalager, utan också verktyg, modeller, arkitektur, teknologier och metoder anpassade för ändamålet.
källa: en.wikipedia.org/wiki/Business_Intelligence
Data Warehouse brukar översättas med datalager till svenska, men många använder den engelska termen. Enligt definitionen är företagets datalager lagringsplatsen för all historisk information, råmaterialet för företagets beslutsstöd. I praktiken kan man inte samla in all historisk information, men det är åtminstone ett riktmärke.
En nyckel till datalagrets framgång är att analytiker eller beslutsfattare kan ställa komplexa frågor och analyser, utan att riskera att företagets operativa system störs. Eftersom ett datalager kan bli väldigt stort, kräver det enorma krav på systemets prestanda och skalbarhet.
Det innebär att det är vanligt med dataförråd (data mart), som är en delmängd av datalagret speciellt fokuserat på en viss typ av frågor eller analyser. Nackdelen är att datat dubbleras, och därmed ta större plats och längre tid att ladda samtidigt som det finns risk att det finns olika versioner av samma data.
Dagens synsätt är något som växt fram under lång tid av många goda tänkare. Ofta kallas Bill Inmon för datalagrets pappa, men innan honom fanns det flera framträdande namn.
Redan på 1960-talet utvecklades termerna dimensioner och fakta i ett gemensamt forskningsprojekt mellan matproducenten General Mills med Dartmouth College.
Sperry Univac lanserade 1975 sin MAPPER (MAintain, Prepare, and Produce Executive Reports), ett databas- och rapportsystem med världens första 4GL. Det är den första plattformen gjord för att bygga Information Centers (föregångare till dagens Data Warehouse).
En annan inflytelserik person är författaren James Martin. Han har skrivit hundratals böcker och kallas ibland 'informationsålderns guru'. Mest känd är han för boken The Wired Society: A Challenge for Tomorrow, som han skrev redan 1977 och som stödde framväxten av beslutsstöd.
Teradata levererade 1983 världens första massivt parallella databasplattform till Wells Fargo, specifikt konstruerad för beslutsstöd.
Forskare som Martyn Richard Jones, Philip Newman, Joseph Bielawski, Bob Richards, Thaluber mfl på Sperry Corporation publicerade 1985 en artikel om Information Centers, där de bla använder termen MAPPER Data Warehouse.
Barry Devlin och Paul Murphy på IBM publicerade 1988 en artikel med konceptet "business data warehouse", vilket innebär en modellarkitektur för flödet av data från operativa källsystem till system för beslutsstöd.
Men det är ändå Bill Inmon som har varit mest framträdande inom datalager. Han började definiera och diskutera begreppet Data Warehouse redan på sjuttiotalet, och han har skrivit många artiklar och hållit många kurser om datalager. 1992 publicerade han den första boken om datalager "Building the Data Warehouse", och han höll den första konferensen om datalager tillsammans med Arnie Barnett. Senare idéer från honom är begreppet "DW 2.0", om nästa generation datalager, och CIF, Corporate Information Factory, som beskriver en större informationsarkitektur vari datalagret ryms.
Sedan nittiotalet har dock Ralph Kimball blivit ett minst lika välkänt namn inom datalager med sin bok The Data Warehouse Lifecycle Toolkit från 1996 och med dess senare efterföljare. Hans viktigaste bidrag är att datalagret skall använda en dimensionell modell och att dimensionerna skall vara samordnade.
Inmon anser att datalagret skall vara normaliserat (enligt den tredje normalformen) och inte dimensionellt. Användarna skall sedan ställa frågor och analyser mot mindre dimensionella dataförråd eller semantiska lager istället för mot det stora normaliserade datalagret. Däremot behöver ej dimensionerna vara samordnade i de olika dataförråden. Inmon förespråkar också ett 'top-down' synsätt vid byggandet av datalagret.
Kimball menar istället att hela datalagret skall vara dimensionellt, tillsammans med eventuella dataförråd. Dataförråden är inte lika viktiga med detta synsätt, och kan undvikas helt om svarstiderna i datalagret är tillräckligt bra. Däremot är det viktigt att de dimensioner som används i datalagret skall vara samordnade (conformed).
Med samordnade dimensioner menas att 'intressanta' dimensioner (tex produkter) använder samma attribut och samma summeringar i olika dataförråd. På detta sätt kan ett datalager byggas baserat på mindre dataförråd. Själva kärnan i Kimball's angreppssätt är att datalagret innehåller samordnade dimensionella databaser redo för analys och att användaren kan fråga datalagret direkt. Kimball tycker alltså att en 'bottom-up' synsätt bör användas vid byggandet.
I ett tillräckligt stort datalager är det idag praxis att data lagras normaliserat eftersom det tar mycket mindre plats än dimensionella data. Däremot erbjuds datat till användarna i en dimensionell form i ett semantiskt lager, eftersom den formen är lättare att förstå och använda för dem.
källa: en.wikipedia.org/wiki/Data_warehouse mfl
Både Inmons och Kimballs modeller medför dock en stelhet i arkitekturen, vilket innebär att det tar lång tid att bygga ett datalager från grunden, och att det ofta är besvärligt och tidsödande att anpassa dem efter nya behov.
För att råda bot på detta publicerade Dan Linstedt år 2000 ett nytt modelleringskoncept kallat Data Vault. syftet är att erbjuda långsiktig historisk datalagring från skiftande källsystem med full flexibilitet och spårning av data oberoende av eventuella ändringar i och från källsystemen.
En annan skillnad är att Data Vault inte skiljer på bra eller dåliga data. Alla data sparas oberoende av kvalitet. I ett klassiskt datalager blir data som inte passar antingen tvättat eller raderat. Detta medför också att det blir enklare att tillgodose krav från Sarbanes-Oxley Act och liknande lagar om dataspårning.
Data Vault löser problemet med ändringar av datastrukturen genom att separera på källsystemens affärsnycklar (business keys), relationerna mellan dem och deras beskrivande attribut. Tanken är att affärsnycklarna (dvs källsystemens faktiska nycklar) sällan eller aldrig ändras, däremot kommer relationerna och attributen att ändras ibland.
Affärsnycklarna lagras för sig i en typ av tabell som kallas Hub, tillsammans med radens surrogatnyckel, en referens till källsystemet samt till operativ metadata (dvs när och hur laddningen av raden gjordes). Notera att affärsnycklen kan vara mer än ett fält.
Attributen som beskriver affärsnycklarnas data lagras i en typ av tabell som kallas Satellit. Det kan finnas mellan en och flera satelliter till en Hub beroende på datastrukturen. Exempelvis kan adressdata lagras i en satellit medan demografiska data lagras i en annan. Här finns möjlighet att använda lagra flera versioner av samma attribut.
Relationerna mellan affärsnycklarna lagras i en typ av tabell som kallas Link. På samma sätt bör bara relationens nyckel sparas i Link-tabellen. Relationens attribut sparas i en satellit, på samma sätt som för en Hub.
En fjärde typ av tabell är Referens, dvs lookup-tabeller med i stort sett fasta referensvärden.
För att underlätta användningen är det sedan normalt att modellen konverteras till en dimensionell modell i ett dataförråd eller semantiskt lager. Link-tabeller med sina satelliter bildar normalt fakta, medan Hub-tabellerna med sina satelliter blir dimensioner.
Enkelt Data Vault exempel med 2 Hubs (blå), 1 Link (grön) och 4 Satelliter (gula).
Data Vault 2.0 lanserades 2013 och inkluderar domäner såsom Big Data, NoSQL, semistrukturerad integration, tillsammans med metodologi, arkitektur och implementationsråd.
källa: en.wikipedia.org/wiki/Data_Vault_modeling
Bill Inmon definierade ett datalager på följande sätt:
Ett datalager består normalt av följande delar:
En semantiskt lager eller ett dataförråd består av dimensioner och fakta, vilket har en viss granularitet.
En dimension är något som beskriver ett verksamhetsobjekt eller en händelse. Dimensionens namn är normalt ett substantiv. Dimensionen innehåller attribut som beskriver varje medlem i dimensionen.
Fakta är något som mäter en verksamhetsprocess. Dessa mått är normalt numeriska. De kan ofta summeras, men inte alltid. Det betyder inte att alla numeriska värden är fakta, exempelvis produktstorlek är snarare ett attribut i en dimension som beskriver produkten. Faktaraderna är kopplade till de dimensioner som behövs för att beskriva processen. Även händelser kan ses som fakta, vilket kan lagras i en s.k. faktalös faktatabell.
Granulariteten är på vilken nivå som faktat lagras. Det blir datalagrets atomära nivå. Rekommendationen är att alltid använda en fin granularitet som möjligt. Alla fakta i en faktatabell måste ha samma granularitet för att kunna summeras.
Ralph Kimball identifierade problemet med skorstensröret (stove pipe). Ett skorstensrör är vad du får när flera olika oberoende system i företaget identifierar och lagrar sina data på olika sätt. Om man försöker koppla ihop dessa system eller använda dessa data direkt i ett datalager får man en onödigt komplicerad lösning.
För att lösa problemet föreslår Kimball att man använder samordnade (conformed) dimensioner. Med samordning menas att 'intressanta' dimensioner (tex produkter) använder samma attribut och samma summeringar i olika dataförråd. Vilket medför att olika dataförråd kan kopplas samman vid behov.
Ett datamodell i form av en snöflinga innebär att dimensionerna är normaliserade. För att beskriva en medlem i en dimension krävs alltså att databasen söker upp medlemmens attribut i ett flertal underliggande dimensionstabeller.
Ett datamodell i form av en stjärna innebär att dimensionerna är helt dimensionella. Det innebär att attributen dubbellagras i dimensionerna, vilket kräver större plats men gör att svarstiden minskar eftersom sökningar undviks. Däremot är faktatabellen fortfarande normaliserad gentemot dimensionerna.En surrogatnyckel är en primärnyckel i en databastabell som inte innehåller någon information. Dess enda syfte är att vara unik. I ett datalager bör man använda surrogatnycklar i alla dimensionstabeller. Om man använder nycklar från underliggande affärssystem bygger man in ett farligt beroende i datalagret, vilket inte har några fördelar alls.
I en datalager är det normalt att vissa dimensioner ändras långsamt. Ibland är det ointressant att spåra ändringarna. Det kan vara kundens hemtelefonnummer som ändrats, och det kan vara helt ointressant att hålla reda på. Då skrivs attributet helt sonika över. Det kallas för en typ 1-ändring.
I andra fall kan det exempelvis vara en kund som flyttar, och då behöver attributet för adress i dimensionen för kunder ändras. Dessa ändringar kan ha betydelse för analysen och då behöver de kunna spåras. Det kan man göra med hjälp av extra kolumner i dimensionen som visar radens aktuella status. Det kallas för en typ 2-ändring.
Teoretiskt finns det även något som kallas för en typ 3-ändring. Det innebär att man helt enkelt lägger till nya attribut, dvs kolumner, för varje ändrat attribut. Det är dock ingen långsiktigt bra lösning och används knappast aldrig i praktiken.
Sidan skapad 10 maj 2007
Uppdaterat 20 januari 2009 (Mer om OLAP)
Uppdaterat 28 augusti 2011 (Semantiskt lager)
Uppdaterat 29 augusti 2014 (Om prestanda)
Uppdaterat 10 oktober 2017 (Mer historik)
Uppdaterat 18 mars 2020 (Data Vault)
Sammanställt av Christer Tärning.