1.1 Inleiding
Het ontwerpen van een database lijkt enigszins op het ontwerpen van de architectuur van een Java-project. Je kunt alle data in een paar tabellen stoppen, of je kunt een mooie datastructuur bouwen van schema's en tientallen tabellen.
Dit zijn de taken waarmee een ontwikkelaar gewoonlijk wordt geconfronteerd bij het ontwerpen van een database:
- Ervoor zorgen dat alle benodigde informatie in de database wordt opgeslagen.
- Zorgen voor de mogelijkheid om gegevens te verkrijgen over alle noodzakelijke verzoeken.
- Vermindering van redundantie en duplicatie van gegevens.
- Zorgen voor database-integriteit
- Optimalisatie van de snelheid van gegevenstoegang
Het belangrijkste om te onthouden is dat je geen ideale databasestructuur kunt maken, omdat. het zal, net als uw code, ook voortdurend veranderen. Er zijn drie dingen waarmee u rekening moet houden bij het ontwerpen van uw databasestructuur:
- De structuur moet goed genoeg zijn.
- In alles moet een logica zitten die andere mensen kunnen begrijpen.
- Voortijdige optimalisatie is de wortel van alle kwaad.
U hoeft niet de beste databasestructuur ter wereld te maken. Ze zal nog veranderen. Het is jouw taak om ervoor te zorgen dat het na 20 wijzigingen in de structuur van je database gemakkelijk genoeg is om erachter te komen.
Hoogstwaarschijnlijk zal niemand je in de eerste jaren van je werk vertrouwen om een basis vanaf nul te ontwerpen. U gaat wijzigingen aanbrengen in een bestaand schema. Je moet proberen te begrijpen op basis van welke principes het is opgesteld en je eraan houden . Met hun charter klimmen ze niet in het klooster van iemand anders.
Optimaliseer de database pas als het nodig is. Als de tabel slechts een paar honderd rijen heeft, zal het DBMS deze hoogstwaarschijnlijk in het geheugen bewaren en er query's naar cachen.
Aan de andere kant zou je het werk van belangrijke verzoeken tientallen of zelfs honderden keren moeten kunnen versnellen. En het zou fijn zijn als je wist hoe het moet. Hoe zeggen ze op de middelbare school in het eerste jaar? "Vergeet alles wat je op school geleerd hebt..."
Als je weet wat databasenormalisatie is, dan haast ik me om je een plezier te doen, in je werk zul je hoogstwaarschijnlijk te maken hebben met denormalisatie . Niets is belangrijker voor de heiligdommen van het project dan de snelheid van de database. En als u, om de selectie van gegevens uit de database te versnellen, 200 (!) Tabellen moet combineren tot één (met monsterlijke redundantie), dan moet u dit doen.
1.2 Bibliotheekontwerp
Laten we een beetje in het onderwerp duiken en nadenken over het ontwerpen van databases met zoiets eenvoudigs als een typische boekenbibliotheek.
De hoofdtaak van elke bibliotheek is de verwerking van het boekenfonds. Er zijn gemakkelijk drie hoofdgroepen systeemgebruikers te onderscheiden: lezer, bibliothecaris, beheerder . De activiteit van elk wordt weergegeven in een use case-diagram.
Nu al kunnen enkele entiteiten en relaties van de toekomstige database worden onderscheiden:
Met deze benadering is het niet duidelijk hoe de lezer met het boek moet worden verbonden (de lezer heeft geen ariteit in de relatie "uitgifte / ontvangst". Als het boek meerdere exemplaren heeft, kan het aan meerdere lezers worden uitgegeven. Zelfs als een boek wordt opgevat als één exemplaar, dan zal het, wanneer het wordt opgeslagen in de boekentabel van de huidige lezer, onmogelijk zijn om informatie te verkrijgen over wie (en hoe vaak) dit boek eerder heeft genomen.
De oplossing kan de introductie van een extra entiteit zijn - een kaart voor het uitgeven van een boek. Wanneer het boek aan de lezer wordt uitgegeven, wordt er een kaart gemaakt en wanneer het boek wordt overhandigd, wordt er een overeenkomstig merkteken op geplaatst. Met behulp van deze kaarten worden de schulden van elke gebruiker bepaald en statistieken over het gebruik van boeken berekend. Bij het boeken van literatuur door de lezer wordt ook een kaart gestart; als de geboekte literatuur niet binnen een bepaalde periode door de lezer wordt afgenomen, wordt de kaart vernietigd. Er is een limiet aan het aantal boeken dat een lezer kan boeken.
Bij het selecteren van literatuur bekijkt de gebruiker de literatuurcatalogus met de mogelijkheid om de zoekresultaten te filteren op auteur, titel, jaar van publicatie.
Het is mogelijk om statistieken te berekenen voor alle boeken in de bibliotheek, terwijl het aantal uitgegeven exemplaren van het boek voor een bepaalde periode. U kunt ook het minimum aantal boekexemplaren instellen waarvoor de berekening wordt uitgevoerd. Op basis van deze statistieken worden ongebruikte boeken uit de bibliotheek afgeschreven.
De volgende hoofdentiteiten van het vakgebied kunnen worden onderscheiden:
- gebruiker (bibliothecarissen en beheerders);
- lezer;
- Lees Kamer;
- boek;
- boekuitgiftekaart;
- boekingskaart boeken.
Het gewijzigde ER-diagram van de database wordt getoond in de figuur.
Volgens de use-cases die worden weergegeven in afbeelding 1, moet de database de volgende query's implementeren (geen uitputtende lijst):
- boeken tonen die voldoen aan de opgegeven voorwaarden;
- gebruikers weergeven die kaarten hebben voor het uitgeven van boeken die niet op tijd zijn afgesloten (de bibliothecaris zoekt debiteuren);
- alle boeken weergeven die overeenkomen met de uitleenkaarten van de gegeven gebruiker die niet op tijd zijn gesloten (de gebruiker kwam naar de bibliotheek voor nieuwe boeken - u moet kijken of hij een schuldenaar is en hem hierover informeren);
- verwijder alle boekingskaarten die meer dan N seconden geleden zijn aangemaakt;
- toon alle boeken die overeenkomen met niet-gesloten boekreserveringskaarten van de opgegeven gebruiker (de lezer heeft boeken besteld en is naar de bibliotheek gekomen - de bibliothecaris heeft deze lijst nodig om deze uit te delen).
1.3 Schemavorming
Om een dataschema te vormen, moet je eerst het ER-diagram aanvullen met de details van de entiteiten (verfijnen). Soms is het tegelijkertijd mogelijk om fouten te vinden bij het construeren van een ER-diagram - bij deze taak bleek dat het boek "op de een of andere manier" verbonden moest zijn met de bibliotheekhal.
Dit kan door het vereiste “zaalnummer” in het boek te plaatsen, echter bij deze aanpak zal hetzelfde boek meerdere keren in de database beschreven moeten worden (als het in verschillende zalen voorkomt). Een correctere aanpak is om een extra entiteit "boekplaatsing" in te voeren. De afbeelding toont een ER-diagram met een toegevoegde entiteit en rekwisieten.
Het bovenstaande ER-diagram geeft de hoofdtabellen, relaties en attributen weer; op basis daarvan kunt u een databasemodel bouwen. Er is geen standaard voor het ER-diagram, maar er zijn een aantal notaties (Chen, IDEFIX, Martin, etc.), maar noch de standaard, noch de notaties konden worden gevonden voor het domeinmodel. Tijdens het construeren van een dergelijk diagram worden echter noodzakelijkerwijs sleutelvelden (extern en intern) gemarkeerd, soms indexen en gegevenstypen.
In dit geval in het volgende schema:
- voor links, Martin's notatie ("kraaienpootjes" wordt gebruikt);
- tabellen worden weergegeven als rechthoeken verdeeld in 3 secties:
- tafel naam;
- interne sleutels (gemarkeerd met een marker);
- de overige velden, terwijl de verplichte velden zijn gemarkeerd met een markering.
Bij het ontwikkelen van dit model was er een wens om de beheerderstabel samen te voegen met de bibliothecaristabel - voeg echter de gebruikerstabel toe:
- de beheerder is niet gekoppeld aan een specifieke kamer (u zou het overeenkomstige veld met null-waarden moeten invullen);
- dit zou waarschijnlijk de verdeling van toegangsrechten bemoeilijken - nu heeft alleen de databasebeheerder (die via een speciaal DBMS-paneel werkt en geen account heeft in het systeem dat wordt ontwikkeld) toegang tot de beheerderstabel. Bij het samenvoegen van tabellen hebben gebruikersquery's echter toegang tot de nieuwe tabel nodig.
Bij het maken van dit diagram werd een fout in het ER-diagram gevonden en gecorrigeerd - er werd een tabel toegevoegd librarians_roomsdie bibliothecarissen en zalen verenigt. Dit is nodig omdat één bibliothecaris in meerdere kamers kan werken, maar meerdere bibliothecarissen in dezelfde kamer kunnen werken.
Bij het ontwerpen van databases moet je in ieder geval kunnen redeneren zoals in het voorbeeld hierboven. Als je denkt dat het je gelukt is, gaan we verder: nog meer theorie.
GO TO FULL VERSION