2.1. Conceptueel ontwerp

Het databaseontwerp wordt in drie fasen uitgevoerd:

  1. conceptueel ontwerp;
  2. logisch ontwerp;
  3. fysiek ontwerp.

Het doel van de conceptuele ontwerpfase is het creëren van een conceptueel gegevensmodel op basis van de ideeën van gebruikers over het onderwerpgebied. Om dit te bereiken, wordt een reeks opeenvolgende procedures uitgevoerd. Een voorbeeld van een entiteit (conceptueel) schema:

1. Definitie van entiteiten en hun documentatie. Om entiteiten te identificeren, worden objecten gedefinieerd die onafhankelijk van andere bestaan. Dergelijke objecten zijn entiteiten. Elke entiteit krijgt een betekenisvolle naam die gebruikers kunnen begrijpen. De namen en omschrijvingen van de entiteiten worden ingevoerd in de datadictionary. Indien mogelijk wordt het verwachte aantal exemplaren van elke entiteit ingesteld.

2. Bepaling van relaties tussen entiteiten en hun documentatie. Alleen die relaties tussen entiteiten worden gedefinieerd die nodig zijn om te voldoen aan de ontwerpvereisten voor de database. Het type van elk is ingesteld. De lidmaatschapsklasse van entiteiten wordt onthuld. Links krijgen betekenisvolle namen die worden uitgedrukt door werkwoorden. Een gedetailleerde beschrijving van elke verbinding, met vermelding van het type en de klasse van verbondenheid van de entiteiten die aan de verbinding deelnemen, wordt ingevoerd in de datadictionary.

3. Creatie van een ER-model van het vakgebied. ER-diagrammen worden gebruikt om entiteiten en relaties daartussen weer te geven. Op basis daarvan wordt een enkel visueel beeld van het gemodelleerde onderwerpgebied gemaakt - het ER-model van het onderwerpgebied.

4. Definitie van attributen en hun documentatie. Alle kenmerken die de entiteiten van het gemaakte ER-model beschrijven, worden onthuld. Elk attribuut krijgt een betekenisvolle naam die gebruikers kunnen begrijpen. Per attribuut wordt de volgende informatie opgeslagen in de datadictionary:

  • attribuut naam en beschrijving;
  • type en dimensie van waarden;
  • de standaardwaarde voor het attribuut (indien aanwezig);
  • of het attribuut NULL-waarden kan hebben;
  • of het attribuut samengesteld is, en zo ja, uit welke enkelvoudige attributen het bestaat. Het kenmerk "Volledige naam van de klant" kan bijvoorbeeld bestaan ​​uit eenvoudige kenmerken "Achternaam", "Voornaam", "Patroniem", of het kan eenvoudig zijn en enkele waarden bevatten, zoals "Sidorsky Evgeniy Mikhailovich". Als de gebruiker geen toegang nodig heeft tot individuele elementen van de "Naam", wordt het attribuut als eenvoudig gepresenteerd;
  • of het attribuut wordt berekend, en zo ja, hoe de waarden ervan worden berekend.
Java university

5. Definitie van attribuutwaarden en hun documentatie. Voor elk attribuut van een entiteit die deelneemt aan het ER-model, wordt een set geldige waarden bepaald en wordt er een naam aan toegekend. Het attribuut "Accounttype" kan bijvoorbeeld alleen de waarden "deposit", "current", "on demand", "card account" hebben. De datadictionary-items die betrekking hebben op de attributen worden bijgewerkt met de namen van de attribuutwaardesets.

6. Definitie van primaire sleutels voor entiteiten en hun documentatie. Deze stap wordt geleid door de definitie van een primaire sleutel - als een attribuut of set attributen van een entiteit die een unieke identificatie van zijn instanties mogelijk maakt. Primaire sleutelinformatie wordt in de datadictionary geplaatst.

7. Bespreking van het conceptuele datamodel met eindgebruikers. Het conceptuele datamodel wordt weergegeven door een ER-model met bijbehorende documentatie waarin een beschrijving van het ontwikkelde datamodel is opgenomen. Als domeininconsistenties worden gevonden, worden wijzigingen in het model aangebracht totdat gebruikers bevestigen dat het door hen voorgestelde model hun persoonlijke opvattingen adequaat weergeeft.

2.2 Logisch ontwerp

Het doel van de logische ontwerpfase is om het conceptuele model op basis van het geselecteerde datamodel om te vormen tot een logisch model dat onafhankelijk is van de kenmerken van het DBMS dat later wordt gebruikt voor de fysieke implementatie van de database. Om dit te bereiken, worden de volgende procedures uitgevoerd.

Een voorbeeld van een logisch databaseschema.

1. Een datamodel kiezen. Meestal wordt een relationeel gegevensmodel gekozen vanwege de duidelijkheid van de tabelweergave van gegevens en het gemak om ermee te werken.

2. Op basis van het ER-model een set tabellen definiëren en documenteren. Er wordt een tabel gemaakt voor elke entiteit van het ER-model. Entiteitsnaam is de naam van de tabel. Relaties tussen tabellen worden tot stand gebracht via het mechanisme van primaire en externe sleutels. De structuren van de tabellen en de gevestigde relaties ertussen worden gedocumenteerd.

3. Normalisatie van tabellen. Om normalisatie goed uit te voeren, moet de ontwerper de semantiek en gebruikspatronen van de gegevens grondig begrijpen. Bij deze stap controleert hij de juistheid van de structuur van de tabellen die in de vorige stap zijn gemaakt door de normalisatieprocedure erop toe te passen. Het bestaat uit het brengen van elk van de tafels naar ten minste de 3e NF. Door normalisatie wordt een zeer flexibel database-ontwerp verkregen, waardoor het eenvoudig is om de nodige uitbreidingen hierop aan te brengen.

4. Controleren van het logische datamodel op de mogelijkheid om alle door gebruikers verstrekte transacties uit te voeren. Een transactie is een reeks acties die wordt uitgevoerd door een individuele gebruiker of een toepassingsprogramma om de inhoud van een database te wijzigen. Een voorbeeld van een transactie in het BANK-project kan dus de overdracht zijn van het recht om de rekeningen van een bepaalde klant te beheren aan een andere klant. In dit geval moeten er meerdere wijzigingen tegelijk in de database worden aangebracht. Als een computer crasht tijdens een transactie, bevindt de database zich in een inconsistente staat omdat sommige wijzigingen al zijn aangebracht en andere niet. Daarom moeten alle gedeeltelijke wijzigingen ongedaan worden gemaakt om de database terug te brengen naar de vorige consistente staat.

De lijst met transacties wordt bepaald door de acties van gebruikers in het onderwerpgebied. Met behulp van het ER-model, de datadictionary en gevestigde relaties tussen primaire en externe sleutels wordt getracht alle benodigde bewerkingen voor gegevenstoegang handmatig uit te voeren. Als een handmatige bewerking uitvalt, is het samengestelde logische datamodel ontoereikend en bevat het fouten die moeten worden geëlimineerd. Misschien houden ze verband met een hiaat in het model van een entiteit, relatie of attribuut.

5. Bepaling van vereisten voor ondersteuning van gegevensintegriteit en hun documentatie. Deze vereisten zijn beperkingen die zijn ingesteld om te voorkomen dat tegenstrijdige gegevens in de database worden ingevoerd. In deze stap worden problemen met gegevensintegriteit behandeld, ongeacht specifieke aspecten van de implementatie ervan. De volgende soorten beperkingen moeten worden overwogen:

  • vereiste data. Uitzoeken of er attributen zijn die geen NULL-waarden kunnen hebben;
  • beperkingen op attribuutwaarden. Geldige waarden voor attributen zijn gedefinieerd;
  • integriteit van de entiteit. Het wordt bereikt als de primaire sleutel van de entiteit geen NULL-waarden bevat;
  • referentiële integriteit. Het is duidelijk dat de waarde van de externe sleutel aanwezig moet zijn in de primaire sleutel van een van de tabelrijen voor de bovenliggende entiteit;
  • beperkingen opgelegd door bedrijfsregels. In het geval van het BANK-project kan bijvoorbeeld een regel worden aangenomen die de klant verbiedt om bijvoorbeeld meer dan drie rekeningen te beheren.

Informatie over alle vastgelegde gegevensintegriteitsbeperkingen wordt in de datadictionary geplaatst.

6. Creatie van de definitieve versie van het logisch datamodel en bespreking met gebruikers. Deze stap bereidt de definitieve versie voor van het ER-model, dat het logische gegevensmodel vertegenwoordigt. Het model zelf en de bijgewerkte documentatie, inclusief de datadictionary en het linkschema van de relationele tabel, worden gepresenteerd ter beoordeling en analyse door gebruikers, die ervoor moeten zorgen dat het het onderwerp nauwkeurig weergeeft.

2.3. Fysiek ontwerp

Het doel van de fysieke ontwerpfase is het beschrijven van een specifieke implementatie van een database die zich in het externe geheugen van een computer bevindt. Dit is een beschrijving van de gegevensopslagstructuur en efficiënte methoden om toegang te krijgen tot databasegegevens. Bij logisch ontwerp beantwoorden ze de vraag - wat moet er gebeuren, en bij fysiek ontwerp - wordt een manier gekozen om het te doen. De fysieke ontwerpprocedures zijn als volgt.

1. Databasetabellen ontwerpen met behulp van het geselecteerde DBMS. Een relationeel DBMS wordt geselecteerd om te worden gebruikt om een ​​database te maken die wordt gehost op machinemedia. De functionaliteit voor het ontwerpen van tabellen is grondig bestudeerd. Vervolgens wordt het ontwerp van tabellen en het schema van hun verbinding in de DBMS-omgeving uitgevoerd. Het voorbereide databaseproject wordt beschreven in de bijbehorende documentatie.

2. Implementatie van bedrijfsregels in de omgeving van het geselecteerde DBMS. Het bijwerken van informatie in tabellen kan worden beperkt door bedrijfsregels. De manier waarop ze worden geïmplementeerd, is afhankelijk van het gekozen DBMS. Sommige systemen voor het implementeren van de vereisten van het vakgebied bieden meer functies, andere minder. In sommige systemen is er helemaal geen ondersteuning voor het implementeren van bedrijfsregels. In dit geval worden applicaties ontwikkeld om hun beperkingen te implementeren.

Alle beslissingen die worden genomen in het kader van de implementatie van domeinbedrijfsregels worden in detail beschreven in de bijbehorende documentatie.

3. Ontwerpen van de fysieke organisatie van de database. Deze stap selecteert de beste bestandsorganisatie voor de tabellen. De transacties die zullen worden uitgevoerd in de database die wordt ontworpen, worden geïdentificeerd en de belangrijkste worden gemarkeerd. Transactiedoorvoer wordt geanalyseerd - het aantal transacties dat binnen een bepaald tijdsinterval kan worden verwerkt, en reactietijd - de tijd die nodig is om één transactie te voltooien. Ze streven ernaar om de transactiedoorvoer te verhogen en de reactietijd te verkorten.

Op basis van deze indicatoren worden beslissingen genomen om de prestaties van de database te optimaliseren door indexen in tabellen te definiëren die de selectie van gegevens uit de database versnellen, of door de vereisten voor het niveau van tabelnormalisatie te verminderen. De benodigde schijfruimte voor de gemaakte database wordt geschat. Probeer het te minimaliseren.

Beslissingen die over de bovenstaande kwesties zijn genomen, worden gedocumenteerd.

4. Ontwikkeling van een strategie voor databasebeveiliging. De database is een waardevol bedrijfsmiddel en er wordt veel aandacht besteed aan de bescherming ervan. Om dit te doen, moeten ontwerpers een volledig en duidelijk begrip hebben van alle beveiligingen die door het geselecteerde DBMS worden geboden.

5. Organisatie van de monitoring van de werking van de database en de bijsturing ervan. Na de creatie van het fysieke project van de database, wordt een continue monitoring van de werking ervan georganiseerd. De resulterende informatie over het prestatieniveau van de database wordt gebruikt om deze af te stemmen. Hierbij worden ook de middelen van het geselecteerde DBMS betrokken.

Beslissingen om wijzigingen aan te brengen in een functionerende database moeten grondig worden overwogen en afgewogen.