Zephyrnet-logo

Conceptuele versus logische versus fysieke datamodellering – DATAVERSITY

Datum:

conceptuele versus logische versus fysieke datamodelleringconceptuele versus logische versus fysieke datamodellering

Bedrijven worden geconfronteerd met een razendsnelle en enorme datagroei “in een tijd waarin analytische capaciteiten daar niet eens bij in de buurt kunnen komen”, zei dr. Peter Aiken tijdens zijn recente Data-Edwebinar, "Conceptuele versus logische versus fysieke gegevensmodellering." Aiken, een erkende autoriteit op het gebied van gegevensbeheer en president van DAMA International, legde uit dat er sprake is van een gebrek aan begrip en documentatie van een bedrijf Gegevensarchitectuur – in combinatie met datastructuren die moeten worden bijgewerkt – leveren geen bruikbare informatie op.

In plaats daarvan hebben veel ondernemingen geplaveide systemen die geen gemeenschappelijke datastructuurtaal spreken en ontwikkelingsgymnastiek vereisen om betekenisvolle gegevens te verkrijgen via een exponentieel aantal systeem- en gebruikersinterfaces. Dit resulteert erin dat organisaties 80% van hun budget besteden aan het verbeteren van bestaande architecturen, merkte Aiken op.

Om betekenisvolle informatie te verkrijgen zijn datastructuren nodig die in een goed raamwerk zijn georganiseerd. Het gebruik van een driedimensionale benadering van evolutionaire datamodellering om bestaande systemen te reverse-engineeren, de vereisten bij te werken en vooruit te gaan met de nieuwe vereisten, belooft een uitstekende aanpak. 

Tijdens het webinar besprak Aiken deze driedimensionale evolutionaire databenadering, wat het is en hoe deze te gebruiken.

Waarom überhaupt een datamodelleringsaanpak overwegen?

Standaard heeft een data-architectuur een soort datamodel, begrepen of gedocumenteerd, omdat het op zijn minst een fysieke datastructuur heeft om gegevens van een systeem naar een gebruiker te krijgen. Volgens Aiken lopen de meeste organisaties vast in dit fysieke model, beginnend met een gebrekkige architectuur en proberen ze de technische structuur op te lossen zonder “een enkele gedachte” over wat de data-architectuur doet of waarom.

Dus omdat veel bedrijven bestaande systemen reverse-engineeren zonder de bestaande systemen en hun sterke en zwakke punten te begrijpen, lopen ze het risico gebrekkige datastructuren door te geven of er niet in te slagen datastructuren die werken opnieuw te creëren. Het aanvankelijke datastructuurprobleem wordt doorgegeven via alle verschillende oplossingen. Aiken zei:

 “Een ernstig productdefect kan het gedurende de hele levenscyclus achtervolgen. Verschillende bedrijven hebben deze 'oepsies' gehad, te beginnen met een gebrekkig datamodel. Bijgevolg houdt deze aanpak deze onvolkomenheden vast en beperkt de voordelen van data-investeringen in de toekomst. “

De organisatie beschikt over onvoldoende verbruikbare gegevens door het migreren, converteren en verbeteren van het bestaande systeem. Dit gebrek betekent dat het updaten van bestaande datastructuren langer duurt en meer kost om waardevolle informatie te leveren.

Om dit proces te doorbreken, moeten bedrijven hun data modelleren om een ​​specifiek bedrijfsprobleem op te lossen en een gedeeld begrip tussen business en IT te bereiken. Ja, organisaties hebben een fysiek model nodig dat hun technische mensen kunnen bouwen; Bedrijven hebben echter ook modellen nodig met dezelfde gemeenschappelijke woordenschat tussen de zakelijke belanghebbenden en de technische mensen die het dataplatform bouwen om betekenisvolle informatie te verkrijgen. 

Waarom drie datamodellen overwegen: conceptueel, logisch en fysiek?

Aiken erkende dat datamodellering in componenten moet worden uitgevoerd om een ​​datastructuur te krijgen die de waarde van de data verbindt met de informatie die nodig is voor de bedrijfsactiviteit of -situatie. Hij merkt op dat er rekening moet worden gehouden met gegevens en informatie wanneer een consument de gegevens vraagt ​​om iets te doen.  

Organisaties creëren elk datamodel om in dit proces een specifieke bedrijfsvraag te beantwoorden: de benodigde informatie. Eén datamodel dat de volledige data-architectuur van het bedrijf probeert weer te geven, wordt log en onbruikbaar, zoals de onderstaande figuur laat zien: 

Beeldbron: Peter Aken

Denk in plaats daarvan aan datamodellen en data-architectuur zoals ontwikkeld voor specifieke behoeften op basis van het op te lossen probleem. Omdat de bedrijfsbehoeften evolueren, kunt u datamodellen als iteratief beschouwen om een ​​bepaald doel beter te bereiken.

Om het doel van een model te bereiken, zijn sommige typen beter geschikt. Terwijl een fysiek model een data-oplossing weergeeft zoals deze is gebouwd, moeten bedrijven weten hoe ze deze oplossing moeten maken en wat ze fundamenteel voor het bedrijf bouwen. Een logisch datamodel reageert op de manier waarop het moet worden gebouwd, en een conceptueel model beschrijft wat er moet worden gemaakt om het bedrijfsprobleem of de casus op te lossen.

Waarom dimensies toevoegen aan drie soorten gegevensmodellen?

Doorgaans beginnen bedrijven niet helemaal opnieuw met het modelleren van een bedrijfsprobleem, omdat er datasystemen bestaan. IT neemt dus de beschikbare data-architectuur en brengt er wijzigingen in aan, wat een wijziging in de datamodellen noodzakelijk maakt. 

Stel dat ontwikkelaars en ingenieurs verder gaan met het updaten en creëren van een nieuwe architectuur. In dat geval gaat IT ervan uit dat ze hebben gevalideerd wat er bestaat en dat iedereen die aan het systeem werkt, dat inzicht heeft.

Deze redenering verklaart dus waarom veel bedrijven hun platforms reverse-engineeren. Ze willen naar een plek komen van het niet gevalideerde of begrepen bestaande systeem naar de gevalideerde, begrepen plek.

Maar hoe weet IT wat er bestaat en hoe voldoet het aan de bedrijfsbehoeften? Wat als de vereisten veranderen omdat het bedrijf is geëvolueerd sinds de updates van de dataoplossing?

Volgens Aiken moeten de mensen die het systeem bouwen of updaten op de hoogte zijn van eventuele nieuwe bedrijfsvereisten en wat er veranderd is. Dit vereist chatten en afstemmen met de zakenmensen en belanghebbenden die de informatie uit de data nodig hebben voor hun werk.

Daarom moeten organisaties begrijpen wat er al bestaat en weten wat er nodig zal zijn. Ze moeten reverse-engineeren zoals ze zijn en de data-architectuur bouwen op basis van wat deze moet zijn. Zie het onderstaande diagram:

Beeldbron: Peter Aken

Een driedimensionaal model-evolutieraamwerk

Het toevoegen van de validatiestatus van het datamodel biedt een derde dimensie voor Aiken. Zie de afbeelding hieronder:

Beeldbron: Peter Aken

Elk datamodel – conceptueel, logisch en fysiek – voegt zich bij elkaar en vormt een volledige Data Architecture-component. Elk modeltype heeft echter een ander doel en een ander perspectief op de zakelijke behoeften en wordt op een andere manier gebruikt.

Het conceptuele datamodel – de datavereisten die nodig zijn om zaken te doen 

Bij het specificeren van wat er moet gebeuren, biedt het conceptuele datamodel “de focus en reikwijdte”, aldus Aiken. Het organiseert de bestaande dataconcepten, analyseert deze met de strategie van de organisatie, merkt afwegingen op vanwege technische sterke en zwakke punten, en bouwt toekomstige capaciteiten op.

Het allerbelangrijkste is dat het conceptuele datamodel de woordenschat harmoniseert tussen technisch personeel, minder technische zakenmensen en tussen systemen. Met belanghebbenden en ingenieurs aan tafel stelt Aiken het volgende voor:

  • Identificeer de entiteiten
  • Identificeer de sleutel voor elke entiteit
  • Teken de verbindingen tussen de entiteiten
  • Identificeer gegevenskenmerken
  • Wijs deze gegevensattributen toe aan de entiteiten

Door dit proces, zo adviseert Aiken, zal het conceptuele model enigszins evolueren. Als deze radicaal begint te veranderen, overweeg dan een andere manier om naar de context te kijken, zoals het beschrijven van verschillende gebruikersvisies via een logisch model en dan terug te keren naar het conceptuele model.

Door de architectuur conceptueel uit te leggen, zijn de deelnemers het eens over wat de entiteiten bedoelen, waardoor hun woordenschat en communicatie worden geharmoniseerd. Deze discussies vormen de basis van een ondernemingstaxonomie met zinvolle bedrijfsdefinities en geldige entiteiten die vereist zijn voor het bedrijfsleven.

Het logische datamodel – Hoe u aan de zakelijke datavereisten kunt voldoen 

Volgens Aiken helpen logische datamodellen bij de overgang tussen de conceptuele en fysieke datamodellen. Ze geven informatie over hoe het conceptuele model moet worden opgebouwd en de moeite die het kost.

Door dit proces kan het logische model de bestaande conceptuele datamodellen uitdagen, aangezien logische datamodellering informatie verschaft over de inspanning, zoals omvang en vorm. Het bedrijfsleven en IT zijn dus betrokken bij het bespreken van logische datamodellen om de juiste relaties met entiteiten te verfijnen, de overeenstemming over de architectuur te vereenvoudigen en te standaardiseren, en een gedeeld vocabulaire tussen bedrijfs- en technische analisten mogelijk te maken, merkte Aiken op.

Het fysieke datamodel – technische blauwdrukken om de bedrijfsoplossing te bouwen 

Als bedrijven de bestaande bedrijfsvereisten begrijpen, weten wat het bedrijf wil en hoe ze dit logisch kunnen opbouwen, hebben bedrijven een specifiek doel. Deze bedrijven hebben bewijsmateriaal over hoe ze de datastructuren, stromen en entiteitsrelaties opnieuw kunnen creëren om een ​​oplossing te bouwen die op één lijn ligt. Deze informatie vormt het fysieke datamodel, de implementatie en de blauwdruk. 

Doorgaans kan IT semi-geautomatiseerde technieken toepassen, met behulp van ingebouwde algoritmen of het maken van programma's "om de datastructuren bloot te leggen of te controleren die moeten worden gemaakt, bijgewerkt, gelezen of verwijderd", aldus Aiken. 

Er kunnen zich vragen voordoen waarbij technische professionals met conceptuele en logische modellen naar het bedrijf moeten terugkeren om meer informatie te verkrijgen om het bedrijfsprobleem via het fysieke model op te lossen.

Conclusie

“Bedrijven moeten aan datamodellering doen om een ​​specifiek bedrijfsprobleem op te lossen of een zakelijke vraag te beantwoorden”, vat Aiken samen. IT en bedrijven moeten doelen en inzichten delen om tot een data-oplossing te komen. Bovendien moet er een gemeenschappelijke taal tussen systemen zijn, zodat gegevens soepel kunnen stromen.

Het zal echter niet helpen om welk model dan ook of een grote, overkoepelende bedrijfsarchitectuur samen te voegen. Een datamodel moet een bepaald doel bereiken, en om dat doel te bereiken is een systematisch proces nodig. 

Het driedimensionale modelevolutieraamwerk van Aiken biedt middelen voor een verbeterd dataplatform. Het houdt rekening met de bestaande architectuur en de evolutie die nodig is om aan de zakelijke behoeften te voldoen en valideert dat belanghebbenden en bouwers op één lijn zitten.

Een combinatie van conceptuele, logische en fysieke datamodellen belooft betekenisvolle en nuttige resultaten, vooral daar waar business en IT een gemeenschappelijk doel moeten bereiken. Door de datamodellering correct uit te voeren en de vereisten te begrijpen, kunnen bedrijven 20% tijd en geld vrijmaken om hun datamogelijkheden te benutten en er meer waarde uit te halen.

Bekijk het webinar:

Afbeelding gebruikt onder licentie van Shutterstock

spot_img

Laatste intelligentie

spot_img