1.5 Er modellering

Datormodellering är det första steget mot databasens utformning, det här är övergången från de verkliga världsobjekten till databasmodellen.

ER-modellen tjänar till att kombinera olika datavisningar på konceptnivå. Baserat på ER-modellen är Diagrams byggda på vilka de tre huvudkomponenterna i ER-modellen visas: enheter, attribut, länkar.

1.5.1 Essence

Eftersom enheten är ett objekt av den verkliga världen, visar orden "essens" och "objekt" ofta samma sak.

På ER-modelleringsnivån, enligt kärnan, innebär faktiskt en uppsättning enheter (enhetsuppsättning), inte den enda väsen. Med andra ord motsvarar företaget i ER-modellering av tabellen, inte en rad i en relationell miljö, en separat linje i ER-modellen kallas en förekomst av enheten (Entity-instans, enhetens förekomst). Kärnan är avbildad av en rektangel där kärnan är inspelad.

1.5.2 Attribut

Attribut beskriver egenskaperna hos kärnan. Exempelvis innehåller studentens essens NSTBIL attribut (studentbiljettnummer), FIO (studentnamn), KURS (kurs), etc.

Fikon. 1,24. Studentens entity attribut i ER-modellen.

Attribut har domäner. Domän är en uppsättning möjliga attributvärden. Till exempel kan en domän för det numeriska värdet av studentens genomsnittliga värdering registreras i form av ett intervall.

Primärnycklar i ER-modellen betonas. Om det finns flera primära nycklar, så betonas alla.

Attribut kan vara enkla och komposit. Kompositattributet är ett attribut som kan delas vidare i flera attribut. Till exempel kan ett adressattribut (adress) delas in i gata (gata), stad (stad), etc.

Attribut kan vara entydiga och multiska. Ett entydigt attribut är ett sådant attribut som kan ta de enda värdena. Till exempel kan värdshuset ha den enda betydelsen av varje person. Entydiga attribut är inte nödvändigtvis enkla. Till exempel är serienummer 78-03-06-137846 ett entydigt attribut, men samtidigt är det ett kompositattribut, för Den kan delas in i en region där produkten släpptes (78), stadskoden (03), som utfärdar ett skifte (06), produktnummer (137846).

Det multi-värderade attributet är ett attribut som kan ta flera värden. Till exempel kan en person avsluta flera universitet, ha flera telefonnummer.

I relationella dbms av multivaluerade attribut för att använda den. Om det finns flera värderade attribut, behövs flera nya attribut inom denna enhet eller skapa en ny enhet bestående av en multi-värderad attributkomponenter.

Derivatattributet är ett attribut som inte behöver lagras i databasen, det erhålls med användning av någon algoritm. Till exempel kan en anställds ålder erhållas som ett helt skillnadsvärde mellan det aktuella datumet och födelsedatumet.

1.5.3. Kommunikation

Förhållandet är en förening. Essenser som är involverade i anslutning kallas deltagare (deltagare). Ett verb eller ett dokument kan användas som länknamn. Avdelningen hanterar till exempel, varorna kommer på grundval av det avslutade kontraktet etc.

Förhållandet mellan enheter i kvantitativ relation kan vara "en-till-ett", "en till många". För att beteckna länktyper används termen "anslutning".

Kommunikationseffekt (kardinalitet) uttrycker ett visst antal uppmuntrande av enheter som är förknippade med en kopia av den associerade enheten. På ER-diagrammet är kommunikationseffekten inte betecknad, men i applikationen kan programmeringsinformationen om max och min kvantiteter av essensinstanser vara användbara. Till exempel kan en grupp inte starta klasser om det finns mindre än 10 studenter.

Kommunikation är etablerade mellan enheter. Om kärnan beror på förekomsten av en eller flera enheter beror det på den existensberoende). Till exempel, om anställda har anhöriga, då för att beräkna skatterna, kan du upprätta en anslutning "den anställde har anhöriga". I det här fallet beror enheten "beroende" på kärnan i "anställd".

Om kärnan kan existera utanför andra enheter är det oberoende av existens-oberoende. Till exempel kan enheten "detaljer" existera oberoende av kärnan i "leverantör".

Om en essens är oberoende av förekomsten av en annan enhet, kallas förhållandet mellan dem ett svagt förhållande (svagt förhållande) eller oidentifierat förhållande (icke-identifierande förhållande). Svaga obligationer uppstår om den primära nyckeln till den bundna enheten inte innehåller de primära komponenterna i den genererande enheten. Det finns till exempel två enheter naturligtvis (kurs) och klass (grupp) som beskrivs som

Kurs ( CRS-kod., Dept_code, ...)

Klass ( Klasskod., CRS_code, ...)

Det finns ett svagt band mellan dessa enheter, eftersom CLASS_CODE-attributet är den primära nyckeln till klassens essens, medan CRS_code-attributet för klassenheten är en extern nyckel. Den primära nyckeln till klassenheten ärver inte den primära nyckeln från kärnan självklart. Svagt bindning är avbildat på Diagrammet i streckkoden.

Starkt förhållande (starkt förhållande), även kallade identifierbara anslutningar (identifierande förhållande) uppstår om närstående enheter är beroende av existens. Den starka bindningen mellan två enheter uppstår när den primära nyckeln på den bundna enheten innehåller komponenten i den primära nyckelgenererande väsen. Till exempel, Entity

Kurs ( CRS-kod., Dept_code, ...)

Klass ( CRS_code., Klass-sektion.,…)

Ha en stark anslutning, för Den sammansatta nyckeln till kärnan i klassen inkluderar naturligtvis den primära enheten. På ER-diagrammet visas starka slipsar med en solid linje.

Man måste komma ihåg att den ordning i vilken tabellerna skapas och laddas är avgörande. För data är till exempel inte möjlig när klassbordets externa nyckel hänvisar till en ännu inte befintlig kursbord. Problemet efter sekvensen för att skapa tabeller i vissa DBMs inträffar inte tills data laddas ned. För att undvika kränkningar av integritet vid referensnivån måste i anslutning 1: m laddas av sidan "1" oavsett om det är starkt eller svagt.

Deltagande av essens i samband kan vara obligatoriskt eller valfritt. Essence-deltagande är valfritt (valfritt deltagande), om en punkt av enhet inte kräver förekomst av en lämplig instans av enheten i en separat anslutning. Till exempel, på grund av kursen (kurs), skapas grupper (klass) åtminstone i vissa kurser, kan grupper inte skapas. De där. Enhetsförekomsten (sträng) i kursbordet kräver inte den obligatoriska tillgängligheten av motsvarande essensinstans i klassbordet. Därför anses kärnan i klassen som frivilligt i förhållande till kärnan självklart. Valfri kommunikation på ER-diagrammet visas med en liten cirkel från en valfri enhet. Förekomsten av valfri indikerar att för den valfria essensen min är värdet av kommunikationseffekten lika med 0.

Deltagande av enhet på grund av nödvändigtvis (obligatoriskt deltagande), om en enhet av enhet nödvändigtvis kräver en lämplig instans av kärnan i en separat anslutning. Om ingen ytterligare symbol är avbildad om kärnan betyder det att denna enhet är inblandad i den obligatoriska kopplingen till den bundna enheten. Min makt för obligatorisk essens är 1.

a) Klass essens är valfri för kärnan självklart

b) Kursens och klassens essens i den obligatoriska anslutningen.

Fig.1.25. En bild av obligatoriska och valfria anslutningar i ER-modellen.

När det gäller utformningen av databasen är förekomsten av en stark koppling mellan den genererande kärnan och den tillhörande väsen eller enheter förknippade med svaga enheter.

Svag enhet (svag enhet) är den enhet som uppfyller två villkor:

villkoren för beroende av existens, d.v.s. Det kan inte existera utan kärnan, med vilken den är ansluten;

den primära nyckeln är delvis eller fullt framställd av den genererande kärnan i den här anslutningen.

I ER-modeller avbildas svag essens av små segment i var och en av de fyra hörnen av entitetsrektangeln.

Fikon. 1,26. Svag essens i ER-diagram.

Svag essens ärver alla delar av den primära nyckeln till sin starka kommunikationspartner. Det är DB-designern som bestämmer huruvida det är svagt att deklarera essensen.

Graden av kommunikation (relation grad) indikerar antalet associerade enheter. Unary (unary relation) finns när föreningen bibehålls inuti den enda enheten. Binärt förhållande (binärt förhållande) finns när två enheter är associerade. Ternary-förhållande (ternär relation) äger rum när tre enheter är associerade. Även om det finns högre kommunikationsgrader, är de ganska sällsynta och har inga speciella namn.

Om kärnan har anslutningar med dig, kallas den här anslutningen rekursiv.

Fikon. 1,27. Är presentation av rekursiv kommunikation

Hierarkin av generaliserade representationer (generaliseringshierarki) visar förhållandet mellan "förfader-ättling". I samband med relationsdatabasen visar hierarkin för generaliserade representationer förhållandet mellan supertopparna på den övre nivåns essens och subtyper på den lägre nivån. De där. Supertyp innehåller delade attribut, medan subtypen innehåller unika attribut.

Fikon. 1,28. Hierarki av generaliserade representationer.

Kommunikation är ärft, d.v.s. Undertyp av Entity ärver attribut och anslutningar från Super Lumidity. Till exempel har alla piloter, mekanik och revisorer tablettrum, namn, hemadress, etc., men de kan ha attribut unika för deras specialisering. Med andra ord är supertip av entitetsuppsättningen vanligtvis förknippad med flera unika och icke-spelande subtyper av en uppsättning enheter. Sådana icke-passande länkar betecknas med bokstaven "G".

Supertyp och subtyp (s) Stöd 1: 1 anslutning. Till exempel kan den anställningsbordsstrukturen ersättas med två tabeller, varav en representerar medarbetarnas supertyp, och den andra är en subtyp av pilot.

Vissa suppel innehåller skärande (överlappande) subtyper. Till exempel kan någon anställd vara en lärare, men samtidigt och administratören.

Korslänkar visas med 'GS' karaktärer.

Fikon. 1,29. Hierarki av generaliserade representationer med skärande subtyper.

Konceptuell databasmodell är

Konceptuell modell Detta är ett slags visuellt diagram, ritat i notationen och visar en detaljerad koppling mellan föremål och deras egenskaper. En konceptuell modell skapas för att ytterligare utforma en databas och överföra den till exempel till en relationsdatabas. Den konceptuella modellen i visuellt bekväm form är föreskrivna länkar mellan dataobjekt och deras egenskaper.

Definierade definitioner i konceptdatabasen

För enhetligheten av programmeringsdatabaser anges följande begrepp för konceptuella databaser:

1. Objekt eller essens. Det här är det faktiska eller ett objekt (för personer) bakom vilka användaren (kunden) vill titta på. Till exempel, Ivanov Ivan Ivanovich;
2. Attribut Detta är karaktäristiken för föremålet som motsvarar dess enhet. Till exempel. Vi frågar dig själv: Vilken information ska jag hålla om Ivanov Ivan Ivanovich? Svar på den här frågan och kommer att vara attributen för objektet Ivanov Ivan Ivanovich;
3. Det tredje konceptet i utformningen av en konceptuell databas är kommunikation eller förhållande Mellan föremål.

Lexiskt mer korrekt talar om länken mellan CBD-objekten och förhållandet mellan enheterna i CBD (konceptuell databas), men du kan uppfylla de mest olika kombinationerna av enheten, objektet, anslutningen och relationen (överföringarnas brister).

Konceptuell databasmodell Villkorliga beteckningar

Konceptuell databasmodell: antagna grafiska beteckningar

Diagram Essence / relation (objekt / kommunikation) kallas ett ER-diagram eller EDR (Entity-Relations-diagram). Självkommunikationsmodellen själv erbjöds av professor Peter Pin-Shen Chen (Peter Chen) 1976. Skriftreglerna och de villkorliga beteckningarna för ER-diagrammet kallas notering. Två huvudsakliga noteringar av ER-diagram är vanliga:

• Notering av Peter Chen;
• Notation Gordon Everest (Gordon Everstra). Under call of crows fot eller gaffel (gaffel).

Er diagram beteckningar i piter chenu

Chen föreslog och detta togs av följande villkorliga notering för ER-diagram:

• Enhet eller objekt betecknar en rektangel;
• Förhållanden betecknar en rhombus;
• Attribut av objekt betecknas med ovala;
• Om kärnan är associerad med attityden, indikeras deras anslutning med en rak linje med en pil. Valfri kommunikation indikeras med en streckad linje. En kraftfull kommunikation betecknas med en dubbel linje.

Varje attribut kan vara associerat med ett objekt (enhet).

Notation Gordon Everest.

Gordon Everest introducerade en ny slipsbeteckning som kallades gaffel eller en raven tass. Det introducerades också att objektet skulle betecknas med en rektangel med namnet på objekttypen i form av ett substantiv inuti rektangeln. Dessutom måste detta namn vara unikt i den databas som skapas.

Attribut är inte markerade i en separat figur och passar in i objektrektangeln med namnet av substantiverna med det förtydligande ordet.

Förhållandet mellan objekt indikeras med en rak linje. Flera relationer är betecknade för en gaffel i slutet. Anslutningen är undertecknad av verbet, till exempel "inkluderar" eller "tillhör".

Konceptuell modell av ERD-gaffelsdatabasen

Kosttillskott

Attribut i ER-diagrammet kan ha sina egna attribut (komposit) attribut.

Enkelt ER-diagram för att rita ganska enkelt. En annan sak är rik, voluminous ER-diagram. Nedan är några tips som hjälper dig att bygga effektiva ER-system:

• Bestäm alla objekt i det här systemet och bestämma förhållandet mellan dessa objekt;
• Objektet ska visas bara en gång i en viss plats för systemet.
• Bestäm det exakta och lämpliga namnet för varje objekt, attribut och förhållande i diagrammet. Välj enkla och begripliga ord. Villkoren som är enkla och välbekanta bestämmer alltid de vaga, tekniska ljudsorden. För objekt, substantiv namn för verb (kan förklaras). Glöm inte den unika objektnamnens unika egenskaper;
• Ta bort implicita, överflödiga eller onödiga relationer mellan objekt;
• Anslut aldrig attityder till andra relationer;
• Använd färger för att klassificera samma typobjekt eller välja nyckelområden i diagrammet.

ER-modelldatabasen

Modell Essence-Communication (Eng. Entity-Relations-modell, ERM, ER-modell) Gör det möjligt att beskriva de konceptuella systemen i ämnesområdet.

ER-modellen används med databasdesign på hög nivå. Med det kan du välja viktiga enheter och ange länkar som kan installeras mellan dessa enheter. ER-modellen är en formell design som inte definierar grafiskt medel för sin representation. Som en vanlig grafisk representation av ER-modellen utvecklas ett diagram över ER-Diagram-kommunikation (Entity Relationship Diagram - ER-diagram). Vid utformning av databaser omvandlas ER-modellen till ett specifikt databasschema.

Som det är känt är det grundläggande begreppet relationsdatabas ett bord (förhållande). Bordet används för att strukturera och lagra information. I relationsdatabasen innehåller varje tabellcell ett värde. Dessutom finns i en databas sammankopplingar mellan tabellerna, som alla sätter delningen av data i tabellen.

ER-diagrammet representerar grafiskt databasen för den angivna databasen. Enheter visas med rektanglar, tabeller som innehåller enhetens namn - databasbord. Relationerna med enheter visas i form av linjer som förbinder enskilda enheter.

Förhållandet indikerar att data för en enhet hänvisar eller relaterar till de andra data.

Graden av slut på kommunikation indikeras grafiskt, det flertal kommunikationen är avbildad i form av en "plugg" i slutet av kommunikationen. Modaliteten av kommunikationen är också avbildad grafiskt - den valfria kommunikationen är markerad med en cirkel i slutet av kommunikationen. Kommunikationsnamn uttrycks av ett verb (fig 13).

Fig. 12.

Attribut Enheter spelas in i rektangeln som visar kärnan och uttrycks av substantiv i singular.

Bland attribut finns det en viktig enhet. När du skapar en enhet är det nödvändigt att markera attributgruppen som kan vara den primära nyckeln och välj sedan attributen som ska inkluderas i primärnyckeln:

· Den primära nyckeln måste väljas på ett sådant sätt att attributvärdena, i det ingår, det var möjligt att exakt identifiera en instans av enheten.

· Inget av de primära nyckelattributen bör inte ha ett nollvärde.

· Värdena för de ursprungliga nyckelattributen bör inte ändras. Om värdet har förändrats betyder det att det här är en annan instans av enheten.

När du väljer en primärnyckel, som regel, är ett ytterligare attribut in i essens, vilket blir nyckeln.

Så, unika siffror används ofta för att bestämma den primära nyckeln, som automatiskt kan genereras av systemet när du lägger till en förekomst av enheten i databasen. Användningen av unika nummer underlättar processen att indexera och söka i databasen.

Det första steget i att skapa en logisk modell av databasen är konstruktionen av ett ER-diagram som består av tre delar: enheter, attribut och relationer.

En mängd olika visuella skapningsverktyg har utvecklats - diagram för olika plattformar. Detta projekt använder utveckling MySQL arbetsbänk..

Det här verktyget förenklar databasdesign och underhåll, automatiserar, tar lång tid och uppgiftsfel och förbättrar kommunikationen bland utvecklare och arkitekter i databasen. Det gör det möjligt för datarkitekter att visualisera kraven, kommunicera med intressenter om designfrågor innan investeringar i projektet görs. Detta ger en kontrollerad databasdesign, vilket är den mest effektiva metoden för att skapa verkliga och väl genomtänkta databaser. ER - Databasdatabas Dance Chart ( control_tests.) Objekt i figuren (fig.14). Två vertikala droppar på ena sidan och "trident" på den andra betecknar "anslutningen till många."

Fikon. 14. ER - Control_Test databasdiagram fjärrtestsystem

Databas normalisering

I databasens relationellaori finns det inga universella föreskrifter, lagar för utformning av en pålitlig, utformad en gång och för alltid databaser. Utvecklare väljer sina databasprojektlösningar, lutar på många sätt att uppleva, intuition, olika verktyg och designmetoder.

Ändå finns några kanoner, reglerna fortfarande. Dessa regler inkluderar normaliseringsregler, d.v.s. föra relationer till normal form.

Introduktion

De centrala idéerna i den moderna informationstekniken är baserade på konceptet, enligt vilket uppgifterna ska bildas i databasen för att visa en förändrad verklig värld och uppfylla användarnas informationsbehov. Dessa databaser bildas och fungerar under kontroll av speciella programvarukomplex (uppsättningar programmeringsspråk och programvara), kallade databashanteringssystem (DBMS). Databas själv är ett förråd för ett stort antal systematiserade data med vilka vissa åtgärder kan utföras: Lägg till, ta bort, ändra, kopiera, beställa.

Ökning av volymen av lagrade data ledde expansionen av användarens cirkel av informationssystem till utbredd den mest praktiska och relativt enkla att förstå relationella (tabell) DBMS. För att säkerställa samtidig tillgång till data av en uppsättning användare, som ofta är tillräckligt långt ifrån varandra och från databaslagringsplatsen, skapas nätverksversioner av databaserna baserat på relationsstrukturen. På ett eller annat sätt löses specifika problem med parallella processer, integritet (korrekthet) och datasäkerhet samt tillgångstillstånd.

Under de senaste åren har det varit en tendens att komplicera datastrukturer. Enkla typer av information, som representerar i form av siffror och textlinjer, som inte förlorar sin betydelse, kompletteras med många multimedia-dokument, grafiska bilder, kronologiska rader, procedurella eller aktiva data och myriader av andra komplexa informationsformer. I detta avseende har en hel databas med DBMS som stöder nya datainsamlingar och som kan förverkliga fördelarna med modern hårdvara uppstått. En av dessa DBMS är MS Access 2003 (2007), som ingår i Microsoft Office-mjukvarupaketet och är en av de populära relationella DBMS för lokala datorer.

Populariteten i Microsoft Access DBMS beror på följande skäl:

tillgänglighet i lärande och förståeligt låter dig vara ett av de bästa systemen för att snabbt skapa databashanteringsapplikationer.

helt randifierad;

förmåga att använda ole-teknik;

stöd till WWW-ideologi;

visuell teknik gör att du ständigt kan se resultaten av dina handlingar och justera dem, dessutom, kan arbeta med en designerformer avsevärt underlätta ytterligare studier av programmeringssystem som Visual Basic eller Delphi;

hjälpsystemet är allmänt presenterat;

förekomsten av en stor uppsättning "mästare" för att utveckla föremål.

För närvarande tillämpas automatiserade informationssystem (AIS) i olika större organisationer.

Syftet med detta projekt är: Ansökan vid utövande av kunskap som erhållits i processen att studera "databas" -kursen och förvärv av praktiska färdigheter vid utformning och skapande informationssystem (IP) baserat på databaser.

Grundläggande begrepp av ER-modeller: essens, instans av enhet, attribut, nyckel, kommunikation, typer av relationer

De viktigaste koncepten i ER-modellen är essens, kommunikation och attribut.

Essence är ett verkligt eller inlämnat objekt, information om vilka bör sparas och är tillgängliga. I ER-modelldiagrammen presenteras enheten som en rektangel som innehåller namnet på enheten. Samtidigt är namnet på enheten namnet på typen, och inte någon specifik instans av denna typ. För större uttryck och bättre förståelse kan namnet på enheten åtföljas av exempel på specifika föremål av denna typ.

Varje fall av ett företag bör särskiljas från någon annan instans av samma enhet (detta krav på något sätt liknar kravet på frånvaro av tuples-duplikat i relationella tabeller).

Entity-attributet är någon del som tjänar till att klargöra, identifiera, klassificera, numerisk egenskap eller uttryck av kärnan. Attributnamn är inlagda i en rektangel som visar kärnan, under namnet på kärnan och är avbildade med små bokstäver, kanske med exempel.

Essensnyckeln är en inandalös uppsättning attribut vars värden är unika för varje enhet förekomst. Nackdelen är att avlägsnandet av något attribut från nyckeln störs av dess unika. Entity kan ha flera olika nycklar. Viktiga attribut är avbildade i understrykningsdiagrammet.

Kommunikation är en grafiskt avbildad förening, installerad mellan två enheter. Denna förening är alltid binär och kan existera mellan två olika enheter eller mellan kärnan och det själv (rekursiv). I vilken som helst anslutning tilldelas två ändar (i enlighet med det befintliga paret av bindande enheter), var och en anger namnet på slutet av kommunikationen, graden av slut på kommunikation (hur många kopior av denna enhet binder), kommunikation Bindning (det vill säga någon instans av denna enhet bör delta i detta avseende).

Kommunikation presenteras i form av en linje som förbinder två enheter eller leder till det själv. Samtidigt används en trepunktsingång till en rektangel av enheten i stället för "dockning", om det finns många (många) i huvudsak och enpunktsingång för denna enhet och en kopia av enheten kan delta i anslutning. Den obligatoriska änden av anslutningen är avbildad med en fast linje och en valfri intermittent linje.

Varje anslutning har två ändar och ett eller två namn. Namnet uttrycks vanligtvis i ett obestämt verbform: "att ha", "tillhör", etc. Var och en av föremålen hänvisar till slutet av kommunikationen. Ibland är namnen inte skrivna med tanke på deras bevis. Varje kommunikation kan ha en av följande typer av kommunikation:

Ett Till en

Ett För många

Mycket för många

Fikon. 1 - Typer av slipsar

Länktypen "en till en" betyder att en kopia av den första essensen (vänster) är förknippad med en kopia av den andra essensen (höger). Anslutningen "en till en" indikerar oftast att vi faktiskt har en enhet, felaktigt uppdelad i två.

Anslutningen av "en till många" betyder att en kopia av den första essensen (vänster) är förknippad med flera instanser av den andra väsen (höger). Detta är den vanligaste typen av kommunikation. Den vänstra essensen (från sidan "en") kallas föräldern, höger (från sidan av "många") - ett dotterbolag.

Kommunikation som "mycket till många" betyder att varje kopia av den första essensen kan vara associerad med flera kopior av den andra enheten, och varje förekomst av den andra enheten kan vara associerad med flera kopior av den första essensen. Typ av kommunikation "Många till många" är en tillfällig typ av kommunikation, tillåten i de tidiga stadierna av modellutvecklingen. I framtiden måste denna typ av kommunikation ersättas med två anslutningar av "en till många" typ genom att skapa en mellanliggande enhet.

Varje anslutning kan ha en av två kommunikationsdatum:

Burk

Måste

Fikon. 2 - Modell av kommunikation

Modaliteten "kan" avses att en förekomst av en enhet kan associeras med en eller flera exemplar av en annan enhet och kanske inte är associerad med någon instans.

Modaliteten "måste" betyder att en förekomst av en enhet måste vara associerad åtminstone med en kopia av en annan enhet.

Transformation av ER-modeller i en relationell datamodell

Tänk på omvandlingen av ER-modellen i en relationell datamodell på ett abstrakt exempel. Antag att ER-modellen ges. Du måste få en uppsättning tabeller (relationer) av bordet (tangent, attribut1, attribut2, ..., attribut). Nyckeln kan vara komposit. Praktiskt attributnamn på ER-modellskalan är unika, då när man bygger en relationell modell (nästan aldrig) är det inte nödvändigt att byta namn.

Konvertering av entitetsuppsättningar (för korthet - enheter)

1. Transformation av vanlig essens

Fikon. 3 - Omvandling av den vanliga enheten

Den vanliga enheten omvandlas till ett separat bord, fältet i tabellen kommer att vara alla enheter attribut: Entity (nyckel, attribut1, attribut2)

1. Omvandling av svag essens

En svag essens omvandlas till ett separat bord, tabellfälten kommer att vara alla attribut för essensen plus viktiga attribut för alla enheter med vilka denna svaga väsen identifieras.

De viktigaste fälten för alla föräldrabord kommer att gå in i dotterbolagets nyckel. För dotterbolaget kommer de att kallas en extern nyckel: Entity1 (Key1, Key2, Attribute1, Attribute2).

Nyckel 1.

Attribut 1

Attribut2

Essens 1.

Väsen2

Nyckel2

Fikon. 4 - Transformation av svag essens

1. Transformation av subtyper av enheter

1 sätt. Ett bord skapas där alla attribut är placerade. För att ange hur underrappan är objektet är det nödvändigt att ange ett extrafunktionsfält: essens1 (nyckel, attribut1, attribut2, attribut3, attribut4, attribut4, tecken).

Nackdelen med denna metod är att det finns många tomma fält i tabellen: för subtypsanläggningen 1 attribut 4 och 5, och för subtypobjektet 2 - attribut kommer 2 och 3 att förbli tomma.

2 sätt. Ett separat bord skapas för varje subtyp. Den innehåller alla attribut för denna subtyp och alla utmatningsegenskaper:

Subtype1 (nyckel, attribut1, attribut2, attribut3)

Subtype2 (nyckel, attribut1, attribut4, attribut 5)

Nackdelen med detta tillvägagångssätt är att subtyper nu inte på något sätt är kopplade till varandra.

3 sätt. Ett bord skapas för apparaten, och på ett bord för varje subtyp, som innehåller nyckelklämmor:

Essens1 (nyckel, attribut1)

Subtype1 (nyckel, attribut2, attribut3)

Subtype2 (nyckel, attribut4, attribut5)

Nackdelen med detta tillvägagångssätt är att information om varje objekt nu krossas längs två tabeller.

Fikon. 5 - Konvertera subtyper av enheter

Transformation av anslutningar

1. Kommunikation m: m

För anslutningar - Dubbla rhombuses behöver inte göra någonting, all information lagras redan i tabellen över en svag enhet.

Fikon. 6 - Kommunikation m: m

Ett nytt bord skapas, innehåller viktiga fält av varje enhet som är involverad i kommunikation och egna kommunikationsegenskaper, om någon. Titeln återspeglar vanligtvis vilka enheter som är bindande, eller ringer ett nytt bord med namnet på meddelandet.

Essence1 Supply2 (Key1, Key2, Attribut1).

Om din egen egenskap av kommunikation är nyckeln, är det faktiskt inte längre en binär anslutning, men anslutningen av större arriskap, dvs. Detta attribut kan ersättas med en ny enhet, mot vilken det finns en länk "till en". I det här fallet är det nödvändigt att tillämpa reglerna för ternära och andra anslutningar.

1. Kommunikation 1: m

Fikon. 7 - Kommunikation 1: m

1 sätt. På samma sätt, som i fallet med M: m skapas ett nytt bord, innehållande nyckelfält i varje enhet som är involverad i anslutning. Titeln återspeglar vanligtvis vilka enheter som är bindande, eller ringer ett nytt bord med namnet på meddelandet. Nyckeln kommer att vara nyckeln till den andra enheten.

Essence Extensivity2 (Key1, Key2).

2 sätt. Det nya tabellen skapas inte, och de viktigaste föräldrarna till moderkärnan läggs till i dotterbordet (de loggar inte in på ett dotterbolags nyckel). Viktiga föräldrars enheter är en extern nyckel (utländsk nyckel) för ett dotterbolag.

Denna metod är att föredra att använda om anslutningen är en länk "exakt till en", det vill säga alla enheter av enheter är inblandade i anslutning. I det här fallet kommer det inte att vara tomt.

Tabell över ett dotterbolag: Essence22 (Key2, Attribut1, Key1).

1. Kommunikation 1: 1

Fikon. 8 - Kommunikation 1: 1

1 sätt. På samma sätt, som i fallet med M: m skapas ett nytt bord, innehållande nyckelfält i varje enhet som är involverad i anslutning. Titeln återspeglar vanligtvis vilka enheter som är bindande, eller ringer ett nytt bord med namnet på meddelandet. Nyckeln kommer att vara nyckeln till någon enhet.

Denna metod är att föredra att använda om anslutningen inte är "mjuk till en", det vill säga, inte alla enheter är inblandade i anslutning.

Essence Extensivity2 (Key1, Key2) eller essens1 Supply2 (Key1, Key2).

2 sätt. På samma sätt som i 2 fall 1: m skapas inte det nya bordet, och i en tabell över en av enheterna (vi kommer att överväga det ett barn) Lägg till nyckelfält i en annan enhet (vi kommer att överväga det en föräldra ).

Om anslutningen inte är en länk "exakt till en" med avseende på moderbordet, det vill säga, inte alla enhetsinstanser är inblandade i kommunikation, kan fältet för den externa nyckeln i vissa poster vara tomma.

Tabell i ett dotterbolag: Essence1 (Key1, Attribut1, Key2),

eller essens2 (Key2, Attribut2, Key1).

3 sätt. Två tabeller för enheter som är associerade med 1: 1 kombineras i en. Nyckeln till det nya bordet kan vara en kombination av viktiga nycklar på båda tabellerna. Om åtminstone i en riktning är anslutningen "exakt till en", kan nyckeln till denna enhet betraktas som nyckeln till det kombinerade tabellen.

Tabeller: Essence1 (Key1, Attribut1) och Entity2 (Key2, Attribut2) ersätts av

Essence1 SustaSnment2 (Key1, Attribut1, Key2, Attribut2)

eller, eventuellt essentiella1 (KEY1, Attribute1, Key2, Attribut2),

eller essens1sutility22 (KEY1, Attribute1, Key2, Attribute2).

För att kommunicera kärnan tillämpas samma regler i sig, men eftersom samma enhet deltar i anslutning två gånger måste de viktigaste fälten gå in i samma tabell två gånger. Därför måste du byta namn på en av nycklarna.

Tänk på anslutningen 1: m, metod 2. Ändra namn på den externa nyckeln.

Fikon. 9 - Kommunikation 1: m, bytt namn på den externa nyckeln

Essence1 (Key1, Attribut1, Utestående1).

För obligationer med arromalering, mer än 2, används samma metod vanligen som för binär kommunikation m: m - ett nytt bord skapas, innehåller nyckelfält i alla relaterade tabeller: essens 0-suspension.

Regler för omvandling av ER-modellen i relationell

Regel 1. Varje enhet sätts i enlighet med förhållandet mellan relationell datamodell. Samtidigt kan namnen på kärnan och förhållandet vara annorlunda, eftersom ytterligare syntaktiska begränsningar inte kan läggas över på namnen på enheter, med undantag för det unika namnet i namnet inom modellen. Namnen på förhållandet kan begränsas av kraven i en specifik DBMS, oftast är dessa namn identifierare på något grundläggande språk, de är begränsade i längd och bör inte innehålla mellanslag och några specialtecken. Till exempel kan enheten kallas "bokkatalog", och motsvarande inställning till det kallas till exempel, till exempel böcker (utan luckor och latinska bokstäver).

Regel 2. Varje entitetsattribut blir ett attribut av motsvarande förhållande. För varje attribut tillåts en specifik datatyp till DBMS och skyldigheten eller alternativet för detta attribut (det vill säga tillåtlighet eller avvisning av nollvärden för det).

Regel 3. Den primära nyckeln till enheten blir den primära nyckeln till motsvarande förhållande. Attribut som ingår i det primära förhållandet mellan förhållandet mottar automatiskt egendom (inte null).

Regel 4. I varje inställning som motsvarar den underordnade enheten tillsätts en uppsättning attribut av huvudenheten, som är den primära nyckeln till huvudkärnan.

Med avseende på den underordnade enheten blir denna uppsättning attribut en extern nyckel (förskottsnyckel).

För att simulera en valfri typ av kommunikation på den fysiska nivån är de attribut som motsvarar den externa nyckeln inställd på giltigheten av huruvida odefinierade värden (nolltecken) kan tas upp till sakprövning. Med en bindande typ av kommunikation, mottar attributen icke-frånvaro egendom (inte nolltecken).

Normaliseringsteori

Normalisering av relationer (tabeller) är en av de grundläggande delarna av teorin om relationsdatabaser. Normalisering är avsedd att bli av med redundans i relationerna och ändra sin struktur på ett sådant sätt att arbetet med att arbeta med dem inte har belastats med olika externa svårigheter. När du ignorerar detta tillvägagångssätt, minskar utformningseffektiviteten snabbt, vilket tillsammans med andra liknande friheter kan leda till kritiska konsekvenser.

Första normal form

Förhållandet är i den första normala formen (förkortad 1NF) om alla dess attribut är atomiska, det vill säga om ingen av dess attribut inte kan delas in i enklare attribut som motsvarar några andra egenskaper hos den beskrivna enheten.

Vi kommer att ringa det ursprungliga förhållandet mellan huvudet, och värdet av det icke-analytiska attributet är underordnat.

För att normalisera det ursprungliga förhållandet är de attribut som är neatomaria, det är nödvändigt att kombinera systemen i huvud- och underordnade förhållandet. Dessutom, om exempelvis en tabell som motsvarar det abnormaliserade förhållandet redan finns i databasen och fylls med information, är uppgiften komplicerad av det faktum att värdet av det icke-analytiska attributet kan i sin tur innehålla flera tuplar.

Tänk på attityden som har attributen för "anställningskoden", "fullnamn", "position", "projekt". Självklart kan en anställd arbeta på flera projekt. Antag att projektet beskrivs av identifieraren, titeln och leveransdatumet.

Anställningskod

Fullständiga namn

Placera

Projekt

Ivanov Ivan Ivanovich

Programmerare

ID: 123; Namn: Steam Boiler Management System; Leveransdatum: 09/30/2011
ID: 231; Titel: PS för kontroll och varningar om överskridandet av MPC av olika gaser i rummet; Leveransdatum: 11/30/2011
ID: 321; Namn: Ansiktsigenkänningsmodul för skyddssystem; Leveransdatum: 12/01/2011

Det är lätt att märka att inte alla attribut för detta förhållande är atomiska (odelbara). I synnerhet kan "projekt" -attributet delas in i tre enklare attribut: "Projektkod", "Titel", "Leveransdatum" och värdet av detta attribut för anställd Ivan Ivanovich Ivanov innehåller flera tuples - Information om tre projekt .

Tänk på algoritmen för att normalisera förhållandet till 1NF.

Skapa ett nytt förhållande, vars schema kommer att erhållas genom att slå samman de huvudsakliga och underordnade systemen i det ursprungliga förhållandet till en.

För varje initial relation, som ingår i en ny linjer som de tuples finns i den underordnade inställningen av denna tuple.

Fyll attributvärdena för det nya förhållandet som motsvarar de underordnade attributattributen. Fyll i strängarna i det nya förhållandet med värdena för atomattribut av originalet.

Applicera denna algoritm till ovanstående förhållande. Det nya förhållningsprogrammet kommer att bestå av 6 attribut: "Personalkod", "Fullständigt namn", "Position", "Projektkod", "Titel", "Leveransdatum". För en enda cortex av en given attityd, lägg till de nya tre linjerna, en för varje projekt (med antalet tuplar i underordnade termer). Nu kan du fylla i värdena för de uppdelade attributen med locken från det underordnade förhållandet. Sedan överför vi till var och en av dessa rader Värdet av atomattribut: "Personalkod", "Fullständigt namn", "position" (alla tre linjer innehåller samma värden för dessa attribut).

Resultatet kommer att se ut så här:

Anställningskod

Fullständiga namn

Placera

Projektkod

namn

Leveransdatum

Ivanov Ivan Ivanovich

Programmerare

123

Steam Boiler Management System

30.09.2011

Ivanov Ivan Ivanovich

Programmerare

231

PS för övervakning och varningar för att överskrida MDC av olika gaser inomhus

30.11.2011

Ivanov Ivan Ivanovich

Programmerare

321

Ansiktsigenkänningsmodul för skyddssystem

01.12.2011

Andra normal form

Förhållandet beläget i 1NF kan också ha redundans. För att eliminera det är den andra normala formen avsedd. Men innan du fortsätter till beskrivningen, bör du först identifiera bristerna i den första.

Låt det ursprungliga förhållandet innehåller information om leverans av vissa varor och deras leverantörer.

Leverantörskod

Stad

Stadsstatus

Produktkod

belopp

Moskva

300

Moskva

400

Moskva

100

Yaroslavl

200

Stavropol.

300

Stavropol.

400

Pskov

100

Det är i förväg känt att i detta avseende innehåller följande funktionella beroenden:

((Leverantörskod, produktkod) -\u003e (kvantitet),

(Leverantörskod) -\u003e (stad),

(Leverantörskod) -\u003e (status),

(Stad) -\u003e (status))

Primär nyckel i förhållande till: (leverantörskod, produktkod).

Självklart har inställningen redundans: det beskriver två enheter - leverans och leverantör. I detta avseende uppstår följande anomalier:

Onormal insats. I relation kan du inte lägga till information om leverantören, som ännu inte har satt en enda produkt.

Anomaly-borttagning. Om endast en leverans har varit från leverantören, kommer all information om leverantören att raderas när du tar bort information om den.

Anomaly uppdatering. Om du behöver ändra information om leverantören (till exempel flyttas leverantören till en annan stad), måste du ändra attributvärdena i alla leveranser från det.

Den fysiska meningen med redundansen i det ursprungliga förhållandet ligger i det faktum att det beskriver inte en enhet, men två leveranser och leverantör.

För att eliminera dessa anomalier är det nödvändigt att krossa det ursprungliga förhållandet på projektionen:

Den första bör innehålla den primära nyckeln och alla icke-urvalsattribut är tydligt beroende av det;

I de återstående prognoserna (i det här fallet kommer det att innehålla icke-urvalsattribut beroende på primärnyckeln implicit, tillsammans med den del av den primära nyckeln, från vilken dessa attribut beror tydligt.

Som ett resultat kommer två relationer att erhållas:

Leverantörskod

Produktkod

belopp

300

400

100

200

300

400

100

Det första förhållandet motsvarar nu följande funktionella beroenden: (leverantörskod, produktkod) -\u003e (nummer)

Leverantörskod

Stad

Stadsstatus

Moskva

Yaroslavl

Stavropol.

Pskov

Andra relationerna motsvarar:

((Leverantörskod) -\u003e (stad),

(Leverantörskod) -\u003e (status),

(Stad) -\u003e (status))

En sådan partition eliminerade de anomalier som beskrivs ovan: Du kan lägga till information om leverantören, som ännu inte har levererat varorna, radera leveransinformationen utan att radera leverantörsinformationen och enkelt uppdatera informationen om leverantören flyttas till en annan stad.

Bestämning av den andra normala formen: förhållandet är i den andra normala formen (förkortad 2NF) om och endast om den är i den första normala formen och var och en av dess icke-selektiva attribut är irreducible beroende på primärnyckeln.

Semantisk modellering

Den breda fördelningen av relationella DBMS och deras användning i ett brett utbud av applikationer visar att relationsdatamodellen är tillräcklig för att simulera ämnesområdena. Utformningen av relationsdatabasen med avseende på relationer på grundval av normaliseringsmekanismen som kortfattat anses av oss är emellertid ofta en mycket komplex och obekväm process för designern.

Samtidigt manifesteras begränsningarna av den relationella modellen för data i följande aspekter:

Modellen ger inte tillräckliga medel för att representera betydelsen av uppgifterna. Semantiken i det verkliga ämnesområdet bör vara oberoende av modellen att vara i designerns huvud. I synnerhet hänvisar detta till problemet med närvaron av nämnda integritetsbegränsningar.

För många tillämpningar är det svårt att simulera ämnesområdet baserat på plana bord. I vissa fall, vid det inledande stadiet av design, måste designern producera våld för att beskriva ämnesområdet i form av ett (kanske till och med abnormiserat) bord.

Även om hela designprocessen är baserad på redovisningen av beroenden, ger relationsmodellen inte några medel för att representera dessa beroenden.

Trots det faktum att designprocessen börjar med fördelningen av några väsentliga föremål av objekt ("enheter") och identifiering av kopplingar mellan dessa enheter, erbjuder relationella datamodellen ingen apparat för separation av enheter och anslutningar.

Behovet hos databasdesigners på bekvämare och kraftfulla medel för att modellera ämnesområdet orsakade riktningen av semantiska datamodeller. Med det faktum att någon utvecklad semantisk datamodell, liksom relationsmodellen, innehåller en strukturell, manipulation och integrerad del, är huvudsyftet med semantiska modeller att säkerställa möjligheten att uttrycka data semantik.

Oftast i praktiken används semantisk modellering i den första etappen av designdatabasen. Samtidigt, när det gäller den semantiska modellen, utförs ett konceptuellt diagram över en databas, som sedan manuellt omvandlas till ett relationellt (eller något annat) -schema. Denna process utförs under kontroll av tekniker där alla steg i en sådan omvandling är ganska tydligt specificerad.

Mindre ofta implementerade en automatiserad sammanställning av konceptionssystemet i relationell. Samtidigt är två tillvägagångssätt kända: baserat på den uttryckliga presentationen av det konceptuella systemet som källinformation för kompilatorn och byggandet av integrerade designsystem med den automatiska skapandet av ett konceptionssystem baserat på en intervju med en objektexperter. Både, och i ett annat fall är det resulterande databasschemat i den tredje normala formen en relationell (mer exakt bör sägas att författaren är okända system som ger en högre normaliseringsnivå).

Slutligen, den tredje möjligheten, som ännu inte har uppstått (eller bara går) utöver forskning och experimentella projekt, arbetar med databasen i den semantiska modellen, d.v.s. DBMS baserat på semantiska datamodeller. Samtidigt övervägs två alternativ: Att tillhandahålla ett användargränssnitt baserat på en semantisk datamodell med automatisk visning av strukturer i en relationell datamodell (detta är uppgiften att ungefär samma komplexitetsnivå som den automatiska sammanställningen av den konceptuella databasen Schema i relationskretsen) och det direkta genomförandet av DBMS baserat på vilken semantisk datamodell. Den närmaste tillvägagångssättet är modern objektorienterad DBMS, vars datamodeller är nära semantiska modeller för många parametrar (även om de i vissa aspekter är mer kraftfulla och i vissa svaga).

Utökad ER-modell (EER-modell)

Begreppen till den vanliga ER-modellen är tillräcklig för att representera majoriteten av databasscheman, till exempel för de flesta kommersiella BD-system. Men områden som automatiserade designsystem, automatiserade förberedelsesystem och andra. Det finns mer komplexa krav för databasen. För sin semantiska modellering kompletterades ER-modellen med nya koncept och omvandlades till EER-modellen (förbättrad ER-modell - en utökad "Essence-Communication" -modell). En sådan modell innehåller alla ER-element i modellen plus ytterligare koncept, nämligen begreppen generalisering, specialisering och aggregering.

Generalisering är en sammanslutning av en uppsättning klasser (typer) av enheter till en mer generell typ av enhet - superklass. Om det i färd med analys av enheter konstateras att två eller flera klasser (typer) av enheter har gemensamma attributuppsättningar, då kan sådana klasser kombineras till en superklass.

Specialisering är den motsatta generaliseringen. Det ligger i det faktum att vissa vanliga (aggregerade, superklass) -klasser eller typ är uppdelad i flera mer privata (specialiserade) underklasser.

Aggregation är processen att kombinera flera oberoende enheter (typer) i en aggregerad (komplex) typ.

Konceptuella er modeller

I enlighet med de huvudsakliga stadierna i databasdesignen efter att ha byggt en konceptmodell väljs ett databashanteringssystem, med vilket databasen och operationen kommer att organiseras. Varje DBMS stöder vissa typer och typer av data, såväl som medel för att representera länkar mellan data som utgör DBMS-datamodellen. Den andra etappen av databasen består av att representera den konceptuella modellen konstruerad i föregående steg med hjälp av DBMS-datamodellen eller i visning av den konceptuella modellen i DBMS-datamodellen. Detta steg kallas ofta den logiska designen i databasen. Den erhållna modellen kallas ofta också den konceptuella modellen eller systemet, men specificerat av begreppen DBMS-datamodell. I vissa källor kallas den resulterande modellen en logisk datastruktur eller databasdatamodell.

Du kan karakterisera begreppet DBMS-datamodell annorlunda. Å ena sidan är DBMS-datamodellen ett sätt att strukturera de data som betraktas som en viss abstraktion i separationen från ämnesområdet. Å andra sidan är DBMS-datamodellen ett verktyg för att presentera en konceptuell modell av ämnesområdet och dynamiken i dess förändring i form av en databas.

Med tanke på både ovanstående parter definierar vi de grundläggande strukturerna för DBA-datamodeller som används för att presentera konceptmodellen för ämnesområdet (enheter, attribut, länkar).

Dataelement (fält) - den minsta namngivna dataenheten. Brukade representera attributvärdet.

Begreppet "datatyp" är oupplösligt kopplat till dataelementet, som kan ta det lämpliga fältet. I olika DBMS kan olika typer av data användas, varav de vanligaste som används i många DBMS är följande: numerisk (numerisk), symbol (char), datum (datum) etc.

Spela in - namngiven förbränning av fält. Brukade representera uppsättningen av attribut av enheten (postrekord).

Inspelningsinstans - Inspelning med specifika fältvärden.

Den primära nyckeln är den minsta uppsättningen av inspelningsfält, identifierar entydigt en filintagensinstans.

Fil - namngiven uppsättning instanser av poster av en typ. Brukade representera en homogen enhetsuppsättning.

En uppsättning filer - med namnet uppsättning filer som behandlas i systemet. Brukade representera flera enheter.

Begreppet "grupp" är ett generaliserande begrepp av "fil" och "inspelning".

En grupp är en namngiven uppsättning dataelement och andra grupper.

Det viktigaste konceptet av den konceptuella modellen är begreppet kommunikation mellan enheter (enheter uppsättningar). I dessa DBMS-modeller återspeglas motsvarande koncept av begreppet "grupprelation".

Gruppförhållande - det angivna binära förhållandet som anges på två uppsättningar kopior av de aktuella grupperna. Enligt karaktären av binära bindningar, är gruppförhållandet i formen 1: 1, 1: m, m: 1, m: n särskiljande. Par siffror kallas grupprelationskoefficienter. I koncernens inställning utses en medlem av koncernen av ägaren av förhållandet, en annan medlem.

Två former används för att representera ett gruppförhållande:

a) grafik. Grupper är avbildade av grafens vertikor, förhållandet mellan grupper - bågar riktade från ägargruppen till en medlemsgrupp som anger namnet på förhållandet och koefficienten.

Efter typ av grafer skiljer du:

hierarkisk modell (graf utan cykler - trä);

nätverksmodell (orienterad grunda graf).

b) Tabell. Kommunikation mellan grupper representeras av en tabell vars kolumner representerar nycklarna hos motsvarande grupper. För en formell beskrivning av bordet använder matematiskt (teoretiskt och flera) koncept av relation. Motsvarande datamodell kallas relationell modell.

Exempel på ER-modeller

Exempel 1.

ER Modell: Zhek

Uppgiftsbeskrivning: Hekk-anställda behöver en databas för att lagra information om reparationer från invånare. Hällen serverar en grupp hus, inklusive flera gator. Ansökan kommer från lägenheten. Ansökan tar avsändaren, det anger antalet och datumet för mottagandet av ansökan, bestämmer typen av ansökan och dess utförande. Ansökan utförs av ett team av specialister. Varje specialist kan bara arbeta i en brigad, varje brigad har en brigadier.

Fikon. 10 - Exempel på bostadsmodellens ER-modell

Exempel 2.

Er-Model Office "Horn och Hooves"

Beskrivning av problemet: Office of "Horns and Hooves" är engagerad i kommersiell verksamhet vid försäljning av produkter som produceras av horn och hovar och tillhandahållande av magiska tjänster.

En anställd i organisationen har ett fullständigt namn, ett tabellnummer, en position. Anställda fördelas över flera avdelningar. Varje avdelning har ett nummer, titel och chef. En anställd kan inte leda mer än en avdelning.

Organisationen arbetar med kunder företag. Varje företag har ett namn och en adress. Några kontrakt kan ingås med företaget.

Kontraktet kännetecknas av ett unikt nummer, datum och typ. Varje kontrakt övervakar någon anställd. Eftersom kunden har genomförts av varorna och tjänsterna enligt kontraktet med viss periodicitet är konton är ogiltiga.

Kontot kännetecknas av ett unikt nummer, betalningsdagen, betalningsperioden och beloppet samt listan över de genomförda varorna och tjänsterna med uppgift om kvantitet. För obetalda konton debiteras påföljder. Kontot kan betalas i flera tekniker, varje betalning kännetecknas av antalet, datumet och summan. Betalningsnummer är unikt inom sitt konto. Priserna för varor och tjänster kan variera med tiden.

Fikon. 11 - Exempel på ER-modellen av "horn och hooves"

Ett exempel på en enkel ER-modellutveckling

När vi utvecklar ER-modeller måste vi få följande information om ämnesområdet:

1. Förteckning över ämnesenheter.

2. Förteckning över enhetsattribut.

3. Beskrivning av relationer mellan enheter.

ER-diagram är praktiska eftersom processen med val av enheter, attribut och anslutningar är iterativ. Efter att ha utvecklat den första ungefärliga versionen av diagrammen klargör vi dem, polerar experterna i ämnesområdet. Samtidigt är dokumentationen där resultaten av konversationer spelas in är Diagrammen själva.

Antag att vi står inför uppgiften att utveckla ett informationssystem för order av något grossisthandel. Först och främst måste vi lära oss ämnesområdet och de processer som uppstår i den. För att göra detta intervjuar vi medarbetarna i företaget, läs dokumentationen, vi studerar orderingången, fakturor etc.

Till exempel, under en konversation med en försäljningschef visade det sig att han (chef) anser att designersystemet ska utföra följande åtgärder:

Förvara information om köpare.

Skriv ut över huvudet för släppta varor.

Övervaka tillgängligheten av varor i lager.

Vi markerar alla substantiv i dessa förslag - det kommer att vara potentiella kandidater för essens och attribut, och analysera dem (obegripliga termer kommer att tilldelas frågetecken):

Köparen är en tydlig kandidat till kärnan.

Fakturaen är en tydlig kandidat till kärnan.

Produkt - En tydlig kandidat till essens

(?) Lager - men i allmänhet, hur många lager har ett företag? Om några, kommer det att vara kandidat till en ny enhet.

(?) Tillgängligheten av varor är sannolikt ett attribut, men vad är entitetsattributet?

Omedelbart uppstår en uppenbar koppling mellan enheter - "Köpare kan köpa många varor" och "varor kan säljas till många köpare." Den första versionen av diagrammet ser ut så här:

Fikon. 12 - Första versionen av ER-diagrammet

Genom att fråga ytterligare frågor till chefen upptäckte vi att företaget har flera lager. Dessutom kan varje produkt lagras i flera lager och säljas från vilket lager som helst.

Var ska man placera enheter "Faktura" och "Warehouse" och med vad du ska knyta dem? Jag frågar dig själv hur dessa enheter är kopplade till varandra och med enheterna "Köparen" och "Produkt"? Köpare köper varor för att få omkostnader där uppgifter om antal och pris på de inköpta varorna görs. Varje köpare kan få några overhead. Varje faktura är skyldig att skrivas på en köpare. Varje faktura måste innehålla flera varor (ingen tomma overhead). Varje produkt kan i sin tur säljas till flera kunder genom flera overhead. Dessutom måste varje faktura släppas ut från ett specifikt lager, och från vilket lager som helst kan tömmas mycket fakturor. Således, efter förtydligande, kommer diagrammet att se ut så här:

Fikon. 12 - Andra versionen av ER-diagrammet

Nu är det nödvändigt att tänka på attributen hos enheter. Det visar sig följande:

Varje köpare är en juridisk person och har namn, adress, bankuppgifter.

Varje produkt har namnet, och kännetecknas också av måttenheter.

Varje faktura har ett unikt nummer, datumet för uttalandet, en förteckning över produkter med kvantiteter och priser, liksom det totala beloppet av fakturan. Fakturaen är urladdad från ett specifikt lager och på en viss köpare.

Varje lager har sitt eget namn.

Vi kommer att upprepa alla substantiv som kommer att vara potentiella attribut och analysera dem:

Den juridiska personen är en retorisk term, vi arbetar inte med individer. Bry dig inte om.

Köparens namn är den uttryckliga karaktäristiken för köparen.

Adressen är den uttryckliga karaktäristiken för köparen.

Bankdetaljer är de uppenbara egenskaperna hos köparen.

Produktnamn är den uttryckliga karaktäristiken för varorna.

(?) Priset på varor - det verkar som om detta är karaktäristiska för varorna. Är denna egenskap av priset i fakturan?

Mätenhet är den uttryckliga karaktäristiken för varorna.

Overheadnummer är en uppenbar unik egenskap av fakturan.

Fakturas datum är en uppenbar egenskap hos fakturan.

(?) Lista över varor i fakturan - listan kan inte vara ett attribut. Förmodligen måste du markera den här listan till en separat enhet.

(?) Antalet varor i fakturan är en uppenbar egenskap, men vad är karaktären av vad? Denna egenskap är inte bara en "produkt", men "varor i fakturan."

(?) Priset på varor i fakturan - det borde inte bara vara karaktäristiken för produkten, utan produktens karakteristik i fakturan. Men priset på varorna har redan träffat ovan - är det här och detsamma?

Summan av fakturan är den uppenbara egenskapen hos fakturan. Denna egenskap är inte oberoende. Summan av fakturan är lika med summan av värdena för alla varor som ingår i fakturan.

Lagerhusets namn är det uppenbara karaktäristiska för lageret.

Varje produkt har något aktuellt pris. Detta pris för vilket produkten säljs för tillfället. Naturligtvis kan detta pris variera med tiden. Priset på samma produkt i olika kostnader, urladdade vid olika tidpunkter, kan vara annorlunda. Således finns det två priser - priset på varor i fakturan och det nuvarande priset på varorna.

Med begreppet "lista över varor i fakturan" är allt ganska klart. Entiteterna "Faktura" och "Varor" är anslutna till varje annan inställning av typen Många-Många. En sådan länk ska delas upp i två-till-många typ av två. Detta kräver ytterligare enhet. Denna essens är kärnan i "listan över varor i fakturan." Dess förbindelse med enheterna "Fakturan" och "produkten" kännetecknas av följande fraser - "Varje faktura är skyldig att ha flera poster från listan över varor i fakturan", "Varje post från listan över varor i fakturan är skyldig att slå på exakt en överlappning "," Varje produkt kan ingå i flera poster från listan över varor i fakturan "," Varje inträde från listan över varor i fakturan är skyldig att vara associerad med exakt med en produkt . Attribut "Antalet varor i fakturan" och "Pris på varor i fakturan" är attribut av enheten "Förteckning över varor i fakturan."

På samma sätt kommer vi att kommunicera med anslutningen som förbinder entienten "lager" och "produkt". Vi presenterar en extra enhet "varor i lager". Attributet för denna enhet kommer att vara "mängden varor i lager". Således kommer produkten att listas på vilket lager som helst och dess nummer på varje lager kommer att vara sin egen.

Nu kan du göra allt i diagrammet:

Fikon. 13 - tredje (slutlig) version av ER-diagram

Referenslista:

Informationssystem i ekonomin: en lärobok för studen. Högre. Studier, institutioner / vb UTKIN, K.V. Baldine. - M.: Publicering Center "Academy", 2004. - 288 s.

Utveckling och drift av automatiserade informationssystem: Studier. Manuell / ed. prof. L.g. Gagarina. - M.: ID "Forum": Infra-M, 2007. - 384 C.: IL. - (Professionell utbildning).

Datum K. Introduktion till databassystem. - m.: Dialektik, 2000.

PERSHIKOV V. I., Savinkov V. M. Förklarande ordbok om datavetenskap. - m.: Finans och statistik, 2001.

Riordan R. Grunderna av relationsdatabaser. - m.: Ryska upplagan, 2001.

Saucup R. Utforma relationssystemdatabasystem. - m.: Ryska upplagan, 2006.

Databashanteringssystem och kunskap / ed. A. N. Naumova. - m.: Finans och statistik, 2005.

Sport M., Papapas F. Datornät och nätverksteknik. - Kiev: LLC "TID" DS ", 2002.

UTKIN V. B. Grunderna för automatisering av yrkesverksamhet. - M.: RDL, 2001.

UTKIN V. B., Sazanovich A.n., Mdichradze V. G. Informatik. - m.: RDL, 2007.

Megaplus: Elektronik, Datorer, Kommunikation.2010. - № 5.

Liksom varje modell har modellen "Essence-Communication" flera grundläggande begrepp som bildar de ursprungliga tegelstenarna, varav redan byggs mer komplexa föremål enligt förutbestämda regler.

Denna modell är mest förenlig med begreppet objektorienterad design, som för närvarande är oändligt grundläggande för att utveckla komplexa mjukvarusystem, så många koncept kan tyckas bekanta med dig, och om det är sant, så är det lättare att behärska databasdesigntekniken Baserat på ER-modellen.

ER-modellen är baserad på följande grundläggande begrepp:

• Essens, S.den hjälp som klassen av samma typ av objekt är modellerad. Essence har ett namn som är unikt inom det simulerade systemet. Eftersom enheten motsvarar en viss klass av samma typ av objekt antas det att det finns många fall av denna enhet i systemet. Det objekt som motsvarar begreppet enhet har sin egen uppsättning attribut -egenskaper som definierar egenskaperna hos denna klassrepresentant. I det här fallet bör uppsättningen av attribut vara sådan att de specifika instanserna av enheten kan särskiljas. I huvudsak kan arbetstagaren ha nästa uppsättning attribut: ett tabellnummer, efternamn, namn, patronymic, födelsedatum, antal barn, närvaro av släktingar utomlands. En uppsättning attribut identifierar definitivt en specifik kopia av enheten, kallad nyckel.För enheten kommer en anställd att vara attributet till bordsnumret, för för alla anställda i detta företag kommer tablettnumren att vara annorlunda. En förekomst av Entity-anställd kommer att vara en beskrivning av en viss anställd i företaget. En av de allmänt accepterade grafiska beteckningarna för enheten är en rektangel, den överrymda som enhetens namn är inspelat, och attributen är listade nedan, och de viktigaste attributen är markerade, till exempel understrykning eller speciell typsnitt (fig 7.1 ):

Fikon. 7,1.Ett exempel på att bestämma kärnan i ER-modellen

Mellan enheter kan installeras kommunikation- Binära föreningar som visar hur enheterna relaterar eller interagerar med varandra. Kommunikation kan existera mellan två olika enheter eller mellan kärnan och det själv (Rekursiv kommunikation).Det visar hur anger är anslutna till varandra. Om anslutningen är etablerad mellan två enheter bestämmer den förhållandet mellan instanser av en och en annan enhet. Till exempel, om vi har en länk mellan kärnan i "studenten" och kärnan i "läraren" och detta förbindelse är ledarskapet för examensprojekten, har varje elev bara en ledare, men samma lärare kan leda en Multitude av Diploman. Därför kommer det att vara anslutningen av "en-till-många" (1: m), en från "föreläsaren" och många av studenten (se bild 7.2).

Fikon. 7,2.Ett exempel på "one-to-många" -förhållandet när det är bindande enheter "student" och "föreläsare"

I olika noteringar är kommunikationseffekten representerad på olika sätt. I vårt exempel använder vi tillämpningen av Power Designer-systemet, här är multipliciteten avbildad genom att separera kommunikationslinjen med 3. Kommunikation har ett gemensamt namn "avhandling" och har rollnamn från båda enheterna. Från sidan av studenten kallas denna roll "skriver ett diplom under ledarskapet", av läraren, kallas den här anslutningen "hantering". Den grafiska tolkningen av kommunikation gör det möjligt att omedelbart läsa meningen med förhållandet mellan enheter, det är visuellt och lätt tolkat. Kommunikation är uppdelad i tre typer av mångfald: en till en(1:1), en och och till-många(1m), många-co-många(M: m). Kommunikation En-till-ett betyder att en förekomst av en enhet är förknippad med endast en kopia av en annan enhet.

Kommunikation 1: m betyder att en instans av det företag som finns till vänster om anslutningen kan vara associerad med flera instanser av det företag som ligger till rätt till kommunikation. Kommunikation "En-till-ett" (1: 1) innebär att en kopia av en enhet endast är ansluten till en kopia av en annan enhet, och anslutningen av "Många-Ko-MNA-GIM" (M: m) betyder det En kopia av de första essenserna kan vara förknippade med flera kopior av den andra enheten, och vice versa, en instans av den andra enheten kan associeras med flera kopior av den första enheten. Om vi \u200b\u200btill exempel överväger anslutningen av typen "studier" mellan enheterna i "studenten" och "disciplin", är det här en anslutning av "många-ko-många" typen (m: m), för varje Student kan studera flera discipliner, men varje disciplin det studeras av många studenter. Används Denna anslutning är avbildad i fig. 7,3.

• Mellan två enheter kan ställas så mycket som möjligt med olika semantiska belastningar. Till exempel kan det finnas två semantiska förbindelser mellan de två enheterna "student" och "lärare", en - den tidigare anses "examen design", och den andra kan vara villkorligt benämnda "föreläsningar", och det bestämmer de föreläsningar som lärare Lyssna på den här studenten och vilka studenter den här läraren läser föreläsningar. Det är uppenbart att detta är en länktyp många-co-många.Ett exempel på dessa länkar visas i fig. 7,3.

Fikon. 7,3.Ett exempel på att modellera kommunikationen "Många-Ko-många"

• Kommunikation av någon av dessa typer kan vara obligatoriskom varje kopia av enheten ska vara inblandad i den här anslutningen, valfritt -om inte varje instans av kärnan ska delta i detta sammanhang. I det här fallet kan anslutningen vara obligatorisk på ena sidanoch valfritt på andra sidan.Kommunikation av kommunikation anges också på olika sätt i olika noteringar. Vi använder igen notationen av Power Designer. Här betecknas den valfria kommunikationen med en tom cirkel i slutet av änden och skyldigheten vinkelrätt mot linjen, korsning av anslutningen. Och denna notering har en enkel tolkning. Cirkel innebär att ingen instans kan delta i detta avseende. Och den vinkelräta tolkas som det faktum att åtminstone en tidpunkt deltar i detta avseende.

Tänk på detta, ett tidigare reducerat exempel på kommunikations "avhandlingsdesign". I vår figur tolkas den här anslutningen som valfri på båda sidor. Men i själva verket måste varje elev som skriver ett examensbevis ha sitt huvud av diplomdesignen, men å andra sidan måste inte alla lärare leda examen. Därför, i denna semantiska formulering, kommer bilden av denna anslutning att förändras och kommer att se ut så här, som presenteras i fig. 7,4.

Fikon. 7,4.Ett exempel på obligatorisk och valfri kommunikation mellan enheter

Dessutom tillåter ER-modellen principen att kategorisera enheter. Det innebär att begreppet subtyp i objektorienterade programmeringsspråk introduceras, "det finns en enhet som kan representeras i form av två eller flera subtyper - enhetervar och en kan ha gemensamma attribut och relationer och / eller attribut och relationer som bestäms en gång på toppnivån och är ärvt på lägsta nivå. Alla subtyper av en enhet anses vara ömsesidigt exklusiva, och när man skiljer kärnan i PA-subtyper, måste den representeras som en komplett uppsättning ömsesidigt exklusiva subtyper. Om det inte är möjligt att identifiera en fullständig lista över subtyper, då en speciell subtyp införs, kallas den villkorligt andra, vilket kan raffineras senare. I verkliga system är det tillräckligt att gå in i subtypen till två eller tre nivåer.

Kärnan på grundval av vilka subtyper är byggda, kallas supertype.Varje förekomst av supera är att relatera till en viss subtyp. För den grafiska bilden av principen om kategorisering eller att skriva essensen introduceras ett speciellt grafiskt element, kallas noddiskriminatori anmärkningen av kraftdesigner är den avbildad i form av en halvcirkel, en konvex sida av den vända sublet. Denna sida är ansluten av riktningspilen med superscross, och subtyperna hos denna enhet är anslutna till diametern för denna cirkel (se bild 7.5).

Fikon. 7,5.Diagram Subtypes Entity Test

Detta diagram kan dekrypteras enligt följande. Varje test i ett visst testsystem är antingen en testkontroll för SQL-kunskap, eller någon analytisk uppgift, som utförs med avancerade Java-appletter, eller ett test för någon form av kunskap, som består av en uppsättning frågor och en uppsättning svar som erbjuds till varje fråga.

Som ett resultat av byggandet av modellen i ämnesområdet, i form av en uppsättning enheter och anslutningar, får vi ett anslutet diagram. I den resulterande kolumnen är det nödvändigt att undvika konjunkturanslutningar - de upptäcker felaktigheten i modellen.

Som ett exempel utformar vi den mytologiska modellen för ett system som är utformat för att lagra information om böcker med kunskapsområden som presenteras i biblioteket. Beskrivningen av ämnesområdet har tidigare tillhandahållits. Utvecklingen av modellen börjar med fördelningen av de viktigaste enheterna.

Först och främst är det kärnan i "böcker", varje bok har en unik chiffer, skorpan är dess nyckel och ett antal attribut som tas från beskrivningen av ämnesområdet. Många essensinstanser definierar många böcker som lagras i biblioteket. Varje förekomst av företaget i "boken" motsvarar en specifik bok som står på hyllan, men beskriver en bok, som vanligtvis ges i biblioteksobjektkatalogen. Varje bok kan vara närvarande i flera kopior, och det här är bara de specifika böcker som står på bibliotekshyllorna.

För att återspegla det måste vi komma in i kärnan i "instanser", vilket kommer att innehålla beskrivningar av alla kopior av böcker som lagras i biblioteket. Varje förekomst av enheten av "instanser" motsvarar en specifik bok på hyllan. Varje kopia har ett unikt inventeringsnummer, som unikt definierar en specifik bok. Dessutom kan varje kopia av boken vara antingen i biblioteket, eller i händerna på någon läsare, och i det senare fallet, för det här fallet, ett ytterligare referensdatum för läsaren och datumet för den påstådda avkastningen av boken anges.

Det finns en länk mellan enheterna "böcker" och "kopior" (1: m), obligatorisk på båda sidor. Vad bestämmer denna typ av kommunikation? Vi kan anta att varje bok kan vara närvarande i biblioteket i flera kopior, så anslutningen "en till många". Samtidigt, om det inte finns en enda dikbokskopia i biblioteket, så kommer vi inte att lagra sin beskrivning, så om boken beskrivs i kärnan av "böcker", är minst en kopia av den här boken närvarande i biblioteket. Det innebär att anslutningen i den del av boken är obligatorisk. När det gäller kärnan i "kopior" kan den inte existera i biblioteket, inte en enda kopia, vilket inte skulle vara relaterat till en viss bok, därför, från "kopior", är anslutningen också obligatorisk.

Nu måste vi bestämma hur läsaren kommer att presenteras i vårt system. Naturligtvis föreslås det att komma in i företaget "läsare" för detta, varav varje fall motsvarar en specifik läsare. I biblioteket tilldelas varje läsare ett unikt antal av läsaren, som definitivt kommer att identifiera vår läsare. Läsarens läsare kommer att vara nyckelattributet för företaget "läsare".

Dessutom måste i kärnan av "läsare" vara ytterligare attribut som krävs för att lösa de angivna uppgifterna, dessa attribut kommer att vara: "Efternamn Namn Patronymic", "Reader's Adress", "Home Phone" och "Phone Working". Varför introducerade vi två separata attribut för telefonerna? Eftersom det är nödvändigt att ringa till dessa telefoner vid olika tidpunkter för att fånga läsaren, så är bibliotekets administration viktigt att veta vilken typ den här telefonen tillhör. I beskrivningen av vårt ämnesområde finns det en gräns för våra läsares ålder, så i kärnan av "läsare" är det nödvändigt att införa ett obligatoriskt attribut "Födelsedatum", vilket gör det möjligt för oss att kontrollera åldern av våra läsare.

Från beskrivningen av ämnesområdet vet vi att varje läsare kan hålla flera kopior av böcker i händerna. För att återspegla denna situation måste vi kommunicera mellan enheterna "läsare" och "exemplar". Och varför inte mellan enheterna "läsare" och "böcker"? Eftersom läsaren tar en specifik kopia av en viss bok från biblioteket, och inte bara en bok. Och hur man tar reda på vad en bok från denna läsare? Och det här finns i den extra sambandet mellan enheterna i "kopior" och "böckerna", och den här anslutningen gör en av boken i enlighet med en bok, så vi kan definitivt bestämma vilka böcker som finns på dina händer på läsaren , även om vi associerar med läsaren bara inventeringsrum tagna böcker. Mellan enheterna "läsare" och "exemplar" etablerar länken "en-till-många", och samtidigt är det inte obligatoriskt på båda sidor. Läsaren för tillfället kanske inte håller en enda bok till hands, men å andra sidan kan denna instans av boken inte vara någon läsare, men bara stå på hyllan i biblioteket.

Nu måste vi återspegla den senaste enheten, som är förknippad med systemkatalogen. Systemkatalogen innehåller en lista över alla kunskapsområden, information som finns i biblioteksböcker. Vi kan komma ihåg systemkatalogen i biblioteket från vilket vi brukar börja hitta de böcker du behöver om vi inte känner till sina författare och namn. Namnet på kunskapsområdet kan vara länge och bestå av flera ord, så att modellera systemkatalogen, introducerar vi företaget "Systemkatalog" med två attribut: "Knowledge Area" och "Namn på kunskapsområde". Attributet "Kunskapsområde" kommer att vara ett viktigt enhetsattribut.

Från beskrivningen av ämnesområdet vet vi att varje bok kan innehålla information från flera kunskapsområden, och å andra sidan är det känt från praktiken att många böcker som rör samma kunskap kan vara närvarande i biblioteket, Så vi måste etablera mellan enheter "Systemkatalog" och "böcker" kommunikation "mogye-to-många", obligatorisk från två sidor. Faktum är att kunskapssystemet inte är närvarande i systemkatalogen, den information som inte presenteras i någon bok i vårt bibliotek, skulle det vara meningslöst. Och tillbaka måste varje bok hänföras till ett eller flera kunskapsområden så att läsaren kan hitta den snabbare.

Den mytologiska modellen för ämnesområdet "Bibliotek" presenteras i FIG. 7,6.

Fikon. 7,6.Mytologiska modell "Bibliotek"

Det mytologiska modellen "Bibliotek" är utvecklat av oss under de uppgifter som tidigare listats. I dessa utmaningar ställde vi inte förutsättningen för lagring av historien att läsa en bok, till exempel för att söka efter den som tidigare hade hållit boken och kunde skada henne eller glömma det av en slump av en stor mängd av pengar. Om vi \u200b\u200bställer oss själva uppgiften att lagra och den här informationen, skulle vår information logisk modell vara annorlunda. Jag kommer att lämna den här uppgiften för din självständiga kreativitet.