Database design

Grunnleggende begreper om databaser og DBMS

Informasjonssystem (IS) Er et system basert på datateknologi, designet for lagring, søk, behandling og overføring av betydelige mengder informasjon, som har et visst praktisk omfang.

Database Er en IP som er lagret elektronisk.

Database (DB)- en organisert innsamling av data beregnet på langtidslagring i eksternt minne DATAMASKIN, konstant fornyelse og bruk.

Databaser brukes til å lagre og søke etter en stor mengde informasjon. Eksempler på databaser: Notisbok, ordbøker, oppslagsverk, oppslagsverk, etc.

Databaseklassifisering:

1. Etter arten av den lagrede informasjonen:

- Factographic - inneholde kort informasjon om de beskrevne objektene, presentert i et strengt definert format (arkivskap, for eksempel: DB for bokfondet til biblioteket, DB for institusjonens ansatte),

- Dokumentar - inneholder dokumenter (informasjon) av en helt annen type: tekst, grafikk, lyd, multimedia (arkiver, for eksempel: oppslagsverk, ordbøker, databaser over lovgivende handlinger innen strafferett, etc.)

2. Ved hjelp av datalagring:

- Sentralisert (lagret på én datamaskin),

- Distribuert (brukes i lokale og globale datanettverk).

3. Etter dataorganisasjonsstruktur:

- Relasjonell (tabell),

- Ikke-relasjonelle.

Begrepet "relasjonell" (fra lat. Relatio - relasjon ) indikerer at en slik datalagringsmodell er bygget på forholdet mellom dens bestanddeler. Relasjonell databasen er i hovedsak en todimensjonal bord... Hver rad i en slik tabell kalles en post. Kolonnene i tabellen kalles felt: hvert felt er preget av navn og datatopp. Et DB-felt er en tabellkolonne som inneholder verdiene til en spesifikk egenskap.

Egenskaper relasjonsmodell data:

Hvert tabellelement er ett dataelement;

Alle felt i tabellen er homogene, dvs. er av samme type;

Identiske poster ikke i tabellen;

Rekkefølgen på poster i tabellen kan være vilkårlig og kan karakteriseres av antall felt, datatype.

En hierarkisk kalt en database, hvor informasjonen er sortert som følger: ett element anses som det viktigste, resten er underordnet. V hierarkisk I databasen er postene ordnet i en bestemt rekkefølge, som trinnene på en stige, og datainnhentingen kan utføres ved sekvensiell "nedstigning" fra trinn til trinn. Denne modellen preget av slike parametere som nivåer, noder, tilkoblinger. Prinsippet for drift av modellen er slik at flere noder er flere lavt nivå er forbundet ved hjelp av kommunikasjon med en node på et høyere nivå.

Node - informasjonsmodell av elementet som ligger på dette nivået hierarki.

Egenskaper hierarkisk modell data:

Flere noder på lavere nivå er knyttet til kun én node på høyere nivå;

Et hierarkisk tre har bare ett toppunkt (rot), det er ikke underordnet noe annet toppunkt;

Hver node har sitt eget navn (identifikator);

Det er bare én vei fra rotposten til den mer private dataposten.

Den hierarkiske databasen er katalogen Windows-mapper som du kan jobbe med ved å starte File Explorer. Toppnivå opptar Desktop-mappen. Det andre nivået inneholder mappene Min datamaskin, Mine dokumenter, nettverksmiljø og Trash, som er etterkommere av Desktop-mappen, som er tvillinger imellom. På sin side er Min datamaskin-mappen stamfaren i forhold til mappene på tredje nivå, diskmappene (Disk 3.5 (A :), C :, D :, E :, F :) og systemmapper(Skrivere, kontrollpanel osv.).

Nettverk kalt en database der horisontale lenker legges til de vertikale hierarkiske lenkene. Ethvert objekt kan være master og underordnet.

Nettverksdatabasen er faktisk Verdensveven global datanettverk Internett. Hyperkoblinger knytter hundrevis av millioner dokumenter sammen til én enkelt distribuert nettverksbase data.

Programvare, designet for å fungere med databaser, kalles databasestyringssystem(DBMS). DBMS brukes til ryddig lagring og behandling store volumer informasjon.

Databasestyringssystem(DBMS) er et system som gir søk, lagring, korrigering av data, dannelse av svar på spørringer. Systemet sikrer sikkerheten til data, deres konfidensialitet, bevegelse og kommunikasjon med andre programvareverktøy.

De viktigste handlingene som brukeren kan utføre ved å bruke DBMS:

Oppretting av databasestruktur;

Fylle databasen med informasjon;

Endre (redigere) strukturen og innholdet i databasen;

Søk etter informasjon i databasen;

Sortering av data;

Databasebeskyttelse;

Databaseintegritetssjekk.

Moderne DBMS gjøre det mulig å inkludere i dem ikke bare tekst og grafisk informasjon men også lydbiter og til og med videoklipp.

Brukervennlighet DBMS lar deg lage nye databaser uten å måtte ty til programmering, men kun bruke innebygde funksjoner. DBMS sikrer korrekthet, fullstendighet og konsistens av data, samt lett tilgang til dem.

Populær DBMS - FoxPro, Access for Windows, Paradoks.

Dermed er det nødvendig å skille mellom den faktiske databasen (DB) - bestilte datasett, og databasestyringssystemer (DBMS) - programmer som administrerer lagring og behandling av data. For eksempel, Få tilgang til appen inkludert i kontorpakke programmer Microsoft Office, er et DBMS som lar brukeren opprette og behandle tabellbaserte databaser.

Prinsipper for bygningskontrollsystemer databaser følge av kravene som databaseorganisasjonen skal tilfredsstille:

- Ytelse og tilgjengelighet. Forespørsler fra brukeren tilfredsstilles av databasen med den hastigheten som kreves for å konsumere dataene. Brukeren mottar raskt data når han trenger det.

- Minimumskostnader. Lav kostnad lagring og bruk av data, minimere kostnadene ved å gjøre endringer.

- Enkelhet og brukervennlighet. Brukere kan enkelt finne ut og forstå hvilke data de har til rådighet. Datatilgang skal være enkel, unntatt mulige feil fra brukerens side.

- Enkelt å gjøre endringer. Databasen kan vokse og endre seg uten å forstyrre eksisterende måter å bruke dataene på.

- Søkeevne. Brukeren av databasen kan stille en rekke spørsmål om dataene som er lagret i den. Det såkalte spørringsspråket brukes for å oppnå dette.

- Integritet. Moderne baser data kan inneholde data som brukes av mange brukere. Det er svært viktig at dataelementer og forbindelsene mellom dem ikke brytes under drift. I tillegg bør maskinvarefeil og ulike typer tilfeldige feil ikke føre til irreversibelt tap av data. Dette betyr at databehandlingssystemet må inneholde en datagjenopprettingsmekanisme.

- Sikkerhet og personvern. Med datasikkerhet menes beskyttelse av data fra utilsiktet eller bevisst tilgang til dem av uautoriserte personer, fra uautorisert modifikasjon (endring) av data eller ødeleggelse av dem. Taushetsplikt er definert som retten til enkeltpersoner eller organisasjoner til å bestemme når, hvor mye informasjon som kan overføres til andre personer eller organisasjoner.

Videre, ved å bruke eksempelet på et av de vanligste databasebehandlingssystemene - Microsoft Access er en del av det populære Microsoft-pakken Kontor - vi vil bli kjent med de grunnleggende datatypene, hvordan man lager databaser og hvordan man jobber med databaser.

Database design

Som ethvert programvareprodukt har databasen sin egen livssyklus (LCBD). Hovedkomponenten i Livssyklus DB er opprettelsen av en enkelt database og programmer som er nødvendige for driften.

ZDBD inkluderer følgende hovedstadier:

1. Planlegging av databaseutvikling;

2. Fastsettelse av systemkrav;

3. Innsamling og analyse av brukerkrav:

4. Databasedesign:

Konseptdesign databaser – lage en konseptuell datamodell, dvs. informasjonsmodell... En slik modell lages uten å fokusere på noen spesifikk DBMS og datamodell. Ofte konseptuell modell database inkluderer: beskrivelse informasjonsobjekter, eller konsepter fagområde og forbindelser mellom dem; en beskrivelse av integritetsbegrensninger, dvs. Kravene til akseptable verdier data og koblinger mellom dem;

Logisk design databaser - lage en logisk datamodell; lage et databaseskjema basert på spesifikk modell data, for eksempel en relasjonsdatamodell. For en relasjonsdatamodell er en logisk modell et sett med relasjonsskjemaer, vanligvis med en indikasjon primærnøkler samt "koblinger" mellom relasjoner, som er fremmednøkler.

Konvertering av konseptmodellen til logisk modell, som regel utføres etter formelle regler. Dette stadiet kan i stor grad automatiseres.

På stadiet med logisk design blir spesifisiteten til en spesifikk datamodell tatt i betraktning, men spesifisiteten til en spesifikk DBMS kan ikke tas i betraktning.

Fysisk databasedesign - lage et databaseskjema for en bestemt DBMS, lage en beskrivelse av DBMS. Spesifikasjonene til en bestemt DBMS kan inkludere restriksjoner på navngivning av databaseobjekter, restriksjoner på støttede datatyper, etc. I tillegg inkluderer spesifikasjonene til et spesifikt DBMS i fysisk design valg av løsninger knyttet til fysisk miljø datalagring (valg av styringsmetoder diskminne, dele databasen etter filer og enheter, metoder for å få tilgang til data, utvikle databeskyttelsesverktøy), lage indekser, etc.;

5. Applikasjonsutvikling:

Transaksjonsdesign (en gruppe SQL-setninger (sett med kommandoer) utført som en helhet);

Design brukergrensesnitt;

6. Gjennomføring;

8. Testing;

9. Drift og vedlikehold:

Analyse av funksjonen og støtten til den originale versjonen av databasen;

Tilpasning, modernisering og støtte av reviderte versjoner.

Database design- prosessen med å lage et databaseskjema og bestemme de nødvendige integritetsbegrensningene (samsvar av informasjonen som er tilgjengelig i databasen med dens interne logikk, struktur og alle eksplisitt spesifiserte regler).

Hovedoppgavene til databasedesign:

Å gi lagring i databasen av all nødvendig informasjon.

Sikre muligheten til å innhente data om alle nødvendige forespørsler.

Redusere dataredundans og duplisering.

Sikre integriteten til databasen.

Før du begynner å lage en database, må du bruke litt tid på den. design.

Hovedmålet med å designe databaser (DB) er å redusere redundansen til lagrede data, og følgelig å spare mengden minne som brukes, å redusere kostnadene ved flere operasjoner for oppdatering av redundante kopier og å eliminere muligheten for inkonsekvenser pga. lagre informasjon om samme objekt på forskjellige steder. ... Det såkalte "rene" DB-prosjektet ("hvert faktum på ett sted") kan opprettes ved å bruken. Normalisering skal brukes i det endelige valideringsstadiet av OBD-designet.

En dårlig studie av strukturen til databasen fører nesten alltid til sløsing med tid for behandlingen av den i fremtiden. Erfarne utviklere bruker like mye tid på å designe databaser som å lage dem. Generelt inkluderer utviklingen av en database følgende stadier:

1. Bestemme formålet med databasen.

2. Bestemme hvilke kildedata databasen skal inneholde.

3. Bestemmelse av kildetabellene til databasen.

4. Bestemmelse av feltene som skal inkluderes i tabellene, og valg av felt som inneholder unike verdier.

5. Tilordne relasjoner mellom tabeller og endelig visning av den resulterende strukturen.

6. Oppretting av tabeller, sammenkobling og eksperimentell fylling av databasen med prøvedata.

7. Oppretting av skjemaer, rapporter og forespørsler om operasjoner med innlagte data.

Bestemme formålet med databasen

Utviklingen av hver database begynner med å undersøke problemet den må løse, eller behovet den må tilfredsstille.

Som et eksempel, la oss prøve å lage den enkleste basen data fra det skjønnlitterære biblioteket "Library". Databasen er laget for å lagre data om bøkene som er kjøpt av biblioteket, informasjon om plasseringen av enkelteksemplarer av hver utgave og informasjon om leserne.

Valg av informasjon som skal inkluderes i databasen

For å vedlikeholde bibliotekskataloger, organiser søket etter de nødvendige bøkene og bibliotekstatistikken, databasen bør lagre informasjon, hvorav det meste er plassert i kommenterte katalogkort. Analyse av forespørsler om litteratur viser at for å søke etter passende bøker (etter emne, forfatter, forlag, etc.) og velge den riktige (for eksempel ved merknad), bør følgende utheves egenskaper katalogkort:

2. Tittelen på boken.

3. Utgivelsessted (by).

4. Utgiver (navn på utgiver).

5. Utgivelsesår.

6. Merknad.

Attributtene som gjør det mulig å karakterisere lagringsstedene til individuelle eksemplarer av bøker inkluderer:

1. Romnummer (rom for oppbevaring av bøker).

2. Nummer på stativet i rommet.

3. Nummer på hylle på stativet.

4. Nummer (bokens inventarnummer).

5. Kjøpsdato.

6. Datoen da en bestemt bok ble lagt ut på et bestemt sted.

7. Datoen boken ble fjernet fra det angitte stedet.

Attributter som gjør det mulig å karakterisere lesere inkluderer:

1. Nummer på lånekortet (skjema).

2. Etternavnet til leseren.

3. Navnet på leseren.

4. Patronym for leseren.

5. Leserens adresse.

6. Telefonnummer til leseren.

7. Utstedelsesdato til leseren av en bestemt bok.

8. Termen som en bestemt bok er gitt til leseren for.

9. Dato for retur av boken.

Definere kildetabeller

Analyse av objektene og attributtene definert ovenfor lar deg definere følgende tabeller for databasen som er designet for å bygge databasen:

2. Bøker... Tabellen er laget for å lagre informasjon om bøker.

3. Forlag Tabellen er beregnet for lagring av informasjon om utgivere.

4. Oppbevaring... Tabellen er ment å beskrive lagringsstedet for bøker.

5. Utstedelse Tabellen er beregnet for lagring av informasjon om utgitte bøker.

6. Lesere Tabellen er beregnet for lagring av informasjon om bibliotekets lesere.

Velge de nødvendige tabellfeltene

Etter å ha bestemt settet med tabeller som er inkludert i databasen, må du tenke på hvilken informasjon om hvert objekt som skal inkluderes i hver av tabellene. Hvert felt må tilhøre en separat tabell. Samtidig må informasjonen i hvert felt være strukturelt elementær, det vil si at den skal lagres i feltene i form av de minste logiske komponentene.

Basert på ovenstående bestemmer vi Enger i de valgte tabellene og type lagrede data.

Bøker:

· bokkode- et numerisk felt designet for å identifisere hver spesifikk bok i databasen;

· boktittel

· merknad- tekstfelt;

· utstedelsesdato;

· dato for opptak til biblioteket;

· Oppbevaring.
Utgivere:

· utgiverkode- et numerisk felt designet for å identifisere hver spesifikke utgiver i databasen;

· utgivernavn- tegnfelt, ikke mer enn 256 tegn;

· byen hvor forlaget holder til- tegnfelt, ikke mer enn 25 tegn.

Oppbevaring:

· setekode- et numerisk felt designet for å identifisere hver spesifikk hylle i databasen;

· romnummer- numerisk felt;

· stativnummer- numerisk felt;

· hyllenummer Er et numerisk felt.

Utstedelse:

· utstede kode- et numerisk felt designet for å identifisere hvert enkelt problem i databasen;

· utstedt boknummer- numerisk felt;

· leserkode- numerisk felt;

· utstedelsesdato;

· utstedelsesdato(antall dager);

· returdato.

Lesere:

· lånekortnummer- et numerisk felt designet for å identifisere hver spesifikke leser i databasen;

· etternavn

· Navn- tegnfelt, ikke mer enn 50 tegn;

· patronymisk- tegnfelt, ikke mer enn 50 tegn;

· adresse- tegnfelt, ikke mer enn 256 tegn;

· telefon- tegnfelt, ikke mer enn 20 tegn.

Velge unike felt

I en relasjonsdatabase kan tabeller relateres til hverandre. Dette forholdet etableres ved hjelp av unike felt. Unike felt Er felt der verdier ikke kan gjentas. For eksempel identifiserer serien og nummeret til et pass entydig alle med pass. Et slikt felt (eller en kombinasjon av felt) som unikt identifiserer en post i en tabell kalles primærnøkkel Primærnøkkelfeltet kan også være serienummer poster i katalogen, personnummeret til en ansatt i bedriften, varevare i detaljhandelen.

For databasen vår er primærnøklene følgende felt:

Bøker - bokkode.

Utgivere - utgiverkode.

Oppbevaring - setekode.

Utstedelse - utstede kode.

Lesere – antall billett.

Tilordne forhold mellom tabeller

Krysstabelllenker kobler sammen to tabeller ved å bruke et felles felt som finnes i begge tabellene. Det finnes tre typer slike lenker:

· en til en- hver post i tabell A kan ikke assosieres med mer enn én post i tabell B;

· en-til-mange- én post i tabell A kan knyttes til mange poster i tabell B (for eksempel kan det være mange elever i hver klasse);

· mange-til-mange- hver post i tabell A kan knyttes til mange poster i tabell B, og hver post i tabell B - med mange poster i tabell A (for eksempel kan hver elev ha flere lærere, og hver lærer kan ha mange elever).

Relasjonsdatabaser lar deg ikke opprette mange-til-mange-relasjoner direkte. Imidlertid, i det virkelige liv slike relasjoner er veldig vanlige, så de implementeres gjennom hjelpetabeller, som kobler flere tabeller med en-til-mange-relasjoner.

For å koble en tabell til en annen, må du legge inn primærnøkkelfeltet fra den første tabellen til den andre tabellen, dvs. gå inn i den andre tabellen ekstern nøkkel... Kobling av to tabeller gjøres ved å koble sammen primærnøkkelen hovedtabell(på den ene siden av forholdet) til det samme fremmednøkkelfeltet i den relaterte tabellen (på mangesiden). Fremmednøkkelfelt i koblet tabell må være samme datatype som primærnøkkelen i den overordnede tabellen, med ett unntak. Hvis primærnøkkelen til hovedtabellen er av Counter-datatypen, må fremmednøkkelfeltet i den koblede tabellen være av numerisk datatype.

I databasen vår vil vi etablere følgende typer relasjoner mellom tabeller:

1. Forfattere - Bøker. Her er lenken mange-til-mange, enhver forfatter kan ha mer enn én bok, og enhver bok kan skrives av flere forfattere. Derfor introduserer vi en hjelpetabell "Forfattere - bøker" med følgende felt:

· bokkode.

2. Bøker - Forlag. Her er lenken mange-til-mange, enhver bok kan gis ut av flere forlag, og ethvert forlag gir ut mer enn én bok. Derfor introduserer vi en ekstra hjelpetabell "Bøker-utgivere" med følgende felt:

· bokkode;

· utgiverkode.

3. Oppbevaring - Bøker. Her er lenken en-til-mange, du kan legge mange bøker på én hylle, men en hvilken som helst bok kan bare stå på én hylle i lageret. Derfor er «Lagringssted»-feltet i «Bøker»-tabellen definert som en fremmednøkkel, og vi kobler «Lagringssted»- og «Bøker»-tabellene med primærnøkkelen «Plasseringskode» og fremmednøkkelen «Lagringssted».

4. Bøker - Utstedelse. Her er lenken en-til-mange, dvs. den samme boken kan gis ut flere ganger på forskjellige datoer til forskjellige lesere. Derfor er feltet «Utstedt boknummer» i tabellen «Utstedt» definert som en fremmednøkkel, og vi kobler tabellene «Bøker» og «Utstedt» med primærnøkkelen «Bokkode» og fremmednøkkelen «Utstedt boknummer» ".

5. Lesere - Utstedelse. Her er lenken en-til-mange, dvs. samme bok kan gis ut flere ganger til forskjellige lesere til forskjellige tider. Derfor er feltet "Leserkode" i tabellen "Utsted" definert som en fremmednøkkel, og vi kobler tabellene "Lesere" og "Utsted" med primærnøkkelen "Library card number" og fremmednøkkelen "Leserkode" .

Normalisering av relasjoner

Når du er ferdig med å designe tabeller og identifisere relasjonene som eksisterer mellom dem, må du nøye dobbeltsjekke den resulterende strukturen før du fortsetter med å lage tabeller og legge inn informasjon. Normalisering av relasjoner kan redusere mengden lagret informasjon betydelig og eliminere anomalier i organiseringen av datalagring.

Regel 1: Hvert felt i en tabell må representere en unik type informasjon.

Databasen vi har laget har ingen felt i forskjellige bord ah som inneholder den samme informasjonen (unntatt fremmednøkler).

Regel 2: Hver tabell må ha en unik identifikator, eller primærnøkkel, som kan bestå av ett eller flere felt.

I databasen vi har laget inneholder alle tabeller (bortsett fra hjelpetillegget "Forfattere - bøker" og "Utgivere - bøker") en primærnøkkel.

Regel 3: For hver primærnøkkelverdi må verdiene i datakolonnene referere til og fullstendig beskrive tabellobjektet.

Denne regelen brukes på to måter. For det første skal det ikke være noen data i tabellen som ikke er relatert til objektet identifisert av primærnøkkelen. For eksempel, selv om hver bok krever informasjon om forfatteren, er forfatteren det uavhengig objekt, og data om det skal være i den tilsvarende tabellen. For det andre må dataene i tabellen fullstendig beskrive objektet.

Regel 4: det skal være mulig å endre verdiene til ethvert felt (ikke inkludert i primærnøkkelen) uten å påvirke dataene til andre felt.

Den siste regelen lar deg sjekke om det vil være problemer ved endring av dataene i tabellene. Siden i databasen vi har designet, som finnes i forskjellige felt i tabellene, ikke gjentas noe sted, har vi muligheten til å justere verdiene til alle felt (med unntak av primærnøkler).

Fylle ut databasen, lage skjemaer og rapporter

For å finne ut hvordan strukturen til databasen samsvarer med oppgaven og hvor praktisk det er å jobbe med denne databasen, må du legge inn noen få enkle poster. Vanligvis etter det må du gå tilbake til strukturen til databasen og justere den i samsvar med resultatene oppnådd under en slik test.

På siste trinn lage skjemaer for å legge inn informasjon i databasen, rapporter for visning av informasjon og spørringer, ved hjelp av hvilke informasjon velges fra flere tabeller. Hvis basen er ment å bli overført til andre brukere, er det mest sannsynlig nødvendig at noen fra fremmede sjekket hvor praktisk det er å jobbe med skjemaer og rapporter.

Mottatt dataskjema den utviklede databasen i MS Access er vist i fig. 4.1.

Ris. 4.1. Dataskjema for den utviklede databasen i Microsoft Access

Kontrollspørsmål

1. Gi definisjonen av et informasjonssystem.

2. Forklar begrepet en database.

3. Hva er et fagområde?

4. Gi definisjonen av et DBMS.

5. Hva er en datamodell?

6. Forklar de grunnleggende prinsippene for relasjonsdatamodellen.

7. Forklar funksjonene til Microsoft Access DBMS.

8. Hva er hovedobjektene til en Access-database?

9. Forklar strukturen til Access-tabellen.

10. Forklar begrepene: spørring, skjema, rapport, datatilgangsside, makro, modul.

11. Hva er hovedstadiene i databasedesign?

12. Hvordan gjennomføres valget av informasjon som inngår i databasen?

13. Forklar begrepene: primærnøkkel, fremmednøkkel.

14. Hva er hensikten med relasjoner mellom tabeller?

15. Forklar hovedtypene av sammenhenger mellom tabeller.

16. Hva er normaliseringen av databaserelasjoner?

Når du utvikler en database, kan følgende stadier av arbeidet skilles.

Trinn I. Formulering av problemet.

På dette stadiet dannes en oppgave for å lage en database. Den beskriver i detalj sammensetningen av databasen, formålet med og formålet med dens opprettelse, og lister også opp hvilke typer arbeid som skal utføres i denne databasen (valg, tillegg, dataendring, utskrift eller utdata av en rapport, etc. .).

Trinn II. Objektanalyse.

På dette stadiet vurderes det hvilke objekter databasen kan bestå av, hva er egenskapene til disse objektene. Etter å ha delt databasen i separate objekter, er det nødvendig å vurdere egenskapene til hvert av disse objektene, eller med andre ord å fastslå hvilke parametere som beskriver hvert objekt. All denne informasjonen kan ordnes i skjemaet individuelle poster og tabeller. Deretter må du vurdere datatypen for hver enkelt registreringsenhet. Informasjon om datatyper bør også legges inn i tabellen som opprettes.

Trinn III. Syntese av modellen.

På dette stadiet, i henhold til analysen ovenfor, er det nødvendig å velge en viss modell DB. Videre vurderes fordelene og ulempene ved hver modell og sammenlignes med kravene og oppgavene til databasen som opprettes. Etter en slik analyse, velg modellen som kan maksimere gjennomføringen av oppgaven. Etter å ha valgt en modell, må du tegne diagrammet som viser relasjonene mellom tabeller eller noder.

Trinn IV. Valg av måter å presentere informasjon på og programvareverktøy.

Etter å ha opprettet modellen, er det nødvendig, avhengig av den valgte programvareprodukt, bestemme formen for informasjonspresentasjon.

I de fleste DBMS-er kan data lagres i to former:

• ved hjelp av skjemaer;
• uten å bruke skjemaer.

Formen Er brukerskapt grafisk grensesnittå legge inn data i databasen.

Trinn V. Syntese datamaskinmodell gjenstand.

I prosessen med å lage en datamodell, kan noen stadier skilles ut som er typiske for enhver DBMS.

1. stadie. Starte DBMS, opprette en ny databasefil eller åpne en tidligere opprettet database.

Trinn 2. Oppretting av den eller de originale tabellene.

Når du oppretter den opprinnelige tabellen, må du angi navn og type for hvert felt. Feltnavn skal ikke gjentas i samme tabell. I prosessen med å jobbe med databasen kan du supplere tabellen med nye felt. Den opprettede tabellen må lagres ved å gi den et navn som er unikt innenfor rammen av databasen som opprettes.

1. Informasjonen i tabellen skal ikke dupliseres. Det skal ikke være repetisjoner mellom bordene. Når visse opplysninger er lagret i kun én tabell, så må den bare endres på ett sted. Dette gjør arbeidet mer effektivt, og eliminerer også muligheten for informasjonsmismatch i ulike tabeller. For eksempel skal én tabell inneholde adresser og telefonnumre til kunder.

2. Hver tabell skal inneholde informasjon om kun ett emne. Informasjon om hvert emne er mye lettere å behandle hvis den finnes i tabeller som er uavhengige av hverandre. For eksempel er det bedre å lagre kundeadresser og bestillinger i forskjellige tabeller slik at når bestillingen slettes, forblir kundeinformasjonen i databasen.

3. Hver tabell må inneholde Obligatoriske felt... Hvert felt i en tabell skal inneholde egen informasjon om emnet for tabellen. For eksempel kan en tabell med kundedata inneholde felt med firmanavn, adresse, by, land og telefonnummer. Når du designer feltene for hver tabell, husk at hvert felt må knyttes til emnet for tabellen. Det anbefales ikke å inkludere data i tabellen som er resultatet av et uttrykk. Tabellen må inneholde alle nødvendig informasjon... Informasjon bør brytes ned i de minste logiske enhetene (for eksempel feltene Fornavn og Etternavn, ikke det generelle Fornavn-feltet).

4. Databasen må ha en primærnøkkel. Dette er nødvendig for at DBMS skal kunne koble data fra ulike tabeller, for eksempel data om en kunde og hans ordre.

Trinn 3. Oppretting av skjermskjemaer.

Til å begynne med må du spesifisere tabellen som skjemaet skal opprettes på grunnlag av. Den kan lages ved å bruke skjemaveiviseren, spesifisere hvilken type den skal ha, eller på egen hånd. Når du oppretter et skjema, kan du angi ikke alle feltene som tabellen inneholder, men bare noen av dem. Navnet på skjemaet kan være det samme som navnet på tabellen som den ble opprettet på grunnlag av. På grunnlag av én tabell kan du lage flere skjemaer som kan variere i type eller antall felter som brukes fra denne tabellen. Etter å ha opprettet skjemaet, må du lagre det. Det opprettede skjemaet kan redigeres ved å endre plassering, størrelse og format på feltene.

Trinn 4. Fyller databasen.

Prosessen med å fylle ut databasen kan utføres i to former: i form av en tabell og i form av et skjema. Numerisk og tekstbokser kan fylles ut i form av en tabell, og felt av typen MEMO og OLE - i form av et skjema.

Trinn VI. Arbeide med den opprettede databasen.

Arbeid med databasen inkluderer følgende handlinger:

• søke etter nødvendig informasjon;
• sortering av data;
• utvalg av data;
• utskrift;
• endring og tillegg av data.

Grunnleggende oppgaver for databasedesign

Hovedmål:

• Å gi lagring i databasen av all nødvendig informasjon.
• Sikre muligheten til å innhente data om alle nødvendige forespørsler.
• Redusere dataredundans og duplisering.
• Sikre dataintegritet (riktighet av innholdet): eliminering av motsetninger i innholdet av data, eliminering av tap av dem, etc.

De viktigste stadiene i databasedesign

Konseptuell (infologisk) design- konstruksjon av en semantisk modell av fagområdet, det vil si en informasjonsmodell av høyeste abstraksjonsnivå. En slik modell lages uten å fokusere på noen spesifikk DBMS og datamodell. Begrepene "semantisk modell", "konseptuell modell" og " infologisk modell"Er synonyme. I tillegg kan ordene «databasemodell» og «domenemodell» (for eksempel «konseptuell databasemodell» og «konseptuell domenemodell») brukes likt, siden en slik modell både er et bilde av virkeligheten og et bilde en projisert database for denne virkeligheten.

Den spesifikke typen og innholdet i den konseptuelle modellen til databasen bestemmes av det formelle apparatet som er valgt for dette. Grafiske notasjoner som ligner på ER-diagrammer er ofte brukt.

Oftest inkluderer den konseptuelle databasemodellen:

• beskrivelse av informasjonsobjekter, eller begreper om fagområdet og sammenhenger mellom dem.
• en beskrivelse av integritetsbegrensninger, dvs. krav til gyldige dataverdier og forhold mellom dem.

Logisk (datalogisk) design- lage et databaseskjema basert på en spesifikk datamodell, for eksempel en relasjonsdatamodell. For en relasjonsdatamodell er en datalogisk modell et sett med relasjonsskjemaer, som vanligvis spesifiserer primærnøkler, så vel som "relasjoner" mellom relasjoner, som er fremmednøkler.

Transformasjonen av en konseptuell modell til en logisk modell utføres vanligvis etter formelle regler. Dette stadiet kan i stor grad automatiseres.

På stadiet med logisk design blir spesifisiteten til en spesifikk datamodell tatt i betraktning, men spesifisiteten til en spesifikk DBMS kan ikke tas i betraktning.

Fysisk design

Fysisk design- lage et databaseskjema for et spesifikt DBMS. Spesifikasjonene til en bestemt DBMS kan inkludere restriksjoner på navngivning av databaseobjekter, restriksjoner på støttede datatyper, etc. I tillegg inkluderer spesifikasjonene til en bestemt DBMS i fysisk design valg av løsninger relatert til det fysiske lagringsmiljøet (valg av metoder for å administrere diskminne, dele databasen etter filer og enheter, metoder for å få tilgang til data), lage indekser, etc. .

Normalisering

Ved utforming av relasjonsdatabaser gjøres vanligvis såkalt normalisering.

Entitetsforholdsmodeller

Entitetsforholdsmodellen (eng. "Entitet-relasjonsmodell" ), eller ER-modellen foreslått av P. Chen i 1976, er den mest kjente representanten for klassen av semantiske (konseptuelle, infologiske) modeller av domenet. ER-modellen presenteres vanligvis i grafisk form, ved å bruke P. Chens originale notasjon, kalt ER-diagram, eller bruke andre grafiske notasjoner ( Kråkefot, Informasjonsteknikk og så videre.).

De viktigste fordelene med ER-modeller:

• synlighet;
• modeller lar deg designe databaser med stort beløp objekter og attributter;
• ER-modeller er implementert i mange systemer datastyrt design databaser (for eksempel ERWin).

Hovedelementene i ER-modeller:

• objekter (enheter);
• objektattributter;
• forbindelser mellom objekter.

En enhet er et domeneobjekt som har attributter.

Forholdet mellom enheter er preget av:

• kommunikasjonstype (1: 1, 1: N, N: M);
• klasse av tilhørighet. Klassen kan være obligatorisk eller valgfri. Hvis hver forekomst av en enhet deltar i et forhold, kreves medlemsklassen, ellers er den valgfri.

Semantiske modeller

Semantisk modell (konseptuell modell, infologisk modell) - en domenemodell designet for å representere semantikken til domenet helt høy level abstraksjon. Dette betyr at behovet for å bruke "lavnivå"-konsepter knyttet til spesifikasjonene ved den fysiske presentasjonen og lagringen av data er eliminert eller minimert.

Dato KJ Introduksjon til databasesystemer. - 8. utg. - M .: "Williams", 2006:

Semantisk modellering har vært gjenstand for intens forskning siden slutten av 1970-tallet. Hovedmotivet bak slike studier (dvs. problemet som forskerne prøvde å løse) var følgende faktum. Poenget er at databasesystemer vanligvis har svært begrenset kunnskap om betydningen av dataene de lagrer. Oftest lar de deg bare manipulere dataene til visse enkle typer og definere noen av de enkleste integritetsbegrensningene som er pålagt disse dataene. Enhver mer kompleks tolkning er overlatt til brukeren. Det ville imidlertid vært flott om systemene kunne ha litt mer informasjon og et litt smartere svar på brukerforespørsler, og støtte mer komplekse (dvs. høyere nivå) brukergrensesnitt.
[…]
Semantiske modelleringsideer kan være nyttige som et databasedesignverktøy selv om de ikke støttes direkte av DBMS.

Klassens mest kjente representant semantiske modeller er enhet-relasjonsmodellen (ER-modellen).

Litteratur

• Dato C.J. Introduksjon til databasesystemer. - 8. utg. - M .: "Williams", 2006. - 1328 s. - ISBN 0-321-19784-4
• Kogalovsky M.R. Avanserte teknologier informasjonssystemer... - M .: DMK Trykk; IT Co., 2003 .-- 288 s. - ISBN 5-279-02276-4
• Kogalovsky M.R. Encyclopedia of Database Technologies. - M .: Finans og statistikk, 2002. - 800 s. - ISBN 5-279-02276-4
• S. D. Kuznetsov Grunnleggende om databasen. - 2. utg. - M .: Internettuniversitet Informasjonsteknologier; BINOMIAL. Kunnskapslaboratoriet, 2007. - 484 s. - ISBN 978-5-94774-736-2
• Connolly T., Begg K. Database. Design, implementering og vedlikehold. Teori og praksis = Databasesystemer: En praktisk tilnærming til design, implementering og ledelse. - 3. utg. - M .: "Williams", 2003. - 1436 s. - ISBN 0-201-70857-4
• Garcia-Molina G., Ullman J., Widom J. Databasesystemer. Komplett kurs... - M .: "Williams", 2003. - 1088 s. - ISBN 5-8459-0384-X

se også

• Designmetoder

Lenker

• Entity-relationship modell - et skritt mot et enhetlig syn på data - Citforum
• Utvide relasjonsmodellen til bedre å reflektere semantikk - Citforum
• En nybegynnerveiledning for design av nettsteddatabase
• En metode for å designe den logiske strukturen til en relasjonsdatabase uten å normalisere tabeller

Notater (rediger)

Wikimedia Foundation. 2010.

Se hva "Databasedesign" er i andre ordbøker:

Databaseadministratoren er den ansvarlige for utvikling av krav til databasen, dens utforming, implementering, effektiv bruk og støtte, inkludert ledelse kontoer databasebrukere og beskyttelse mot uautoriserte ... ... Wikipedia

- (English database refactoring) er en enkel endring i databaseskjemaet, som bidrar til forbedring av designen samtidig som den funksjonelle og informasjonsmessige semantikken opprettholdes. Med andre ord kan ikke konsekvensen av databaserefaktorering være ... ... Wikipedia

DESIGN- en av formene for forutseende refleksjon av virkeligheten, prosessen med å skape en prototype (prototype) av det påståtte objektet, fenomenet eller prosessen ved hjelp av spesifikke. metoder. P. er en spesifikk form for manifestasjon av prognostisk. kontrollfunksjoner, ... ... Russisk sosiologisk leksikon

"DB"-forespørselen omdirigeres hit; se også andre betydninger. En database presentert i en objektiv form, et sett med uavhengig materiale (artikler, beregninger, forskrifter, rettsavgjørelser og annet lignende materiale), ... ... Wikipedia