Stadia van database-ontwikkeling. Basisstappen voor het maken van een database

Database-ontwerp

Stadia van databaseontwerp:

1. Systeemanalyse en verbale beschrijving van informatieobjecten van het vakgebied en relaties daartussen.

2. Semantische domeinmodellering is een gedeeltelijk geformaliseerde beschrijving van domeinobjecten in termen van een semantisch model, bijvoorbeeld een ER-model.

3. Keuze uit standaard DBMS.

4. Logisch ontwerp van de database, dat wil zeggen de beschrijving van de database in termen van het geaccepteerde datamodel. In dit stadium worden het aantal en de structuur van tabellen bepaald, worden query's op de database gevormd, worden soorten rapportagedocumenten bepaald, worden algoritmen voor informatieverwerking ontwikkeld, worden formulieren voor het invoeren en bewerken van gegevens gemaakt, enz.

5. Fysiek ontwerp van de database, dat wil zeggen de keuze voor een efficiënte plaatsing van de database op externe media om maximale prestaties bij gegevensverwerking te garanderen.

4.2 Entiteit-relatiemodel (ER-model)

Essence is een object van de echte wereld dat onafhankelijk kan bestaan. entiteit heeft gevallen, die van elkaar verschillen in attribuutwaarden en een eenduidige identificatie mogelijk maken. Attribuut is een benoemd kenmerk van een entiteit. Bijvoorbeeld entiteit Boek gekenmerkt door attributen zoals auteur, titel, uitgever, etc. Concrete boeken zijn entiteitsinstanties Boek. Ze verschillen in de waarden van de opgegeven attributen en worden uniek geïdentificeerd door het attribuut "name". Een attribuut dat instanties van een entiteit op unieke wijze identificeert, wordt aangeroepen toets. De sleutel kan zijn composiet A die een combinatie van meerdere attributen vertegenwoordigt.

Stel dat er een database wordt ontworpen voor het vakgebied BANK. Het heeft filialen beheerd door managers. Klanten hebben verschillende soorten rekeningen: lopende, dringende, op afroep, enz., die in filialen worden verwerkt. Binnen het vakgebied zijn vier entiteiten te onderscheiden: Filiaal, Manager, Account, Klant.

Op een ER-diagram wordt een entiteit afgebeeld als een rechthoek waarin de naam wordt aangegeven, bijvoorbeeld:

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

Er zijn 3 links in het onderwerp BANK:

1. Filiaalmanager

2. Filiaal Verwerking Factuur

3. Klant heeft een account

Een belangrijk kenmerk van communicatie is verbindingstype (multipliciteit). Overweeg de typen van de bovenstaande links. Aangezien één manager slechts één filiaal beheert, is de 1e relatie van het type één-op-één (1:1).

Aangezien één filiaal meerdere rekeningen verwerkt en elke rekening door slechts één filiaal wordt verwerkt, is de tweede relatie van het type één-op-veel (1:M).

Aangezien één account door meerdere klanten kan worden gedeeld en één klant meerdere accounts kan hebben, is de derde relatie van het type many-to-many (M:N).

Mate van participatie bepaalt of alle of slechts enkele instanties van de entiteit deelnemen aan de relatie. Misschien is ze dat wel verplicht of optioneel.

Als niet elke instantie van entiteit A geassocieerd is met een instantie van entiteit B, dan is de mate van participatie van entiteit A dat wel optioneel. Dit wordt weergegeven op het ER-diagram door een zwarte cirkel op de linklijn 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 op het ER-diagram de zwarte cirkel op de linklijn in een rechthoek naast entiteit A geplaatst. Medewerker Registreert Klanten heeft type (1:M). Tegelijkertijd meldt niet iedere medewerker cliënten aan (optionele deelname), maar wordt iedere cliënt aangemeld door een medewerker (verplichte deelname):

Stel dat in het beschouwde vakgebied BANK de mate van participatie van alle vier de entiteiten verplicht is. Dan ziet het ER-model er als volgt uit:

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

Een ER-model in combinatie met entiteitattribuutsets kan dienen als voorbeeld van een semantisch (conceptueel) domeinmodel of een conceptueel databaseschema.

De volgende stadia van database-ontwikkeling kunnen worden onderscheiden:

· ontwerpen;

software-implementatie;

voltooiing en werking.

De ontwerpfase is de theoretische constructie van het initiële database-informatiemodel. Het bevat:

het verzamelen van informatie over het vakgebied, de structuur ervan, input- en outputinformatiegegevensstromen, de studie van automatiseringstaken, de analyse en selectie van objecten van het bronsysteem en het definiëren van relaties daartussen;

Definitie van eigenschappen en kenmerken voor elk object in de database, waaraan velden (attributen) worden toegewezen, brontabellen en relaties daartussen worden samengesteld, gegevenselementen in de database worden bepaald, beperkingen op gegevenswaarden, enz.

toewijzing van primaire sleutels (velden) voor elk object en normalisatie (partitionering) van brontabellen;

· het controleren van de juistheid van het project, dat alle geselecteerde objecten, hun attributen en beschreven processen op het vereiste detailniveau zou moeten weergeven, het onderwerpgebied weergeven waarvoor het probleem moet worden opgelost;

definitie van de logische structuur van de database;

· oplossing van vragen over bescherming en behoud van de integriteit van de database. Onder data-integriteit wordt verstaan ​​een stelsel van maatregelen gericht op het te allen tijde handhaven van de juistheid van de gegevens in de database.

De fase van software-implementatie houdt verband met de ontwikkeling van applicaties op een computer, waarvoor u de volgende stappen moet uitvoeren:

Beschrijf de resulterende tabellen met behulp van het DBMS en voer ze in op de computer;

· voor gebruikers van het informatiesysteem om interfaces te ontwikkelen voor het werken met de database, dat wil zeggen schermformulieren voor het invoeren en weergeven van gegevens, rapporten voor het afdrukken van overzichtsgegevens, query's voor het verkrijgen van gegevens;

· ontwikkel de procedure voor het in goede staat houden en onderhouden van de database, het werk van eindgebruikers;

Het systeem testen, instructies opstellen om ermee te werken en personeel opleiden.

De exploitatie- en bevolkingsfase begint met het vullen van de database met specifieke gegevens. Het omvat het directe onderhoud van de database en het onderhoud ervan.

Bij het ontwikkelen van een database voor grote ondernemingen en bedrijven wordt analyse en modellering uitgevoerd met behulp van speciale softwaretools, zoals CASE-tools, waarmee u gegevensstromen, processen en functies van een onderneming kunt simuleren, knelpunten kunt identificeren en aanbevelingen kunt doen voor de effectieve organisatie van de structuur en bedrijfsprocessen in een onderneming.

Naast het bouwen van modellen van de huidige staat van de onderneming en analyse, kunt u met modelleringssoftware specificaties genereren en een project voor het toekomstige systeem bouwen, bovendien kunt u een programmacode krijgen voor de meest voorkomende DBMS. De modelleringsfase kan dus de ontwerpfase en een deel van de implementatiefase van het informatiesysteem bevatten.

Conceptueel databaseontwerp

De eerste fase van het databaseontwerpproces wordt het conceptuele databaseontwerp genoemd. Het bestaat uit het creëren van een conceptueel gegevensmodel voor het geanalyseerde deel van de objecten van het systeem dat wordt bestudeerd. Dit datamodel wordt gemaakt op basis van de informatie die is vastgelegd in de specificaties van de gebruikersvereisten. Het conceptuele ontwerp van een database is absoluut onafhankelijk van details van de implementatie ervan, zoals het gekozen type DBMS, de set applicatieprogramma's die worden gemaakt, de gebruikte programmeertalen, het gekozen type computerplatform en alle andere functies van de fysieke uitvoering. Het gecreëerde conceptuele datamodel is de informatiebron voor de ontwerpfase van de logische database.

Logisch databaseontwerp

De tweede fase van databaseontwerp wordt logisch databaseontwerp genoemd. Het doel is om een ​​logisch gegevensmodel te creëren. Het conceptuele datamodel dat in de vorige stap is gemaakt, wordt verfijnd en omgezet in een logisch datamodel. Het logische datamodel houdt rekening met de kenmerken van het gekozen dataorganisatiemodel in het DBMS (bijvoorbeeld een relationeel of netwerkmodel).

Als het conceptuele datamodel niet afhankelijk is van fysieke aspecten van de implementatie, dan wordt het logische datamodel gemaakt op basis van het gekozen dataorganisatiemodel in het DBMS. Met andere woorden, in dit stadium zou al bekend moeten zijn welk DBMS zal worden gebruikt: relationeel, netwerk, hiërarchisch of objectgeoriënteerd. In dit stadium worden echter alle andere aspecten van het geselecteerde DBMS genegeerd, bijvoorbeeld alle kenmerken van de fysieke organisatie van de gegevensopslagstructuren en indexopbouw.

Tijdens het ontwikkelproces wordt het logische datamodel continu getoetst en gevalideerd aan de wensen van de gebruiker. Om de juistheid van het logische datamodel te controleren, wordt de normalisatiemethode gebruikt. Normalisatie zorgt ervoor dat relaties die zijn afgeleid van een bestaand gegevensmodel geen gegevensredundantie hebben die update-afwijkingen kan veroorzaken zodra ze fysiek zijn geïmplementeerd. Het logische datamodel moet onder meer ondersteuning bieden voor alle transacties die gebruikers nodig hebben.

Het geconstrueerde logische datamodel is een bron van informatie voor de fysieke ontwerpfase en biedt de ontwikkelaar van de fysieke database de middelen om de afwegingen te maken die nodig zijn om de gestelde doelen te bereiken, wat erg belangrijk is voor een effectief ontwerp. Het logische datamodel speelt ook een belangrijke rol tijdens de exploitatie- en onderhoudsfase van een reeds opgeleverd systeem. Met goed onderhoud stelt een goed onderhouden datamodel u in staat om nauwkeurig en visueel alle wijzigingen in de database weer te geven en de impact ervan op applicaties te evalueren.

Database-normalisatie

Bij het ontwerpen van databases is het belangrijkste de definitie van tabelstructuren en relaties daartussen. Fouten in de datastructuur zijn moeilijk en vaak niet programmatisch te corrigeren. Hoe beter de datastructuur, hoe gemakkelijker het is om de database te programmeren. Databaseontwerptheorie omvat het concept van normale vormen die zijn ontworpen om de structuur van de database te optimaliseren. Normale formulieren zijn een lineaire opeenvolging van regels die worden toegepast op de database, en hoe hoger het nummer van de normale vorm, hoe perfecter de structuur van de database. Normalisatie is een proces met meerdere stappen waarin databasetabellen worden georganiseerd, gescheiden en gegevens worden geordend. De taak van normalisatie is om enkele ongewenste kenmerken uit de database te verwijderen. Het is met name de taak om sommige soorten gegevensredundantie te elimineren en zo anomalieën bij gegevenswijzigingen te voorkomen. Anomalieën bij gegevensmodificatie zijn moeilijkheden bij het invoegen, wijzigen en verwijderen van gegevens die ontstaan ​​door de structuur van de database. Hoewel er veel niveaus zijn, is het meestal voldoende om te normaliseren naar de derde normaalvorm.

Overweeg een voorbeeld van het normaliseren van de database voor het beheer van de levering van bestellingen. De ongeordende database "Sales" zou uit één tabel bestaan ​​(Fig. 7).

Afb.7. DB "Verkoop"

In de tabel bevat elk record informatie over meerdere bestellingen van dezelfde klant. Omdat de kolom met productdetails te veel gegevens bevat, is het moeilijk om georganiseerde informatie uit deze tabel te halen (bijvoorbeeld om te rapporteren over de totale aankopen van verschillende soorten goederen).

Eerste normaalvorm

Eerste normaalvorm definieert de atomiciteit van alle gegevens in kolommen. Het woord "atoom" komt van het Latijnse "atomis", wat letterlijk betekent "niet te verdelen". De eerste normaalvorm geeft aan dat op elke positie die wordt gedefinieerd door een rij en kolom, er slechts één waarde is, geen matrix of lijst met waarden. De voordelen van deze vereiste zijn duidelijk: als een enkele kolom zoeklijsten bevat, is er geen gemakkelijke manier om die waarden te manipuleren. Dit verhoogt natuurlijk het aantal records in de tabel.

Laten we de database "Sales" normaliseren naar de eerste normale vorm (Fig. 8).

Afb.8. Eerste normaalvorm

3.3.2. Tweede normaalvorm

U kunt naar de tweede normaalvorm springen vanuit een tabel die al overeenkomt met de eerste normaalvorm. Bovendien moet aan de volgende voorwaarde worden voldaan: elk niet-sleutelveld moet volledig afhankelijk zijn van de primaire sleutel.

Laten we de database "Verkoop" normaliseren naar de tweede normaalvorm. Alle informatie die geen betrekking heeft op individuele bestellingen wordt gescheiden in een aparte tabel. Als gevolg hiervan krijgen we in plaats van één tabel "Verkoop" er twee - de tabel "Orders" (Fig. 9) en de tabel "Producten" (Fig. 10).

Afb.9. Tabel "Bestellingen"

Afb.10. Tabel "Producten"

Het producttype wordt dus in slechts één tabel opgeslagen. Opgemerkt moet worden dat er geen informatie verloren gaat tijdens normalisatie.

3.3.3. derde normaalvorm

Van een tabel wordt gezegd dat deze zich in de derde normaalvorm bevindt als deze in de tweede normaalvorm is en alle niet-sleutelkolommen onderling onafhankelijk zijn. Een kolom waarvan de waarden worden berekend op basis van gegevens in andere kolommen, is een voorbeeld van een afhankelijkheid.

Laten we de "Sales"-database normaliseren naar de derde normaalvorm. Verwijder hiervoor de kolom "Totaal" uit de tabel "Bestellingen". De waarden in deze kolom zijn niet afhankelijk van een sleutel en kunnen worden berekend met de formule ("Prijs")*("Aantal"). Zo werd de database "Sales" verkregen met een optimale structuur, die uit twee tabellen bestaat (Fig. 11).

Rijst. 11. Genormaliseerde database "Verkoop"

3.2 Software-implementatie van de database

De software-implementatie van de database wordt uitgevoerd door een doel-DBMS te creëren in de datadefinitietaal (DDL). DDL-commando's worden gecompileerd en gebruikt om schema's en lege databasebestanden te maken. In dezelfde fase worden alle specifieke gebruikersweergaven gedefinieerd.

Applicatieprogramma's worden geïmplementeerd met behulp van talen van de derde of vierde generatie. Sommige elementen van deze applicatieprogramma's zijn databaseverwerkingstransacties die zijn geschreven in de datamanipulatietaal (DML) van het doel-DBMS en worden aangeroepen vanuit programma's in de onderliggende programmeertaal, bijvoorbeeld Visual Basic, C++, Java. Daarnaast worden in deze fase andere onderdelen van het aanvraagproject gemaakt, zoals menuschermen, invoerformulieren en rapporten. Houd er rekening mee dat veel bestaande DBMS'en hun eigen ontwikkeltools hebben waarmee u snel applicaties kunt maken met behulp van niet-procedurele querytalen, een verscheidenheid aan rapportgeneratoren, formuliergeneratoren, grafische generatoren en applicatiegeneratoren.

In deze fase worden ook de middelen geïmplementeerd die door de toepassing worden gebruikt om de database te beschermen en de integriteit ervan te behouden. Sommige worden beschreven met behulp van de DDL-taal, terwijl andere mogelijk op andere manieren moeten worden gedefinieerd, bijvoorbeeld door aanvullende DBMS-hulpprogramma's te gebruiken of door toepassingsprogramma's te maken die de vereiste functies implementeren.

3.2.1. Applicatie ontwikkeling

Applicatieontwikkeling is het ontwerp van de gebruikersinterface en applicatieprogramma's voor het werken met een database. In de meeste gevallen kan het applicatieontwerp pas worden voltooid als het databaseontwerp is voltooid. Aan de andere kant is de database ontworpen om applicaties te ondersteunen, en daarom moet er tussen de fasen van het ontwerpen van een database en het ontwerpen van applicaties voor deze database een constante uitwisseling van informatie plaatsvinden.

Er moet voor worden gezorgd dat alle functionaliteit die in de specificaties van de gebruikersvereisten wordt geboden, wordt geleverd door de gebruikersinterface van de respectieve applicaties. Dit geldt zowel voor het ontwerp van applicatieprogramma's voor toegang tot informatie in de database als voor het ontwerp van transacties, d.w.z. methoden voor databasetoegang ontwerpen.

Naast het ontwerpen van de manieren waarop de gebruiker toegang kan krijgen tot de functionaliteit die hij nodig heeft, moet u ook de juiste gebruikersinterface voor uw databasetoepassingen ontwerpen. Deze interface moet de gebruiker op de voor hem meest geschikte manier de nodige informatie verstrekken.

3.2.2 Databasetesten

Testen is het uitvoeren van toepassingsprogramma's om fouten te vinden. Voordat een nieuw systeem in de praktijk wordt gebruikt, moet het zorgvuldig worden getest. Dit kan worden bereikt door een goed doordacht testalgoritme te ontwikkelen met behulp van echte gegevens, dat zo moet worden ontworpen dat het hele testproces strikt consistent en methodisch correct wordt uitgevoerd. De testtaak is niet het proces van het aantonen van de afwezigheid van fouten, het is onwaarschijnlijk dat de afwezigheid van fouten in software kan worden aangetoond - integendeel, het kan alleen hun aanwezigheid aantonen. Als de test slaagt, komen de fouten in de applicatieprogramma's en databasestructuren aan het licht. Als bijproduct kunnen testen alleen aantonen dat de database en applicaties werken volgens hun specificaties terwijl ze nog steeds voldoen aan de prestatie-eisen. Bovendien kunt u door het verzamelen van statistische gegevens in de testfase indicatoren vaststellen voor de betrouwbaarheid en kwaliteit van de gemaakte software.

Net als bij het ontwerpen van een database, moeten gebruikers van een nieuw systeem worden betrokken bij het testproces. Idealiter zouden systeemtesten moeten worden uitgevoerd op een aparte set apparatuur, maar vaak is dit eenvoudigweg niet mogelijk. Wanneer u echte gegevens gebruikt, is het belangrijk om van tevoren een back-up te maken voor het geval ze door fouten beschadigd raken. Na voltooiing van het testen wordt het proces van het maken van een toegepast systeem als voltooid beschouwd en kan het worden overgedragen aan commerciële exploitatie.

3.3 Databasegebruik en -onderhoud

Bediening en onderhoud - ondersteuning voor de normale werking van de database.

In de voorgaande stappen is de database applicatie volledig geïmplementeerd en getest. Nu gaat het systeem de laatste fase van zijn levenscyclus in, genaamd bediening en onderhoud. Het omvat het doen van dingen als:

Bewaking van systeemprestaties. Als de prestaties onder een acceptabel niveau komen, kan aanvullende reorganisatie van de database nodig zijn;

· Onderhoud en modernisering (indien nodig) van database-applicaties. Nieuwe vereisten worden in de databasetoepassing opgenomen wanneer de vorige levenscyclusstappen opnieuw worden geprobeerd.

Zodra de database in productie is genomen, moet u het proces van het functioneren ervan voortdurend bewaken - dit zorgt ervoor dat prestatie- en andere indicatoren aan de vereisten voldoen. Een typisch DBMS biedt doorgaans verschillende hulpprogramma's voor databasebeheer, waaronder hulpprogramma's voor het laden van gegevens en systeembewaking. Dergelijke hulpprogramma's kunnen de systeemprestaties bewaken en informatie verstrekken over verschillende statistieken, zoals databasegebruik, vergrendelingssysteemprestaties (inclusief het aantal deadlocks dat is opgetreden) en strategieën voor het uitvoeren van query's om uit te kiezen. De databasebeheerder kan deze informatie gebruiken om het systeem af te stemmen om de prestaties te verbeteren (bijvoorbeeld door extra indexen te maken), query's te versnellen, opslagstructuren te wijzigen, individuele tabellen samen te voegen of te splitsen.

Het monitoringproces moet gedurende de hele levensduur van de applicaties worden gehandhaafd, zodat de database op elk moment efficiënt kan worden gereorganiseerd om aan veranderende eisen te voldoen. Dergelijke wijzigingen geven informatie over de meest waarschijnlijke verbeteringen aan de database en de bronnen die in de toekomst nodig kunnen zijn. Als het gebruikte DBMS een aantal van de benodigde hulpprogramma's niet heeft, moet de beheerder deze zelf ontwikkelen of de vereiste aanvullende hulpprogramma's aanschaffen bij externe ontwikkelaars.

4. DBMS Microsoft-toegang

4.1 Doel en algemene informatie over het Microsoft Access DBMS

Microsoft Access is een databasebeheersysteem dat gebruikmaakt van een relationeel gegevensmodel en is opgenomen in het Microsoft Office-toepassingspakket. Het is ontworpen om gegevens op te slaan, in te voeren, te zoeken en te bewerken, en om ze in een handige vorm uit te geven.

De toepassingsgebieden van Microsoft Access omvatten het volgende:

in kleine bedrijven (boekhouding, orderinvoer, beheer van klantinformatie, beheer van zakelijke contactinformatie);

in grote bedrijven (applicaties voor werkgroepen, informatieverwerkingssystemen);

· als een persoonlijk DBMS (adreslijst, bijhouden van een beleggingsportefeuille, een kookboek, catalogi van boeken, platen, video's, enz.).

Access is een van de krachtigste, gebruiksvriendelijke en eenvoudigste databasebeheersystemen. Omdat Access deel uitmaakt van Microsoft Office, deelt het veel functies van Office-toepassingen en kan het ermee communiceren. Zo kunt u tijdens het werken in Access bestanden openen en bewerken en het klembord gebruiken om gegevens uit andere toepassingen te kopiëren.

Tools voor het ontwerpen van objecten in Access zijn "wizards" en "constructors". Dit zijn speciale programma's die worden gebruikt voor het maken en bewerken van tabellen, query's, verschillende soorten formulieren en rapporten. In de regel wordt "wizard" gebruikt om objecten te maken en "constructor" - om objecten te bewerken. Het bewerkingsproces omvat het veranderen van het uiterlijk van een object om het te verbeteren. Bij het bewerken van een formulier kunt u de namen en volgorde van de velden wijzigen, de grootte van het gegevensinvoergebied vergroten of verkleinen, enzovoort. U kunt ook de "constructor" gebruiken om formulieren te maken, maar dit is een zeer tijdrovende klus. Access omvat speciale softwaretools waarmee u de structuur van gegevens kunt analyseren, spreadsheets en tekstgegevens kunt importeren, de prestaties van toepassingen kunt verbeteren en toepassingen kunt maken en aanpassen met behulp van ingebouwde sjablonen. Om uw applicaties volledig te automatiseren, kunt u met macro's gegevens koppelen aan formulieren en rapporten.

Access implementeert relationeel databasebeheer. Het systeem ondersteunt primaire en externe sleutels. Dwingt gegevensintegriteit af op kernelniveau, waardoor incompatibele bewerkingen voor het bijwerken of verwijderen van gegevens niet zijn toegestaan. Tabellen in Access zijn uitgerust met tools voor gegevensvalidatie, d.w.z. ongeldige invoer is niet toegestaan. Elk tabelveld heeft zijn eigen formaat en standaardbeschrijvingen, wat het invoeren van gegevens vergemakkelijkt. Access ondersteunt de volgende veldtypen, waaronder: tab, tekst, numeriek, teller, valuta, datum/tijd, memo, boolean, hyperlink, OLE-objectvelden, bijlage en berekend. Als er geen waarden in de velden verschijnen, biedt het systeem volledige ondersteuning voor null-waarden.

In Access kunt u grafische hulpmiddelen gebruiken, zoals in Microsoft Word, Excel, PowerPoint en andere toepassingen, om verschillende soorten grafieken en diagrammen te maken. U kunt staafdiagrammen, 2D- en 3D-diagrammen maken. U kunt allerlei soorten objecten toevoegen aan Access-formulieren en -rapporten: afbeeldingen, grafieken, audio- en videoclips. Door deze objecten te koppelen aan de ontwikkelde database kunt u dynamische formulieren en rapporten maken. U kunt in Access ook macro's gebruiken om bepaalde taken te automatiseren. Hiermee kunt u formulieren en rapporten openen en sluiten, menu's en dialoogvensters maken om het maken van verschillende toepassingstaken te automatiseren.

In Access kunt u contextgevoelige hulp krijgen door op te klikken en op het scherm wordt helpinformatie weergegeven over het probleem dat de gebruiker op dit moment interesseert. U kunt eenvoudig navigeren naar de inhoudsopgave, specifieke informatie, geschiedenis van eerdere toegangen en bladwijzers van het helpsysteem. De database-informatie wordt opgeslagen in een bestand met de extensie .accdb.

4.2. Microsoft Access-objecten

Wanneer u Access DBMS start, verschijnt er een venster voor het maken van een nieuwe database of voor het werken met eerder gemaakte databases of met bestaande sjablonen (Fig. 12).

Rijst. 12. Start Toegang

Sjablonen zijn lege databasestructuren die veldtypen definiëren, basisobjecten maken, koppelingen tussen tabellen maken, enzovoort.

Wanneer u een nieuwe database maakt, opent Access een lege tabel met één rij en twee kolommen (Afbeelding 13).

Afb.13. Nieuw databasevenster

In het linkerdeel van het venster (navigatiegebied) worden alle aangemaakte database-objecten getoond, terwijl we alleen een lege tabel zien, omdat er zijn geen aangemaakte objecten meer in de nieuwe database (Fig. 13). De belangrijkste objecten van het Access DBMS zijn de volgende.

tafels. Tabellen zijn de basisobjecten van databases omdat ze alle gegevens opslaan en de structuur van de database definiëren. Een database kan duizenden tabellen bevatten, alleen beperkt door de beschikbare ruimte op de harde schijf van uw computer. Het aantal vermeldingen in de tabellen wordt bepaald door de grootte van de harde schijf en het aantal velden is niet meer dan 255.

Tabellen in Access kunnen als volgt worden gemaakt:

in de "constructor" -modus;

in de modus voor het invoeren van gegevens in een tabel.

U kunt een tabel maken door gegevens die elders zijn opgeslagen te importeren of te koppelen. Dit kan bijvoorbeeld met gegevens die zijn opgeslagen in een Excel-bestand, in een Windows SharePoint Services-lijst, een XML-bestand, een andere MS ACCESS-database. Met een SharePoint-lijst kunt u toegang tot gegevens verlenen aan gebruikers die de MS ACCESS-toepassing niet hebben geïnstalleerd. Wanneer u gegevens importeert, wordt er een kopie gemaakt in een nieuwe tabel in de huidige database. Latere wijzigingen in de oorspronkelijke gegevens hebben geen invloed op de geïmporteerde gegevens en vice versa. Wanneer u naar gegevens koppelt, wordt er een gekoppelde tabel gemaakt in de huidige database om een ​​dynamische verbinding te bieden met gegevens die elders zijn opgeslagen. Wijzigingen in gegevens in een gerelateerde tabel worden weergegeven in de bron en wijzigingen in de bron worden weergegeven in de gerelateerde tabel.

De tabelweergave geeft de gegevens weer die in de tabel zijn opgeslagen, terwijl de ontwerpweergave de structuur van de tabel weergeeft.

Als tabellen gemeenschappelijke velden hebben, kunt u een subtabel gebruiken om records van een andere in één tabel in te voegen. Met deze aanpak kunt u tegelijkertijd gegevens uit meerdere tabellen bekijken.

Verzoeken. Query's zijn speciale hulpmiddelen die zijn ontworpen om informatie in databasetabellen te zoeken en te analyseren die aan bepaalde criteria voldoen. De gevonden records, queryresultaten genoemd, kunnen op verschillende manieren worden bekeken, bewerkt en geanalyseerd. Bovendien kunnen queryresultaten worden gebruikt als basis voor het maken van andere Access-objecten. Er zijn verschillende soorten query's, waarvan de meest voorkomende selectiequery's, parametrische en kruisquery's, records verwijderen, query's wijzigen en andere zijn. Minder vaak gebruikt zijn actiequery's en SQL-query's (Structured Query Language). Als de vereiste aanvraag niet bestaat, kan deze aanvullend worden gemaakt.

Verzoeken worden op verschillende manieren gevormd, bijvoorbeeld met behulp van de "wizard", u kunt ook handmatig een verzoek maken in de "ontwerper" modus. Het eenvoudigste en meest gebruikte type query is de selectiequery. Deze query's selecteren gegevens uit een of meer tabellen en vormen daaruit een nieuwe tabel, waarvan de records kunnen worden gewijzigd. Selectiequery's zijn nodig om sommen en gemiddelden te berekenen en andere totalen te vinden. Query's gebruiken dus gegevens uit de hoofdtabellen en maken tijdelijke tabellen.

Formulieren. Formulieren worden gebruikt om records in databasetabellen in te voeren en te bewerken. Formulieren kunnen in drie modi worden weergegeven: gegevensinvoermodus, tabelmodus, waarbij gegevens in tabelvorm worden gepresenteerd, en lay-out- en ontwerpmodi, waarmee u wijzigingen en toevoegingen aan formulieren kunt aanbrengen.

De belangrijkste elementen van het formulier zijn labels, die de tekst bevatten die direct in het formulier wordt weergegeven, en velden die de waarden van de tabelvelden bevatten. Hoewel de "designer"-modus u in staat stelt om een ​​formulier helemaal opnieuw te maken, wordt het meestal gebruikt om formulieren die met behulp van de "wizard" zijn gemaakt, te verfijnen en te verbeteren. Naast de bovenstaande tools kunnen formulieren ook worden gemaakt met behulp van de volgende tools:

· "het formulier";

"gesplitste vorm";

"meerdere elementen";

"lege vorm".

Het is het meest efficiënt om formulieren voor gegevensinvoer te gebruiken in de vorm van speciale formulieren, aangezien het formulier eruit kan zien als een formulier. Door het gebruik van formulieren kunt u gegevens invoeren in een gebruiksvriendelijke vorm van vertrouwde documenten. Met I/O-formulieren kunt u gegevens in de database invoeren, bekijken, veldwaarden wijzigen, records toevoegen en verwijderen. Een formulier kan een knop bevatten die wordt gebruikt om een ​​rapport af te drukken, andere objecten te openen of andere taken automatisch uit te voeren.

rapporten. Rapporten worden gebruikt om informatie in tabellen weer te geven in een opgemaakte vorm die zowel op het beeldscherm als op papier duidelijk wordt gepresenteerd. Het rapport is een effectief hulpmiddel om gegevens uit de database af te drukken in de door de gebruiker gewenste vorm (in de vorm van certificaten, examenbladen, tabellen, enz.). Naast gegevens die zijn opgehaald uit meerdere tabellen en query's, kunnen rapporten ontwerpelementen bevatten die gemeenschappelijk zijn voor gedrukte documenten, zoals titels, kop- en voetteksten.

Het rapport kan in vier modi worden weergegeven: in de "designer"-modus, waarmee u het uiterlijk van het rapport kunt wijzigen, in de voorbeeldweergavemodus, waarin u alle elementen van het voltooide rapport kunt weergeven, maar in een verkleinde vorm. formulier, in de "lay-out"-modus, waarmee u het rapport duidelijker kunt weergeven (in vergelijking met de ontwerpmodus) en kunt opmaken, en in de afdrukvoorbeeldmodus, waar het rapport wordt weergegeven zoals het zal worden afgedrukt.

Tabellen, query's, formulieren en rapporten zijn de meest gebruikte objecten bij de ontwikkeling van Access-databases.

De mogelijkheden van de database kunnen echter aanzienlijk worden verbeterd door gebruik te maken van toegangspagina's, macro's en modules.

Pagina's. Om internetgebruikers toegang te geven tot informatie, kunt u aangepaste gegevenstoegangspagina's in uw database maken. Met gegevenstoegangspagina's kunt u de in de database opgeslagen gegevens bekijken, toevoegen, wijzigen en manipuleren. Gegevenstoegangspagina's kunnen ook gegevens uit andere bronnen bevatten, zoals Excel. Om informatie uit een database te publiceren, bevat Web Access een "wizard" die zorgt voor het maken van een toegangspagina.

Macro's. Macro's zijn kleine programma's van een of meer macro's die specifieke bewerkingen uitvoeren, zoals het openen van een formulier, het afdrukken van rapporten, het klikken op een knop, enzovoort. Dit is vooral handig als u van plan bent de database over te dragen aan onervaren gebruikers. U kunt bijvoorbeeld macro's schrijven die een reeks opdrachten bevatten die routinetaken uitvoeren, of u kunt acties zoals het openen van een formulier of het afdrukken van een rapport koppelen aan knoppen op een knopformulier.

modules. Een module is een database-object waarmee u bibliotheken kunt maken van subroutines en functies die in een toepassing worden gebruikt. Met behulp van modulecodes kunt u taken oplossen zoals het afhandelen van invoerfouten, het declareren en gebruiken van variabelen, het organiseren van lussen, enz.

Federaal Agentschap voor Onderwijs

Rijksonderwijsinstelling voor hoger beroepsonderwijs

AMOER STAATS UNIVERSITEIT

(GOUVPO "AmSU")

TEST

in de discipline "Informatiesystemen in de economie"

over het onderwerp: "Principes van constructie en stadia van het ontwerpen van databases"

Uitvoerder

leerling van groep C - 81 N.A. Vokhmyanina

Leidinggevende

Universitair hoofddocent, Ph.D. D.G. Shevko

Blagovesjtsjensk 2010

Invoering

1. Principes van het bouwen van databases

2. Concepten van het bouwen van databases

3. Stadia van databaseontwerp

Bibliografische lijst

INVOERING

De perceptie van de echte wereld kan worden gecorreleerd met een opeenvolging van verschillende, hoewel soms met elkaar samenhangende fenomenen. Sinds de oudheid hebben mensen geprobeerd deze verschijnselen te beschrijven (zelfs als ze ze niet konden begrijpen). Zo'n beschrijving wordt data genoemd.

Traditioneel wordt het vastleggen van gegevens uitgevoerd met behulp van een specifiek communicatiemiddel, bijvoorbeeld met behulp van natuurlijke taal in een specifiek medium.

Op dit moment is het succesvol functioneren van verschillende bedrijven, organisaties en ondernemingen eenvoudigweg niet mogelijk zonder een ontwikkeld informatiesysteem waarmee u het verzamelen en verwerken van gegevens kunt automatiseren. Gewoonlijk wordt een database gemaakt om gegevens met informatie over een bepaald onderwerp op te slaan en te openen.

Databank (DB)- een benoemde set gegevens die de staat van objecten en hun relaties in het onderwerpgebied in kwestie weerspiegelt.

Een vakgebied wordt meestal begrepen als een bepaald gebied van menselijke activiteit of een gebied van de echte wereld dat moet worden bestudeerd voor de organisatie van beheer en automatisering, bijvoorbeeld een onderneming, een universiteit, enz.

Databasebeheersysteem (DBMS)- een reeks taal- en softwaretools die zijn ontworpen om databases aan te maken, aan te vullen, bij te werken en te verwijderen.

Programma's waarmee gebruikers met de database werken, worden applicaties genoemd.

1. PRINCIPES VAN HET BOUWEN VAN DATABASES

De volgende basiseisen worden gesteld aan moderne databases en daarmee aan het DBMS waarop ze zijn gebouwd.

1. Hoge performance (korte responstijd op een aanvraag).

Reactietijd - de tijdsperiode vanaf het moment van een verzoek aan de database tot de daadwerkelijke ontvangst van gegevens. Een vergelijkbare term is toegangstijd - het tijdsinterval tussen het geven van een schrijf- (lees) commando en de daadwerkelijke ontvangst van gegevens. Toegang verwijst naar het zoeken, lezen of schrijven van gegevens. Vaak worden de bewerkingen van het schrijven, verwijderen en wijzigen van gegevens een updatebewerking genoemd.

2. Gemakkelijk om gegevens bij te werken.

3. Gegevensonafhankelijkheid.

4. Gegevens delen tussen veel gebruikers.

5. Gegevensbeveiliging - bescherming van gegevens tegen opzettelijke of onopzettelijke schending van geheimhouding, vervorming of vernietiging.

6. Standaardisatie van de opbouw en werking van de database (eigenlijk het DBMS).

8. Vriendelijke gebruikersinterface.

De belangrijkste zijn de eerste twee tegenstrijdige eisen: prestatieverbetering vereist de vereenvoudiging van de databasestructuur, wat op zijn beurt de procedure bemoeilijkt gegevensupdates, vergroot hun redundantie.

Onafhankelijkheid van gegevens- de mogelijkheid om de logische en fysieke structuur van de database te wijzigen zonder de mening van gebruikers te veranderen.

Gegevensonafhankelijkheid impliceert onveranderlijkheid van de aard van gegevensopslag, software en hardware. Het zorgt voor minimale wijzigingen in de databasestructuur met wijzigingen in de datatoegangsstrategie en de structuur van de brongegevens zelf. Dit wordt bereikt door alle wijzigingen te "verschuiven" naar de conceptuele en logische ontwerpfase, met minimale wijzigingen tijdens de fysieke ontwerpfase.

Dataveiligheid omvat hun integriteit en bescherming.

Gegevensintegriteit is de weerstand van opgeslagen gegevens tegen vernietiging en vernietiging in verband met storingen van technische middelen, systeemfouten en foutieve acties van gebruikers.

Zij suggereert:

1. het ontbreken van onjuist ingevoerde gegevens of twee identieke vermeldingen over hetzelfde feit;

2. bescherming tegen fouten bij het updaten van de database;

3. de onmogelijkheid van het verwijderen (of trapsgewijze verwijdering) van gerelateerde gegevens van verschillende tabellen;

4. niet-vervorming van gegevens bij het werken in multi-user modus en in gedistribueerde databases;

5. veiligheid van data bij uitval van apparatuur (data recovery).

Integriteit wordt geleverd door integriteitstriggers - speciale applicatieprogramma's die onder bepaalde omstandigheden werken. Gegevensbescherming tegen ongeoorloofde toegang omvat het beperken van de toegang tot vertrouwelijke gegevens en kan worden bereikt:

1. de invoering van een wachtwoordsysteem;

2. het verkrijgen van toestemmingen van de databasebeheerder (DBA);

4. vorming van weergaven - tabellen afgeleid van de originele en bedoeld voor specifieke gebruikers.

De laatste drie procedures kunnen eenvoudig worden uitgevoerd binnen de Structured Query Language - SQL, vaak aangeduid als SQL2.

Standaardisatie zorgt voor de continuïteit van generaties DBMS, vereenvoudigt de interactie van databases van één generatie DBMS met dezelfde en verschillende datamodellen. Standaardisatie (ANSI/SPARC) is voor een groot deel doorgevoerd in de gebruikersinterface van het DBMS en de SQL-taal. Dit maakte het mogelijk om het probleem van de interactie tussen verschillende relationele DBMS'en met succes op te lossen, zowel met behulp van de SQL-taal als met behulp van de Open Database Connection (ODBC)-toepassing. In dit geval kan zowel lokale als externe toegang tot gegevens worden uitgevoerd (client/server-technologie of netwerkversie).

2. HET CONCEPT VAN HET BOUWEN VAN DE DATABASE

Er zijn twee benaderingen voor het bouwen van een database op basis van twee benaderingen voor het creëren van een geautomatiseerd besturingssysteem (ACS).

De eerste daarvan, veel gebruikt in de jaren 80 en daarom ook wel genoemd klassiek (traditioneel), geassocieerd met de automatisering van de workflow (een reeks documenten die in het proces van de onderneming bewegen). Documenten waren de begin- en uitvoercoördinaten, zoals te zien is in voorbeeld1.

Het volgende proefschrift is gebruikt. Gegevens zijn minder mobiel dan algoritmen, dus u moet een generieke database maken die vervolgens voor elk algoritme kan worden gebruikt. Al snel werd echter duidelijk dat het opzetten van een universele database problematisch is. Het concept van data-integratie dat tot voor kort domineerde, met een sterke toename van hun volume, bleek onhoudbaar. Bovendien begonnen applicaties te verschijnen (bijvoorbeeld tekst, grafische editors) op basis van veelgebruikte standaardalgoritmen.

In de jaren negentig had zich een tweede gevormd, moderne aanpak geassocieerd met automatiseringsbeheer. Het gaat om de eerste identificatie van standaard applicatie-algoritmen (bedrijfsalgoritmen in buitenlandse terminologie), waaronder de gegevens worden gedefinieerd, en dus de database. Objectgeoriënteerd programmeren heeft het belang van deze benadering alleen maar vergroot.

Bij de werking van de database zijn single- en multi-user (meerdere gebruikers verbinden met één computer via verschillende poorten) modi mogelijk.

Gebruik top-down en top-down databaseontwerp. De eerste wordt gebruikt in gedistribueerde databases bij het integreren van ontworpen lokale databases die kunnen worden uitgevoerd met behulp van verschillende datamodellen. Typischer voor gecentraliseerde databases is het ontwerp van bovenaf.

3. STADIA VAN DATABASE-ONTWERP

Databaseontwerp vindt plaats in vier fasen.

Op het podium formuleren en analyseren van eisen de doelen van de organisatie worden gesteld, de eisen aan de database worden bepaald. Ze bestaan ​​uit algemene vereisten zoals gedefinieerd in sectie 1 en specifieke vereisten. Om specifieke vereisten te formuleren, wordt meestal de techniek gebruikt van het interviewen van personeel op verschillende managementniveaus. Alle vereisten zijn gedocumenteerd in een vorm die toegankelijk is voor de eindgebruiker en databaseontwerper.

Fase conceptueel ontwerp bestaat uit de beschrijving en synthese van informatiebehoeften van gebruikers in het eerste ontwerp van de database. De initiële gegevens kunnen een set gebruikersdocumenten zijn in de klassieke benadering of toepassingsalgoritmen (bedrijfsalgoritmen) in de moderne benadering. Het resultaat van deze fase is een representatie op hoog niveau (in de vorm van een databasetabelsysteem) van gebruikersinformatievereisten op basis van verschillende benaderingen.

Eerst wordt het databasemodel geselecteerd. Vervolgens wordt een databasestructuur gecreëerd, die wordt gevuld met gegevens met behulp van menusystemen, schermformulieren of in de databasetabelweergavemodus. Het biedt ook bescherming en integriteit (inclusief referentie) van gegevens met behulp van een DBMS of door triggers te bouwen.

Tijdens logisch ontwerp de weergave op hoog niveau van de gegevens wordt omgezet naar de structuur van het gebruikte DBMS. Het belangrijkste doel van de fase is het elimineren van gegevensredundantie met behulp van speciale normalisatieregels. Het doel van normalisatie is het minimaliseren van gegevensherhalingen en mogelijke structurele wijzigingen in de database tijdens updateprocedures. Dit wordt bereikt door één tabel in twee of meer te splitsen (ontleden), gevolgd door het gebruik van navigatiebewerkingen in query's. Merk op dat navigatie zoeken de prestaties van de database vertraagt, d.w.z. verhoogt de reactietijd van query's. De resulterende logische structuur van de database kan worden gekwantificeerd met behulp van verschillende kenmerken (het aantal toegangen tot logische records, de hoeveelheid gegevens in elke toepassing, de totale hoeveelheid gegevens). Op basis van deze beoordelingen kan het logframe worden verbeterd om meer efficiëntie te bereiken.

Stappen voor het ontwerpen van databases

Het is onmogelijk om een ​​database te maken zonder een gedetailleerde beschrijving ervan, net zoals het onmogelijk is om een ​​complex product te maken zonder een tekening en een gedetailleerde beschrijving van de productietechnologieën. Met andere woorden, je hebt een project nodig. projecteren Het is gebruikelijk om een ​​schets van een apparaat te overwegen, die later in werkelijkheid zal worden vertaald.

Het database-ontwerpproces is een proces van overgangen van een informele verbale beschrijving van de informatiestructuur van het vakgebied naar een geformaliseerde beschrijving van de objecten van het vakgebied in termen van een bepaald model. Het uiteindelijke doel van design is het bouwen van een specifieke database. Het ontwerpproces is duidelijk complex en daarom is het logisch om het op te delen in logisch complete delen - fasen.

Er zijn vijf hoofdfasen van databaseontwerp:

1. Verzamelen van informatie en systeemanalyse van het vakgebied.

2. Infologisch ontwerp.

3. Keuze van DBMS.

4. Datalogisch ontwerp.

5. Fysiek ontwerp.

Verzamelen van informatie en systeemanalyse van het vakgebied- Dit is de eerste en belangrijkste fase in het ontwerp van de database. Het is noodzakelijk om een ​​gedetailleerde verbale beschrijving uit te voeren van de objecten van het onderwerpgebied en de echte verbindingen die bestaan ​​tussen echte objecten. Het is wenselijk dat de beschrijving de relatie definieert tussen de objecten van het onderwerpgebied.

In het algemeen zijn er twee benaderingen voor de keuze van de samenstelling en structuur van het vakgebied:

· functionele benadering- het wordt gebruikt wanneer de functies van een bepaalde groep personen en de takencomplexen waarvoor deze database wordt gemaakt, van tevoren bekend zijn, d.w.z. de minimaal noodzakelijke set objecten van het onderwerpgebied onder de beschrijving wordt duidelijk onderscheiden.

· Onderwerp benadering- wanneer de informatiebehoeften van databaseklanten niet duidelijk vastliggen en multidimensionaal en dynamisch kunnen zijn. In dit geval is het moeilijk om de minimale set objecten in het onderwerpgebied te onderscheiden. De beschrijving van het vakgebied omvat die objecten en relaties die daarvoor het meest kenmerkend en essentieel zijn. Tegelijkertijd wordt de database onderwerp en is geschikt om veel problemen op te lossen (wat het meest verleidelijk lijkt). De moeilijkheid van algemene dekking van het onderwerpgebied en de onmogelijkheid om gebruikersbehoeften te specificeren, leidt echter tot een te ingewikkeld databaseschema, dat voor sommige taken inefficiënt zal zijn.

Systeemanalyse moet eindigen met een gedetailleerde beschrijving van informatie over de objecten van het onderwerpgebied die in de database moeten worden opgeslagen, de formulering van specifieke taken die zullen worden opgelost met behulp van deze database met een korte beschrijving van de algoritmen voor hun oplossing, een beschrijving van de uitvoer- en invoerdocumenten bij het werken met de database.

infologisch ontwerp- gedeeltelijk geformaliseerde beschrijving van objecten van het vakgebied in termen van een semantisch model.

Waarom is een infologisch model nodig en welke voordelen biedt het ontwerpers? Het ontwerpproces is namelijk langdurig en vraagt ​​om overleg met de klant en experts op het vakgebied. Bovendien is bij het ontwikkelen van serieuze bedrijfsinformatiesystemen het databaseproject de basis waarop het hele systeem is gebouwd, en wordt de kwestie van de mogelijkheid van leningen vaak bepaald door bankexperts op basis van een goed gemaakt infologisch databaseproject. Daarom zou het infologische model een dergelijke geformaliseerde beschrijving van het onderwerpgebied moeten bevatten, die niet alleen door databasespecialisten gemakkelijk zal worden waargenomen. De beschrijving moet zo uitgebreid zijn dat het mogelijk is om de diepte en juistheid van de studie van het databaseproject te beoordelen.

Tot op heden is Chen's Entity Relationship-model het meest gebruikte model geworden, het is de de facto standaard geworden in infologische modellering en wordt het ER-model genoemd.

DBMS-keuze wordt uitgevoerd op basis van verschillende vereisten voor de database en dienovereenkomstig de mogelijkheden van het DBMS, evenals afhankelijk van de ervaring van de ontwikkelaars.

Gegevens logisch ontwerp er is een beschrijving van de database in termen van het geaccepteerde datamodel. In relationele databases leidt datalogisch of logisch ontwerp tot de ontwikkeling van een databaseschema, d.w.z. sets van relatieschema's die de objecten van het onderwerpgebied en semantische relaties tussen objecten adequaat modelleren. De basis van de schemacorrectheidsanalyse zijn de functionele afhankelijkheden tussen de databaseattributen. In sommige gevallen kunnen er ongewenste afhankelijkheden ontstaan ​​tussen relatieattributen, die bijwerkingen en afwijkingen veroorzaken bij het wijzigen van de database. Onder wijziging begrijp de introductie van nieuwe gegevens in de database, het verwijderen van gegevens uit de database en het bijwerken van de waarden van sommige attributen. Om mogelijke anomalieën te elimineren, wordt verondersteld de databaserelaties te normaliseren.

De logische ontwerpfase gaat niet alleen over het ontwerpen van een relatiediagram. Als resultaat van deze fase moeten in de regel de volgende resulterende documenten worden verkregen:

· Beschrijving van het conceptuele schema van de database in termen van het geselecteerde DBMS.

· Beschrijving van externe modellen in termen van het geselecteerde DBMS.

· Beschrijving van declaratieve regels voor het handhaven van database-integriteit.

· Ontwikkeling van procedures voor het handhaven van de semantische integriteit van de database.

Fysiek ontwerp bestaat uit het koppelen van de logische structuur van de database en het fysieke opslagmedium om gegevens zo efficiënt mogelijk te plaatsen, d.w.z. de logische structuur van de database afbeelden op de opslagstructuur. De kwestie van het plaatsen van opgeslagen gegevens in de geheugenruimte, de keuze van effectieve toegangsmethoden tot verschillende componenten van de "fysieke" database, de problemen met het waarborgen van de beveiliging en veiligheid van gegevens worden opgelost. Beperkingen in het logische gegevensmodel worden geïmplementeerd door verschillende DBMS-tools, bijvoorbeeld met behulp van indexen, declaratieve integriteitsbeperkingen, triggers, opgeslagen procedures. Ook in dit geval definiëren beslissingen op het niveau van logische modellering een aantal grenzen waarbinnen het mogelijk is om een ​​fysiek gegevensmodel te ontwikkelen. Evenzo kunnen binnen deze grenzen verschillende beslissingen worden genomen. Relaties in een logisch gegevensmodel moeten bijvoorbeeld worden geconverteerd naar tabellen, maar voor elke tabel kunt u bovendien verschillende indexen declareren die de snelheid van gegevenstoegang verhogen.

Bovendien kunnen parallelle worden gebruikt om de prestaties te verbeteren. Hierdoor kan de database zich op meerdere netwerkcomputers bevinden. Anderzijds kunnen de voordelen van multiprocessorsystemen worden benut.

Om de beveiliging en veiligheid van gegevens te waarborgen, zijn de problemen opgelost met betrekking tot het herstellen van fouten, het maken van back-ups van informatie, het configureren van beveiligingssystemen voor het geselecteerde beveiligingsbeleid, enz.

Opgemerkt moet worden dat sommige moderne relationele DBMS'en voornamelijk fysieke structuren en toegangsmethoden gebruiken op basis van technologie voor bestandsontwerp, waardoor het probleem van fysiek ontwerp in wezen wordt geëlimineerd.

Het is dus duidelijk dat de beslissingen die in elke fase van databasemodellering en -ontwikkeling worden genomen, van invloed zullen zijn op de volgende fasen. daarom een speciale rol wordt gespeeld door de juiste beslissingen te nemen in de vroege stadia van het modelleren.

De essentie van het ontwerpen van databases (DB), evenals van elk ander ontwerpproces, is het creëren van een beschrijving van een nieuw systeem dat voorheen niet in deze vorm bestond en dat, wanneer het is geïmplementeerd, zogenaamd in staat is om onder de juiste omstandigheden te functioneren. Hieruit volgt dat de stadia van databaseontwerp consistent en logisch de essentie van dit proces moeten weerspiegelen.

Inhoud van database-ontwerp en stadia

Het ontwerpidee is gebaseerd op een geformuleerde maatschappelijke behoefte. Deze behoefte heeft een omgeving waarin het voorkomt en een doelgroep van consumenten die het resultaat van het ontwerp zullen gebruiken. Daarom begint het ontwerpproces van de database met het onderzoeken van een bepaalde behoefte vanuit het oogpunt van de klanten en de functionele omgeving van de beoogde locatie. Dat wil zeggen, de eerste fase is het verzamelen van informatie en het definiëren van een model van het onderwerpgebied van het systeem, evenals het bekijken ervan vanuit het oogpunt van de doelgroep. Om de vereisten voor het systeem te bepalen, wordt in het algemeen de reikwijdte van acties bepaald, evenals de grenzen van de databasetoepassingen.

Verder verduidelijkt de ontwerper, die al bepaalde ideeën heeft over wat hij moet creëren, de taken die zogenaamd door de applicatie zijn opgelost, maakt er een lijst van (vooral als de ontwerpontwikkeling een grote en complexe database heeft), verduidelijkt de volgorde van het oplossen problemen en analyseert de gegevens. Zo'n proces is ook een gefaseerd ontwerpwerk, maar meestal worden deze stappen in de ontwerpstructuur geabsorbeerd door de conceptuele ontwerpfase - de fase van het selecteren van objecten, attributen, relaties.

Het creëren van een conceptueel (informatiemodel) omvat de voorlopige vorming van de conceptuele vereisten van gebruikers, inclusief vereisten voor applicaties die mogelijk niet onmiddellijk worden geïmplementeerd, maar rekening houdend met de functionaliteit van het systeem in de toekomst. Omgaan met representaties van object-abstracties van een set (zonder de methoden van fysieke opslag te specificeren) en hun relaties, komt het conceptuele model overeen met de inhoud van het domeinmodel. Daarom wordt in de literatuur de eerste fase van databaseontwerp infologisch ontwerp genoemd.

Vervolgens wordt een afzonderlijke fase (of aanvulling op de vorige) gevolgd door de fase van vorming van vereisten voor de besturingsomgeving, waar de vereisten voor computerbronnen die de werking van het systeem kunnen waarborgen, worden geëvalueerd. Dienovereenkomstig, hoe groter het volume van de ontworpen database, hoe hoger de gebruikersactiviteit en de intensiteit van verzoeken, hoe hoger de vereisten voor bronnen: voor de computerconfiguratie, voor het type en de versie van het besturingssysteem. Het gebruik door meerdere gebruikers van een toekomstige database vereist bijvoorbeeld een netwerkverbinding met een besturingssysteem dat geschikt is voor multitasking.

De volgende stap moet de ontwerper een databasebeheersysteem (DBMS) kiezen, evenals softwaretools. Daarna moet het conceptuele model worden overgezet naar een datamodel dat compatibel is met het geselecteerde besturingssysteem. Maar vaak wordt dit geassocieerd met de introductie van amendementen en wijzigingen in het conceptuele model, aangezien niet altijd de relaties van objecten met elkaar, weerspiegeld door het conceptuele model, kunnen worden geïmplementeerd met behulp van dit DBMS.

Deze omstandigheid bepaalt de opkomst van de volgende fase - de opkomst van een specifiek door DBMS ondersteund conceptueel model. Deze stap komt overeen met de fase van logisch ontwerp (creatie van een logisch model).

Ten slotte is de laatste fase van databaseontwerp het fysieke ontwerp - de fase van het koppelen van de logische structuur en de fysieke opslagomgeving.

Zo worden de belangrijkste fasen van het ontwerp in een gedetailleerde vorm weergegeven door de fasen:

• infologisch ontwerp,
• opstellen van eisen aan de werkomgeving
• keuze van besturingssysteem en databasesoftware,
• logisch ontwerp,
• fysiek ontwerp

De belangrijkste zullen hieronder in meer detail worden besproken.

infologisch ontwerp

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

• beschrijving van objecttypen,
• de integriteitsbeperkingen die horen bij het beschreven type,
• processen die leiden tot de evolutie van het vakgebied - de overgang naar een andere staat.

Een infologisch model kan op verschillende manieren en benaderingen worden gemaakt:

1. De functionele benadering is gebaseerd op de gestelde taken. Het wordt functioneel genoemd omdat het wordt gebruikt als de functies en taken bekend zijn van personen die met behulp van de ontworpen database in hun informatiebehoefte zullen voorzien.
2. De onderwerpbenadering richt zich op informatie over de informatie die in de database komt te staan, ondanks het feit dat de structuur van queries mogelijk niet vastligt. In dit geval laten ze zich bij het onderzoek van het vakgebied leiden door de meest geschikte weergave ervan in de database in de context van het volledige scala aan veronderstelde informatieverzoeken.
3. Een geïntegreerde aanpak op basis van de "entiteit-relatie"-methode combineert de voordelen van de twee voorgaande. De methode is beperkt tot het opdelen van het hele vakgebied in lokale delen, die afzonderlijk worden gemodelleerd en vervolgens weer worden gecombineerd tot één gebied.

Aangezien het gebruik van de entiteit-relatiemethode in dit stadium een ​​gecombineerde ontwerpmethode is, wordt het vaker een prioriteit dan andere.

Lokale vertegenwoordigingen met methodische scheiding zouden, indien mogelijk, informatie moeten bevatten die voldoende zou zijn om een ​​afzonderlijk probleem op te lossen of om verzoeken te verstrekken aan een groep potentiële gebruikers. Elk van deze gebieden bevat ongeveer 6-7 entiteiten en komt overeen met een afzonderlijke externe applicatie.

De afhankelijkheid van entiteiten wordt weerspiegeld in hun verdeling in sterk (basis, ouder) en zwak (kind). Een sterke entiteit (bijvoorbeeld een lezer in een bibliotheek) kan op zichzelf in de database bestaan, terwijl een zwakke entiteit (bijvoorbeeld het abonnement van deze lezer) "gehecht" is aan een sterke en niet afzonderlijk bestaat.

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 set 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;
• enkelvoudig of meerwaardig (met het juiste aantal waarden voor een entiteitsinstantie);
• basis (onafhankelijk van andere attributen) of afgeleiden (berekend op basis van de waarden van andere attributen);
• eenvoudig (ondeelbaar uit één component) of samengesteld (gecombineerd uit meerdere componenten).

Daarna worden de specificatie van het attribuut, de specificatie van de links in de lokale representatie (onderverdeeld in optioneel en verplicht) en de vereniging van lokale representaties uitgevoerd.Met maximaal 4-5 lokale regio's kunnen ze worden gecombineerd in één stap. Bij een toename van het aantal vindt de binaire samenvoeging van gebieden in verschillende fasen plaats.

Tijdens deze en andere tussenliggende fasen komt het iteratieve karakter van het ontwerp tot uiting, wat hier tot uiting komt in het feit dat het, om tegenstellingen te elimineren, nodig is om terug te keren naar het stadium van het modelleren van lokale representaties voor verduidelijking en verandering (bijvoorbeeld om dezelfde namen van semantisch verschillende objecten te wijzigen of om het eens te worden over integriteitsattributen voor dezelfde attributen in verschillende toepassingen).

Keuze van besturingssysteem en databasesoftware

De praktische invulling van het informatiesysteem hangt af van de keuze van het databasemanagementsysteem. De belangrijkste criteria in het selectieproces zijn de parameters:

• type gegevensmodel en de overeenstemming ervan met de behoeften van het vakgebied,
• marge bij uitbreiding van het informatiesysteem,
• prestatiekenmerken van het geselecteerde systeem,
• bedrijfszekerheid en gemak van het DBMS,
• tooling gericht op gegevensbeheerpersoneel,
• de kosten van het DBMS zelf en aanvullende software.

Fouten bij de keuze van DBMS zullen vrijwel zeker later aanleiding geven tot aanpassing van de conceptuele en logische modellen.

Logisch databaseontwerp

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

Bij voorkeur komt de natuurlijke datastructuur overeen met het model dat deze representeert. Dus als de gegevens bijvoorbeeld worden gepresenteerd in de vorm van een hiërarchische structuur, dan is het beter om een ​​hiërarchisch model te kiezen. In de praktijk wordt een dergelijke keuze echter vaker bepaald door het databasemanagementsysteem en niet door het datamodel. Het conceptuele model wordt dus daadwerkelijk vertaald naar een datamodel dat compatibel is met het geselecteerde databasemanagementsysteem.

De aard van het ontwerp wordt hier ook weerspiegeld, wat de mogelijkheid (of noodzaak) biedt om terug te keren naar het conceptuele model om het te wijzigen als de relaties tussen objecten (of objectattributen) die daar worden weergegeven, niet kunnen worden geïmplementeerd met behulp van de middelen van het geselecteerde DBMS.

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

Databaseschema's worden gegenereerd met behulp van een van de volgende twee uiteenlopende benaderingen:

• of een bottom-upbenadering gebruiken, wanneer wordt gewerkt vanuit de lagere niveaus van attribuutdefinitie, gegroepeerd in relaties die objecten vertegenwoordigen, gebaseerd op de relaties die tussen attributen bestaan;
• of met behulp van de omgekeerde, top-down benadering, toegepast met een significante (tot honderden en duizenden) toename van het aantal attributen.

De tweede benadering omvat de definitie van een aantal entiteiten op hoog niveau en hun relaties, gevolgd door detaillering tot het gewenste niveau, hetgeen bijvoorbeeld een weerspiegeling is van een model dat is opgesteld op basis van de "entiteit-relatie"-methode. In de praktijk worden beide benaderingen echter 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 database-opslagstructuur, dat wil zeggen gekoppeld aan zo'n fysiek opslagmedium waar de gegevens zo efficiënt mogelijk worden geplaatst. Hier wordt het gegevensschema in detail beschreven, waarbij alle typen, velden, groottes en beperkingen worden aangegeven. Naast het ontwikkelen van indexen en tabellen, worden basisquery's gedefinieerd.

De constructie van een fysiek model wordt in veel opzichten geassocieerd met het oplossen van tegenstrijdige problemen:

1. problemen met het minimaliseren van gegevensopslagruimte,
2. doelstellingen om integriteit, veiligheid en maximale prestaties te bereiken.

De tweede taak conflicteert met de eerste omdat bijvoorbeeld:

• voor een efficiënte werking van transacties moet u schijfruimte reserveren voor tijdelijke objecten,
• om de zoeksnelheid te verhogen, moet u indexen maken, waarvan het aantal wordt bepaald door het aantal van alle mogelijke combinaties van velden die bij de zoekopdracht betrokken zijn,
• om de gegevens te herstellen, wordt er een back-up van de database gemaakt en wordt een logboek bijgehouden van alle wijzigingen.

Dit alles vergroot de omvang van de database, dus de ontwerper zoekt naar een redelijk evenwicht waarin taken optimaal worden opgelost door gegevens vakkundig in geheugenruimte te plaatsen, maar niet ten koste van 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 geëvalueerd (zoeksnelheid, efficiëntie van de uitvoering van query's en verbruik van bronnen, correctheid van bewerkingen). Soms wordt deze fase, net als de fasen van database-implementatie, testen en optimalisatie, evenals onderhoud en bediening, buiten het bereik van het directe databaseontwerp gehouden.