Schemamigratie:Relationeel naar Star

Opmerking:dit artikel toont de migratie van een relationeel database-model (RDB) naar een sterschema met behulp van de Eclipse IDE voor Voracity (en de bijbehorende producten), IRI Workbench, na een inleiding tot beide architecturen. Als u geïnteresseerd bent in het migreren van uw RDB of gegevens naar een Data Vault 2.0-model, wordt er in mei 2019 een nieuwe Workbench-wizard geïntroduceerd in het World Wide Data Vault Consortium; abonneer je op de IRI-blog om die stapsgewijze instructies te krijgen zodra ze worden gepubliceerd!

Een datawarehouse (DW) is een verzameling gegevens die zijn geëxtraheerd uit het operationele of transactionele systeem in een bedrijf, getransformeerd om inconsistenties op te ruimen en vervolgens gerangschikt om snelle analyse en/of rapportage te ondersteunen. De DW vereist een schema, of een logische beschrijving en grafische weergave van de operationele database. Dit artikel behandelt deze onderwerpen en biedt een handleiding voor het overstappen van een conventioneel relationeel databaseschema naar een populair DW-schema met de naam star schema.

Sterschema versus relationeel

De meeste relationele datastructuren worden geïllustreerd in entiteit-relatiediagrammen (ER). Een ER-diagram wordt gebruikt bij de ontwikkeling van conceptuele modellen voor een databasebeheersysteem voor online transactieverwerking (OLTP). Het is de bron waaruit de tabelstructuur is vertaald.

Het sterschema is echter de algemeen aanvaarde standaard voor de onderliggende tabelstructuur van een datawarehouse. De eenvoudige stervorm (wanneer ER-diagram is weergegeven) toont de feitentabel (met transactiewaarden of metingen) in het midden en dimensietabellen (met beschrijvende of attributieve waarden) die eruit voortkomen. Gewoonlijk heeft de feitentabel de vorm van de derde normaal (3NF), terwijl dimensionale tabellen gedenormaliseerd zijn.

De basisverschillen tussen een entiteit-relationeel (ER) model en een stermodel zijn:

1. ER-modellen gebruiken logische en fysieke structuren voor genormaliseerd databaseontwerp
2. Dimensiemodellen gebruiken een fysieke structuur voor  gedenormaliseerd databaseontwerp

Klik hier om te zien hoe IRI-software gegevens kan de-/normaliseren door het draaien van rijen en kolommen.

Achtergrond conversieproces

In dit artikel laat ik zien hoe u gegevens van een relationeel model naar een ster kunt converteren met behulp van taken die u min of meer handmatig moet definiëren, maar die u automatisch kunt maken en uitvoeren, en eenvoudig kunt wijzigen.

Wat u hier ziet, zijn de 4GL-gegevens en taakspecificaties van IRI — uitgedrukt in "SortCL"-scripts[1] — die gegevens in dimensietabellen toewijzen en gegevens samenvoegen in de centrale feitentabel. SortCL is het kernprogramma voor gegevensmanipulatie en -toewijzing in het IRI Voracity-gegevensbeheer en ETL-platform. Het begrijpen van de methodologie en toewijzingen in mijn SortCL-taken is hier echter de sleutel, niet de scriptsyntaxis.

De gratis Eclipse GUI, IRI Workbench, biedt een syntaxisbewuste SortCL-editor, evenals grafische contouren en dialogen, workflow- en toewijzingsdiagrammen en intuïtieve taakwizards om deze scripts automatisch te bouwen of aan te passen als u dat niet wilt. met de hand. Ter informatie:IRI gebruikt dezelfde metadata en GUI voor het profileren en diagrammen van DB's, het genereren van testgegevens, het uitvoeren van ETL, het opmaken van rapporten, het maskeren van PII, het vastleggen van gewijzigde gegevens, het migreren en repliceren van gegevens, het opschonen en valideren van gegevens, enz.

Workbench gebruikt een verbeterde versie van de Data Tools Platform (DTP) plug-in voor Eclipse om verbinding te maken met databases via JDBC en om SQL-bewerkingen en IRI-metadata-uitwisseling in de Data Source Explorer (DSE)-weergave mogelijk te maken. In dit geval ondersteunt de Workbench:

1. het maken en vullen van beperkte Oracle-testtabellen (brontabellen) via SortCL (of IRI RowGen taken, volgens dit artikel)
2. het toewijzen van entiteitstabelgegevens aan dimensietabellen via SortCL
3. het in kaart brengen van feitenelementen als een n-aire relatie om de principiële dimensietabel te associëren; d.w.z. het uitvoeren van een multi-table join in SortCL om de Fact-tabel te maken
4. populatie van alle doeltabellen (star schema)
5. ER-diagrammen van de bron- en doelschema's

De entiteitstypen in mijn oorspronkelijke relationele model zijn:Dept, Emp, Project, Category, Item, Item_Use en Sale:

Voor …

Het volgende diagram toont het uiteindelijke Star-model met acht dimensietabellen en één feitentabel. De dimensietabellen zijn:Dept_Dim, Emp_Dim, Emp_Salary_Range_Dim, Project_Dim, Category_Dim, Item_Price_Range_Dim, Item_Dim. De feitentabel in het midden is Sale_Fact, die sleutels bevat voor alle dimensietabellen.

… Na

Conversiestappen

1. Definieer en maak de feitentabel
   De structuur voor de Sale_Fact-tabel wordt in dit document weergegeven. De primaire sleutel is sale_id en de rest van de attributen zijn externe sleutels die zijn overgenomen van de dimensietabellen. Ik gebruik een Oracle-database (hoewel elke RDB werkt) die is verbonden met de Workbench DSE (via JDBC) en SortCL voor gegevenstransformatie en -toewijzing ( via ODBC). Ik heb mijn tabellen gemaakt in SQL-scripts die zijn bewerkt in het SQL-plakboek van DSE en uitgevoerd in de Workbench.

2. Definieer en maak de dimensietabellen
   Gebruik dezelfde techniek en metadata die hierboven zijn gekoppeld om deze dimensietabellen te maken die de relationele gegevens zullen ontvangen die in de volgende stap zijn toegewezen aan SortCL-taken:Category_Dim table, Dept to Dept_Dim, Project to Project_Dim, Item to Item_Dim en Emp to Emp_Dim. U kunt dat .SQL-programma met alle CREATE-logica tegelijk uitvoeren om de tabellen te bouwen.

3. Verplaats de originele entiteitstabelgegevens naar de dimensietabellen
   Definieer en voer de SortCL-taken uit die hier worden weergegeven om de (door RowGen gemaakte test) gegevens van het relationele schema toe te wijzen aan dimensietabellen voor het Star-schema. Deze scripts laden met name gegevens uit de tabel Categorie naar de tabel Categorie_Dim, Dept naar Dept_Dim, Project naar Project_Dim, Item naar Item_Dim en Emp naar Emp_Dim.

4. Vul de feitentabel in
   Gebruik SortCL om gegevens uit de originele Sale-, Emp-, Project-, Item_Use-, Item-, Category-entiteitstabellen samen te voegen om gegevens voor te bereiden voor de nieuwe Sale_Fact-tabel. Gebruik hier het tweede (join job) script.

Om ons voorbeeld te verbeteren, zullen we ook SortCL gebruiken om nieuwe dimensionale gegevens in het Star-schema te introduceren waarop mijn Fact-tabel ook zal vertrouwen. U kunt deze extra tabellen in het bovenstaande sterdiagram zien die niet in mijn relationele schema stonden:Emp_Salary_Range_Dim en Item_Price_Range_Dim. Die tabellen worden gemaakt in hetzelfde .SQL-bestand voor de Fact- en andere dimensietabellen.

De Fact-tabel heeft de emp_salary_range_id en item_price_range_id-gegevens uit deze tabellen nodig om het waardenbereik in die dimensietabellen weer te geven. Wanneer ik bijvoorbeeld de dimensionale prijswaarden in het datawarehouse laad, wil ik ze toewijzen aan een prijsbereik:

De eenvoudigste manier om bereik-ID's toe te wijzen in het taakscript (dat is het voorbereiden van gegevens voor mijn Sale_Fact-tabel) is door een IF-THEN-ELSE-instructie te gebruiken in het uitvoergedeelte. Zie dit artikel over bucketing-waarden voor achtergrond.

Hoe dan ook, ik heb deze hele baan gemaakt met de CoSort Nieuwe Join Job wizard in de Workbench. En toen ik het eenmaal had uitgevoerd, was mijn feitentabel gevuld:

Sale_Fact-tabelweergave in de IRI Workbench DSE

Conclusie

Het grote voordeel van dimensionale gegevensrepresentatie is het verminderen van de complexiteit van een databasestructuur. Dit maakt het voor mensen gemakkelijker om de database te begrijpen en er query's op te schrijven door het aantal tabellen en dus het aantal benodigde joins te minimaliseren. Zoals eerder vermeld, optimaliseren dimensionale modellen ook de queryprestaties. Het heeft echter zowel zwakte als kracht. De vaste structuur van het Star Schema beperkt de queries. Dus omdat het de meest voorkomende zoekopdrachten gemakkelijk maakt om te schrijven, beperkt het ook de manier waarop de gegevens kunnen worden geanalyseerd.

De IRI Workbench GUI voor Voracity heeft een krachtige en uitgebreide set tools die data-integratie vereenvoudigen, inclusief het maken, onderhouden en uitbreiden van datawarehouses. Met deze intuïtieve, gebruiksvriendelijke interface maakt Voracity snelle, flexibele end-to-end ETL-processen (extract, transform, load) mogelijk waarbij gegevensstructuren op verschillende platforms betrokken zijn.

Bij ETL-bewerkingen worden gegevens uit verschillende bronnen gehaald, afzonderlijk getransformeerd en in een datawarehouse en mogelijk andere doelen geladen. Het bouwen van het ETL-proces is in potentie een van de grootste taken bij het bouwen van een magazijn; het is complex en tijdrovend. De ETL-aanpak van IRI ondersteunt dit proces op een zeer efficiënte en database-onafhankelijke manier, door alle gegevensintegratie en fasering in het bestandssysteem uit te voeren.

[1] Als u een syntaxishond bent, houd er dan rekening mee dat SortCL-scripts die in het IRI CoSort-product of IRI Voracity-platform worden gebruikt dezelfde syntaxis en gegevensdefinities ondersteunen als IRI RowGen voor het genereren van testgegevens, IRI NextForm voor gegevensmigratie en IRI FieldShield voor gegevensmaskering. Al deze tools worden allemaal ondersteund in de IRI Workbench GUI, en hun metadata kunnen ook worden gedeeld en door teams worden beheerd voor versiebeheer, taak-/gegevensafstamming en beveiliging in de cloud.

[2] E-R-diagrammen weergeven in IRI Workbench:

1. Selecteer Nieuw IRI-project en maak een nieuwe map
2. Selecteer die map en markeer alle toepasselijke databasetabellen in de Gegevensbronverkenner; klik vervolgens met de rechtermuisknop op IRI, Nieuw ER-diagram
3. Er wordt een bestand (Schema.QA) gemaakt
4. Klik met de rechtermuisknop op dat bestand en selecteer Nieuwe weergave, Nieuw entiteitsrelatiediagram.

[3] De elementen van het ER-diagram die dergelijke modellen illustreren, zijn onder meer:

1. gedefinieerde entiteitstypes
2. gedefinieerde attributen
3. de relatie tussen de entiteitstypen
4. algemeen beeld of conceptueel diagram

[4] IRI FACT en SQL*Loader zijn respectievelijk bulkextractie- en laadopties.