Infologisk datamodell "entity-relationship". Automatisering av arbetsplatsen för en kontorsuthyrningschef


"Grundläggande koncept

Syftet med informationsmodellering är att tillhandahålla de mest naturliga sätten för människor att samla in och presentera den information som är tänkt att lagras i databasen som skapas data. Därför försöker de bygga en infologisk datamodell i analogi med naturligt språk (det senare kan inte användas i sin rena form på grund av komplexiteten i datortextbehandling och tvetydigheten i alla naturligt språk). De huvudsakliga konstruktiva delarna av informationsmodeller är enheter, kopplingar mellan dem och deras egenskaper (attribut).

En entitet är vilket som helst särskiljbart objekt (ett objekt som vi kan skilja från ett annat), information om vilket måste lagras i en databas. Entiteter kan vara människor, platser, flygplan, flyg, smak, färg etc. Det är nödvändigt att skilja mellan begrepp som entitetstyp och entitetsinstans. Begreppet en entitetstyp hänvisar till en uppsättning homogena individer, objekt, händelser eller idéer som fungerar som en helhet. En entitetsinstans hänvisar till en specifik sak i en uppsättning. Entitetstypen kan till exempel vara CITY, och instansen kan vara Moskva, Kiev, etc.

Ett attribut är en namngiven egenskap hos en entitet. Dess namn måste vara unikt för en specifik enhetstyp, men kan vara detsamma för olika typer entiteter (till exempel kan FÄRG definieras för många entiteter: HUND, BIL, SMOKE, etc.). Attribut används för att definiera vilken information som ska samlas in om en enhet. Exempel på attribut för CAR-entiteten är TYPE, MAKE, LICENSE PLATE, COLOR, etc. Även här finns det en skillnad mellan typ och instans. Attributtypen COLOR har många instanser eller värden:

Röd, blå, banan, vit natt, etc.,

Varje entitetsinstans tilldelas dock endast ett attributvärde.

Det finns ingen absolut skillnad mellan enhetstyper och attribut. Ett attribut är endast sådant i förhållande till entitetstypen. I ett annat sammanhang kan ett attribut fungera som en självständig enhet. Till exempel, för en bilfabrik är färg bara ett attribut för produktionsprodukten, men för en färg- och lackfabrik är färg en typ av enhet.

En nyckel är en minsta uppsättning attribut vars värden kan användas för att unikt hitta den nödvändiga instansen av en entitet. Minimalitet innebär att exkludering av något attribut från uppsättningen inte tillåter att enheten identifieras av de återstående. För Schema-entiteten (klausul 1.2) är nyckeln attributet Flight_number eller uppsättningen av: Departure_point, Departure_time och Destination_point (förutsatt att ett plan flyger från punkt till punkt vid varje tidpunkt).

En relation är en sammanslutning av två eller flera enheter. Om syftet med databasen bara var att lagra individuella, orelaterade data, så kan dess struktur vara mycket enkel. Ett av huvudkraven för att organisera en databas är dock att säkerställa möjligheten att hitta vissa enheter genom andras värden, för vilka det är nödvändigt att upprätta mellan dem vissa samband. Och eftersom riktiga databaser ofta innehåller hundratals eller till och med tusentals enheter, kan teoretiskt mer än en miljon kopplingar upprättas mellan dem. Närvaron av en sådan mängd kopplingar bestämmer komplexiteten hos informationsmodeller.

Kännetecken för samband och modelleringsspråk

När du bygger informationsmodeller kan du använda språket för ER-diagram (från engelska Entity-Relationship, d.v.s. entity-relationship). I dem avbildas enheter som markerade rektanglar, associationer som markerade diamanter eller hexagoner, attribut som markerade ovaler och anslutningar mellan dem som icke-riktade kanter, över vilka graden av anslutning (1 eller en bokstav som ersätter ordet "många"). och den nödvändiga förklaringen kan anges.

Mellan två enheter, till exempel A och B, är fyra typer av anslutningar möjliga.

Första typen– EN-TILL-EN-relation (1:1): vid varje tidpunkt motsvarar varje representant (instans) för enhet A 1 eller 0 representanter för enhet B:

En student får inte "tjäna" ett stipendium, få ett vanligt stipendium eller få något av de utökade stipendierna.

Andra typen– EN-TILL-MÅNGA-relation (1:M): en representant för enhet A motsvarar 0, 1 eller flera representanter för enhet B.

Lägenheten kan stå tom, en eller flera boende kan bo i den.

Eftersom anslutningar i båda riktningarna är möjliga mellan två entiteter, finns det ytterligare två typer av relationer: MÅNGA-TILL-EN (M:1) och MÅNGA-TILL-MÅNGA (M:N).

Exempel 2.1. Om kopplingen mellan entiteterna MAN och KVINNA kallas Äktenskap, så finns det fyra möjliga representationer av en sådan koppling:

Typen av kopplingar mellan enheter är inte begränsad till de som anges. Det finns också mer komplexa samband:

många kopplingar mellan samma enheter

(en patient som har en behandlande läkare kan också ha flera konsulterande läkare; en läkare kan vara behandlande läkare för flera patienter och kan samtidigt konsultera flera andra patienter);

Träningsförbindelser

ENTITY (attribut 1, attribut 2, ..., attribut n) ASSOCIATION [ENTITY S1, ENTITY S2, ...] (attribut 1, attribut 2, ..., attribut n)

där S är graden av koppling, och de attribut som ingår i nyckeln måste markeras med ett understreck.

Således kan ovanstående exempel på en uppsättning kopplingar mellan enheter beskrivas i NAM enligt följande:

Läkare (läkarnummer, efternamn, förnamn, patonym, specialitet)Patient (registreringsnummer, sängnummer, efternamn, förnamn, patonym, adress, födelsedatum, kön) Behandlande_läkare [läkare 1, patient M] (läkarnummer, registreringsnummer) Konsult [läkare M, patient N] (läkarnummer, registreringsnummer).

Ris. 2.1. Exempel på ER-diagram

För att identifiera relationer mellan enheter är det nödvändigt att åtminstone definiera enheterna själva. Men det är det inte enkel uppgift, eftersom samma objekt inom olika ämnesområden kan vara en enhet, attribut eller association. Låt oss illustrera detta uttalande med exempel relaterade till beskrivningen av äktenskapliga band (se exempel 2.1).

Exempel 2.2. Folkbokföringsverket (ZAGS) har inte med alla människor att göra, utan endast de som har ansökt om att få registrera vigsel, födelse eller död. Därför, i länder där endast traditionella äktenskap är tillåtna, kan folkbokföringskontor lägga upp information om registrerade äktenskap i en enda enhet:

Äktenskap (Certifikatnummer, mannens efternamn, mannens förnamn, mannens patronym, mannens födelsedatum, hustruns efternamn, ... , registreringsdatum, registreringsort, ...),

ER-diagrammet som visas i fig. 2.1, b.

Exempel 2.3. Tänk nu på en situation där folkbokföringskontoret är beläget i ett land som tillåter polygami. Om du använder enheten "Äktenskap" i exempel 2.2 för att registrera äktenskap, kommer information om män som har flera fruar att dupliceras (se tabell 2.1).

Tabell 2.1

Certifikatnummer Makens efternamn ... Hustruns efternamn ... Registrerings datum
1-YUB 154745 Petukhov ... Kurochkina ... 06/03/1991
1-YUB 163489 Petukhov ... Pestrushkina ... 11/08/1991
1-UB 169887 Petukhov ... Ryabova ... 12/12/1992
1-UB 169878 Seleznev ... Utochkina ... 12/12/1992
1-UB 154746 Parasyuk ... Svinyushkina ... 06/03/1991
1-UB 169879 Parasyuk ... Khavronia ... 12/12/1992
... ... ... ... ... ...

Duplicering kan elimineras genom att skapa en ytterligare enhet "män"

Makar (Code_M, Efternamn, Förnamn, Patronymic, Födelsedatum, Födelseort)

och att ersätta enheten "Äktenskap" med en egenskap (se punkt 2.3) med hänvisning till motsvarande beskrivning i enheten "Makar".

Vigsel (Intygsnummer, Kod_M, Hustruns efternamn, ..., Registreringsdatum, ...) (Makar).

ER-diagrammet för kopplingen mellan dessa enheter visas i fig. 2.1,c, och ett exempel på deras kopior finns i tabellen. 2.2 och 2.3.

Tabell 2.2

Tabell 2.3

Certifikatnummer Kod_M Hustruns efternamn Hustruns namn Registrerings datum ...
1-YUB 154745 111 Kurochkina Augustinus 06/03/1991 ...
1-YUB 163489 111 Pestrushkina Mariana 11/08/1991 ...
1-UB 169877 111 Ryabova Milano 12/12/1992 ...
1-UB 169878 112 Utochkina Veronica 12/12/1992 ...
1-UB 154746 113 Svinyushkina Elvira 06/03/1991 ...
1_UB 169879 113 Khavronia Rufina 12/12/1992 ...
... ... ... ... ... ...

Exempel 2.4. Slutligen, överväg fallet när en organisation behövde uppgifter om närvaron av gifta par i den, och det fanns redan en enhet för att lagra information om anställda

Anställda (Personal_number, Efternamn, Förnamn, ...).

Användningen av enheten "Äktenskap" som diskuteras i exempel 2.2 är olämplig: "Anställda" innehåller redan makarnas efternamn, förnamn och patronymer. Låt oss därför skapa en förening

Äktenskap [Anställd 1, Anställd 1] (Personal_number of makes, Personal_number of wife, ...),

ansluter vissa instanser av "Anställda"-enheten (Fig. 2.1,d).

Sammanfattningsvis noterar vi att ER-diagrammet Fig. 2.1a beskriver strukturen för att placera data om äktenskap i folkbokföringskontoren i länder som tillåter gruppäktenskap, och ER-diagrammen i exempel 2.1 beskriver alla typer av äktenskap i organisationer där det finns enheter "män" och "kvinnor", inklusive ensamstående och ogifta människor.

Vad är "anslutning"? I ER-diagram är detta en linje som förbinder geometriska former som visar enheter, attribut, associationer och andra informationsobjekt. I texten används denna term för att indikera det ömsesidiga beroendet mellan enheter. Om detta ömsesidiga beroende har attribut, kallas det en association.

Enhetsklassificering

Det är dags att förstå terminologin. K. Date definierar tre huvudklasser av entiteter: kärna, associativa och karakteristiska, samt en underklass av associativa enheter - beteckningar.

En kärnenhet (pivot) är en oberoende enhet (den kommer att definieras mer i detalj nedan).

I de tidigare diskuterade exemplen är stavarna "Student", "Lägenhet", "Män", "Doktare", "Äktenskap" (från exempel 2.2) och andra, vars namn är placerade i rektanglar.

En associativ enhet (association) är en "många-till-många" ("-till-många", etc.) relation mellan två eller flera enheter eller instanser av en enhet (som i exempel 2.4). Föreningar behandlas som fullvärdiga enheter:

de kan delta i andra föreningar och beteckningar precis som kärnenheter;

kan ha egenskaper, d.v.s. har inte bara en uppsättning nyckelattribut som är nödvändiga för att indikera relationer, utan även valfritt antal andra attribut som kännetecknar relationen. Till exempel innehåller föreningarna "Äktenskap" från exempel 2.1 och 2.4 nyckelattribut”Code_M”, ”Code_Zh” och ”Makens personalnummer”, ”Hustruns personalnummer”, samt förtydligande attribut ”Certifikatnummer”, ”Registreringsdatum”, ”Registreringsplats”, ”Registreringsnummer i kansliboken” etc. .

En karakteristisk enhet (karakteristisk) är en mång-till-en- eller en-till-en-relation mellan två enheter ( specialfall föreningar). Det enda syftet med egenskapen inom ramen för den övervägda ämnesområde består i att beskriva eller förtydliga någon annan enhet. Behovet av dem uppstår på grund av det faktum att enheter i den verkliga världen ibland har flera värdefulla egenskaper. En man kan ha flera fruar (exempel 2.3), en bok kan ha flera egenskaper hos ett nytryck (korrigerat, utökat, reviderat, ...), etc.

Förekomsten av en egenskap beror helt på den enhet som karakteriseras: kvinnor förlorar sin status som hustru om deras man dör.

För att beskriva egenskapen används ett nytt JIM-förslag som i allmänhet har formen:

KARAKTERISTISK (attribut 1, attribut 2, ...) (LISTA ÖVER KARAKTERISERADE ENHETER).

Låt oss också utöka språket för ER-diagram genom att introducera en trapets som representerar egenskaperna (Fig. 2.2).

Ris. 2.2. Element i det utökade ER-diagramspråket

En designerande enhet eller beteckning är en mång-till-en- eller en-till-en-relation mellan två enheter och skiljer sig från en egenskap genom att den inte är beroende av den utpekade enheten.

Låt oss överväga ett exempel relaterat till registreringen av anställda i olika avdelningar i organisationen.

I avsaknad av strikta regler (en anställd kan samtidigt vara inskriven på flera avdelningar eller inte vara inskriven på någon avdelning), är det nödvändigt att skapa en beskrivning med föreningen Enrollment:

Avdelningar (Avdelningsnummer, Avdelningens namn, ...)Anställda (Personalnummer, Efternamn, ...)Inskrivning [Avdelningar M, Anställda N] (Avdelningsnummer, Personalnummer, Inskrivningsdatum).

Förutsatt att varje anställd måste vara inskriven på någon av avdelningarna kan du dock skapa en beskrivning med beteckningen Anställda:

Avdelningar (Avdelningsnummer, Avdelningsnamn, ...)Anställda (Personalnummer, Efternamn, ..., Avdelningsnummer, Inskrivningsdatum)[Avdelningar]

I i detta exempel anställda har en självständig existens (om en avdelning raderas, följer det inte att de anställda på den avdelningen också måste tas bort). Därför kan de inte vara kännetecken för avdelningar och kallas beteckningar.

Notationer används för att lagra återkommande värden för stora textattribut: "kodifierare" av discipliner som studerats av studenter, namn på organisationer och deras avdelningar, listor över varor, etc.

Beskrivningen av en beteckning skiljer sig externt från beskrivningen av en egenskap endast genom att de angivna enheterna inte är tandställning, och i kvadrat:

DESIGNATION (attribut 1, attribut 2, ...) [LISTA ÖVER DESIGNATEDE ENHETER].

Vanligtvis behandlas inte beteckningar som fullständiga enheter, även om detta inte skulle leda till några fel.

Beteckningar och egenskaper är inte helt oberoende enheter, eftersom de förutsätter att det finns någon annan enhet som kommer att "utses" eller "karakteriseras". De representerar dock fortfarande speciella väsen och kan naturligtvis ha egenskaper, kan delta i föreningar, beteckningar och ha sina egna (mer låg nivå) egenskaper. Vi betonar också att alla instanser av en egenskap måste associeras med någon instans av den karakteriserade enheten. Det är dock tillåtet att vissa instanser av den karakteriserade enheten inte har relationer. Det är sant att om detta gäller äktenskap, bör essensen av "män" ersättas med essensen av "män" (det finns ingen man utan en fru).

Låt oss nu omdefiniera kärnenheten som en enhet som varken är en association, eller en beteckning eller en egenskap. Sådana enheter har en oberoende existens, även om de kan utse andra enheter, till exempel anställda som utser avdelningar.

Avslutningsvis, låt oss överväga ett exempel på att konstruera en informationsmodell av databasen "Nutrition", där information om rätter (Fig. 2.3), deras dagliga konsumtion, produkterna från vilka dessa rätter tillagas och leverantörerna av dessa produkter bör lagras. Informationen kommer att användas av kocken och chefen för en liten cateringanläggning, samt dess besökare.

Ris. 2.3. Exempel på recept

Med hjälp av dessa användare identifierades följande objekt och egenskaper hos den designade basen:

Rätter som kräver data som ingår i deras kulinariska recept för att beskriva: rättens nummer (till exempel från en bok med kulinariska recept), namnet på rätten, typ av rätt (förrätt, soppa, huvudrätt, etc.), recept (teknik för förbereda rätten), avkastning (portionsvikt), namn, kaloriinnehåll och vikt för varje produkt som ingår i rätten. För varje produktleverantör: namn, adress, namn på levererad produkt, leveransdatum och pris vid leveranstillfället. Daglig matkonsumtion (konsumtion): rätt, antal portioner, datum.

Analys av objekt låter oss lyfta fram:

Spön Diskar, produkter och städer; föreningar Komposition (länkar Rätter med Produkter) och

Tillbehör (länkar leverantörer till produkter);

Beteckning Leverantörer; egenskaper Recept och konsumtion.

ER-diagrammet för modellen visas i fig. 2.4. och modellen på YAM-språket har följande form:

Rätter (BL, Fat, Typ)Produkter (PR, Produkt, Kaloriinnehåll)Leverantörer (POS, Stad, Leverantör) [Stad]Komposition [Rätter M, Produkter N] (BL, PR, Vikt (g))Förråd [Leverantörer M] , Produkter N] (POS, PR, Date_P, Pris, Vikt (kg))Städer (Stad, Land) Recept (BL, Recept) (Rätter)Konsumption (BL, Date_P, Portioner) (Rätter)

I dessa modeller är Dish, Product och Supplier namn, och BL, PR och POS är det digitala koder rätter, produkter och organisationer som tillhandahåller dessa produkter.

Ris. 2.4. Infologisk modell av databasen "Nutrition".

Om primära och främmande nycklar

Kom ihåg att en nyckel eller möjlig nyckel är en minsta uppsättning attribut vars värden kan användas för att unikt hitta den nödvändiga instansen av en entitet. Minimalitet innebär att exkludering av något attribut från uppsättningen inte tillåter att enheten identifieras av de återstående. Varje enhet har minst en möjlig nyckel. En av dem tas som primärnyckel. När man väljer primärnyckel företräde bör ges till icke-sammansatta nycklar eller nycklar som består av ett minsta antal attribut. Det är också orådligt att använda nycklar med långa textvärden(det är att föredra att använda heltalsattribut). Så för att identifiera en student kan du använda antingen unikt nummer betygsbok, eller en uppsättning efternamn, förnamn, patronym, gruppnummer och kanske ytterligare attribut, eftersom det är möjligt att två elever (och oftare kvinnliga elever) med samma efternamn, förnamn och patronymer kommer att förekomma i gruppen. Det är också dåligt att använda som nyckel, inte numret på rätten, utan dess namn, till exempel "Förrätt på smältost "Vänskap" med skinka och inlagd gurka" eller "Hare i gräddfil med potatiskroketter och rödkålssallad .”

Primärnyckeln för en kärnenhet (alla attribut som deltar i primärnyckeln) får inte ha ett odefinierat värde. Annars kommer en motsägelsefull situation att uppstå: en icke-individuell, och därför obefintlig, instans av kärnessensen kommer att dyka upp. Av samma skäl är det nödvändigt att säkerställa att den primära nyckeln är unik.

Nu om främmande nycklar:

Om entitet C länkar entitet A och B, måste den inkludera främmande nycklar som motsvarar primärnycklarna för entitet A och B. Om entitet B hänvisar till entitet A, måste den inkludera en främmande nyckel som motsvarar primärnyckeln för entitet A.

I avsnitt 2.3 övervägdes ett exempel där "Anställda" betecknade "Avdelningar" och inkluderade en främmande nyckel "Avdelningsnummer" motsvarande primärnyckeln för enheten "Avdelningar".

Förhållandet mellan primära och främmande nycklar för enheter illustreras i fig. 2.5.

Ris. 2.5. Strukturer: a - föreningar; b - beteckningar (egenskaper)

Här, för att beteckna någon av de associerade enheterna (kärnor, egenskaper, beteckningar eller till och med associationer), används en ny generaliserande term "Mål" eller "Målenhet".

Så när man överväger problemet med att välja ett sätt att representera associationer och notationer i en databas, är huvudfrågan som måste besvaras: "Vad är främmande nycklar?" Och sedan, för varje främmande nyckel, måste tre frågor lösas:

1. Kan denna främmande nyckel acceptera odefinierade värden (NULL-värden)? Med andra ord, kan det finnas någon instans av en enhet av denna typ, för vilken målentiteten som indikeras av den främmande nyckeln är okänd? När det gäller leveranser är detta förmodligen inte möjligt - en leverans från en okänd leverantör eller en leverans av en okänd produkt är inte meningsfull. Men när det gäller anställda kan en sådan situation dock vara vettig - det är fullt möjligt att någon anställd i det här ögonblicket inte inskriven på någon avdelning alls. Observera att svaret på denna fråga inte beror på databasdesigners nyck, utan bestäms av det faktiska tillvägagångssättet i den del av den verkliga världen som ska representeras i databasen i fråga. Liknande kommentarer är relevanta för de frågor som diskuteras nedan.

2. Vad ska hända när du försöker RADERA en målenhet som refereras av en främmande nyckel? Till exempel vid radering av en leverantör som har gjort minst en leverans. Det finns tre möjligheter:

3. Vad ska hända när du försöker UPPDATERA primärnyckeln för en målenhet som refereras av någon främmande nyckel? Exempelvis kan ett försök göras att uppdatera numret på en leverantör för vilken det finns minst en motsvarande leverans. För att vara tydlig kommer vi återigen att överväga detta fall mer i detalj. Du har samma tre alternativ som när du raderar:

KASKADER Uppdateringsoperationen är "kaskadad" för att även uppdatera den främmande nyckeln i den leverantörens leveranser.
BEGRÄNSAD. Primärnycklarna för endast de leverantörer som ännu inte har gjort leveranser uppdateras. Annars avvisas uppdateringen.
INSTALLERAD För alla leveranser från den leverantören sätts NULL-värdet för den främmande nyckeln till odefinierat, och sedan uppdateras leverantörens primärnyckel. Denna funktion är naturligtvis inte tillämplig om den främmande nyckeln inte får innehålla NULL-värden.

Sålunda, för varje främmande nyckel i en design måste databasdesignern ange inte bara fältet eller kombinationen av fält som utgör den främmande nyckeln och måltabellen som identifieras av den nyckeln, utan också svaren på ovanstående frågor (den tre begränsningar som gäller för denna främmande nyckel).

Slutligen, om egenskaper - betecknar enheter, vars existens beror på typen av angivna enheter. Beteckningen representeras av en främmande nyckel i tabellen som motsvarar den egenskapen. Men de tre utländska nyckelrestriktioner som diskuterats ovan för det här fallet bör specificeras enligt följande:

NULL-värden är inte tillåtna DELETE FROM (mål) CASCADED UPDATE (målprimärnyckel) CASCADED

De specificerade specifikationerna representerar beroende av förekomsten av karakteristiska enheter.

Integritetsbegränsningar

Integritet (från engelska integrity - intactness, inviolability, safety, integrity) förstås som riktigheten av data när som helst. Men detta mål kan bara uppnås inom vissa gränser: DBMS kan inte kontrollera riktigheten av varje enskilt värde som matas in i databasen (även om varje värde kan kontrolleras för rimlighet). Till exempel kan det inte upptäckas att ingångsvärdet 5 (representerar veckodagen) faktiskt borde vara 3. Å andra sidan skulle värdet 9 helt klart vara ett fel och bör avvisas av DBMS. Men för att göra detta bör hon få veta att siffrorna för veckodagarna måste tillhöra uppsättningen (1,2,3,4,5,6,7).

Att upprätthålla databasens integritet kan ses som att skydda data från obehöriga ändringar eller förstörelse (inte att förväxla med obehöriga ändringar och förstörelse, som är en säkerhetsfråga). Moderna DBMS har ett antal sätt att säkerställa att integriteten upprätthålls (liksom medel för att säkerställa att säkerheten upprätthålls).

Det finns tre grupper av integritetsregler:

Entitetsintegritet. Referensintegritet. Användardefinierad integritet.

I avsnitt 2.4 har motiveringen för två integritetsregler, gemensamma för ev relationsdatabaser data.

Alla attribut som deltar i en primärnyckel får inte ha ett odefinierat värde. Värdet på den främmande nyckeln måste antingen: vara lika med värdet på målets primärnyckel; vara helt osäker, d.v.s. varje attributvärde som är involverat i främmande nyckel måste vara odefinierat. För varje specifik databas finns det ett antal ytterligare specifika regler som gäller enbart för den och som bestäms av utvecklaren. Oftast kontrolleras:

det unika hos vissa attribut,
värdeintervall (examenspoäng från 2 till 5),
tillhör en uppsättning värden (kön "M" eller "F").

Om att bygga en informationsmodell

En läsare som bara har bekantat sig med materialet i detta och de föregående kapitlen kommer inte att korrekt uppfatta och utvärdera de tips och rekommendationer för att bygga en bra informationsmodell, som har utvecklats under decennier av de största specialisterna inom området databehandling. För att göra detta måste du åtminstone studera följande material. Helst är det nödvändigt för läsaren att först implementera minst ett informationssystemprojekt och föreslå det riktiga användare och har varit databas- och applikationsadministratör tillräckligt länge för att känna igen åtminstone en liten del av problemen som uppstår från dåligt genomtänkta design. Erfarenheten från författaren och alla informationssystemspecialister han känner visar att alla teoretiska rekommendationer tas på allvar först efter flera misslyckade försök att återuppliva dåligt designade system. (Även om det också finns designers som fortsätter att tro att de kan återuppliva ett döende projekt genom att byta program, snarare än genom att ändra databasens infologiska modell.)

För att bestämma listan och strukturen för lagrad data är det faktiskt nödvändigt att samla in information om verkliga och potentiella applikationer, såväl som om databasanvändare, och när du bygger en informationsmodell bör du bara bry dig om tillförlitligheten av att lagra dessa data, helt glömma de applikationer och användare för vilka databasen skapas data

Detta beror på de helt olika kraven på databasen över applikationsprogrammerare och databasadministratören. De förra vill ha på ett ställe (till exempel i en tabell) all data de behöver för att implementera en fråga från applikationsprogram eller från terminalen. De senare tar hand om att eliminera eventuella förvrängningar av lagrad data vid inmatning av ny information i databasen och uppdatering eller radering av befintlig information. För att göra detta tar de bort dubbletter och oönskade funktionella relationer mellan attribut från databasen, vilket delar upp databasen i många små tabeller (se avsnitt 4.6). Sedan många års global erfarenhet av att använda informationssystem, byggd på basen av databaser, visar att bristerna i projektet inte kan elimineras med några knep i applikationsprogram, då tillåter erfarna designers sig inte att möta applikationsprogrammerare halvvägs (även när de själva är sådana).

Skilj tydligt mellan sådana begrepp som att begära data och underhålla data (inmatning, ändring och radering); kom ihåg att som regel är databasen informationsunderlag inte en, utan flera applikationer, av vilka några kommer att dyka upp i framtiden; en dålig databasdesign kan inte korrigeras av några (även de mest sofistikerade) applikationerna. LITTERATUR Atre Sh. Strukturellt tillvägagångssätt att organisera databaser. – M.: Finans och statistik, 1983. – 320 sid. Boyko V.V., Savinkov V.M. Design av informationssystemdatabaser. – M.: Finans och statistik, 1989. – 351 sid. Datum K. Guide till DB2 relations-DBMS. – M.: Finans, 1990. – 386 sid. Hubbard J. Automatiserad databasdesign. – M.: Mir, 1984. – 294 sid. Tsikritisis D., Lochowski F. Datamodeller. – M.: Finans och statistik, 1985. – 344 sid.

Databasen är grunden för hela systemet och frågan om eventuell utlåning avgörs ofta av bankexperter utifrån ett välgjort informationsdatabasprojekt. Därför måste informationsmodellen innehålla en sådan formaliserad beskrivning ämnesområde, som kommer att vara lätt att "läsa" inte bara av databasspecialister. Och denna beskrivning bör vara så rymlig att det är möjligt att bedöma djupet och riktigheten av utvecklingen av databasprojektet, och naturligtvis, som tidigare nämnt, bör den inte vara knuten till ett specifikt DBMS. Att välja ett DBMS är en separat uppgift för att lösa det korrekt, du behöver ha ett projekt som inte är knutet till något specifikt DBMS.

Infologisk design förknippas i första hand med ett försök att representera semantik ämnesområde i databasmodellen. Den relationella datamodellen tillåter, på grund av sin enkelhet och korthet, inte visning av semantik, det vill säga betydelsen ämnesområde. Tidiga grafteoretiska modeller speglade semantik i större utsträckning ämnesområde. De definierade uttryckligen hierarkiska relationer mellan objekt ämnesområde.

Problemet med att representera semantik har länge varit av intresse för utvecklare, och på sjuttiotalet kallade flera datamodeller semantiska modeller. Dessa inkluderar semantisk modell data, föreslagna Hummer (Hammare) Och McLeon (McLeon) 1981, en funktionell datamodell Shipman (Shipman), som också skapades 1981, den enhetsrelationsmodell som föreslagits av Chen (Chen) 1976, och ett antal andra modeller. Alla modeller hade sina positiva och negativa sidor, men bara den sistnämnda har bestått tidens tand. Och i för närvarande Det var Chens Entity Relationship-modell som blev de facto-standarden för infologisk databasmodellering. Det förkortade namnet ER-modell har blivit allmänt accepterat, de flesta moderna CASE-verktyg innehålla verktyg att beskriva data i denna modells formalism. Dessutom har metoder utvecklats för att automatiskt konvertera ett databasprojekt från en ER-modell till en relationell, där konverteringen görs till en datalogisk modell motsvarande ett specifikt DBMS. Alla CASE-system har utvecklat verktyg för att dokumentera databasutvecklingsprocessen med automatiska rapportgeneratorer detaljerad beskrivning databasobjekt och deras relationer som i grafisk form, och i form av färdiga standardutskrivna rapporter, vilket i hög grad underlättar projektledningen.

För tillfället finns det inget enskilt allmänt accepterat notationssystem för ER-modellen och olika CASE-system använder olika grafiska notationer, men när du väl förstår en kan du enkelt förstå andra notationer.

Entitetsrelationsmodell

Liksom alla modeller har "entity-relationship"-modellen flera grundläggande begrepp som bildar de initiala tegelstenarna från vilka fler komplexa objekt enligt förutbestämda regler.

Denna modell är mest förenlig med konceptet objektorienterad design, som för närvarande utan tvekan är grunden för utvecklingen av komplexa mjukvarusystem, så många av begreppen kan verka bekanta för dig, och om detta är sant, desto lättare blir det för dig att behärska databasdesignteknik baserad på ER-modellen.

ER-modellen bygger på följande grundläggande koncept:

  • Väsen, med hjälp av vilken en klass av liknande objekt modelleras. En enhet har ett namn som är unikt inom systemet som modelleras. Eftersom en entitet motsvarar en viss klass av objekt av samma typ, antas det att det finns många instanser av denna entitet i systemet. Objektet som begreppet entitet motsvarar har sin egen uppsättning attribut - egenskaper som bestämmer egenskaperna hos en given klassrepresentant. I det här fallet måste uppsättningen av attribut vara sådan att det är möjligt att särskilja specifika instanser av enheten. Till exempel kan den anställdas enhet ha följande uppsättning attribut: Personalnummer, Efternamn, Förnamn, Patronym, Födelsedatum, Antal barn, Närvaro av släktingar utomlands. En uppsättning attribut som unikt identifierar en specifik enhetsinstans, ringde nyckel.För anställd entitet kommer nyckelattributet att vara personalnummer, eftersom för alla anställda av detta företag antalet anställda kommer att vara annorlunda. En instans av den anställda enheten kommer att vara en beskrivning av en specifik anställd i företaget. En av de allmänt accepterade grafiska symboler entiteter - en rektangel, i den övre delen av vilken namnet på enheten är skrivet, och attributen listas nedan, med nyckelattribut markerade, till exempel med understrykningar eller ett speciellt teckensnitt (Fig. 7.1):


    Ris. 7.1.

    Mellan enheter kan ställas in kommunikation - binära associationer, som visar hur enheter relaterar till eller interagerar med varandra. En relation kan existera mellan två olika enheter eller mellan en enhet och sig själv (rekursiv anslutning).Den visar hur entitetsinstanser är relaterade till varandra. Om en relation upprättas mellan två enheter, definierar den relationen mellan instanser av den ena och den andra enheten. Om vi ​​till exempel har en koppling mellan entiteten "Student" och "Lärare", och denna koppling är handledning av diplomprojekt, har varje student bara en handledare, men samma lärare kan handleda många doktorander. Därför blir det en en-till-många-relation (1:M), en på Lärarsidan och många på Elevsidan (se figur 7.2).


    Ris. 7.2. Ett exempel på en en-till-många-relation när enheterna "Student" och "Lärare" länkas

    Olika notationer uttrycker kommunikationskraft olika. I vårt exempel använder vi CASE-notation POWER-system DESIGNER, här avbildas mångfalden genom att dela länken i 3. Länken har ett gemensamt namn för "Diploma Design" och har rollnamn från båda enheternas sida. Från elevens sida kallas denna roll "Skriver en uppsats under vägledning", från lärarens sida kallas denna koppling för "Guidning". En grafisk tolkning av en koppling gör att du omedelbart kan läsa betydelsen av relationen mellan entiteter, den är visuell och lätt att tolka. Anslutningar är indelade i tre typer beroende på deras mångfald: en till en (1:1), en till många(1:M), många-till-många(M:M). En en-till-en-relation innebär att en instans av en enhet är relaterad till endast en instans av en annan enhet. Länk 1: M betyder en enhetsinstans, som ligger till vänster längs länken, kan associeras med flera instanser av enheten som finns till höger längs länken. En en-till-en-relation (1:1) innebär att en instans av en enhet är associerad med endast en instans av en annan entitet, medan en många-till-många-relation (M:M) innebär att en instans av den första enheten kan associeras med flera instanser av den andra enheten, och omvänt kan en instans av den andra enheten associeras med flera instanser av den första enheten. Om vi ​​till exempel betraktar ett förhållande av typen "Studier" mellan enheterna "Student" och "Disciplin", så är detta ett förhållande av typen "många-till-många" (M:M), eftersom varje elev kan studera flera discipliner, men varje disciplin studeras av många studenter. Denna anslutning visas i fig. 7.3.

  • Valfritt antal anslutningar med olika semantiska belastningar kan specificeras mellan två enheter. Till exempel, mellan två entiteter "Student" och "Lärare", kan två semantiska kopplingar upprättas, den ena är den tidigare diskuterade "Diploma Design", och den andra kan villkorligt kallas "Föreläsningar", och den avgör vilka lärares föreläsningar detta elev lyssnar på och som Denna lärare håller föreläsningar för studenter. Det är tydligt att detta är en koppling som många-till-många Ett exempel på dessa samband ges i Dessutom tillåter ER-modellen principen om kategorisering av enheter. Detta innebär att, liksom i objektorienterade programmeringsspråk, konceptet entitetsundertyp, det vill säga en entitet kan representeras i form av två eller flera av dess undertyper - enheter, som alla kan ha gemensamma attribut och relationer och/eller attribut och relationer som definieras en gång på övre nivån och ärvs på lägre nivå. Alla undertyper av en enhet anses vara ömsesidigt uteslutande, och när en enhet delas in i undertyper ska den representeras som hela uppsättningenömsesidigt uteslutande undertyper. Om det på analysnivå inte är möjligt att identifiera en fullständig lista med undertyper, så introduceras en speciell undertyp, villkorligt kallad ANDRA, som kan förtydligas ytterligare. I riktiga system Ibland räcker det med att införa subtypning på två eller tre nivåer.

Modellen föreslogs av Peter Ping-Shen Chen 1976. De flesta moderna tillvägagångssätt för databasdesign (främst relationella) är baserade på användningen av varianter av ER-modellen. Domänmodellering baseras på användningen av grafiska diagram som inkluderar ett litet antal heterogena komponenter. På grund av tydligheten i presentationen av konceptuella databasdiagram har ER-modeller blivit utbredda i CASE-system som stöder datorstödd design relationsdatabaser. De grundläggande begreppen i ER-modellen är entitet, relation och attribut.

En entitet är ett verkligt eller imaginärt objekt om vilken information är av intresse. I ER-modelldiagram representeras en entitet som en rektangel som innehåller namnet på entiteten. I det här fallet är namnet på entiteten namnet på typen och inte ett specifikt objekt - en instans av denna typ. Varje instans av en enhet måste kunna särskiljas från alla andra instanser av samma enhet.

En relation är en grafiskt representerad association etablerad mellan två enheter. Denna association är alltid binär och kan existera mellan två olika entiteter eller mellan en entitet och sig själv (rekursiv relation). I vilken anslutning som helst identifieras två ändar (i enlighet med paret av anslutna enheter), som var och en anger namnet på slutet av anslutningen, graden av slutet av anslutningen (hur många instanser av denna enhet är anslutna) , anslutningens obligatoriska karaktär (dvs. om någon instans av denna enhet måste delta i denna anslutning).

En anslutning representeras som en linje som förbinder två enheter eller leder från en enhet till sig själv. I det här fallet, vid den punkt där anslutningen "förenas" med entiteten, används en trepunktsingång i entitetsrektangeln, om många instanser av entiteten kan användas för denna entitet i anslutningen, och en enpunkts entry, om endast en instans av enheten kan delta i anslutningen. Den erforderliga änden av anslutningen är avbildad med en heldragen linje och den valfria änden med en streckad linje.

Liksom en enhet är en relation ett generiskt begrepp alla instanser av båda paren av relaterade enheter är föremål för föreningsreglerna.

Figur 12 visar ett exempel på en bild av enheter och förhållandet mellan dem.

Ris. 12. Ett exempel på en relation mellan enheter

Detta diagram kan tolkas enligt följande: Varje STUDENT studerar i endast en GRUPP; Varje GRUPP består av en eller flera STUDENTER. I följande figur (fig. 13)

essensen av MÄNNISKAN avbildas med en rekursiv koppling som förbinder den med sig själv.

Fig. 13. Exempel på rekursiv länk

En lakonisk muntlig tolkning av det avbildade diagrammet är som följer:

Varje PERSON är son till en och endast en PERSON; Varje PERSON kan vara far till en eller flera PERSONER ("PERSON").

Ett enhetsattribut är varje detalj som tjänar till att förtydliga, identifiera, klassificera, kvantifiera eller uttrycka enhetens tillstånd. Attributnamn skrivs in i en rektangel som representerar entiteten, under entitetsnamnet och avbildas med små bokstäver. Till exempel (se bild 14):

Fig. 14. Bild av en enhet med dess attribut

En entitets unika identifierare är ett attribut, en kombination av attribut, en kombination av relationer eller en kombination av relationer och attribut som unikt skiljer varje instans av entiteten från andra instanser av samma typ av entitet.

Liksom i relationsdatabasscheman introducerar ER-scheman begreppet normala former, och deras betydelse överensstämmer väl med betydelsen av relationella normalformer. Observera att formuleringarna av normala former av ER-scheman gör innebörden av normalisering av relationsscheman tydligare. Vi kommer endast att överväga mycket korta och informella definitioner av de tre första normalformerna.

I första normala formen ER-scheman eliminerar dubbletter av attribut eller grupper av attribut, d.v.s. implicita enheter "förklädda" som attribut identifieras.

I andra normalformen attribut som endast beror på en del av den unika identifieraren elimineras. Denna del av den unika identifieraren identifierar en enda enhet.

I tredje normalformen attribut som är beroende av attribut som inte är en del av den unika identifieraren tas bort. Dessa attribut är grunden för en separat enhet. Vi fokuserade endast på de viktigaste begreppen i ER-datamodellen. Mer komplexa delar av modellen inkluderar följande:

Undertyper och supertyper av enheter. ER-modellen låter dig specificera IS-A-relationen mellan typer. Dessutom, om Ti IS-AT2 (där Ti och T2 är typer av enheter), så kallas Ti en subtyp av T2 och T2 är en supertyp av Ti. Det är alltså möjligt att ärva en entitetstyp baserat på en eller flera supertyper.

Anslutningar "många-med-många". Ibland är det nödvändigt att koppla samman enheter på ett sådant sätt att det kan finnas flera instanser av enheten i båda ändarna av länken (till exempel äger alla medlemmar i ett kooperativ gemensamt andelslagets egendom). För att göra detta introduceras en typ av "många-till-många"-relationer.

Specificerbara grader av anslutning. Ibland är det användbart att definiera det möjliga antalet entitetsinstanser som deltar i en given relation (till exempel får en anställd delta i högst tre projekt åt gången). För att uttrycka denna semantiska begränsning är det tillåtet att ange i slutet av anslutningen dess maximala eller obligatoriska grad.

Kaskadraderingar av entitetsinstanser. Vissa kopplingar är så starka (naturligtvis i fallet med en koppling "en till många"), att vid radering av en referensenhetsinstans (motsvarande den "ena" änden av relationen), måste alla entitetsinstanser som motsvarar den "många" änden av relationen också tas bort. Motsvarande krav på "kaskadradering" kan formuleras när en enhet definieras.

Domäner. Precis som med relationsdatamodellen är det användbart att kunna definiera en potentiellt giltig uppsättning värden för ett entitetsattribut (domän).

Dessa och andra, mer komplexa delar av EntityLink-datamodellen gör den mer kraftfull, men gör den samtidigt något svårare att använda. När du faktiskt använder ER-diagram för databasdesign måste du naturligtvis bekanta dig med alla möjligheter.

Föreläsning 15. Konceptuella datamodeller

I motsats till ämnesområdets infologiska modell, som enligt vissa regler beskriver information om föremål i den materiella världen och kopplingarna mellan dem som bör finnas i databasen, konceptuell modell beskriver data och anslutningar som är lagrade i datorn. På grund av detta är varje datamodell oupplösligt kopplad till databeskrivningsspråket för en specifik DBMS.

I huvudsak är en datamodell en kombination av tre komponenter: typer av datastrukturer, operationer på data och integritetsbegränsningar.

En datamodell är med andra ord något slags intellektuellt verktyg för designern, som gör det möjligt att implementera tolkningen av information om ämnesområdet i form av formaliserad data i enlighet med vissa krav, det vill säga ett abstraktionsverktyg som gör det är möjligt att se "skogen" (informationsinnehållet i uppgifterna), och inte enskilda "träd" (specifika datavärden).

Typer av datastrukturer

Bland de många olika definitioner som betecknar typer av datastrukturer är den vanligaste terminologin för CODASYL (Conference of DAta SYstems Language), en internationell sammanslutning för databehandlingssystemspråk skapad 1959.

I enlighet med denna terminologi används fem typiska strukturer (i komplexitetsordning):

1. dataelement;

2. Dataaggregat;

3. spela in;

4. uppsättning;

5. databas.

Låt oss ge korta definitioner dessa strukturer.

Ett dataelement är den minsta namngivna enhet av data som DBMS direkt kan adressera och med hjälp av vilken alla andra datastrukturer byggs upp.

Ett dataaggregat är en namngiven samling av dataelement som kan betraktas som en helhet. Enheten kan vara enkel eller sammansatt (om den innehåller andra enheter).

En post är en namngiven samling av dataelement och (eller) aggregat. En post är alltså ett aggregat som inte ingår i andra aggregat. En post kan ha en komplex hierarkisk struktur eftersom den tillåter aggregering att tillämpas flera gånger.

En uppsättning är en namngiven samling poster som bildar en hierarkisk struktur på två nivåer. Varje uppsättningstyp representerar ett förhållande mellan två posttyper. En uppsättning definieras genom att deklarera en posttyp som "ägande post" och de andra typerna

register - "medlemsregister". I det här fallet måste varje instans av uppsättningen innehålla en instans av "ägarposten" och valfritt antal "medlemsposter". Om en post representerar en enhet i datamodellen, representerar en uppsättning en relation mellan enheter. Till exempel, om vi betraktar kopplingen "studier" mellan enheterna "studiegrupp" och "student", så deklareras den första av enheterna som "ägarposten" (det är den enda i instansen av uppsättningen), och den andra

- "medlemspost" (det kan vara flera av dem i en viss instans).

En databas är en namngiven samling av postinstanser av olika typer, som innehåller länkar mellan poster som representeras av inställda instanser.

Observera att databasstrukturer är byggda på basis av följande grundläggande sammansättningsregler:

1. En databas kan innehålla valfritt antal posttyper och uppsättningstyper;

2. valfritt antal uppsättningar kan definieras mellan två posttyper;

3. En posttyp kan vara både en ägare och en medlem av flera uppsättningstyper.

Genom att följa dessa regler kan du simulera data om hur många

alla komplexa ämnesområde med den nödvändiga nivån av fullständighet och detaljer.

De övervägda typerna av datastrukturer kan representeras i olika former- Graf; tabellform; i form av källtexten till databeskrivningsspråket för ett specifikt DBMS.

Operationer på data

Operationer som implementeras av DBMS inkluderar urval (sökning) av data och åtgärder på dem. Dataurval utförs med hjälp av ett kriterium baserat på användningen eller den logiska positionen för en given (element, aggregat, post) eller värde för en given, eller relationer mellan data. Val baserat på den logiska positionen för en given artikel baseras på ordningen av data i systemminnet. I det här fallet kan sökkriterierna formuleras enligt följande:

1. hitta nästa givna (rekord);

2. hitta den föregående givna;

3. hitta det givna värdet;

4. hitta den första (sista) givna.

Denna typ av urval kallas urval genom aktuellt urval, som använder en aktuell statusindikator som automatiskt underhålls av DBMS och, som regel, pekar på någon instans av en DB-post.

Urvalskriteriet baserat på datavärden bildas från enkla eller booleska urvalsvillkor. Exempel enkla förhållanden sökningar är:

1. MILITÄR SPECIALITET = 200100;

2. ÅLDER > 20;

3. DATUM< 19.04.2002 и т.п.

Ett booleskt urvalsvillkor bildas genom att kombinera enkla villkor med hjälp av logiska operationer, Till exempel:

1. (FÖDELSEDATUM< 28.12.1963) И (СТАЖ > 10);

2. (ACADEMIC_TITLE = ASSOCIATE PROFESSOR) ELLER (ACADEMICAL TITLE = PROFESSOR), etc.

Om datamodellen som stöds av en viss DBMS tillåter dig att utföra dataurval genom relationer, kan du hitta data som är associerade med det aktuella värdet av alla data. Till exempel, om datamodellen implementerar en dubbelriktad "studie"-relation mellan enheterna "student" och "studiegrupp", är det möjligt att identifiera studiegrupper där unga män studerar (om studentbeskrivningen inkluderar attributet "kön"). .

Som regel majoriteten modernt DBMS tillåta olika kombinationer de typer av dataurval som beskrivs ovan.

Integritetsbegränsningar. Dessa logiska begränsningar för data används för att säkerställa att data överensstämmer med vissa fördefinierade villkor när man utför operationer på den. I huvudsak är integritetsbegränsningar en uppsättning regler som används för att skapa specifik modell data baserat på det valda DBMS.

Det finns interna och explicita begränsningar.

Begränsningar som orsakas av kapaciteten hos en viss DBMS kallas interna integritetsbegränsningar. Dessa restriktioner

gäller de typer av lagrade data (till exempel "ett textdataelement får bestå av högst 256 tecken" eller "en post får inte innehålla fler än 100 fält") och vilka typer av relationer som är tillåtna (till exempel kan en DBMS stöder endast så kallade funktionella relationer, d.v.s. kopplingar av typ 1:1, 1: M eller M: 1). De flesta befintliga DBMS stöder i första hand interna integritetsbegränsningar, vars överträdelser leder till felaktig data och är ganska lätt att kontrollera.

Begränsningar som orsakas av egenskaperna hos lagrad data om specifik programvara kallas uttryckliga integritetsbegränsningar. Dessa begränsningar stöds också med hjälp av det valda DBMS, men de bildas nödvändigtvis med deltagande av databasutvecklaren genom att definiera (programmering) särskilda förfaranden, säkerställa datakonsistens. Om till exempel dataposten "betygsbok" i posten "elev" definieras som en nyckel måste den vara unik, d.v.s. det ska inte finnas två poster i databasen med samma värden nyckel Ett annat exempel: låt samma post innehålla elementet "militär specialitet" och sex tilldelas för det decimalsiffror. Då är andra representationer av detta dataelement i databasen inte möjliga. Med hjälp av explicita integritetsbegränsningar är det möjligt att organisera "enkel" kontroll av indata (i första hand för att dataelement tillhör en fast och förutbestämd

given uppsättning värden: till exempel, elementet "akademisk titel" ska inte ha värdet "hedersdocent" om vi pratar om om ryska forskare) och mer komplexa procedurer (till exempel att ange värdet "professor" för dataelementet "akademisk titel" i en post om en lärare som är 25 år gammal bör kräva åtminstone ytterligare bekräftelse).

En elementär dataenhet kan implementeras på en mängd olika sätt, vilket i synnerhet har lett till en mängd olika kända datamodeller. Datamodellen definierar reglerna enligt vilka data struktureras. Typiskt är operationer på data relaterade till dess struktur.

Mångfald befintliga modeller data motsvarar en mängd olika applikationer och användarpreferenser.

I den specialiserade litteraturen finns en beskrivning av ganska stora mängder olika modeller data. Även om det är hierarkiskt, nätverk och, utan tvekan, relationsmodell, några andra bör nämnas tillsammans med dem.

Med hjälp av funktionerna i den logiska organisationen av data som en klassificeringsfunktion kan vi ge följande lista över kända modeller:

1. hierarkisk datamodell;

2. nätverksdatamodell;

3. relationsdatamodell;

4. binär datamodell;

5. semantisk webb.

Syftet med informationsmodellering är att tillhandahålla de mest naturliga sätten för människor att samla in och presentera den information som är tänkt att lagras i databasen som skapas. Därför försöker de bygga en infologisk datamodell i analogi med naturligt språk (det senare kan inte användas i sin rena form på grund av komplexiteten datorbehandling texter och tvetydighet i alla naturliga språk). De huvudsakliga konstruktiva delarna av informationsmodeller är enheter, kopplingar mellan dem och deras egenskaper (attribut).

Väsen- vilket som helst urskiljbart objekt (ett objekt som vi kan skilja från ett annat), information om vilket måste lagras i en databas. Entiteter kan vara människor, platser, flygplan, flyg, smak, färg etc. Det är nödvändigt att skilja på begrepp som t.ex Entitetstyp Och enhetsinstans. Begreppet enhetstyp hänvisar till en uppsättning homogena individer, objekt, händelser eller idéer som fungerar som en helhet. En entitetsinstans hänvisar till en specifik sak i en uppsättning. Entitetstypen kan till exempel vara CITY, och instansen kan vara Moskva, Kiev, etc.

Attribut- en namngiven egenskap hos en enhet. Dess namn måste vara unikt för en viss entitetstyp, men kan vara detsamma för olika entitetstyper (till exempel kan COLOR definieras för många entiteter: DOG, CAR, SMOKE, etc.). Attribut används för att definiera vilken information som ska samlas in om en enhet. Exempel på attribut för CAR-entiteten är TYPE, MAKE, LICENSE PLATE, COLOR, etc. Även här finns det en skillnad mellan typ och instans. Attributtypen COLOR har många instanser eller värden:

Röd, blå, banan, vit natt, etc., men varje enhetsinstans tilldelas endast ett attributvärde.

Det finns ingen absolut skillnad mellan enhetstyper och attribut. Ett attribut är endast sådant i förhållande till entitetstypen. I ett annat sammanhang kan ett attribut fungera som en självständig enhet. Till exempel, för en bilfabrik är färg bara ett attribut för produktionsprodukten, men för en färg- och lackfabrik är färg en enhetstyp.

Nyckel- en minsta uppsättning attribut vars värden kan användas för att entydigt hitta den nödvändiga instansen av en enhet. Minimalitet innebär att exkludering av något attribut från uppsättningen inte tillåter att enheten identifieras av de återstående. För Schema-entiteten (klausul 1.2) är nyckeln attributet Flight_number eller uppsättningen av: Departure_point, Departure_time och Destination_point (förutsatt att ett plan flyger från punkt till punkt vid varje tidpunkt).

Förbindelse- sammanslutning av två eller flera enheter. Om syftet med databasen bara var att lagra individuella, orelaterade data, så kan dess struktur vara mycket enkel. Ett av huvudkraven för att organisera en databas är dock att säkerställa möjligheten att hitta vissa enheter genom andras värden, för vilka det är nödvändigt att upprätta vissa kopplingar mellan dem. Och eftersom riktiga databaser ofta innehåller hundratals eller till och med tusentals enheter, kan teoretiskt mer än en miljon kopplingar upprättas mellan dem. Närvaron av en sådan mängd kopplingar bestämmer komplexiteten hos informationsmodeller.


2024 gtavrl.ru.