2010 Eksamensopgave Databaser for udviklere Kasper Lorenzen 08-06-2010
Definition Følgende definition på et data warehouse( varehus ) formuleret af Bill Inmon taget fra wikipedia 1 er: Emneorienteret, hvilket vil sige at data i databasen er organiseret så alle elementer, der er knyttet til et bestemt objekt eller begivenhed i den virkelige verden skal være knyttet sammen i database house'et. Tidsafhængige, hvilket vil sige at data i database skal gemmes sammen med tidspunkt så man kan se hvordan data har ændret sig over tid. Uforanderlige, hvilket skal forstås sådan at data aldrig ændres eller slettes, men beholdes så de kan bruges i fremtidige rapporter; og, Integreret, hvilket betyder at data skal komme fra alle systemer organisationen bruger og at data skal være konsistente. Forskel på OLTP og Data warehousing Figur 1: forskel på OLTP og Data warehousing Som det kan ses på Figur 1, så er der en klar forskel på hvad de to systemer benyttes til. Dette giver også et tydeligt overblik over hvilke ting de benyttes til, og hvor krævende det er. Den største og mest markante forskel er at OLTP benyttes til operationer(hvilket oftest tolkes som daglig drift og beregninger), hvorimod at data warehouse benyttes til statistiske/analytiske formål. Dette medfører også næsten automatisk en del af de andre forskelle der er listet, som f.eks. data age, hvor OLTP er nutidig og data warehouse er historisk, 1 http://da.wikipedia.org/wiki/data_warehouse Kasper Lorenzen, DM08107 Side 1 af 7
men i forbindelse med at ERP og CRM systemer får vigtigere roller, bliver disse systemer også mere og mere en integreret del af data warehousing, hvilket også giver mulighed for næsten realtids analyser. Fordele - Potential high returns on investment - Competitive advantage - Increased productivity of corporate decision-makers - A data warehouse provides a common data model for all data of interest regardless of the data's source. This makes it easier to report and analyze information than it would be if multiple data models were used to retrieve information such as sales invoices, order receipts, general ledger charges, etc. - Prior to loading data into the data warehouse, inconsistencies are identified and resolved. This greatly simplifies reporting and analysis. - Information in the data warehouse is under the control of data warehouse users so that, even if the source system data is purged over time, the information in the warehouse can be stored safely for extended periods of time. - Because they are separate from operational systems, data warehouses provide retrieval of data without slowing down operational systems. - Data warehouses can work in conjunction with and, hence, enhance the value of operational business applications, notably customer relationship management (CRM) systems. - Data warehouses facilitate decision support system applications such as trend reports (e.g., the items with the most sales in a particular area within the last two years), exception reports, and reports that show actual performance versus goals. Som det kan ses, er de fleste fordele baseret på forretningsmuligheder, såsom mulighed for øget omsætning og bedre konkurrence muligheder. Dette skyldes at man får mulighed for at analysere på de data man har behandlet igennem historien. Et eksempel der er nemt at forstå kan være en almindelig netbutik. Mange netbutikker har mulighed for at vise hvad andre brugere har købt sammen med en vare. Disse oplysninger over flere år, vil kunne medføre en stor værdi, da man vil kunne lave forespørgsler på alder, køn, geografi osv. Dette er også med til at øge funktionaliteten i CRM og ERP systemer, da disse systemer direkte er baseret på tidligere hændelser. Ulemper/Problemer - Underestimation of resources for data loading - Hidden problems with source systems - Required data not captured - Increased end-user demands - Data homogenization - High demand for resources - Data ownership - High maintenance - Long duration projects - Complexity of integration - Data warehouses are not the optimal environment for unstructured data. Kasper Lorenzen, DM08107 Side 2 af 7
- Because data must be extracted, transformed and loaded into the warehouse, there is an element of latency in data warehouse data. - Over their life, data warehouses can have high costs. - Data warehouses can get outdated relatively quickly. There is a cost of delivering suboptimal information to the organisation. - There is often a fine line between data warehouses and operational systems. Duplicate, expensive functionality may be developed. Or, functionality may be developed in the data warehouse that, in retrospect, should have been developed in the operational systems. Som det ses ovenfor er det langt fra problemfrit at ville have et data warehouse. Nogle af de største problemer ved dette er kompleksiteten og datamængden. Det skal derfor overvejes grundigt før man vælger at implementere et varehus, da det også tager flere år før man har noget der reelt er brugbart(dette kan variere alt efter mængden af data og hvordan det skal bruges). Arkitektur Som det kan ses på Figur 2 består et data warehouse af en forskellige ting. Data sources er blandt andet de databaser som bliver brugt i forbindelse med daglig drift. Dette dog også være div. filer såsom.xml,.cvs eller lign. Operational Data: Dette er kilden hvorfra dataene tilgår varehuset. Figur 2: arkitektur over data warehouse Dette kan for eksempel være Excel og CSV filer, relationelle databaser, system logs og andre former for data der kan benyttes til analytiske formål. Kasper Lorenzen, DM08107 Side 3 af 7
Operational Data Store: Denne komponent kaldes også for staging area, fordi at her samles data og klargøres inden det bliver flyttet over varehuset. Load manager(front end component): Denne komponent står for at udfører alle operationer i forbindelse med extraction og load i varehuset. Warehouse manager: Denne komponent holder styr på selve varehuset, og dette gøres ved forskellige operationer. Eksempler på disse operationer kan være: - At danne index og views på base tables - At lave back-up og arkivere data Query manager(back-end component): Denne komponent står for at holde styr på de kald der kommer fra brugerne af varehuset. Dette foregår ofte ved at benytte specielt designede database værktøjer, monitorerings systemer o.lign. Detailed data: Her bliver den rå data/stamdata gemt. Dette vil næsten aldrig blive brugt direkte, men aggregeret til næste trin af detaljering. Summarized data(aggregeret data): Her vil dataene der benyttes befinde sig. Årsagen til at det er dette område der bliver benyttet til div. kald fra end-user, skyldes at det er billigere at lave kald på allerede grupperede/sorterede data. Det koster dog flere ressourcer at initialisere varehuset, men dette vil hurtigt hente sig ind under driften. Da dataene som sagt ligger aggregeret medfører det at dataene der ligger i dette område vil skulle opdateres løbende da eftersom der tilføres flere data. Archive/Back-up data: Her ligger der både detaljeret data, og aggregeret data i forbindelse med arkivering og back-up. Metadata: Data om data. - To map data sources to a common view of information within the warehouse. - To automate the production of summary tables. - To direct a query to the most appropriate data source. Data flow Inflow: Kasper Lorenzen, DM08107 Side 4 af 7
Dette er data flowet fra operational data til varehuset. Det er her data bliver ordnet så det er klar til at komme i varehuset, ved at fjerne dårlig data, omstrukturere og måske denormalisere. Med dårlig data menes evt. fejl data som ikke har nogen direkte betydning på den daglige operation i organisationen, men som kan medfører fejl/misvisning i varehuset. Upflow: Dette er det flow der er fra detailed data til summarized data. Det er her der aggregeres på den rå data, og dette kan medfører at forskellige visninger bliver muliggjort i f.eks. grafer. Det er også her at data bliver flyttet rundt for at kunne udfører de forskellige kald udefra. Downflow: Dette er flowet fra varehuset og ned til arkiv/back-up systemet. Metaflow: Her bliver det metadata der ligger omkring de andre flows flyttet rundt i forbindelse med alle de andre flytninger der sker. Dette skal løbende opdateres ved ændringer. Outflow: Her bliver data tilgængeligt for end-users. Data Marts Årsager til at oprette data marts: - To give users access to the data they need to analyze most often. - To provide data in a form that matches the collective view of the data by a group of users in a department or business application area. - To improve end-user response time due to the reduction in the volume of data to be accessed. - To provide appropriately structured data as dictated by the requirements of the end-user access tools. - Building a data mart is simpler compared with establishing an enterprise-wide DW (EDW). - The cost of implementing data marts is normally less than that required to establish a EDW. - The future users of a data mart are more easily defined and targeted to obtain support for a data mart than an enterprise-wide data warehouse project. Data marts giver hurtigere og nemmere adgang til data, frem for et varehus. Rå data bliver beholdt tilbage i varehuset, og derved ligger der kun det data der skal bruges, hvilket kan give lidt det indtryk af at data marts kan sammenlignes lidt med en stand der står ude foran varehuset. Design Dimensionality modelling: Kasper Lorenzen, DM08107 Side 5 af 7
Dimensionality modellering består af nogle grundkoncepter: - A logical design technique that aims to present the data in a standard, intuitive form that allows for high-performance access - Every dimensional model (DM) is composed of one table with a composite primary key, called the fact table, and a set of smaller tables called dimension tables. - Each dimension table has a simple (non-composite) primary key that corresponds exactly to one of the components of the composite key in the fact table. - All natural keys are replaced with surrogate keys. Means that every join between fact and dimension tables is based on surrogate keys, not natural keys. - Surrogate keys allows the data in the warehouse to have some independence from the data used and produced by the OLTP systems. Schemas: Nedenfor er et star schema. Det er opbygget ved at have en fact tabel i midten, der så har dimension tabeller tilknyttet. Figur 3: star schema Et snowflake schema minder om et star schema, men forskellen er som man kan se på Figur 4, at dimension tabellerne normaliseres. Kasper Lorenzen, DM08107 Side 6 af 7
Figur 4: snowflake schema Der er et 3. mønster kaldet starflake, hvilket består af en kombination af star og snowflake schema. Kasper Lorenzen, DM08107 Side 7 af 7