Databaseontwerp gaat veel verder dan alleen lijnen en kaders tekenen. In dit artikel reflecteer ik op het proces van gegevensmodellering met de nadruk op best practices, evenals op het gebruik van tools om die best practices te implementeren om een goed database-ontwerp te creëren.
Databaseontwerp is het proces van het produceren van een gedetailleerd model van een database. De start van databasemodellering houdt in dat u inzicht krijgt in het zakelijke gebied en de functionaliteit die wordt ontwikkeld.
Als u een beetje onzeker bent over de stappen die betrokken zijn bij het ontwerpproces van de database, verwijs ik u naar deze beschrijving van de stappen voor het ontwerpen van databases.
Begin met modelleren:praat met het bedrijf
Dit is een sleutelprincipe in de informatietechnologie. We lossen een zakelijk probleem aan de datakant op zodat de benodigde data beschikbaar is. We moeten met de zakenmensen praten om hun behoeften te begrijpen.
We moeten vragen stellen als:
- "Wat is het domein?"
- "Wat zijn de uitdagingen in dit domein?"
- "Wat zijn de problemen die moeten worden opgelost?"
- "Welke informatie moeten we bewaren?"
Door met het bedrijf te praten, kunnen we afwegingen maken die van invloed kunnen zijn op het databasemodel. We leggen ook de basis voor modellering.
Laten we een concreet voorbeeld gebruiken. Neem een boekhoudtoepassing voor een bedrijf:u zou klanten, leveranciers, facturen, betalingen, rekeningen, saldi, enz. moeten modelleren. U moet deze concepten en boekhouding leren kennen. Je kunt dit alleen doen door praten aan de zakenmensen.
Concepten op orde krijgen
Dit eerste werk met het bedrijfsleven zal u leiden naar een model van welke "concepten" in de database moeten worden opgeslagen (lees deze uitleg van de verschillende niveaus van modellen). Van het concept van wat we in de database moeten opslaan, dat wil zeggen ons conceptuele model, gaan we naar een logisch model. Het logische model documenteert de bedrijfsconcepten en regels waarop we details stapelen (u bent wellicht geïnteresseerd om deze discussie te lezen over de vraag of logische gegevensmodellering achterhaald is).
Als je niet zeker bent over de verschillende soorten datamodellen, bekijk dan ons artikel over het implementeren van conceptuele, logische en fysieke datamodellen met Vertabelo.
Het logische datamodel voegt meer informatie toe aan de concepten die we al hebben gedocumenteerd. Het beschrijft hoe de gegevens zijn gestructureerd en hoe de entiteiten zich tot elkaar verhouden. Daarnaast bevat het informatie over de soorten gegevens die we beheren.
In Vertabelo kunnen we een logisch datamodel maken via een logisch entiteit-relatiediagram (ERD). Bekijk de details over het uitvoeren van logische gegevensmodellering met Vertabelo.
Hier is een eenvoudig, en nog niet volledig, logisch datamodel van klanten, leveranciers, facturen, betalingen en rekeningen.
Een ander voordeel van het werken met Vertabelo is dat ik me niet al te veel zorgen hoef te maken over de exacte notatie. Met de modelleringstool hoeft u zich geen zorgen te maken over het ontwerp en niet over de bijzonderheden van de notaties en symbolen van het entiteit-relatiediagram (ERD), wat uiteraard de minste van uw zorgen zou moeten zijn tijdens het ontwerpproces van de database.
Laten we fysiek worden
Om daadwerkelijk met de database te werken, moeten we van ons logische model naar een fysiek model gaan. Met de Vertabelo-tool kunnen we eenvoudig een fysiek datamodel genereren vanuit een logisch model. U maakt eerst een logisch datamodel, daarna kunt u "auto-magisch " genereer een fysiek model door het logische model te selecteren en op "Fysiek gegevensmodel genereren" te klikken (zie deze gedetailleerde handleiding voor de exacte stappen).
Het is duidelijk dat het gegenereerde fysieke datamodel vergelijkbaar zal zijn met het logische model; logische gegevenstypen worden echter vertaald in gegevenstypen die zijn toegestaan voor het specifieke databasebeheersysteem (DBMS) waarvoor u het fysieke model genereert. Het fysieke model zal ook aangeven welke attributen refererende sleutels zijn tussen tabellen. Mogelijk wilt u ook aanvullende modellering uitvoeren met betrekking tot de fysieke aspecten van de database, bijvoorbeeld indexen en weergaven.
Daarnaast is het mogelijk om direct een fysiek datamodel te maken; je hoeft niet eerst een logische aan te maken. Rechtstreeks naar een fysiek model gaan is logisch voor kleinere, meer gerichte modelleringsactiviteiten, waar het bedrijfsdomein beter is gedefinieerd. Het modelleringsproces van de fysieke database is eenvoudig en zou niet al te veel uitdagingen moeten opleveren. Het hebben van een logisch datamodel zal nuttig zijn voor grotere projecten, maar het hebben van ten minste een fysiek model is beter dan helemaal geen.
Evolutie van uw database-ontwerp
Ontwikkelaars vinden over het algemeen dat het databasemodel rond de eigenlijke code moet draaien, terwijl datamodelleurs denken dat de code moet worden gemaakt op basis van een relatief statisch gegevensmodel. Gegevensmodellering moet tegenwoordig samenwerkend zijn . De code en het datamodel beïnvloeden elkaar heen en weer.
We hebben dus een tool nodig die een gezamenlijk databaseontwerpproces en modellering ondersteunt. Naast het werken met het bedrijf om het conceptuele ontwerp te maken, moeten datamodelleurs tijdens de ontwikkelingscyclus samenwerken om de logische en fysieke datamodellen indien nodig bij te werken. Modelbouwers en ontwikkelaars moeten het model aanpassen totdat het echt de zakelijke en niet-functionele vereisten van het systeem ondersteunt.
Veranderingen kunnen uiteraard tot fouten leiden. Nogmaals, het hebben van een tool kan helpen; een tool die uw datamodel voortdurend valideert, is van onschatbare waarde. Vertabelo heeft een ingebouwde, live, online validatie voor zowel logische als fysieke datamodellen zodat problemen worden gedetecteerd tijdens het modelleren, niet tijdens de implementatie. En fouten blijven zichtbaar voor iedereen die eraan meewerkt. Ook kunt u de validatie-instellingen naar wens aanpassen. Hier is een voorbeeld van mijn onvolledige gegevensmodel met verschillende fouten en waarschuwingen.
Terugkerend naar het boekhoudvoorbeeld, zou u tijdens de ontwikkeling kunnen ontdekken dat het niet voldoende is om een enkele valuta zoals euro's of dollars te modelleren voor facturen en betalingen. In plaats daarvan zou u bedragen met hun respectieve valuta moeten opslaan en deze moeten converteren naar de "basis" -valuta waarin de boekhouding van het bedrijf wordt gehouden. Mogelijk hebt u ook de wisselkoersen en historische informatie nodig van de koersen die in het verleden werden gebruikt voor het omrekenen van valuta.
Dit is waar een tool voor collaboratieve databasemodellering zoals Vertabelo echt zijn waarde bewijst. U kunt meer informatie vinden over het gebruik van Vertabelo voor collaboratieve modellering. U hoeft alleen maar te klikken en uw model te delen met uw teamleden.
Fysiek voor implementatie
Zodra u uw eerste versie van het fysieke model hebt, zult u waarschijnlijk graag met de eigenlijke database aan de slag gaan. Om dat te doen, genereert Vertabelo SQL DDL-scripts (Data Definition Language) om de database te maken. Ik zal hier niet alle details schrijven, omdat je ze kunt vinden in het online Knowledge Base-artikel over het genereren van een SQL-script waarmee je een database maakt.
Laat me je uit ervaring vertellen - dit is zo'n welkome functie. U voorkomt dat u te maken krijgt met de grillen van verschillende SQL DDL-syntaxis voor databases, en u kunt zich concentreren op uw ontwerp .
Versiebeheer
Zoals ik hierboven schreef, zullen je modellen evolueren, of het nu is tijdens het ontwerpen van de database, tijdens de softwareontwikkeling of daarna tijdens het daadwerkelijke gebruik van je database. Er zijn twee geweldige functies van Vertabelo waarvan ik zeker wil weten dat je ze kent.
Ten eerste omvat Vertabelo versiebeheer. U kunt wijzigingen volgen en versies van de gegevensmodellen beheren, dus het is gemakkelijk om "de tijd terug te draaien" en indien nodig terug te draaien naar een vorige versie. Als je gedisciplineerd bent, kun je de verschillende versies taggen met precieze namen, of dat nu concepten of daadwerkelijke releases van de database zijn.
De andere functie, waar ik jarenlang van heb gedroomd tijdens mijn databasemodellering, is de mogelijkheid van de Vertabelo-tool om automatisch migratiescripts genereren tussen versies van uw gegevensmodel. Ik ben de tel kwijt van de keren dat ik herhaaldelijk handmatig migratiescripts moest schrijven en corrigeren. Hier is een voorbeeld van het genereren van de migratiescripts tussen twee versies van een database voor een online enquête.
Wat een zegen voor datamodelleurs om een tool te hebben die versies efficiënt beheert en de impact van wijzigingen tussen de versies inschat!
Grote modellen
Laat ik eerst eerlijk zijn. Ik werk niet altijd met grote modellen, maar soms moet ik ze wel maken. Ook hier biedt Vertabelo ons een oplossing om onze modellen te organiseren.
We kunnen tabellen visueel groeperen met onderwerpgebieden; als je wilt zien hoe je dat doet, kun je ook een video bekijken over het beheren van grote datamodellen in Vertabelo.
U kunt deze techniek ook gebruiken wanneer u reverse-engineering uitvoert van een SQL DDL-script naar een gegevensmodel.
Aan de slag met database-ontwerp
Als u op zoek bent naar enkele praktische tips voor het ontwerpen van databases, raad ik u aan dit artikel te bekijken. Voor tips voor een beter databaseontwerp hoeft u niet verder te zoeken dan dit artikel. En bekijk deze voor advies over hoe u aan de slag kunt gaan met Vertabelo voor uw database-ontwerp.