Wat zijn de stappen bij het ontwerpen van databases?

Databaseontwerp is een van de belangrijkste factoren die bijdragen aan de prestaties van een applicatie. Daarom is het van het grootste belang hoe goed de database is ontworpen. Bij het ontwerpen van databases draait alles om het efficiënt organiseren van gegevens op basis van productworkflows, toekomstige roadmap en verwachte gebruikspatronen.

De output van een database-ontwerpoefening is een datamodel. Een datamodel vertegenwoordigt alle objecten, entiteiten, attributen, relaties en beperkingen in het systeem. In het algemeen kunnen gegevensmodellen van twee soorten zijn:logisch of fysiek . De weergave van het gegevensmodel wordt gedaan door een ER-diagram te maken, ook wel een entiteitsrelatiediagram, een ERD-diagram of een databasediagram genoemd.

Het fysieke datamodel heeft betrekking op de daadwerkelijke implementatiedetails in de database. Het logische datamodel daarentegen abstraheert de technische aspecten van de implementatie. Dit maakt het logische datamodel bruikbaar voor de business. Een belangrijk verschil tussen de twee modellen is dat het logische model database-agnostisch is, terwijl het fysieke model specifiek moet zijn voor de gebruikte database.

Een goed database-ontwerp wordt vaak onderschat en verwaarloosd tijdens de ontwikkeling van applicaties. De kosten van deze verwaarlozing worden meestal veel later gerealiseerd wanneer nieuwe applicatiefuncties binnenkomen of wanneer oude functies moeten worden gewijzigd. Dit is wanneer het ontwerp van de database ophoudt zinvol te zijn. Hoewel het niet mogelijk is om het ontwerp van een database toekomstbestendig te maken, is het heel goed mogelijk om de moeite te nemen om de zakelijke use-cases zo goed mogelijk te begrijpen en de database dienovereenkomstig te ontwerpen. Lees hier meer over tips voor een beter databaseontwerp.

Laten we met dat in gedachten de stappen in het databaseontwerp doornemen.

Stap 1:Verzamel zakelijke vereisten

De eerste stap is om met het bedrijf te praten over hun vereisten. Als het gesprek effectief is, moet het voldoende informatie opleveren om te gaan werken aan een conceptueel datamodel, dat een abstractie is van het logische model. Door met de business te praten, krijg je allereerst een compleet beeld van de bedrijfsprocessen, die op hun beurt informatie geven over de verschillende datapunten die belangrijk zijn voor de business om vast te leggen en te volgen. In een boekingsmodel voor een taxi is het bijvoorbeeld de moeite waard om de volgende vragen te stellen:

Wilt het bedrijf de voertuigvolggegevens in de database, ongeacht of er een actieve rit is of niet? Zo ja, dan is het veld vehicle_trip_id in de tabel vehicle_trips zou nullable zijn . Anders is het niet nullable .
Wilt het bedrijf de geschiedenis van wijzigingen in trip_status opgeslagen in de database? Zo ja, dan elke keer dat de trip_status wijzigingen, komt er nog een record in de trips tafel. Anders, elke keer dat de trip_status wijzigingen, trip_status zal op zijn plaats worden bijgewerkt.

Zoals in dit voorbeeld wordt getoond, zou u op basis van de input van het bedrijf uiteindelijk de ene optie boven de andere kiezen. Het zou resulteren in het veranderen van de betrokken entiteiten en hun relaties.

Het verzamelen van vereisten omvat over het algemeen ook het starten van een gesprek over gegevensbeveiliging, zoals welke gegevens moeten worden gemaskeerd en versleuteld. De oefening voor het verzamelen van vereisten resulteert in een document met vereisten, vaak ondersteund door een werkend concept van het conceptuele datamodel.

Stap 2:begrijp de zakelijke routekaart

Bedrijven veranderen hun processen voortdurend; hun aanpassingsvermogen maakt dat ze minder snel falen. Veranderende bedrijfsprocessen betekent veranderende workflows en datamodellen. Hoewel het niet mogelijk is om deze veranderingen ruim van tevoren te kennen, is het zeker mogelijk om op de hoogte te zijn van de business roadmap.

Als een bedrijf bijvoorbeeld plannen heeft om zich op een nieuwe geografische regio te richten, moet het model rekening houden met taalondersteuning, valuta's, tijdzones, enzovoort. De voordelen van het begrijpen van de zakelijke roadmap voor de lange termijn komen vaak tot uiting in een soepelere overgang naar nieuwe bedrijfsprocessen.

Laat me nog een voorbeeld geven, dat meer gaat over continu evoluerende zakelijke prioriteiten. Het taxibedrijf werd aan het begin van COVID-19 zwaar getroffen. Als taxibedrijf wil je preventief optreden om mensen te verzekeren dat je er alles aan doet om ervoor te zorgen dat je reis in de taxi zo veilig mogelijk is, dat het voertuig elke dag wordt gedesinfecteerd, dat de chauffeur helemaal een masker draagt tijden, en dat er handdesinfecterend middel beschikbaar is in de cabine. Om al deze informatie vast te leggen, wijzigingen in twee entiteiten, drivers en vehicles , nodig zou zijn. Verschillende Booleaanse vlagvelden moeten aan deze entiteiten worden toegevoegd om tegemoet te komen aan deze zakelijke use-case.

Stap 3:Identificeer entiteiten en attributen

Zodra de zakelijke vereisten zijn verzameld, kan de informatie worden gebruikt om entiteiten te identificeren, samen met de essentiële set attributen. Een of meer entiteiten verwijzen over het algemeen rechtstreeks naar bedrijfsprocessen, en de relatie tussen die entiteiten bootst ook de workflow van het bedrijfsproces na.

Deze stap wordt ook gebruikt om te bepalen welke attributen zullen fungeren als identifiers in de entiteiten. Identifiers vertalen naar primaire sleutels in het fysieke model. Daarnaast is het ook gebruikelijk om gegevenstypen op te geven voor alle attributen in deze stap.

In het taxiboekingsmodel zou u bijvoorbeeld de attributen moeten identificeren die zullen dienen als de verplichte velden voor de registratie van gebruikers en chauffeurs van de boekingsapp. Gebruikersregistratie zou worden gedaan met behulp van user_phone en chauffeursregistratie zou worden gedaan met behulp van driver_phone .

Op dezelfde manier worden tijdens deze stap andere entiteiten en attributen geïdentificeerd, nadat ze zijn toegewezen aan de workflows van bedrijfsprocessen.

Stap 4:Identificeer relaties

Na het identificeren van de entiteiten en hun kenmerken, is de volgende stap het definiëren van de relaties tussen entiteiten op basis van de zakelijke workflows die zijn gedocumenteerd in de fase van het verzamelen van vereisten. Naast het vaststellen dat er een relatie is tussen twee entiteiten, is het ook belangrijk om vast te stellen welke van de volgende vier soorten relaties tussen hen bestaat. Overweeg twee willekeurige entiteiten, A en B:

Een-op-een → Eén record in A komt overeen met maximaal één record in B.
Een-op-veel → Eén record in A komt overeen met veel records in B.
Veel-op-één → Veel records in A komen overeen met maximaal één record in B.
Veel-op-veel → Veel records in A komen overeen met veel records in B.

In het taxiboekingsmodel is slechts één type relatie gebruikt, namelijk één-op-veel. Neem de relatie tussen users en trips als voorbeeld. In het model is er een aanname dat slechts één gebruiker kan worden gerelateerd aan een reis, wat inhoudt dat er geen gedeelde of gepoolde taxi's zijn. Maar als er gedeelde of gepoolde taxi's waren, zou er mogelijk een veel-op-veel-relatie zijn geweest tussen users en trips , als veel gebruikers dezelfde trip_id hebben gedeeld .

Stap 5:maak een logisch ER-diagram

Nu entiteiten, attributen en entiteitsrelaties zijn gedefinieerd, is de onmiddellijke volgende stap het tekenen van het ER-diagram. Alle bovenstaande stappen kunnen binnen Vertabelo worden uitgevoerd. Er zijn geen vaste regels voor de manier waarop logische modellering zou moeten worden gedaan, met mogelijke uitzondering van de referentienotatie.

Bekijk bijvoorbeeld het volgende voorbeeld van een logisch ER-diagram. Het legt een eenvoudige zakelijke workflow vast van een taxibedrijf, waarbij een gebruiker een rit kan boeken met de mogelijkheid om het voertuig te volgen.

Stap 6:Valideer het logische ER-diagram

Logische modellering is een proces waarbij veel bedrijfsinformatie moet worden vertaald naar een database-ontwerp. Zonder grondige controles is deze fase van databaseontwikkeling gevoelig voor fouten die in een later stadium behoorlijk kostbaar kunnen blijken te zijn.

Om hiervoor te zorgen heeft Vertabelo een gedegen lijst met controles die op een logisch model kunnen worden uitgevoerd. Controles kunnen op alle granulariteiten worden uitgevoerd, van het model als geheel tot individuele attributen en alles daartussenin. Enkele van de eenvoudige controles zijn:

Namen van entiteiten, attributen, relaties, enz., mogen niet nul zijn en moeten uniek zijn.
Een entiteit moet minimaal 1 attribuut hebben.
Identifiers (PK's) moeten voor elke entiteit worden gedefinieerd.
Het model moet een van de vermelde gegevenstypen voor kenmerken gebruiken.

Al deze controles zijn optioneel en kunnen worden geconfigureerd om te worden overgeslagen als er een ander validatieraamwerk is. Een goede validatie van Vertabelo helpt je naar de volgende stap te gaan met zo min mogelijk wrijving.

Stap 7:Maak een Fysiek ER-diagram

Nadat het logische ER-diagram is gemaakt, is de volgende stap het maken van een fysiek gegevensmodel. Het fysieke gegevensmodel is specifiek voor de database waarin u het gegevensmodel wilt implementeren. Alle databases hebben hun unieke implementatie van nomenclatuurregels, gegevenstypen en beperkingen. Hierdoor verschilt de Data Definition Language (DDL) vaak van database tot database.

Volg deze stappen om een fysiek gegevensmodel te maken:

Zoek het dichtstbijzijnde gegevenstype in de doeldatabase om het generieke gegevenstype te vervangen dat in het logische gegevensmodel is geselecteerd.
Volg de nomenclatuurregels voor tabellen, kolommen en beperkingen zoals voorgeschreven door de doeldatabase.
Wijzig het model zodat het overeenkomt met vooraf gedefinieerde query-workflows. Dit resulteert over het algemeen in toenemende redundantie om joins op te slaan.
Ten slotte kunt u indexen, partities, distributiesleutels en sorteersleutels maken. Dit is het moment waarop u prestatieverhogende wijzigingen aan het model kunt aanbrengen.

Deze stappen kunnen worden uitgevoerd met elke tool voor gegevensmodellering die u kunt gebruiken om een volledig nieuw gegevensmodel te maken. Vertabelo heeft echter een optie om een logisch datamodel om te zetten naar een volwaardig fysiek datamodel voor alle grote databasesystemen zoals MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery en meer. Zodra het logische datamodel is omgezet naar een fysiek datamodel, kun je doorgaan met de vier stappen die we hebben besproken.

Vertabelo heeft ook een optie om pre- en post-implementatiescripts op tabelniveau toe te voegen, samen met eventuele opmerkingen op het zeer gedetailleerde niveau van het model. De opmerkingen zijn handig wanneer de functie voor het genereren van documentatie die door Vertabelo wordt aangeboden, wordt gebruikt. Het databasedocument kan worden geëxporteerd in een van de volgende drie formaten:HTML, PDF of DOCX.

Laten we, om verder te gaan met het voorbeeld van het boeken van een taxi, eens kijken naar het fysieke datamodel dat door Vertabelo is gegenereerd.

Stap 8:Valideer het fysieke ER-diagram

Net zoals het logische ER-diagram werd gevalideerd, heeft Vertabelo een tool om fysieke ER-diagrammen te valideren met verschillende extra controles, zoals of FK's bestaan en of de lengte van een tabelnaam of een kolomnaam de limiet overschrijdt op basis van de geselecteerde database.

De validatie hoeft niet expliciet te worden uitgevoerd. Het gebeurt als het diagram wordt gewijzigd. De problemen met het model vallen in een van de drie categorieën:fouten, waarschuwingen en hints, in volgorde van afnemende ernst. Er is een nuttig, goed geschreven artikel waarin wordt gesproken over de veelvoorkomende fouten die worden gemaakt tijdens het ontwerpproces van de database.

Stap 9:problemen met het fysieke ER-diagram oplossen

De resultaten van de validatie kunnen problemen identificeren die moeten worden opgelost. Enkele van de meest voorkomende problemen zijn:

Ontbrekende externe sleutels waar entiteitsrelaties zijn gedefinieerd.
Primaire sleutels ontbreken in tabellen.
Niet-ondersteunde gegevenstypen voor de geselecteerde database.

Zodra deze en andere soortgelijke problemen zijn opgelost, is het model klaar om te worden geëxporteerd naar een inzetbaar SQL-script voor het geselecteerde databasebeheersysteem.

Stap 10:Genereer de DDL-scripts voor het implementeren van het model

Databaseontwerp gaat niet alleen over het maken van ER-diagrammen. Een oefening in gegevensmodellering met behulp van ER-diagrammen is alleen succesvol als het resulteert in iets inzetbaars. Vertabelo heeft een handige optie om het fysieke model te exporteren naar een kant-en-klaar SQL-script. Zodra het is gegenereerd, kunnen eventuele openstaande problemen direct in het SQL-script worden opgelost.

Het wordt echter niet aanbevolen om het gegenereerde SQL-script te wijzigen. Het veroorzaakt een drift tussen het fysieke gegevensmodel en het SQL-script dat in de database is geïmplementeerd, wat ook kan leiden tot een afwijking tussen de werkelijke tabellen en de databasedocumentatie.

Nu we het einde van het database-ontwerpproces hebben bereikt, gaan we eens kijken naar de SQL-code die door Vertabelo is gegenereerd.

Deel uw gedachten

Databaseontwerp is een activiteit met grote impact in softwareontwikkeling. Het gebied van databaseontwerp is in de loop der jaren geëvolueerd met nieuwe manieren om het ontwerp voor het bedrijf, voor de ingenieurs en voor de gegevensanalisten weer te geven. Dit heeft vaak geresulteerd in nieuwe soorten diagrammen, modelleringsnormen en notaties. Een groot deel van de evolutie is behandeld in de sectie over de basisprincipes van het ontwerp.

We kijken graag met u mee wat uw ervaringen zijn met het ontwerpen van databases. Schrijf ons op [email protected].