Datamodellering voor kwaliteit

In dit artikel beschrijf ik een methode voor het modelleren van gegevens, zodat het voldoet aan zakelijke eisen. Centraal in deze methode is dat het modelleren van niet alleen de vereiste gegevens, maar ook de subset van de echte wereld die betrekking heeft op de onderneming.

Dit onderscheid is al lang onderwerp van discussie in de datamodellering wereld: de eerste editie van (Kent, Data and Reality, 2015) werd gepubliceerd in 1978.

[Dit artikel wordt gepubliceerd in samenwerking met de IRM UK Data Governance Conference Europe – een virtuele conferentie die plaatsvindt van 15-17 November 2021. Het artikel is ook te vinden op IRM UK Connects. TDAN.com is een media sponsor van dit evenement.]

Waarom niet alleen de vereiste gegevens modelleren?
Er zijn goede redenen waarom we niet alleen de vereiste gegevens moeten modelleren.

Ten eerste is er meestal meer dan één manier om een real-world subset in data weer te geven. Beslissingen over welke datastructuren te gebruiken voor een bepaalde real-world subset zijn afhankelijk van verwerkingsvereisten, relatief gemak van query schrijven, en het doel DBMS of andere data platform. Terwijl ontwikkelaars moeten weten welke datastructuren worden gebruikt, en kunnen input hebben voor het besluitvormingsproces, zakelijke belanghebbenden zijn meestal alleen geïnteresseerd in welke informatie over de real-world subset ze kunnen bekijken en/of bij te werken in plaats van hoe het intern wordt weergegeven.

Ten tweede is het belangrijk dat de modelbouwer(s), alvorens tijd en moeite te investeren in een model dat de te gebruiken datastructuren weergeeft, de relevante reële Concepten, de relaties tussen deze concepten en hun attributen (inclusief het gedrag van die attributen) correct hebben begrepen. Dit kan alleen op betrouwbare wijze worden bereikt als belanghebbenden uit het bedrijfsleven een model krijgen dat zij kunnen begrijpen. Een logisch datamodel kan zowel primaire sleutels als bedrijfsidentifiers en buitenlandse sleutels bevatten, alsook relaties, wat de hoeveelheid metadata toevoegt die moet worden geanalyseerd door een zakelijke stakeholder die het model herziet.

bijvoorbeeld
Laten we bijvoorbeeld de gegevens modelleren die het mogelijk maken de volgende vragen te beantwoorden:

Welke vlucht (en) reizen van Luchthaven A naar Luchthaven B op welke dagen?
Op welke luchthaven begint vlucht X?
Op welke luchthaven eindigt vlucht X?
Op welke andere luchthavens (indien van toepassing) stopt vlucht X?
Op welke dagen vliegt Flight X?
Sommige vluchten hebben alleen een herkomst en een bestemming (zoals QF11 van Sydney – Los Angeles), terwijl andere, multi-leg, vluchten tussenliggende haltes hebben (zoals QF1 van Sydney – Londen Heathrow via Singapore). Deze kunnen op een aantal manieren worden weergegeven:

gebruik van een SQL: 2003 (object-relationele) tabel met een ingebedde sub-tabel zoals in Figuur 1
in traditionele SQL relationele tabellen zoals in Figuur 2
in een Vluchtpoottabel waarin elk deel van een meerpootvlucht afzonderlijk wordt weergegeven, zoals in Figuur 3.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *