ER-databasemodell
Entity-relationship-modellen (ERM, ER-modellen) lar deg beskrive konseptuelle skjemaer fagområde.
ER-modellen brukes i databasedesign på høyt nivå. Med dens hjelp er det mulig å fremheve nøkkelenhetene og utpeke forbindelsene som kan etableres mellom disse enhetene. ER-modellen er en formell konstruksjon som ikke definerer grafikk presentasjonen hennes. Som en standard grafisk representasjon av ER-modellen er Entity Relationship Diagram (ER) utviklet. Ved utforming av databaser konverteres ER-modellen til et spesifikt databaseskjema.
Som kjent, grunnleggende konsept en relasjonsdatabase er en tabell (relasjon). Tabellen brukes til å strukturere og lagre informasjon. I relasjonsdatabaser inneholder hver celle i en tabell én verdi. I tillegg, innenfor samme database, er det relasjoner mellom tabeller, som hver spesifiserer deling av tabelldata.
ER-diagram viser grafisk datastrukturen til den utformede databasen. Entiteter vises ved hjelp av rektangler, tabeller som inneholder enhetsnavnet - databasetabeller. Entitetsrelasjoner vises som linjer som forbinder individuelle enheter.
Et forhold indikerer at data fra en enhet er referert til eller koblet til data fra en annen.
Graden av slutten av lenken er indikert grafisk, mangfoldet av lenken er avbildet som en "gaffel" på slutten av lenken. Lenkemodaliteten vises også grafisk - den valgfrie lenken er merket med en sirkel på slutten av lenken. Navngivningen av en sammenheng er uttrykt i ett verb (fig. 13).
Fig. 13.
Egenskaper enheter er skrevet innenfor et rektangel som representerer enheten og uttrykkes som et entallssubstantiv.
Enhetsnøkkelen er uthevet blant attributtene. Når du oppretter en enhet, er det nødvendig å velge en gruppe attributter som kan være en primærnøkkel, og deretter velge attributtene som skal inkluderes i primærnøkkel:
· Primærnøkkelen bør velges på en slik måte at verdiene til attributtene som er inkludert i den, nøyaktig kan identifisere enhetsforekomsten.
· Ingen av primærnøkkelattributtene må ha en nullverdi.
· Verdiene til primærnøkkelattributtene må ikke endres. Hvis verdien har endret seg, er dette allerede en annen forekomst av enheten.
Når du velger en primærnøkkel, introduseres som regel et ekstra attributt i enheten, som blir nøkkelen.
Så, for å bestemme primærnøkkelen, brukes ofte unike tall, som kan genereres automatisk av systemet når en enhetsforekomst legges til databasen. applikasjon unike rom forenkler prosessen med å indeksere og søke i databasen.
Det første trinnet i å skape logisk modell Databasen er konstruksjonen av et ER-diagram, bestående av tre deler: enheter, attributter og relasjoner.
Mange verktøy for visuell oppretting av ER - diagrammer er utviklet for ulike plattformer. Dette prosjektet brukte utviklingen MySQL arbeidsbenk.
Dette verktøyet forenkler databasedesign og vedlikehold, automatiserer tidkrevende og feilutsatte oppgaver, og forbedrer kommunikasjonen mellom utviklingsteam og databasearkitekter. Det lar dataarkitekter visualisere krav, kommunisere med interessenter om designspørsmål før de investerer i et prosjekt. Det gir modelldrevet databasedesign, som er den mest effektive metodikken for å lage ekte og gjennomtenkte databaser. ER - systemdatabasediagram fjerntesting (kontroll_tester) er vist på figuren (fig. 14). To vertikale streker på den ene siden og en "trident" på den andre betegner henholdsvis et "en-til-mange-forhold".
Ris. fjorten. ER - control_test databasediagram over det eksterne testsystemet
Databasenormalisering
V relasjonell teori Det finnes ingen universelle resepter eller lover for å utforme en pålitelig, en gang for alle database. Utviklere velger sine databasedesignbeslutninger basert på erfaring, intuisjon, ulike designverktøy og -teknikker.
Likevel, noen kanoner, regler eksisterer. Disse reglene inkluderer normaliseringsregler, dvs. bringe forhold til normal form.
ER-diagrammer (Figur 2) brukes til å designe data og er en standard måte å definere data og relasjonene mellom dem. Dermed blir granulariteten til datavarehus utført. Et ER-diagram inneholder informasjon om enhetene i systemet og hvordan de samhandler, inkluderer identifisering av objekter som er viktige for domenet (entitetene), egenskapene til disse objektene (attributtene) og deres forhold til andre objekter (lenker). I mange tilfeller er informasjonsmodellen svært kompleks og inneholder mange objekter.
Ris. 2. Et eksempel på et ER-diagram
En enhet vises som et rektangel med enhetsnavnet øverst (for eksempel TITLER). Attributtene til enheten kan vises i rektangelet; attributtene til ER-diagrammer i fet skrift1 er nøkkelen (så Tittelidentitet er nøkkelattributtet til TITLES-enheten, resten av attributtene er ikke nøkkel).
Forholdet er avbildet med en linje mellom to enheter (blå linjer i figuren).
Den enkle linjen til høyre (Figur 3) betyr én, fuglens fot til venstre betyr mange, og forholdet leses langs linjen, for eksempel en-til-mange. Den vertikale linjen betyr "obligatorisk", sirkelen betyr "valgfritt", for eksempel for hver utgave i TITTEL, må forlaget i PUBLISHERS angis, og ett forlag i PUBLISHERS kan gi ut flere titler på publikasjoner i TITLES. Det skal bemerkes at lenkene alltid kommenteres (påskriften på linjen som representerer lenken).
Ris. 3. ER-diagramelement
Vi vil også gi et eksempel (fig. 4) på bildet av den refleksive holdningen «ansatt», der én ansatt kan styre flere underordnede, og så videre nedover i posisjonshierarkiet.
Det skal bemerkes at et slikt forhold alltid er valgfritt, i ellers det vil være et endeløst hierarki.
Ris. 4. ER-diagram av en refleksiv holdning
Entitetsattributter kan være nøkkelen - de er i fet skrift; obligatorisk - de er innledet med et "*"-tegn, det vil si at verdien deres alltid er kjent, valgfri - en O er plassert foran dem, det vil si at verdiene til denne attributten i noen øyeblikk kan være fraværende eller udefinerte .
Hvis en enhet har et sett med gjensidig utelukkende relasjoner med andre enheter, sies slike relasjoner å være i en bue. For eksempel kan en bankkonto utstedes enten for en juridisk person, eller for naturlig person... Et fragment av ER-diagrammet for denne typen forhold er vist i fig. 5.
Ris. 5. Bue
I dette tilfellet har attributtet OWNER av ACCOUNT-enheten en spesiell betydning for denne enheten - enheten er delt inn i typer i henhold til kategoriene: "for et individ" og "for juridisk enhet". De resulterende enhetene kalles undertyper, og opprinnelige enhet blir en supertype. For å forstå om du trenger en supertype eller ikke, må du fastslå hvor mange av de samme egenskapene ulike undertyper har. Det skal bemerkes at det er en ganske vanlig feil å overbruke undertyper og supertyper. De er avbildet som vist i fig. 6.
Ris. 6. Undertyper (høyre) og supertype (venstre)
formålet med arbeidet
Kjennskap til metodene og algoritmen for å lage «Entity-relationship»-modellen.
Grunnleggende konsepter for "Entity-relationship"-modellen. ER-modeller.
Den infologiske modellen brukes på andre trinn av databasedesign, etter den verbale beskrivelsen av fagområdet. Den bør inneholde en formalisert beskrivelse av fagområdet som er lett å «lese» av både databasespesialister og alle brukere. Denne beskrivelsen skal være så omfattende at det er mulig å vurdere dybden og riktigheten av utviklingen av databasedesignet, og den skal selvfølgelig ikke være knyttet til et spesifikt DBMS. Valget av et DBMS er en egen oppgave, for riktig løsning er det nødvendig å ha et prosjekt som ikke er knyttet til noen spesifikk DBMS.
Infologisk design er først og fremst assosiert med et forsøk på å representere fagområdets semantikk i en databasemodell, noe som er dårlig reflektert i nettverk, hierarkiske datamodeller.
Flere datamodeller har blitt foreslått, kalt semantiske modeller. Alle disse modellene hadde sine positive og negative sider, men bare enhet-relasjonsmodellen, eller Entity Relationships, ble de facto-standarden i infologisk databasemodellering. Det forkortede navnet ER-modellen har blitt allment akseptert, og de fleste moderne CASE-verktøy inneholder verktøyå beskrive data i formalismen til denne modellen. I tillegg er det utviklet metoder for automatisk å konvertere et databasedesign fra en ER-modell til en relasjonsdatabase, samtidig som man konverterer til en modell av et spesifikt DBMS. Alle CASE-systemer har utviklet verktøy for å dokumentere utviklingsprosessen, automatiske rapportgeneratorer lar deg utarbeide en rapport på nåværende tilstand prosjekt med en detaljert beskrivelse av databaseobjektene og deres relasjoner, noe som i stor grad letter vedlikeholdet av prosjektet.
Som enhver modell har enhet-relasjonsmodellen flere grunnleggende konsepter hvorfra flere komplekse gjenstander i henhold til forhåndsdefinerte regler. Denne modellen er mest konsistent med konseptet objektorientert design, som er grunnleggende for utvikling av komplekse programvaresystemer.
La oss se på de grunnleggende konseptene bak ER-modellen.
1... Essens, ved hjelp av hvilken en klasse av objekter av samme type modelleres. En enhet har et navn som er unikt i det modellerte systemet. Siden en enhet tilsvarer en bestemt klasse av objekter av samme type, antas det at det er mange forekomster av denne enheten i systemet. Et objekt som tilsvarer begrepet en enhet har sitt eget sett egenskaper - egenskaper som definerer egenskapene til denne klasserepresentanten. I dette tilfellet må settet med attributter være slik at det er mulig å skille mellom spesifikke forekomster av enheten. For eksempel enheten Ansatt det kan være følgende sett med attributter: Personalnummer, Etternavn, Fornavn, Patronym, Fødselsdato, Antall barn, Tilstedeværelse av slektninger i utlandet. Settet med attributter som unikt identifiserer en spesifikk forekomst av en enhet kalles nøkkel. For Ansatt-enheten vil nøkkelattributtet være Personalnummeret, siden personellnummer er forskjellige for alle ansatte i den gitte virksomheten. En enhetsforekomst Ansatt det vil være en beskrivelse av en bestemt ansatt i virksomheten. En av de generelt aksepterte grafiske betegnelsene til en enhet er et rektangel, øverst på denne er navnet på enheten skrevet, og attributtene nedenfor er oppført, og nøkkelattributtene er merket for eksempel med en understreking eller spesiell skrift. , som vist under:
2. Mellom enheter kan etableres kommunikasjon - binære assosiasjoner , viser hvordan enheter forholder seg til eller samhandler med hverandre. En forbindelse kan eksistere mellom to forskjellige enheter eller mellom en enhet og seg selv (rekursiv lenke). Den viser hvordan enhetsforekomster er relatert til hverandre. Hvis et forhold etableres mellom to enheter, definerer det forholdet mellom forekomster av den ene og den andre enheten. For eksempel, hvis det er en relasjon mellom enheten "Student" og enheten "Lærer" og dette forholdet er ledelsen av hovedfagsprosjekter, så har hver student bare én leder, men den samme læreren kan lede mange hovedfagsstudenter. Derfor vil det være en en-til-mange-relasjon (1:M), en fra «Lærer»-siden og mange fra «Student»-siden (Fig. 10.1.).
3. I forskjellige notasjoner er kraften til forbindelsen avbildet på forskjellige måter. I det betraktede eksemplet er multiplisiteten avbildet ved å dele kommunikasjonslinjen med 3. Forholdet har et felles navn "Graduate Design" og har navn på roller fra begge enhetene. Fra elevens side kalles denne rollen «Gjør prosjektet under regi», fra instruktørens side kalles denne relasjonen «Leading». Den grafiske tolkningen av forholdet lar deg umiddelbart lese betydningen av forholdet mellom enheter, det er visuelt og lett å tolke. Relasjoner er delt inn i tre typer i henhold til deres mangfold: en til en (1:1), en-til-mange(1 millioner), mange-til-mange(MM). En en-til-en-relasjon betyr at en forekomst av én enhet er assosiert med bare én forekomst av en annen enhet. Relasjon 1: M betyr at en enhetsforekomst plassert til venstre for forholdet kan assosieres med flere forekomster av enheten lokalisert til høyre for forholdet. En mange-til-mange (M:M)-relasjon betyr at én forekomst av den første enheten kan assosieres med flere forekomster av den andre enheten, og omvendt, én forekomst av den andre enheten kan assosieres med flere forekomster av den første enhet. For eksempel er et forhold av typen "Lærer" mellom enhetene "Student" og "Disiplin" et forhold av typen "mange-til-mange" (M:M), siden hver student kan studere flere disipliner, og hver disiplin studeres av mange studenter. Dette forholdet er vist i fig. 10.2.
4. Et hvilket som helst antall forbindelser med forskjellige semantiske belastninger kan settes mellom to enheter. For eksempel, mellom to enheter "Student" og "Lærer", kan det etableres to semantiske forbindelser, den ene er den tidligere ansett som "Graduate Design", og den andre kan konvensjonelt kalles "Forelesninger", og den bestemmer hvilke forelesninger av hvilke lærere en gitt student lytter og som denne læreren holder forelesninger for studenter. Det er tydelig at dette er en sammenheng av typen mange-til-mange.
5. Kommunikasjon av noen av disse typene kan være påbudt, bindende, hvis hver forekomst av enheten må delta i denne forbindelse, og valgfri- hvis ikke alle forekomster av enheten bør delta i dette forholdet. I dette tilfellet kan forbindelsen være obligatorisk på den ene siden og valgfritt på den annen side. Obligatorisk kommunikasjon er også betegnet på forskjellige måter i forskjellige notasjoner. Den valgfrie lenken kan angis med en tom sirkel på slutten av lenken, og den obligatoriske med en vinkelrett linje som krysser lenken. Og denne notasjonen har en enkel tolkning. Sirkelen gjør at ingen instans kan delta i denne forbindelse. Og perpendikulæren tolkes som det faktum at minst én forekomst av enheten deltar i dette forholdet.
I det tidligere eksemplet av Graduate Engineering-forholdet tolkes dette forholdet som valgfritt på begge sider. Faktisk bør hver student som tar et diplom ha sin egen diplomdesignveileder, men på den annen side er det ikke alle lærere som utfører diplomdesign. Derfor, i denne semantiske innstillingen, vil bildet av denne forbindelsen endre seg og vil se ut som vist i fig. 10.3.
Som et resultat av å bygge en domenemodell i form av et sett med enheter og relasjoner, får vi en sammenhengende graf. I den resulterende grafen er det nødvendig å unngå sykliske forbindelser - de avslører feilen til modellen.
Et eksempel på å lage en ER-modell
Vi skal designe en infologisk modell av et system designet for å lagre informasjon om bøker og kunnskapsområder som presenteres i biblioteket. La oss begynne å utvikle modellen ved å fremheve hovedenhetene.
Først og fremst er det essensen av "Boken"; hver bok har et unikt chiffer, som er dens nøkkel, og en rekke attributter som er hentet fra beskrivelsen av fagområdet. Mange forekomster av en enhet definerer de mange bøkene som er lagret i biblioteket. Hver forekomst av "Bøker"-enheten tilsvarer ikke en spesifikk bok på hyllen, men til en beskrivelse av en bestemt bok, som vanligvis er gitt i fagkatalogen til biblioteket. Hver bok kan finnes i flere eksemplarer, og dette er bare de spesifikke bøkene som står i hyllene på biblioteket. For å reflektere dette bør enheten Instances introduseres, som skal inneholde beskrivelser av alle bokforekomstene som er lagret i biblioteket. Hver forekomst av Instances-enheten tilsvarer en bestemt bok på hyllen. Hvert eksemplar har et unikt inventarnummer som unikt identifiserer en spesifikk bok. I tillegg kan hvert eksemplar av boken enten være på biblioteket eller i hendene på en leser, og i sistnevnte tilfelle, for dette tilfellet datoen for å ta boken av leseren og datoen for forventet retur av boken er angitt i tillegg.
Det er et forhold (1:M) mellom enhetene "Bøker" og "Forekomster", som er obligatorisk på begge sider. Hva bestemmer gitt type kommunikasjon? Hver bok kan være tilstede i biblioteket i flere eksemplarer, derfor - 1:M-forholdet. Dessuten, hvis biblioteket ikke har en eneste kopi av denne boken, vil vi ikke lagre beskrivelsen, derfor, hvis boken er beskrevet i essensen av "Bøker", så av i det minste det er ett eksemplar av denne boken på biblioteket, noe som betyr at fra bokens side er kommunikasjon obligatorisk. Når det gjelder enheten "Forekomster", kan det ikke være en enkelt forekomst i biblioteket som ikke tilhører en bestemt bok, derfor er forholdet også obligatorisk på "Forekomster"-siden.
Nå er det nødvendig å definere hvordan leseren skal presenteres i systemet. Det er naturlig å foreslå å introdusere enheten "Lesere", som hver forekomst vil tilsvare en bestemt leser. I biblioteket er hver leser tildelt et unikt lånekortnummer, som identifiserer leseren unikt. Lånekortnummeret vil være et nøkkelattributt for Readers-enheten. I tillegg, i «Lesere»-enheten, må ytterligere attributter være tilstede som kreves for å løse de tildelte oppgavene; disse attributtene vil være: "Etternavn Fornavn Patronymic", "Leserens adresse", "Hjemmetelefon" og "Arbeidstelefon". I tillegg bør du i Readers-enheten angi attributtet Date of Birth for å kontrollere alderen til leserne.
Hver leser kan holde flere eksemplarer av bøker. For å gjenspeile denne situasjonen bør det trekkes et forhold mellom enhetene "Lesere" og "Forekomster", siden leseren tar fra biblioteket en spesifikk kopi av en bestemt bok, og ikke bare en bok. Og du kan finne ut hvilken bok en gitt leser har etter ekstra kommunikasjon mellom enhetene "Forekomster" og "Bøker", og dette forholdet tildeler én bok til hver forekomst, slik at det alltid er mulig å entydig bestemme hvilke bøker som er i hendene på leseren, selv om vi kun knytter inventarnumrene til bøkene som er tatt. med leseren. En 1:M-relasjon etableres mellom enhetene "Lesere" og "Forekomster", og samtidig er det ikke obligatorisk på begge sider. Leseren for øyeblikket holder kanskje ikke en eneste bok i hendene, og på den annen side kan dette eksemplaret av boken ikke være i noen lesers besittelse, men bare stå i hyllen i biblioteket.
Nå skal gjenspeile den siste enheten knyttet til systemkatalogen, som inneholder en liste over alle kunnskapsområder, informasjon om hvilke finnes i bibliotekets bøker. Navnet på kunnskapsområdet kan være langt og bestå av flere ord, derfor vil vi, for å modellere systemkatalogen, introdusere enheten "Systemkatalog" med to attributter: "Kunnskapsområdekode" og "Kunnskapsområdenavn". Attributtet Knowledge Area Code vil være nøkkelattributtet til enheten.
Det er kjent fra beskrivelsen av fagområdet at hver bok kan inneholde informasjon fra flere kunnskapsområder, og på den annen side kan biblioteket inneholde mange bøker knyttet til samme kunnskapsområde, derfor er det nødvendig å sette mellom enhetene "Systemkatalog" og "Bøker" forbindelse M: M, bindende på begge sider. Systemkatalogen bør faktisk ikke inneholde et slikt kunnskapsområde, informasjon som ikke er presentert i noen bok i biblioteket. Motsatt bør hver bok klassifiseres i ett eller flere kunnskapsområder slik at leseren kan finne den raskere.
ER-modellen for fagområdet "Bibliotek" er vist i fig. 10.4.
Den infologiske modellen «Bibliotek» ble utviklet for oppgavene oppført tidligere. De inneholder ikke vilkårene for å lagre historien om å lese boken, for eksempel med sikte på å finne noen som tidligere holdt boken og kunne skade den. Hvis oppgaven var å lagre denne informasjonen også, ville den infologiske modellen vært annerledes.
Normalisering av ER-diagrammer
Den infologiske modellen brukes i de tidlige stadiene av prosjektutvikling. Hvis du forstår språket legende som tilsvarer kategoriene til ER-modellen, kan den enkelt "leses", derfor er den tilgjengelig for analyse av programmerere-utviklere som vil utvikle individuelle applikasjoner. Den har en entydig tolkning, i motsetning til enkelte naturlige språksetninger, og derfor kan det ikke være noen misforståelser fra utviklernes side.
Eksperter foretrekker alltid å uttrykke tankene sine på et eller annet formelt språk som gir en entydig tolkning av dem. Dette språket for programmerere er språket til algoritmer. Enhver algoritme har en entydig tolkning. Den er implementert på forskjellige språk programmering, men selve algoritmen forblir uendret. Ulike formalismer brukes for å beskrive algoritmer.
Språket til ER-modellen har blitt det konvensjonelle konvensjonelle språket for å beskrive databasen. For ER-modellen er det en algoritme for dens entydige transformasjon til en relasjonsdatamodell, som gjorde det mulig i fremtiden å utvikle en rekke instrumentelle systemer som støtter utviklingen av informasjonssystemer basert på databaseteknologi. Og i alle disse systemene er det midler for å beskrive den infologiske modellen til den utviklede databasen med muligheten til å automatisk generere den datalogiske modellen som prosjektet skal implementeres på i fremtiden.
Regler for konvertering av en ER-modell til en relasjonsdatabase
La oss vurdere reglene for å transformere en ER-modell til en relasjonsdatabase.
1. Hver enhet er tildelt en relasjon av relasjonsdatamodellen. I dette tilfellet kan navnene på enheten og relasjonen være forskjellige, siden ytterligere syntaktiske begrensninger ikke kan pålegges navnene på enhetene, bortsett fra det unike med navnet i modellen. Relasjonsnavn kan begrenses av kravene til et bestemt DBMS, oftest er disse navnene identifikatorer i noen basisspråk, de er begrenset i lengde og må ikke inneholde mellomrom eller noen spesialtegn. For eksempel kan en enhet navngis « Bokkatalog ”, og det er ønskelig å navngi den tilsvarende relasjonen, for eksempel BØKER (uten mellomrom og med latinske bokstaver).
2. Hvert attributt til en enhet blir et attributt for det tilsvarende forholdet. Gi nytt navn til attributter bør utføres i samsvar med de samme reglene som å gi nytt navn til relasjoner i klausul 1. For hvert attributt spesifiseres en spesifikk datatype som er tillatt i DBMS og den obligatoriske eller valgfrie karakteren til dette attributtet.
3. Primærnøkkelen til enheten blir PRIMÆRNØKKEL for den tilsvarende relasjonen. Attributter som er en del av primærnøkkelen til en relasjon blir automatisk tildelt en obligatorisk egenskap.
4. Et sett med attributter for hovedenheten, som er hovednøkkelen til hovedenheten, legges til hvert forhold som tilsvarer den underordnede enheten. I en relasjon som tilsvarer en underordnet enhet, blir dette settet med attributter en fremmednøkkel.
5. For å modellere en valgfri type relasjon på det fysiske nivået, settes attributtet til fremmednøkkelen til egenskapen tillatte nullverdier. Hvis koblingstypen er obligatorisk, får attributtene egenskapen uten nullverdier.
Det er mulig å lage bare én relasjon for alle undertyper av én supertype. Den inkluderer alle attributtene til alle undertyper, men i noen tilfeller vil noen av attributtene ikke gi mening. Og selv om de har udefinerte verdier, vil det kreves ytterligere regler for å skille noen undertyper fra andre. Fordelen med dette synet er at kun ett forhold skapes.
I den andre metoden opprettes separate relasjoner for hver undertype og for supertypen. Ulempen med denne presentasjonsmetoden er at det skapes mange relasjoner, men denne metoden har flere fordeler, siden man kun jobber med signifikante attributter av undertypen. I tillegg, for å kunne navigere til undertyper fra supertypen, må relasjonsidentifikatoren inkluderes i supertypen.
7. I tillegg, når man beskriver forholdet mellom type og undertyper, er det nødvendig å angi typen diskriminator. Diskriminatoren kan være gjensidig utelukkende eller ikke. Hvis denne diskriminatortypen er satt, betyr det at én forekomst av en supertype-enhet er assosiert med bare én forekomst av en subtype-enhet, og det er en etterkommer for hver forekomst av en supertype-enhet. I tillegg må du spesifisere for den andre metoden om bare supertype-identifikatoren skal arves til undertyper, eller om alle supertype-attributter er arvet.
8. Hvis ER-skjemaet har en M:M relasjon(er) som relasjonsmodellen ikke støtter, introduseres en spesiell koblingsrelasjon, som tilknyttes hver innledende relasjon med en 1:M-relasjon. Attributtene til dette forholdet er hovednøklene til forholdet som er bundet.
Algoritme for å redusere den semantiske modellen til 3NF
Algoritmen for å redusere den semantiske modellen til 3. normalform kan være som følger:
1. Analyser skjemaet for tilstedeværelsen av entiteter som latent modellerer flere forskjellige sammenkoblede klasser av objekter i den virkelige verden (dette er det som tilsvarer unormaliserte relasjoner). Hvis slikt avsløres, del hver av disse enhetene i flere nye enheter og etablere passende koblinger mellom dem; den resulterende kretsen vil være i første normal form.
2. Analyser alle entiteter som har sammensatte primærnøkler for ufullstendige funksjonelle avhengigheter av ikke-primære attributter på attributter til en mulig nøkkel. Hvis slike avhengigheter blir funnet, del enhetsdataene med 2, definer primærnøkler for hver enhet og etablere passende relasjoner mellom dem. Den resulterende kretsen vil være i andre normal form.
3. Analyser ikke-nøkkelattributtene til alle enheter for tilstedeværelsen av transitive funksjonelle avhengigheter. Hvis du finner noen, del hver enhet i flere på en slik måte at du eliminerer transitive avhengigheter. Kretsen er i tredje normalform.
Ved å bruke de vurderte bestemmelsene normaliserer vi ER-ordningen. Resultatet av normalisering er vist i fig. 5. Ved normalisering av skjemaet, ble relasjonen "Bøker-katalogkoblinger" introdusert i den, som inneholder attributtene "ISBN" og "Kunnskapsområdekode", som tjener til å implementere M:M-lenken "Bøker - systematisk katalog", og i relasjonen "Forekomster" for sine I forbindelse med relasjonene "Bøker" og "Lesere" er attributtene "Lånekortnummer" og "ISBN" innført. Piler indikerer retningen til koblingene.
Det kan vises at diagrammet i fig. 10.5 tilfredsstiller kravene til 3. normalform.
Arbeidsordre
1. Gjennomfør en semantisk analyse av fagområdet for eksempelet nedenfor.
Eksempel. Fagområde for IP: Human Resources Department.
Minimum liste over egenskaper:
Etternavn, navn, patronym, hjemmeadresse, telefonnummer, fødselsdato, stilling, dato for påmelding, arbeidserfaring, utdanning;
etternavn, fornavn, patronym og fødselsdato for familiemedlemmer til hver ansatt;
avdelingens navn, antall stabsenheter, lønn, lønn for måneden og for året.
2. Ved hjelp av metoden ovenfor, representere fagområdet i form av en ER-modell.
3. Bruk den ovenfor beskrevne ER-modell normaliseringsteknikken, bring den utviklede ER-modellen til 3NF.
4. Vis resultatene av arbeidet på alle stadier i rapporten.
Som nevnt tidligere, er et av hovedmålene med semantisk modellering å reflektere resultatene av domeneanalyse i en enkel, visuell, men samtidig formalisert og tilstrekkelig informativ form.
I denne forstand er domenemodellering basert på bruk av grafiske diagrammer, er en en god beslutning... Den grafiske formen lar deg vise i kompakt form (på grunn av visuelle konvensjoner) typologien og egenskapene til enheter og relasjoner, og formalismene som ligger til grunn for ER-diagrammer gjør det mulig å formulere et begrenset sett med designregler logisk struktur Database.
Diagram- grafisk representasjon et sett med elementer, oftest avbildet som en sammenhengende graf med toppunkter-objekter og kanter-relasjoner. I ER-diagrammet er toppunktene enhetene og (for eksempel i Chens notasjon) egenskapene til enhetene. Kantene til et ER-diagram representerer forhold mellom enheter og mellom en enhet og dens egenskaper.
Det finnes flere forskjellige notasjoner (språk) for å avbilde ER-diagrammer. Historisk sett er den første Chens notasjon; i IDEF-familien av standarder er enhetsrelasjonsmodellen implementert av IDEF1X-notasjonen; Martin og Barker-notasjoner og UML grafiske elementer brukes.
Ris. 5.5. ER-diagram i UML-notasjon
UML-notasjon. I fig. 5.5 viser et eksempel på et SbA ER-diagram i UML-notasjon.
Samlet språk UML-modellering(Unified Modeling Language) er et språk for å definere, presentere, designe og dokumentere programvaresystemer, organisatoriske og økonomiske systemer, tekniske systemer og andre systemer av ulik karakter. Strukturen til UML er standard sett diagrammer og notasjoner.
Hovedmålene i utviklingen av UML var følgende:
Gi et ekspressivt visuelt modelleringsspråk som er klart til bruk som gjør det mulig å utvikle og dele meningsfulle modeller;
Tilveiebringe mekanismer for utvidelse av språkets grunnleggende konsepter;
Sikre uavhengighet fra spesifikke programmeringsspråk og utviklingsprosesser.
Integrer beste praksis.
UML er for tiden i ferd med å standardiseres av Object Management Group (OMG).
Vurder reglene for skildring av enheter, egenskaper og relasjoner i denne notasjonen.
Hver enhetstype i UML ER-diagrammer er representert som et rektangel som inneholder enhetsnavnet og en liste over enhetsegenskaper. Navnet på en enhet er vanligvis et entallssubstantiv (for eksempel AVDELING, PROSJEKT, ANSAT). Enhetsnavnet vises øverst i rektangelet med stor bokstav, egenskapsnavn er oppført nederst i rektangelet og begynner med en liten bokstav.
Svake enheter er preget av det faktum at de ikke kan identifiseres unikt bare med sine egne attributter (på grunn av deres avhengighet av de "overordnede" enhetene og umuligheten av uavhengig eksistens). I ER-diagrammer har ikke svake enheter primærnøkler (for eksempel SLAVE-enheten)
Egenskaper brukes til å klargjøre, identifisere, karakterisere eller uttrykke tilstanden til en enhet eller et forhold. Refleksjon over ER-diagrammer av typologi av egenskaper er presentert i tabell. 5.2.
Tabell 5.2. Representasjon av eiendomstyper i UML
| Eiendomstype | Beskrivelse | Eksempel |
| Primær nøkkeleiendom | etter eiendomsnavnet i krøllete regulering identifikasjonen av primærnøkkelen (PK) er plassert |  |
| Tvetydig | etter eiendomsnavnet i firkantede parenteser er gitt mulige grenser endringer i antall verdier |  |
| Derivat | egenskapsnavnet starter med en skråstrek "/" |  |
| Betinget (valgfritt) | etter eiendomsnavnet, i firkantede parenteser, settes mulige grenser for å endre antall verdier |  |
| Sammensatte | under navnet på den sammensatte egenskapen er navnene på de enkle egenskapene rykket inn til høyre |  |
Binære lenker er indikert med linjer som indikerer navnet på lenken og styrken til lenken fra siden av hver enhet. Linkstyrken bestemmer antall objekter som er koblet til hvert objekt i den andre enden av lenken:
1..* - en eller fler;
0..* - null eller mer;
1 - nøyaktig en;
0..1 - kanskje en.
Et område kan også spesifiseres (for eksempel 1..10) eller nøyaktig mengde annet enn 1
For å betegne n-Ary link bruker en rombe, der navnet på linken er angitt. Multiplisitet n-ær relasjon for hver enhet viser hvor mange av dens objekter kan være hvis nøyaktig ett objekt er involvert i relasjonen fra siden av de andre deltakende enhetene. For eksempel, treveiskommunikasjonen i fig. 5.6 spesifiserer at enhver leverandør kan levere mange deler til ethvert prosjekt.
Ris. 5.6. Eksempel på treveis kommunikasjon
Tilstedeværelsen i oppgaven med kommunikasjonskraften til verdien "0" erklærer kommunikasjonen som ufullstendig (valgfritt). For eksempel fungerer forholdet mellom enhetene AVDELING og ANSAT i fig. 5.5 bør lyde som følger: «Hver ansatt arbeider nødvendigvis kun i én avdeling; avdelingen sysselsetter et vilkårlig antall ansatte eller ingen”.
Linken kan endres ved å spesifisere rollen. For eksempel, for den rekursive forbindelsen KOMPOSISJON i fig. 5.5 rollene er angitt: "Detalj omfatter... "og" Detalj som en del av…».
En mange-til-mange-relasjon kan ha sine egne egenskaper som karakteriserer samspillet mellom entiteter (for eksempel relasjonene DELTA og PROSJEKTIMPLEMENTERING i fig. 5.5). I dette tilfellet vises lenken ved hjelp av grafisk element tilsvarer en svak enhet. Entitetsrektangelet er festet til koblingslinjen (eller til romben i tilfelle av n-ær binding) med en stiplet linje.
Chen notasjon. Hver enhetstype i Chens notasjon er representert som et rektangel som inneholder enhetens navn (entallssubstantiv).
Kommunikasjon (både binær og n-ar) i ER-diagrammet vises som en diamant med navnet på forholdet inni. Verbale substantiver brukes vanligvis som navn.
Egenskaper vises som ellipser som inneholder egenskapsnavnet. Ellipsen er forbundet med den tilsvarende enheten eller forbindelsen med en linje (fig. 5.7).
Ris. 5.7. Fragment av et ER-diagram i Chen-notasjon
Kommunikasjonsdeltakerne er koblet til kommunikasjonen med linjer. Den doble linjen angir full (obligatorisk) deltakelse av enheten i forbindelse med denne parten. For eksempel betyr det obligatoriske forholdet STYRING fra siden av PROSJEKT-enheten (fig. 5.8) at hvert prosjekt må ha en leder. Imidlertid er ikke alle ansatte pålagt å lede et prosjekt.
Type tilkobling er angitt med indeksene "1" eller "M" over den tilsvarende linjen. For eksempel har LEDELSE-relasjonen (fig. 5.8) en en-til-mange-type: én ansatt kan administrere mange prosjekter; DELTAGELSE forholdet (fig. 5.7) er av typen «mange-til-mange»: én ansatt kan delta i mange prosjekter, og mange ansatte kan delta i et prosjekt.
Når man bygger modeller av informasjonssystemer, er den viktigste teknikken ER-modellering eller konstruksjon av entitetsrelasjonsdiagrammer. En enhet er en klasse av elementer som er identiske i betydning og brukes i informasjon System... En enhet må alltid ha et navn.
Enheter er representert på informasjonssystemmodellen ved å bruke instanser. Forekomst er et konkret objekt som representerer en gitt enhet. La oss gi et eksempel: en forekomst av "Disciple"-enheten vil være "Disciple Sidorov".
Innenfor rammen av å bygge et informasjonssystem har objekter ulike attributter. Vanligvis er det en eller flere av dem. Et attributt er en egenskap som er iboende i en gitt enhet. La oss gi et eksempel for vår enhet "Student": "Etternavn", "Fornavn", "Patronym", "Klasse".
Et sett med forskjellige attributter som har verdier som er spesifikke for alle forekomster av et objekt, kalles en enhetsnøkkel. I vår situasjon, hvis du sletter et attributt, vil dets unikhet bli krenket, og det er dette som oppnår ikke-redundans. Objekter samhandler med hverandre gjennom lenker. Objektforbindelser er en metode for interaksjon mellom to elementer i et informasjonssystem. Elementer er vanligvis koblet som med andre IP-elementer. Objektrelasjoner gir muligheten til å finne de nødvendige elementene ved å etablere deres forhold til originalen. En forbindelse ser vanligvis ut som en pil eller en linje som forbinder ulike enheter eller kobler seg selv.
Det er tre typer lenker:
- 1) 1-til-1. I denne typen relasjoner er en forekomst av det første objektet assosiert med en forekomst av det andre objektet. Som regel bør slike koblinger forkastes;
- 2) 1-til-n. Med dette forholdet er en forekomst av det første objektet assosiert med noen forekomster av det andre objektet. I informasjonssystemer er dette den vanligste typen kommunikasjon. Med denne strukturen kalles det første objektet den overordnede enheten, og det andre kalles barnet.
- 3) n-til-n. Med dette forholdet er flere forekomster av det første objektet assosiert med flere forekomster av det andre objektet. I praksis betyr dette at systemet er i et mellomstadium av utvikling og under videre analyse. gitt syn koblinger vil bli erstattet med 1-til-n, og oppretter mellomliggende enheter og tilordner lenker på nytt.
Den grunnleggende forskjellen skaper modalitet ved bruk av lenker. Hvis en gjenstand "Kan" være knyttet til en annen, så gir dette ham muligheten til å ta med ulike forekomster av en annen gjenstand, men samtidig er han ikke forpliktet til å ha en tilknytning. I en annen situasjon, hvis et objekt "Bør" ha en relasjon med en forekomst av et annet objekt, må det ha minst ett forhold. Når du modellerer et informasjonssystem ved hjelp av ER-notasjon, er det nødvendig å analysere fagområdet for å bygge følgende grafiske data:
- 1) Liste over objekter;
- 2) Liste relaterte attributter gjenstander;
- 3) Bygge korrekte relasjoner mellom ulike objekter.
Når du bygger diagrammer i ER-notasjon, er modelleringsprosessen iterativ. Etter å ha brukt reverse engineering eller hentet ut en grov modell, kan transformasjons- og forbedringsprosessen ta lang tid, og selve modellen kan suppleres og foredles i samsvar med de nye dataene som er innhentet. Det er to fundamentalt forskjellige typer ER-diagrammer:
- 1) Konseptuell;
- 2) Fysisk.
Ved å bruke eksemplet vist i fig. 11 kan vi se at modellen er en konseptuell modell av en kommersiell virksomhet beskrevet i ER-notasjonen. En slik modell beskriver relasjonene mellom ulike enheter i et gitt informasjonssystem, men tar ikke hensyn til egenskapene til databasen, og kan derfor ikke brukes til videre datamaskindesign. Konseptuelle modeller brukes til videre konstruksjon av fysiske diagrammer, som allerede inkluderer navn på tabeller, felt, typer forskjellige variabler. Den konseptuelle modellen avbildet i figuren viser alle objektene i dette informasjonssystemet og etablerer forbindelsene deres.
Etter transformasjonen ser vi at dette fysiske diagrammet nå formidler informasjon om nøklene, i tillegg til å definere forholdet mellom objektene. Hver tabell lagrer en idé om typen overførte og lagrede data. Denne notasjonen av ER-diagrammer er nærmest standardvisningen av databaser. V denne innleveringen Tabeller inneholder en liste over attributter knyttet til objektet. Denne visningen lar deg raskt gå fra modellutvikling til programvare. SQL-kode og omvendt ved å bruke omvendte utviklerfunksjoner. I denne situasjonen har vi å gjøre med semantisk modellering gjennom bruk av entitetsrelasjonsdiagrammer. Slike diagrammer gir oss en bred forståelse av informasjonssystemet som utvikles, og visualisering lar oss forenkle prosessen med å gruppere elementer og bringe databasen til den nødvendige kanoniske formen. Fordelen med fysiske diagrammer fremfor konseptuelle modeller er tydelig, så mange moderne modelleringsverktøy lar deg hoppe fra en representasjonsform til en annen umiddelbart. Konseptuelle modeller er nødvendige når dybdeanalyse av databasen ikke er nødvendig, og for å modernisere systemet er det nok å forstå og endre kommunikasjonslogikken til elementene.
