Database-ontwerp. Beste praktijken

In afwachting van de start van de volgende stroom tegen de snelheid "Database" We hebben een klein auteursmateriaal opgesteld met belangrijke tips voor het ontwerpen van een database. We hopen dat dit materiaal nuttig voor u zal zijn.

Database-ontwerp. Beste praktijken

Databases zijn overal: van de eenvoudigste blogs en directory's tot betrouwbare informatiesystemen en grote sociale netwerken. Of de database eenvoudig of complex is, is niet zo belangrijk als wel het correct ontwerpen ervan. Wanneer een database gedachteloos en zonder een duidelijk begrip van het doel wordt ontworpen, is deze niet alleen ineffectief, maar zal verder werken met de database een echte kwelling zijn, een ondoordringbaar bos voor gebruikers. Hier volgen enkele databaseontwerptips waarmee u een nuttig en gebruiksvriendelijk product kunt maken.

1. Bepaal waar de tafel voor dient en wat de structuur ervan is

Database-ontwerp. Beste praktijken

Tegenwoordig helpen ontwikkelingsmethoden zoals Scrum of RAD (Rapid Application Development) IT-teams snel databases te ontwikkelen. Bij het najagen van de tijd is de verleiding echter heel groot om meteen in de bouw van een basis te duiken, terwijl je je vaag voorstelt wat het doel zelf is, wat de uiteindelijke resultaten zouden moeten zijn.
 
Het lijkt alsof het team gefocust is op efficiënt en snel werken, maar dit is een luchtspiegeling. Hoe verder en sneller je in de diepte van het project duikt, hoe meer tijd het kost om fouten in het databaseontwerp te identificeren en te wijzigen.

Het eerste dat u moet beslissen, is dus het doel van uw database definiëren. Voor welk type toepassing wordt de database ontwikkeld? Zal de gebruiker alleen met records werken en aandacht moeten besteden aan transacties, of is hij meer geïnteresseerd in data-analyse? Waar moet de basis worden ingezet? Zal het het gedrag van klanten volgen of eenvoudigweg klantrelaties beheren? 

Hoe eerder het ontwerpteam deze vragen beantwoordt, hoe soepeler het databaseontwerpproces zal verlopen.

2. Welke gegevens moet ik kiezen voor opslag?

Database-ontwerp. Beste praktijken

Vooruit plannen. Gedachten over wat de site of het systeem waarvoor de database wordt ontworpen in de toekomst zal doen. Het is belangrijk om verder te gaan dan de eenvoudige eisen van de technische specificaties. Denk alstublieft niet na over alle mogelijke soorten gegevens die een gebruiker ooit zal opslaan. Bedenk in plaats daarvan of gebruikers berichten kunnen schrijven, documenten of foto's kunnen uploaden of berichten kunnen uitwisselen. Als dit het geval is, moet u er ruimte voor toewijzen in de database.

Werk samen met het team, de afdeling of de organisatie waarvoor de ontwerpbasis in de toekomst zal worden ondersteund. Communiceer met mensen op verschillende niveaus, van klantenservicespecialisten tot afdelingshoofden. Zo krijgt u met behulp van feedback een duidelijk beeld van de eisen van het bedrijf. 

Het is onvermijdelijk dat de behoeften van gebruikers binnen dezelfde afdeling met elkaar in conflict zullen komen. Als u hiermee te maken krijgt, wees dan niet bang om op uw eigen ervaring te vertrouwen en een compromis te vinden dat voor alle partijen geschikt is en voldoet aan het uiteindelijke doel van de database. Wees gerust: in de toekomst ontvang je +100500 aan karma en een berg koekjes.

3. Modelleer gegevens zorgvuldig

Database-ontwerp. Beste praktijken

Er zijn een aantal belangrijke punten waar u op moet letten bij het modelleren van gegevens. Zoals we eerder zeiden, bepaalt het doel van de database welke methoden bij het modelleren moeten worden gebruikt. Als we een database ontwerpen voor online record processing (OLTP), oftewel voor het aanmaken, bewerken en verwijderen van records, maken we gebruik van transactiemodellering. Als de database relationeel moet zijn, kun je het beste multidimensionale modellering gebruiken.

Tijdens het modelleren worden conceptuele (CDM), fysieke (PDM) en logische (LDM) datamodellen gebouwd. 

Conceptuele modellen beschrijven entiteiten en de soorten gegevens die ze bevatten, evenals de relaties daartussen. Verdeel uw gegevens in logische stukken - het maakt het leven een stuk eenvoudiger.
Het belangrijkste is gematigdheid, overdrijf het niet.

Als een entiteit erg moeilijk in één woord of zin te classificeren is, dan is het tijd om subtypes (onderliggende entiteiten) te gebruiken.

Als een entiteit zijn eigen leven leidt, attributen heeft die zijn gedrag en uiterlijk beschrijven, evenals relaties met andere objecten, dan kunt u veilig niet alleen een subtype gebruiken, maar ook een supertype (bovenliggende entiteit). 

Als u deze regel negeert, zullen andere ontwikkelaars in uw model in de war raken en de gegevens en de regels voor het verzamelen ervan niet volledig begrijpen.

Conceptuele modellen worden geïmplementeerd met behulp van logische modellen. Deze modellen zijn als een routekaart voor fysiek databaseontwerp. In het logische model worden bedrijfsgegevensentiteiten geïdentificeerd, gegevenstypen bepaald en de status van de regelsleutel bepaald die de relaties tussen gegevens regelt.

Vervolgens wordt het Logische Datamodel vergeleken met het vooraf geselecteerde DBMS-platform (databasemanagementsysteem) en wordt een Fysiek Model verkregen. Het beschrijft hoe gegevens fysiek worden opgeslagen.

4. Gebruik de juiste datatypen

Database-ontwerp. Beste praktijken

Het gebruik van het verkeerde gegevenstype kan resulteren in minder nauwkeurige gegevens, problemen bij het samenvoegen van tabellen, problemen bij het synchroniseren van attributen en opgeblazen bestandsgroottes.
Om de informatie-integriteit te garanderen, mag een attribuut alleen gegevenstypen bevatten die daarvoor acceptabel zijn. Als leeftijd in de database wordt ingevoerd, zorg er dan voor dat de kolom gehele getallen van maximaal 3 cijfers opslaat.

Maak een minimum aan lege kolommen met een NULL-waarde. Als u alle kolommen als NULL maakt, is dit een grote fout. Als u een lege kolom nodig heeft om een ​​specifieke bedrijfsfunctie uit te voeren, terwijl de gegevens onbekend zijn of nog niet zinvol zijn, kunt u deze gerust aanmaken. De kolommen “Overlijdensdatum” of “Datum van ontslag” kunnen wij immers niet vooraf invullen; wij zijn geen voorspellers die met de vingers naar de hemel wijzen :-).

De meeste modelleringssoftware (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) data stelt u in staat prototypes van dataregio's te maken. Dit zorgt niet alleen voor het juiste datatype, applicatielogica en goede prestaties, maar ook dat de waarde vereist is.

5. Ga voor natuurlijk

Database-ontwerp. Beste praktijken

Wanneer u beslist welke kolom in een tabel u als sleutel wilt gebruiken, moet u altijd overwegen welke velden de gebruiker kan bewerken. Kies ze nooit als sleutel - een slecht idee. Er kan van alles gebeuren, maar je moet ervoor zorgen dat het uniek is.

Het is het beste om een ​​natuurlijke of zakelijke sleutel te gebruiken. Het heeft een semantische betekenis, zodat u dubbel werk in de database voorkomt. 

Tenzij de bedrijfssleutel uniek is (voornaam, achternaam, functie) en in verschillende rijen van de tabel wordt herhaald of moet worden gewijzigd, moet de gegenereerde kunstmatige sleutel worden aangewezen als de primaire sleutel.

6. Normaliseer met mate

Database-ontwerp. Beste praktijken

Om gegevens in een database effectief te ordenen, moet u een aantal richtlijnen volgen en de database normaliseren. Er zijn vijf normale vormen die moeten worden gevolgd.
Met normalisatie vermijdt u redundantie en waarborgt u de integriteit van de gegevens die in uw applicatie of site worden gebruikt.

Zoals altijd moet alles met mate gebeuren, zelfs normalisatie. Als er te veel tabellen in de database zijn met dezelfde unieke sleutels, dan heeft u zich laten meeslepen en de database te veel genormaliseerd. Overmatige normalisatie heeft een negatieve invloed op de databaseprestaties.

7. Test vroeg, test vaak

Database-ontwerp. Beste praktijken

Testplan en goed testen moeten deel uitmaken van het databaseontwerp.

De beste manier om uw database te testen is via continue integratie. Simuleer een ‘dag uit het leven van een database’-scenario en controleer of alle edge cases zijn afgehandeld en welke gebruikersinteracties waarschijnlijk zijn. Hoe eerder u bugs ontdekt, hoe meer u zowel tijd als geld bespaart.

Dit zijn slechts zeven tips die u kunt gebruiken om een ​​geweldige productiviteits- en efficiëntiedatabase te ontwerpen. Als u ze volgt, voorkomt u in de toekomst de meeste kopzorgen. Deze tips zijn slechts het topje van de ijsberg bij databasemodellering. Er zijn een groot aantal lifehacks. Welke gebruik je?

Bron: www.habr.com

Voeg een reactie