Databasedesignstadier

Det er umulig å lage en database uten en detaljert beskrivelse av den, akkurat som det ikke er mulig å lage noe komplekst produkt uten en tegning og en detaljert beskrivelse av teknologiene for produksjonen. Vi trenger med andre ord et prosjekt. Prosjekt Det er generelt akseptert å vurdere en skisse av en enhet, som senere vil bli oversatt til virkelighet.

Databasedesignprosessen er en prosess med overganger fra en uformell verbal beskrivelse av informasjonsstrukturen fagområde til en formalisert beskrivelse av domeneobjekter i form av en bestemt modell. Det endelige målet med design er å bygge en spesifikk database. Selvfølgelig er designprosessen kompleks, og derfor er det fornuftig å dele den inn i logisk fullførte deler - stadier.

Det er fem hovedstadier av databasedesign:

1. Innsamling av informasjon og systemanalyse av fagområdet.

2. Infologisk design.

3. Velge en DBMS.

4. Datalogisk design.

5. Fysisk design.

Innsamling av informasjon og systemanalyse av fagområdet- dette er den første og det viktigste stadiet når du designer en database. Det krever detaljert verbal beskrivelse objekter i fagområdet og reelle forbindelser tilstede mellom virkelige objekter. Det er ønskelig at beskrivelsen definerer relasjonene mellom objekter i fagområdet.

Generelt er det to tilnærminger til å velge sammensetning og struktur for et fagområde:

· Funksjonell tilnærming– brukes når funksjonene til en bestemt gruppe personer og settene med oppgaver som denne databasen er opprettet for er kjent på forhånd, dvs. det minste nødvendige settet med domeneobjekter for beskrivelse er tydelig identifisert.

· Fagtilnærming– når informasjonsbehovene til databasekunder ikke er tydelig registrert og kan være flerdimensjonale og dynamiske. I i dette tilfellet minimumssett Det er vanskelig å velge domeneobjekter. Beskrivelsen av fagområdet omfatter slike objekter og relasjoner som er mest karakteristiske og vesentlige for det. Samtidig blir databasen fagspesifikk og egner seg til å løse mange problemer (noe som virker mest fristende). Vanskeligheten med universell dekning av fagområdet og umuligheten av å spesifisere brukerbehov fører imidlertid til overflødig kompleks ordning En database som vil være ineffektiv for noen oppgaver.

Systemanalyse må avsluttes Detaljert beskrivelse informasjon om objekter i fagområdet, som bør lagres i databasen, med formuleringen spesifikke oppgaver, som vil løses ved hjelp av denne databasen med Kort beskrivelse algoritmer for deres løsning, beskrivelse av utdata og inngangsdokumenter ved arbeid med databasen.

Infologisk design– en delvis formalisert beskrivelse av objekter i fagområdet i form av en viss semantisk modell.

Hvorfor er det nødvendig med en informasjonsmodell, og hvordan gagner den designere? Faktum er at designprosessen er lang og krever diskusjoner med kunden og fageksperter. I tillegg, ved utvikling av seriøse bedrifter informasjonssystemer Databaseprosjektet er grunnlaget for hele systemet som helhet, og spørsmålet om muligheten for utlån avgjøres ofte av bankeksperter på bakgrunn av et godt laget informasjonsdatabaseprosjekt. Følgelig bør informasjonsmodellen inkludere en slik formalisert beskrivelse av fagområdet som lett vil bli oppfattet ikke bare av databasespesialister. Beskrivelsen bør være så fyldig at man kan vurdere dybden og riktigheten av utviklingen av databaseprosjektet.

I dag har Chens Entity Relationship-modell blitt den mest brukte; den har blitt de facto-standarden innen informasjonsmodellering, og kalles ER-modellen.

Velge en DBMS utføres på grunnlag av ulike krav til databasen og følgelig egenskapene til DBMS, samt avhengig av den eksisterende erfaringen til utviklerne.

Datalogisk design det er en beskrivelse av databasen i forhold til akseptert dato logisk modell data. I relasjonsdatabaser fører datalogisk eller logisk design til utvikling av databaseskjemaet, dvs. sett med relasjonsskjemaer som tilstrekkelig modellerer objekter i fagområdet og semantiske relasjoner mellom objekter. Grunnlaget for å analysere riktigheten av et skjema er de funksjonelle avhengighetene mellom databaseattributter. I noen tilfeller kan det oppstå uønskede avhengigheter mellom relasjonsattributter som forårsaker bivirkninger og uregelmessigheter under databasemodifisering. Under modifikasjon forstå å legge inn nye data i databasen, slette data fra databasen, samt oppdatere verdiene til noen attributter. For å eliminere mulige anomalier er det planlagt å normalisere databaserelasjoner.

Det logiske designstadiet handler ikke bare om å designe relasjonsdiagrammet. Som et resultat av dette stadiet, som regel, bør følgende resulterende dokumenter innhentes:

· Beskrivelse av det konseptuelle skjemaet til databasen i forhold til valgt DBMS.

· Beskrivelse eksterne modeller når det gjelder valgt DBMS.

· Beskrivelse av deklarative regler for vedlikehold av databaseintegritet.

· Utvikling av prosedyrer for å opprettholde den semantiske integriteten til databasen.

Fysisk design er å linke logisk struktur DB og fysisk lagringsmiljø for den mest effektive plassering av data, dvs. kartlegge den logiske strukturen til databasen til lagringsstrukturen. Spørsmålet om å plassere lagrede data i minnet, velge effektive metoder tilgang til ulike komponenter"fysisk" database, problemer med å sikre datasikkerhet og sikkerhet er løst. Begrensningene i den logiske datamodellen implementeres av ulike DBMS-verktøy, for eksempel ved å bruke indekser, deklarative integritetsbegrensninger, utløsere og lagrede prosedyrer. I dette tilfellet, igjen, bestemmer beslutninger tatt på logisk modelleringsnivå noen grenser som den fysiske datamodellen kan utvikles innenfor. Likeledes, innenfor disse grensene kan man akseptere ulike løsninger. For eksempel må relasjonene i den logiske datamodellen konverteres til tabeller, men ulike indekser kan valgfritt deklareres på hver tabell for å forbedre tilgangshastigheten til dataene.

I tillegg kan funksjoner brukes til å forbedre ytelsen. parallell behandling data. Som et resultat kan databasen være plassert på flere nettverksdatamaskiner. På den annen side kan fordelene med multiprosessorsystemer brukes.

For å sikre sikkerheten og sikkerheten til data er problemer med gjenoppretting etter feil løst, Reserver eksemplar informasjon, sette opp beskyttelsessystemer som passer den valgte sikkerhetspolicyen, etc.

Det skal bemerkes at noen moderne relasjonell DBMS bruker hovedsakelig fysiske strukturer og tilgangsmetoder basert på fildesignteknologi, som i hovedsak eliminerer spørsmålet om fysisk design.

Dermed er det klart at beslutninger som tas på hvert trinn av modellering og databaseutvikling vil påvirke påfølgende stadier. Derfor aksept spiller en spesiell rolle riktige avgjørelser på tidlige stadier modellering.

Databasedesigntrinn

Alle finesser av konstruksjon informasjonsmodell i et eller annet fagområde for menneskelig aktivitet, forfølger de ett mål - å få en god database. La oss forklare begrepet – en god database og formulere kravene som en slik database må tilfredsstille:

1. Databasen skal tilfredsstille brukernes (organisasjoners) informasjonsbehov og i struktur og innhold samsvare med oppgavene som løses;

2. Databasen skal levere nødvendige data i en akseptabel tid, d.v.s. oppfylle ytelseskrav;

3. Databasen bør enkelt utvides når fagområdet omorganiseres;

4. Databasen skal være enkel å endre når programvare- og maskinvaremiljøet endres;

5. Korrekte data som lastes inn i databasen må forbli korrekte (data må kontrolleres for korrekthet når de legges inn).

La oss vurdere hovedstadiene i design (fig. 3.5):

Første etappe. Planlegging for databaseutvikling. På dette stadiet den mest fremtredende effektiv metode gjennomføring av stadier Livssyklus systemer.

Andre fase. Fastsettelse av systemkrav. Omfanget og grensene for databaseapplikasjonen bestemmes, og brukerkrav samles inn og analyseres.

Tredje trinn. Design konseptuell modell DB. Prosessen med å lage en database begynner med å definere en konseptuell modell som representerer objekter og deres relasjoner uten å spesifisere hvordan de fysisk lagres. Innsatsen på dette stadiet bør være rettet mot å strukturere dataene og identifisere sammenhenger mellom dem. Denne prosessen kan deles inn i flere undertrinn:

a) Avklaring av problemet. Allerede før du starter arbeidet spesifikk applikasjon Utvikleren har vanligvis en ide om hva han vil utvikle. I andre tilfeller, når en liten personlig database utvikles, kan slike visninger være ganske komplette. I andre tilfeller, når en stor tilpasset database utvikles, kan det være svært få slike visninger, eller de vil mest sannsynlig være overfladiske. Det er helt klart for tidlig å starte utviklingen med en gang ved å definere tabeller, felt og relasjoner mellom dem. Denne tilnærmingen kan resultere i en fullstendig redesign av mye av applikasjonen. Derfor bør du bruke litt tid på å sette sammen en liste over alle hovedoppgavene som denne applikasjonen i prinsippet skal løse, inkludert de som kan oppstå i fremtiden.

Ris. 3.5. Database design diagram

b) Avklaring av rekkefølgen av oppgaver. For å få applikasjonen til å fungere logisk og praktisk, er det best å organisere hovedoppgavene i grupper og deretter organisere oppgavene til hver gruppe slik at de er ordnet i den rekkefølgen de er utført. Gruppering og grafisk representasjon Rekkefølgen av utførelsen deres vil bidra til å bestemme den naturlige rekkefølgen av oppgaver.

c) Dataanalyse. Etter å ha bestemt listen over oppgaver, er det nødvendig å opprette for hver oppgave detaljert liste data som kreves for å løse det. Etter dataanalysestadiet kan du begynne å utvikle en konseptuell modell, dvs. å fremheve objekter, attributter og relasjoner.

Fjerde trinn. Konstruksjon av en logisk modell. Å bygge en logisk modell begynner med å velge en datamodell. Når du velger modell viktig rolle dens enkelhet, klarhet og sammenligning av den naturlige datastrukturen med modellen som representerer den spiller en rolle. For eksempel, hvis hierarkisk struktur er iboende i selve dataene, vil det være å foretrekke å velge en hierarkisk modell. Men ofte bestemmes dette valget av suksessen (eller tilgjengeligheten) til en eller annen DBMS. Det vil si at utvikleren velger DBMS, ikke datamodellen. Dermed blir den konseptuelle modellen på dette stadiet oversatt til en datamodell som er kompatibel med det valgte DBMS. Det er mulig at relasjonene mellom objekter eller noen attributter til objekter som vises i den konseptuelle modellen, senere vil vise seg å være urealiserbare av den valgte DBMS. Dette vil kreve en endring i den konseptuelle modellen. Versjonen av en konseptuell modell som kan leveres av en bestemt DBMS kalles logisk modell. Prosessen med å definere konseptuelle og logiske modeller kalles noen ganger datastrukturdefinisjon.

Femte etappe. Konstruksjon fysisk modell. Den fysiske modellen definerer dataoppsettet, tilgangsmetoder og indekseringsteknikker. På det fysiske designstadiet blir vi knyttet til et spesifikt DBMS og beskriver dataskjemaet mer detaljert, og indikerer typer, feltstørrelser og begrensninger. I tillegg til å designe tabeller og indekser, innebærer dette stadiet også å definere grunnleggende spørringer.

Når man konstruerer en fysisk modell, må man løse to innbyrdes motsatte problemer. Den første av disse er å minimere datalagringsplass, og den andre er å oppnå maksimal ytelse, dataintegritet og sikkerhet. For eksempel for å sikre høy hastighet søk, det er nødvendig å lage indekser, og antallet vil bli bestemt av alle mulige kombinasjoner av felt som deltar i søket; For å gjenopprette data må du føre en logg over alle endringer og lage sikkerhetskopier av databaser; Til effektivt arbeid transaksjoner krever å reservere diskplass for midlertidige objekter osv., noe som fører til en økning (noen ganger betydelig) i størrelsen på databasen.

Sjette etappe. Evaluering av den fysiske modellen. På dette stadiet gjennomføres en vurdering ytelsesegenskaper. Her kan du sjekke effektiviteten til utføring av spørringer, søkehastighet, korrekthet og enkel utførelse av databaseoperasjoner, dataintegritet og effektiviteten til dataressurser. Hvis ytelsesegenskapene er utilfredsstillende, er det mulig å gå tilbake til revisjonen av de fysiske og logiske datamodellene, valg av DBMS og type datamaskin.

Syvende etappe. Implementering av databasen. Hvis ytelsen er tilfredsstillende, kan du gå videre til å lage applikasjonsoppsettet, det vil si et sett med grunnleggende tabeller, spørringer, skjemaer og rapporter. Denne foreløpige mockupen kan demonstreres for kunden og få godkjenning før den detaljerte implementeringen av applikasjonen.

Åttende etappe. Testing og optimalisering. Et obligatorisk stadium er testing og optimalisering av den utviklede applikasjonen.

Etappe ni, finale. Vedlikehold og drift. Siden det ikke er mulig å identifisere og eliminere alle feil på teststadiet, er vedlikeholdsstadiet normalt for databaser.

Det er to hovedtilnærminger til dataskjemadesign: ovenfra og ned og nedenfra og opp. Med en nedenfra og opp-tilnærming begynner arbeidet på det lavere nivået - nivået for å definere attributter, som, basert på en analyse av relasjonene som eksisterer mellom dem, er gruppert i relasjoner som representerer objekter og forbindelser mellom dem. Tabell normaliseringsprosess for relasjonsmodell data er et typisk eksempel på denne tilnærmingen. Denne tilnærmingen er godt egnet for å designe relativt små databaser. Når antallet attributter øker til flere hundre eller til og med tusenvis, er en ovenfra-ned-tilnærming en mer passende designstrategi. Denne tilnærmingen begynner med å definere flere enheter på høyt nivå og relasjonene mellom dem. Disse objektene blir deretter detaljert til nødvendig nivå. Et eksempel på denne designtilnærmingen er bruken av en enhetsrelasjonsmodell. I praksis kombineres disse tilnærmingene vanligvis. I dette tilfellet kan vi snakke om en blandet designtilnærming.

Essensen av databasedesign, som enhver annen designprosess, er å lage en beskrivelse av et nytt system som ikke tidligere har eksistert i denne formen, som, når det implementeres, er i stand til å forventes å fungere under passende forhold. Det følger av dette at stadiene i databasedesign må konsekvent og logisk gjenspeile essensen av denne prosessen.

Innhold i databasedesign og fasing

Designhensikten er basert på et eller annet formulert sosialt behov. Dette behovet har et miljø for sin forekomst og en målgruppe av forbrukere som vil bruke designresultatet. Følgelig begynner databasedesignprosessen med å studere et gitt behov fra forbrukernes synspunkt og det funksjonelle miljøet til den tiltenkte plasseringen. Det vil si at det første trinnet er å samle informasjon og definere en modell av systemets fagområde, samt se på det fra synspunktet målgruppe. Generelt, for å bestemme systemkrav, bestemmes omfanget av aktiviteter så vel som grensene for databaseapplikasjoner.

Deretter avklarer designeren, som allerede har visse ideer om hva han trenger å lage, oppgavene som angivelig er løst av applikasjonen, lager en liste over dem (spesielt hvis prosjektutviklingen er en stor og kompleks database), klargjør sekvensen av løsningen problemer og utfører dataanalyse. Denne prosessen er også en trinnvis prosess. prosjekt arbeid, men vanligvis i designstrukturen absorberes disse trinnene av det konseptuelle designstadiet - stadiet for å identifisere objekter, attributter og forbindelser.

Å lage en konseptuell (informasjonsmodell) innebærer den foreløpige dannelsen av konseptuelle brukerkrav, inkludert krav til applikasjoner som kanskje ikke umiddelbart implementeres, men tar hensyn til hvilke som vil forbedre funksjonaliteten til systemet i fremtiden. Når det gjelder representasjoner av setteabstraksjonsobjekter (uten å spesifisere fysiske lagringsmetoder) og deres relasjoner, tilsvarer den konseptuelle modellen i hovedsak domenemodellen. Derfor, i litteraturen, kalles den første fasen av databasedesign infologisk design.

Deretter, som et eget trinn (eller et tillegg til det forrige), følger trinnet med å stille krav til driftsmiljøet, hvor kravene til dataressurser, i stand til å sikre at systemet fungerer. Følgelig, jo større volumet på den utformede databasen er, jo høyere brukeraktivitet og intensitet på forespørsler, jo høyere krav til ressurser: for datamaskinkonfigurasjonen, for type og versjon operativsystem. For eksempel flerbrukermodus fremtidig base data som kreves Nettverkstilkobling bruke et operativsystem som er egnet for multitasking.

Det neste trinnet er for designeren å velge et databasestyringssystem (DBMS), samt verktøy programmatisk i naturen. Etter dette må den konseptuelle modellen overføres til en datamodell som er kompatibel med det valgte styringssystemet. Men ofte innebærer dette å gjøre endringer og endringer i den konseptuelle modellen, siden sammenkoblingene mellom objekter reflektert i den konseptuelle modellen ikke alltid kan implementeres ved å bruke midlene til et gitt DBMS.

Denne omstendigheten bestemmer fremveksten av det neste trinnet - fremveksten av en konseptuell modell utstyrt med midlene til en spesifikk DBMS. Dette trinnet tilsvarer stadiet av logisk design (opprette en logisk modell).

Til slutt er det siste stadiet av databasedesign fysisk design - stadiet for å koble den logiske strukturen og det fysiske lagringsmiljøet.

Dermed presenteres hovedstadiene av design i detaljert form i følgende stadier:

• informasjonsdesign,
• dannelse av krav til driftsmiljøet
• valg av kontrollsystem og programvare DB,
• logisk design,
• fysisk design

De viktigste vil bli diskutert mer detaljert nedenfor.

Infologisk design

Identifikasjon av enheter danner det semantiske grunnlaget for infologisk design. En enhet her er et objekt (abstrakt eller konkret), informasjon om hvilken vil bli akkumulert i systemet. I informasjonsmodellen til fagområdet i Brukervennlig i termer som ikke er avhengig av den spesifikke implementeringen av databasen, beskrives strukturen og dynamiske egenskaper til fagområdet. Men begrepene er tatt på en standardskala. Det vil si at beskrivelsen ikke uttrykkes gjennom individuelle objekter i fagområdet og deres relasjoner, men gjennom:

• beskrivelse av objekttyper,
• integritetsbegrensninger knyttet til den beskrevne typen,
• prosesser som fører til utviklingen av et fagområde - dets overgang til en annen stat.

En informasjonsmodell kan lages ved hjelp av flere metoder og tilnærminger:

1. Den funksjonelle tilnærmingen er basert på de tildelte oppgavene. Det kalles funksjonelt fordi det brukes hvis funksjonene og oppgavene til personene som skal betjene deres informasjonsbehov ved hjelp av den utformede databasen er kjent.
2. Fagtilnærmingen fokuserer på informasjon om informasjonen som vil være i databasen, til tross for at spørringsstrukturen kanskje ikke er definert. I dette tilfellet er forskning innen fagområdet fokusert på den mest passende visningen i databasen i konteksten fullt spektrum forventede informasjonsforespørsler.
3. En integrert tilnærming ved bruk av "entitetsforhold"-metoden kombinerer fordelene med de to foregående. Metoden går ut på å dele opp hele fagområdet i lokale deler, som modelleres separat og deretter rekombinert til et helt område.

Siden bruk av enhet-relasjonsmetoden er kombinert metode design på dette stadiet, blir det oftest en prioritet.

Når det er metodisk inndelt, bør lokale representasjoner, hvis mulig, inkludere informasjon som vil være tilstrekkelig til å løse et eget problem eller til å møte forespørslene fra en viss gruppe potensielle brukere. Hvert av disse områdene inneholder ca. 6-7 enheter og tilsvarer en egen ekstern applikasjon.

Entiteters avhengighet gjenspeiles i deres inndeling i sterk (base, forelder) og svak (barn). En sterk enhet (for eksempel en leser i et bibliotek) kan eksistere i databasen alene, men en svak enhet (for eksempel denne leserens abonnement) er "festet" til en sterk og eksisterer ikke separat.

Det er nødvendig å skille begrepene "entitetsforekomst" (et objekt preget av spesifikke egenskapsverdier) og konseptet "enhetstype" - et objekt preget av et vanlig navn og en liste over egenskaper.

For hver enkelt enhet velges attributter (et sett med egenskaper), som, avhengig av kriteriet, kan være:

• identifisere seg (med unik verdi for enheter av denne typen, noe som gjør dem potensielle nøkler) eller beskrivende;
• enkeltverdi eller flerverdi (med passende antall verdier for en enhetsforekomst);
• grunnleggende (uavhengig av andre attributter) eller avledet (beregnet basert på verdiene til andre attributter);
• enkel (delelig en-komponent) eller kompositt (kombinert fra flere komponenter).

Etter dette spesifiseres attributtet, forbindelsene spesifiseres i lokalvisningen (delt i valgfri og obligatorisk) og de lokale visningene slås sammen Dersom antall lokalområder er opp til 4-5 kan de kombineres i ett trinn . Hvis antallet øker, skjer den binære sammenslåingen av områder i flere stadier.

I løpet av dette og andre mellomstadier gjenspeiles designens iterative natur, som her kommer til uttrykk i det faktum at for å eliminere motsetninger er det nødvendig å gå tilbake til stadiet med modellering av lokale representasjoner for avklaring og endring (for eksempel for å endre samme navn på semantisk forskjellige objekter eller for å koordinere integritetsattributter på samme attributter i forskjellige applikasjoner).

Velge et kontrollsystem og databaseprogramvare

Den praktiske implementeringen av informasjonssystemet avhenger av valget av databasestyringssystem. De viktigste kriteriene i utvelgelsesprosessen er følgende parametere:

• type datamodell og dens samsvar med behovene til fagområdet,
• reserve av muligheter i tilfelle utvidelse av informasjonssystemet,
• ytelsesegenskaper til det valgte systemet,
• driftssikkerhet og bekvemmelighet til DBMS,
• verktøy rettet mot dataadministrasjonspersonell,
• kostnadene for selve DBMS og tilleggsprogramvare.

Feil ved valg av DBMS vil nesten helt sikkert i ettertid provosere behovet for å justere de konseptuelle og logiske modellene.

Logisk databasedesign

Den logiske strukturen til databasen må samsvare med den logiske modellen for fagområdet og ta hensyn til forbindelsen mellom datamodellen og støttet DBMS. Derfor begynner stadiet med å velge en datamodell, hvor det er viktig å ta hensyn til dens enkelhet og klarhet.

Det er å foretrekke når den naturlige datastrukturen faller sammen med modellen som representerer den. Så for eksempel hvis dataene presenteres i skjemaet hierarkisk struktur, da er det bedre å velge en hierarkisk modell. Men i praksis bestemmes et slikt valg ofte av databasestyringssystemet i stedet for av datamodellen. Derfor blir den konseptuelle modellen faktisk oversatt til en datamodell som er kompatibel med det valgte databasestyringssystemet.

Dette gjenspeiler også designens natur, som åpner for muligheten (eller nødvendigheten) av å gå tilbake til den konseptuelle modellen for å endre den hvis relasjonene mellom objekter (eller objektattributter) som reflekteres der, ikke kan implementeres ved å bruke det valgte DBMS.

Når trinnet er fullført, bør databaseskjemaer for begge arkitekturnivåene (konseptuelle og eksterne) genereres, opprettet i datadefinisjonsspråket som støttes av det valgte DBMS.

Databaseskjemaer dannes ved å bruke en av to forskjellige tilnærminger:

• eller ved å bruke en nedenfra og opp-tilnærming, når arbeidet kommer fra de lavere nivåene med å definere attributter, gruppert i relasjoner som representerer objekter, basert på relasjonene som eksisterer mellom attributter;
• eller ved å bruke en omvendt, ovenfra-ned-tilnærming, brukt når antallet attributter øker betydelig (opptil hundrevis og tusenvis).

Den andre tilnærmingen innebærer å identifisere en rekke enheter på høyt nivå og deres relasjoner med påfølgende detaljering til det nødvendige nivået, noe som for eksempel gjenspeiles i en modell laget basert på «entitetsrelasjon»-metoden. Men i praksis kombineres vanligvis begge tilnærmingene.

Fysisk databasedesign

På neste trinn av fysisk utforming av databasen vises den logiske strukturen i form av en databaselagringsstruktur, det vil si at den er knyttet til slike fysisk miljø lagring hvor data skal plasseres så effektivt som mulig. Her er dataskjemaet beskrevet i detalj, og indikerer alle typer, felt, størrelser og begrensninger. I tillegg til å utvikle indekser og tabeller, defineres grunnleggende spørringer.

Konstruksjonen av en fysisk modell innebærer å løse stort sett motstridende problemer:

1. oppgaver med å minimere datalagringsplass,
2. utfordringer for å oppnå integritet, sikkerhet og maksimal ytelse.

Den andre oppgaven er i konflikt med den første fordi, for eksempel:

• for at transaksjoner skal fungere effektivt, må du reservere diskplass for midlertidige objekter,
• for å øke søkehastigheten, må du opprette indekser, hvorav antallet bestemmes av antallet av alle mulige kombinasjoner av felt involvert i søket,
• for datagjenoppretting vil bli opprettet sikkerhetskopier database og føre en logg over alle endringer.

Alt dette øker størrelsen på databasen, så designeren leter etter en rimelig balanse der problemer løses optimalt ved intelligent plassering av data i minneplass, men ikke på bekostning av databasesikkerhet, som inkluderer både beskyttelse mot uautorisert tilgang og beskyttelse fra feil.

For å fullføre opprettelsen av en fysisk modell, vurderes dens operasjonelle egenskaper (søkehastighet, effektivitet av utførelse av spørringer og ressursforbruk, korrekthet av operasjoner). Noen ganger er dette stadiet, som stadiene av databaseimplementering, testing og optimalisering, samt vedlikehold og drift, tatt utenfor den umiddelbare utformingen av databasen.

Parameternavn	Betydning
Artikkel emne:	Databasedesignstadier
Rubrikk (tematisk kategori)	Forbindelse

Stadier av databasedesign.

Temaer: stadier av databasedesign, databasedesign basert på en objektrelasjonsmodell

Før du oppretter en database, må utvikleren bestemme hvilke tabeller databasen skal bestå av, hvilke data som må plasseres i hver tabell, og hvordan tabellene skal kobles sammen. Disse problemene er løst på databasedesignstadiet.

Som et resultat av designet må den logiske strukturen til databasen bestemmes, det vil si sammensetningen av relasjonstabeller, deres struktur og inter-tabellrelasjoner.

Før du oppretter en database, er det ekstremt viktig å ha en beskrivelse av det valgte fagområdet, som skal dekke reelle objekter og prosesser, identifisere alle nødvendige informasjonskilder for å tilfredsstille de forventede brukerforespørslene og bestemme behovene for databehandling.

Basert på en slik beskrivelse, på databasedesignstadiet, bestemmes sammensetningen og strukturen av fagområdedataene, som skal ligge i databasen og sikre oppfyllelsen av nødvendige forespørsler og brukeroppgaver. Datastrukturen til fagområdet kan vises ved hjelp av en informasjonslogisk modell. Basert på denne modellen kan en relasjonsdatabase enkelt lages.

Stadiene for å designe og lage en database bestemmes av følgende sekvens:

‣‣‣ konstruksjon av en informasjonslogisk datamodell av fagområdet;

‣‣‣ definisjon av logisk struktur relasjonsgrunnlag data;

‣‣‣ designe databasetabeller;

‣‣‣ lage et dataskjema;

‣‣‣ legge inn data i tabeller (opprette poster);

‣‣‣ utvikling av nødvendige skjemaer, spørringer, makroer, moduler, rapporter;

‣‣‣ utvikling av brukergrensesnittet.

I prosessen med å utvikle en datamodell er det ekstremt viktig å identifisere informasjonsobjekter som oppfyller kravene til datanormalisering og bestemme relasjonene mellom dem. Denne modellen lar deg lage en relasjonsdatabase uten duplisering, som sikrer engangsdataregistrering under innledende lasting og justeringer, samt dataintegritet når endringer gjøres.

Ved utvikling av en datamodell kan to tilnærminger brukes. I den første tilnærmingen Først bestemmes hovedoppgavene for løsningen som basen er bygget av, databehovene til oppgavene identifiseres, og sammensetningen og strukturen til informasjonsobjekter bestemmes deretter. På den andre tilnærmingen Typiske objekter fra fagområdet installeres umiddelbart. Den mest rasjonelle kombinasjonen av begge tilnærmingene. Dette skyldes det faktum at på det første stadiet Som regel er det ingen utfyllende informasjon om alle oppgaver. Bruken av slik teknologi er desto mer berettiget fordi fleksible verktøy for å lage relasjonsdatabaser lar deg gjøre endringer i databasen og endre strukturen på ethvert utviklingsstadium uten å skade tidligere innlagte data.

Prosessen med å identifisere informasjonsobjekter i et fagområde som oppfyller kravene til normalisering, kan utføres på grunnlag av en intuitiv eller formell tilnærming. Teoretisk grunnlag formell tilnærming ble utviklet og fullstendig presentert i monografier om organisering av databaser av den berømte amerikanske vitenskapsmannen J. Martin.

Med en intuitiv tilnærming kan informasjonsobjekter tilsvarende ekte gjenstander. Samtidig krever den resulterende informasjonslogiske modellen, som regel, ytterligere transformasjoner, spesielt transformasjonen av flerverdige forhold mellom objekter. Med denne tilnærmingen er betydelige feil mulig hvis det ikke er nok erfaring. Etterfølgende verifisering av etterlevelse av normaliseringskrav viser vanligvis den ekstreme viktigheten av å avklare informasjonsobjekter.

La oss vurdere de formelle reglene som kan brukes til å identifisere informasjonsobjekter.

‣‣‣ basert på beskrivelsen av fagområdet, identifisere dokumenter og deres attributter som skal lagres i databasen;

‣‣‣ bestemme funksjonelle avhengigheter mellom attributter;

‣‣‣ velg alle avhengige attributter og angi for hver alle dens nøkkelattributter, dvs. de som den er avhengig av;

‣‣‣ Grupper attributter som er like avhengige av nøkkelattributter. De resulterende gruppene av avhengige attributter, sammen med deres nøkkelattributter, danner informasjonsobjekter.

Når man definerer den logiske strukturen til en relasjonsdatabase basert på en modell, er hvert informasjonsobjekt tilstrekkelig representert av en relasjonstabell, og relasjonene mellom tabeller tilsvarer relasjonene mellom informasjonsobjekter.

Under opprettelsesprosessen vil databasetabellene som tilsvarer informasjonsobjekter konstruert datamodell. Deretter kan et dataskjema lages der eksisterende logiske forbindelser mellom tabeller registreres. Disse koblingene tilsvarer koblingene til informasjonsobjekter. Dataskjemaet kan spesifisere parametere for å opprettholde integriteten til databasen dersom datamodellen ble utviklet i samsvar med normaliseringskrav. Dataintegritet betyr at relasjoner mellom poster er etablert og korrekt vedlikeholdt i databasen forskjellige bord når du laster inn, legger til og sletter poster i relaterte tabeller, samt når du endrer verdiene til nøkkelfelt.

Etter at dataskjemaet er dannet, legges konsistente data fra fagområdedokumentene inn.

Basert på den opprettede databasen genereres de nødvendige spørringene, skjemaene, makroene, modulene, rapportene som utfører den nødvendige behandlingen av databasedataene og deres presentasjon.

Ved hjelp av innebygde verktøy og databaseverktøy opprettes databasen brukergrensesnitt, slik at du kan administrere prosessene med å legge inn, lagre, behandle, oppdatere og presentere databaseinformasjon.

2 Designe en database basert på en objektrelasjonsmodell

Tilgjengelig hele linjen teknikker for å lage informasjon og logiske modeller. En av de mest populære metodene for å utvikle modeller bruker ERD (Entity-Relationship Diagrams). I russiskspråklig litteratur kalles disse diagrammene "objekt - forhold" eller "essens - forbindelse". ERD-modellen ble foreslått av Peter Ping Shen Chen i 1976. Til dags dato har flere av dens varianter blitt utviklet, men de er alle basert på de grafiske diagrammene foreslått av Chen. Diagrammer er laget av lite antall komponenter. På grunn av klarheten i presentasjonen er de mye brukt i CASE-verktøy (Computer Aided Software Engineering).

La oss se på terminologien og notasjonen som brukes.

Entitet- en reell eller imaginær gjenstand som har betydning for det aktuelle fagområdet, og informasjon om hvilken er gjenstand for lagring.

Hver enhet må ha en unik identifikator. Hver forekomst av en enhet må være unikt identifiserbar og forskjellig fra alle andre forekomster av denne typen(enheter). Hver enhet må ha visse egenskaper:

‣‣‣ har unikt navn; Dessuten må den samme tolkningen (entitetsdefinisjon) alltid brukes på dette navnet. Og omvendt: samme tolkning kan ikke brukes på forskjellige navn, med mindre de er pseudonymer;

‣‣‣ har en eller flere attributter som enten tilhører enheten eller som er arvet av den gjennom et forhold;

‣‣‣ har ett eller flere attributter som unikt identifiserer hver forekomst av en enhet.

En enhet må være uavhengig eller avhengig. Et tegn på en avhengig enhet er tilstedeværelsen av attributter som er arvet gjennom et forhold (fig. 1.).

Hver enhet kan ha et hvilket som helst antall forbindelser med andre enheter i modellen.

Forhold- en navngitt assosiasjon mellom to enheter som har betydning for fagområdet som vurderes. En av enhetene som deltar i forbindelsen er uavhengig, vanligvis kalt en overordnet enhet, den andre er avhengig, vanligvis kalt en underordnet eller etterkommer enhet. Vanligvis er hver forekomst av en overordnet enhet assosiert med et vilkårlig (inkludert null) antall forekomster av en underenhet. Hver forekomst av en underenhet er knyttet til nøyaktig én forekomst av dens overordnede enhet. En forekomst av en underordnet enhet kan imidlertid bare eksistere hvis den overordnede enheten eksisterer.

Forbindelsen får et navn, uttrykt ved den grammatiske vendingen av verbet og plassert nær forbindelseslinjen. Hvert navn forholdet mellom to gitte enheter må være unikt, men navnene på relasjonene i modellen trenger ikke å være unike. Hver forbindelse har en definisjon. Definisjonen av et forhold dannes ved å kombinere navnet på den overordnede enheten, navnet på forholdet, et uttrykk for graden av tilknytning og navnet på den underordnede enheten.

For eksempel bør selgers tilknytning til kontrakten defineres som følger:

‣‣‣ selgeren kan motta kompensasjon for en eller flere kontrakter;

‣‣‣ kontrakten må initieres av nøyaktig én selger.

I diagrammet er forbindelsen avbildet som et segment (polylinje). Endene av segmentet bruker spesielle symboler (fig. 2) for å indikere graden av forbindelse. Samtidig indikerer linjens natur - stiplet eller solid - forbindelsens obligatoriske natur.

Egenskap- ethvert kjennetegn ved en enhet som er vesentlig for fagområdet som vurderes. Det er ment å kvalifisere, identifisere, klassifisere, kvantifisere eller uttrykke tilstanden til en enhet. Et attributt representerer en type kjennetegn (egenskaper) assosiert med et sett av virkelige eller abstrakte objekter (mennesker, steder, hendelser, tilstander, ideer, gjenstandspar osv.) (Fig. 3). Attributtforekomst- dette er en viss egenskap ved en spesifikk forekomst av en enhet. En attributtforekomst er definert av typen av egenskapen (for eksempel "Farge") og dens verdi (for eksempel "lilla"), kalt attributtverdien. I ER-modellen er attributter knyttet til spesifikke enheter. Hver enhetsforekomst må ha én spesifikk verdi for hver av dens attributter.

Attributten må være enten obligatorisk, eller valgfri. Obligatorisk betyr at attributtet ikke kan akseptere nullverdier. Attributtet må enten være beskrivende (dvs. en vanlig enhetsbeskrivelse) eller en del av unik identifikator (primærnøkkel).

Unik identifikator er et attributt eller et sett med attributter og/eller relasjoner som unikt karakteriserer hver forekomst av en gitt type enhet. Ved full identifikasjon blir en forekomst av en gitt enhetstype fullstendig identifisert av sine egne nøkkelattributter, ellers deltar også attributtene til en annen enhet, forelderen, i identifiseringen.

Identifikasjonens art vises i et diagram på kommunikasjonslinjen (fig. 4).

Hvert attributt identifiseres med et unikt navn, uttrykt med en grammatisk substantivfrase som beskriver egenskapen attributtet representerer. Attributter er representert som en liste over navn innenfor en tilknyttet enhetsblokk, der hvert attributt opptar en egen linje. Attributter som definerer primærnøkkelen er plassert øverst på listen og uthevet med tegnet ''#'.

Hver enhet må ha minst én mulig nøkkel. En kandidatenhetsnøkkel er ett eller flere attributter hvis verdier unikt identifiserer hver forekomst av enheten. Hvis det er flere mulige nøkler en av dem er utpekt som primærnøkkel, og resten er utpekt som alternative nøkler.

I dag er det, basert på Chens tilnærming, laget IDEF1X-metodikken, som er utformet med hensyn til krav som enkel læring og muligheten for automatisering. IDEFlX-diagrammer brukes av en rekke vanlige CASE-verktøy (spesielt ERwin, Design/IDEF).

En enhet i IDEF1X-metoden kalles vanligvis identifikatoren uavhengig eller ganske enkelt uavhengig hvis hver forekomst av enheten må identifiseres unikt uten å definere dens relasjoner med andre enheter. En enhet kalles vanligvis identifikatoravhengig eller ganske enkelt avhengig hvis den entydige identifiseringen av en enhetsinstans avhenger av dens forhold til en annen enhet (fig. 5).

Hver enhet får et unikt navn og nummer, atskilt med en skråstrek ’ʼ/ʼʼ og plassert over blokken.

Hvis en forekomst av en underordnet enhet er unikt bestemt av forholdet til den overordnede enheten, kalles forholdet vanligvis identifiserende, ellers - ikke-identifiserende.

Det identifiserende forholdet mellom en overordnet enhet og en barneenhet er avbildet som en heltrukket linje. I fig. 5: Nr. 2 - avhengig enhet, Relasjon 1 - identifiserende relasjon. En underordnet enhet i et identitetsforhold er en identifikatoravhengig enhet. Den overordnede enheten i et identitetsforhold må være både en identitetsuavhengig og en identitetsavhengig enhet (dette bestemmes av dens relasjoner til andre enheter).

Den stiplede linjen representerer et ikke-identifiserende forhold. I fig. 5: Nr. 4 - selvstendig enhet, Relasjon 2 - ikke-identifiserende forhold. En underordnet enhet i et ikke-identifiserende forhold vil være uavhengig av identifikatoren med mindre det også er en underordnet enhet i et eller annet identifiserende forhold.

Forholdet kan defineres ytterligere ved å spesifisere grad eller kardinalitet (antall forekomster av den underordnede enheten som kan eksistere for hver forekomst av den overordnede enheten). I IDEF1X er følgende koblingskrefter uttrykt:

‣‣‣ Hver overordnede enhetsforekomst kan ha null, én eller flere underordnede enhetsforekomster knyttet til seg;

‣‣‣ Hver overordnede enhetsinstans må ha minst én underordnet enhetsinstans tilknyttet seg;

‣‣‣ Hver overordnede enhetsinstans må ha høyst én underordnet enhetsinstans tilknyttet seg;

‣‣‣ Hver forekomst av en overordnet enhet er knyttet til et bestemt antall forekomster av en underenhet.

Kommunikasjonseffekten er indikert som vist i fig. 6 (standard strøm -N).

Enheter kan også ha fremmednøkler. I et identifiserende forhold brukes de som en del av eller hele primærnøkkelen; i et ikke-identifiserende forhold fungerer de som ikke-nøkkelattributter. I attributtlisten er en fremmednøkkel merket med bokstavene FK i parentes.

Resultatet er en informasjonslogisk modell, som brukes av en rekke vanlige CASE-verktøy, som ERwin, Design/IDEF. På sin side har CASE-teknologier et stort potensial i utviklingen av databaser og informasjonssystemer, nemlig å øke arbeidsproduktiviteten, forbedre kvaliteten programvareprodukter, som støtter en enhetlig og konsistent arbeidsstil.

Stadier av databasedesign - konsept og typer. Klassifisering og funksjoner i kategorien "Stages of database design" 2017, 2018.

Når du oppretter en database, kan du skille mellom følgende trinn:

1. Formulering av problemet. På dette stadiet er det nødvendig å bestemme hvilken informasjon som skal lagres i den planlagte databasen og hvordan den skal brukes. Ut fra dette vil det være mulig å bestemme hvilke tabeller som skal lagres i databasen og hvilke opplysninger (felter) som skal inkluderes i hver tabell.

2. Beskrivelse av strukturen til databasetabeller. På dette stadiet er det nødvendig å beskrive hver tabell - angi hvilke felt som skal inneholde i tabellen, typen og størrelsen på data som er lagret i feltene, og angi primærnøkler.

3. Definere relasjoner mellom tabeller. Når alle tabellene er definert, må du fortelle Access hvilke handlinger du skal gjøre for å kombinere innholdet i tabellene som utgjør databasen.

4. Testing og forbedring. På dette tidspunktet må du legge inn noen få poster i hver tabell og sjekke om du kan trekke ut nødvendig informasjon fra disse tabellene. Det anbefales at du lager utkast til skjemaer og rapporter for å finne ut om de inneholder den informasjonen du forventer.

Legge inn data og lage andre databaseobjekter. Hvis databasestrukturen oppfyller kravene, kan du begynne å legge inn data og lage nødvendige spørringer, skjemaer, rapporter, datatilgangssider, makroer og moduler.

17. TABELLER

Bord- et databaseobjekt som brukes til å lagre data.

Vanligvis består en database av flere tabeller, som hver inneholder informasjon om bare ett emne. Hver tabell består av rader og kolonner, som vanligvis kalles poster og felt hhv.

Ta opp- en rad i en databasetabell som inneholder all informasjon om et spesifikt element. For eksempel, i Bøker-tabellen i biblioteksdatabasen, er dette informasjon om en bestemt bok.

Felt- en kolonne i en databasetabell som utgjør en del av en post som er allokert for en egen egenskap ved en vare. For å gå tilbake til forrige eksempel, kan feltene være forfatterens etternavn, boktittel, utgivelsessted, utgiver, utgivelsesår, bokkode (eller bokkode).

BORDSTRUKTUR

Når du oppretter en database, må du først bestemme hvilken informasjon som skal lagres i den planlagte databasen og hvordan den skal brukes. Ut fra dette kan du bestemme hvilke tabeller (og hvor mange) som skal lagres i databasen (hver tabell skal være relatert til et spesifikt emneområde), og hvilke felt som skal inkluderes i hver tabell. Dermed er det nødvendig å beskrive strukturen til hver tabell - angi hvor mange felt som finnes i tabellen, definer et navn for hvert felt, angi type og størrelse på dataene.

Rekkefølgen på feltene, som indikerer navnene på feltene, typen data som er lagret i feltene, størrelsen på disse dataene osv. fastslå tabellstruktur.