Viktige databasedesigntrinn

2.1. Konseptuell design

Databasedesign utføres i tre trinn:

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

Hensikten med konseptdesignfasen er å lage en konseptuell datamodell basert på brukernes ideer om fagområdet. For å oppnå det, utføres en rekke sekvensielle prosedyrer. Et eksempel på et enhetsskjema (konseptuelt):

1. Definisjon av enheter og deres dokumentasjon. For å identifisere enheter defineres objekter som eksisterer uavhengig av andre. Slike objekter er enheter. Hver enhet får et meningsfylt navn som brukerne kan forstå. Navnene og beskrivelsene av enhetene legges inn i dataordboken. Hvis mulig, angis forventet antall forekomster av hver enhet.

2. Fastsettelse av forhold mellom enheter og deres dokumentasjon. Bare de relasjonene mellom enheter er definert som er nødvendige for å tilfredsstille kravene til databasedesign. Typen av hver er satt. Medlemskapsklassen av enheter avsløres. Lenker tildeles meningsfulle navn uttrykt av verb. En detaljert beskrivelse av hver forbindelse, som indikerer typen og tilhørighetsklassen til enhetene som deltar i forbindelsen, legges inn i dataordboken.

3. Oppretting av en ER-modell av fagområdet. ER-diagrammer brukes til å representere enheter og relasjoner mellom dem. Basert på dem lages et enkelt visuelt bilde av det modellerte fagområdet - ER-modellen av fagområdet.

4. Definisjon av attributter og deres dokumentasjon. Alle attributter som beskriver enhetene til den opprettede ER-modellen avsløres. Hvert attributt får et meningsfylt navn som brukerne kan forstå. Følgende informasjon er lagret i dataordboken for hvert attributt:

• attributtnavn og beskrivelse;
• type og dimensjon av verdier;
• standardverdien for attributtet (hvis noen);
• om attributtet kan ha NULL-verdier;
• om attributtet er sammensatt, og i så fall hvilke enkle attributter det består av. For eksempel kan attributtet "Klientens fulle navn" bestå av enkle attributter "Etternavn", "Fornavn", "Patronym", eller det kan være enkelt, inneholde enkeltverdier, for eksempel "Sidorsky Evgeniy Mikhailovich". Hvis brukeren ikke trenger tilgang til individuelle elementer i "Navn", presenteres attributtet som enkelt;
• om attributtet beregnes, og i så fall hvordan verdiene beregnes.

5. Definisjon av attributtverdier og deres dokumentasjon. For hvert attributt til en enhet som deltar i ER-modellen, bestemmes et sett med gyldige verdier og et navn tildeles det. For eksempel kan attributtet "Kontotype" bare ha verdiene "innskudd", "aktuelt", "på forespørsel", "kortkonto". Dataordbokoppføringene knyttet til attributtene oppdateres med navnene på attributtverdisettene.

6. Definisjon av primærnøkler for enheter og deres dokumentasjon. Dette trinnet styres av definisjonen av en primærnøkkel - som et attributt eller sett med attributter til en enhet som tillater unik identifikasjon av dens forekomster. Primærnøkkelinformasjon plasseres i dataordboken.

7. Diskusjon av den konseptuelle datamodellen med sluttbrukere. Den konseptuelle datamodellen er representert ved en ER-modell med tilhørende dokumentasjon som inneholder en beskrivelse av den utviklede datamodellen. Hvis det oppdages inkonsekvenser i domene, gjøres endringer i modellen inntil brukerne bekrefter at modellen foreslått av dem reflekterer deres personlige synspunkter tilstrekkelig.

2.2 Logisk design

Hensikten med det logiske designstadiet er å transformere den konseptuelle modellen basert på den valgte datamodellen til en logisk modell som er uavhengig av funksjonene til DBMS som senere brukes for den fysiske implementeringen av databasen. For å oppnå det, utføres følgende prosedyrer.

Et eksempel på et logisk databaseskjema.

1. Velge en datamodell. Oftest velges en relasjonsdatamodell på grunn av klarheten i den tabellformede presentasjonen av data og bekvemmeligheten av å jobbe med dem.

2. Definere et sett med tabeller basert på ER-modellen og dokumentere dem. En tabell opprettes for hver enhet i ER-modellen. Enhetsnavn er navnet på tabellen. Relasjoner mellom tabeller etableres gjennom mekanismen for primær- og fremmednøkler. Strukturene til tabellene og de etablerte relasjonene mellom dem er dokumentert.

3. Normalisering av tabeller. For å utføre normalisering på riktig måte, må designeren ha en dyp forståelse av semantikken og bruksmønstrene til dataene. På dette trinnet kontrollerer han riktigheten av strukturen til tabellene opprettet i forrige trinn ved å bruke normaliseringsprosedyren på dem. Det består i å bringe hvert av bordene til minst 3. NF. Som et resultat av normalisering oppnås en svært fleksibel databasedesign, som gjør det enkelt å lage nødvendige utvidelser til den.

4. Sjekke den logiske datamodellen for muligheten for å utføre alle transaksjoner levert av brukere. En transaksjon er et sett med handlinger utført av en individuell bruker eller applikasjonsprogram for å endre innholdet i en database. Så et eksempel på en transaksjon i BANK-prosjektet kan være overføring av retten til å administrere kontoene til en bestemt klient til en annen klient. I dette tilfellet må det gjøres flere endringer i databasen samtidig. Hvis en datamaskin krasjer under en transaksjon, vil databasen være i en inkonsekvent tilstand fordi noen endringer allerede er gjort og andre ikke. Derfor må alle delvise endringer angres for å returnere databasen til sin tidligere konsistente tilstand.

Listen over transaksjoner bestemmes av handlingene til brukerne i fagområdet. Ved å bruke ER-modellen, dataordboken og etablerte relasjoner mellom primær- og fremmednøkler, forsøkes det å utføre alle nødvendige datatilgangsoperasjoner manuelt. Hvis noen manuell operasjon mislykkes, er den kompilerte logiske datamodellen utilstrekkelig og inneholder feil som må elimineres. Kanskje de er relatert til et gap i modellen til en enhet, relasjon eller attributt.

5. Fastsettelse av dataintegritetsstøttekrav og deres dokumentasjon. Disse kravene er restriksjoner som er satt på plass for å forhindre at motstridende data legges inn i databasen. På dette trinnet dekkes dataintegritetsproblemer uten hensyn til spesifikke aspekter ved implementeringen. Følgende typer restriksjoner bør vurderes:

• nødvendige data. Finne ut om det er attributter som ikke kan ha NULL-verdier;
• restriksjoner på attributtverdier. Gyldige verdier for attributter er definert;
• enhetens integritet. Det oppnås hvis enhetens primærnøkkel ikke inneholder NULL-verdier;
• referanseintegritet. Det er forstått at fremmednøkkelverdien må være tilstede i primærnøkkelen til en av tabellradene for den overordnede enheten;
• restriksjoner pålagt av forretningsreglene. For eksempel, når det gjelder BANK-prosjektet, kan det vedtas en regel som forbyr kunden å administrere for eksempel mer enn tre kontoer.

Informasjon om alle etablerte dataintegritetsbegrensninger er plassert i dataordboken.

6. Oppretting av den endelige versjonen av den logiske datamodellen og diskusjon med brukere. Dette trinnet forbereder den endelige versjonen av ER-modellen, som representerer den logiske datamodellen. Selve modellen og oppdatert dokumentasjon, inkludert dataordbok og koblingsskjema for relasjonstabeller, presenteres for gjennomgang og analyse av brukere, som må sørge for at den nøyaktig representerer fagområdet.

2.3. Fysisk design

Formålet med det fysiske designstadiet er å beskrive en spesifikk implementering av en database som ligger i det eksterne minnet til en datamaskin. Dette er en beskrivelse av datalagringsstrukturen og effektive metoder for tilgang til databasedata. I logisk design svarer de på spørsmålet - hva må gjøres, og i fysisk design - velges en måte hvordan det skal gjøres. De fysiske designprosedyrene er som følger.

1. Designe databasetabeller ved å bruke valgt DBMS. En relasjonell DBMS er valgt for å brukes til å lage en database som er vert på maskinmedier. Dens funksjonalitet for å designe bord er dypt studert. Deretter utføres utformingen av tabeller og skjemaet for deres tilkobling i DBMS-miljøet. Det utarbeidede databaseprosjektet er beskrevet i den medfølgende dokumentasjonen.

2. Implementering av forretningsregler i miljøet til det valgte DBMS. Oppdatering av informasjon i tabeller kan begrenses av forretningsregler. Måten de implementeres på avhenger av det valgte DBMS. Noen systemer for å implementere kravene til fagområdet tilbyr flere funksjoner, andre mindre. I noen systemer er det ikke støtte for å implementere forretningsregler i det hele tatt. I dette tilfellet utvikles applikasjoner for å implementere sine begrensninger.

Alle beslutninger som tas i forbindelse med implementering av domeneforretningsregler er detaljert beskrevet i den medfølgende dokumentasjonen.

3. Designe den fysiske organiseringen av databasen. Dette trinnet velger den beste filorganiseringen for tabellene. Transaksjonene som skal utføres i databasen som designes, identifiseres, og de viktigste av dem utheves. Transaksjonsgjennomstrømning analyseres - antall transaksjoner som kan behandles i et gitt tidsintervall, og responstid - tidsperioden som kreves for å fullføre en transaksjon. De streber etter å øke transaksjonsgjennomstrømningen og redusere responstiden.

Basert på disse indikatorene tas det beslutninger om å optimalisere ytelsen til databasen ved å definere indekser i tabeller som fremskynder utvalget av data fra databasen, eller ved å redusere kravene til nivået for tabellnormalisering. Diskplassen som kreves for å romme den opprettede databasen, er beregnet. Prøv å minimere det.

Beslutninger som er tatt i de ovennevnte spørsmålene er dokumentert.

4. Utvikling av en databasebeskyttelsesstrategi. Databasen er en verdifull bedriftsressurs, og mye oppmerksomhet rettes mot beskyttelsen. For å gjøre dette må designere ha en fullstendig og klar forståelse av alle beskyttelsene som tilbys av det valgte DBMS.

5. Organisering av databasefungerende overvåking og justering av den. Etter opprettelsen av det fysiske prosjektet til databasen, organiseres kontinuerlig overvåking av funksjonen. Den resulterende informasjonen om ytelsesnivået til databasen brukes til å justere den. For dette er også midlene til det valgte DBMS involvert.

Beslutninger om å gjøre endringer i en fungerende database bør vurderes og veies grundig.