Et universelt fjerntestingssystem for skolebarn og studenter online. Entitetsrelasjonsmodelleringsmetode
Fysisk modell(Tabulære) data inneholder definisjoner av alle implementerte objekter i en bestemt database for en bestemt DBMS.
Modeller er hjørnesteinen i design. Ingeniører må bygge en modell av bilen og finne ut alle detaljene før de settes i produksjon. På samme måte utvikler systemingeniører først modeller for å studere forretningslogikken og utdype forståelsen av databasestrukturen.
I siste forelesning ble vi kjent med metodene IDEF0 og DFD, som lar oss beskrive forretningsprosesser som skjer i et informasjonssystem. I DFD-modellen betraktet vi et element – et datalager, som viser hvilke typer informasjon som systemet opererer på. Denne metodikken er imidlertid ikke ment å beskrive strukturen til lagret informasjon. Ulike Entity Relationship-diagrammer (entity-diagrammer) er mer egnet for dette, hvis formål er å beskrive strukturen til de lagrede dataene og relasjonene mellom dem. Det er utviklet metoder som lar deg konvertere slike data til et sett med kommandoer som vil skape nødvendig lagring (tabeller) i informasjonssystemdatabasen.
ER-modellering
I informasjonssystemer deles data inn i separate kategorier eller essens. Tross alt husker vi at en database er et sett med strukturerte data. Data forskjellige typer lagres separat. Oppgaven til ER-modellen er å vise hvilke typer informasjon som er lagret i systemet, hva deres struktur er og hvordan de henger sammen. ER-modellen er bygget på grunnlag av en forretningsanalyse (konstruert DF-diagram). I dette tilfellet blir i utgangspunktet hver butikk på DF-diagrammet en enhet på ER-diagrammet. Under videre analyse kan de brytes ned i sine komponentdeler. Det er verdt å merke seg at ER-modeller er mer motstandsdyktige mot endringer i forretningsstruktur enn DF-diagrammer. Forretningsprosesser kan endres, men informasjonen som trengs for å implementere dem forblir ofte uendret.
De viktigste fordelene med ER-modeller:
- Et nøyaktig og forståelig format for å dokumentere informasjonsstrukturen.
- Lar deg spesifisere krav til data og relasjoner mellom dem.
- Lar deg tydelig vise lagringsstrukturen for å lette databasedesign.
- Det finnes metoder for å kartlegge ER-modeller til databasetabeller og omvendt.
- Legger grunnlaget for integrasjon med andre applikasjoner.
Hovedtypene av objekter i ER-diagrammet:
- Entitet er en type objekter, informasjon om hvilke vil bli lagret i databasen. For eksempel: avdelinger, ansatte, varer, fakturaer.
- Attributt - elementer som utgjør enheter. For eksempel, for «produkter»-enheten, kan attributtene være «navn», «beskrivelse», «mengde», «pris» og andre, avhengig av informasjonssystemets behov. Avhengig av notasjonen til ER-diagrammet, ved siden av attributtet, i tillegg til navnet, angi type og obligatorisk fylling. Lysbildet viser et ER-diagram i "Information Engineering"-notasjonen, i henhold til hvilket navn, type og om det er et eksternt og/eller primærkall er angitt for attributtet.
- Relasjoner viser sammenhenger mellom enheter. For eksempel jobber en ansatt i en avdeling der "avdeling" og "avdeling" er enheter.
En enhet er et sett med objekter fra den virkelige verden, som hver har følgende egenskaper:
- Unik (kan skilles fra alle andre på en eller annen måte)
- Spiller en rolle i systemet som modelleres
- Kan beskrives med én eller flere opplysninger (attributt)
Eksempel: personer, ansatte, arrangementer, bestillinger, salg, kunder, leverandører
Et attributt beskriver noen egenskaper til en enhet. En enhet kan ha mange attributter, men bare de som er viktige for systemet velges. Attributter er delt inn i nøkkel (Entity Keys) og beskrivende (Entity Descriptors). Nøkkelattributter må identifisere forekomster av en enhet unikt. For hvert attributt må et domene (type, emneområde) angis.
Lysbildet viser hvordan enheter og attributter er skrevet i ulike ER-modellnotasjoner. I alle notasjoner er en enhet et rektangulært formet objekt, øverst i hvilket navnet på enheten er angitt. Attributtene er oppført under enhetsnavnet.
La oss se nærmere på hva nøkkelegenskaper er. Dette er viktig for å forstå typene relasjoner mellom enheter.
Grunnleggende vilkår
Relasjonsmodellen kan beskrives ved behov matematisk språk, det vil si den mest nøyaktige oppfunnet av mennesket. Nedenfor følger løse definisjoner av noen begreper i relasjonsmodellen.
- "Datatype" (type, domene - domene) - et sett med tillatte verdier ("domene") og operasjoner. Alle typer har sammenlignings- og tildelingsoperasjoner. Mengder er ikke forbudt å ha strukturen til for eksempel en gjenstand.
- "Relasjon" (relasjon) - et sett med attributter: unike navn med avklaring av datatypen; pluss et sett med "verdisett" ("serier") som tilsvarer attributtene. Verdier i sett kan bare representeres av enkeltverdier av typene som tilsvarer attributtene, det vil si at de kan være skalarer ("første normalform").
- "Nøkkel" (nøkkel) er en gruppe attributter hvis verdier i alle sett er forskjellige i forhold, men ikke en eneste undergruppe av disse attributtene har allerede en slik egenskap (nøkkelens "minimalitet"-egenskap). Spesielt kan en gruppe bestå av et enkelt attributt. En nøkkel i et forhold må alltid være tilstede, og hvis det er flere av dem, må en av dem betegnes som "primær".
- "Fremmednøkkel" er en gruppe attributter hvis verdier i hvert sett med relasjonsverdier må falle sammen med verdiene til en nøkkel av muligens en annen relasjon. Fremmednøkler i en relasjon er valgfrie og deklareres i henhold til modelleringsbehov.
- "Operasjoner" (operasjon) - et sett med generelle handlinger på relasjoner, som igjen resulterer i relasjoner ("lukkethet av operasjoner"). De brukes til å innhente nye relasjoner for behovene til etterfølgende modellering eller ved uttrekking av nødvendige data fra databasen. Listen over operasjoner kan defineres på forskjellige måter; i de første setningene av modellen ble det gitt åtte operasjoner (projeksjon, kobling, utvalg, etc.), ikke lenger minimumssett, som et kompromiss mellom mangel på redundans og brukervennlighet.
- " Relasjonsdatabase" (relasjonsdatabase) - et sett med relasjoner.
En "datatype" kalles noen ganger et "domene", men noen ganger refererer "domene" bare til "definisjonsdomenet" av verdier. Et "sett med mengder" (tuppel) på russisk kalles ellers en "tuppel" eller "n-coy".
For enkelhets skyld er relasjoner ofte avbildet i form av tabeller, selv om en slik representasjon er illegitim (verken rekkefølgen av attributter eller rekkefølgen av sett med verdier er definert i en relasjon, i motsetning til en tabell). I SQL, som den er bygget på grunnlag av, inkludert Oracle DBMS, begrepet «relasjon» som et modelleringsverktøy er blitt erstattet nettopp med «tabell». En annen representasjon av relasjonsdata kan være en hyperkube, og det er også noen ganger praktisk å ty til den i resonnement om en eksisterende database.
Hvis vi forlater det definerende sporingsordet "relasjonell", kan begrepet "relasjonsdatabase" oversettes til "relasjonsdatabase" (mer presist, "database bygget gjennom relasjoner"; relasjoner som et verktøy, ikke som et objekt for modellering: ellers ville det opprinnelige begrepet være relasjonsdatabase). På samme måte kan begrepet "relasjonsmodell" oversettes til "relasjonsmodell", det vil si "en begrepssystem for å konstruere en modell av et fagområde i form av et sett relasjoner." Av en rekke grunner, inkludert historiske og språklige, ble dette ikke gjort på den tiden.
Alle dataforhold er beskrevet åpenbart Og bare verdier i sett (dette kan være annerledes i andre modelleringsmetoder). Det er ingen "underforståtte" avhengigheter (inkludert på nivået av programlogikk), bortsett fra relasjonene formulert av variabler. Den relasjonelle tilnærmingen skiller mellom beskrivelsen av data og programlogikken som følger med applikasjonen (i motsetning til for eksempel objekttilnærmingen).
Ovennevnte visning av en relasjonsdatabase (et sett med relasjoner og operasjoner) er typisk for relasjonsalgebra. Dette er ikke det eneste synspunktet. Hvert sett med verdier i en relasjonsvariabel kan forstås som en sann uttalelse ("predikat"): det er en slik og en ansatt med slike og slike egenskaper; slik og slik avdeling og så videre. Dermed representerer relasjonsdatabasen i hvert øyeblikk i tid et sett av sanne utsagn om fagområdet, formulert gjennom relasjoner. I hovedsak et sett med uttalelser i forholdsvariabler og danner en domenemodell representert av databasen. Denne visningen av en relasjonsdatabase er typisk for relasjonsregning. Begge syn på relasjonsmodellen er godt studert og deres ekspressive ekvivalens er bevist.
For begrepene som er oppført på forrige lysbilde, er det uformelle ekvivalenter for å gjøre det lettere å forstå og huske betydningen:
- Relasjon → Tabell
- Tuple → String, ta opp
- Kardinalitet → Antall linjer
- Attributt → Kolonne, felt
- Grad → Antall kolonner
- Primærnøkkel → Identifikator
- Domene → Utvalg av akseptable verdier
Nøkkelfelt
Noen av egenskapene til et forhold er nøkler eller nøkler. Det finnes flere typer nøkler:
- En enkel nøkkel består av ett attributt, en sammensatt nøkkel består av flere.
- Potensiell nøkkel- et attributt eller sett med attributter som kan identifisere hver av tuplene i en relasjon. For eksempel, i forhold til passkontoret («Passnummer») og («Fullt navn» og «Fødselsdato») er potensielle nøkler som lar deg identifisere hver person unikt.
- Hvert forhold kan bare ha én primærnøkkel - et attributt eller sett med attributtverdier hvis verdier unikt identifiserer hver post. Hvis flere sett med attributter har slike egenskaper, velges en av dem som den primære, og alle de andre velges som alternative.
- Utenlandsk nøkkel - butikker betydning den primære nøkkelen til en annen relasjon. Fremmednøkler brukes til å kommunisere mellom relasjoner.
Primærnøkkel
- Hver relasjonsrelasjon har bare 1 primærnøkkel, alle andre er alternative nøkler.
- Verdien av alle primærnøkkelattributter Ikke Kan være udefinert. For eksempel lagrer en relasjon informasjon om innbyggerne i en by. Primærnøkkelen er sammensatt (NAVN, ETTERNAVN, fødselsdato). Informasjonssystemet ble installert på Island, hvor de ikke bruker etternavn, noe som betyr at "etternavn"-attributtet vil være tomt for de fleste tupler. Til tross for dette vil den sammensatte primærnøkkelen fortsette å identifisere hver av tuplene unikt. Det er imidlertid uakseptabelt at verdiene til alle primærnøkkelattributter er tomme samtidig.
- Verdien til primærnøkkelen påvirker ikke plasseringen av tuplene i tabellvisningen av forholdet. Selv om primærnøkkelverdien er et tall (for eksempel 1,2,3...) gir dette generelt ingen garanti for at tuplene i databasen er lagret i samme rekkefølge og vil bli sendt ut i samme rekkefølge. I det "generelle tilfellet" betyr det at noen ganger, på grunn av spesifikasjonene til en bestemt DBMS, kan rader lagres i rekkefølge etter primærnøkkelen, men dette er snarere et unntak. Når du sender ut spørringsresultater, må vi spesifisere eksplisitt rekkefølgen radene skal skrives ut i hvis den rekkefølgen er viktig. Resultatene av spørringen "gi meg de første 5 personene" er uforutsigbare hvis vi ikke spesifiserer etter hvilket kriterium de skal være "første".
- Primærnøkkelen påvirker ikke tilgangen til attributtene til en tuppel. For eksempel, i forhold til "passkontoret", lagres personens registreringsadresse sammen med fullt navn og fødselsdato. Vi kan be databasen trekke ut alle adresser uten å vite fullt navn og fødselsdato.
Ekstern nøkkel
En fremmednøkkel brukes til å etablere forbindelser mellom relasjoner. La oss for eksempel ta to forhold "Eiere" (primærnøkkel "passnummer") og "Eiendom". For å fastslå hvem som eier hver eiendom, vil vi koble disse relasjonene med verdien av "passnummer"-attributtet. I motsetning til primærnøkkelen kan verdien av en fremmednøkkel være udefinert (linje 4 på lysbildet) - hvis vi ikke kjenner eieren av eiendommen, angir vi det ikke. I motsetning til primærnøkkelen, kan verdien av fremmednøkkelen gjentas (lager 1.3 på lysbildet) - én eier kan ha flere eiendomsobjekter. Det faktum at "passnummer"-attributtet i "Eiendom"-relasjonen er en fremmednøkkel til primærnøkkelen til "Eier"-forholdet, garanterer imidlertid at verdien av "pastornummer"-attributtet kun kan være verdier fra primærnøkkelen. Vi kan ikke spesifisere prestebolignummeret til en person som en attributtverdi som ikke allerede eksisterer i Eierrelasjonen (linje 5).
Ved å angi en fremmednøkkel, kan du eksplisitt angi oppførselen til DBMS hvis du endrer verdien på primærnøkkelen eller sletter en tuppel. Regelen "den fremmede nøkkelen lagrer bare verdiene som er i primærnøkkelen eller en udefinert verdi (NULL)" forblir den samme.
En fremmednøkkel mellom relasjoner er vanligvis spesifisert når du designer en database. Den kan imidlertid fjernes når som helst eller installeres på nytt hvis å legge til denne begrensningen ikke er i konflikt med egenskapene til fremmednøkkelen. Fjerning/installering av fremmednøkler gjøres vanligvis når du setter inn svært store datamengder, for å fremskynde denne prosessen - DBMS kan ikke lagre inkonsistente (feil, feilaktige) data, så den sjekker hver begrensning når den setter inn hver rad.
ER-modeller: tilkoblinger
I ER-modeller vises fremmednøkler som relasjoner.
Hver forbindelse er preget av 4 egenskaper - styrke, kraft, grad og deltakelse av enheten i forbindelsen.
La oss se på disse egenskapene.
Entitets deltakelse i forholdet
Indikert på forbindelsen med en tverrgående linje eller sirkel.
Tverrlinjen betyr påbudt, bindende (påbudt, bindende) enhetens deltakelse i forbindelsen, og sirkelen - valgfri (valgfri).
I tilfelle av obligatorisk deltakelse av en enhet i en forbindelse, verbet " må". Hvis enheten ikke nødvendigvis deltar i forbindelsen, vil verbet " Kan være".
På avdelingen Kan være ansette flere ansatte. Ansatt må arbeid i en av avdelingene.
Tilknytningsgrad ( forhold grad) angir antall tilknyttede enheter. Binær kommunikasjon ( binær forhold) beskriver assosiasjonen av to enheter. Ternær forbindelse (ternær forhold) oppstår når tre enheter er tilknyttet. Unær kommunikasjon (unær forhold) beskriver assosiasjoner innenfor en enkelt enhet.
De vanligste er binære forbindelser - de forbinder to forskjellige enheter ("Avdeling" - "Ansatt", "Ordre" - "Varer", "Kurs" - "Forelesninger", "Gruppe" - "Studenter"). Mindre vanlig, men fortsatt ofte brukt, er unære forbindelser. Med deres hjelp setter de vanligvis en nesterelasjon på objekter av samme type («Detaljer»-relasjonen - vi kan spesifisere integrert del hvilken detalj er dette, forholdet "Ansatte" - vi kan indikere hvilken ansatt som er sjef for dette).
Koblingsstyrke viser hvor mange forekomster av en enhet som er koblet til forekomster av en annen enhet.
Strøm kan være:
- en til en(1:1) - det er en rektor i en gruppe studenter;
- en-til-mange(1:N) - mange ansatte jobber i en avdeling;
- mange-til-mange(M:N) - én kjøper kjøpte mange varer, mange kjøpere kjøpte varer.
Tilknytningsstyrke: sterk tilknytning (identifiserende forhold)
En underordnet enhet kan ikke eksistere uten en overordnet enhet. (Det er ikke noe svar uten et spørsmål; det er ikke noe produkt i brukerens handlekurv hvis selve handlekurven ikke eksisterer)
I dette tilfellet migrerer primærnøkkelen fra den overordnede enheten til den underordnede enheten, hvor den blir en del av primærnøkkelen.
I et diagram er et sterkt forhold representert av en ubrutt linje mellom enheter.
Relasjonsstyrke: Ikke-identifiserende forhold
Den overordnede og underordnede enheten er relatert, men den underordnede enheten kan opprettes først. (Lasten tilhører ordren, men lasten kan være på lageret før ordren opprettes).
Primærnøkkelen migrerer fra den overordnede enheten til den underordnede enheten og er ikke en del av primærnøkkelen (den blir ganske enkelt en fremmednøkkel).
I diagrammet er et sterkt forhold representert med en stiplet linje mellom enheter.
Rekursiv kobling (unær kobling)
Oftest brukt til å bygge hierarkier.
En leverandør KAN jobbe med NULL eller FLERE kunder (id_Customer).
Kunden MÅ samarbeide med én leverandør (id_Sup).
Men leverandøren og kunden – enten det er en bedrift eller en organisasjon – er gjenstander av samme type og er derfor lagret i samme relasjon.
Mange-til-mange kommunikasjon.
Eksempel: Leverandører kan levere mange typer varer. Ulike leverandører kan levere samme type varer.
Mange-til-mange-relasjoner er gyldige fra ER-modellens synspunkt, men kan ikke reflekteres direkte i forhold til relasjonsalgebra.
Tvetydigheten i forholdet løses ved å introdusere overgangsenheter, som vist på lysbildet.
ER-modeller og virkelighet
Ved nærmere inspeksjon av en en-til-en-relasjon viser det seg nesten alltid at A og B faktisk er forskjellige undergrupper av den samme tingen, eller forskjellige perspektiver på den, bare de har forskjellige navn og ulikt beskrevne relasjoner og attributter.
La oss forestille oss at A er leverandøren, B er produktet.
Obligatorisk-obligatorisk. For eksempelet vist på lysbildet betyr dette forholdet at hver Leverandør må leverer kun én unik sett med varer (Faktura). Fra et teoretisk synspunkt er alt bra her. I praksis er dette ikke akseptabelt: ingen vil se etter en ny leverandør hvis leverandøren du har verifisert kan tilby flere produktserier. Og nå om følelsene operatøren vil oppleve når han prøver å legge inn data om en ny leverandør. Han vil ikke kunne legge inn data i noen av tabellene. Så all bagasjen med uanstendig språk vil bli rettet mot deg.
Valgfritt-obligatorisk. Et eksempel på tilkoblingen er vist på lysbildet. Som vi kan se, er alt bra med operatøren nå: han kan legge inn data. Virksomheten har igjen et problem: den må se etter en ny leverandør, selv om leverandøren du har verifisert kan levere flere produktlinjer. Trenger virksomheten problemer? Nei. Den må fungere. Hvordan tilfredsstille en bedrift? Svaret er enkelt. Når du designer en database, må du tenke på normalisering. Hvis leverandøren er en enhet, bruk valgfrie-obligatoriske (obligatoriske-valgfrie) eller valgfrie-valgfrie relasjoner. Selv om oftest en-til-en-forhold er en feil.
Valgfritt-valgfritt. Som vi ser går det bra igjen med operatøren, men virksomheten har igjen et problem. La oss oppsummere for en-til-en kommunikasjon. Hvis enheter deltar i en forbindelse som: - obligatorisk-obligatorisk, har en slik forbindelse ingen rett til liv; - valgfritt-obligatorisk (obligatorisk-valgfritt) eller valgfritt-valgfritt, da er forretningsstøtte problematisk.
En en-til-mange obligatorisk-obligatorisk relasjon er en ganske sterk konstruksjon som innebærer at en forekomst av entitet B ikke kan opprettes uten samtidig å skape minst en forekomst av entitet A knyttet til den. Oftest er dette en feil relasjon.
Et en-til-mange obligatorisk-valgfritt forhold er den vanligste formen for forhold. Den forutsetter at hver eneste forekomst av enhet A kan eksistere kun i sammenheng med én (og bare én) forekomst av enhet B. I sin tur kan forekomster av B eksistere enten med eller uten forekomster av A.
En-til-mange-forhold valgfritt-valgfritt - Både A og B kan eksistere uten et forhold mellom dem.
Når det gjelder det forrige lysbildet, kan disse diagrammene illustreres med følgende eksempler.
En-til-mange forhold. Disse relasjonene innebærer at én post i én tabell kan være logisk relatert til flere poster i en annen tabell.
Obligatorisk-obligatorisk. For eksempelet vist på lysbildet betyr dette forholdet at hver leverandør (A) må levere ett eller flere sett med varer (B). Fra et teoretisk synspunkt er alt bra her. Men i praksis vil operatøren ikke kunne legge inn data i noen av tabellene, siden postene må være det samtidig gå inn i begge tabellene.
Valgfritt-obligatorisk. I dette tilfellet er alt bra for operatøren: han kan legge inn data, men virksomheten kan ha problemer. Poenget er at det valgfritt-obligatoriske forholdet forutsetter at leverandøren (A) må levere ett eller flere sett med varer (B), mens B Kan være tilhører leverandøren. Med andre ord kan varer eksistere uten leverandør mens leverandøren har varene. De. ukontrollert forretningsatferd er mulig: hvem leverte varene? Hvem skal jeg spørre? Trenger virksomheten problemer? Nei. Det må gi overskudd. I dette tilfellet er det bedre å bruke obligatorisk-valgfritt: Leverandøren kan levere ett eller flere sett med varer, mens varene må tilhøre leverandøren. Med andre ord har produktet en leverandør, og data om leverandørene som en gang leverte produktet vil bli lagret. Og sauene er trygge og ulvene blir matet - operatøren kan legge inn data og forretningsmannen er orientert.
Valgfritt-valgfritt. Som vi ser er alt bra med operatøren igjen, men virksomheten har et problem – mangel på kontroll: Et produkt kan eksistere uten en leverandør og en leverandør uten et produkt.
La oss oppsummere for en-til-mange-kommunikasjon. Hvis enheter deltar i et forhold som: - obligatorisk-obligatorisk, har et slikt forhold ingen rett til liv, siden det er umulig å legge inn poster samtidig i begge tabellene; - valgfritt-valgfritt, da er forretningsstøtte problematisk.
Mange-til-mange-relasjoner er gyldige i ER-diagrammer, men når de konverteres til bordvisning en slik forbindelse erstattes av en mellomliggende enhet.
Mange-til-mange obligatorisk-obligatorisk - denne konstruksjonen forekommer ofte i begynnelsen av analysestadiet og betyr et forhold - enten ikke fullt ut forstått og krever ytterligere oppløsning, eller gjenspeiler et enkelt kollektivt forhold - en toveis liste.
Mange-til-mange obligatorisk-valgfritt - brukes sjelden. Slike forbindelser er alltid gjenstand for ytterligere detaljer.
Rekursive sammenhenger. Disse relasjonene antyder at tabelloppføringer kan være logisk relatert til hverandre.
Valgfritt-valgfritt en-til-en. For eksempelet vist på lysbildet betyr dette forholdet at enhver mann (kvinne) kan være gift med én kvinne (mann). Denne forbindelsen er praktisk for å spore historien til de som gifter seg: for første gang, igjen, ... Med andre ord, en alternativ type forhold.
Valgfritt-valgfritt en-til-mange. Et eksempel på tilkoblingen er vist på lysbildet. Dette er et klassisk hierarki (trestruktur). Relasjonen som vises på lysbildet kan for eksempel tolkes som følger: enhver ansatt kan rapportere til kun én leder, mens en leder kan administrere én eller flere ansatte.
Valgfritt-valgfritt M:M Et eksempel på kommunikasjon er vist på lysbilde 3. Dette er en nettverksstruktur.
Sjekkliste for enhetsspørsmål
- Gjenspeiler enhetsnavnet essensen av dette objektet?
- Er det noen overlapping med andre enheter?
- Er det minst to attributter?
- Det er ikke mer enn åtte attributter totalt?
- Finnes det noen synonymer/homonymer for denne enheten?
- Er enheten fullstendig definert?
- Finnes det en unik identifikator?
- Er det minst én forbindelse?
- Er det minst én funksjon for å opprette, søke, redigere, slette, arkivere og bruke en enhetsverdi?
- Er det en historie med endringer?
- Er det samsvar med datanormaliseringsprinsipper?
- Er det samme enhet i et annet applikasjonssystem, kanskje under et annet navn?
- Har ikke essensen også generell betydning?
- Er nivået av generalisering nedfelt i den tilstrekkelig?
Sjekkliste for attributter:
- Er attributtnavnet et entallssubstantiv som gjenspeiler essensen av egenskapen angitt av attributtet?
- Inkluderer ikke attributtnavnet enhetsnavnet (det burde det ikke)?
- Har et attributt bare én verdi om gangen?
- Er det noen dupliserte verdier (eller grupper)?
- Er formatet, lengden, gyldige verdier, innhenting av algoritme osv.?
- Kan dette attributtet være en manglende enhet som vil være nyttig for et annet applikasjonssystem (eksisterende eller foreslått)?
- Kan han være en tapt forbindelse?
- Er det en referanse et sted til et attributt som en "designfunksjon" som skal forsvinne når du flytter til applikasjonsnivå?
- Er det behov for en endringshistorikk?
- Avhenger betydningen bare av denne enheten?
- Hvis attributtens verdi kreves, er den alltid kjent?
- Er det behov for å opprette et domene for denne og lignende attributter?
- Avhenger verdien bare av en del av den unike identifikatoren?
- Er verdien avhengig av verdiene til noen attributter som ikke er inkludert i den unike identifikatoren?
Introduksjon
Sentrale ideer om moderne informasjonsteknologi er basert på konseptet om at data skal samles inn i databaser for å reflektere den virkelige verden i endring og møte brukernes informasjonsbehov. Disse databasene er dannet og opererer under kontroll av spesielle programvaresystemer (sett med programmeringsspråk og programvare), kalt databasestyringssystemer (DBMS). Selve databasen er et depot for en stor mengde systematiserte data som du kan utføre visse handlinger med: legge til, slette, endre, kopiere, organisere.
Økningen i volumet av lagrede data og utvidelsen av brukerkretsen av informasjonssystemer har ført til utbredt bruk av den mest praktiske og relativt lettfattelige relasjonelle (tabellformede) DBMS. For å sikre samtidig tilgang til data for mange brukere, ofte plassert ganske langt fra hverandre og fra stedet der databasene er lagret, er det laget nettverksbaserte flerbrukerversjoner av databaser basert på en relasjonsstruktur. På en eller annen måte løser de spesifikke problemer med parallelle prosesser, integritet (riktighet) og sikkerhet for data, samt tilgangsautorisasjon.
I løpet av de siste årene har det vært en trend mot mer komplekse datastrukturer. Enkle typer informasjon representert i form av tall og tekststrenger, uten å miste sin betydning, suppleres i dag av en rekke multimediedokumenter, grafiske bilder, kronologiske serier, prosedyremessige eller aktive data og myriader av andre komplekse informasjonsformer. I denne forbindelse har en hel galakse av DBMS-er dukket opp som støtter nye datainnsamlinger og er i stand til å realisere fordelene med moderne maskinvare. En slik DBMS er MS Access 2003 (2007), inkludert i programvarepakken Microsoft Office, og er en av de populære relasjonelle DBMS-ene for lokale datamaskiner.
Populariteten til Microsoft Access DBMS skyldes følgende årsaker:
tilgjengelighet og klarhet gjør det til et av de beste systemene for raskt å lageoner;
fullstendig russifisert;
muligheten til å bruke OLE-teknologi;
støtte for WWW-ideologi;
visuell teknologi lar deg hele tiden se resultatene av handlingene dine og korrigere dem; i tillegg kan arbeid med skjemadesigneren betydelig lette videre studier av programmeringssystemer som f.eks. Visual Basic eller Delphi;
hjelpesystemet er bredt og tydelig presentert;
tilstedeværelsen av et stort sett med "mestere" i å utvikle objekter.
For tiden er automatiserte informasjonssystemer (AIS) mye brukt i ulike store organisasjoner.
Formålet med dette prosjektet: å i praksis anvende kunnskapen som er oppnådd i prosessen med å studere "Databaser"-kurset og å tilegne seg praktiske ferdigheter i design og opprettelse av informasjonssystemer (IS) basert på databaser.
Grunnleggende konsepter for ER-modellen: enhet, enhetsforekomst, attributt, nøkkel, relasjon, typer relasjoner
Hovedkonseptene i ER-modellen er enhet, relasjon og attributt.
En enhet er et reelt eller tenkelig objekt som informasjon må lagres og tilgjengelig om. I ER-modelldiagrammer er en enhet representert som et rektangel som inneholder navnet på enheten. I dette tilfellet er navnet på enheten navnet på typen, og ikke en spesifikk forekomst av denne typen. For større uttrykksevne og bedre forståelse kan enhetsnavnet ledsages av eksempler på spesifikke objekter av denne typen.
Hver forekomst av en enhet må kunne skilles fra alle andre forekomster av samme enhet (dette kravet er noe analogt med kravet om at det ikke er dupliserte tupler i relasjonstabeller).
Et enhetsattributt er enhver detalj som tjener til å klargjøre, identifisere, klassifisere, kvantifisere eller uttrykke enhetens tilstand. Attributtnavn legges inn i et rektangel som representerer enheten, under enhetsnavnet, og er avbildet med små bokstaver, eventuelt med eksempler.
En enhetsnøkkel er et ikke-redundant sett med attributter hvis kollektive verdier er unike for hver enhetsforekomst. Ikke-redundans er at fjerning av attributter fra en nøkkel bryter dens unikhet. En enhet kan ha flere forskjellige nøkler. Nøkkelattributter er vist understreket i diagrammet.
Et forhold er en grafisk representert assosiasjon etablert mellom to enheter. Denne assosiasjonen er alltid binær og kan eksistere mellom to forskjellige enheter eller mellom en enhet og seg selv (rekursivt forhold). I enhver forbindelse identifiseres to ender (i samsvar med det eksisterende paret av tilkoblede enheter), som hver indikerer navnet på slutten av forbindelsen, graden av slutten av forbindelsen (hvor mange forekomster av denne enheten er koblet til ), den obligatoriske karakteren av forbindelsen (dvs. om noen forekomst av denne enheten må delta i denne forbindelse).
En forbindelse er representert som en linje som forbinder to enheter eller leder fra en enhet til seg selv. I dette tilfellet, på punktet der forbindelsen "føyes sammen" med enheten, brukes en trepunktsinngang i enhetsrektangelet, hvis mange forekomster av enheten kan brukes for denne enheten i forbindelsen, og et enkeltpunkt oppføring, hvis bare én forekomst av enheten kan delta i forbindelsen. Den nødvendige enden av forbindelsen er avbildet med en heltrukket linje, og den valgfrie enden med en brutt linje.
Hver lenke har to ender og ett eller to navn. Navnet er vanligvis uttrykt i en ubestemt verbal form: "å ha", "tilhøre", etc. Hvert navn refererer til sin egen ende av forbindelsen. Noen ganger skrives ikke navn fordi de er åpenbare. Hver lenke kan ha en av følgende koblingstyper:
Entil en
Enfor mange
Mange til mange
Ris. 1 – Typer tilkoblinger
En en-til-en-relasjon betyr at én forekomst av den første enheten (den venstre) er assosiert med én forekomst av den andre enheten (den høyre). Et en-til-en-forhold indikerer oftest at vi faktisk bare har én enhet, feilaktig delt i to.
En en-til-mange-relasjon betyr at én forekomst av den første enheten (den venstre) er assosiert med flere forekomster av den andre enheten (den høyre). Dette er den mest brukte typen kommunikasjon. Den venstre enheten (på "en"-siden) kalles forelderen, den høyre (på "mange"-siden) kalles barnet.
En mange-til-mange-relasjon betyr at hver forekomst av den første enheten kan assosieres med flere forekomster av den andre enheten, og hver forekomst av den andre enheten kan assosieres med flere forekomster av den første enheten. Mange-til-mange relasjonstypen er en midlertidig relasjonstype som er akseptabel i de tidlige stadiene av modellutvikling. I fremtiden bør denne typen relasjoner erstattes av to en-til-mange relasjoner ved å opprette en mellomenhet.
Hver tilkobling kan ha en av to kommunikasjonsmodaliteter:
Kan være
Må
Ris. 2 – Kommunikasjonsmodalitet
"kan"-modaliteten betyr at en forekomst av en enhet kan være assosiert med en eller flere forekomster av en annen enhet, eller ikke kan være assosiert med noen forekomst.
"Må"-modaliteten betyr at en forekomst av én enhet må være assosiert med minst én forekomst av en annen enhet.
Konvertering av ER-modellen til en relasjonsdatamodell
La oss se på transformasjonen av en ER-modell til en relasjonsdatamodell ved å bruke et abstrakt eksempel. La oss anta at en ER-modell er gitt. Det er nødvendig å få et sett med tabeller (relasjoner) av formen Tabell (Key, Attribute1, Attribute2, ..., AttributeN). Nøkkelen kan være sammensatt. Det er praktisk å gjøre navnene på attributter i skalaen til ER-modellen unike, så når man bygger en relasjonsmodell, vil de (nesten aldri) måtte gis nytt navn.
Konvertering av enhetssett (entities for korte)
Konvertering av en vanlig enhet
Ris. 3 – Konvertering av en vanlig enhet
En vanlig enhet konverteres til en separat tabell, tabellfeltene vil være alle attributtene til enheten: Entitet (Nøkkel, Attributt1, Attributt2)
Konvertering av en svak enhet
Den svake enheten konverteres til en separat tabell, feltene i tabellen vil være alle attributtene til enheten pluss nøkkelattributtene til alle enhetene som denne svake enheten er identifisert med.
Nøkkelfeltene til alle overordnede tabeller vil bli inkludert i nøkkelen til den underordnede tabellen. For en underordnet tabell vil de bli kalt en fremmednøkkel: Entity1 (Key1, Key2, Attribute1, Attribute2).
Nøkkel 1
Egenskap 1
Egenskap2
Entitet 1
Essens2
Nøkkel2
Ris. 4 – Svak enhetstransformasjon
Konvertering av enhetsundertyper
1 vei. Det lages én tabell der alle attributter er plassert. For å indikere hvilken undertype et objekt tilhører, må du legge inn et ekstra attributtfelt: Entity1(Key, Attribute1, Attribute2, Attribute3, Attribute4, Attribute4, Attribute).
Ulempen med denne metoden er at mange tomme felt forblir i tabellen: for et objekt av undertype 1, attributter 4 og 5, og for et objekt av undertype 2, vil attributter 2 og 3 forbli tomme.
Metode 2. Opprettet separat bord for hver undertype. Den inkluderer alle attributtene til denne undertypen og alle attributtene til supertypen:
Subtype1(Nøkkel, attributt1, attributt2, attributt3)
Subtype2(Nøkkel, attributt1, attributt4, attributt5)
Ulempen med denne tilnærmingen er at undertypene ikke lenger er relatert til hverandre.
3 veis. Det opprettes én tabell for supertypen, og én tabell for hver undertype, som inkluderer nøkkelfeltene til supertypen:
Entitet1(nøkkel, attributt1)
Subtype1(Nøkkel, attributt2, attributt3)
Subtype2(Nøkkel, attributt4, attributt5)
Ulempen med denne tilnærmingen er at informasjon om hvert objekt nå er spredt over to tabeller.
Ris. 5 – Konvertering av enhetsundertyper
M:M-forbindelse
Transformere lenker
For tilkoblinger - doble diamanter, trenger du ikke å gjøre noe; all informasjon er allerede lagret i tabellen til den svake enheten.
Ris. 6 – M:M kommunikasjon
Det opprettes en ny tabell som inneholder nøkkelfeltene til hver enhet som deltar i relasjonen og relasjonens egne attributter, hvis noen. Navnet gjenspeiler vanligvis hvilke enheter som kobles sammen, eller refererer til den nye tabellen med navnet på relasjonen.
Entitet1Entitet2(Nøkkel1, Nøkkel2, Attributt1).
Hvis den egen egenskapen til en forbindelse er nøkkelen, så er det faktisk ikke lenger en binær forbindelse, men en forbindelse med større aritet, dvs. dette attributtet kan erstattes av en ny enhet som det er en en-til-en-relasjon til. I dette tilfellet må du bruke reglene for ternære og andre forhold
Link 1:M
Ris. 7 – Link 1:M
1 vei. På samme måte som i tilfellet med M:M, opprettes en ny tabell som inneholder nøkkelfeltene til hver enhet som deltar i relasjonen. Navnet gjenspeiler vanligvis hvilke enheter som kobles sammen, eller refererer til den nye tabellen med navnet på relasjonen. Nøkkelen vil være nøkkelen til den andre enheten.
Entitet1Enhet2(Nøkkel1, Nøkkel2).
Metode 2. En ny tabell opprettes ikke, og nøkkelfeltene til den overordnede enheten legges til tabellen til den underordnede enheten (de vil ikke bli inkludert i nøkkelen til den underordnede enheten). Nøkkelfeltene til den overordnede enheten representerer fremmednøkkelen til den underordnede enheten.
Denne metoden er å foretrekke å bruke hvis relasjonen er en nøyaktig én relasjon, det vil si at alle enhetsforekomster er involvert i relasjonen. I dette tilfellet vil fremmednøkkelfeltet aldri være tomt.
Underordnet enhetstabell: Entitet2(Nøkkel2, Attributt1, Nøkkel1).
1:1 kommunikasjon
Ris. 8 – 1:1 kommunikasjon
1 vei. På samme måte som i tilfellet med M:M, opprettes en ny tabell som inneholder nøkkelfeltene til hver enhet som deltar i relasjonen. Navnet gjenspeiler vanligvis hvilke enheter som kobles sammen, eller refererer til den nye tabellen med navnet på relasjonen. Nøkkelen vil være nøkkelen til enhver enhet.
Denne metoden er å foretrekke å bruke hvis relasjonen ikke er "nøyaktig til en", det vil si at ikke alle enhetsinstanser deltar i relasjonen.
Entitet1Entitet2(Nøkkel1, Nøkkel2) eller Entitet1Entitet2(Nøkkel1, Nøkkel2).
Metode 2. På nøyaktig samme måte som i tilfelle 2 1:M, opprettes ikke en ny tabell, men nøkkelfeltene til en annen enhet (vi vil anse det som overordnet) legges til tabellen til en av enhetene (vi vil vurdere det et barn).
Hvis relasjonen ikke er en nøyaktig én relasjon til den overordnede tabellen, det vil si at ikke alle enhetsforekomster deltar i relasjonen, kan fremmednøkkelfeltet i enkelte poster være tomt.
Underordnet enhetstabell: Entity1(Key1, Attribute1, Key2),
eller Entitet2(Nøkkel2, Attributt2, Nøkkel1).
3 veis. To tabeller for enheter som er relatert 1:1 slås sammen til én. Nøkkelen til det nye bordet kan være en kombinasjon av nøklene til begge tabellene. Hvis forholdet er "nøyaktig til en" i minst én retning, kan nøkkelen til denne enheten betraktes som nøkkelen til den sammenføyde tabellen.
Tabeller: Entitet1(Nøkkel1, Attributt1) og Entitet2(Nøkkel2, Attributt2) erstattes med
Entitet1Entitet2(Nøkkel1, attributt1, nøkkel2, attributt2)
eller kanskje Entity1Entity2(Key1, Attribute1, Key2, Attribute2),
eller Entitet1Entitet2(Nøkkel1, Attributt1, Nøkkel2, Attributt2).
De samme reglene gjelder for å relatere en enhet til seg selv, men siden samme enhet er involvert i relasjonen to ganger, må nøkkelfeltene vises i samme tabell to ganger. Derfor må du gi nytt navn til en av nøklene.
La oss se på 1:M-forholdet, metode 2. Fremmednøkkelen har fått nytt navn.
Ris. 9 – Relasjon 1:M, fremmednøkkel omdøpt
Entitet1(Nøkkel1, Attributt1, En annenNøkkel1).
For relasjoner med aritet større enn 2, brukes vanligvis samme metode som for en binær M:M-relasjon - det opprettes en ny tabell som inneholder nøkkelfeltene til alle relaterte tabeller: Entity1Entity2Entity3(Nøkkel1, Nøkkel2, Nøkkel3).
Regler for å konvertere en ER-modell til en relasjonsmodell
Regel 1. Hver enhet er assosiert med en relasjon i relasjonsdatamodellen. I dette tilfellet kan navnene på enheten og relasjonen være forskjellige, fordi navnene på enhetene kanskje ikke er underlagt ytterligere syntaktiske begrensninger, bortsett fra det unike med navnet i modellen. Relasjonsnavn kan begrenses av kravene til et bestemt DBMS, oftest er disse navnene identifikatorer på et underliggende språk, de er begrenset i lengde og må ikke inneholde mellomrom og noen spesialtegn. For eksempel kan en enhet kalles "Bokkatalog", og det er ønskelig å navngi den tilsvarende relasjonen, for eksempel BØKER (uten mellomrom og med latinske bokstaver).
Regel 2: Hvert enhetsattributt blir et attributt for den tilsvarende relasjonen. For hvert attributt spesifiseres en spesifikk datatype som er tillatt i DBMS og den obligatoriske eller valgfrie karakteren til dette attributtet (det vil si tillatelighet eller utillatelighet av NULL-verdier for det).
Regel 3. Primærnøkkelen til en enhet blir PRIMÆRNØKKEL for den tilsvarende relasjonen. Attributter inkludert i primærnøkkelen til en relasjon tildeles automatisk den nødvendige egenskapen (IKKE NULL).
Regel 4. I hvert forhold som tilsvarer en underordnet enhet, legges det til et sett med attributter til hovedenheten, som er primærnøkkelen til hovedenheten.
I relasjonen som tilsvarer den underordnede enheten, blir dette settet med attributter en FOREING KEY.
For å modellere en valgfri type relasjon på fysisk nivå, er attributter som tilsvarer en fremmednøkkel satt til å tillate nullverdier (NULL-attributt). Med en obligatorisk tilkoblingstype får attributtene egenskapen at de ikke har noen udefinerte verdier (NOT NULL-attributtet).
Normaliseringsteori
Normalisering av relasjoner (tabeller) er en av de grunnleggende delene av teorien om relasjonsdatabaser. Normalisering tar sikte på å kvitte seg med redundans i relasjoner og modifisere strukturen deres slik at prosessen med å jobbe med dem ikke belastes med ulike uvedkommende vanskeligheter. Hvis denne tilnærmingen ignoreres, reduseres designeffektiviteten raskt, noe som sammen med andre lignende friheter kan føre til kritiske konsekvenser.
Første normalform
En relasjon er i første normalform (forkortet 1NF) hvis alle dens attributter er atomære, det vil si hvis ingen av dens attributter kan deles inn i enklere attributter som tilsvarer noen andre egenskaper ved enheten som beskrives.
Vi vil kalle den opprinnelige relasjonen den viktigste, og verdien av den ikke-atomære attributten - den underordnede.
For å normalisere en kilderelasjon hvis attributter er ikke-atomiske, er det nødvendig å kombinere skjemaene til hoved- og underordnede relasjoner. I tillegg, hvis for eksempel en tabell som tilsvarer en ikke-normalisert relasjon allerede finnes i databasen og fylt med informasjon, kompliseres oppgaven av det faktum at verdien av en ikke-atomisk attributt i sin tur kan inneholde flere tupler.
La oss vurdere et forhold som har attributtene "Ansattkode", "Fullt navn", "Posisjon", "Prosjekter". Det er klart at én ansatt kan jobbe med flere prosjekter. La oss anta at et prosjekt er beskrevet av en ID, en tittel og en forfallsdato.
Ansatt kode
Fullt navn
Jobbtittel
Prosjekter
Ivanov Ivan Ivanovich
Programmerer
ID: 123; Tittel: Steam boiler control system; Innleveringsdato: 30.09.2011
ID: 231; Navn: PS for overvåking og advarsel om overskridelse av maksimalt tillatt konsentrasjon av ulike gasser i rommet; Innleveringsdato: 30.11.2011
ID: 321; Navn: Ansiktsgjenkjenningsmodul for sikkerhetssystem; Innleveringsdato: 12.01.2011
Det er lett å legge merke til at ikke alle egenskapene til dette forholdet er atomære (udelelige). Spesielt kan attributtet "Prosjekter" deles inn i tre enklere attributter: "Prosjektkode", "Tittel", "Leveringsdato", og verdien av dette attributtet for ansatte Ivan Ivanovich Ivanov inneholder flere tuples - informasjon om tre prosjekter.
La oss vurdere algoritmen for normalisering av forholdet til 1NF.
Opprett en ny relasjon, hvis skjema vil bli oppnådd ved å slå sammen hoved- og underordnede skjemaer for den opprinnelige relasjonen til ett.
For hver tuppel i den opprinnelige relasjonen, inkluderer i den nye så mange rader som det er tupler i den underordnede relasjonen til denne tuppelen.
Fyll inn verdiene til attributtene til den nye relasjonen som tilsvarer attributtene til den underordnede relasjonen. Fyll linjene i det nye forholdet med verdiene til atomattributtene til den opprinnelige.
La oss bruke denne algoritmen på forholdet ovenfor. Den nye relasjonsordningen vil bestå av 6 attributter: «Ansattkode», «Fullt navn», «Posisjon», «Prosjektkode», «Tittel», «Leveringsdato». For én enkelt tuppel av en gitt relasjon, legg til tre linjer til den nye, en for hvert prosjekt (i henhold til antall tupler i den underordnede relasjonen). Nå kan du fylle ut de separerte attributtverdiene med tupler fra den underordnede relasjonen. Deretter vil vi overføre verdiene til atomattributter til hver av disse linjene: "Ansattkode", "Fullt navn", "Posisjon" (alle tre linjene vil inneholde de samme verdiene for disse attributtene).
Resultatet vil se slik ut:
Ansatt kode
Fullt navn
Jobbtittel
Prosjektkode
Navn
Tidsfrist
Ivanov Ivan Ivanovich
Programmerer
123
Dampkjele kontrollsystem
30.09.2011
Ivanov Ivan Ivanovich
Programmerer
231
PS for overvåking og advarsel om overskridelse av maksimalt tillatt konsentrasjon av ulike gasser i rommet
30.11.2011
Ivanov Ivan Ivanovich
Programmerer
321
Ansiktsgjenkjenningsmodul for sikkerhetssystem
01.12.2011
Andre normalform
En relasjon i 1NF kan også ha redundans. Den andre normalformen er ment å eliminere den. Men før vi begynner å beskrive det, må vi først identifisere manglene ved den første.
La den innledende relasjonen inneholde informasjon om forsyningen av noen varer og deres leverandører.
Leverandør kode
By
Bystatus
Produktkode
Mengde
Moskva
300
Moskva
400
Moskva
100
Yaroslavl
200
Stavropol
300
Stavropol
400
Pskov
100
Det er kjent på forhånd at denne relasjonen inneholder følgende funksjonelle avhengigheter:
((Leverandørkode, Produktkode) -> (Antall),
(Leverandørkode) -> (By),
(Leverandørkode) -> (Status),
(By) -> (Status) )
Primærnøkkel i relasjonen: (Leverandørkode, Produktkode).
Det er åpenbart at forholdet er overflødig: det beskriver to enheter - forsyning og leverandør. I denne forbindelse oppstår følgende anomalier:
Anomali ved innsetting. Du kan ikke legge til informasjon om en leverandør som ennå ikke har levert noen varer til et forhold.
Slettingsavvik. Hvis det kun var én leveranse fra leverandøren, vil all informasjon om leverandøren slettes når informasjon om den slettes.
Oppdater anomali. Hvis du trenger å endre informasjon om leverandøren (for eksempel har leverandøren flyttet til en annen by), må du endre attributtverdiene i alle poster om leveranser fra ham.
Fysisk betydning Redundansen til den opprinnelige relasjonen ligger i det faktum at den ikke beskriver én enhet, men to - forsyningen og leverandøren.
For å eliminere disse anomaliene, er det nødvendig å bryte det opprinnelige forholdet i anslag:
Den første bør inkludere primærnøkkelen og alle ikke-nøkkelattributter som er eksplisitt avhengige av den;
I andre anslag (i i dette tilfellet det er en) ikke-nøkkelattributter som implisitt avhenger av primærnøkkelen vil bli inkludert, sammen med den delen av primærnøkkelen som disse attributtene er eksplisitt avhengig av.
Som et resultat vil to relasjoner oppnås:
Leverandør kode
Produktkode
Mengde
300
400
100
200
300
400
100
Den første relasjonen tilsvarer nå følgende funksjonelle avhengigheter: (Leverandørkode, Produktkode) -> (Antall)
Leverandør kode
By
Bystatus
Moskva
Yaroslavl
Stavropol
Pskov
Den andre relasjonen tilsvarer:
( (Leverandørkode) -> (By),
(Leverandørkode) -> (Status),
(By) -> (Status) )
Denne sammenbruddet eliminerte uregelmessighetene beskrevet ovenfor: det var mulig å legge til informasjon om en leverandør som ennå ikke hadde levert varene, slette informasjon om en leveranse uten å slette informasjon om leverandøren, og enkelt oppdatere informasjon dersom leverandøren flyttet til en annen by.
Definisjon av andre normalform: En relasjon er i andre normalform (forkortet 2NF) hvis og bare hvis den er i første normalform og hver av dens ikke-nøkkelattributter er irreduserbart avhengig av primærnøkkelen.
Semantisk modellering
Den utbredte bruken av relasjonelle DBMS-er og deres bruk i en lang rekke applikasjoner viser at relasjonsdatamodellen er tilstrekkelig for å modellere problemområder. Imidlertid design relasjonsgrunnlag data i form av relasjoner basert på normaliseringsmekanismen vi kort diskuterte er ofte en svært kompleks og upraktisk prosess for designeren.
Samtidig manifesteres begrensningene til relasjonsdatamodellen i følgende aspekter:
Modellen gir ikke tilstrekkelige midler til å representere betydningen av dataene. Semantikken til det reelle fagområdet skal representeres i designerens hode på en modelluavhengig måte. Spesielt er dette knyttet til problemet med å representere integritetsbegrensninger som vi nevnte.
For mange applikasjoner er det vanskelig å modellere domenet ved å bruke flate tabeller. I noen tilfeller på selve det første stadiet design, må designeren tvinge seg selv til å beskrive fagområdet i form av én (muligens til og med ikke-normalisert) tabell.
Selv om hele designprosessen foregår på grunnlag av å ta hensyn til avhengigheter, gir ikke relasjonsmodellen noen midler for å representere disse avhengighetene.
Selv om designprosessen begynner med å identifisere noen domeneobjekter som er essensielle for applikasjonen ("entiteter") og identifisere relasjonene mellom disse enhetene, tilbyr ikke relasjonsdatamodellen noe apparat for å skille enheter og relasjoner.
Behovene til databasedesignere for mer praktiske og kraftige domenemodelleringsverktøy har gitt opphav til trenden med semantiske datamodeller. Gitt at enhver utviklet semantisk datamodell, som en relasjonsmodell, inkluderer strukturelle, manipulasjons- og integrerte deler, er hovedformålet med semantiske modeller å gi muligheten til å uttrykke semantikken til data.
Oftest i praksis brukes semantisk modellering i første fase av databasedesign. I dette tilfellet produseres et konseptuelt databaseskjema i form av den semantiske modellen, som deretter manuelt konverteres til et relasjonsskjema (eller et annet) skjema. Denne prosessen utføres under kontroll av metoder der alle stadier av slik transformasjon er ganske tydelig spesifisert.
Mindre ofte implementert er automatisert kompilering av et konseptuelt skjema til et relasjonsskjema. I dette tilfellet er to tilnærminger kjent: basert på den eksplisitte presentasjonen av det konseptuelle diagrammet som innledende informasjon for kompilatoren og konstruksjonen av integrerte designsystemer med automatisert oppretting av det konseptuelle diagrammet basert på intervjuer med domeneeksperter. I begge tilfeller er resultatet et relasjonsdatabaseskjema i tredje normalform (det ville være mer nøyaktig å si at forfatteren ikke er klar over systemer som gir et høyere nivå av normalisering).
Til slutt, den tredje muligheten, som ennå ikke har gått (eller bare kommer) utover forsknings- og eksperimentelle prosjekter, er å jobbe med en database i en semantisk modell, dvs. DBMS basert på semantiske datamodeller. I dette tilfellet vurderes to alternativer igjen: å gi brukergrensesnitt basert på en semantisk datamodell med automatisk kartlegging av konstruksjoner til en relasjonsdatamodell (dette er en oppgave med omtrent samme kompleksitetsnivå som å automatisk kompilere et konseptuelt databaseskjema til et relasjonsskjema) og en direkte implementering av et DBMS basert på noen semantisk datamodell. Nærmest den andre tilnærmingen er moderne objektorienterte DBMS-er, hvis datamodeller på mange måter er nære semantiske modeller(selv om de er kraftigere i noen aspekter og svakere i andre).
Utvidet ER-modell (EER-modell)
Konseptene til en konvensjonell ER-modell er tilstrekkelig til å representere de fleste databaseskjemaer, slik som de fleste kommersielle databasesystemer. Imidlertid områder som systemer datastyrt design, automatiserte produksjonsklargjøringssystemer osv. stiller mer komplekse krav til databasen. For deres semantiske modellering ble ER-modellen supplert med nye konsepter og transformert til en EER-modell (Enhanced ER model). En slik modell inneholder alle elementene i ER-modellen pluss tilleggsbegreper, nemlig begrepene generalisering, spesialisering og aggregering.
Generalisering er foreningen av et sett med klasser (typer) av enheter til en mer generell type enhet - en superklasse. Hvis det under entitetsanalyse oppdages at to eller flere klasser (typer) av enheter har felles sett med attributter, kan slike klasser kombineres til en superklasse.
Spesialisering er det motsatte av generalisering. Den består i det faktum at en viss generell (aggregert, superklasse) klasse eller type er delt inn i flere mer spesifikke (spesialiserte) underklasser.
Aggregering er prosessen med å kombinere flere uavhengige enheter (typer) til en aggregert (kompleks) type.
Konseptuelle ER-modeller
I henhold til hovedstadiene av databasedesign etter konstruksjon konseptuell modell et databasestyringssystem velges, ved hjelp av hvilket databasen vil bli organisert og arbeide med den. Hver DBMS støtter visse typer og typer data, samt midler for å representere relasjoner mellom dataene som utgjør DBMS-datamodellen. Den andre fasen av databasedesign består av å presentere den konseptuelle modellen bygget på forrige trinn ved å bruke DBMS-datamodellen eller kartlegge den konseptuelle modellen inn i DBMS-datamodellen. Dette stadiet kalles ofte logisk databasedesign. Den resulterende modellen kalles ofte også en konseptuell modell eller skjema, men spesifisert til konseptene til DBMS-datamodellen. I noen kilder kalles den resulterende modellen logisk struktur data eller databasedatamodell.
Konseptet med en DBMS-datamodell kan karakteriseres på forskjellige måter. På den ene siden er en DBMS-datamodell en måte å strukturere data på som anses som en form for abstraksjon isolert fra fagområdet. På den annen side er en DBMS-datamodell et verktøy for å representere den konseptuelle modellen for et fagområde og dynamikken i endringen i form av en database.
Ved å ta hensyn til begge aspektene ovenfor, vil vi definere hovedstrukturene til DBMS-datamodeller som brukes til å representere den konseptuelle modellen for fagområdet (enheter, attributter, relasjoner).
Et dataelement (felt) er den minste navngitte enheten av data. Brukes til å representere verdien av et attributt.
Uløselig knyttet til et dataelement er konseptet "datatype", som det tilsvarende feltet kan akseptere. Kan brukes i forskjellige DBMS-er forskjellige typer data, hvorav de vanligste, brukt i mange DBMS-er, er følgende: numerisk (numerisk), tegn (char), dato (dato), etc.
En post er en navngitt samling av felt. Brukes til å representere en samling av attributter til en enhet (enhetspost).
En postforekomst er en post med spesifikke feltverdier.
En primærnøkkel er minimumssettet med postfelter som unikt identifiserer en forekomst av en filpost.
En fil er en navngitt samling av postforekomster av samme type. Brukes til å representere et homogent sett med enheter.
Et sett med filer er en navngitt samling av filer som behandles i systemet. Brukes til å representere flere sett med enheter.
Konseptet "gruppe" er et generelt konsept for "fil" og "rekord".
En gruppe er en navngitt samling av dataelementer og andre grupper.
Det viktigste begrepet i den konseptuelle modellen er begrepet relasjoner mellom enheter (sett av enheter). I DBMS-datamodeller reflekteres det tilsvarende konseptet av konseptet "grupperelasjon".
En grupperelasjon er en navngitt binær relasjon definert på to sett med forekomster av gruppene som vurderes. Basert på arten av binære relasjoner, skilles gruppeforhold av typen 1:1, 1:M, M:1, M:N. Tallpar kalles gruppeforholdskoeffisienter. I et gruppeforhold er ett medlem av gruppen utpekt som eier av forholdet, og det andre som medlem.
To former brukes for å representere et gruppeforhold:
a) Graf. Grupper er representert av toppunktene på grafen, forbindelsene mellom grupper er representert av buer rettet fra eiergruppen til medlemsgruppen, som indikerer navnet på forholdet og koeffisienten.
Etter type grafer er det:
hierarkisk modell (graf uten sykluser – tre);
nettverksmodell ( rettet graf generelt syn).
b) Tabell. Forholdet mellom grupper er representert av en tabell hvis kolonner representerer nøklene til de tilsvarende gruppene. For å formelt beskrive en tabell, brukes det matematiske (sett-teoretiske) begrepet om en relasjon. Den tilsvarende datamodellen kalles en relasjonsmodell.
Eksempler på ER-modeller
Eksempel 1
ER-modell: Boligkontor
Beskrivelse av oppgaven: Boligkontoransatte trenger en database for å lagre informasjon om forespørsler om reparasjoner mottatt fra beboere. Boligkontoret betjener en gruppe hus, inkludert flere gater. Søknaden kommer fra leiligheten. Søknaden blir akseptert av ekspeditøren, han setter nummeret og datoen for mottak av søknaden, bestemmer søknadstypen og fristen for å fullføre den. Søknaden utføres av et team av spesialister. Hver spesialist kan jobbe i bare ett team; hvert team har en arbeidsleder.
Ris. 10 – Eksempel på en ER-modell av et boligkontor
Eksempel 2
ER- modell av "Horns and Hooves"-kontoret
Beskrivelse av oppgaven: Kontoret «Horns and Hooves» driver kommersiell virksomhet for salg av produkter laget av horn og hover, og yting av magiske tjenester.
En ansatt i organisasjonen har fullt navn, personalnummer og stilling. De ansatte er fordelt på flere avdelinger. Hver avdeling har et nummer, navn og leder. En ansatt kan ikke lede mer enn én avdeling.
Organisasjonen jobber med klientbedrifter. Hver virksomhet har navn og adresse. Det kan inngås flere kontrakter med et foretak.
Kontrakten er preget av et unikt nummer, dato og type. Hver kontrakt er overvåket av en bestemt ansatt. Ettersom varer og tjenester under kontrakten selges til oppdragsgiver, utstedes fakturaer med noen intervaller.
Fakturaen er preget av et unikt nummer, utstedelsesdato, betalingsbetingelse og beløp, samt en liste over solgte varer og tjenester, som angir deres mengde. Straff utmåles på ubetalte fakturaer. Fakturaen kan betales i flere rater, der hver betaling er preget av et nummer, dato og beløp. Betalingsnummeret er unikt på kontoen. Prisene på varer og tjenester kan endres over tid.
Ris. 11 – Eksempel på en ER-modell av "Horns and Hooves"-kontoret
Et eksempel på utvikling av en enkel ER-modell
Ved utvikling av ER-modeller må vi innhente følgende informasjon om fagområdet:
1. Liste over domeneenheter.
2. Liste over enhetsattributter.
3. Beskrivelse av relasjonene mellom enheter.
ER-diagrammer er praktiske fordi prosessen med å identifisere enheter, attributter og relasjoner er iterativ. Etter å ha utviklet den første omtrentlige versjonen av diagrammene, avgrenser vi dem ved å intervjue fageksperter. Samtidig er dokumentasjonen der resultatene av samtalene registreres, selve ER-diagrammene.
La oss anta at vi står overfor oppgaven med å utvikle et informasjonssystem for et bestemt engroshandelsselskap. Først av alt må vi studere fagområdet og prosessene som skjer i det. For å gjøre dette intervjuer vi bedriftens ansatte, leser dokumentasjon, studerer bestillingsskjemaer, fakturaer m.m.
For eksempel, under en samtale med en salgssjef, viste det seg at han (lederen) mener at systemet som designes skal oppfylle følgende handlinger:
Lagre kundeinformasjon.
Skriv ut fakturaer for utgitte varer.
Overvåke tilgjengeligheten av varer på lageret.
La oss velge alle substantivene i disse setningene - disse vil være potensielle kandidater for enheter og attributter, og analysere dem (vi vil fremheve uklare termer med et spørsmålstegn):
Kjøperen er en klar kandidat for enheten.
Fakturaen er en klar kandidat for en enhet.
Produktet er en klar kandidat for enhet
(?) Lager – generelt, hvor mange varehus har bedriften? Hvis det er flere, vil det være en kandidat for en ny enhet.
(?) Tilstedeværelsen av et produkt er mest sannsynlig en egenskap, men en egenskap for hvilken enhet?
En åpenbar sammenheng oppstår umiddelbart mellom enhetene - "kjøpere kan kjøpe mange varer" og "varer kan selges til mange kjøpere." Den første versjonen av diagrammet ser slik ut:
Ris. 12 – Første versjon av ER-diagram
Etter å ha spurt tilleggsspørsmål leder, fant vi ut at selskapet har flere varehus. Dessuten kan hvert produkt lagres i flere varehus og selges fra hvilket som helst lager.
Hvor skal jeg plassere enhetene "Faktura" og "Lager" og hva skal jeg koble dem til? La oss spørre oss selv, hvordan er disse enhetene relatert til hverandre og til enhetene "Kjøper" og "Produkt"? Kjøpere kjøper varer og mottar fakturaer som inneholder data om mengde og pris på de kjøpte varene. Hver kjøper kan motta flere fakturaer. Hver faktura skal utstedes til én kjøper. Hver faktura må inneholde flere varer (det er ingen tomme fakturaer). Hvert produkt kan på sin side selges til flere kjøpere gjennom flere fakturaer. I tillegg må hver faktura utstedes fra et spesifikt lager, og mange fakturaer kan utstedes fra hvilket som helst lager. Derfor, etter avklaring, vil diagrammet se slik ut:
Ris. 12 – Andre versjon av ER-diagrammet
Nå må vi tenke på egenskapene til enheter. Følgende viser seg:
Hver kjøper er en juridisk enhet og har navn, adresse og bankdetaljer.
Hvert produkt har et navn, pris, og er også preget av måleenheter.
Hver faktura har et unikt nummer, utstedelsesdato, en liste over varer med mengder og priser, samt totalbeløpet på fakturaen. Fakturaen utstedes fra et spesifikt lager og til en bestemt kjøper.
Hvert lager har sitt eget navn.
La oss skrive ned alle substantivene som vil være potensielle attributter igjen og analysere dem:
Juridisk enhet er et retorisk begrep, vi ikke jobber med enkeltpersoner. Vi tar ikke hensyn.
Navnet på kjøperen er et tydelig kjennetegn ved kjøperen.
Adressen er et tydelig kjennetegn på kjøperen.
Bankdetaljer er et tydelig kjennetegn ved kjøperen.
Navnet på produktet er en tydelig egenskap ved produktet.
(?) Pris på produktet - det ser ut til at dette er en egenskap ved produktet. Skiller denne egenskapen seg fra prisen på fakturaen?
En måleenhet er en tydelig egenskap ved et produkt.
Fakturanummeret er en tydelig unik egenskap ved fakturaen.
Fakturadatoen er et tydelig kjennetegn ved fakturaen.
(?) Liste over varer i fakturaen - listen kan ikke være et attributt. Du må sannsynligvis dele denne listen i en egen enhet.
(?) Varemengden på fakturaen er en åpenbar egenskap, men en egenskap ved hva? Dette er en egenskap ved ikke bare et "produkt", men et "produkt på fakturaen".
(?) Prisen på produktet i fakturaen - igjen, dette skal ikke bare være en egenskap ved produktet, men en egenskap ved produktet i fakturaen. Men prisen på produktet er allerede sett ovenfor - er det det samme?
Fakturabeløpet er en eksplisitt egenskap ved fakturaen. Denne egenskapen er ikke uavhengig. Fakturabeløpet er lik summen av kostnadene for alle varer som er inkludert i fakturaen.
Navnet på lageret er et tydelig kjennetegn ved lageret.
Hvert produkt har en viss gjeldende pris. Dette er prisen som produktet selges til dette øyeblikket. Naturligvis kan denne prisen endre seg over tid. Prisen på samme produkt i forskjellige fakturaer utstedt i annen tid, kan være annerledes. Dermed er det to priser - prisen på varene i fakturaen og den gjeldende prisen på varene.
Med det nye konseptet "Liste over varer på fakturaen" er alt ganske klart. Enhetene "Faktura" og "Produkt" er knyttet til hverandre ved et mange-til-mange-forhold. Et slikt forhold må deles i to en-til-mange-forhold. Dette krever en ekstra enhet. Denne enheten vil være enheten "Liste over varer i fakturaen". Dens forbindelse med enhetene "Faktura" og "Produkt" er preget av følgende setninger - "hver faktura må ha flere oppføringer fra listen over varer i fakturaen", "hver oppføring fra listen over varer i fakturaen må inkluderes i nøyaktig én faktura", "hvert produkt kan inkluderes i flere oppføringer fra varelisten på fakturaen", "hver oppføring fra varelisten på fakturaen må være knyttet til nøyaktig ett produkt." Attributtene "Antall varer i fakturaen" og "Pris på varene i fakturaen" er attributter til enheten "Liste over varer i fakturaen".
Vi vil gjøre det samme med forbindelsen som forbinder enhetene "Warehouse" og "Product". La oss introdusere en ekstra enhet "Vare på lager". Attributtet til denne enheten vil være "Antall varer på lager". Dermed vil produktet bli oppført på ethvert lager og dets mengde i hvert lager vil være forskjellig.
Nå kan du sette alt dette inn i et diagram:
Ris. 13 – Tredje (endelig) versjon av ER-diagrammet
Bibliografi:
Informasjonssystemer i økonomi: En lærebok for studenter. høyere skoler, institusjoner / V.B. Utkin, K.V. Baldin. – M.: Publishing Center “Academy”, 2004. – 288 s.
Utvikling og drift av automatiserte informasjonssystemer: lærebok. godtgjørelse / Red. prof. L.G. Gagarina. – M.: Forlag “FORUM”: INFRA-M, 2007. – 384 s.: ill. - (Yrkesutdanning).
Dato K. Introduksjon til databasesystemer. – M.: Dialektikk, 2000.
Pershikov V. I., Savinkov V. M. Forklarende ordbok for informatikk. – M.: Finans og statistikk, 2001.
Riordan R. Grunnleggende om relasjonsdatabaser. – M.: Russisk utgave, 2001.
Saukap R. Design av relasjonsdatabasesystemer. – M.: Russisk utgave, 2006.
Database og kunnskapsstyringssystemer / Red. A.N. Naumova. – M.: Finans og statistikk, 2005.
Sportak M., Pappas F. Datanettverk og nettverksteknologier. – Kiev: TID DS LLC, 2002.
Utkin V.B. Grunnleggende om automatisering av profesjonelle aktiviteter. – M.: RDL, 2001.
Utkin V. B., Sazanovich A. N., Mdicharadze V. G. Datavitenskap. – M.: RDL, 2007.
MegaPlus: Elektronikk, datamaskiner, kommunikasjon. 2010. – Nr. 5.
En av de mest populære måtene å formalisere fagområdet for systemer fokusert på å behandle faktainformasjon er "entity-relationship" -modellen, som er grunnlaget for et betydelig antall kommersielle CASE-produkter som støtter hele utviklingssyklusen til databasesystemer eller dets individuelle stadier. Samtidig støtter mange av dem ikke bare stadiet for konseptuell design av fagområdet til systemet som utvikles, men lar også det logiske designstadiet utføres basert på modellen konstruert av deres midler ved automatisk å generere et konseptuelt databaseskjema for det valgte DBMS, for eksempel et databaseskjema for en SQL-server eller objekt DBMS.
Modellering av fagområdet i dette tilfellet er basert på bruk av grafiske diagrammer, inkludert komparativt lite antall komponenter, og viktigst av alt - konstruksjonsteknologi slike diagrammer.
Det semantiske grunnlaget for ER-modellen består av følgende forutsetninger:
den delen av den virkelige verden (et sett med sammenkoblede objekter), informasjon om hvilke som skal plasseres i databasen, kan presentert som helhet enheter;
Hver enhet har karakteristiske egenskaper (attributter) som skiller den fra andre enheter og lar den å identifisere;
Entiteter kan klassifiseres etter enhetstyper: hver forekomst av en enhet (som representerer et objekt) kan klassifiseres Til klasse - enhetstype, hver forekomst har egenskaper som er felles for dem og som skiller dem fra enheter av andre klasser;
klassebasert representasjonssystematisering forutsetter generelt en hierarkisk avhengighet av typer: typeenheten EN er undertype essens I, hvis hver forekomst av typen EN er en forekomst av en enhet av typen I;
forhold mellom objekter kan representeres som forbindelser - enheter, som tjener til å registrere (representere) den gjensidige avhengigheten til to eller flere enheter.
Her bør vi nok en gang understreke konseptets informasjonsmessige karakter essens og dets forhold til materielle eller imaginære objekter i fagområdet. Ethvert emnedomeneobjekt har egenskaper, hvorav noen utmerker seg som karakteristiske - betydningsfulle fra synspunktet til den anvendte oppgaven. I dette tilfellet, for eksempel i prosessen med å analysere og systematisere et fagområde, klasser - en samling av objekter som har samme sett med egenskaper, spesifisert i skjemaet attributtsett(attributtverdier for objekter av samme klasse kan selvfølgelig variere). Følgelig, på representasjonsnivået for fagområdet (dvs. dets infologiske modell), tilsvarer objektet betraktet som et konsept (et objekt i det menneskelige sinnet) konseptet essens; et objekt, som en del av den materielle verden (og eksisterer uavhengig av menneskelig bevissthet), tilsvarer konseptet enhetsforekomst; klassen av objekter tilsvarer konseptet enhetstype.
I det følgende, siden den infologiske modellen ikke tar hensyn til individuelle forekomster av objekter, men klasser, vil vi ikke skille mellom de tilsvarende konseptene til disse to nivåene, dvs. vi vil anta identiteten til konseptene en gjenstand Og enhet, egenskap til et objekt Og eiendom til en enhet.
ER modell, som en beskrivelse av fagområdet må den definere objekter og relasjoner mellom dem, dvs. etablere forbindelser av følgende to typer.
1. Forbindelser mellom objekter og sett med karakteristiske egenskaper, og dermed definere selve objektene.
2. Forbindelser mellom objekter, som definerer naturen og funksjonelle karakteren av deres gjensidige avhengighet.
Som nevnt tidligere er ER-modellering av et fagområde basert på bruk av grafiske diagrammer som en enkel (kjent), visuell og samtidig informativ og flerdimensjonal måte å vise prosjektkomponenter på. Derfor vil presentasjonen av hovedbestemmelsene til ER-modellen bli illustrert med materiale fra et eksempel på et ER-diagram vist i fig. 5.4.
Essens. Enheten som en klasse av lignende objekter er modellert av, er definert som "et objekt som tydelig kan identifiseres." Akkurat som hvert objekt er unikt preget av et sett med egenskapsverdier, må en enhet vær bestemt som dette et sett med attributter, som vil tillate en å skille mellom individuelle forekomster av en enhet. Hver forekomst av en enhet må kunne skilles fra alle andre forekomster av samme enhet (dette kravet ligner på kravet om at det ikke er noen dupliserte tupler i relasjonstabeller). For å for eksempel identifisere hver forekomst av "Ansatt"-enheten unikt, introduseres attributtet "Personnelnummer", som på grunn av sin natur alltid vil ha en unik verdi i bedriften. Det vil si at en unik enhetsidentifikator kan være et attributt, en kombinasjon av attributter, en kombinasjon av relasjoner eller en kombinasjon av relasjoner og attributter som unikt skiller enhver forekomst av enheten fra andre forekomster av samme type enhet.
Enheten har Navn, unik i modellen. Hvori enhetsnavn - Dette skriv navn, og ikke et spesifikt tilfelle.
Enheter er delt inn i sterk Og svak. En enhet er svak hvis dens eksistens avhenger av en annen enhet som er sterk i forhold til den. For eksempel er den underordnede enheten svak mot Til"Ansatt"-enhet: hvis en post som tilsvarer en bestemt ansatt som har underordnede slettes, må også informasjon om underordningen slettes.
Egenskaper. Eiendommens art, hvordan forbindelsens natur egenskaper med en enhet (objekt) kan være forskjellige. La oss se på hovedtypene egenskaper.
Eiendommen kan være flere eller singel - det vil si at et attributt som definerer en egenskap kan samtidig ha flere verdier eller følgelig bare én. For eksempel kan en ansatt ha flere spesialiteter, men den eneste verdien er "Personalnummer".
Eiendommen kan være enkel(ikke gjenstand for ytterligere oppdeling sett fra anvendte oppgaver) eller sammensatt - hvis verdien består av verdier enkle egenskaper. For eksempel er "Fødselsår"-egenskapen enkel, og "Adresse"-egenskapen er kompleks, siden den inkluderer verdiene til de enkle egenskapene "By", "Street", "Hus".
I noen tilfeller er det nyttig å skille grunnleggende Og derivater egenskaper. For eksempel kan en "Leverandør" ha egenskapen "Totalt antall leverte deler", som beregnes ved å summere antall deler den leverer til et prosjekt.
Hvis tilstedeværelsen av en eiendom for alle forekomster av en enhet ikke er obligatorisk, kalles en slik egenskap betinget. For eksempel har ikke alle ansatte egenskapen "akademisk grad".
Eiendomsverdier kan være konstante - statisk eller dynamisk, dvs. endre seg over tid. For eksempel er Personal Number-egenskapen statisk, mens Address-egenskapen er dynamisk. Eiendommen kan være usikker, hvis den er dynamisk, men dens gjeldende verdi er ennå ikke satt.
Eiendommen kan anses som nøkkel, hvis betydningen er unik og, kanskje i en bestemt kontekst, unikt identifiserer enheten. For eksempel en underordnet til en bestemt ansatt.
Tilkoblinger I tillegg til koblingene mellom et objekt og dets egenskaper, reflekterer den infologiske modellen koblingene mellom objekter av ulike klasser. I forbindelse er definert som "en forening som forener flere enheter." Denne assosiasjonen kan alltid eksistere mellom ulike enheter eller mellom en enhet og seg selv (rekursiv assosiasjon).
Som essens er tilkobling typisk konsept, det vil si at alle forekomster av tilknyttede enheter er underlagt reglene for typetilknytning. Den grunnleggende forskjellen i typene forbindelser mellom typer og instanser er illustrert av ER-diagrammer for typer og instanser presentert i fig. 5.5.
Entiteter forent av et forhold kalles deltakere. Grad av tilknytning bestemt av antall kommunikasjonsdeltakere.
Hvis hver forekomst av en enhet deltar i minst én forekomst av et forhold, kalles slik deltakelse av den enheten fullstendig(eller obligatorisk); ellers - ufullstendig(eller valgfri).
Den kvantitative karakteren av deltakelsen av enhetsinstanser (en eller flere) er spesifisert type tilkobling(eller kommunikasjonskraft), Følgende typer er mulige: "en til en"(1:1), "en til mange"(1 millioner), "mange til en"(M:1), "mange til mange"(MM).
Det skal bemerkes at koblingsverktøyet er et middel til å representere komplekse gjenstander, som hver kan betraktes som et sett med noe sammenkoblede enkle gjenstander. Inndelingen i enkle og komplekse objekter, så vel som relasjonens natur, er betinget og bestemmes av særegenhetene ved analysen av fagområdet, dvs. til slutt av arten av bruken av disse objektene i anvendte problemer blir løst. Dessuten, fra synspunktet til for eksempel en designer, er en DETALJ komplekst objekt, og fra leverandørens side – enkelt.
Blant de mange typene relasjoner er slike relasjoner vanligst hierarkisk type, som "del - hel", "slekt - art".
Del-hel forholdet brukes til å representere sammensatte objekter. For eksempel består MASKINER av ENHETER, ENHETER består av DELER. Relasjoner er mulig her "en til mange" så og "mange til mange".
Forholdet "slekt - art" - for representasjon generaliserte objekter. For eksempel er ANSATTE delt inn etter yrke i DESIGNERE, PROGRAMMERE, ARBEIDERE; PROGRAMMERE - inn i APPLIKASJONSPROGRAMMERE og SYSTEMPROGRAMMERE. Hierarkiske forhold, og spesielt "slekt-arter"-forhold, brukes vanligvis som grunnlag for å klassifisere objekter etter sett med karakteristiske trekk. Dessuten "art"-objekter arve"generiske" egenskaper.
En annen mye brukt type forhold er aggregering - å kombinere enkle objekter til komplekse basert på prinsippet om medlemskap enhet eller deres felles deltakelse i en eller annen prosess. Aggregasjon, betraktet her som et mer generelt tilfelle av hierarkiske relasjoner, kombinerer objekter av forskjellig natur med en enkelt felles eiendom " felles deltakelse" Aggregerte objekter navngis vanligvis etter verbale substantiver, for eksempel "Sammensatt": UNDERINNDELING omfatter ANSATTE; "Forsyning": FORSØRGER forsyninger DETALJER.
Supertyper og undertyper. En enhet kan deles i to eller flere som utelukker hverandre undertyper, som hver inkluderer vanlige attributter og/eller relasjoner. Disse vanlige egenskapene og/eller relasjonene er eksplisitt definert en gang høy level. Undertyper kan definere sine egne attributter og/eller relasjoner. I prinsippet kan subtyping fortsette for mer lave nivåer, men i de fleste tilfeller er to eller tre nivåer tilstrekkelig.
Entiteten som undertyper bestemmes på grunnlag av kalles supertype. Undertyper må danne et komplett sett, det vil si at enhver forekomst av en supertype må tilhøre en undertype. Noen ganger, for å fullføre settet, er det nødvendig å definere en ekstra undertype, for eksempel ANDRE.
Undertypen arver egenskapene og relasjonene til supertypen. For eksempel enhetstype PROGRAMMERER er en undertype av enhet ANSATT. Programmerere har alle egenskapene til ansatte og deltar i all kommunikasjon, men det motsatte er ikke sant.
En enhetstype, dens undertyper, undertyper av disse undertypene osv. skjema hierarki av enhetstyper, et eksempel er vist i fig. 5.6.
14. Enhetsrelasjonsmodell (er-modell)
Essens– dette er et objekt i den virkelige verden som kan eksistere uavhengig. Enheten har kopier, som skiller seg fra hverandre i attributtverdier og tillater entydig identifikasjon. Egenskap er en navngitt egenskap ved en enhet. Et attributt som unikt identifiserer forekomster av en enhet kalles nøkkel. Nøkkelen kan være sammensatte, som representerer en kombinasjon av flere attributter.
Forbindelse representerer samspillet mellom enheter. Det er preget strøm (grad av tilkobling), som viser hvor mange enheter som er involvert i forholdet. Forholdet mellom to enheter kalles binær
En viktig egenskap ved kommunikasjon er typekommunikasjon(mangfoldighet). La oss vurdere typene av forbindelsene ovenfor. Siden én leder kun administrerer én filial, er den første relasjonen av en-til-en-typen (1:1).
Siden én filial behandler flere fakturaer, og hver faktura behandles av kun én filial, er den andre relasjonen en en-til-mange (1:M)-relasjon.
Siden én konto kan deles av flere kunder og én kunde kan ha flere kontoer, er den tredje relasjonen et mange-til-mange (M:N)-forhold.
Grad av deltakelse bestemmer om alle eller bare noen forekomster av en enhet er involvert i forholdet. Det kan hun være påbudt, bindende eller valgfri.
Hvis ikke hver forekomst av enhet A er assosiert med noen forekomst av enhet B, er graden av deltagelse av enhet A valgfri. Dette er representert på ER-diagrammet av en svart sirkel plassert på kommunikasjonslinjen nær enhet A.
Hvis hver forekomst av enhet A er assosiert med en forekomst av enhet B, er graden av deltagelse av enhet A påbudt, bindende. I dette tilfellet, på ER-diagrammet, er en svart sirkel på kommunikasjonslinjen plassert i et rektangel ved siden av enhet A. For eksempel kommunikasjon Ansatt registrerer klienter har type (1:M). I dette tilfellet registrerer ikke alle ansatte klienter (valgfri deltakelse), men hver klient registreres av en ansatt (obligatorisk deltakelse):
Hver av de fire modellenhetene kan beskrives med sitt eget sett med attributter.
|
SJEF | ||
|
Managernummer (NM) |
Filialnummer (NF) |
|
|
Arbeidserfaring (STAGE) |
Filialadresse (ADR_F) |
|
|
Spesialitet (SPESIAL) | ||
|
Kundenummer (NC) |
||
|
Kontonummer (NA) |
FULLT NAVN. klient (fullt navn_K) |
|
|
Kontotype (TYPE) |
Klientadresse (ADR_K) |
|
|
Kontosaldo (BT) |
Sosial status (SOC_P) |
En ER-modell, sammen med sett med enhetsattributter, kan tjene som et eksempel på en semantisk (konseptuell) modell av et domene eller et konseptuelt databaseskjema.
Før du begynner å lage et automatisert informasjonsbehandlingssystem, må utvikleren danne konsepter om objektene, fakta og hendelser han vil operere med dette systemet. For å bringe disse konseptene til en eller annen datamodell, er det nødvendig å erstatte dem med informasjonsrepresentasjoner. En av de mest praktiske verktøy enhetlig datarepresentasjon, uavhengig av implementer programvare, er en enhet-relasjonsmodell (ER - modell).
Entitetsrelasjonsmodellen er basert på viktig semantisk informasjon om den virkelige verden og er ment å representere data logisk. Den definerer betydningen av data i sammenheng med deres forhold til andre data. Viktig for oss er det faktum at alle eksisterende datamodeller (hierarkiske, nettverk, relasjonelle, objekt) kan genereres fra "entity-relationship"-modellen, så den er den mest generelle.
"Entity-relationship"-modellen ble foreslått i 1976 av Peter Ping-Sheng Chen; den russiske oversettelsen av artikkelen hans "The "Entity-relationship"-modellen - et skritt mot en enhetlig datarepresentasjon" ble publisert i tidsskriftet "DBMS" nr. 3, 1995.
Datavisninger på flere nivåer
Når du studerer en datamodell, bør du identifisere nivåene av logisk representasjon av data som denne modellen relaterer seg til. Ved å utvide settet med bestemmelser kan vi definere fire nivåer av datapresentasjon:
Informasjon knyttet til enheter og forbindelser som eksisterer i vår fantasi; - informasjonsstruktur - organisering av informasjon der enheter og relasjoner er representert av data. - datastruktur uavhengig av tilgangsveier - datastrukturer som ikke er assosiert med søk, indeksering, etc. ordninger. - datastruktur avhengig av tilgangsveier.
Figur 1. Analyse av datamodeller ved hjelp av flere lag med logiske visninger
Informasjon om enheter og relasjoner
På dette nivået vurderer vi enheter og relasjoner. En enhet er et objekt som kan identifiseres på en måte som skiller det fra andre objekter. Eksempler på en enhet er spesiell person, selskap eller arrangement. Et forhold er en assosiasjon etablert mellom enheter. For eksempel er far-sønn en forbindelse mellom to menneskelige enheter.1)
En virksomhetsdatabase inneholder informasjon om enheter og relasjoner som er av interesse for den virksomheten. Kan ikke legges inn i firmadatabasen Full beskrivelse enheter eller forbindelser. Det er ikke mulig (og sannsynligvis ikke nødvendig) å lagre all potensielt tilgjengelig informasjon om enheter og relasjoner. Deretter vil vi kun vurdere de enhetene og relasjonene (og informasjon om dem) som bør inkluderes i databaseprosjektet.
Entitet og mange enheter
La e betegne en enhet som eksisterer i fantasien vår. Hver enhet tilhører et bestemt enhetssett, for eksempel ANSAT, PROSJEKT eller AVDELING. Hvert sett med enheter er knyttet til et predikat som lar deg sjekke om en gitt enhet tilhører dette settet. For eksempel, hvis vi vet at en enhet tilhører enhetssettet ANSAT, så vet vi også at denne enheten har egenskaper til felles med andre enheter i enhetssettet ANSAT. Disse egenskapene inkluderer predikatet nevnt ovenfor. La Ei betegne settet med enheter. Merk at sett med enheter ikke trenger å være usammenhengende. For eksempel, en enhet som tilhører MALE-PERSON-enhetssettet, tilhører også PERSON-enhetssettet. I dette tilfellet er MALE-PERSON en undergruppe av PERSON.
Tilknytning, rolle og mange sammenhenger.
La oss vurdere enhetsforeninger. Et relasjonssett Ri er et matematisk forhold mellom n enheter, som hver tilhører et visst sett med enheter:
( | e1 ∈ E1, e2 ∈ E2, ..., en ∈ En), og hver tuppel av enheter, , er et forhold. Merk at i denne definisjonen trenger ikke Ei å være distinkte sett. Ekteskap er for eksempel et forhold mellom to enheter fra PERSON-enhetssettet.
Rollen til en enhet i et forhold er funksjonen som enheten utfører i et gitt forhold. Mann (ektemann) og kone (kone) er roller. Rekkefølgen av enheter i definisjonen av forholdet (merk at hakeparenteser ble brukt) kan være fraværende hvis rollene til enhetene er eksplisitt angitt i forholdet: (r1/e1, r2/e2 ,..., rn/en ), hvor ri er rollen til enhet ei i denne forbindelse.
Attributt, verdi og sett med verdier.
Informasjon om en enhet eller et forhold innhentes gjennom observasjon eller måling og uttrykkes som et sett med attributt-verdi-par. 3, red, Peter og Johnson er verdiene. Verdier er klassifisert i ulike verdisett, for eksempel FEET, COLOR, FIRST-NAME og LAST-NAME. Hvert sett med verdier har et predikat knyttet til seg for å teste om verdien tilhører det settet. En verdi fra et sett med verdier kan være ekvivalent med en annen verdi fra et annet sett med verdier. For eksempel tilsvarer 12 i INCH-verdisettet 1 i FEET-verdisettet.
Et attributt kan formelt defineres som en funksjon som kartlegger et sett med enheter eller et sett med relasjoner til et sett med verdier eller et kartesisk produkt av sett med verdier:
f: Ei eller Ri → Vi eller Vi1 × Vi2 × ... × Vin I fig. Figur 2 viser flere attributter definert på PERSON-enhetssettet. AGE-attributtet tilordnes verdien satt til NO-OF-YEARS. Attributtet kan spesifisere tilordningen av sett med verdier til et kartesisk produkt. For eksempel spesifiserer NAME-attributtet visningen av FIRST-NAME- og LAST-NAME-verdiene i settet. Merk at flere attributter kan tilordne samme enhetssett til samme verdisett (eller samme gruppe med verdisett). For eksempel spesifiserer attributtene NAME og ALTERNATIVE-NAME en tilordning fra ANSATTE-enheten til verdisettene FORNAVN og EFTERNAVN. Dermed er et attributt og et verdisett forskjellige konsepter, selv om de i noen tilfeller kan ha samme navn (for eksempel spesifiserer EMPLYEE-NO-attributtet en tilordning fra ANSAT til et verdisett ANSATTE-NR - ANSAT)). Denne forskjellen er ikke tydelig i nettverksmodell og i mange eksisterende databehandlingssystemer. Merk også at attributtet er definert som en funksjon. Derfor vises den denne enheten til én verdi (eller én tuppel av verdier i tilfelle av et kartesisk produkt av sett med verdier).
Ris. 2. Attributter definert på settet med PERSON-enheter
Merk at tilkoblinger også har attributter. La oss vurdere settet med PROJECT-WORKER-forbindelser (fig. 3). PROSJEKT-AV-TID-attributtet, som representerer andelen av tiden som er allokert til en bestemt ansatt på et bestemt prosjekt, er et attributt som er definert på PROSJEKT-ARBEIDERE-relasjonssettet. Det er verken et attributt til ANSATTE-enheten eller et attributt til PROSJEKT-enheten, siden betydningen avhenger av både den ansatte og prosjektet. Konseptet med en relasjonsattributt er viktig for å forstå semantikken til data og definere funksjonelle avhengigheter mellom data.
Ris. 3. Attributter definert på settet med PROJECT-WORKER-tilkoblinger
Konseptuell struktur av informasjon.
Vi vil nå diskutere hvordan informasjon om enheter og relasjoner kan organiseres. Denne artikkelen foreslår en metode for å skille enhetsinformasjon og relasjonsinformasjon. Vi vil vise at denne separasjonen er nyttig for å identifisere funksjonelle avhengigheter mellom data.
I fig. 4 viser informasjon om enhetene i enhetssettet i tabellform. Hver rad med verdier refererer til den samme enheten, og hver kolonne refererer til et sett med verdier, som igjen refererer til et attributt. Rekkefølgen på rader og kolonner er ikke signifikant.
Ris. 4. Informasjon om enheter fra et sett med enheter (tabellform)
Ris. 5. Informasjon om forbindelser fra et sett med forbindelser (tabellform)
I fig. 5 viser informasjon om forbindelsene i settet med forbindelser. Merk at hver rad med verdier refererer til et forhold som er indikert av en gruppe enheter, som hver har en spesifikk rolle og tilhører et spesifikt enhetssett.
Merk at i fig. Figurene 4 og 2 (og også figurer 5 og 3) viser forskjellige former for samme informasjon. Tabellskjemaet brukes for å lette koblingen til relasjonsmodellen.
Informasjonsstruktur
Entiteter, relasjoner og betydninger på nivå 1 (se figur 2-5) er konseptuelle objekter som eksisterer i fantasien vår (dvs. vi var i det konseptuelle riket). På nivå 2 tar vi for oss representasjoner av konseptuelle objekter. Vi antar at det er direkte representasjoner av mening. Deretter beskriver vi hvordan enheter og relasjoner kan representeres.
Primærnøkkel.
I fig. 2 ANSATTE-NO attributtverdier kan brukes til å identifisere enheter i ANSATTE-enhetssettet hvis hver ansatt har et unikt ansattnummer. Du kan trenge mer enn ett attributt for å identifisere enheter i et enhetssett. Det er også mulig at flere attributtgrupper vil bli brukt til å identifisere enheter. I hovedsak er en enhetsnøkkel en gruppe attributter slik at tilordningen fra et enhetssett til en tilsvarende gruppe verdisett er en en-til-en-tilordning. Hvis en slik kartlegging ikke kan finnes i tilgjengelige data, eller hvis enkel objektidentifikasjon er ønskelig, kan et attributt- og verdisett kunstig defineres for å oppnå en en-til-en kartlegging. Når det finnes flere nøkler, velges vanligvis den semantisk meningsfulle nøkkelen som enhetens primærnøkkel. primærnøkkel– PK).
Ris. 6. Representasjon av enheter etter verdier (ansattnummer)
Ris. 6 ble oppnådd ved å slå sammen settet med ANSATTE-enheter med settet med ANSATTE-NO-verdier fra fig. 2. La oss ta hensyn til noen semantiske konsekvenser av fig. 6. Hver verdi i ANSATTE-NR-verdisettet representerer en enhet (ansatt). Attributter spesifiserer tilordningen fra ANSATTE-NR-verdisettet til andre verdisett. Vær også oppmerksom på at attributtet EMPLOYEE-NO spesifiserer tilordningen av et sett med EMPLOYEE-NO-verdier i seg selv.
Entitets-/relasjonsforhold.
Informasjon om enhetene i enhetssettet kan nå organiseres i skjemaet vist i figur. 7. Merk at fig. 7 er lik fig. 4, bortsett fra at entiteter er representert av verdiene til deres primærnøkler. Hele tabellen er på fig. 7 representerer en enhetsrelasjon, og hver rad representerer en enhets-tuppel.
I noen tilfeller kan ikke enheter i et enhetssett identifiseres unikt med sine egne attributtverdier; derfor må vi bruke relasjoner for å identifisere dem. Vurder for eksempel de avhengige og støttende enhetene: underordnede identifiseres ved navn og de primære nøkkelverdiene til deres overordnede (dvs. ved deres forhold til de ansatte). Merk at i fig. 9 ANSAT-NR er ikke et attributt for enheter i AVHENGIG-settet, men representerer primærnøkkelen til ansatte som har underordnede. Hver linje med verdier i fig. 9 er en tuppel av enheter med ANSATTE-NR og NAVN som primærnøkler. Hele tabellen er en enhetsrelasjon.
I teorien kan enhver type relasjon brukes til å identifisere enheter. For enkelhets skyld vil vi begrense oss til kun én type relasjon: binære relasjoner med en 1:n-kartlegging, der eksistensen av n enheter på den ene siden av relasjonen avhenger av eksistensen av en enhet på den andre siden av relasjonen. . For eksempel kan en ansatt ha n (n = 0, 1, 2,...) underordnede, og eksistensen av de underordnede avhenger av eksistensen av den tilsvarende overordnede ansatt.
Denne metoden for å identifisere enheter ved relasjoner til andre enheter kan brukes rekursivt inntil enheter som kan identifiseres med verdiene til deres egne attributter oppstår. For eksempel kan en bedrifts avdelings primærnøkkel bestå av avdelingsnummeret og avdelingens primærnøkkel, som igjen består av avdelingsnummeret og firmanavnet.
Følgelig har vi to former for enhetsrelasjoner. Hvis relasjoner brukes til å identifisere enheter, vil vi kalle dette en svak enhetsrelasjon (Figur 9). Hvis relasjoner ikke brukes til å identifisere enheter, vil vi kalle det en vanlig enhetsrelasjon (Figur 8). Hvis noen enheter i en relasjon identifiseres av andre relasjoner, vil vi kalle dette en svak relasjonsrelasjon. For eksempel vil alle relasjoner mellom AVHENGIGE enheter og andre enheter resultere i svake assosiasjonsforhold fordi den AVHENGE enheten identifiseres ved sitt navn og forhold til den ANSATTE enheten. Å skille mellom vanlige og svake enhetsrelasjoner og relasjoner vil være nyttig for å opprettholde dataintegriteten.
