2.1. Koncept design

Databasedesign udføres i tre faser:

  1. koncept design;
  2. logisk design;
  3. fysisk design.

Formålet med den konceptuelle designfase er at skabe en konceptuel datamodel baseret på brugernes forestillinger om fagområdet. For at opnå det udføres en række sekventielle procedurer. Et eksempel på et enhedsskema (konceptuelt):

1. Definition af enheder og deres dokumentation. For at identificere entiteter defineres objekter, der eksisterer uafhængigt af andre. Sådanne objekter er enheder. Hver enhed får et meningsfuldt navn, som brugerne kan forstå. Navne og beskrivelser af enhederne indtastes i dataordbogen. Hvis det er muligt, indstilles det forventede antal forekomster af hver enhed.

2. Fastlæggelse af relationer mellem enheder og deres dokumentation. Kun de relationer mellem enheder er defineret, som er nødvendige for at opfylde databasedesignkravene. Typen af ​​hver er indstillet. Medlemskabsklassen af ​​enheder afsløres. Links tildeles meningsfulde navne udtrykt ved verber. En detaljeret beskrivelse af hver forbindelse, med angivelse af dens type og tilhørsklasse for de enheder, der deltager i forbindelsen, er indtastet i dataordbogen.

3. Oprettelse af en ER-model af fagområdet. ER-diagrammer bruges til at repræsentere enheder og relationer mellem dem. Ud fra dem skabes et enkelt visuelt billede af det modellerede emneområde - ER-modellen af ​​emneområdet.

4. Definition af attributter og deres dokumentation. Alle attributter, der beskriver entiteterne i den oprettede ER-model, afsløres. Hver egenskab får et meningsfuldt navn, som brugerne kan forstå. Følgende oplysninger gemmes i dataordbogen for hver attribut:

  • attributnavn og beskrivelse;
  • type og dimension af værdier;
  • standardværdien for attributten (hvis nogen);
  • om attributten kan have NULL-værdier;
  • om attributten er sammensat, og i givet fald hvilke simple attributter den består af. For eksempel kan attributten "Kundens fulde navn" bestå af simple attributter "Efternavn", "Fornavn", "Patronym", eller den kan være enkel, indeholdende enkelte værdier, såsom "Sidorsky Evgeniy Mikhailovich". Hvis brugeren ikke har brug for adgang til individuelle elementer i "Navn", så præsenteres attributten som enkel;
  • om attributten beregnes, og i så fald hvordan dens værdier beregnes.
Java webinar

5. Definition af attributværdier og deres dokumentation. For hver egenskab for en enhed, der deltager i ER-modellen, bestemmes et sæt gyldige værdier, og det tildeles et navn. For eksempel kan attributten "Kontotype" kun have værdierne "indbetaling", "aktuel", "på anfordring", "kortkonto". Dataordbogsposterne relateret til attributterne opdateres med navnene på attributværdisættene.

6. Definition af primære nøgler for enheder og deres dokumentation. Dette trin er styret af definitionen af ​​en primær nøgle - som en attribut eller et sæt attributter for en enhed, der tillader entydig identifikation af dens forekomster. Primære nøgleoplysninger placeres i dataordbogen.

7. Diskussion af den konceptuelle datamodel med slutbrugere. Den konceptuelle datamodel er repræsenteret ved en ER-model med tilhørende dokumentation indeholdende en beskrivelse af den udviklede datamodel. Hvis der konstateres domæne-inkonsekvenser, foretages der ændringer i modellen, indtil brugerne bekræfter, at den model, de foreslår, afspejler deres personlige synspunkter tilstrækkeligt.

2.2 Logisk design

Formålet med den logiske designfase er at transformere den konceptuelle model baseret på den valgte datamodel til en logisk model, der er uafhængig af funktionerne i det DBMS, der senere bruges til den fysiske implementering af databasen. For at opnå det udføres følgende procedurer.

Et eksempel på et logisk databaseskema.

1. Valg af datamodel. Oftest vælges en relationel datamodel på grund af klarheden i den tabelformede præsentation af data og bekvemmeligheden ved at arbejde med dem.

2. Definere et sæt tabeller baseret på ER-modellen og dokumentere dem. Der oprettes en tabel for hver enhed i ER-modellen. Enhedsnavn er navnet på tabellen. Relationer mellem tabeller etableres gennem mekanismen med primære og fremmede nøgler. Tabellernes strukturer og de etablerede relationer mellem dem er dokumenteret.

3. Normalisering af tabeller. For korrekt at udføre normalisering skal designeren dybt forstå dataenes semantik og brugsmønstre. På dette trin kontrollerer han rigtigheden af ​​strukturen af ​​tabellerne oprettet i det foregående trin ved at anvende normaliseringsproceduren på dem. Det består i at bringe hvert af bordene til mindst 3. NF. Som følge af normalisering opnås et meget fleksibelt databasedesign, som gør det nemt at lave de nødvendige udvidelser til den.

4. Kontrol af den logiske datamodel for muligheden for at udføre alle transaktioner leveret af brugere. En transaktion er et sæt handlinger udført af en individuel bruger eller et applikationsprogram for at ændre indholdet af en database. Så et eksempel på en transaktion i BANK-projektet kan være overførsel af retten til at administrere en bestemt kundes konti til en anden kunde. I dette tilfælde skal der foretages flere ændringer i databasen på én gang. Hvis en computer går ned under en transaktion, vil databasen være i en inkonsistent tilstand, fordi nogle ændringer allerede er foretaget, og andre ikke er. Derfor skal alle delvise ændringer fortrydes for at returnere databasen til dens tidligere konsistente tilstand.

Listen over transaktioner bestemmes af brugernes handlinger i emneområdet. Ved at bruge ER-modellen, dataordbogen og etablerede relationer mellem primære og fremmede nøgler, forsøges alle nødvendige dataadgangshandlinger manuelt. Hvis nogen manuel betjening mislykkes, er den kompilerede logiske datamodel utilstrækkelig og indeholder fejl, der skal elimineres. Måske er de relateret til et hul i modellen for en enhed, et forhold eller en egenskab.

5. Fastlæggelse af dataintegritetsstøttekrav og deres dokumentation. Disse krav er begrænsninger, der er sat på plads for at forhindre modstridende data i at blive indtastet i databasen. På dette trin er dataintegritetsspørgsmål dækket uden hensyntagen til specifikke aspekter af dets implementering. Følgende typer begrænsninger bør overvejes:

  • nødvendige data. At finde ud af, om der er attributter, der ikke kan have NULL-værdier;
  • restriktioner på attributværdier. Gyldige værdier for attributter er defineret;
  • enheds integritet. Det opnås, hvis entitetens primære nøgle ikke indeholder NULL-værdier;
  • referentiel integritet. Det er underforstået, at den fremmede nøgleværdi skal være til stede i den primære nøgle i en af ​​tabelrækkerne for den overordnede enhed;
  • restriktioner pålagt af forretningsregler. I tilfælde af BANK-projektet kan der f.eks. vedtages en regel, der forbyder kunden at administrere f.eks. mere end tre konti.

Oplysninger om alle etablerede dataintegritetsbegrænsninger placeres i dataordbogen.

6. Oprettelse af den endelige version af den logiske datamodel og diskussion med brugere. Dette trin forbereder den endelige version af ER-modellen, som repræsenterer den logiske datamodel. Selve modellen og opdateret dokumentation, herunder dataordbogen og relationelt tabellinkskema, præsenteres til gennemsyn og analyse af brugere, som skal sikre, at den repræsenterer emneområdet nøjagtigt.

2.3. Fysisk design

Formålet med den fysiske designfase er at beskrive en specifik implementering af en database placeret i den eksterne hukommelse på en computer. Dette er en beskrivelse af datalagringsstrukturen og effektive metoder til at få adgang til databasedata. I logisk design svarer de på spørgsmålet - hvad skal der gøres, og i fysisk design - vælges en måde, hvordan det skal gøres. De fysiske designprocedurer er som følger.

1. Design af databasetabeller ved hjælp af det valgte DBMS. En relationel DBMS er valgt til at blive brugt til at oprette en database hostet på maskinmedier. Dens funktionalitet til at designe borde er dybt undersøgt. Derefter udføres designet af tabeller og skemaet for deres forbindelse i DBMS-miljøet. Det udarbejdede databaseprojekt er beskrevet i den medfølgende dokumentation.

2. Implementering af forretningsregler i miljøet af det valgte DBMS. Opdatering af oplysninger i tabeller kan begrænses af forretningsregler. Måden de implementeres på afhænger af det valgte DBMS. Nogle systemer til implementering af kravene til fagområdet tilbyder flere funktioner, andre mindre. I nogle systemer er der slet ingen støtte til at implementere forretningsregler. I dette tilfælde udvikles applikationer til at implementere deres begrænsninger.

Alle beslutninger truffet i forbindelse med implementering af domæneforretningsregler er detaljeret beskrevet i den medfølgende dokumentation.

3. Design af databasens fysiske organisering. Dette trin vælger den bedste filorganisation til tabellerne. De transaktioner, der vil blive udført i databasen, der designes, identificeres, og de vigtigste af dem fremhæves. Transaktionsgennemstrømning analyseres - antallet af transaktioner, der kan behandles i et givet tidsinterval, og responstid - det tidsrum, der kræves for at gennemføre en transaktion. De stræber efter at øge transaktionsgennemstrømningen og reducere responstiden.

På baggrund af disse indikatorer træffes beslutninger om at optimere databasens ydeevne ved at definere indekser i tabeller, der fremskynder udvælgelsen af ​​data fra databasen, eller ved at reducere kravene til niveauet for tabelnormalisering. Den diskplads, der kræves for at rumme den oprettede database, er estimeret. Stræb efter at minimere det.

Beslutninger truffet i ovenstående spørgsmål er dokumenteret.

4. Udvikling af en databasebeskyttelsesstrategi. Databasen er en værdifuld virksomhedsressource, og der lægges stor vægt på dens beskyttelse. For at gøre dette skal designere have en fuldstændig og klar forståelse af alle de beskyttelser, som det valgte DBMS giver.

5. Organisering af databasens funktionsovervågning og justering heraf. Efter oprettelsen af ​​det fysiske projekt af databasen organiseres kontinuerlig overvågning af dens funktion. Den resulterende information om databasens ydeevneniveau bruges til at tune den. Til dette inddrages også midlerne fra det valgte DBMS.

Beslutninger om at foretage ændringer i en fungerende database bør overvejes og vejes grundigt.