Tips voor een beter databaseontwerp

In de loop der jaren, werkend als datamodelleur en database-architect, heb ik gemerkt dat er een paar regels zijn die moeten worden gevolgd tijdens datamodellering en -ontwikkeling. Hier beschrijf ik enkele tips in de hoop dat ze je kunnen helpen. Ik heb de tips opgesomd in de volgorde waarin ze voorkomen tijdens de levenscyclus van het project, in plaats van ze te rangschikken op belangrijkheid of hoe vaak ze voorkomen.

1. Plan vooruit

Niet plannen is plannen om te mislukken.

Alan Lakein

Een probleem dat ik heb gezien, is wanneer gegevensmodellering tegelijkertijd met softwareontwikkeling plaatsvindt. Dit is als het bouwen van de basis voordat de blauwdrukken worden voltooid. In het verleden leek planning een voor de hand liggende stap voordat met de ontwikkeling werd begonnen. Ontwikkelteams zouden geen databases maken zonder planning, net zoals architecten geen gebouwen zouden bouwen zonder blauwdrukken.

Bij applicatieontwikkeling is het van cruciaal belang om de aard van de gegevens te begrijpen.

Planning wordt vaak genegeerd, zodat ontwikkelaars gewoon kunnen "beginnen met coderen". Het project gaat van start en als er zich problemen voordoen, is er geen speling in de planning om ze aan te pakken. Ontwikkelaars nemen snelkoppelingen met de bedoeling ze later te repareren, maar dit gebeurt zelden of nooit.

Zorgvuldige planning is hoe je ervoor zorgt dat je een goede database krijgt die niet samen wordt gehackt. Als u vooraf niet de tijd en moeite besteedt aan het adresseren van de gegevens die nodig zijn voor de processen, betaalt u er later voor met een database die moet worden herwerkt, vervangen of afgedankt.

Zelfs als de planning niet altijd wordt gedaan, volgen veel datamodelleurs deze richtlijnen nog steeds. Dat wil niet zeggen dat we elke ontwerpbehoefte van tevoren kunnen voorspellen, maar de meeste modelbouwers zijn van mening dat het de moeite waard is om de gegevens en het gebruik ervan te begrijpen. U wilt geen ontwerp voor transactieverwerking wanneer het nodig is om analytische rapporten te maken.

Tijden zijn veranderd; Agile-methodologieën komen vaker voor, dus databaseteams moeten hun benadering van datamodellering heroverwegen. In Agile wordt het Domain Model uit Use Cases gebruikt in plaats van Entity Relationship Diagrams. De behoefte aan planning is echter niet afgenomen. We moeten de gegevens begrijpen en begrijpen wat ze moeten doen. Over het algemeen moeten de eerste paar Sprints zich richten op datadesign.

Het is dus niet Agile dat het probleem is voor databasemodelleurs, maar eerder voor individuen die de aard van data niet begrijpen. Sommigen zien database-ontwikkeling als hetzelfde als applicatie-ontwikkeling. Databasemodellering en softwareontwikkeling zijn verschillend en hebben de juiste focus nodig.

De database is de kern van de meeste softwaretoepassingen. U moet de tijd nemen om de vereisten te analyseren en hoe het datamodel daaraan zal voldoen. Dit verkleint de kans dat de ontwikkeling koers en richting verliest.

De ontwikkelaars moeten het belang van data en de bijdrage ervan aan het ontwikkelingsproces begrijpen. We leven in het informatietijdperk. Toepassingen tonen en manipuleren gegevens. Het is de informatie in de gegevens die betekenis geeft aan de applicatie.

Het is niet mogelijk om elke vereiste of elk probleem te voorzien, maar het is belangrijk om je voor te bereiden op problemen door een zorgvuldige planning.

2. Documenteer uw model

Bij het maken van een datamodel lijkt alles vanzelfsprekend. Je geeft de objecten een naam zodat hun doel duidelijk is en iedereen de betekenis zal begrijpen door de naam te lezen. Dit kan waar zijn, maar het is niet zo vanzelfsprekend als je zou denken. Maak bij het kiezen van namen voor tabellen en kolommen duidelijk wat het gebruik van elk object zal zijn. Na verloop van tijd zal de betekenis van objecten onduidelijk zijn zonder documentatie.

Het gebruik van een naamgevingsconventie is een stap in de richting van effectieve documentatie. Wanneer u in de toekomst wijzigingen moet aanbrengen, zult u eventuele bestaande documentatie op prijs stellen. Een kort, eenvoudig document dat de beslissingen beschrijft die u hebt genomen en het ontwerp beschrijft, zal u helpen de ontwerpkeuze op dat moment te verklaren.

U wilt voldoende documentatie zodat de database door een nieuwe beheerder kan worden beheerd en zij de betekenis kunnen begrijpen zonder bij u terug te hoeven komen voor uitleg. Als het datamodel en de omgeving niet gedocumenteerd zijn, is het moeilijk om het te onderhouden of te veranderen als de vereisten veranderen.

Documentatie heeft tot op zekere hoogte weinig te maken met datamodellering. Documentatie gaat over het communiceren van het ontwerp en het begrijpelijk maken ervan in de toekomst.

Documentatie is vaak een bijzaak. Wanneer schema's kort zijn, wordt documentatie genegeerd. Toch is dit technische schuld met hoge kosten. Door tijdens de ontwikkelingscyclus te bezuinigen, zullen in de toekomst kosten ontstaan ​​voor databasewijzigingen, probleemidentificatie, het opsporen van bugs en voor het begrijpen van het gegevensmodel en de aard van de gegevens.

Datamodellen hebben bijvoorbeeld vaak een "ID"-veld als primaire sleutel voor een tabel of een deel van de naam van een sleutel. Dit kan een primaire sleutel zijn, zoals TransactionID op de Transaction tafel. Als sommige tabellen "Nummer" gebruiken als onderdeel van de naam van een sleutel, dan is het goed om te documenteren waarom. Misschien ReferenceNumber wordt gebruikt als de naam van de primaire sleutel op het bericht, omdat de referentie zo wordt genoemd in het zakelijke gebied. In financiële diensten bevatten financiële berichten bijvoorbeeld doorgaans een referentienummer.

Documenteer de definitie van tabellen, kolommen en relaties zodat programmeurs toegang hebben tot de informatie. De documentatie moet de verwachtingen van de databasestructuur beschrijven.

In de Vertabelo-tool kan ik onmiddellijk commentaar toevoegen aan elk item:tabellen, kolommen, referenties, alternatieve sleutels, wat betekent dat de documentatie onmiddellijk bij mijn model wordt opgeslagen in plaats van in een extra document dat apart moet worden onderhouden.

Slechte of ontbrekende documentatie is vaak te wijten aan kortzichtig denken, maar negeer het belang ervan niet. Dit is nog een probleem dat moet worden opgelost.

3. Conventies volgen

Naamgevingsconventies lijken misschien niet belangrijk tijdens het ontwerp. In werkelijkheid geven namen het inzicht om een ​​model te begrijpen. Ze zijn een introductie en zouden logisch moeten zijn.

Inconsistente naamgeving heeft geen zin. Het frustreert alleen ontwikkelaars die toegang moeten hebben tot de gegevens, beheerders van de database en modelbouwers die in de toekomst wijzigingen moeten aanbrengen.

Wanneer "ID" wordt gebruikt voor sommige kunstmatige sleutels, maar sommige tabellen gebruiken een andere naamgevingsconventie (zoals Number), kunnen ontwikkelaars, analisten en DBA's tijd verspillen aan het begrijpen van de uitzonderingen. Zwakke naamgevingsconventies leiden ook tot fouten in de ontwikkeling omdat de naamgeving niet consistent is.

Hand in hand met documentatie, het gebruik van een naamgevingsconventie maakt het in de toekomst voor iemand om het model te begrijpen. Schakel niet willekeurig tussen het gebruik van "ID" (zoals CustomerID ) en “Nummer” (AccountNumber ) als de toetsen voor tabellen. Maak alleen uitzonderingen op de conventies als ze gerechtvaardigd zijn. Documenteer wat de uitzondering is en waarom de conventie niet wordt gerespecteerd.

Hetzelfde geldt voor cryptische namen zoals "XRT1" - zijn dat de uitgebreide referentietabellen? Jouw gok is even goed als die van mij. Ik hoop dat de ontwerper wist waarom hij zo'n cryptische naam koos, maar ik betwijfel of de volgende persoon die toegang krijgt tot de database de reden kan raden.

Naamgevingsconventies zijn een kwestie van persoonlijke keuze. Zorg ervoor dat beslissingen consistent en gedocumenteerd zijn.

Als ik erin geslaagd ben u te overtuigen om naamgevingsconventies toe te passen in uw databaseontwerp, lees dan gerust mijn volgende artikel dat volledig aan dit onderwerp is gewijd.

4. Denk goed na over sleutels

Sleutels genereren vaak controverse:primaire sleutels, externe sleutels en kunstmatige sleutels. Tabellen hebben een primaire sleutel nodig die elke rij identificeert. De kunst is om te beslissen welke kolommen deel moeten uitmaken van de primaire sleutel en welke waarden moeten worden opgenomen.

Voor een goede normalisatie heeft elke tabel een identificatiesleutel nodig. De uniciteit moet gegarandeerd zijn. Toch hoeven natuurlijke sleutels en primaire sleutels niet hetzelfde te zijn. In feite zijn ze dat misschien niet, zolang de tabel maar een natuurlijke sleutel heeft.

Sommige datamodelleurs geven de voorkeur aan een kunstmatige sleutel vanwege uniciteit. Toch geven sommige modelbouwers de voorkeur aan een natuurlijke sleutel om de gegevensintegriteit te waarborgen.

Dus, moeten we een natuurlijke sleutel gebruiken als de primaire sleutel? Een uitdaging ontstaat als de natuurlijke sleutel moet worden gewijzigd. Als de natuurlijke sleutel uit veel kolommen bestaat, moet u mogelijk op veel plaatsen wijzigingen aanbrengen. Een andere uitdaging is het gebruik van een kunstmatige sleutel als enige sleutel voor een tafel.

U heeft bijvoorbeeld een tabel met informatie over producten. De tabel kan worden gedefinieerd met een kunstmatige sleutel zoals een reeks, een code voor de korte alfabetische naam voor het product en de productdefinitie. Als uniciteit alleen wordt gegarandeerd door de kunstmatige sleutel, kunnen er twee rijen zijn met dezelfde productcode. Zijn dit hetzelfde product dat twee keer wordt ingevoerd? Misschien is een sleutel met de productcode meer geschikt.

5. Gebruik integriteitscontroles zorgvuldig

Om de gegevensintegriteit te waarborgen, hebben we externe sleutels en beperkingen nodig. Pas op dat u deze integriteitscontroles niet te veel of te weinig gebruikt.

Domeintabellen zijn effectief voor het afdwingen van integriteit. Domeintabellen werken goed wanneer er veel waarden moeten worden gecontroleerd, of als de te controleren waarden regelmatig veranderen.

Een probleem kan zijn dat ontwikkelaars besluiten dat de toepassing de integriteit controleert. Het probleem hierbij is dat veel applicaties toegang hebben tot een centrale database. Over het algemeen wilt u de gegevens ook beschermen waar ze zich bevinden:in de database.

Als de mogelijke waarden beperkt zijn of binnen een bereik vallen, kan een controlebeperking de voorkeur hebben. Laten we zeggen dat berichten worden gedefinieerd als Inkomend of Uitgaand, in welk geval er geen externe sleutel nodig is. Maar voor zoiets als geldige valuta's, hoewel deze misschien statisch lijken, veranderen ze van tijd tot tijd. Landen sluiten zich aan bij een muntunie en valuta's veranderen.

Applicaties moeten ook integriteitscontroles uitvoeren, maar vertrouw niet alleen op de applicatie voor integriteitscontrole. Het definiëren van integriteitsregels in de database zorgt ervoor dat die regels nooit worden geschonden. Op deze manier voldoen de gegevens te allen tijde aan de gedefinieerde integriteitsregels.

6. Vergeet geen indexen in uw ontwerp

Sommige indexeringsontwerpen zijn handig tijdens databasemodellering, zelfs als indexen kunnen veranderen tijdens daadwerkelijke implementatie en gebruik. Natuurlijk is het mogelijk om te veel indexen te hebben, net zoals het mogelijk is om te weinig te hebben.

Indexering is een continu proces. Tijdens het ontwerpen start u het proces op uw model. Ontwerpwerk is op de primaire sleutels en beperkingen.

Indexen zijn belangrijk bij het overwegen van query's op de gegevens. Bij het modelleren moet u overwegen hoe de gegevens worden opgevraagd. Zorg ervoor dat u niet overindexeert. Indexering draait om het optimaliseren van zoekopdrachten.

7. Vermijd algemene opzoektabellen

Ik heb vaak een algemene opzoektabel gezien voor attribuutparen. Het definiëren van een enkele, generieke domeintabel wordt gezien als een vereenvoudiging van het ontwerp. Deze stijl van domeintabel maakt een abstracte definitie voor het vasthouden van tekst. Ik heb gehoord dat het een "Toegestane waarde" of "Geldige waarden"-tabel wordt genoemd, maar de term "MUCK"-tabel is in 2006 bedacht voor dit anti-patroon:Massively Unified Code-Key.

MUCK-tabellen bevatten niet-gerelateerde gegevens.

U kunt bijvoorbeeld een tabel hebben die het domein, het item en een beschrijving definieert. Terugdenkend aan het berichtvoorbeeld hierboven, kunnen twee items zijn:

Voeg nu items toe voor een ander domein:

Dit is gewoon een puinhoop. Wat betekent de tabel?

Voor de lol heb ik een eenvoudig voorbeeld van een MUCK-tabel gemodelleerd (of OTLT, "One True Lookup Table" als je een Tolkien-fan bent) en enkele opmerkingen toegevoegd. Houd er rekening mee dat dit een antipatroon is en ik raad u niet aan dit in uw gegevensmodel te gebruiken.

Met MUCK-tabellen kunnen geen beperkingen worden gedefinieerd. MUCK's kunnen veel rijen worden zonder enige betekenis. Wanneer u een andere tabel moet opvragen om de betekenis van een veld te begrijpen, is dit niet ideaal.

Deze "alles mag"-tabellen maken integriteitscontroles complex of zelfs onmogelijk. Een reden dat deze tabellen kunnen worden gemaakt, is omdat verschillende tabellen in de database een vergelijkbare definitie hebben. Dan worden gegevensintegriteitscontroles onmogelijk. Hun grootte kan ook behoorlijk groot worden.

Normalisatie zou weg moeten leiden van MUCK-tabellen. Een enkele tabel moet een enkel domein vertegenwoordigen; in plaats van een enkele (MUCK) tabel die alle domeinen vertegenwoordigt. Zonder MUCK-tabellen kunnen we externe sleutelbeperkingen invoeren.

Gebruik aparte tabellen voor domeinobjecten in plaats van ze in een enkele tabel te proppen. Dit maakt de juiste kolomtypen, beperkingen en relaties mogelijk. Een tabel met 'Toegestane waarden' is gewoon een rommeltje en hoort niet thuis in een gegevensmodel.

8. Definieer een archiveringsstrategie

Ik heb maar al te vaak databases gezien die zijn gemaakt zonder een goede strategie voor het bewaren en archiveren van gegevens. Hoe lang blijven gegevens online beschikbaar in actieve databasetabellen? De meeste systemen zijn gebouwd om gegevens 'voor altijd' in de database te bewaren. Voor de meeste systemen is dit geen redelijke langetermijnstrategie voor het bewaren van gegevens. Op een gegeven moment moeten actieve gegevens worden gearchiveerd.

Een benadering die ik bepleit, is om het bewaren van gegevens op te nemen als onderdeel van uw ontwerpoverwegingen. Heeft u actieve en historische tabellen zodat het invoegen van nieuwe rijen in de actieve tabellen snel blijft, terwijl zoekopdrachten op historische gegevens kunnen worden geoptimaliseerd?

Dit voorkomt dat u de archivering in uw database opnieuw moet ontwerpen bovenop het oorspronkelijke ontwerp.

9. Test vroeg, test vaak

Om Al Capone (of John Van Buren, zoon van de 8e Amerikaanse president) te parafraseren:"test vroeg, test vaak". Zo volg je het pad van Continuous Integration. Testen in een vroeg ontwikkelingsstadium bespaart tijd en geld.

Testen is altijd een uitdaging in het ontwikkelplan. Er is vaak een testfase aan het einde van een Agile Sprint en systeemtesten aan het einde van de ontwikkeling. Testen is over het algemeen het eerste waar je op moet letten als de tijd krap wordt.

Bij het testen van de database moet het doel zijn om een ​​productieomgeving te simuleren:"A Day in the Life of the Database". Welke volumes zijn te verwachten? Welke gebruikersinteracties zijn waarschijnlijk? Worden de grensgevallen afgehandeld?

Het testplan en het juiste testen moeten dus een integraal onderdeel zijn van de datamodellering en database-ontwikkeling.

Conclusie

Dit zijn de belangrijkste problemen die ik heb gezien bij het werken met datamodelleurs en het beoordelen van datamodellen. Door aandacht te besteden aan deze tips, wordt uw database beter ontworpen en robuuster. Toch is de terugverdientijd van sommige van deze investeringen niet altijd duidelijk of zichtbaar. Plan, documenteer, gebruik standaarden, creëer sleutels, zorg voor integriteit, voer indexering uit, vermijd MUCK, ontwikkel strategieën en TEST!

Geen van deze activiteiten zal enorm veel tijd in beslag nemen en toch een enorme impact hebben op de kwaliteit van uw datamodel.

Wat is uw mening over deze tips?

Heeft u zelf tips?