Belangrijkste fasen van databaseontwikkeling. Stadia van databaseontwikkeling

Databaseontwerp

Fasen voor databaseontwerp:

1. Systeemanalyse en verbale beschrijving van informatieobjecten van het vakgebied en de verbindingen daartussen.

2. Semantische modellering van een vakgebied – een gedeeltelijk geformaliseerde beschrijving van objecten van een vakgebied in termen van een semantisch model, bijvoorbeeld een ER-model.

3. Een standaard DBMS selecteren.

4. Logisch ontwerp van de database, dat wil zeggen beschrijving van de database in termen van het geaccepteerde datamodel. In dit stadium worden het aantal en de structuur van de tabellen bepaald, worden er zoekopdrachten naar de database gegenereerd, worden de typen rapportagedocumenten bepaald, worden er algoritmen voor informatieverwerking ontwikkeld, worden er formulieren voor het invoeren en bewerken van gegevens gemaakt, enz.

5. Fysiek ontwerp van de database, dat wil zeggen de keuze voor een effectieve plaatsing van de database op externe media om maximale prestaties bij het verwerken van gegevens te garanderen.

4.2 Entiteit-relatiemodel (ER-model)

Essence– dit is een object van de echte wereld dat onafhankelijk kan bestaan. De entiteit heeft kopieën, die van elkaar verschillen in attribuutwaarden en een ondubbelzinnige identificatie mogelijk maken. Attribuut is een benoemd kenmerk van een entiteit. Bijvoorbeeld entiteit Boek gekenmerkt door attributen als auteur, titel, uitgever, enz. Specifieke boeken zijn voorbeelden van een entiteit Boek. Ze verschillen in de waarden van de opgegeven attributen en worden uniek geïdentificeerd door het attribuut “name”. Een attribuut dat op unieke wijze exemplaren van een entiteit identificeert, wordt aangeroepen sleutel. De sleutel kan zijn composiet, die een combinatie van verschillende attributen vertegenwoordigt.

Laten we aannemen dat er een database wordt ontworpen voor het vakgebied BANK. Het heeft vestigingen die worden beheerd door managers. Klanten hebben verschillende soorten rekeningen: lopende, dringende, vraagrekeningen, enz., die in de filialen worden verwerkt. Op vakgebied zijn vier entiteiten te onderscheiden: Vestiging, Manager, Account, Klant.

In een ER-diagram wordt een entiteit weergegeven door een rechthoek met daarin de naam, bijvoorbeeld:

Verbinding vertegenwoordigt de interactie tussen entiteiten. Het is gekarakteriseerd vermogen (graad van aansluiting), die laat zien hoeveel entiteiten bij de relatie betrokken zijn. De relatie tussen twee entiteiten wordt genoemd binair. Op een ER-diagram wordt de relatie weergegeven als een ruit, bijvoorbeeld:

Binnen het vakgebied BANK zijn 3 verbanden te onderscheiden:

1. Manager geeft leiding aan het filiaal

2. Filiaal verwerkt factuur

3. Klant heeft een account

Een belangrijk kenmerk van communicatie is verbindingstype (veelvoud). Laten we eens kijken naar de typen van de bovenstaande verbindingen. Omdat één manager slechts één filiaal beheert, is de 1e relatie van het type één-op-één (1:1).

Omdat één filiaal meerdere facturen verwerkt en elke factuur slechts door één filiaal wordt verwerkt, is de tweede relatie een één-op-veel-relatie (1:M).

Omdat één account door meerdere klanten kan worden gedeeld en één klant meerdere accounts kan hebben, is de derde relatie een veel-op-veel-relatie (M:N).

Mate van deelname bepaalt of alle of slechts enkele exemplaren van een entiteit bij de relatie betrokken zijn. Misschien wel verplicht of optioneel.

Als niet elke instantie van entiteit A geassocieerd is met enige instantie van entiteit B, dan is de mate van deelname van entiteit A dat wel optioneel. Dit wordt in het ER-diagram weergegeven door een zwarte cirkel op de communicatielijn nabij entiteit A.

Als elke instantie van entiteit A geassocieerd is met een instantie van entiteit B, dan is de mate van deelname van entiteit A dat ook verplicht. In dit geval wordt in het ER-diagram een zwarte cirkel op de communicatielijn in een rechthoek naast entiteit A geplaatst. Bijvoorbeeld communicatie Medewerker registreert klanten heeft type (1:M). In dit geval registreert niet iedere medewerker cliënten (optionele deelname), maar wordt iedere cliënt geregistreerd door een medewerker (verplichte deelname):

Laten we aannemen dat in het onderhavige BANK-onderwerp de mate van participatie van alle vier de entiteiten verplicht is. Het ER-model ziet er dan als volgt uit:

Elk van de vier modelentiteiten kan worden beschreven door zijn eigen set attributen.

Een ER-model kan, samen met sets entiteitsattributen, dienen als voorbeeld van een semantisch (conceptueel) model van een domein of een conceptueel databaseschema.

Bij het ontwikkelen van een database kunnen de volgende werkfasen worden onderscheiden.

Fase I. Formulering van het probleem.

In dit stadium wordt een taak voor het maken van een database gegenereerd. Het beschrijft in detail de samenstelling van de database, het doel en het doel van de oprichting ervan, en vermeldt ook welke soorten werk in deze database moeten worden uitgevoerd (selectie, toevoeging, wijzigen van gegevens, afdrukken of uitvoeren van een rapport, enz. ).

Fase II. Objectanalyse.

In deze fase bekijken we uit welke objecten de database kan bestaan en wat de eigenschappen van deze objecten zijn. Nadat de database in afzonderlijke objecten is verdeeld, is het noodzakelijk om de eigenschappen van elk van deze objecten in overweging te nemen, of, met andere woorden, om vast te stellen welke parameters elk object beschrijven. Al deze informatie kan worden gerangschikt in de vorm van afzonderlijke records en tabellen. Vervolgens moeten we rekening houden met het gegevenstype van elke individuele recordeenheid. Informatie over gegevenstypen moet ook worden opgenomen in de tabel die u maakt.

Fase III. Modelsynthese.

In dit stadium is het op basis van de bovenstaande analyse noodzakelijk om een specifiek databasemodel te selecteren. Vervolgens worden de voor- en nadelen van elk model overwogen en vergeleken met de vereisten en doelstellingen van de database die wordt gemaakt. Na een dergelijke analyse wordt een model geselecteerd dat de uitvoering van de taak het beste kan garanderen. Nadat u een model heeft gekozen, moet u het diagram tekenen dat de relaties tussen tabellen of knooppunten aangeeft.

Fase IV. Methoden selecteren voor het presenteren van informatie en softwaretools.

Na het maken van het model is het noodzakelijk, afhankelijk van het geselecteerde softwareproduct, de vorm van informatiepresentatie te bepalen.

In de meeste DBMS'en kunnen gegevens in twee vormen worden opgeslagen:

gebruik van formulieren;

zonder gebruik te maken van formulieren.

Een formulier is een door de gebruiker gemaakte grafische interface voor het invoeren van gegevens in een database.

V-fase. Synthese van een computermodel van een object.

Bij het maken van een computermodel zijn er enkele fasen die typerend zijn voor elk DBMS.

Fase 1. Het DBMS starten, een nieuw databasebestand maken of een eerder gemaakte database openen.

Fase 2: Maak de eerste tabel of tabellen.

Wanneer u de brontabel maakt, moet u de naam en het type van elk veld opgeven. Veldnamen mogen niet binnen dezelfde tabel worden herhaald. Terwijl u met de database werkt, kunt u nieuwe velden aan de tabel toevoegen. De gemaakte tabel moet worden opgeslagen, waarbij deze een naam krijgt die uniek is binnen de database die wordt gemaakt.

1. Informatie in de tabel mag niet worden gedupliceerd. Er mogen geen herhalingen tussen tabellen voorkomen. Wanneer bepaalde informatie slechts in één tabel is opgeslagen, hoeft deze maar op één plek te worden gewijzigd. Dit maakt het werk efficiënter en elimineert ook de mogelijkheid van niet-overeenkomende informatie in verschillende tabellen. Eén tabel moet bijvoorbeeld klantadressen en telefoonnummers bevatten.
2. Elke tabel mag informatie over slechts één onderwerp bevatten. Informatie over elk onderwerp is veel gemakkelijker te verwerken als deze is opgenomen in tabellen die onafhankelijk van elkaar zijn. Zo is het beter om klantadressen en bestellingen in verschillende tabellen op te slaan, zodat bij het verwijderen van een bestelling informatie over de klant in de database blijft staan.
3. Elke tabel moet de verplichte velden bevatten. Elk veld in de tabel moet afzonderlijke informatie bevatten over het onderwerp van de tabel. Een klantgegevenstabel kan bijvoorbeeld velden bevatten voor bedrijfsnaam, adres, stad, land en telefoonnummer. Wanneer u velden voor elke tabel ontwerpt, moet u er rekening mee houden dat elk veld gerelateerd moet zijn aan het onderwerp van de tabel. Het wordt niet aanbevolen om gegevens in een tabel op te nemen die het resultaat zijn van een expressie. De tabel moet alle benodigde informatie bevatten. Informatie moet worden opgesplitst in de kleinste logische eenheden (bijvoorbeeld de velden Voornaam en Achternaam, in plaats van een algemeen veld Voornaam).
4. De database moet een primaire sleutel hebben. Dit is nodig zodat het DBMS gegevens uit verschillende tabellen kan koppelen, bijvoorbeeld klantgegevens en zijn bestellingen.

Fase 3. Creatie van schermformulieren.

In eerste instantie moet u de tabel opgeven op basis waarvan het formulier zal worden gemaakt. U kunt het aanmaken met behulp van de formulierwizard, waarbij u aangeeft welk type het moet hebben, of u kunt het zelf maken. Wanneer u een formulier maakt, kunt u niet alle velden in de tabel opgeven, maar slechts enkele. De naam van het formulier kan dezelfde zijn als de naam van de tabel waarin het is gemaakt. Op basis van één tabel kunt u meerdere formulieren maken, die kunnen verschillen in het type of aantal velden dat uit deze tabel wordt gebruikt. Nadat u het formulier heeft gemaakt, moet u het opslaan. Het gemaakte formulier kan worden bewerkt door de locatie, grootte en indeling van de velden te wijzigen.

Fase 4. Het invullen van de database.

Het proces van het invullen van de database kan in twee vormen worden uitgevoerd: in de vorm van een tabel en in de vorm van een formulier. Numerieke velden en tekstvelden kunnen als tabel worden ingevuld, en MEMO- en OLE-velden kunnen als formulier worden ingevuld.

Fase VI. Werken met de aangemaakte database.

Het werken met de database omvat de volgende acties:

het zoeken naar de benodigde informatie;

gegevens sorteren;

gegevensselectie;

afdrukken;

gegevens wijzigen en toevoegen.

De creatie en implementatie van moderne informatiesystemen van geautomatiseerde databases brengt nieuwe ontwerpproblemen met zich mee die niet met traditionele technieken en methoden kunnen worden opgelost. Er moet veel aandacht worden besteed aan problemen met het ontwerpen van databases. De effectiviteit van het systeem als geheel, de levensvatbaarheid ervan en de mogelijkheid van uitbreiding en verdere ontwikkeling hangen af van hoe succesvol de database is ontworpen. Daarom wordt de kwestie van databaseontwerp geïdentificeerd als een afzonderlijk, onafhankelijk werkgebied bij de ontwikkeling van informatiesystemen.

Databaseontwerp is een iteratief, meerfasig proces van het nemen van weloverwogen beslissingen tijdens het analyseren van het informatiemodel van het vakgebied, de gegevensvereisten van applicatieprogrammeurs en gebruikers, het synthetiseren van logische en fysieke gegevensstructuren, het analyseren en rechtvaardigen van de keuze van software en hardware. De fasen van databaseontwerp houden verband met de organisatie van gegevens op meerdere niveaus. Bij het overwegen van de kwestie van databaseontwerp zullen we ons houden aan een dergelijke presentatie van gegevens op meerdere niveaus: extern, infologisch, logisch (datalogisch) en intern.

Deze representatie van datalagen is niet de enige. Er zijn andere opties voor gegevenspresentatie op meerdere niveaus. In overeenstemming met de voorstellen van de onderzoeksgroep op het gebied van datamanagementsystemen van het American National Standards Institute ANSI/X3/SPARC, evenals CODASYL (Conference on Data Systems Languages), zijn er in de regel drie niveaus van datapresentatie :

· extern niveau (vanuit het standpunt van de eindgebruiker en applicatieprogrammeur),
· conceptueel niveau (vanuit DBMS-oogpunt),
· interieur niveau (vanuit het standpunt van een systeemprogrammeur).

In overeenstemming met dit concept is de externe laag een onderdeel (subset) van het conceptuele model dat nodig is om elk verzoek of applicatieprogramma te implementeren. Dat wil zeggen, als een conceptueel model fungeert als een schema dat wordt ondersteund door een specifiek DBMS, dan is het externe niveau een bepaalde reeks subcircuits die nodig zijn om een specifiek toepassingsprogramma of gebruikersverzoek te implementeren.

Er is ook een ander gezichtspunt, volgens welke het externe niveau wordt opgevat als meer algemene concepten die verband houden met de studie en analyse van informatiestromen van het vakgebied en hun structurering. Sommige auteurs introduceren een hulpniveau (tussen het externe en datalogische niveau), dat infologisch wordt genoemd. Het kan fungeren als een onafhankelijk niveau of een integraal onderdeel zijn van het externe niveau.

Dit concept is geschikter vanuit het oogpunt van het begrijpen van het databaseontwerpproces. Daarom zullen we het infologische niveau beschouwen als een onafhankelijk niveau van gegevenspresentatie. Het externe niveau fungeert in dit geval als een afzonderlijke ontwerpfase, waarin alle niet-machine-informatieondersteuning wordt bestudeerd, dat wil zeggen vormen van documentatie en presentatie van gegevens, evenals de externe omgeving waarin de databank zal opereren in termen van van methoden voor het vastleggen, verzamelen en verzenden van informatie naar de databasegegevens.

Bij het ontwerpen van een database op extern niveau het is noodzakelijk om de werking van het besturingsobject waarvoor de database wordt ontworpen, alle primaire en outputdocumentatie, te bestuderen vanuit het oogpunt van het bepalen welke gegevens in de database moeten worden opgeslagen. Het externe niveau is in de regel een verbale beschrijving van invoer- en uitvoerberichten, evenals gegevens die in de database moeten worden opgeslagen. De beschrijving van het externe niveau sluit de aanwezigheid van elementen van duplicatie, redundantie en inconsistentie van gegevens niet uit. Om deze afwijkingen en tegenstrijdigheden in de externe beschrijving van gegevens te elimineren, wordt daarom infologisch ontwerp uitgevoerd.

Een informatiemodel is een middel om een vakgebied te structureren en het concept van datasemantiek te begrijpen. Het informatiemodel kan vooral worden beschouwd als een middel om de presentatievorm van informatiebehoeften te documenteren en te structureren, wat zorgt voor consistente communicatie tussen gebruikers en systeemontwikkelaars.

Alle externe representaties worden geïntegreerd op het infologische niveau, waar een infologisch (canoniek) datamodel wordt gevormd, dat niet eenvoudigweg een som is van externe datarepresentaties.

Infologisch niveau is een informatielogisch model (ILM) van het onderwerpgebied, waarbij gegevensredundantie is uitgesloten en de informatiekenmerken van het beheerobject worden weergegeven zonder rekening te houden met de kenmerken en details van een bepaald DBMS. Dat wil zeggen dat de infologische presentatie van gegevens primair gericht is op de persoon die de database ontwerpt of gebruikt.

Logisch (conceptueel) het niveau wordt gebouwd rekening houdend met de specifieke kenmerken en kenmerken van een bepaald DBMS. Dit niveau van gegevenspresentatie is meer gericht op computerverwerking en de programmeurs die deze ontwikkelen. Op dit niveau wordt een conceptueel datamodel gevormd, dat wil zeggen een speciaal gestructureerd model van het vakgebied dat voldoet aan de kenmerken en beperkingen van het geselecteerde DBMS. Het logische niveaumodel, ondersteund door middel van een specifiek DBMS, wordt ook wel datalogisch genoemd.

Infologische en datalogische modellen, die het model van één vakgebied weerspiegelen, zijn van elkaar afhankelijk. Het infologische model kan eenvoudig worden omgezet in een datalogisch model.

Intern niveau geassocieerd met de fysieke plaatsing van gegevens in het computergeheugen. Op dit niveau wordt een fysiek model van de database gevormd, dat structuren omvat voor het opslaan van gegevens in het computergeheugen, incl. beschrijving van recordformaten, de volgorde van hun logische of fysieke rangschikking, plaatsing per apparaattype, evenals kenmerken en paden om toegang te krijgen tot gegevens. De volgende kenmerken van het functioneren van de database zijn afhankelijk van de parameters van het fysieke model: geheugenvolume en systeemresponstijd. De fysieke parameters van de database kunnen tijdens de werking ervan worden gewijzigd om de efficiëntie van het systeem te vergroten. Het veranderen van fysieke parameters bepaalt niet vooraf de noodzaak om de informatie- en datamodellen te veranderen. Het diagram van de relatie tussen de niveaus van gegevenspresentatie in de database wordt getoond in figuur 1.1. De database is ontworpen in overeenstemming met deze niveaus. Databaseontwerp is een complex en tijdrovend proces dat de betrokkenheid van veel hooggekwalificeerde specialisten vereist. De prestaties van het informatiesysteem en de volledigheid van het voldoen aan de functionele behoeften van gebruikers en applicatieprogramma's zijn afhankelijk van hoe goed de database is ontworpen. Een slecht ontworpen database kan het ontwikkelingsproces bemoeilijken

applicatiesoftware maken het gebruik van complexere logica noodzakelijk, wat op zijn beurt de responstijd van het systeem zal vergroten, en in de toekomst kan leiden tot de noodzaak om het logische databasemodel opnieuw te ontwerpen. Het herstructureren of aanbrengen van wijzigingen in het logische databasemodel is een zeer ongewenst proces, omdat het de noodzaak veroorzaakt voor wijziging of zelfs herprogrammering van individuele taken. Al het werk dat in elke ontwerpfase wordt uitgevoerd, moet worden geïntegreerd met de datadictionary. Elke ontwerpfase wordt beschouwd als een bepaalde reeks iteratieve procedures, waardoor een bepaald databasemodel ontstaat.

Rijst. 1.1.

Het externe niveau is de voorbereidende fase van infologisch ontwerp.

Het doel van ontwerp op extern niveau is het ontwikkelen van niet-machine-informatieondersteuning, waaronder een systeem van invoer (primaire) documentatie die een bepaald onderwerpgebied karakteriseert, een systeem voor het classificeren en coderen van technische en economische informatie, evenals een lijst met overeenkomstige uitvoerberichten die moeten worden gegenereerd met behulp van BnD.

Er zijn twee benaderingen voor het ontwerpen van databases op extern niveau: ‘domeingebaseerd’ en ‘querygestuurd’. De “domeingebaseerde” aanpak bestaat uit het vormen van externe informatieondersteuning voor het gehele vakgebied, zonder rekening te houden met de behoeften van gebruikers en applicatieprogramma's. Soms wordt deze aanpak ook objectgebaseerd of niet-process genoemd.

Bij de ‘from request’-benadering is de belangrijkste bron van informatie over het vakgebied het onderzoek naar gebruikersverzoeken en de behoeften van applicatieprogramma’s. Deze aanpak wordt ook wel proces- of functioneel genoemd. Met deze aanpak is de database ontworpen om huidige beheertaken uit te voeren zonder rekening te houden met de mogelijkheid van systeemuitbreiding en de opkomst van nieuwe beheertaken. Het voordeel van de 'onderwerpdomein'-benadering is de objectiviteit, de consistentie bij het weergeven van software en de stabiliteit van het informatiemodel, de mogelijkheid om een groot aantal applicatieprogramma's en queries te implementeren, inclusief de ongeplande programma's en queries bij het maken van een database. Het nadeel van deze aanpak is de aanzienlijke hoeveelheid werk die moet worden gedaan bij het bepalen van de informatie die in de database moet worden opgeslagen, wat dienovereenkomstig de ontwikkelingstijd van het project compliceert en verlengt.

De functionele aanpak is gericht op het implementeren van de huidige eisen van gebruikers en applicatieprogramma's zonder rekening te houden met de vooruitzichten voor de ontwikkeling van het systeem. Bij gebruik ervan kunnen er problemen optreden bij het samenvoegen van de vereisten van verschillende gebruikers en applicatieprogramma's. Met deze aanpak worden de ontwerpinspanningen echter aanzienlijk verminderd, en daarom is het mogelijk een systeem met hoge prestatiekenmerken te creëren. Afzonderlijk gezien kan geen van deze methoden echter voldoende informatie verschaffen om een rationele databasestructuur te ontwerpen. Daarom is het raadzaam om bij het ontwerpen van een database deze twee benaderingen samen te gebruiken. Als we ons het databaseontwerpproces op extern niveau schematisch voorstellen, bestaat het uit de volgende werken.

1. Bepaling van functionele problemen van het vakgebied die onderworpen zijn aan een geautomatiseerde oplossing. Aangezien het hoofddoel van het creëren van een database is om gegevensverwerkingsfuncties van informatie te voorzien, is het allereerst noodzakelijk om alle functies van het vakgebied (controleobject) waarvoor de database wordt ontwikkeld te bestuderen en hun kenmerken te analyseren. . De functies en functionele kenmerken van een beheerobject moeten worden bestudeerd in onlosmakelijk verband met het onderzoek naar functionele gegevensbehoeften van toekomstige gebruikers van het informatiesysteem. Studie en analyse omvatten het identificeren van informatiebehoeften en het bepalen van informatiestromen. Dit werk kan worden gedaan door het vakgebied te onderzoeken en de medewerkers ervan te bevragen. Het resultaat van zo’n onderzoek kan een lijst met functionele taken zijn die geautomatiseerd moeten worden opgelost met behulp van een database.
2. Studie en analyse van operationele primaire documenten. Nadat we de functies hebben bestudeerd en de lijst met functionele taken hebben bepaald die het onderwerp zijn van een geautomatiseerde oplossing, gaan we over tot de studie van operationele documenten die worden gebruikt bij de invoer van elke taak of hun complex. Nadat ze alle operationele documenten (zowel extern als intern) die bij de invoer van elke taak worden gebruikt, hebben bestudeerd en geanalyseerd, bepalen ze welke details van deze documenten in de database moeten worden opgeslagen.
3. Studie van normatieve en referentiedocumenten. In de derde stap wordt alle regelgevings- en referentiedocumentatie bestudeerd en geanalyseerd. Dergelijke documentatie omvat verschillende classificaties, schattingen, contracten, regelgeving, wetgevingshandelingen op het gebied van belastingbeleid, planningsdocumentatie, enz. De distributie en afzonderlijke analyse van operationele en regelgevende informatie zijn technologisch bepaald. Databases verschillen in de technologieën voor het creëren en onderhouden van bestanden met voorwaardelijk permanente informatie in normatieve en referentiedocumentatie, en bestanden met operationele informatie.
4. Studie van de processen van het omzetten van invoerberichten in uitvoerberichten.

Allereerst worden alle uitgangsberichten die worden afgedrukt of weergegeven, bestudeerd en in de vorm van uitgangsarrays op de MD opgeslagen. Dit is nodig om te bepalen welke attributen van de invoerberichten in de database moeten worden opgeslagen om uitvoerberichten te ontvangen. Bovendien worden in dit stadium de indicatoren bepaald die worden verkregen tijdens de oplossing van het probleem als resultaat van het uitvoeren van bepaalde berekeningen. Voor elke berekende indicator moet u het algoritme voor de vorming ervan bepalen en ervoor zorgen dat deze indicator kan worden verkregen op basis van de attributen van operationele en regelgevende informatie die in de tweede en derde stap zijn bepaald. Als bepaalde gegevens niet voldoende zijn om de berekeningen te voltooien, is het noodzakelijk om terug te gaan, aanvullend onderzoek uit te voeren en

bepaal waar en op welke manier je de ontbrekende attributen kunt verkrijgen. Bovendien moet u beslissen welke van de berekende indicatoren geschikt zijn om in de database op te slaan. Indicatoren verkregen door berekening worden in de regel niet in de database opgeslagen. De uitzondering zijn gevallen waarin de berekende indicator moet worden gebruikt om andere problemen of voor deze taak op te lossen, maar in de volgende kalenderperioden.

Bij het uitvoeren van ontwerpwerkzaamheden op extern niveau moet er rekening mee worden gehouden dat het voor het uitvoeren van bepaalde functies in de database noodzakelijk is om aanvullende gegevens op te slaan die niet in documenten worden weergegeven (kalendergegevens, statistische gegevens, enz. .). Een algemeen diagram van het proces van het bestuderen van documenten en gegevens tijdens het ontwerp op extern niveau wordt getoond in figuur 1.2.

Afb.1.2.

Een dergelijk onderzoek moet worden uitgevoerd voor elke functionele taak of elk complex van taken dat met behulp van de database zal worden opgelost.

Het resultaat van het ontwerp op extern niveau zal een lijst zijn met attributen (details) van operationele en voorwaardelijk permanente informatie die in de database moet worden opgeslagen, met vermelding van de bronnen van hun ontvangst en de vorm van presentatie.

Deze lijst sluit echter de mogelijkheid van redundantie, duplicatie, inconsistentie en andere tekortkomingen daarin niet uit. Daarom eindigt het proces hier niet, maar wordt er een overgang naar de fase van informatieontwerp uitgevoerd.

Bij het ontwikkelen van een database kunnen de volgende werkfasen worden onderscheiden.

Fase I. Formulering van het probleem.

Fase II. Objectanalyse.

Fase III. Modelsynthese.

Fase IV. Methoden selecteren voor het presenteren van informatie en softwaretools.

Na het maken van het model is het noodzakelijk, afhankelijk van het geselecteerde softwareproduct, de vorm van informatiepresentatie te bepalen.

In de meeste DBMS'en kunnen gegevens in twee vormen worden opgeslagen:

gebruik van formulieren;
zonder gebruik te maken van formulieren.

Formulier is een door de gebruiker gemaakte grafische interface voor het invoeren van gegevens in de database.

V-fase. Synthese van een computermodel van een object.

Bij het maken van een computermodel zijn er enkele fasen die typerend zijn voor elk DBMS.

Fase 1. Het DBMS starten, een nieuw databasebestand maken of een eerder gemaakte database openen.

Stage 2. Maak de eerste tabel of tabellen.

1. Informatie in de tabel mag niet worden gedupliceerd. Er mogen geen herhalingen tussen tabellen voorkomen. Wanneer bepaalde informatie slechts in één tabel is opgeslagen, hoeft deze maar op één plek te worden gewijzigd. Dit maakt het werk efficiënter en elimineert ook de mogelijkheid van niet-overeenkomende informatie in verschillende tabellen. Eén tabel moet bijvoorbeeld klantadressen en telefoonnummers bevatten.

2. Elke tabel mag informatie over slechts één onderwerp bevatten. Informatie over elk onderwerp is veel gemakkelijker te verwerken als deze is opgenomen in tabellen die onafhankelijk van elkaar zijn. Zo is het beter om klantadressen en bestellingen in verschillende tabellen op te slaan, zodat bij het verwijderen van een bestelling informatie over de klant in de database blijft staan.

3. Elke tabel moet de verplichte velden bevatten. Elk veld in de tabel moet afzonderlijke informatie bevatten over het onderwerp van de tabel. Een klantgegevenstabel kan bijvoorbeeld velden bevatten voor bedrijfsnaam, adres, stad, land en telefoonnummer. Wanneer u velden voor elke tabel ontwerpt, moet u er rekening mee houden dat elk veld gerelateerd moet zijn aan het onderwerp van de tabel. Het wordt niet aanbevolen om gegevens in een tabel op te nemen die het resultaat zijn van een expressie. De tabel moet alle benodigde informatie bevatten. Informatie moet worden opgesplitst in de kleinste logische eenheden (bijvoorbeeld de velden Voornaam en Achternaam, in plaats van een algemeen veld Voornaam).

4. De database moet een primaire sleutel hebben. Dit is nodig zodat het DBMS gegevens uit verschillende tabellen kan koppelen, bijvoorbeeld klantgegevens en zijn bestellingen.

Fase 3. Schermformulieren maken.

Fase 4. Het vullen van de database.

Fase VI. Werken met de aangemaakte database.

Het werken met de database omvat de volgende acties:

het zoeken naar de benodigde informatie;
gegevens sorteren;
gegevensselectie;
afdrukken;
gegevens wijzigen en toevoegen.

De essentie van databaseontwerp is, net als elk ander ontwerpproces, het creëren van een beschrijving van een nieuw systeem dat nog niet eerder in deze vorm heeft bestaan en dat, wanneer het wordt geïmplementeerd, naar verwachting onder de juiste omstandigheden kan functioneren. Hieruit volgt dat de fasen van het databaseontwerp op consistente en logische wijze de essentie van dit proces moeten weerspiegelen.

Inhoud van databaseontwerp en fasering

De ontwerpintentie is gebaseerd op een geformuleerde sociale behoefte. Deze behoefte heeft een omgeving waarin deze zich kan voordoen en een doelgroep van consumenten die het ontwerpresultaat zullen gebruiken. Bijgevolg begint het databaseontwerpproces met het bestuderen van een bepaalde behoefte vanuit het standpunt van consumenten en de functionele omgeving van de beoogde plaatsing ervan. Dat wil zeggen dat de eerste fase bestaat uit het verzamelen van informatie en het definiëren van een model van het onderwerpgebied van het systeem, en het bekijken ervan vanuit het gezichtspunt van de doelgroep. Om de systeemvereisten te bepalen, worden over het algemeen de reikwijdte van de activiteiten en de grenzen van databaseapplicaties bepaald.

Vervolgens verduidelijkt de ontwerper, die al bepaalde ideeën heeft over wat hij moet maken, de taken die zogenaamd door de applicatie zijn opgelost, maakt er een lijst van (vooral als de projectontwikkeling een grote en complexe database is), verduidelijkt de volgorde van het oplossen problemen en voert data-analyse uit. Zo'n proces is ook een gefaseerd ontwerpwerk, maar gewoonlijk worden deze stappen in de ontwerpstructuur geabsorbeerd door de conceptuele ontwerpfase - de fase van het identificeren van objecten, attributen en verbindingen.

Het creëren van een conceptueel (informatiemodel) omvat de voorlopige vorming van conceptuele gebruikersvereisten, inclusief vereisten voor applicaties die mogelijk niet onmiddellijk worden geïmplementeerd, maar waarbij rekening wordt gehouden met de functionaliteit van het systeem in de toekomst. Het conceptuele model, dat zich bezighoudt met representaties van set-abstractieobjecten (zonder fysieke opslagmethoden te specificeren) en hun relaties, komt in essentie overeen met het domeinmodel. Daarom wordt in de literatuur de eerste fase van databaseontwerp infologisch ontwerp genoemd.

Vervolgens volgt een afzonderlijke fase (of een aanvulling op de vorige) de fase van het vormen van vereisten voor de besturingsomgeving, waarbij de vereisten voor computerbronnen die de werking van het systeem kunnen garanderen, worden beoordeeld. Dienovereenkomstig geldt: hoe groter het volume van de ontworpen database, hoe hoger de gebruikersactiviteit en intensiteit van verzoeken, hoe hoger de vereisten voor bronnen: voor de computerconfiguratie, voor het type en de versie van het besturingssysteem. Het gebruik van een toekomstige database door meerdere gebruikers vereist bijvoorbeeld een netwerkverbinding met behulp van een besturingssysteem dat geschikt is voor multitasking.

De volgende stap is dat de ontwerper een databasebeheersysteem (DBMS) en softwaretools selecteert. Hierna moet het conceptuele model worden overgebracht naar een datamodel dat compatibel is met het geselecteerde managementsysteem. Maar vaak brengt dit het aanbrengen van wijzigingen en wijzigingen in het conceptuele model met zich mee, aangezien de onderlinge verbindingen tussen objecten die in het conceptuele model worden weerspiegeld niet altijd kunnen worden geïmplementeerd met behulp van de middelen van een bepaald DBMS.

Deze omstandigheid bepaalt de opkomst van de volgende fase: de opkomst van een conceptueel model voorzien van de middelen van een specifiek DBMS. Deze stap komt overeen met de fase van logisch ontwerp (het creëren van een logisch model).

Ten slotte is de laatste fase van het databaseontwerp het fysieke ontwerp: de fase waarin de logische structuur en de fysieke opslagomgeving met elkaar worden verbonden.

Zo worden de belangrijkste ontwerpfasen in gedetailleerde vorm gepresenteerd in de volgende fasen:

informatie ontwerp,
het opstellen van eisen voor de werkomgeving
selectie van besturingssysteem en databasesoftware,
logisch ontwerp,
fysiek ontwerp

De belangrijkste zullen hieronder in meer detail worden besproken.

Infologisch ontwerp

Identificatie van entiteiten vormt de semantische basis van infologisch ontwerp. Een entiteit is hier een object (abstract of concreet), waarover informatie in het systeem wordt verzameld. In het infologische model van het vakgebied worden de structuur en dynamische eigenschappen van het vakgebied beschreven in gebruiksvriendelijke termen die niet afhankelijk zijn van de specifieke implementatie van de database. Maar de termen worden op een standaardschaal genomen. Dat wil zeggen dat de beschrijving niet tot uitdrukking komt door individuele objecten van het onderwerpgebied en hun relaties, maar door:

beschrijving van objecttypen,
integriteitsbeperkingen die verband houden met het beschreven type,
processen die leiden tot de evolutie van een vakgebied – de overgang naar een andere staat.

Een informatiemodel kan worden gemaakt met behulp van verschillende methoden en benaderingen:

De functionele aanpak is gebaseerd op de toegewezen taken. Het wordt functioneel genoemd omdat het wordt gebruikt als de functies en taken bekend zijn van de personen die met behulp van de ontworpen database in hun informatiebehoeften zullen voorzien.
De onderwerpbenadering richt zich op informatie over de informatie die in de database zal worden opgenomen, ondanks het feit dat de zoekstructuur mogelijk niet is gedefinieerd. In dit geval richt onderzoek op een vakgebied zich op de meest adequate weergave ervan in de database in de context van het volledige scala aan verwachte informatieverzoeken.
Een geïntegreerde aanpak waarbij gebruik wordt gemaakt van de ‘entiteit-relatie’-methode combineert de voordelen van de vorige twee. De methode komt erop neer dat het hele vakgebied wordt opgedeeld in lokale delen, die afzonderlijk worden gemodelleerd en vervolgens opnieuw worden gecombineerd tot een heel gebied.

Omdat het gebruik van de ‘entiteit-relatie’-methode in dit stadium een gecombineerde ontwerpmethode is, wordt het meestal een prioriteit.

Wanneer ze methodisch verdeeld zijn, moeten lokale vertegenwoordigingen, indien mogelijk, informatie bevatten die voldoende zou zijn om een afzonderlijk probleem op te lossen of om aan de verzoeken van een bepaalde groep potentiële gebruikers te voldoen. Elk van deze gebieden bevat ongeveer 6-7 entiteiten en komt overeen met een afzonderlijke externe applicatie.

De afhankelijkheid van entiteiten komt tot uiting in hun indeling in sterk (basis, ouder) en zwak (kind). Een sterke entiteit (bijvoorbeeld een lezer in een bibliotheek) kan op zichzelf in de database bestaan, maar een zwakke entiteit (bijvoorbeeld het abonnement van deze lezer) is ‘verbonden’ aan een sterke en bestaat niet afzonderlijk.

Het is noodzakelijk om de concepten van "entiteitsinstantie" (een object dat wordt gekenmerkt door specifieke eigenschapswaarden) en het concept van "entiteitstype" te scheiden - een object dat wordt gekenmerkt door een gemeenschappelijke naam en een lijst met eigenschappen.

Voor elke individuele entiteit worden attributen (een reeks eigenschappen) geselecteerd, die, afhankelijk van het criterium, kunnen zijn:

identificerend (met een unieke waarde voor entiteiten van dat type, waardoor ze potentiële sleutels worden) of beschrijvend;
enkelwaardig of meerwaardig (met het juiste aantal waarden voor een entiteitsinstantie);
basis (onafhankelijk van andere attributen) of afgeleid (berekend op basis van de waarden van andere attributen);
eenvoudig (ondeelbaar uit één component) of samengesteld (gecombineerd uit meerdere componenten).

Hierna wordt het attribuut gespecificeerd, worden de verbindingen gespecificeerd in de lokale weergave (verdeeld in optioneel en verplicht) en worden de lokale weergaven samengevoegd. Als het aantal lokale gebieden maximaal 4-5 is, kunnen ze in één stap worden gecombineerd . Als het aantal toeneemt, vindt de binaire samenvoeging van gebieden in verschillende fasen plaats.

Tijdens deze en andere tussenfasen wordt het iteratieve karakter van ontwerp weerspiegeld, wat hier tot uiting komt in het feit dat het, om tegenstrijdigheden te elimineren, noodzakelijk is terug te keren naar de fase van het modelleren van lokale representaties voor verduidelijking en verandering (bijvoorbeeld om dezelfde namen van semantisch verschillende objecten of om integriteitsattributen op dezelfde attributen in verschillende toepassingen te coördineren).

Een besturingssysteem en databasesoftware selecteren

De praktische implementatie van het informatiesysteem is afhankelijk van de keuze van het databasemanagementsysteem. De belangrijkste criteria in het selectieproces zijn de volgende parameters:

type datamodel en de overeenstemming ervan met de behoeften van het vakgebied,
reserve aan mogelijkheden bij uitbreiding van het informatiesysteem,
prestatiekenmerken van het geselecteerde systeem,
operationele betrouwbaarheid en gemak van het DBMS,
tools gericht op personeel voor gegevensbeheer,
de kosten van het DBMS zelf en aanvullende software.

Fouten bij het kiezen van een DBMS zullen vrijwel zeker aanleiding geven tot de noodzaak om de conceptuele en logische modellen aan te passen.

Logisch databaseontwerp

De logische structuur van de database moet overeenkomen met het logische model van het vakgebied en rekening houden met de aansluiting van het datamodel met het ondersteunde DBMS. Daarom begint de fase met het kiezen van een datamodel, waarbij het belangrijk is om rekening te houden met de eenvoud en duidelijkheid ervan.

Het verdient de voorkeur wanneer de natuurlijke datastructuur samenvalt met het model dat deze representeert. Als de gegevens dus bijvoorbeeld in de vorm van een hiërarchische structuur worden gepresenteerd, is het beter om voor een hiërarchisch model te kiezen. In de praktijk wordt een dergelijke keuze echter vaak bepaald door het databasemanagementsysteem en niet zozeer door het datamodel. Daarom wordt het conceptuele model daadwerkelijk vertaald naar een datamodel dat compatibel is met het geselecteerde databasebeheersysteem.

Dit weerspiegelt ook de aard van het ontwerp, die de mogelijkheid (of noodzaak) biedt om terug te keren naar het conceptuele model om het te veranderen als de relaties tussen objecten (of objectattributen) die daarin worden weerspiegeld, niet kunnen worden geïmplementeerd met behulp van het gekozen DBMS.

Na voltooiing van de fase moeten databaseschema's van beide architectuurniveaus (conceptueel en extern) worden gegenereerd, gemaakt in de datadefinitietaal die wordt ondersteund door het geselecteerde DBMS.

Databaseschema's worden gevormd met behulp van een van de twee verschillende benaderingen:

of door gebruik te maken van een bottom-up benadering, waarbij het werk afkomstig is van de lagere niveaus van het definiëren van attributen, gegroepeerd in relaties die objecten vertegenwoordigen, gebaseerd op de relaties die bestaan tussen attributen;
of het gebruik van een omgekeerde, top-down benadering, gebruikt wanneer het aantal attributen aanzienlijk toeneemt (tot honderden en duizenden).

De tweede benadering omvat het identificeren van een aantal entiteiten op hoog niveau en hun relaties, met daaropvolgende detaillering tot het vereiste niveau, wat bijvoorbeeld tot uiting komt in een model dat is gemaakt op basis van de 'entiteitsrelatie'-methode. Maar in de praktijk worden beide benaderingen meestal gecombineerd.

Fysiek databaseontwerp

In de volgende fase van het fysieke ontwerp van de database wordt de logische structuur weergegeven in de vorm van een databaseopslagstructuur, dat wil zeggen gekoppeld aan de fysieke opslagomgeving waar de gegevens zo efficiënt mogelijk worden geplaatst. Hier wordt het dataschema gedetailleerd beschreven, waarbij alle typen, velden, maten en beperkingen worden aangegeven. Naast het ontwikkelen van indexen en tabellen worden basisquery's gedefinieerd.

De constructie van een fysiek model omvat het oplossen van grotendeels tegenstrijdige problemen:

taken van het minimaliseren van gegevensopslagruimte,
uitdagingen om integriteit, veiligheid en maximale prestaties te bereiken.

De tweede taak is in strijd met de eerste omdat bijvoorbeeld:

Om transacties effectief te laten functioneren, moet u schijfruimte reserveren voor tijdelijke objecten,
om de zoeksnelheid te verhogen, moet u indexen maken, waarvan het aantal wordt bepaald door het aantal mogelijke combinaties van velden die bij de zoekopdracht betrokken zijn,
Om gegevens te herstellen, worden er databaseback-ups gemaakt en wordt er een logboek van alle wijzigingen bijgehouden.

Dit alles vergroot de omvang van de database, dus zoekt de ontwerper naar een redelijk evenwicht waarin problemen optimaal worden opgelost door gegevens op een intelligente manier in geheugenruimte te plaatsen, maar niet ten koste van de databasebeveiliging, die zowel bescherming tegen ongeautoriseerde toegang als bescherming omvat. van mislukkingen.

Om de creatie van een fysiek model te voltooien, worden de operationele kenmerken ervan beoordeeld (zoeksnelheid, efficiëntie van de uitvoering van zoekopdrachten en verbruik van hulpbronnen, correctheid van de bewerkingen). Soms wordt deze fase, net als de fasen van de database-implementatie, het testen en optimaliseren, maar ook het onderhoud en de exploitatie, buiten het directe ontwerp van de database gehouden.