Voel je je overweldigd door de hoeveelheid tijd die je nodig hebt om te leren databaseontwerper te worden? Lees over de essentiële vaardigheden en talenten die je nodig hebt - het is niet zo erg!
Waar denk je aan als je door de gangpaden van de supermarkt loopt, het winkelwagentje in de ene hand en het boodschappenlijstje in de andere? Als je net als ik bent, stel je je voor hoe je de organisatie van de schappen kunt verbeteren, zodat je wekelijkse boodschappen minder tijdrovend zijn. Of misschien voel je hetzelfde verlangen om informatie te ordenen en te structureren wanneer een vriend je hun grote collectie tijdschriften laat zien. Of misschien valt het op wanneer u uw afspeellijsten beheert om beter aan uw voorkeuren te voldoen. Als je door het leven gaat nadenken over hoe je de werkelijkheid kunt representeren in termen van entiteiten, attributen en relaties, dan is het je roeping om databasemodelleur te zijn.
Misschien ben je niet zo extreem, maar je voelt je nog steeds aangetrokken tot het idee om database-ontwerp als een carrière na te streven. Hoe dan ook, je zult een paar nieuwe vaardigheden onder de knie moeten krijgen. Sommige zijn puur technisch; deze vaardigheden kun je leren door te studeren of te lezen en te verdiepen door werkervaring. Andere vaardigheden omvatten niet-technische kennis die u kunt leren door middel van cursussen, blogartikelen of door anderen te observeren.
Hier is een samenvatting van de essentiële kennis en vaardigheden die elke databaseontwerper moet hebben.
Databaseontwerpers voor harde vaardigheden hebben behoefte
Harde vaardigheden zijn vaardigheden die door studie worden verworven en door oefening worden aangescherpt. Als je met concreet bewijs kunt aantonen dat je een harde vaardigheid onder de knie hebt, betekent dit dat je in staat bent om elke taak uit te voeren die daarbij komt kijken.
Wat databasekennis betreft, omvatten harde vaardigheden de grondbeginselen van databasetheorie en de verschillende technieken die worden gebruikt om theoretische concepten toe te passen om concrete problemen op te lossen. Laten we eens kijken naar elk van de harde vaardigheden die databaseontwerpers nodig hebben.
Databasetheorie
Databasetheorie zit vol met abstracte concepten die moeilijk te begrijpen kunnen zijn als ze niet worden geassocieerd met echte feiten. Het relationele model, domeinen, attributen, relaties en relaties, primaire en externe sleutels, entiteitsintegriteit, referentiële integriteit en domeinbeperkingen zijn slechts enkele voorbeelden. Als je nog complexere zaken toevoegt (zoals relationele algebra of relationele calculus), kun je je afvragen of het niet beter zou zijn om een carrière te kiezen die zich bezighoudt met concrete dingen zoals tuinieren of gastronomisch koken.
Geen paniek. Grondige kennis van databasetheorie is belangrijk als u van plan bent colleges te geven of een nieuwe manier uitvindt om informatie te ordenen. Maar om databases te ontwerpen, hoeft u alleen de theoretische concepten te beheersen die van toepassing zijn op het oplossen van echte problemen. De belangrijkste – het ABC van databaseontwerp – is het relationele model.
Het relationele model
Hogeschoolprofessoren zullen je vertellen dat het relationele model een gegevensorganisatiemechanisme is dat is gebaseerd op verzamelingenleer en predikatenlogica. Maar daar heb je in je dagelijkse werk als databasemodelleur niet veel aan. In de praktijk moet u weten dat het relationele model een intuïtieve en eenvoudige manier is om gegevens in de vorm van tabellen te ordenen - relaties genoemd - die zijn samengesteld uit rijen (die ook tupels worden genoemd). Elke tabel (of relatie) wordt gedefinieerd door zijn attributen (of kolommen).
Fundamentele concepten van het relationele model.
Alle relaties moeten een of meer openstaande attributen hebben die een unieke identifier vertegenwoordigen voor elke tuple. In database-jargon is dat de sleutel van de tabel. Niet-sleutelkenmerken zijn sleutelafhankelijk in die zin dat elke sleutelwaarde een enkele mogelijke waarde voor elk kenmerk bepaalt.
Stelt u zich een tabel met voertuiginformatie voor waarin de sleutel het kenteken is. De kentekenplaat bepaalt de kenmerken van elk voertuig (zoals de fabrikant, het model, de eigenaar, enz.), aangezien de regels van het domein voorkomen dat twee verschillende voertuigen dezelfde kentekenplaat delen.
Relationele databases
Relationele databasebeheersystemen (RDBMS'en) implementeren het relationele model, met respect voor de principes ervan. Ze bieden manieren om informatie op te halen via zoekopdrachten en informatie bij te werken via transacties. Om ervoor te zorgen dat de informatie in een relationele database real-life feiten en situaties weergeeft, kunt u voorwaarden of beperkingen definiëren die specifiek zijn voor het domein waarop de database van toepassing is. In een tabel met informatie over scholieren kan bijvoorbeeld een beperking worden opgelegd zodat de geboortedata geen toekomstige data of data die te ver in het verleden liggen, toestaan.
De organisatie van tabellen in een database wordt gewoonlijk het databaseschema genoemd. Naast tabellen geeft het schema details over beperkingen met betrekking tot paren tabellen die relaties worden genoemd. Een relatie verbindt twee tabellen door de beperking op te leggen dat de waarden in het veld van een van de tabellen overeenkomen met waarden in de primaire sleutel van de andere tabel.
Databaseschema's worden meestal weergegeven door het entiteit-relatiediagram (ERD), een veelgebruikt hulpmiddel voor elke databaseontwerper.
Een ERD die een klantgegevensmodel vertegenwoordigt.
Anomalieën en normalisatie
Alle concepten die we tot nu toe hebben besproken, zijn redelijk duidelijk, toch? Nu kunnen we praten over de anomalieën die optreden in databases als gevolg van een gebrekkig of ontoereikend ontwerp (d.w.z. de database weerspiegelt niet adequaat de realiteit die hij probeert weer te geven).
Afwijkingen treden op wanneer een invoeg-, bijwerk- of verwijderbewerking inconsistenties in de gegevens genereert. Stel dat u een tabel hebt om verkoopgegevens op te slaan. Voor elke verkoop (d.w.z. in elk record van de tabel) worden de naam en het adres van de klanten geregistreerd. De anomalie is als volgt:
- Als het adres van de klant is gewijzigd in een van de verkopen, en
- Dezelfde klant heeft andere verkopen,
- De andere verkopen hebben een verouderd adres.
Om afwijkingen te voorkomen, kunt u een ontwerptechniek toepassen die databasenormalisatie wordt genoemd. Dit omvat het ontleden van tabellen en kolommen (d.w.z. ze in kleinere delen op te splitsen) om ontwerpfouten te voorkomen, zoals:
- Kolommen die meer dan één stuk informatie bevatten (bijvoorbeeld het ID-nummer van een item en de naam).
- Dezelfde informatie meer dan eens opslaan in dezelfde tabel.
- Velden die afhankelijk zijn van andere niet-sleutelvelden.
Niet-genormaliseerde tabel (links) versus genormaliseerd schema (rechts).
Datawarehouses en denormalisatie
Sommige databases worden gebruikt voor het opvragen van grote hoeveelheden informatie in plaats van online transactieverwerking (OLTP). Deze databases worden datawarehouses genoemd.
De informatie in een datawarehouse komt niet uit gebruikersinterfaces (bijvoorbeeld rechtstreeks ingevoerd vanuit een e-commerce bestelsysteem). Het is afkomstig van batchprocessen die informatie uit verschillende bronnen verzamelen, verwerken, opschonen en opslaan in tabellen. Om deze reden kunnen we aannemen dat datawarehouses niet worden blootgesteld aan dezelfde afwijkingen als conventionele databases.
Daarom hoeven datawarehouses niet dezelfde normalisatievoorwaarden te handhaven als een OLTP-database. Aan de andere kant is het belangrijker om de query-efficiëntie in datawarehouses te optimaliseren. Daarom wordt in een datawarehouse denormalisatie toegepast; deze techniek maakt gebruik van een zekere mate van redundantie om query's te vereenvoudigen en schema's vol te proppen met een buitensporig aantal tabellen.
Een typisch datawarehouse-schema.
Big data
Net als datawarehousing verwijst het concept van Big Data naar opslagplaatsen die grote hoeveelheden gegevens bevatten. Er is echter een belangrijk verschil tussen beide concepten. Een datawarehouse is ontworpen voor een specifiek doel en is gericht op het genereren van rapporten waarvan het gedrag en formaat van tevoren bekend zijn.
Big Data daarentegen is gericht op het verzamelen van grote hoeveelheden gegevens die met hoge snelheid worden gegenereerd uit verschillende bronnen - b.v. informatie van sociale media, microtransacties of slimme sensoren. Deze enorme hoeveelheid informatie kan worden gebruikt voor verkenning en analyse of voor het trainen van machine learning-modellen.
Bij het ontwerp van Big Data-databases krijgen opslagruimtebesparing en gegevenspartitionering (onder andere) prioriteit om parallellisme en realtime gegevensvastlegging mogelijk te maken. Daarnaast worden niet-relationele of NoSQL-databasesystemen gebruikt, die betere alternatieven bieden voor het verwerken van ongestructureerde informatie.
Technologieën zoals NoSQL en het concept van Big Data zelf zijn relatief nieuw in vergelijking met relationele databases, die al meer dan 40 jaar oud zijn. Daarom moet je als databaseontwerper alert zijn op nieuwe ontwikkelingen op dit gebied. Houd er rekening mee dat Big Data ook big business is. Veel bedrijven willen daarin een leidende positie innemen en ontwikkelen daarvoor nieuwe tools en technologieën.
Databasebeheer
Als een database eenmaal in de lucht is, moet iemand voor het dagelijkse beheer zorgen. Dit betekent routinematige taken uitvoeren zodat de database nooit een bottleneck wordt voor de applicaties die er gebruik van maken. Beheertaken omvatten het onderhouden van back-ups, het bewaken van het verbruik van opslagruimte, het detecteren van crashes tussen processen en het oplossen van gegevensproblemen die de normale werking van applicaties belemmeren.
De persoon die over de databasevaardigheden beschikt om deze taken uit te voeren, is de databasebeheerder, of DBA - als die er is. In zeer kleine organisaties – of in ontwikkelomgevingen waar de werking van de databases niet essentieel is voor het bedrijf – kan de verantwoordelijkheid voor het databaseonderhoud bij de databasemodelleur komen te liggen. Daarom moet u enige kennis hebben waarmee u in bepaalde situaties de DBA kunt overnemen. U mag echter in geen geval de verantwoordelijkheid aanvaarden voor het beheer van een database in een productieomgeving die zakelijke of bedrijfskritieke toepassingen ondersteunt .
Beheertaken variëren sterk, afhankelijk van het databasesysteem en de infrastructuur waarop het is gemonteerd. De taken van het beheren van Microsoft SQL Server-databases zijn bijvoorbeeld heel anders dan die van het beheren van MySQL- of Oracle-databases. En het beheren van een server die lokaal op uw notebook draait, is heel anders dan het beheren van een server die in de cloud draait.
Ik raad niet aan om veel moeite te doen om te leren hoe je een bepaalde databaseserver moet beheren, aangezien je gedurende je hele carrière met heel verschillende databases en omgevingen te maken krijgt. Het heeft niet veel zin om je in slechts één te specialiseren.
Concurrency- en transactiebeheer
Gelijktijdige toegang tot een database kan problemen veroorzaken in toepassingen wanneer meerdere gebruikers tegelijkertijd toegang proberen te krijgen tot dezelfde bron. We zouden kunnen denken dat dit als ontwerpers niet onze zaak is en dat het de verantwoordelijkheid van de DBA is om met deze problemen om te gaan. We kunnen ook denken dat het de schuld van de programmeurs is voor het maken van applicaties die dit toestaan.
Ontwerpers kunnen echter hun deel doen om mogelijke gelijktijdigheidsproblemen te minimaliseren door schema's te ontwerpen die ze vermijden.
Veel gelijktijdigheidsproblemen treden op wanneer lange en complexe transacties op een database worden uitgevoerd; terwijl de transactie wordt verwerkt, worden de betrokken tabellen geblokkeerd voor andere processen die ze nodig hebben om informatie te lezen of te schrijven. Om dit soort problemen te voorkomen, kunt u er het beste voor zorgen dat uw ontwerpen minimaal voldoen aan de derde normaalvorm. Vervolgens is het de verantwoordelijkheid van de programmeur om correct over de transacties na te denken om impasses te voorkomen.
Maar u kunt ook strategieën gebruiken die gelijktijdigheid vermijden, zoals het partitioneren van schema's of het groeperen van tabellen volgens de functie die elk vervult.
Laten we ons een database voor een e-commercesite voorstellen. U kunt de stamgegevenstabellen voor producten, voorraad en prijzen in het ene schema plaatsen en bestellingen en verkopen in een ander, samen met weergaven of alleen-lezen replica's van de tabellen uit het eerste schema. Dit helpt fouten te voorkomen bij het uitvoeren van transacties die de stamgegevens bijwerken.
Hulpprogramma's voor databaseontwerp
Als u het relationele model, de entiteit-relatiediagrammen en normalisatietechnieken begrijpt, kunt u databases ontwerpen met geen ander hulpmiddel dan potlood en papier. Uw prestaties zullen echter aanzienlijk worden verbeterd als u een intelligente tool gebruikt, vooral een die bepaalde ontwerptaken kan automatiseren, zoals het verplaatsen of wijzigen van objecten in een diagram, het detecteren van ontwerpfouten, het genereren van SQL-scripts om een database te maken of bij te werken, en het omkeren van engineering van een bestaand databaseontwerp.
Als u een gespecialiseerde tool beheerst, zoals het Vertabelo-platform, kunt u veel sneller werken. En het stelt je in staat om je te onderscheiden van andere ontwerpers die deze hulp niet hebben.
SQL en programmeren
We willen allemaal graag een database-ontwerp kunnen opleveren, trots kunnen zeggen “Mijn werk hier is gedaan” en vertrekken voor een welverdiende vakantie. Maar meestal gebeurt die ideale situatie nooit. Als je eenmaal klaar bent met je ontwerp, moeten de applicatieprogrammeurs het gebruiken, en ze hebben jou in de buurt nodig om hen te helpen.
Een manier om te blijven helpen bij een ontwikkelingsproject, is door views, triggers, opgeslagen procedures en andere dingen in SQL (Structured Query Language) te schrijven om bepaalde toepassingsbehoeften op te lossen. Een andere manier is om toezicht te houden op de programmeertaken die worden uitgevoerd met iets dat Object-Relational Mapping (ORM) wordt genoemd.
ORM's zijn bedoeld om gegevenstoegang uit een bepaald RDBMS te abstraheren. De goede kant hiervan is dat programmeurs zich geen zorgen hoeven te maken over de details van de database die ze zullen gebruiken - met andere woorden, ze hoeven zich geen zorgen te maken of het RDBMS MySQL, Oracle, IBM DB2, MS SQL Server is , of iets anders.
Het nadeel van ORM's is dat de database-ontwerpobjecten - tabellen, attributen en relaties - worden gedefinieerd in de code van een programmeertaal op hoog niveau zoals Java, Python, R of C#. Met andere woorden, ze zijn waar wij databaseontwerpers ze niet kunnen zien.
De oplossing voor dit probleem ligt in Agile-ontwikkelingsmethodologieën en hun samenwerkingsfilosofie. Deze bevorderen dat ontwerpers en programmeurs samenwerken in de loop van een project, dus u wilt een goede relatie met de programmeurs behouden. Je moet bereid zijn om naast hen te gaan zitten, naar de programmeercode te kijken en samen de definities van de data-objecten te schrijven.
Soft Skills Database Designers zouden moeten hebben
Naast de theoretische en technische kennis die specifiek is voor databaseontwerp, zou een ontwerper idealiter over andere vaardigheden moeten beschikken die bekend staan als 'soft skills'. Deze vaardigheden, zoals een goede communicator zijn en de visie van het bedrijf op het eindproduct begrijpen, hebben indirect invloed op het succes van uw werk. Degene die ik hieronder noem zijn slechts enkele voorbeelden, maar er zijn nog veel meer soft skills die enorm worden gewaardeerd door potentiële werkgevers.
Zakelijke visie
Wanneer u een database ontwerpt, representeert u de realiteit van een bedrijf in termen van onderling gerelateerde gegevensobjecten. We hebben gezien dat het ontwerp moet voldoen aan standaardisatievoorwaarden en dat het inconsistenties, anomalieën en gelijktijdigheidsproblemen moet voorkomen. Maar net zo belangrijk – of misschien wel belangrijker – is dat het ontwerp aansluit bij de bedrijfsvisie van degene die je salaris betaalt.
Als u de bedrijfsvisie begrijpt, kunt u het belang van elke vereiste beter begrijpen en uw beslissingen sturen, zodat uw ontwerpen beter aansluiten bij de doelstellingen van de organisatie.
Hier is een eenvoudig voorbeeld van hoe inzicht in de bedrijfsvisie uw werk zal vormgeven. U denkt misschien dat het gebruik van een surrogaatsleutel in een tabel uw ontwerp onoverzichtelijk maakt en een onnodig en vervelend element toevoegt. Maar door de surrogaatsleutel weg te laten, kunt u query's op die tabel vertragen omdat een sleutel van het INTEGER-type superieure prestaties kan leveren. Als het de bedrijfsvisie is om snelle vragen te stellen, dan is de surrogaatsleutel de juiste keuze.
Communicatievaardigheden
Het is niet genoeg om geweldige ontwerpen te maken. Je moet ook kunnen uitleggen waarom je ontwerp werkt. De manier om dit te doen is te weten hoe je het moet presenteren, zowel discursief (gesproken of geschreven) als visueel.
Maak een lijst van de sterke punten van je ontwerp zodat ze opvallen. Denk na over de beslissingen die je hebt genomen om het te maken en noteer de redenen voor die beslissingen. Wees bereid om uw beslissingen en uw ontwerp te verdedigen tegen degenen die het niet begrijpen of die het willen veranderen, waardoor het onvolmaakt of gebrekkig is.
Maar je moet ook bereid zijn opbouwende kritiek te accepteren en standpunten in overweging te nemen die anders zijn dan de jouwe. Soms kan een programmeur een probleem opmerken dat u niet zag en u goed advies geven. Ontsla uw collega's niet omdat ze denken dat ze geen databasekennis hebben.
Interpersoonlijke vaardigheden
Ik heb hierboven al gewezen op de voordelen van een goede verstandhouding met programmeurs. Hoe geavanceerd u ook bent in uw vakgebied, het is belangrijk dat u een houding van kameraadschap behoudt met alle teamleden, of het nu een tester is die een defect heeft ontdekt dat u dwingt een deel van uw ontwerp te heroverwegen of een projectmanager die behoefte heeft aan u om een taak te volbrengen tegen een bepaalde datum. Kortom,je moet een teamspeler zijn . Niemand wil prima donna's in hun team hebben die zich onvervangbaar voelen en hun regels willen opleggen.
Het kan voorkomen dat u niet de enige database-ontwerper in een ontwikkelteam bent. Misschien moet je een subgroep van je collega's leiden. Om dit te doen, moet je leiderschapskwaliteiten tonen en optreden als projectmanager, om ervoor te zorgen dat het team van databaseontwerpers zijn doelstellingen haalt en gemotiveerd blijft.
Hoe u databaseontwerpvaardigheden leert
U kunt de vaardigheden die u nodig heeft om databaseontwerper te worden, verwerven via universitaire opleidingen, cursussen, boeken en gespecialiseerde artikelen. Het voordeel van universitaire cursussen is dat ze je alle kennis geven die je nodig hebt en die kennis onderschrijven met een erkend diploma. Het nadeel is dat ze een grote investering van tijd en geld vergen.
Als u liever zelf leert door boeken en artikelen te lezen, bespaart u tijd en geld - maar u hebt een gids nodig om u door de essentiële onderwerpen te leiden en uw kennis te evalueren. En je zult je kennis op een praktische manier moeten demonstreren, omdat je geen diploma hebt om het te staven.
In ieder geval, of je nu leert door cursussen te volgen of te lezen, die kennis zal alleen als basis dienen. Je leert het meest door modellen te maken, echte problemen onder ogen te zien en de acties van je collega's en collega's te observeren.