Database designstadier. Databasestyringssystemer. Trinn II. Objektanalyse

Oversettelse av en serie på 15 artikler om databasedesign.
Informasjonen er beregnet på nybegynnere.
Hjalp meg. Kanskje det vil hjelpe noen andre med å fylle hullene.

Databasedesignguide.

1. Introduksjon.

Hvis du skal lage dine egne databaser, er det en god idé å følge databasedesignregler, da dette vil sikre langsiktig integritet og enkel vedlikehold av dataene dine. Denne veiledningen vil fortelle deg hva databaser er og hvordan du designer en database som følger designregler. relasjonsdatabaser data.

Databaser er programmer som lar deg lagre og motta store volumer relatert informasjon... Databaser består av tabeller, som inneholder informasjon... Når du oppretter en database, må du tenke på hvilken tabeller du trenger å lage og hva forbindelser finnes mellom informasjonen i tabellene. Du må med andre ord tenke deg om prosjekt databasen din. Bra prosjekt databaser, som nevnt tidligere, vil sikre dataintegritet og enkelt vedlikehold.

Databasen er opprettet for å lagre informasjon i den og innhente denne informasjonen om nødvendig. Dette betyr at vi må kunne plassere, sette inn ( SETT INN) informasjon inn i databasen og vi ønsker å kunne hente informasjon fra databasen ( PLUKKE UT).
Databasespørringsspråket ble oppfunnet for dette formålet og fikk navnet Strukturert spørrespråk eller SQL. Operasjonene med å sette inn data (INSERT) og deres valg (SELECT) er en del av dette språket. Nedenfor er et eksempel på en datahentingsspørring og resultatet.

SQL er et stort emne for historiefortelling og ligger utenfor denne veiledningen. Denne artikkelen er strengt fokusert på presentasjon databasedesignprosess... Senere, i en egen opplæring, skal jeg dekke det grunnleggende om SQL.

Den relasjonelle modellen.

I denne opplæringen vil jeg vise deg hvordan du lager en relasjonsdatamodell. En relasjonsmodell er en modell som beskriver hvordan man organiserer data i tabeller og hvordan man definerer relasjoner mellom disse tabellene.

Reglene for relasjonsmodellen tilsier hvordan informasjon skal organiseres i tabeller og hvordan tabeller forholder seg til hverandre. Til syvende og sist kan resultatet presenteres i form av et databasediagram eller, mer presist, et entitetsforholdsdiagram, som i figuren (eksempel hentet fra MySQL Workbench).

Eksempler.

Jeg har brukt en rekke apper som eksempler i opplæringen.

RDBMS.

RDBMS-en jeg brukte til å lage eksempeltabellene er MySQL. MySQL er den mest populære RDBMS og er gratis.

Databaseadministrasjonsverktøy.

Etter å ha installert MySQL får du bare grensesnittet kommandolinjeå samhandle med MySQL. Personlig foretrekker jeg et grafisk grensesnitt for å administrere databasene mine. Jeg bruker SQLyog mye. den gratis verktøy med et grafisk grensesnitt. Bilder av tabeller i denne håndboken tatt derfra.

Visuell modellering.

Det er en utmerket gratis app MySQL arbeidsbenk. Den lar deg designe databasen grafisk. Illustrasjonene av diagrammene i manualen er tatt i dette programmet.

Design uavhengig av RDBMS.

Det er viktig å vite at selv om denne opplæringen gir eksempler for MySQL, er databasedesign uavhengig av RDBMS. Dette betyr at informasjonen gjelder relasjonsdatabaser generelt, ikke bare MySQL. Du kan bruke kunnskap fra denne opplæringen til alle relasjonsdatabaser som Mysql, Postgresql, Microsoft Access, Microsoft SQL eller Oracle.

I neste del vil jeg kort snakke om utviklingen av databaser. Du vil finne ut hvor databasene kom fra og relasjonsmodell data.

2. Historie.

På 70- og 80-tallet, da dataforskere fortsatt hadde brune smoking og store, firkantede briller, ble data lagret ustrukturert i filer som var Tekstdokument med data atskilt (vanligvis) med kommaer eller tabulatorer.

Slik så IT-fagfolk ut på 70-tallet. (Bill Gates er nederst til venstre).

Tekstfiler brukes fortsatt i dag til å lagre små mengder enkel informasjon. Comma-Separated Values ​​(CSV) - Komma-separerte verdier er veldig populære og støttes bredt i dag av ulike programvare og operativsystemer. Microsoft Excel Er et av eksemplene på programmer som kan fungere med CSV-filer. Dataene som er lagret i en slik fil kan leses av et dataprogram.

Ovenfor er et eksempel på hvordan en slik fil kan se ut. Leseprogram av denne filen, må varsles om at dataene er atskilt med komma. Hvis programmet ønsker å velge og vise kategorien som leksjonen er plassert i "Opplæring for databasedesign", så skal den leses linje for linje til ord blir funnet "Opplæring for databasedesign" og så må hun lese det neste ordet etter kommaet for å vise kategorien Programvare.

Databasetabeller.

Å lese en fil linje for linje er ikke særlig effektivt. I en relasjonsdatabase lagres data i tabeller. Tabellen nedenfor inneholder de samme dataene som filen. Hver linje eller "post" inneholder én leksjon. Hver kolonne inneholder noen leksjonsegenskaper. V denne saken dette er tittelen og dens kategori.

Et dataprogram kan søke i tutorial_id-kolonnen i denne tabellen etter den spesifikke tutorial_id for raskt å finne den tilsvarende tittelen og kategorien. Dette er mye raskere enn å søke i filen linje for linje, akkurat som et program gjør i en tekstfil.

Moderne relasjonsdatabaser er designet for å kunne hente data fra spesifikke rader, kolonner og flere tabeller om gangen, veldig raskt.

Historien om relasjonsmodellen.

Relasjonsdatabasemodellen ble oppfunnet på 70-tallet av Edgar Codd, en britisk vitenskapsmann. Han ønsket å overvinne feil nettverksmodell databaser og hierarkisk modell... Og han var veldig vellykket i dette. Relasjonsdatabasemodellen er allment akseptert i dag og regnes som en kraftig modell for effektiv organisasjon data.

Et bredt spekter av databasebehandlingssystemer er tilgjengelig i dag: fra små skrivebordsapplikasjoner til multifunksjonelle serversystemer med svært optimaliserte søkemetoder. Her er noen av de mest kjente systemer relasjonsdatabaseadministrasjon (RDBMS):

- Oracle- brukes først og fremst til profesjonelle, store applikasjoner.
- Microsoft SQL server- RDBMS Microsoft... Kun tilgjengelig for operativsystem Windows.
- Mysql Er en veldig populær åpen kildekode RDBMS. Det er mye brukt av både profesjonelle og nybegynnere. Hva mer trengs?! Det er gratis.
- IBM- har en rekke RDBMS, den mest kjente er DB2.
- Microsoft Access- RDBMS, som brukes på kontoret og hjemme. Faktisk er det mer enn bare en database. MS Access lar deg lage databaser med et brukergrensesnitt.
I neste del vil jeg snakke om noen av egenskapene til relasjonsdatabaser.

3. Kjennetegn ved relasjonsdatabaser.

Relasjonsdatabaser er designet for hurtiglagring og motta store mengder informasjon. Følgende er noen av egenskapene til relasjonsdatabaser og relasjonsdatamodellen.

Ved hjelp av nøkler.

Hver rad med data i en tabell identifiseres av en unik "nøkkel" kalt primærnøkkelen. Ofte, primærnøkkel dette er et automatisk økende tall (1,2,3,4 osv.). Data i ulike tabeller kan kobles sammen ved hjelp av nøkler. Primærnøkkelverdiene til en tabell kan legges til radene (postene) i en annen tabell, og dermed koble disse postene sammen.

Ved hjelp av strukturert språk spørringer (SQL), data fra forskjellige bord som er koblet sammen med en nøkkel, kan velges på én gang. Du kan for eksempel lage en spørring som vil velge alle bestillinger fra ordretabellen som tilhører brukeren med id 3 (Mike) fra brukertabellen. Vi vil snakke om nøkler videre, i de følgende delene.

ID-kolonnen i denne tabellen er primærnøkkelen. Hver post har en unik primærnøkkel, ofte et tall. Brukergruppekolonnen er en fremmednøkkel. Som navnet antyder, refererer det tilsynelatende til en tabell som inneholder brukergrupper.

Ingen dataredundans.

I en databasedesign som er bygget ved hjelp av reglene for relasjonsdatamodellen, lagres hver informasjonsbit, for eksempel et brukernavn, på bare ett sted. Dette eliminerer behovet for å jobbe med data på flere steder. Duplisering av data kalles dataredundans og bør unngås i en god databasedesign.

Inndatabegrensning.

Ved hjelp av en relasjonsdatabase kan du definere hva slags data som er tillatt å lagre i en kolonne. Du kan lage et felt som inneholder heltall, desimaler, små tekstbiter, store tekstbiter, datoer osv.

Når du oppretter en databasetabell, oppgir du en datatype for hver kolonne. For eksempel er varchar en datatype for små tekstbiter med maksimalt antall tegn lik 255, og int er tall.

I tillegg til datatyper lar RDBMS deg ytterligere begrense dataene du kan legge inn. Begrens for eksempel lengden eller håndhev det unike ved verdien av poster i denne kolonnen... Sistnevnte begrensning brukes ofte for felt som inneholder brukerregistreringsnavn (pålogginger), eller adresser E-post.

Disse begrensningene gir deg kontroll over integriteten til dataene dine og forhindrer situasjoner som følgende:

Skriv inn en adresse (tekst) i feltet der du forventer å se et nummer
- gå inn i indeksen for regionen med lengden på den samme indeksen med hundre tegn
- opprette brukere med samme navn
- opprette brukere med samme e-postadresse
- legge inn vekt (tall) i bursdagsfeltet (dato)

Opprettholde dataintegritet.

Ved å justere feltegenskaper, koble tabeller og angi begrensninger, kan du øke påliteligheten til dataene dine.

Tildeling av rettigheter.

De fleste RDBMS-er tilbyr en tillatelsesinnstilling som lar deg tildele visse rettigheter enkelte brukere. Noen handlinger som kan tillates eller nektes for brukeren: VELG (hent), INSERT (sett inn), SLETT (slett), ENDRE (endre), LAG (opprett), etc. Dette er operasjoner som kan utføres ved hjelp av Structured Query Language (SQL).

Structured Query Language (SQL).

For å utføre visse operasjoner på databasen, som å lagre data, hente dem, endre dem, brukes et strukturert spørrespråk (SQL). SQL er relativt lett å forstå og tillater inkl. og stablede valg, for eksempel å hente relaterte data fra flere tabeller ved hjelp av SQL-setning BLI MED. Som nevnt tidligere, vil ikke SQL bli diskutert i denne opplæringen. Jeg vil fokusere på databasedesign.

Hvordan du designer databasen din vil ha en direkte innvirkning på spørringene du må utføre for å hente data fra databasen. Dette er en annen grunn til at du må tenke på hva basen din skal være. Med en godt utformet database kan søkene dine bli renere og enklere.

Bærbarhet.

Den relasjonsdatamodellen er standard. Ved å følge reglene for relasjonsdatamodellen kan du være sikker på at dataene dine relativt enkelt kan migreres til en annen RDBMS.

Som nevnt tidligere, er å designe en database et spørsmål om å identifisere data, koble dem sammen og plassere resultatene av en løsning. dette problemet på papir (eller i dataprogram). Design databasen uavhengig av RDBMS du har tenkt å bruke for å lage den.

I neste del skal vi se nærmere på primærnøkler.

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- bygge en semantisk modell fagområde, det er informasjonsmodell det høyeste abstraksjonsnivået. 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 informasjonsobjekter, eller begreper om fagområdet og sammenhenger mellom dem.
• en beskrivelse av integritetsbegrensninger, dvs. Kravene til akseptable verdier data og koblinger 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.

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

På scenen logisk design spesifikasjonene er tatt i betraktning spesifikk modell data, men spesifikasjonene til et bestemt 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 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, datatilgangsmetoder), lage indekser osv.

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. Oftere enn ikke tillater de bare manipulering av visse enkle datatyper og definerer 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.

Den mest kjente representanten for klassen av semantiske modeller er enhetsrelasjonsmodellen (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

Temaer: stadier av databasedesign, databasedesign basert på en modell av objektrelasjonstypen.

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

Som et resultat av designet bør den logiske strukturen til databasen bestemmes, det vil si sammensetningen av relasjonstabeller, deres struktur og inter-tabellkoblinger.

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

På grunnlag av en slik beskrivelse, på designstadiet av databasen, bestemmes fagområdets sammensetning og datastruktur, som skal ligge i databasen og sikre oppfyllelse av nødvendige forespørsler og brukeroppgaver. Datastrukturen til fagområdet kan vises ved en informasjonslogisk modell. Basert på denne modellen kan en relasjonsdatabase enkelt lages.

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

Bygge en informasjonslogisk datamodell av fagområdet;

Bestemme den logiske strukturen til en relasjonsdatabase;

Database tabell design;

Oppretting av dataskjemaer;

Legge inn data i tabeller (opprette poster);

Utvikling av nødvendige skjemaer, forespørsler, makroer, moduler, rapporter;

Utvikling av brukergrensesnitt.

I prosessen med å utvikle en datamodell er det nødvendig å velge informasjonsobjekter som oppfyller kravene til datanormalisering og bestemme relasjonene mellom dem. Denne modellen lar deg lage en relasjonsdatabase uten duplisering, som gir én enkelt oppføring av data under innledende lasting og justeringer, samt dataintegritet når endringer gjøres.

Ved utvikling av en datamodell kan to tilnærminger benyttes. I den første tilnærmingen først bestemmes hovedoppgavene, for løsningen som basen er bygget av, behovene til oppgavene i data identifiseres og følgelig bestemmes sammensetningen og strukturen til informasjonsobjekter. Med den andre tilnærmingen de typiske objektene i fagområdet installeres umiddelbart. Den mest rasjonelle kombinasjonen av begge tilnærminger. Dette skyldes det faktum at det i den innledende fasen som regel ikke er omfattende informasjon om alle oppgaver. Bruken av denne teknologien er desto mer berettiget fordi fleksible midler for å lage relasjonsdatabaser tillater på ethvert utviklingsstadium å gjøre endringer i databasen og endre dens struktur uten at det berører tidligere innlagte data.

Prosessen med å identifisere informasjonsobjekter i fagområdet som oppfyller kravene til normalisering, kan utføres på grunnlag av en intuitiv eller formell tilnærming. Det teoretiske grunnlaget for den formelle tilnærmingen ble utviklet og fullstendig beskrevet i monografiene om organisering av databaser av den berømte amerikanske vitenskapsmannen J. Martin.

Med en intuitiv tilnærming kan informasjonsobjekter som tilsvarer virkelige objekter lett identifiseres. Imidlertid krever den resulterende informasjonslogiske modellen som regel ytterligere transformasjoner, spesielt transformasjonen av multiverdiforbindelser mellom objekter. Med denne tilnærmingen er betydelige feil mulig hvis det ikke er nok erfaring. Etterfølgende verifisering av oppfyllelsen av normaliseringskravene indikerer vanligvis behovet for å avgrense informasjonsobjektene.

Tenk på de formelle reglene som kan brukes til å fremheve informasjonsobjekter:

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

Bestem funksjonelle avhengigheter mellom attributter;

Velg alle avhengige attributter og spesifiser for hver alle nøkkelattributtene, det vil si de som det avhenger av;

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

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

I prosessen med opprettelsen konstrueres først databasetabellene som tilsvarer informasjonsobjektene til den konstruerte datamodellen. Videre kan et dataskjema opprettes, der de eksisterende logiske relasjonene mellom tabellene er fikset. Disse lenkene tilsvarer lenkene til informasjonsobjekter. Dataskjemaet kan konfigureres til å opprettholde integriteten til databasen hvis datamodellen er designet for å møte normaliseringskrav. Dataintegritet betyr at databasen har etablert og korrekt vedlikeholdt relasjoner mellom poster i forskjellige tabeller ved lasting, tillegging og sletting av poster i relaterte tabeller, samt ved endring av verdier til nøkkelfelt.

Etter dannelsen av dataskjemaet utføres inndata av konsistente data fra dokumentene til fagområdet.

Basert på den opprettede databasen, nødvendige henvendelser, skjemaer, makroer, moduler, rapporter som utfører den nødvendige behandlingen av databasedata og deres presentasjon.

Innebygde verktøy og databaseverktøy brukes til å lage brukergrensesnitt, som lar deg administrere prosessene med å legge inn, lagre, behandle, oppdatere og presentere databaseinformasjon.

Designe en database basert på en objektrelasjonsmodell

Det er hele linjen metoder for å lage informasjon og logiske modeller. En av de mest populære modelleringsteknikkene bruker ERD (Entity-Relationship Diagrams). I den russiskspråklige litteraturen kalles disse diagrammene "objekt - forhold" eller "enhet - forhold". ERD-modellen ble foreslått av Peter Ping Sheng Chen i 1976. Til dags dato er det utviklet flere varianter, men alle er basert på grafiske diagrammer foreslått av Chen. Diagrammer er laget av et lite antall komponenter. På grunn av deres tydelige presentasjon, er de mye brukt i CASE-verktøy (Computer Aided Software Engineering).

Vurder terminologien og notasjonen som brukes.

Entitet- en reell eller imaginær gjenstand som er vesentlig for det betraktede fagområdet, informasjon om hvilken skal lagres.

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

Hver enhet må ha noen egenskaper:

Ha unikt navn; dessuten må den samme tolkningen (definisjonen av enheten) alltid brukes på dette navnet. Omvendt kan den samme tolkningen ikke brukes på forskjellige navn, med mindre de er aliaser;

Ha en eller flere attributter som enten tilhører en enhet eller som er arvet av den gjennom et forhold;

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

En enhet kan 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 relasjoner med andre enheter i modellen.

Forhold- en navngitt assosiasjon mellom to enheter som er viktig for domenet som vurderes. En av enhetene som deltar i forholdet er uavhengig, kalt overordnet enhet, den andre er avhengig, kalt barnet eller etterkommerentitet. Som regel er hver forekomst av den overordnede enheten assosiert med et vilkårlig (inkludert null) antall forekomster av den underordnede enheten. Hver forekomst av en etterkommer-enhet er knyttet til nøyaktig én forekomst av en overordnet enhet. Dermed kan en forekomst av en etterkommer-enhet bare eksistere hvis den overordnede enheten eksisterer.

Koblingen får et navn uttrykt ved den grammatiske vendingen av verbet og plasseres nær lenken.

Navnet på hvert forhold mellom disse to enhetene må være unikt, men relasjonsnavnene i modellen trenger ikke å være unike. Hver binding har en definisjon. Definisjonen av et forhold dannes ved å kombinere navnet på den overordnede enheten, navnet på forholdet, uttrykket for graden av forholdet og navnet på den etterkommere enheten.

For eksempel kan en selgers forhold til en kontrakt defineres som følger:

Selger kan motta godtgjørelse for en eller flere kontrakter;

Kontrakten må initieres av nøyaktig én selger.

I diagrammet er forbindelsen representert av et linjestykke (stiplet linje). Endene av segmentet ved hjelp av spesielle betegnelser (fig. 2) indikerer graden av forbindelse. I tillegg indikerer linjens natur - stiplet eller solid, den obligatoriske forbindelsen.

Egenskap- ethvert kjennetegn ved en enhet som er vesentlig for det betraktede fagområdet. Det er ment å kvalifisere, identifisere, klassifisere, kvantifisere eller uttrykke tilstanden til en enhet. Et attributt representerer en type egenskaper (egenskaper) assosiert med et sett av virkelige eller abstrakte objekter (mennesker, steder, hendelser, tilstander, ideer, gjenstandspar osv.) (Fig. 3).

Attributtforekomst Er en spesifikk egenskap ved en spesifikk forekomst av en enhet. En attributtforekomst bestemmes av attributttypen (for eksempel "Farge") og verdien (for eksempel "lilla"), kalt attributtverdien. I ER-modellen er attributter knyttet til spesifikke enheter. Hver forekomst av en enhet må ha én spesifikk verdi for hver av dens attributter.

Attributten kan være enten obligatorisk eller valgfri... Obligatorisk betyr at attributtet ikke kan ha nullverdier. Et attributt kan enten være beskrivende (det vil si en vanlig enhetsbeskrivelse) eller en del av en 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 enhetstype. Hvis den er fullstendig identifisert, blir en forekomst av en gitt enhetstype fullstendig identifisert av sine egne nøkkelattributter, i ellers attributter til en annen enhet, forelderen, er også involvert i identifikasjon.

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

Hvert attributt identifiseres med en unik substantivfrase som beskriver egenskapen representert av attributtet. Attributter vises som en liste over navn innenfor den tilknyttede enhetsblokken, med hvert attributt på en egen linje. Attributtene som definerer primærnøkkelen er plassert øverst på listen og er merket med et "#"-tegn.

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

For tiden, basert på Chens tilnærming, er IDEF1X-metodikken utviklet, som er utviklet under hensyntagen til slike 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-metodikken kalles uavhengig av identifikatorer, eller ganske enkelt uavhengig, hvis hver forekomst av en enhet kan identifiseres unikt uten å definere dens relasjoner med andre enheter. En enhet kalles identifikatoravhengig eller ganske enkelt avhengig hvis den unike identifiseringen av en enhetsforekomst avhenger av dens forhold til en annen enhet (Figur 5).

Hver enhet er tildelt et unikt navn og nummer, atskilt med en skråstrek "/" og plassert over blokken.

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

Det identifiserende forholdet mellom den overordnede enheten og den etterkommer enheten vises med en heltrukket linje. I fig. 5: # 2 er en avhengig enhet, Link 1 er et identifiserende forhold. En etterkommer-enhet i et identifiserende forhold er en identifikatoravhengig enhet. En overordnet enhet i et identifiserende forhold kan enten være en uavhengig eller en identifikatoravhengig enhet (dette bestemmes av dens relasjoner med andre enheter).

Den stiplede linjen representerer et ikke-identifiserende forhold. I fig. 5: # 4 er en uavhengig enhet, Link 2 er et ikke-identifiserende forhold. En etterkommer-enhet i et ikke-identifiserende forhold vil være uavhengig av identifikatoren hvis den ikke også er en etterkommer-enhet i et identifiserende forhold.

Forholdet kan defineres ytterligere ved å spesifisere graden eller kardinaliteten (antall forekomster av den etterkommere enheten som kan eksistere for hver forekomst av den overordnede enheten).

Følgende kardinaliteter kan uttrykkes i IDEF1X:

Hver overordnede enhetsforekomst kan ha null, én eller flere etterkommerentitetsforekomster knyttet til seg;

Hver overordnede enhetsforekomst må ha minst én tilknyttet etterkommerenhetsforekomst;

Hver overordnede enhetsforekomst må ha maksimalt én tilknyttet etterkommerenhetsforekomst;

Hver overordnede enhetsforekomst er knyttet til et bestemt antall etterkommere enhetsforekomster.

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

Attributter vises som en liste over navn inne i enhetsblokken. Attributtene som definerer primærnøkkelen er plassert øverst på listen og atskilt fra andre attributter med en horisontal strek (Figur 7).

Som et resultat oppnås 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, støtte for en enhetlig og konsistent arbeidsstil.

Enheter kan også ha utenlandsk nøkkel. Med en identifiserende relasjon brukes de som en del eller en hel primærnøkkel, med en ikke-identifiserende relasjon tjener de som ikke-nøkkelattributter. I listen over attributter er fremmednøkkelen merket med bokstavene FK i parentes.

Prosessen med å designe en database er en sekvens av overganger fra en uformell verbal beskrivelse av informasjonsstrukturen til fagområdet til en formalisert beskrivelse av programvareobjekter i form av en bestemt modell. Generelt kan følgende designstadier skilles:

JEG. Systemanalyse og verbal beskrivelse av programvareinformasjonsobjekter... Det er to tilnærminger til å velge sammensetning og struktur for fagområdet:

· Funksjonell tilnærming. Den implementerer prinsippet om bevegelse "fra oppgaver" og brukes når funksjonene til en viss gruppe personer og komplekser av oppgaver er kjent, for å betjene informasjonsbehovene som en database er opprettet av. I dette tilfellet kan du tydelig fremheve det nødvendige minimalt sett objekter som skal beskrives.

· Fagtilnærming. Informasjonsbehovene til fremtidige brukere er ikke stivt fastsatt. Det er umulig å velge det nødvendige minimumssettet med objekter som må beskrives. I dette tilfellet inkluderer beskrivelsen av programvaren slike objekter og relasjoner som er mest karakteristiske og essensielle for den. Den utformede databasen kalles en emnedatabase og kan brukes til en rekke forskjellige, forhåndsdefinerte oppgaver. Denne tilnærmingen ser ut til å være den mest lovende, men den kan føre til redundans av oppgaven eller brukerbehov, og på den annen side tar den hensyn til muligheten for å øke nye applikasjoner.

II. Utforming av en infologisk programvaremodell. Oppgaven til det infologiske designstadiet: å skaffe semantiske (semantiske) datamodeller (for eksempel når det gjelder ER-modeller)., Vise informasjonsinnholdet til en spesifikk programvare. Først trekkes den nødvendige delen av programvaren ut fra den oppfattede virkeligheten, dens grenser bestemmes, og abstraksjonen fra ubetydelige deler for en spesifikk applikasjon av databasen finner sted. Som et resultat bestemmes objekter, deres egenskaper og relasjoner, noe som vil være avgjørende for fremtidige brukere av systemet.

III. Datalogisk eller logisk databasedesign, dvs. beskrivelse av databasen i form av den aksepterte datalogiske datamodellen (for eksempel relasjonell). Oppgaven til det logiske designstadiet er å organisere dataene som er valgt på forrige trinn i formen som er akseptert i den valgte spesifikke DBMS, ved å bruke dens typer og datamodeller. Det gis anbefalinger om valg av datatilgangsmetoder.

IV. Fysisk utforming av databasen, dvs. valg av effektiv databaseplassering på eksterne medier for å sikre den mest effektive driften av applikasjonen. Oppgaven til det fysiske designstadiet er å velge en rasjonell datalagringsstruktur. og metoder for tilgang til dem, basert på arsenalet av verktøy og metoder som en spesifikk DBMS gir utvikleren.

Når du designer en database, løses to hovedproblemer:

Hvordan kartlegge domeneobjekter til abstrakte datamodellobjekter? Dette problemet kalles det logiske databasedesignproblemet.

Hvordan sikre effektiv utførelse av databasespørringer, dvs. hvordan, med tanke på særegenhetene til et bestemt DBMS, å ordne dataene i eksternt minne, hvilke tilleggsstrukturer (for eksempel indekser) å kreve osv.? Dette problemet kalles det fysiske databasedesignproblemet.

Når det gjelder relasjonsdatabaser, er det vanskelig å gi noen generell oppskrift på fysisk design. Her avhenger for mye av DBMS som brukes. Derfor vil vi begrense oss til spørsmålene om logisk utforming av relasjonsdatabaser, som er essensielle ved bruk av relasjons-DBMS.

Dessuten vil vi ikke berøre et veldig viktig aspekt ved design - å definere integritetsbegrensninger (med unntak av primærnøkkelbegrensningen). Faktum er at når du bruker en DBMS med utviklede mekanismer for integritetsbegrensninger (for eksempel SQL-orienterte systemer), er det vanskelig å foreslå noen generell tilnærming til å definere integritetsbegrensninger. Disse begrensningene kan være veldig generelle, og formuleringen deres tilhører så langt kunstfeltet snarere enn ingeniørfaget. Det meste som er foreslått i litteraturen om denne saken er den automatiske konsistenskontrollen av et sett med integritetsbegrensninger.

hvilke relasjoner skal databasen bestå av og

hvilke egenskaper bør disse relasjonene ha

Det er tre hovedtilnærminger til databasedesign:

1. innsamling av informasjon om objektene for problemet som løses i en tabell og dens påfølgende dekomponering i flere sammenkoblede tabeller basert på normaliseringsprosedyrer ( klassisk metode);

2. overgang fra den semantiske (infologiske) modellen av andre trinn ved bruk av CASE-verktøy til et ferdig databaseskjema eller til og med et ferdig applikasjonsinformasjonssystem (IS);

3. strukturere informasjon til bruk i IS i prosessen med å gjennomføre en systemanalyse basert på et sett med praktiske regler og anbefalinger.

Først vil en klassisk tilnærming bli vurdert, der hele designprosessen utføres i form av relasjonsdatamodellen ved metoden med suksessive tilnærminger til et tilfredsstillende sett med relasjonsskjemaer. Utgangspunktet er representasjonen av programvaren i form av en eller flere relasjoner, og ved hvert designtrinn produseres et visst sett med relasjonsskjemaer med bedre egenskaper. Designprosessen er en prosess for å normalisere relasjonsskjemaer, hvor hver påfølgende normalform har bedre egenskaper enn den forrige.

I teorien om relasjonsdatabaser skilles vanligvis følgende sekvens av normale former:

første normalform (1NF);

andre normalform (2NF);

tredje normalform (3NF);

Boyes-Codd normal form (BCNF)

fjerde normalform (4NF);

femte normalform (5NF eller PJ / NF).

Grunnleggende egenskaper ved normale former:

hver neste normalform er på en eller annen måte bedre enn den forrige;

ved overgang til neste normalform beholdes egenskapene til de forrige normalegenskapene.

Designprosessen er basert på normaliseringsmetoden, dekomponering av en relasjon i forrige normalform til to eller flere relasjoner som tilfredsstiller kravene til den neste normalformen.

De viktigste normale formene for relasjoner i praksis er basert på et grunnleggende begrep i teorien om relasjonsdatabaser funksjonell avhengighet... For den videre fremstillingen trenger vi flere definisjoner.

Definisjon 1. Funksjonell avhengighet

I forhold til R avhenger Y-attributtet funksjonelt av X-attributtet (X og Y kan være sammensatte) hvis og bare hvis hver X-verdi tilsvarer nøyaktig én Y-verdi: R.X -> R.Y.

Definisjon 2 . Fullstendig funksjonell avhengighet

En funksjonell avhengighet R.X -> R.Y kalles komplett hvis attributtet Y ikke funksjonelt avhenger av noen eksakt delmengde av X.

Definisjon 3. Transitiv funksjonell avhengighet

Den funksjonelle avhengigheten R.X -> R.Y kalles transitiv hvis det er en slik attributt Z at det er funksjonelle avhengigheter R.X -> R.Z og R.Z -> R.Y og det er ingen funksjonell avhengighet R.Z - / -> R.X.

Definisjon 4. Ikke-nøkkelattributt

Et ikke-nøkkelattributt er ethvert attributt til et forhold som ikke er en del av primærnøkkelen (spesielt primærnøkkelen).

Definisjon 5 . Gjensidig uavhengige attributter

To eller flere attributter er gjensidig uavhengige hvis ingen av disse attributtene er funksjonelt avhengige av de andre.

For så vidt det første normalformkravet er et grunnleggende krav til den klassiske relasjonsmodellen data, vil vi anta at det innledende settet med relasjoner allerede oppfyller dette kravet, dvs. alle attributter er atomære. Hvis tabellen inneholder sammensatte attributter, kan du redusere den til 1NF ved å bruke normaliseringsalgoritme foreslått av E. Codd:

fra den opprinnelige tabellen, blir dens primærnøkkel tatt og lagt til hver underordnet tabell (sammensatt attributt);

primærnøkkelen til hver utvidet tabell består av primærnøkkelen til den underordnede tabellen og den ekstra overordnede primærnøkkelen;

etter det blir alle vanskelige attributter slettet fra den overordnede tabellen, og denne prosedyren gjentas for hver av de underordnede tabellene;

betingelsen for slutten av algoritmen er atomiteten til alle attributter.

Eksempel 5.1 Betrakt som et fagområde en bestemt organisasjon som utfører noen prosjekter. Vi beskriver domenemodellen med følgende uformelle tekst:

De ansatte i organisasjonen gjennomfører prosjekter.

Prosjekter består av flere oppgaver.

Hver ansatt kan delta i ett eller flere prosjekter, eller midlertidig ikke delta i noen prosjekter.

Flere ansatte kan jobbe med hvert prosjekt, eller prosjektet kan bli midlertidig suspendert, da er det ingen ansatte som jobber med det.

Nøyaktig én ansatt jobber med hver oppgave i prosjektet.

Hver ansatt er oppført i én avdeling.

Hver ansatt har et telefonnummer plassert i den ansattes avdeling.

I løpet av ytterligere avklaring av hvilke data som bør tas i betraktning, ble følgende klart:

Det skal lagres et personalnummer om hver ansatt. Personalnummeret er unikt for hver ansatt.

Hver avdeling har unikt nummer.

Hvert prosjekt har et nummer. Prosjektnummeret er unikt.

Hver oppgave fra prosjektet har et nummer som er unikt innenfor prosjektet.

La oss forestille oss et relasjonsdiagram (all informasjon i én tabell):

ANSATTE-AVDELINGER-PROSJEKTER

(SOTR_NUMBER, SOTR_ZARP, DT_NUMBER, PRO_NUMBER, SOTR_SET)

Primærnøkkel:

SOTR_NUMBER, PRO_NUMBER

Funksjonelle avhengigheter:

SOTR_NUMBER -> SOTR_ZARP

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

COPY_NUMBER, PRO_NUMBER -> COPY_SET

Som du kan se, selv om primærnøkkelen er det sammensatte attributtet SOTR_NUMBER, PRO_NUMBER, avhenger attributtene SOTR_ZARP og DTD_NUMBER funksjonelt av delen av primærnøkkelen, SOTR_NUMBER-attributtet. Som et resultat vil vi ikke kunne sette inn i relasjonen ANSATTE-AVDELINGER-PROSJEKTER en tuppel som beskriver en ansatt som ennå ikke utfører noe prosjekt (primærnøkkelen kan ikke inneholde en udefinert verdi). Når du sletter en tuppel, ødelegger vi ikke bare forbindelsen til denne ansatte med dette prosjektet, men mister også informasjonen om at han jobber i en bestemt avdeling. Ved overføring av en ansatt til en annen avdeling, vil vi bli tvunget til å endre alle tuplene som beskriver denne ansatte, ellers vil vi få et inkonsekvent resultat. Slike ubehagelige fenomener kalles anomalier relasjonsordninger. De elimineres ved normalisering.

Definisjon 6 . Andre normalform(denne definisjonen forutsetter at den eneste nøkkelen til forholdet er primærnøkkelen)

En relasjon R er i andre normalform (2NF) hvis og bare hvis den er i 1NF, og hvert ikke-nøkkelattributt er helt avhengig av primærnøkkelen.

Du kan gjøre følgende dekomponering av ANSATTE-AVDELINGER-PROSJEKTER-relasjonen i to ANSATTE-AVDELINGER og ANSATTE-PROSJEKTER-relasjoner:

AVDELINGSANSATTE (SOTR_NUMBER, SOTR_ZARP, DEPARTMENT_NUMBER)

Primærnøkkel:

SOTR_NUMBER

Funksjonelle avhengigheter:

SOTR_NUMBER -> SOTR_ZARP

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

Primærnøkkel:

SOTR_NUMBER, PRO_NUMBER

Funksjonelle avhengigheter:

COP_NUMBER, PRO_NUMBER -> COPY_DEFINED

Hver av disse to relasjonene er i 2NF, og uregelmessighetene nevnt ovenfor er eliminert (det er enkelt å verifisere at alle de angitte operasjonene utføres uten problemer).

Vurder igjen forholdet ANSATTE-AVDELING i 2NF. Merk at den funksjonelle avhengigheten SOTR_NUMBER -> SOTR_ZARP er transitiv; det er en konsekvens av de funksjonelle avhengighetene SOTR_NUMBER -> DT_NUMBER og DT_NUMBER -> SOTR_ZARP. Med andre ord, lønnen til en ansatt er faktisk ikke en egenskap for den ansatte, men for avdelingen han jobber i (dette er ikke en veldig naturlig antagelse, men tilstrekkelig for et eksempel).

Som et resultat vil vi ikke kunne legge inn informasjon som karakteriserer lønnen til en avdeling i databasen før minst én ansatt dukker opp i denne avdelingen (primærnøkkelen kan ikke inneholde en udefinert verdi). Hvis vi sletter tuppelen som beskriver den siste ansatte ved denne avdelingen, mister vi informasjon om lønnen til avdelingen. For å endre lønnen til en avdeling på en konsistent måte, må vi først finne alle tuppene som beskriver de ansatte ved denne avdelingen. De. det er fortsatt uregelmessigheter i ANSATTEAVDELINGEN. De kan elimineres ved ytterligere normalisering.

Definisjon 7. Tredje normalform(Definisjonen er gitt under antagelsen om at en enkelt nøkkel eksisterer.)

En relasjon R er i tredje normalform (3NF) hvis og bare hvis den er i 2NF og hvert ikke-nøkkelattributt ikke transitivt avhenger av primærnøkkelen.

Du kan dekomponere ANSATTE-AVDELINGER-forholdet i to ANSATTE- og AVDELINGS-forhold:

ANSATTE (COPY_NUMBER, DEPARTMENT_NUMBER)

Primærnøkkel:

SOTR_NUMBER

Funksjonelle avhengigheter:

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENTS (DEPARTMENT_NUMBER, SOTR_ZARP)

Primærnøkkel:

DET_NUMBER

Funksjonelle avhengigheter:

DEPARTMENT_NUMBER -> SOTR_ZARP

Hver av disse to forholdene er på 3NF og fri for markerte anomalier.

Hvis vi forlater begrensningen om at en relasjon har en enkelt nøkkel, tar definisjonen av 3NF følgende form:

Definisjon 7 *

En relasjon R er i tredje normalform (3NF) hvis og bare hvis den er i 2NF, og hvert ikke-nøkkelattributt er ikke transitivt avhengig av noen nøkkel R.

I praksis er den tredje normalformen for relasjonsskjemaer tilstrekkelig i de fleste tilfeller, og prosessen med å utforme en relasjonsdatabase ender vanligvis opp med å konvertere til den tredje normalformen..

Noen ganger er det imidlertid nyttig å fortsette med normaliseringsprosessen.

Eksempel 5.2 Tenk på følgende eksempel på et relasjonsdiagram:

ANSATTE-PROSJEKTER (SOTR_NUMBER, SOLD_NAME, PRO_NUMBER, SOTR_PASED)

Mulige nøkler:

SOTR_NUMBER, PRO_NUMBER

SOLD_NAME, PRO_NUMBER

Funksjonelle avhengigheter:

COP_NUMBER -> COP_NAME

SOTR_NUMBER -> PRO_NUMBER

COPY_NAME -> COPY_NUMBER

SOLD_NAME -> PRO_NUMBER

COP_NUMBER, PRO_NUMBER -> COPY_DEFINED

COPY_NAME, PRO_NUMBER -> COPY_SET

I dette eksemplet antar vi at identiteten til den ansatte er fullstendig bestemt av både nummeret og navnet hans (dette er igjen ikke en veldig viktig antagelse, men tilstrekkelig for et eksempel).

I henhold til definisjonen av 7 * er ANSATTE-PROSJEKTER forholdet i 3NF. Det faktum at det er funksjonelle avhengigheter av relasjonsattributter på et attributt som er en del av primærnøkkelen, fører imidlertid til anomalier. For eksempel, for å endre navnet på en ansatt med et gitt nummer på en konsistent måte, må vi endre alle tupler som inkluderer nummeret hans.

Definisjon 8. Avgjørende faktor

En determinant er ethvert attributt som et annet attributt avhenger av fullt funksjonelt.

Definisjon 9 . Boyes-Codd normal form

R-relasjonen er i Boyes-Codd Normal Form (BCNF) hvis og bare hvis hver determinant er en mulig nøkkel.

Dette kravet er åpenbart ikke oppfylt for forholdet ANSATTE-PROSJEKTER. Du kan dekomponere det til relasjonene ANSATTE og ANSATTE-PROSJEKTER:

ANSATTE (COPY_NUMBER, COPY_NAME)

Mulige nøkler:

SOTR_NUMBER

Funksjonelle avhengigheter:

COP_NUMBER -> COP_NAME

COPY_NAME -> COPY_NUMBER

ANSATTE-PROSJEKTER (SOTR_NUMBER, PRO_NUMBER, SOTR_SIGNED)

Mulig nøkkel:

SOTR_NUMBER, PRO_NUMBER

Funksjonelle avhengigheter:

COP_NUMBER, PRO_NUMBER -> COPY_DEFINED

En alternativ dekomponering er mulig hvis du velger SOTR_NAME som grunnlag. I begge tilfeller er de resulterende ANSATTE- og PROSJEKTANSATTE-relasjonene i BCNF og viser ikke de bemerkede anomaliene.

Eksempel 5.3 Tenk på et eksempel på følgende relasjonsdiagram:

PROSJEKTER (PRO_NUMBER, PRO_SOTR, PRO_ZADAN)

PROSJEKTER-relasjonen inneholder prosjektnummer, for hvert prosjekt en liste over ansatte som kan gjennomføre prosjektet, og en liste over oppgaver som prosjektet ser for seg. Ansatte kan delta i flere prosjekter, og ulike prosjekter kan inneholde de samme oppgavene.

Hver tuppel av et forhold forbinder et prosjekt med en ansatt som deltar i dette prosjektet og oppgaven som den ansatte utfører innenfor rammen av dette prosjektet (vi antar at enhver ansatt som deltar i prosjektet utfører alle oppgavene som er fastsatt av dette prosjektet). På grunn av betingelsene formulert ovenfor, er den eneste mulige relasjonsnøkkelen den sammensatte attributten PRO_NUMBER, PRO_SOTP, PRO_DASED, og ​​det er ingen andre determinanter. Derfor er forholdet PROSJEKTER i BCNF. Men samtidig har det ulemper: Hvis for eksempel en bestemt ansatt blir med i dette prosjektet, er det nødvendig å sette inn så mange tupler i PROSJEKTER-relasjonen som det er oppgaver i den.

Definisjon 10 . Flerverdier avhengigheter

I forhold til R (A, B, C), er det en flerverdiavhengig avhengighet RA -> -> RB hvis og bare hvis settet med verdier av B som tilsvarer et verdipar av A og C bare avhenger av A og er ikke avhengig av C.

Når det gjelder PROSJEKTER, er det følgende to tvetydige avhengigheter:

PRO_NUMBER -> -> PRO_SOTR

PRO_NUMBER -> -> PRO_SPECIFIED

Det er lett å vise at i det generelle tilfellet i forhold til R (A, B, C) er det en flerverdi avhengighet R.A -> -> R.B hvis og bare hvis det er en flerverdi avhengighet R.A -> -> R.C.

Ytterligere normalisering av relasjoner som ligner på relasjonen PROSJEKTER er basert på følgende teorem:

Fagins teorem

Forhold R (A, B, C) kan projiseres tapsfritt inn i forhold R1 (A, B) og R2 (A, C) hvis og bare hvis det er MVD A -> -> B | C.

Tapsfri projeksjon forstås som en slik metode for dekomponering av en relasjon, der den opprinnelige relasjonen er fullstendig og uten redundans gjenopprettet av en naturlig kombinasjon av de oppnådde relasjonene.

Definisjon 11 . Fjerde normalform

En relasjon R er i fjerde normalform (4NF) hvis og bare hvis, i tilfelle av en flerverdiavhengig avhengighet A -> -> B, alle andre attributter til R funksjonelt avhenger av A.

I vårt eksempel kan vi dekomponere relasjonen PROSJEKTER i to relasjoner PROSJEKTER-ANSATTE og PROSJEKTER-OPPGAVER:

PROSJEKTER-ANSATTE (PRO_NUMBER, PRO_SOTR)

PROSJEKTER-OPPGAVER (PRO_NUMBER, PRO_ZONE)

Begge disse forholdene er i 4NF og er fri for bemerkede anomalier.

I alle normaliseringer vurdert frem til dette punktet, ble en relasjon dekomponert i to. Noen ganger kan dette ikke gjøres, men dekomponering til mer relasjoner, som hver har de beste egenskapene.

Eksempel 5.4 Tenk for eksempel på forholdet

ANSATTE-DEPARTMENTS-PROSJEKTER (COP_NUMBER, DEPARTMENT_NUMBER, PRO_NUMBER)

Anta at samme ansatt kan jobbe i flere avdelinger og jobbe i hver avdeling med flere prosjekter. Den primære nøkkelen til dette forholdet er det komplette settet med dets attributter; det er ingen funksjonelle og flerverdige avhengigheter.

Derfor er forholdet på 4NF. Imidlertid kan det eksistere anomalier i den, som kan elimineres ved nedbrytning i tre forhold.

Definisjon 12. Tilkoblingsavhengighet

Relasjonen R (X, Y, ..., Z) tilfredsstiller forbindelsesavhengigheten * (X, Y, ..., Z) hvis og bare hvis R gjenopprettes uten tap ved å koble projeksjonene til X, Y, .. ., Z.

Definisjon 13 . Femte normalform

En relasjon R er i femte normalform (projeksjonssammenføyning normalform - PJ / NF) hvis og bare hvis noen sammenføyningsavhengighet i R følger av eksistensen av en mulig nøkkel i R.

La oss introdusere følgende navn på sammensatte attributter:

CO = (COP_NUMBER, DEP_NUMBER)

SP = (SOTR_NUMBER, PRO_NUMBER)

OP = (DT_NUMBER, PRO_NUMBER)

Anta at det er en forbindelsesavhengighet i forhold til ANSATTE-AVDELINGER-PROSJEKTER:

* (CO, SP, OP)

Det er enkelt å vise med eksempler at det kan oppstå problemer ved innsetting og sletting av tupler. De kan elimineres ved å dekomponere det opprinnelige forholdet til tre nye forhold:

AVDELINGSANSATTE (COPY_NUMBER, DEPARTMENT_NUMBER)

ANSATTE-PROSJEKTER (SOTR_NUMBER, PRO_NUMBER)

DEPARTMENTS-PROJECTS (DEPARTMENT_NUMBER, PRO_NUMBER)

Den femte normalformen er den siste normalformen som kan oppnås ved nedbrytning. Forholdene er ganske utrivielle, og i praksis brukes ikke 5NF. Legg merke til at tilknytningsavhengigheten er en generalisering av både flerverdig avhengighet og funksjonell avhengighet.

Kommentar ... Hvis forholdet ikke er normalisert, oppstår det problemer. redundans, potensiell inkonsistens (oppdateringsavvik), inklusjonsavvik, slettingsavvik.

Ved å følge prinsippene beskrevet i denne artikkelen kan du lage en database som fungerer som forventet og kan tilpasses for å møte nye krav i fremtiden. Vi vil dekke de grunnleggende prinsippene database design, samt måter å optimalisere den på.

Databasedesignprosess

Ordentlig strukturert base data:

• Hjelper å spare diskplass ved å ekskludere unødvendige data;
• Opprettholder datanøyaktighet og integritet;
• Gir enkel tilgang til data.

Databaseutvikling inkluderer følgende stadier:

1. Analysere kravene eller definere formålet med databasen;
2. Organisering av data i tabeller;
3. Angivelse av primærnøkler og analyse av sammenhenger;
4. Normalisering av tabeller.

Vurder hver databasedesignfasen i mer detalj. Merk at denne opplæringen fokuserer på Edgar Codds relasjonsdatabasemodell, skrevet i SQL-språk (ikke hierarkisk, nettverks- eller objektmodell).

Kravanalyse: Definere formålet med databasen

Hvis du for eksempel oppretter en database for et offentlig bibliotek, må du vurdere hvordan både lesere og bibliotekarer skal få tilgang til databasen.

Det er flere måter å samle informasjon på før du oppretter en database:

• Intervjue folk som vil bruke det;
• Analyse av forretningsformer som fakturaer, tidsplaner, undersøkelser;
• Hensyn til alle eksisterende systemer data ( inkludert fysiske og digitale filer).

Start med å samle eksisterende data som skal inkluderes i databasen. Definer deretter hvilke typer data du vil lagre. Samt objekter som beskriver disse dataene. For eksempel:

Kunder

• Adresse;
• By (*): Stat (*): Postnummer;
• Epostadresse.

Varer

• Navn;
• Pris;
• Antall på lager;
• Antall på bestilling.

Ordrene

• Ordrenummer;
• Salgsrepresentant;
• Dato;
• Produkt;
• Mengde;
• Pris;
• Pris.

Ved utforming av en relasjonsdatabase vil denne informasjonen senere bli en del av dataordboken, som beskriver databasetabellene og -feltene. Bryt informasjonen ned i de minste mulige biter. Vurder for eksempel å skille postadresse- og tilstandsfeltet slik at du kan filtrere folk etter staten de bor i.

Når du har bestemt deg for hvilke data som skal inkluderes i databasen, hvor disse dataene skal komme fra, og hvordan de skal brukes, kan du begynne å planlegge selve databasen.

Databasestruktur: byggeklosser

Det neste trinnet er å visualisere databasen. For å gjøre dette må du vite nøyaktig hvordan relasjonsdatabaser er strukturert. Innenfor databasen er relaterte data gruppert i tabeller, som hver består av rader og kolonner.

For å konvertere lister med data til tabeller, start med å lage en tabell for hver type objekt, for eksempel produkter, salg, kunder og bestillinger. Her er et eksempel:

Hver rad i tabellen kalles en post. Registreringer inkluderer informasjon om noe eller noen, for eksempel en spesifikk kunde. Kolonner (også kalt felt eller attributter) inneholder informasjon av samme type som vises for hver post, for eksempel adressene til alle klientene som er oppført i tabellen.

For å sikre konsistens på tvers av poster når du designer databasemodellen, tilordne en passende datatype til hver kolonne. TIL vanlige typer data inkluderer:

• CHAR - spesifikk lengde på teksten;
• VARCHAR - tekst av forskjellige lengder;
• TEKST - stor mengde tekst;
• INT - positivt eller negativt heltall;
• FLYT, DOBBEL - flytende kommatall;
• BLOB er binære data.

Noen DBMS-er tilbyr også datatypen Autonummer, som automatisk genererer et unikt nummer på hver rad.

V visuell presentasjon DB hver tabell vil bli representert av en blokk i diagrammet. Overskriften til hver blokk skal indikere hva dataene i denne tabellen beskriver, og attributtene skal være oppført nedenfor:

På design av informasjonsdatabase det er nødvendig å bestemme hvilke attributter som skal fungere som primærnøkkel for hver tabell, hvis noen. Primærnøkkel ( PK) Er en unik identifikator for av dette objektet... Med den kan du velge dataene til en spesifikk kunde, selv om du bare kjenner denne verdien.

Attributter valgt som primærnøkler må være unike, uforanderlige og kan ikke være NULL ( de kan ikke være tomme). Av denne grunn er bestillingsnumre og brukernavn passende primærnøkler, men telefonnumre eller adresser er det ikke. Du kan også bruke flere felt samtidig som en primærnøkkel ( dette kalles en sammensatt nøkkel).

Når det er på tide å lage den faktiske DB, implementerer du både den logiske og den fysiske strukturen gjennom datadefinisjonsspråket som støttes av DBMS.

Det er også nødvendig å estimere størrelsen på databasen for å sikre at det nødvendige ytelsesnivået kan oppnås og at du har tilstrekkelig lagringsplass.

Skape relasjoner mellom enheter

Nå som dataene er konvertert til tabeller, må vi analysere relasjonene mellom dem. Kompleksiteten til en database bestemmes av antall elementer som samhandler mellom to koblede tabeller... Å bestemme kompleksitet bidrar til å sikre at du deler inn dataene dine i tabeller på den mest effektive måten.

Hvert objekt kan kobles sammen med et annet ved hjelp av en av tre typer lenker:

En-til-en kommunikasjon

Når det bare er én forekomst av objekt A for hver forekomst av objekt B, sies de å ha en en-til-en-relasjon ( ofte betegnet 1:1). Du kan indikere denne typen forhold i ER-diagrammet med en linje med en strek i hver ende:

Når du designer og utvikler databasene dine, hvis du ikke har noen grunn til å dele disse dataene, indikerer et 1:1-forhold vanligvis at det er bedre å kombinere disse tabellene til én.

Men under visse omstendigheter er det mer hensiktsmessig å lage tabeller med 1:1-relasjoner. Hvis det er et felt med valgfrie data, for eksempel "beskrivelse", som ikke er fylt ut for mange poster, kan du flytte alle beskrivelser til en egen tabell, unntatt tomme felt og forbedre databaseytelsen.

For å sikre at dataene korrelerer riktig, må du inkludere i det minste, én identisk kolonne i hver tabell. Dette vil mest sannsynlig være hovednøkkelen.

En-til-mange forhold

Disse relasjonene oppstår når en post i en tabell er koblet til flere poster i en annen. For eksempel kan én klient legge inn mange bestillinger, eller leseren kan ha flere bøker hentet fra biblioteket samtidig. En-til-mange (1:M)-forhold er merket med det såkalte kråkefotmerket, som i dette eksemplet:

For å implementere et 1:M-forhold, legg til primærnøkkelen fra "én" tabell som et attributt til en annen tabell. Når en primærnøkkel er spesifisert i en annen tabell på denne måten, kalles den en fremmednøkkel. Tabellen på "1"-siden av relasjonen er den overordnede tabellen for den underordnede tabellen på den andre siden.

Mange-til-mange forhold

Når flere tabellobjekter kan kobles til flere andre objekter. De sier de har et bånd " mange-til-mange» ( M: N). For eksempel, når det gjelder studenter og kurs, kan en student delta på mange kurs og hvert kurs kan delta av mange studenter.

I ER-diagrammet vises disse relasjonene ved hjelp av følgende linjer:

Når du designer en databasestruktur, er det umulig å implementere denne typen relasjoner. I stedet må du dele dem inn i to en-til-mange-forhold.

For å gjøre dette, må du opprette en ny enhet mellom disse to tabellene. Hvis det er en M:N-relasjon mellom salg og produkter, kan du kalle dette nytt objekt « solgte_produkter"Som den vil inneholde data for hvert salg. Både salgstabellen og produkttabellen vil ha en 1:M-relasjon med solgte_produkter. Denne typen mellomobjekt i ulike modeller kalt en lenketabell, assosiativt objekt eller koblingstabell.

Hver post i relasjonstabellen vil tilsvare to enheter fra tilstøtende tabeller. En tabell med koblinger mellom studenter og kurs kan for eksempel se slik ut:

Er det obligatorisk eller ikke?

En annen måte å analysere relasjoner på er å vurdere hvilken side av et forhold som må eksistere for at den andre skal eksistere. Den valgfrie siden kan merkes med en sirkel på linjen. For eksempel må et land eksistere for å ha en representant i FN, og ikke omvendt:

To objekter kan være avhengige av hverandre ( det ene kan ikke eksistere uten det andre).

Rekursive lenker

Noen ganger, når du designer en database, refererer en tabell til seg selv. For eksempel kan en ansatttabell ha et lederattributt som refererer til en annen person i samme tabell. Dette kalles rekursiv kobling.

Ekstra tilkoblinger

Overflødige forbindelser er de som kommer til uttrykk mer enn én gang. Som regel er det mulig å fjerne en av disse lenkene uten å miste noen viktig informasjon... For eksempel, hvis objektet "elever" har en direkte relasjon til et annet objekt kalt "lærere", men også har et indirekte forhold til lærere gjennom "elementer", må du fjerne koblingen mellom "elever" og "lærere". Fordi den eneste måten som elever er tildelt lærere er fag.

Databasenormalisering

Etter foreløpig utforming av databasen kan normaliseringsregler brukes for å sikre at tabellene er riktig strukturert.

Samtidig trenger ikke alle databaser normaliseres. Generelt, databaser med sanntids transaksjonsbehandling ( OLTP) bør normaliseres.

Databaser med interaktive analytisk bearbeiding (OLAP), som gjør dataanalyse enklere og raskere, kan være mer effektiv med en viss grad av denormalisering. Hovedkriteriet her er hastigheten på beregningene. Hver form eller nivå av normalisering inkluderer regler knyttet til de lavere formene.

Den første formen for normalisering

Den første formen for normalisering ( forkortet 1NF) sier at under logisk databasedesign hver celle i en tabell kan bare ha én verdi, ikke en liste med verdier. Derfor samsvarer ikke en tabell som den nedenfor 1NF:

Du kan bli fristet til å omgå denne begrensningen ved å dele opp dataene i flere kolonner. Men dette er også mot reglene: en tabell med grupper av repeterende eller tett relaterte attributter samsvarer ikke med den første formen for normalisering. Tabellen nedenfor samsvarer for eksempel ikke med 1NF:

I stedet, under den fysiske utformingen av databasen, deler du dataene inn i flere tabeller eller poster til hver celle inneholder bare én verdi og det ikke er flere kolonner. Slike data anses å være oppdelt til det minste nyttig størrelse... I tabellen ovenfor kan du opprette ekstra bord « Salgsdetaljer», Som vil tilsvare spesifikke produkter med salg. "Salg" vil ha et 1:M-forhold med " Salgsdetaljer».

Andre form for normalisering

Den andre formen for normalisering ( 2NF) fastsetter at hver av attributtene må avhenge helt av primærnøkkelen. Hvert attributt må være direkte avhengig av hele primærnøkkelen, og ikke indirekte gjennom et annet attributt.

For eksempel avhenger attributtet "alder" av "bursdag", som igjen avhenger av "student-ID", har en delvis funksjonell avhengighet... Tabellen som inneholder disse attributtene vil ikke samsvare med det andre normaliseringsskjemaet.

I tillegg bryter en tabell med en primærnøkkel som består av flere felt den andre formen for normalisering dersom ett eller flere felt ikke er avhengig av hver del av nøkkelen.

Dermed vil en tabell med disse feltene ikke samsvare med det andre normaliseringsskjemaet, siden "produktnavn"-attributtet avhenger av produkt-ID, men ikke av ordrenummeret:

• Ordrenummer (primærnøkkel);
• Produkt-ID (primærnøkkel);
• Produktnavn.

Den tredje formen for normalisering

Den tredje formen for normalisering ( 3NF) : hver ikke-nøkkelkolonne må være uavhengig av enhver annen kolonne. Hvis kl relasjonsdatabasedesign en endring i en verdi i en ikke-nøkkelkolonne forårsaker en endring i en annen verdi, denne tabellen tilsvarer ikke den tredje formen for normalisering.

I følge 3NF kan du ikke lagre noen avledede data i tabellen, som for eksempel Skattekolonnen, som i eksemplet nedenfor direkte avhenger av totalkostnad rekkefølge:

På et tidspunkt ble tilbudt tilleggsskjemaer normalisering. Inkludert Boyce-Codd-formen for normalisering, den fjerde til sjette formen og domenenøkkelnormalisering, men de tre første er de vanligste.

Flerdimensjonale data

Noen brukere kan trenge tilgang til flere visninger av samme datatype, spesielt i databaser OLAP-data... For eksempel vil de kanskje vite salg etter kunde, land og måned. I denne situasjonen er det best å lage en sentral tabell som kan refereres av kunde-, land- og månedstabeller. For eksempel:

Regler for dataintegritet

Bruker også verktøy for databasedesign det er nødvendig å konfigurere databasen under hensyntagen til muligheten for å kontrollere dataene for samsvar med visse regler. Mange DBMS-er, for eksempel Microsoft Access, håndhever automatisk noen av disse reglene.

Integritetsregelen sier at primærnøkkelen aldri kan være NULL. Hvis nøkkelen har flere kolonner, kan ingen av dem være NULL. Ellers kan den identifisere posten tvetydig.

Linkintegritetsregelen krever at hver fremmednøkkel som er oppført i én tabell, tilordnes én primærnøkkel i tabellen den refererer til. Hvis primærnøkkelen endres eller slettes, må disse endringene implementeres i alle objekter som refereres til av denne nøkkelen i databasen.

Fosikrer at data samsvarer med visse logiske parametere. For eksempel må møtetidene være innenfor standard åpningstid.

Legge til indekser og visninger

En indeks er en sortert kopi av en eller flere kolonner med verdier i stigende eller synkende rekkefølge. Ved å legge til en indeks kan du finne poster raskere. I stedet for å sortere på nytt for hver spørring, kan systemet få tilgang til postene i den rekkefølgen indeksen viser.

Mens indekser fremskynder datainnhenting, kan de senke tilføyelse, oppdatering og sletting av data fordi indeksen må bygges opp igjen hver gang en post endres.

En visning er en lagret forespørsel om data. Visninger kan inkludere data fra flere tabeller, eller vise en del av en tabell.

Utvidede egenskaper

Etter design av databasemodeller Du kan avgrense databasen med avanserte egenskaper som hjelpetekst, inndatamasker og formateringsregler som gjelder for et bestemt skjema, visning eller kolonne. Fordelen med denne metoden er at siden disse reglene er lagret i selve databasen, vil presentasjonen av dataene være konsistent på tvers av de flere programmene som har tilgang til dataene.

SQL og UML

Unified Modeling Language ( UML) Er en annen visuell måte uttrykkene komplekse systemer laget i et objektorientert språk. Noen av konseptene nevnt i denne opplæringen er kjent under forskjellige navn i UML. For eksempel er et objekt i UML kjent som en klasse.

UML brukes ikke så ofte nå. Det brukes akademisk og i kommunikasjon mellom utviklere i disse dager. programvare og deres klienter.

Databasestyringssystemer

Strukturen til den utformede databasen avhenger av hvilket DBMS du bruker. Noen av de vanligste:

• Oracle DB;
• MySQL;
• Microsoft SQL Server
• PostgreSQL;
• IBM DB2.

Et passende databasestyringssystem kan velges basert på kostnad, installert operativsystem, tilgjengelighet ulike funksjoner etc.

Oversettelse av artikkelen " Opplæring i databasestruktur og design»Vennlig prosjektteam

I den første artikkelen i serien "Data i WordPress" ga jeg en oversikt over bruk av relasjonsdatabaser i WordPress: hvilke tabeller som brukes og hvilke data ...

For å beskytte konfidensielle data, introduserte MySQL 5.7 muligheten til å kryptere data ved hjelp av InnoDB-motoren. I denne artikkelen vil jeg forklare prinsippene for databasekryptering, ...