Database design stadier

Det er umuligt at lave en database uden en detaljeret beskrivelse af den, ligesom det ikke er muligt at lave noget komplekst produkt uden en tegning og en detaljeret beskrivelse af teknologierne til dets produktion. Vi har med andre ord brug for et projekt. Projekt Det er generelt accepteret at overveje en skitse af en eller anden enhed, som senere vil blive oversat til virkelighed.

Databasedesignprocessen er en overgangsproces fra en uformel verbal beskrivelse af informationsstrukturen emneområde til en formaliseret beskrivelse af domæneobjekter i form af en bestemt model. Det ultimative mål med design er at bygge en specifik database. Naturligvis er designprocessen kompleks, og derfor giver det mening at opdele den i logisk afsluttede dele - stadier.

Der er fem hovedfaser af databasedesign:

1. Indsamling af information og systemanalyse af fagområdet.

2. Infologisk design.

3. Valg af et DBMS.

4. Datalogisk design.

5. Fysisk design.

Indsamling af information og systemanalyse af fagområdet- dette er den første og den vigtigste fase ved design af en database. Det kræver detaljeret verbal beskrivelse objekter i emneområdet og reelle forbindelser til stede mellem virkelige objekter. Det er ønskeligt, at beskrivelsen definerer relationerne mellem objekter i emneområdet.

Generelt er der to tilgange til at vælge et fagområdes sammensætning og struktur:

· Funktionel tilgang– bruges, når funktionerne for en bestemt gruppe af personer og de sæt af opgaver, som denne database er oprettet til, er kendt på forhånd, dvs. det mindst nødvendige sæt af domæneobjekter til beskrivelse er tydeligt identificeret.

· Faglig tilgang– når databasekundernes informationsbehov ikke er klart registreret og kan være multidimensionelle og dynamiske. I I dette tilfælde minimum sæt Det er svært at vælge domæneobjekter. Beskrivelsen af ​​emneområdet omfatter sådanne objekter og relationer, der er mest karakteristiske og væsentlige for det. Samtidig bliver databasen emnespecifik og er velegnet til at løse mange problemer (hvilket virker mest fristende). Vanskeligheden ved universel dækning af fagområdet og umuligheden af ​​at specificere brugerbehov fører imidlertid til overflødig kompleks ordning En database, der vil være ineffektiv til nogle opgaver.

Systemanalyse skal afsluttes Detaljeret beskrivelse oplysninger om objekter i emneområdet, som skal gemmes i databasen, med formuleringen specifikke opgaver, som vil blive løst ved hjælp af denne database med Kort beskrivelse algoritmer til deres løsning, beskrivelse af output og input dokumenter ved arbejde med databasen.

Infologisk design– en delvist formaliseret beskrivelse af objekter i fagområdet i form af en bestemt semantisk model.

Hvorfor er der brug for en informationsmodel, og hvordan gavner den designere? Faktum er, at designprocessen er lang og kræver diskussioner med kunden og fageksperter. Hertil kommer, når man udvikler seriøs corporate informationssystemer databaseprojektet er grundlaget for hele systemet som helhed, og spørgsmålet om muligheden for udlån afgøres ofte af bankeksperter på baggrund af et gennemarbejdet informationsdatabaseprojekt. Derfor bør informationsmodellen omfatte en sådan formaliseret beskrivelse af fagområdet, som ikke kun vil kunne opfattes af databasespecialister. Beskrivelsen skal være så rummelig, at man kan vurdere dybden og rigtigheden af ​​udviklingen af ​​databaseprojektet.

I dag er Chens Entity Relationship-model blevet den mest udbredte; den er blevet de facto-standarden inden for informationsmodellering og kaldes ER-modellen.

Valg af et DBMS udføres på grundlag af forskellige krav til databasen og dermed DBMS'ens muligheder samt afhængigt af udviklernes eksisterende erfaring.

Datalogisk design der er en beskrivelse af databasen i forhold til den accepterede dato logisk model data. I relationelle databaser fører datalogisk eller logisk design til udvikling af databaseskemaet, dvs. sæt af relationsskemaer, der tilstrækkeligt modellerer objekter i emneområdet og semantiske relationer mellem objekter. Grundlaget for at analysere rigtigheden af ​​et skema er de funktionelle afhængigheder mellem databaseattributter. I nogle tilfælde kan der opstå uønskede afhængigheder mellem relationsattributter, der forårsager bivirkninger og uregelmæssigheder under databaseændring. Under modifikation forstå indtastning af nye data i databasen, sletning af data fra databasen, samt opdatering af værdierne for nogle attributter. For at eliminere mulige anomalier er det planlagt at normalisere databaserelationer.

Den logiske designfase handler ikke kun om at designe relationsdiagrammet. Som et resultat af denne fase skal følgende resulterende dokumenter som regel indhentes:

· Beskrivelse af databasens konceptuelle skema i forhold til det valgte DBMS.

· Beskrivelse eksterne modeller i forhold til det valgte DBMS.

· Beskrivelse af deklarative regler for vedligeholdelse af databasens integritet.

· Udvikling af procedurer til vedligeholdelse af databasens semantiske integritet.

Fysisk design er at linke logisk struktur DB og fysisk lagermiljø med henblik på den mest effektive placering af data, dvs. kortlægning af databasens logiske struktur til lagerstrukturen. Spørgsmålet om at placere lagrede data i hukommelsesplads, valg effektive metoder adgang til forskellige komponenter"fysisk" database, problemer med at sikre datasikkerhed og sikkerhed er løst. De begrænsninger, der findes i den logiske datamodel, implementeres af forskellige DBMS-værktøjer, for eksempel ved hjælp af indekser, deklarative integritetsbegrænsninger, triggere og lagrede procedurer. I dette tilfælde bestemmer beslutninger truffet på det logiske modelleringsniveau igen nogle grænser, inden for hvilke den fysiske datamodel kan udvikles. Ligeledes inden for disse grænser kan man acceptere forskellige løsninger. For eksempel skal relationerne indeholdt i den logiske datamodel konverteres til tabeller, men forskellige indekser kan valgfrit deklareres på hver tabel for at forbedre hastigheden for at få adgang til dataene.

Derudover kan funktioner bruges til at forbedre ydeevnen. parallel bearbejdning data. Som følge heraf kan databasen være placeret på flere netværkscomputere. På den anden side kan fordelene ved multiprocessorsystemer udnyttes.

For at sikre datasikkerheden er problemer med gendannelse efter fejl løst, Reserve eksemplar information, opsætning af beskyttelsessystemer, der passer til den valgte sikkerhedspolitik mv.

Det skal bemærkes, at nogle moderne relationel DBMS bruger primært fysiske strukturer og adgangsmetoder baseret på fildesignteknologi, hvilket i det væsentlige eliminerer spørgsmålet om fysisk design.

Det er således klart, at beslutninger, der træffes på hvert trin af modellering og databaseudvikling, vil påvirke de efterfølgende trin. Derfor accept spiller en særlig rolle rigtige beslutninger på tidlige stadier modellering.

Database design trin

Alle konstruktionens finesser informationsmodel inden for et eller andet fagområde for menneskelig aktivitet forfølger de ét mål - at få en god database. Lad os forklare begrebet – en god database og formulere de krav, en sådan database skal opfylde:

1. Databasen skal tilfredsstille brugernes (organisationernes) informationsbehov og i struktur og indhold svare til de opgaver, der løses;

2. Databasen skal levere de nødvendige data inden for en acceptabel tid, dvs. opfylde præstationskrav;

3. Databasen bør let kunne udvides, når fagområdet reorganiseres;

4. Databasen skal være nem at ændre, når software- og hardwaremiljøet ændres;

5. Korrekte data indlæst i databasen skal forblive korrekte (data skal kontrolleres for korrekthed, når de indtastes).

Lad os overveje de vigtigste faser af design (fig. 3.5):

Første etape. Planlægning af databaseudvikling. På dette stadium den mest fremtrædende effektiv metode implementering af etaper livscyklus systemer.

Anden fase. Fastlæggelse af systemkrav. Databaseapplikationens omfang og grænser bestemmes, og brugerkrav indsamles og analyseres.

Tredje etape. Design konceptuel model DB. Processen med at skabe en database begynder med at definere en konceptuel model, der repræsenterer objekter og deres relationer uden at specificere, hvordan de fysisk opbevares. Indsatsen på dette stadium bør være rettet mod at strukturere dataene og identificere sammenhænge mellem dem. Denne proces kan opdeles i flere undertrin:

a) Afklaring af problemet. Selv før arbejdet påbegyndes specifik anvendelse Udvikleren har normalt en ide om, hvad han vil udvikle. I andre tilfælde, når en lille personlig database udvikles, kan sådanne visninger være ret komplette. I andre tilfælde, når en stor brugerdefineret database udvikles, kan der være meget få sådanne visninger, eller de vil højst sandsynligt være overfladiske. Det er klart for tidligt at starte udviklingen med det samme ved at definere tabeller, felter og relationer mellem dem. Denne tilgang kan resultere i et fuldstændigt redesign af meget af applikationen. Derfor bør du bruge lidt tid på at lave en liste over alle de hovedopgaver, som denne applikation i princippet skal løse, også dem der måtte opstå i fremtiden.

Ris. 3.5. Database design diagram

b) Afklaring af rækkefølgen af ​​opgaver. For at få applikationen til at fungere logisk og bekvemt, er det bedst at organisere hovedopgaverne i grupper og derefter organisere hver gruppes opgaver, så de er arrangeret i den rækkefølge, de er udført. Gruppering og grafisk fremstilling Rækkefølgen af ​​deres udførelse vil hjælpe med at bestemme den naturlige rækkefølge af opgaver.

c) Dataanalyse. Efter at have bestemt listen over opgaver, er det nødvendigt at oprette for hver opgave detaljeret liste nødvendige data for at løse det. Efter dataanalysefasen kan du begynde at udvikle en konceptuel model, dvs. at fremhæve objekter, egenskaber og relationer.

Fjerde etape. Konstruktion af en logisk model. Opbygning af en logisk model begynder med at vælge en datamodel. Ved valg af model vigtig rolle dens enkelhed, klarhed og sammenligning af den naturlige datastruktur med modellen, der repræsenterer den, spiller en rolle. For eksempel, hvis hierarkisk struktur er iboende i selve dataene, vil det være at foretrække at vælge en hierarkisk model. Men ofte er dette valg bestemt af succesen (eller tilgængeligheden) af et eller andet DBMS. Det vil sige, at udvikleren vælger DBMS, ikke datamodellen. På dette stadium er den konceptuelle model således oversat til en datamodel, der er kompatibel med det valgte DBMS. Det er muligt, at relationerne mellem objekter eller nogle attributter af objekter, der vises i den konceptuelle model, efterfølgende vil vise sig at være urealiserbare af det valgte DBMS. Dette vil kræve en ændring i den konceptuelle model. Den version af en konceptuel model, der kan leveres af et bestemt DBMS, kaldes logisk model. Processen med at definere konceptuelle og logiske modeller kaldes nogle gange datastrukturdefinition.

Femte etape. Konstruktion fysisk model. Den fysiske model definerer datalayout, adgangsmetoder og indekseringsteknikker. På det fysiske designstadium bliver vi bundet til et specifikt DBMS og beskriver dataskemaet mere detaljeret med angivelse af typer, feltstørrelser og begrænsninger. Ud over at designe tabeller og indekser involverer denne fase også at definere grundlæggende forespørgsler.

Når man konstruerer en fysisk model, skal man løse to indbyrdes modsatte problemer. Den første af disse er at minimere datalagerplads, og den anden er at opnå maksimal ydeevne, dataintegritet og sikkerhed. For eksempel for at sikre høj hastighed søgning, er det nødvendigt at oprette indekser, og deres antal vil blive bestemt af alle mulige kombinationer af felter, der deltager i søgningen; For at gendanne data skal du føre en log over alle ændringer og oprette databasesikkerhedskopier; Til effektivt arbejde transaktioner kræver, at der reserveres diskplads til midlertidige objekter osv., hvilket fører til en stigning (nogle gange betydelig) i størrelsen af ​​databasen.

Sjette etape. Evaluering af den fysiske model. På dette stadium foretages en vurdering præstationsegenskaber. Her kan du kontrollere effektiviteten af ​​udførelse af forespørgsler, søgehastighed, korrekthed og lethed ved at udføre databaseoperationer, dataintegritet og effektivitet af computerressourcer. Hvis ydeevneegenskaberne er utilfredsstillende, er det muligt at vende tilbage til revisionen af ​​de fysiske og logiske datamodeller, valget af et DBMS og typen af ​​computer.

Syvende etape. Implementering af databasen. Hvis ydeevnen er tilfredsstillende, kan du gå videre til at oprette applikationslayoutet, det vil sige et sæt grundlæggende tabeller, forespørgsler, formularer og rapporter. Denne foreløbige mockup kan demonstreres for kunden og opnås godkendelse før den detaljerede implementering af applikationen.

Ottende etape. Test og optimering. En obligatorisk fase er test og optimering af den udviklede applikation.

Etape ni, sidste. Vedligeholdelse og drift. Da det ikke er muligt at identificere og eliminere alle fejl på teststadiet, er vedligeholdelsesstadiet normalt for databaser.

Der er to hovedtilgange til dataskemadesign: top-down og bottom-up. Med en bottom-up tilgang begynder arbejdet på det lavere niveau - niveauet for at definere attributter, som baseret på en analyse af de relationer, der eksisterer mellem dem, grupperes i relationer, der repræsenterer objekter og forbindelser mellem dem. Tabel normaliseringsproces for relationel model data er et typisk eksempel på denne tilgang. Denne tilgang er velegnet til at designe relativt små databaser. Når antallet af attributter stiger til flere hundrede eller endda tusinder, er en top-down tilgang en mere passende designstrategi. Denne tilgang begynder med at definere flere enheder på højt niveau og relationerne mellem dem. Disse objekter er derefter detaljeret til påkrævet niveau. Et eksempel på denne designtilgang er brugen af ​​en enhedsrelationsmodel. I praksis kombineres disse tilgange normalt. I dette tilfælde kan vi tale om en blandet designtilgang.

Essensen af ​​databasedesign er, som enhver anden designproces, at skabe en beskrivelse af et nyt system, der ikke tidligere har eksisteret i denne form, som, når det implementeres, er i stand til at forventes at fungere under passende forhold. Det følger heraf, at faserne af databasedesign konsekvent og logisk skal afspejle essensen af ​​denne proces.

Indhold af databasedesign og faseinddeling

Designhensigten er baseret på et eller andet formuleret socialt behov. Dette behov har et miljø for dets forekomst og en målgruppe af forbrugere, der vil bruge designresultatet. Derfor begynder databasedesignprocessen med at studere et givet behov fra forbrugernes synspunkt og det funktionelle miljø for dens tilsigtede placering. Det vil sige, at den første fase er at indsamle information og definere en model af systemets fagområde samt at se på det fra et synspunkt målgruppe. Generelt, for at bestemme systemkrav, bestemmes omfanget af aktiviteter såvel som grænserne for databaseapplikationer.

Dernæst afklarer designeren, som allerede har visse ideer om, hvad han skal skabe, de opgaver, der angiveligt er løst af applikationen, opretter en liste over dem (især hvis projektudviklingen er en stor og kompleks database), præciserer rækkefølgen af ​​løsningen. problemer og udfører dataanalyse. Denne proces er også en trin-for-trin proces. projekt arbejde, men normalt i designstrukturen absorberes disse trin af det konceptuelle designstadium - stadiet med at identificere objekter, attributter og forbindelser.

Oprettelse af en konceptuel (informationsmodel) indebærer den foreløbige dannelse af konceptuelle brugerkrav, herunder krav til applikationer, der måske ikke umiddelbart implementeres, men under hensyntagen til, hvilke vil forbedre systemets funktionalitet i fremtiden. Når man beskæftiger sig med repræsentationer af sæt abstraktionsobjekter (uden at specificere fysiske lagringsmetoder) og deres relationer, svarer den konceptuelle model i det væsentlige til domænemodellen. Derfor kaldes den første fase af databasedesign i litteraturen for infologisk design.

Dernæst følger som et separat trin (eller en tilføjelse til det foregående) fasen med at stille krav til driftsmiljøet, hvor kravene til computerressourcer, der er i stand til at sikre systemets funktion. Følgelig, jo større volumen af ​​den designede database, jo højere brugeraktivitet og intensitet af anmodninger, jo højere krav til ressourcer: til computerkonfigurationen, for typen og versionen operativ system. For eksempel multi-user mode fremtidig base nødvendige data netværks forbindelse ved hjælp af et styresystem, der er egnet til multitasking.

Det næste trin er for designeren at vælge et databasestyringssystem (DBMS), samt værktøjer programmatisk karakter. Herefter skal den konceptuelle model overføres til en datamodel, der er kompatibel med det valgte ledelsessystem. Men ofte involverer dette at foretage ændringer og ændringer i den konceptuelle model, da sammenkoblingerne mellem objekter, der afspejles i den konceptuelle model, ikke altid kan implementeres ved hjælp af en given DBMS.

Denne omstændighed bestemmer fremkomsten af ​​det næste trin - fremkomsten af ​​en konceptuel model forsynet med midlerne fra et specifikt DBMS. Dette trin svarer til stadiet af logisk design (oprettelse af en logisk model).

Endelig er den sidste fase af databasedesign fysisk design - stadiet med at forbinde den logiske struktur og det fysiske lagermiljø.

Således præsenteres hovedstadierne af design i detaljeret form i følgende faser:

• informationsdesign,
• dannelse af krav til driftsmiljøet
• valg af styresystem og software DB,
• logisk design,
• fysisk design

De vigtigste vil blive diskuteret mere detaljeret nedenfor.

Infologisk design

Identifikation af entiteter danner det semantiske grundlag for infologisk design. En enhed her er et objekt (abstrakt eller konkret), hvorom information vil blive akkumuleret i systemet. I informationsmodellen for fagområdet i brugervenlig i termer, der ikke afhænger af den specifikke implementering af databasen, beskrives fagområdets struktur og dynamiske egenskaber. Men vilkårene er taget på en standardskala. Det vil sige, at beskrivelsen ikke udtrykkes gennem individuelle objekter i emneområdet og deres relationer, men gennem:

• beskrivelse af objekttyper,
• integritetsbegrænsninger forbundet med den beskrevne type,
• processer, der fører til udviklingen af ​​et emneområde - dets overgang til en anden tilstand.

En informationsmodel kan oprettes ved hjælp af flere metoder og tilgange:

1. Den funktionelle tilgang tager udgangspunkt i de tildelte opgaver. Det kaldes funktionelt, fordi det bruges, hvis funktioner og opgaver for de personer, der skal betjene deres informationsbehov ved hjælp af den designede database, er kendt.
2. Fagtilgangen fokuserer på information om de oplysninger, der vil være indeholdt i databasen, på trods af at forespørgselsstrukturen muligvis ikke er defineret. I dette tilfælde er forskningen i emneområdet fokuseret på dens mest passende visning i databasen i konteksten fuldt spektrum forventede informationsanmodninger.
3. En integreret tilgang ved hjælp af "entity-relationship"-metoden kombinerer fordelene ved de to foregående. Metoden går ud på at opdele hele fagområdet i lokale dele, som modelleres separat og derefter rekombineres til et helt område.

Siden bruger entity-relation-metoden er kombineret metode design på dette stadium, bliver det oftest en prioritet.

Når de er metodisk opdelt, bør lokale repræsentationer, hvis det er muligt, indeholde oplysninger, der ville være tilstrækkelige til at løse et separat problem eller til at imødekomme ønsker fra en bestemt gruppe potentielle brugere. Hvert af disse områder indeholder omkring 6-7 enheder og svarer til en separat ekstern applikation.

Enheders afhængighed afspejles i deres opdeling i stærke (base, forælder) og svage (barn). En stærk enhed (for eksempel en læser i et bibliotek) kan eksistere i databasen alene, men en svag enhed (f.eks. denne læsers abonnement) er "knyttet" til en stærk og eksisterer ikke separat.

Det er nødvendigt at adskille begreberne "entitetsinstans" (et objekt karakteriseret ved specifikke egenskabsværdier) og begrebet "entitetstype" - et objekt karakteriseret ved et fælles navn og en liste over egenskaber.

For hver enkelt enhed vælges attributter (et sæt egenskaber), som afhængigt af kriteriet kan være:

• identificere sig (med unik værdi for enheder af denne type, hvilket gør dem til potentielle nøgler) eller beskrivende;
• enkeltværdi eller multi-værdi (med det passende antal værdier for en enhedsforekomst);
• grundlæggende (uafhængig af andre attributter) eller afledt (beregnet baseret på værdierne af andre attributter);
• simpel (delelig en-komponent) eller sammensat (sammensat af flere komponenter).

Herefter specificeres attributten, forbindelserne angives i lokalvisningen (opdelt i valgfri og obligatorisk) og lokalvisningerne slås sammen Hvis antallet af lokalområder er op til 4-5, kan de kombineres i et trin . Hvis antallet stiger, sker den binære sammenlægning af områder i flere trin.

Under dette og andre mellemstadier afspejles designs iterative karakter, hvilket her kommer til udtryk i det faktum, at det for at eliminere modsigelser er nødvendigt at vende tilbage til stadiet med modellering af lokale repræsentationer for afklaring og forandring (f.eks. for at ændre de samme navne på semantisk forskellige objekter eller for at koordinere integritetsattributter på samme attributter i forskellige applikationer).

Valg af kontrolsystem og databasesoftware

Den praktiske implementering af informationssystemet afhænger af valget af databasestyringssystemet. De vigtigste kriterier i udvælgelsesprocessen er følgende parametre:

• type datamodel og dens overensstemmelse med fagområdets behov,
• reserve af muligheder i tilfælde af udvidelse af informationssystemet,
• ydelseskarakteristika for det valgte system,
• driftssikkerhed og bekvemmelighed af DBMS,
• værktøjer rettet mod dataadministrationspersonale,
• omkostningerne til selve DBMS og yderligere software.

Fejl ved valg af DBMS vil næsten helt sikkert efterfølgende fremprovokere behovet for at justere de konceptuelle og logiske modeller.

Logisk databasedesign

Den logiske struktur af databasen skal svare til fagområdets logiske model og tage højde for datamodellens forbindelse med det understøttede DBMS. Derfor begynder stadiet med at vælge en datamodel, hvor det er vigtigt at tage højde for dens enkelthed og overskuelighed.

Det er at foretrække, når den naturlige datastruktur falder sammen med den model, der repræsenterer den. Så for eksempel hvis dataene præsenteres i formularen hierarkisk struktur, så er det bedre at vælge en hierarkisk model. Men i praksis er et sådant valg ofte bestemt af databasestyringssystemet frem for af datamodellen. Derfor er den konceptuelle model faktisk oversat til en datamodel, der er kompatibel med det valgte databasestyringssystem.

Dette afspejler også arten af ​​design, som tillader muligheden (eller nødvendigheden) af at vende tilbage til den konceptuelle model for at ændre den, hvis relationerne mellem objekter (eller objektattributter), der afspejles der, ikke kan implementeres ved hjælp af det valgte DBMS.

Efter afslutningen af ​​etapen skal der genereres databaseskemaer for begge arkitekturniveauer (konceptuelt og eksternt), oprettet i det datadefinitionssprog, der understøttes af det valgte DBMS.

Databaseskemaer er dannet ved hjælp af en af ​​to forskellige tilgange:

• eller ved at bruge en bottom-up tilgang, når arbejdet kommer fra de lavere niveauer af at definere attributter, grupperet i relationer, der repræsenterer objekter, baseret på de relationer, der eksisterer mellem attributter;
• eller ved at bruge en omvendt top-down tilgang, der bruges, når antallet af attributter stiger markant (op til hundreder og tusinder).

Den anden tilgang indebærer at identificere en række entiteter på højt niveau og deres relationer med efterfølgende detaljering til det krævede niveau, hvilket eksempelvis afspejles i en model, der er skabt baseret på "entity-relationship"-metoden. Men i praksis kombineres begge tilgange normalt.

Fysisk databasedesign

På næste trin af fysisk design af databasen vises den logiske struktur i form af en databaselagerstruktur, det vil sige, at den er knyttet til en sådan fysiske miljø opbevaring, hvor data vil blive placeret så effektivt som muligt. Her er dataskemaet beskrevet detaljeret, med angivelse af alle typer, felter, størrelser og begrænsninger. Ud over at udvikle indekser og tabeller defineres grundlæggende forespørgsler.

Konstruktionen af ​​en fysisk model involverer løsning af stort set modstridende problemer:

1. opgaver med at minimere datalagerplads,
2. udfordringer for at opnå integritet, sikkerhed og maksimal ydeevne.

Den anden opgave er i konflikt med den første, fordi f.eks.

• for at transaktioner kan fungere effektivt, skal du reservere diskplads til midlertidige objekter,
• for at øge søgehastigheden skal du oprette indekser, hvis antal bestemmes af antallet af alle mulige kombinationer af felter involveret i søgningen,
• til datagendannelse vil blive oprettet sikkerhedskopier database og føre en log over alle ændringer.

Alt dette øger størrelsen af ​​databasen, så designeren leder efter en fornuftig balance, hvor problemer løses optimalt ved intelligent at placere data i hukommelsespladsen, men ikke på bekostning af databasesikkerheden, som omfatter både beskyttelse mod uautoriseret adgang og beskyttelse fra fiaskoer.

For at fuldføre oprettelsen af ​​en fysisk model vurderes dens operationelle karakteristika (søgehastighed, effektivitet af forespørgselsudførelse og ressourceforbrug, korrekthed af operationer). Nogle gange er denne fase, ligesom stadierne af databaseimplementering, test og optimering, samt vedligeholdelse og drift, taget uden for databasens umiddelbare design.

Parameternavn	Betyder
Artiklens emne:	Database design stadier
Rubrik (tematisk kategori)	Forbindelse

Stadier af databasedesign.

Temaer: stadier af databasedesign, databasedesign baseret på en objektrelationsmodel

Inden der oprettes en database, skal udvikleren bestemme, hvilke tabeller databasen skal bestå af, hvilke data der skal placeres i hver tabel, og hvordan tabellerne sammenkædes. Disse problemer er løst på databasedesignstadiet.

Som et resultat af designet skal den logiske struktur af databasen bestemmes, det vil sige sammensætningen af ​​relationelle tabeller, deres struktur og inter-table relationer.

Inden du opretter en database, er det ekstremt vigtigt at have en beskrivelse af det valgte emneområde, som skal dække reelle objekter og processer, identificere alle de nødvendige informationskilder for at tilfredsstille de forventede brugerønsker og bestemme behovene for databehandling.

Ud fra en sådan beskrivelse fastlægges på databasedesignstadiet sammensætningen og strukturen af ​​fagområdedataene, som skal ligge i databasen og sikre opfyldelsen af ​​de nødvendige forespørgsler og brugeropgaver. Fagområdets datastruktur kan vises ved en informationslogisk model. Ud fra denne model kan en relationel database nemt oprettes.

Stadierne af design og oprettelse af en database bestemmes af følgende sekvens:

‣‣‣ opbygning af en informations- og logisk datamodel for fagområdet;

‣‣‣ definition af logisk struktur relationsgrundlag data;

‣‣‣ designe databasetabeller;

‣‣‣ oprettelse af et dataskema;

‣‣‣ indtastning af data i tabeller (oprettelse af poster);

‣‣‣ udvikling af de nødvendige formularer, forespørgsler, makroer, moduler, rapporter;

‣‣‣ udvikling af brugergrænsefladen.

I processen med at udvikle en datamodel er det ekstremt vigtigt at identificere informationsobjekter, der opfylder kravene til datanormalisering og bestemme forholdet mellem dem. Denne model giver dig mulighed for at oprette en relationsdatabase uden duplikering, hvilket sikrer engangsdataindtastning under indledende indlæsning og justeringer, samt dataintegritet, når der foretages ændringer.

Ved udvikling af en datamodel kan der anvendes to tilgange. I den første tilgang Først fastlægges hovedopgaverne for den løsning, som basen er bygget af, opgavernes databehov identificeres, og informationsobjekternes sammensætning og struktur bestemmes i overensstemmelse hermed. På den anden tilgang Typiske objekter fra fagområdet installeres straks. Den mest rationelle kombination af begge tilgange. Dette skyldes, at på indledende fase Der er som udgangspunkt ikke fyldestgørende information om alle opgaver. Brugen af ​​en sådan teknologi er så meget desto mere berettiget, fordi fleksible værktøjer til at skabe relationelle databaser giver dig mulighed for at foretage ændringer i databasen og ændre dens struktur på ethvert udviklingstrin uden at beskadige tidligere indtastede data.

Processen med at identificere informationsobjekter i et fagområde, der opfylder kravene til normalisering, kan udføres på grundlag af en intuitiv eller formel tilgang. Teoretisk grundlag formel tilgang blev udviklet og fuldt præsenteret i monografier om organisering af databaser af den berømte amerikanske videnskabsmand J. Martin.

Med en intuitiv tilgang kan informationsobjekter svarende til rigtige genstande. Samtidig kræver den resulterende informationslogiske model som regel yderligere transformationer, især transformationen af ​​multi-værdiforhold mellem objekter. Med denne tilgang er væsentlige fejl mulige, hvis der ikke er nok erfaring. Efterfølgende verifikation af overholdelse af normaliseringskrav viser normalt den ekstreme vigtighed af afklaring af informationsobjekter.

Lad os overveje de formelle regler, der kan bruges til at identificere informationsobjekter.

‣‣‣ baseret på beskrivelsen af ​​emneområdet identificere dokumenter og deres attributter, der skal gemmes i databasen;

‣‣‣ bestemme funktionelle afhængigheder mellem attributter;

‣‣‣ vælg alle afhængige attributter og angiv for hver alle dens nøgleattributter, dvs. dem, som den afhænger af;

‣‣‣ Gruppér attributter, der er lige så afhængige af nøgleattributter. De resulterende grupper af afhængige attributter danner sammen med deres nøgleattributter informationsobjekter.

Når man definerer den logiske struktur af en relationel database baseret på en model, er hvert informationsobjekt tilstrækkeligt repræsenteret af en relationstabel, og relationerne mellem tabeller svarer til relationerne mellem informationsobjekter.

Under oprettelsesprocessen vil databasetabellerne, der svarer til informationsobjekter konstrueret datamodel. Dernæst kan der oprettes et dataskema, hvori eksisterende logiske forbindelser mellem tabeller registreres. Disse forbindelser svarer til forbindelserne af informationsobjekter. Dataskemaet kan specificere parametre til opretholdelse af databasens integritet, hvis datamodellen er udviklet i overensstemmelse med normaliseringskrav. Dataintegritet betyder, at relationer mellem registreringer etableres og vedligeholdes korrekt i databasen forskellige borde ved indlæsning, tilføjelse og sletning af poster i relaterede tabeller, samt ved ændring af værdierne af nøglefelter.

Efter at dataskemaet er dannet, indtastes konsistente data fra emneområdets dokumenter.

Baseret på den oprettede database genereres de nødvendige forespørgsler, formularer, makroer, moduler, rapporter, der udfører den nødvendige behandling af databasedataene og deres præsentation.

Ved hjælp af indbyggede værktøjer og databaseværktøjer oprettes databasen brugergrænseflade, hvilket giver dig mulighed for at styre processerne for indtastning, lagring, behandling, opdatering og præsentation af databaseinformation.

2 Design af en database baseret på en objektrelationsmodel

Ledig hele linjen teknikker til at skabe information og logiske modeller. En af de i øjeblikket mest populære metoder til udvikling af modeller bruger ERD (Entity-Relationship Diagrams). I russisksproget litteratur kaldes disse diagrammer "objekt - forhold" eller "essens - forbindelse". ERD-modellen blev foreslået af Peter Ping Shen Chen i 1976. Til dato er flere af dens varianter blevet udviklet, men de er alle baseret på de grafiske diagrammer foreslået af Chen. Diagrammer er konstrueret ud fra lille antal komponenter. På grund af præsentationens klarhed er de meget brugt i CASE-værktøjer (Computer Aided Software Engineering).

Lad os se på den anvendte terminologi og notation.

Enhed- en reel eller imaginær genstand, der har betydning for det pågældende emneområde, og som oplysninger om, der skal opbevares.

Hver enhed skal have en unik identifikator. Hver forekomst af en enhed skal være entydigt identificerbar og adskiller sig fra alle andre forekomster af denne type(enheder). Hver enhed skal have visse egenskaber:

‣‣‣ har unikt navn; Desuden skal den samme fortolkning (entitetsdefinition) altid anvendes på dette navn. Og omvendt: den samme fortolkning kan ikke anvendes på forskellige navne, medmindre de er pseudonymer;

‣‣‣ har en eller flere attributter, der enten tilhører enheden eller er nedarvet af den gennem et forhold;

‣‣‣ har en eller flere attributter, der unikt identificerer hver forekomst af en enhed.

En enhed skal være uafhængig eller afhængig. Et tegn på en afhængig enhed er tilstedeværelsen af ​​attributter, der er nedarvet gennem et forhold (fig. 1.).

Hver enhed kan have et hvilket som helst antal forbindelser med andre enheder i modellen.

Forhold- en navngiven forening mellem to enheder, der er væsentlig for det pågældende emneområde. En af de enheder, der deltager i forbindelsen, er uafhængig, sædvanligvis kaldet en overordnet enhed, den anden er afhængig, normalt kaldet en under- eller efterkommerenhed. Typisk er hver forekomst af en overordnet enhed knyttet til et vilkårligt (inklusive nul) antal forekomster af en underordnet enhed. Hver forekomst af en underordnet enhed er knyttet til nøjagtig én forekomst af dens overordnede enhed. En forekomst af en underordnet enhed kan dog kun eksistere, hvis den overordnede enhed eksisterer.

Forbindelsen får et navn, udtrykt ved den grammatiske vending af verbet og placeret nær forbindelseslinjen. Hvert navn forholdet mellem to givne enheder skal være unikt, men navnene på relationerne i modellen behøver ikke at være unikke. Hver forbindelse har en definition. Definitionen af ​​en relation dannes ved at kombinere navnet på den overordnede enhed, navnet på relationen, et udtryk for graden af ​​tilknytning og navnet på den underordnede enhed.

For eksempel bør sælgers tilknytning til kontrakten defineres som følger:

‣‣‣ sælgeren kan modtage kompensation for en eller flere kontrakter;

‣‣‣ kontrakten skal indledes af nøjagtig én sælger.

I diagrammet er forbindelsen afbildet som et segment (polylinje). Enderne af segmentet bruger specielle symboler (fig. 2) for at angive graden af ​​forbindelse. Samtidig angiver linjens beskaffenhed - stiplet eller ubrudt - forbindelsens obligatoriske karakter.

Attribut- enhver egenskab ved en enhed, der er væsentlig for det pågældende emneområde. Det er beregnet til at kvalificere, identificere, klassificere, kvantificere eller udtrykke en enheds tilstand. En attribut repræsenterer en type karakteristika (egenskaber), der er forbundet med et sæt af virkelige eller abstrakte objekter (mennesker, steder, begivenheder, tilstande, ideer, par af objekter osv.) (Fig. 3). Attributforekomst- dette er en bestemt karakteristik af en specifik forekomst af en enhed. En attributforekomst er defineret af karakteristikkens type (f.eks. "Farve") og dens værdi (f.eks. "lilla"), kaldet attributværdien. I ER-modellen er attributter knyttet til specifikke enheder. Hver enhedsinstans skal have én specifik værdi for hver af dens attributter.

Attributten skal være enten obligatorisk, eller valgfri. Obligatorisk betyder, at attributten ikke kan acceptere null-værdier. Attributten skal enten være beskrivende (dvs. en almindelig enhedsdeskriptor) eller en del af unik identifikator (primærnøgle).

Unik identifikator er en attribut eller et sæt attributter og/eller relationer, der unikt karakteriserer hver forekomst af en given type enhed. I tilfælde af fuld identifikation er en forekomst af en given enhedstype fuldt identificeret ved sine egne nøgleattributter, ellers deltager attributterne for en anden enhed, forælderen, også i identifikationen.

Identifikationens art vises i et diagram på kommunikationslinjen (fig. 4).

Hver egenskab identificeres med et unikt navn, udtrykt ved en grammatisk navneordssætning, der beskriver den egenskab, egenskaben repræsenterer. Attributter er repræsenteret som en liste over navne inden for en tilknyttet enhedsblok, hvor hver attribut optager en separat linje. Attributter, der definerer den primære nøgle, er placeret øverst på listen og fremhævet med tegnet ''#'.

Hver enhed skal have mindst én mulig nøgle. En kandidatenhedsnøgle er en eller flere attributter, hvis værdier unikt identificerer hver forekomst af entiteten. Hvis der er flere mulige nøgler en af ​​dem er udpeget som den primære nøgle, og resten er udpeget som alternative nøgler.

I dag er der med udgangspunkt i Chens tilgang skabt IDEF1X-metoden, som er designet under hensyntagen til krav som let læring og mulighed for automatisering. IDEFlX-diagrammer bruges af en række almindelige CASE-værktøjer (især ERwin, Design/IDEF).

En enhed i IDEF1X-metoden kaldes sædvanligvis identifikator-uafhængig eller blot uafhængig, hvis hver forekomst af entiteten skal identificeres entydigt uden at definere dens relationer til andre enheder. En enhed kaldes normalt identifikatorafhængig eller blot afhængig, hvis den utvetydige identifikation af en enhedsinstans afhænger af dens forhold til en anden enhed (fig. 5).

Hver enhed får et unikt navn og nummer, adskilt af en skråstreg ’ʼ/ʼʼ og placeret over blokken.

Hvis en forekomst af en underordnet enhed er entydigt bestemt af dens relation til den overordnede enhed, kaldes relationen normalt identificerende, ellers - ikke-identificerende.

Det identificerende forhold mellem en overordnet enhed og en underordnet enhed er afbildet som en ubrudt linje. I fig. 5: Nr. 2 - afhængig enhed, Relation 1 - identificerende relation. En underordnet enhed i et identitetsforhold er en identifikatorafhængig enhed. Forælderenheden i et identitetsforhold skal både være en identitetsuafhængig og en identitetsafhængig enhed (dette bestemmes af dens relationer til andre enheder).

Den stiplede linje repræsenterer et ikke-identificerende forhold. I fig. 5: Nr. 4 - selvstændig enhed, Relation 2 - ikke-identificerende forhold. En underordnet enhed i et ikke-identificerende forhold vil være uafhængigt af identifikatoren, medmindre det også er en underordnet enhed i et eller andet identificerende forhold.

Relationen kan defineres yderligere ved at angive grad eller kardinalitet (antallet af forekomster af den underordnede enhed, der kan eksistere for hver forekomst af moderenheden). I IDEF1X udtrykkes følgende linkbeføjelser:

‣‣‣ Hver overordnede enhedsinstans kan have nul, én eller flere underordnede entitetsforekomster tilknyttet;

‣‣‣ Hver overordnet enhedsinstans skal have mindst én underordnet enhedsinstans tilknyttet;

‣‣‣ Hver overordnet enhedsinstans skal højst have en underordnet enhedsinstans tilknyttet;

‣‣‣ Hver forekomst af en overordnet enhed er knyttet til et bestemt antal forekomster af en underordnet enhed.

Kommunikationseffekten er angivet som vist i fig. 6 (standardstrøm -N).

Enheder kan også have fremmednøgler. I et identificerende forhold bruges de som en del af eller hele den primære nøgle; i et ikke-identificerende forhold tjener de som ikke-nøgleattributter. I attributlisten er en fremmednøgle markeret med bogstaverne FK i parentes.

Resultatet er en informationslogisk model, som bruges af en række gængse CASE-værktøjer, såsom ERwin, Design/IDEF. Til gengæld har CASE-teknologier et stort potentiale i udviklingen af ​​databaser og informationssystemer, nemlig at øge arbejdsproduktiviteten, forbedre kvaliteten software produkter, der understøtter en samlet og konsekvent arbejdsstil.

Stadier af databasedesign - koncept og typer. Klassificering og funktioner i kategorien "Stadier af databasedesign" 2017, 2018.

Når du opretter en database, kan der skelnes mellem følgende trin:

1. Formulering af problemet. På dette stadium er det nødvendigt at beslutte, hvilke oplysninger der skal gemmes i den planlagte database, og hvordan de vil blive brugt. Ud fra dette vil det være muligt at bestemme, hvilke tabeller der skal gemmes i databasen, og hvilke informationer (felter) der skal indgå i hver tabel.

2. Beskrivelse af strukturen af ​​databasetabeller. På dette stadium er det nødvendigt at beskrive hver tabel - angiv hvilke felter, der vil være indeholdt i tabellen, typen og størrelsen af ​​data, der er gemt i felterne, og sæt primære nøgler.

3. Definere relationer mellem tabeller. Når alle tabellerne er blevet defineret, skal du fortælle Access, hvilke handlinger du skal tage for at kombinere indholdet af de tabeller, der udgør databasen.

4. Test og forbedring. På dette tidspunkt skal du indtaste et par poster i hver tabel og kontrollere, om du kan udtrække nødvendige oplysninger fra disse tabeller. Det anbefales, at du opretter udkast til formularer og rapporter for at afgøre, om de indeholder de oplysninger, du forventer.

Indtastning af data og oprettelse af andre databaseobjekter. Hvis databasestrukturen opfylder kravene, kan du begynde at indtaste data og oprette de nødvendige forespørgsler, formularer, rapporter, dataadgangssider, makroer og moduler.

17. BORDE

Bord- et databaseobjekt, der bruges til at lagre data.

Typisk består en database af flere tabeller, som hver kun indeholder information om ét emne. Hver tabel består af rækker og kolonner, som almindeligvis kaldes optegnelser og felter henholdsvis.

Optage- en række i en databasetabel, der indeholder alle oplysninger om et specifikt element. For eksempel, i tabellen Bøger i biblioteksdatabasen, er dette oplysninger om en bestemt bog.

Mark- en kolonne i en databasetabel, der udgør en del af en post, der er allokeret til en særskilt karakteristik af et element. Vender vi tilbage til det foregående eksempel, kan felterne være forfatterens efternavn, bogtitel, udgivelsessted, forlag, udgivelsesår, bogkode (eller bogkode).

BORDSTRUKTUR

Når du opretter en database, skal du først bestemme, hvilke oplysninger der skal gemmes i den planlagte database, og hvordan de vil blive brugt. Ud fra dette kan du bestemme hvilke tabeller (og hvor mange) der skal gemmes i databasen (hver tabel skal være relateret til et specifikt emneområde), og hvilke felter der skal inkluderes i hver tabel. Det er således nødvendigt at beskrive strukturen af ​​hver tabel - angiv hvor mange felter der er indeholdt i tabellen, definer et navn for hvert felt, angiv typen og størrelsen af ​​dataene.

Rækkefølgen af ​​felterne, med angivelse af felternes navne, typen af ​​data, der er gemt i felterne, størrelsen af ​​disse data osv. bestemme tabelstruktur.