Klik voor meer informatie over auteur Thomas Frisendal.
Dit is een goed moment om te kijken naar best practices in databaseontwerp voor SQL-databases. Zijn er dingen die gemakkelijker hadden kunnen worden gedaan als de SQL-ontwerpers een absolute vooruitziende blik hadden gehad? Het antwoord is natuurlijk ja. Maar het belangrijkste is wat echt een groot verschil had kunnen maken.
De evolutie van SQL – op welke eigenschappen wachten we?
Over het algemeen is de SQL-standaard gegroeid door veel problemen te omarmen die zich in de loop der jaren hebben voorgedaan. Ik noem alleen XML, tijddatatypes en multidimensionaal als voorbeelden van nuttige aanpassingen. Voor “brood en boter” -databases werkt SQL over het algemeen prima, maar er zijn enkele dingen die de moeite waard zijn om te bespreken:
- De behoefte voor surrogaatsleutels evenals de complexiteit van het omgaan met aaneengeschakelde (zakelijke) sleutels geven aan dat de concepten van sleutels en het bereik van dergelijke sleutels mogelijk een make-over nodig hebben
- De omvang van de sleutels is ook een discussie waard – in de grafiekruimte zijn mensen best tevreden met het RDF-concept van IRI’s (Internalized Resource Identifiers). IRI’s worden veel gebruikt, met een globaal bereik. In de SQL-communities worden GUID’s voor vergelijkbare doeleinden gebruikt
- (Buitenlandse) belangrijkste relaties zou een sterkere rol kunnen spelen in het SQL-paradigma – eigenlijk zijn het niet de relaties tussen sleutels, maar de relaties tussen typen bedrijfsobjecten die er toe doen
- Dit raakt de zaken van normalisatie
(en gecontroleerde denormalisatie), die in hoge mate deel uitmaken van best practices in het ontwerpen van SQL-databases
Tussen de vier verschillende probleemgroepen die hierboven zijn genoemd, is er één gemeenschappelijke noemer: tijdelijkheid. Dit zou ook in meer alledaagse termen kunnen worden omschreven als ‘correct omgaan met gegevens in de loop van de tijd’ – gericht op zakelijke behoeften die we hebben geprobeerd op te lossen door middel van datawarehouses en datameren in veeleisende, gegevensintensieve sectoren zoals de overheid, farmaceutica, technologie en wetenschap.
Datakluizen en ankermodellen – Ensemble
Veel zware databases in veeleisende industrieën hebben hun weg gevonden naar twee enigszins verwante modellering benaderingen:
- Modellering van gegevenskluis: Oorspronkelijk ontwikkeld door Dan Linstedt voor de Amerikaanse defensie
- Anker modellering: Open source-project afkomstig uit Zweden, door Lars Rönnbäck
Tegenwoordig presenteren de twee gemeenschappen (meer dan 5000 DV-modelbouwers) en een 3-cijferig aantal ankermodelmakers (voornamelijk in Zweden en Nederland) zichzelf als onderdeel van het “Ensemble – Modelling voor het moderne datawarehouse”.
De belangrijkste motivatie om databases op deze manieren te modelleren, kan in drie woorden worden samengevat:
- Schaalbaarheid (petabyte-niveaus)
- Tijdelijkheid (uni-, bi- en meer)
- Veerkracht (ten opzichte van structurele en terminologische veranderingen)
Anker modellering
Ik zal me concentreren op het modelleren van gegevenskluizen, maar voordat ik dat doe – enkele opmerkingen over ankermodellering:
- Anchor-modellering heeft een goede website als referentie
- Er is een gratis online modelleertool hier
- U kunt online training krijgen hier
Anchor-modellering is beschreven door Lars Rönnbäck vindt dit leuk:
“Ankermodellering is een open source-databasemodelleringstechniek die is gebaseerd op het uitgangspunt dat de omgeving rond een datawarehouse voortdurend verandert. Een grote verandering aan de buitenkant van het model zal resulteren in een kleine verandering aan de binnenkant. De techniek omvat de natuurlijke concepten van objecten, attributen en relaties, waardoor het gemakkelijk te gebruiken en te begrijpen is. Het is gebaseerd op de zesde normaalvorm, wat resulteert in een sterk afgebroken implementatie, die veel van de valkuilen vermijdt die gepaard gaan met traditionele databasemodellering. Dankzij het modulaire karakter ondersteunt de techniek het scheiden van zorgen en vereenvoudigt het projectscoping. Je kunt klein beginnen met prototyping en later uitgroeien tot een enterprise datawarehouse zonder dat je je eerdere werk opnieuw hoeft uit te voeren. “
“Hoewel de oorsprong ligt bij de eisen die aan datawarehousing worden gesteld, is het een generieke modelleringsaanpak, ook geschikt voor andere typen systemen. Elke wijziging wordt geïmplementeerd als een onafhankelijke niet-destructieve uitbreiding in het bestaande model. Hierdoor blijven alle huidige applicaties onaangetast. Veranderingen in de invoer naar en uitvoer van de database kunnen daardoor asynchroon worden afgehandeld, en alle versies van een applicatie kunnen worden uitgevoerd tegen dezelfde evoluerende database. Elke eerdere versie van het databasemodel bestaat nog steeds als een subset binnen een ankermodel. “
Modellering van gegevenskluis: een kort overzicht
Hoewel bij het modelleren van gegevenskluizen een andere terminologie wordt gebruikt en verschillende weergaven worden gebruikt, zijn de bedoelingen vrijwel hetzelfde. Een goede (hoewel ietwat oude) vergelijking is te vinden hier.
Het gezaghebbende bronboek voor gegevenskluis is Een schaalbaar datawarehouse bouwen met Data Vault 2.0 door Daniel Lindstedt en Michael Olschimke (Morgan Kaufmann, 2016).
Ik raad aan om deze drie websites te bezoeken om een overzicht te krijgen van het modelleren van gegevenskluizen:
De basisbouwstenen zijn:
- ‘Hubs’ (de kern van het record van een bedrijfsobjecttype)
- “Satellieten” (informatie over kenmerken van typen bedrijfsobjecten)
- “Links” (verbindingen tussen hubs en satellieten)
Hier is een diagram van een eenvoudig gegevenskluismodel (voorbeelden op DDL-niveau volgen):
Hans Hultgren is een bekende datafluis-trainer en “evangelist” die samenwerkt met Genesee Academy en anderen.
Let daar op:
- Er kunnen meerdere hubs zijn voor een bepaald type bedrijfsobject (als het afkomstig is uit meer dan één systeem)
- Er kunnen meerdere satellieten zijn voor een bepaald type bedrijfsobject (als er meerdere bronsystemen zijn en / of meerdere patronen van verandering ertussen). De gegevenskluis probeert over het algemeen gegevens te “bundelen”, die updatepatronen (en tijdlijnen) in één tabel delen
- Alle hubs, links en satellieten zijn afzonderlijke tabellen in SQL
- Databases van gegevenskluizen werken doorgaans met hashkeys om versies enz. Te isoleren.
(Bij ankermodellering is de keuze altijd de zesde normale vorm met individuele tabellen voor alles – en bij “concurrent-temporele” modellering worden alleen inserts gedaan in de database).
Lees voor een goede intro Dan Linstedt’s bericht over de Northwind-database die wordt weergegeven als een gegevenskluis. Als dat niet genoeg voor je is, dan zou ik HET boek over datakluis aanbevelen, Een schaalbaar datawarehouse bouwen met Data Vault 2.0, hierboven vermeld.
Het datakluis 2.0-boek (waarnaar hierboven wordt verwezen) heeft een aantal uitbreidingen op de tot dusver gepresenteerde terminologie. Hier volgt een lijst met de belangrijkste met indien nodig een toelichting.
Er zijn nog veel meer specifieke termen en constructies voor datakluis, maar het formaat van een blogbericht biedt er geen ruimte voor! Volg de bovenstaande links en lees het boek dat in dit bericht wordt genoemd voor meer informatie.
Datakluizen worden vaak gebouwd door middel van op sjablonen gebaseerde datakluisgeneratoren die op de markt beschikbaar zijn – hier zijn er een handvol:
- Vaultspeed
- WhereScape
- Visuele gegevenskluis
- Datavault Builder
- TEAM
In het hierboven genoemde gegevenskluisboek (2.0, de huidige versie van het boek), kunnen gegevenskluizen worden geconstrueerd (met behulp van ‘punt in tijd’-tabellen) om updates (van bijvoorbeeld de einddatumtijden) te elimineren, wat leidt tot het invoegen van alleen ladingen, die het meest performant zijn.
Data Vault DDL-voorbeelden
Het gegevenskluisboek waarnaar we verschillende keren hebben verwezen, Een schaalbaar datawarehouse bouwen met Data Vault 2.0, heeft een bijbehorende site waar u een grote verzameling code kunt downloaden. U moet het boek kopen om toegang te krijgen. Ik heb hieronder een paar voorbeelden van CREATE TABLE-statements uitgekozen om u een idee te geven van de complexiteit van de tabeldefinities in een gegevenskluis:
Een simpele hub (ankerpunt voor AirlineID):
Een enigszins complexe hub (ondersteunt een aaneengeschakelde bedrijfssleutel):
Een ‘payload’-satelliet die de luchthavens van herkomst beschrijft:
Een koppelingstabel (vluchten, vervoerders, vliegtuigen, datums, vertrekpunten en bestemmingen koppelen):
Een effectiviteitssatelliet:
Lessen die zijn getrokken uit het bouwen van grote databases in SQL
Om dit af te ronden: wat kunnen we dan overnemen als aanvullende zakelijke vereisten om een nog betere databasetaal te maken dan wat SQL tegenwoordig is?
Het is duidelijk dat de constructie van de basisgegevenskluis, waarbij een bedrijfsentiteit wordt gescheiden in hub (s) en satellieten, verschillende problemen aanpakt met betrekking tot:
- Sleutels
- Updates (mogelijk in verschillende bronsystemen)
De expliciete ondersteuning van relaties als fysieke tabellen (“links”) is ook gericht op het afhandelen van sleutels (vreemd in SQL-termen) en updates (mogelijk ook in verschillende bronsystemen).
Het is eerlijk om te zeggen dat we kunnen concluderen dat we de problemen met betrekking tot het omgaan met sleutels moeten oplossen:
- Identiteit en uniekheid
- Aanhoudende sleutels
- Aaneengeschakelde bedrijfssleutels
- Vreemde sleutels en hun relatie tot relaties
Er moet een gerichte, intuïtieve en flexibele aanpak worden ontworpen (in plaats van de problemen op te splitsen in verschillende fysieke database-objecten).
Tijdelijkheid is ook een belangrijke drijfveer achter datakluis en ankermodellering:
- Laad datetime-stempels
- Verander detectie
- Zoals versus vanaf (versies)
- Effectief van en naar
- Afhandeling van schemawijzigingen
En tot slot komt het bijhouden van gegevens ook expliciet aan de orde in de complexe datamodelleringspraktijken die hierboven zijn beschreven:
- Laad datetime-stempels
- Bron volgen
- Verander detectie
- Laad geschiedenis
Niet expliciet zichtbaar, maar zeker een belangrijke drijfveer achter datakluis is de behoefte aan snelheid bij het laden van data. Gebruikers hebben behoefte aan databases op petabyte-schaal, en ze dringen aan op snel laden en snelle zoekopdrachten.
Een interessante gedachte is dat de metadatamodellen in die datakluisgeneratoren waarschijnlijk relatief veel lijken op (delen van) een 6e normaalvorm datamodel. Dat geldt zeker ook voor ankermodellering.
Kunnen we deze uitdagingen op nieuwe manieren oplossen? Ja dat kunnen we! Een nieuwe taal (zoals de komende Graph Query Language, GQL) kan worden ontworpen om de hierboven genoemde modelleerproblemen op een ongecompliceerde, to-the-point constructies te ondersteunen die intuïtief zijn en effectief met die vereisten omgaan, achter de schermen en met goede prestaties. Parallel met de fysieke databaseobjecten moet het DBMS zich bewust zijn van de “diepe structuren” van semantiek die erachter schuilen het datamodel.