LEZING

Entiteit-relatiemodel.

Basisbegrippen: Essentie, Eigenschappen, Relaties.

Weergave van entiteiten, eigenschappen, relaties

9.1. Model "Entiteit-relatie"

De meest gebruikelijke manier om het vakgebied van systemen gericht op het verwerken van feitelijke informatie te modelleren is het ‘entiteitsrelatie’-model ( Entiteit - Relatiemodel - ER M), voor het eerst voorgesteld door Peter Ping-Sheng Chen in 1976. Dit model wordt traditioneel gebruikt bij structurele analyse en ontwerp, maar implementeert in wezen een objectgebaseerde benadering van domeinmodellering.

Het entiteit-relatiemodel vormt de basis voor een aanzienlijk aantal commerciële CASE-producten die de volledige ontwikkelingscyclus van databasesystemen of de afzonderlijke fasen ervan ondersteunen. Tegelijkertijd ondersteunen velen van hen niet alleen de fase van conceptueel ontwerp van het onderwerpgebied van het systeem dat wordt ontwikkeld, maar laten ze ook toe dat de logische ontwerpfase wordt uitgevoerd op basis van het model dat met hun middelen is geconstrueerd door automatisch te genereren een conceptueel databaseschema voor het geselecteerde DBMS, bijvoorbeeld een databaseschema voor een SQL-server of object-DBMS.

Het modelleren van het onderwerpgebied is in dit geval gebaseerd op het gebruik van grafische diagrammen, inclusief een relatief klein aantal componenten (dia 2) en, het allerbelangrijkste: bouw technologie zulke diagrammen.

Semantische basis ER -modellen maken de volgende aannames:

- dat deel van de echte wereld (een reeks onderling verbonden objecten), waarover informatie in de database moet worden geplaatst, kan zijn gepresenteerd als een geheel entiteiten;

- Elke entiteit heeft karakteristieke eigenschappen (attributen) die haar onderscheiden van andere entiteiten en dit mogelijk maken identificeren;

- Entiteiten kunnen worden geclassificeerd op basis van entiteitstypen: elke instantie van een entiteit (die een bepaald object vertegenwoordigt) kan aan een klasse worden toegewezen - type entiteiten, waarvan elk exemplaar gemeenschappelijke eigenschappen heeft en hen onderscheidt van entiteiten van andere klassen;

- Op klassen gebaseerde representatiesystematisering gaat doorgaans uit van een hiërarchische afhankelijkheid van typen: de type-entiteit A is subtype essenceB, als elk exemplaar van type A is een instantie van een entiteit van het typeB;

- relaties tussen objecten kunnen worden weergegeven als communicatie– entiteiten die dienen om de onderlinge afhankelijkheid van twee of meer entiteiten vast te leggen (representeren).

Hier moeten we nogmaals het informatieve karakter van het concept benadrukken essence en de relatie ervan met materiële of denkbeeldige objecten uit het vakgebied. Elk onderwerpdomeinobject heeft eigenschappen, waarvan sommige worden onderscheiden als karakteristiek - significant vanuit het oogpunt van de toegepaste taak. In dit geval bijvoorbeeld tijdens het analyseren en systematiseren van een vakgebied, meestal klassen– een verzameling objecten met dezelfde set eigenschappen, gespecificeerd in het formulier attributensets(attribuutwaarden voor objecten van dezelfde klasse kunnen uiteraard verschillen). Dienovereenkomstig komt een object dat als een concept wordt beschouwd (een object in de menselijke geest) op het niveau van representatie van het onderwerpgebied (dat wil zeggen het infologische model) overeen met het concept essence; een object, als onderdeel van de materiële wereld (en onafhankelijk van het menselijk bewustzijn bestaand), komt overeen met het concept entiteitsinstantie; de klasse van objecten komt overeen met het concept entiteitstype.

Omdat het infologische model geen individuele gevallen van objecten in beschouwing neemt, maar klassen, zullen we in wat volgt geen onderscheid maken tussen de overeenkomstige concepten van deze twee niveaus, d.w.z. we zullen de identiteit van concepten aannemen voorwerp En essence, objecteigenschap En entiteit eigendom.

Op dia 3 Dit is een voorbeeld van een entiteitsrepresentatie, die niet compleet is en niet beweert exact overeen te komen met enige versie van de constructie van ER-diagrammen.

Het ER-model moet, als beschrijving van het vakgebied, objecten en relaties daartussen definiëren, d.w.z. breng verbindingen tot stand van de volgende twee typen:

1. verbindingen tussen objecten en sets van karakteristieke eigenschappen en daarmee de objecten zelf definiëren;

2. verbindingen tussen objecten, waarbij de aard en functionele aard van hun onderlinge afhankelijkheid worden gedefinieerd.

Zoals eerder opgemerkt, is ER-modellering van een vakgebied gebaseerd op het gebruik van grafische diagrammen als een eenvoudige (vertrouwde), visuele en tegelijkertijd informatieve en multidimensionale manier om projectcomponenten weer te geven.

Essence. Een entiteit waarmee een klasse van vergelijkbare objecten wordt gemodelleerd, wordt gedefinieerd als ‘een object dat duidelijk kan worden geïdentificeerd’. Net zoals elk object op unieke wijze wordt gekenmerkt door een reeks eigenschapswaarden, moet een entiteit dat ook doen bepaald worden zoals dit set attributen, waardoor iemand onderscheid kan maken tussen individuele exemplaren van een entiteit. Elke instantie van een entiteit moet te onderscheiden zijn van elke andere instantie van dezelfde entiteit (deze vereiste is vergelijkbaar met de vereiste dat er geen dubbele tupels voorkomen in relationele tabellen). Om bijvoorbeeld elk exemplaar van de entiteit “Employee” uniek te identificeren, wordt het attribuut “Tab.number” geïntroduceerd, dat vanwege zijn aard altijd een unieke waarde zal hebben binnen de onderneming. Dat wil zeggen dat een unieke entiteitsidentificator een attribuut, een combinatie van attributen, een combinatie van relaties of een combinatie van relaties en attributen kan zijn die een entiteitsinstantie op unieke wijze onderscheidt van andere entiteitsinstanties van hetzelfde type.

De entiteit heeft Naam, uniek binnen het model. Tegelijkertijd entiteitsnaam- Dit typ naam, en niet een specifiek exemplaar.

Entiteiten zijn onderverdeeld in sterk En zwak. Een entiteit is zwak als haar bestaan ​​afhangt van een andere entiteit – sterk in relatie tot haar. De entiteit “Ondergeschikte” is bijvoorbeeld zwak ten opzichte van de entiteit “Werknemer”: als een record dat overeenkomt met een werknemer die ondergeschikten heeft, wordt verwijderd, moet ook de informatie over de ondergeschikte worden verwijderd.

Eigenschappen( dia 4)

De aard van het onroerend goed, hoe aard van verbinding eigenschappen met een entiteit (object) kunnen verschillen. Laten we eens kijken naar de belangrijkste soorten eigendommen.

Het pand kan zijn meerdere of enkel– d.w.z. een attribuut dat een eigenschap specificeert, kan tegelijkertijd meerdere waarden hebben, of dienovereenkomstig slechts één. Een medewerker kan bijvoorbeeld meerdere specialiteiten hebben, maar de enige waarde is 'Tab. nummer".

Het pand kan zijn eenvoudig(niet onderworpen aan verdere verdeling vanuit het oogpunt van toegepaste taken) of composiet– als de waarde ervan bestaat uit de waarden van eenvoudige eigenschappen. De eigenschap 'Geboortejaar' is bijvoorbeeld eenvoudig en de eigenschap 'Adres' is samengesteld, omdat omvat de waarden van eenvoudige eigenschappen “Stad”, “Straat”, “Huis”.

In sommige gevallen is het nuttig om onderscheid te maken eenvoudig En derivaten eigenschappen. Een 'Leverancier' kan bijvoorbeeld de eigenschap 'Totaal aantal geleverde onderdelen' hebben, die wordt berekend door het aantal onderdelen dat hij voor een project levert bij elkaar op te tellen.

Als de aanwezigheid van een eigenschap voor alle instanties van een entiteit niet verplicht is, wordt een dergelijke eigenschap genoemd voorwaardelijk. Zo beschikken niet alle medewerkers over de eigenschap ‘academisch diploma’.

Eigenschapswaarden kunnen constant zijn - statisch, of dynamisch, d.w.z. veranderen in de loop van de tijd. De eigenschap 'Tab. nummer" is statisch en "adres" is dynamisch. Het pand kan zijn onzeker, als het dynamisch is maar de huidige waarde nog niet is ingesteld.

Het pand kan worden beschouwd als sleutel, als de betekenis ervan uniek is en misschien, in een bepaalde context, de entiteit op unieke wijze identificeert. Bijvoorbeeld een ondergeschikte van een bepaalde medewerker.

Verbindingen Naast de verbindingen tussen een object en zijn eigenschappen weerspiegelt het infologische model de verbindingen tussen objecten van verschillende klassen. Verbinding wordt gedefinieerd als “een vereniging die verschillende entiteiten verenigt.” Deze associatie kan altijd bestaan ​​tussen verschillende entiteiten of tussen een entiteit en zichzelf (recursieve relatie).

Net als essentie is verbinding dat ook type nieuw concept, d.w.z. alle exemplaren van gekoppelde entiteiten zijn onderworpen aan typebindende regels. Het fundamentele verschil tussen de soorten relaties tussen typen en instanties wordt geïllustreerd in dia's.

Entiteiten verenigd door een relatie worden aangeroepen deelnemers. Mate van verbinding bepaald door het aantal communicatiedeelnemers.

Als elke instantie van een entiteit deelneemt aan ten minste één instantie van een relatie, wordt een dergelijke deelname van die entiteit genoemd compleet(of verplicht); anders - onvolledig(of optioneel).

De kwantitatieve aard van de deelname van entiteitsinstanties (een of meerdere) wordt gespecificeerd soort verbinding(of communicatieve kracht). De volgende typen zijn mogelijk: "één op één"(1:1), "één voor velen"(1: M) , "veel tegen één"(M:1) , "veel tot veel"(MM) (Dia's 5, 6, 7).

Opgemerkt moet worden dat de linktool een representatiemiddel is complexe objecten, die elk kunnen worden beschouwd als een reeks enigszins onderling verbonden eenvoudige voorwerpen. De indeling in eenvoudige en complexe objecten, evenals de aard van de relatie, is voorwaardelijk en wordt bepaald door de eigenaardigheden van de analyse van het vakgebied, d.w.z. uiteindelijk - door de aard van het gebruik van gegevens over objecten in opgeloste toegepaste problemen. Bovendien is een PART vanuit bijvoorbeeld het gezichtspunt van een ontwerper een complex object, maar vanuit het gezichtspunt van een leverancier is het een eenvoudig object.

Van de vele soorten relaties zijn de meest voorkomende relaties van een hiërarchisch type, zoals ‘deel-geheel’, ‘geslacht-soort’.

Om te representeren worden deel-geheel-relaties gebruikt samengestelde objecten. MACHINES bestaan ​​bijvoorbeeld uit EENHEDEN, EENHEDEN bestaan ​​uit DELEN. Relaties zijn hier mogelijk "één voor velen" zo en "veel voor veel".

Geslacht-soortrelatie - voor representatie gegeneraliseerde objecten. WERKNEMERS zijn bijvoorbeeld per beroep onderverdeeld in ONTWERPERS, PROGRAMMEERDERS, WERKNEMERS; PROGRAMMERS – in APPLICATIEPROGRAMMERS en SYSTEEMPROGRAMMERS. Hiërarchische relaties, en in het bijzonder: “ geslachtsspecifiek", worden meestal gebruikt als basis voor het classificeren van objecten op basis van reeksen karakteristieke kenmerken. Bovendien zijn het ‘soorten’-objecten erven"generieke" eigenschappen.

Een ander veelgebruikt type relatie is aggregatie: het combineren van eenvoudige objecten tot complexe objecten op basis van het principe van hun lidmaatschap eenheid of hun gezamenlijke deelname aan een bepaald proces. Aggregatie, hier beschouwd als een meer algemeen geval van hiërarchische relaties, combineert objecten van verschillende aard met de enige gemeenschappelijke eigenschap van ‘gezamenlijke participatie’. Geaggregeerde objecten worden meestal genoemd met verbale zelfstandige naamwoorden, bijvoorbeeld "Verbinding": DIVISIE bestaat uit MEDEWERKERS; " Levering": LEVERANCIER benodigdheden DETAILS.

Supertypes en subtypen. Een entiteit kan worden opgesplitst in twee of meer die elkaar uitsluiten subtypen, die elk gemeenschappelijke kenmerken en/of relaties bevatten. Deze gemeenschappelijke kenmerken en/of relaties worden op een hoger niveau expliciet gedefinieerd. Subtypen kunnen hun eigen attributen en/of relaties definiëren. In principe kan het subtypen op lagere niveaus doorgaan, maar in de meeste gevallen zijn twee of drie niveaus voldoende.

De entiteit op basis waarvan subtypen worden bepaald, wordt aangeroepen supertype. Subtypen moeten een complete set vormen, d.w.z. elk exemplaar van een supertype moet tot een bepaald subtype behoren. Soms is het, om de set compleet te maken, nodig om een ​​aanvullend subtype te definiëren, bijvoorbeeld OTHERS.

Het subtype erft de eigenschappen en relaties van het supertype. Het entiteitstype PROGRAMMER is bijvoorbeeld een subtype van de entiteit WERKNEMER. Programmeurs hebben alle eigenschappen van werknemers en nemen deel aan alle communicatie, maar het omgekeerde is niet waar.

Een entiteitstype, de subtypen ervan, subtypen van deze subtypen, enz. formulier hiërarchie van entiteitstypen, waarvan een voorbeeld wordt gegeven in Dia 8.

9.2. ER-diagram

Zoals eerder opgemerkt, is een van de hoofddoelen van semantische modellering ervoor te zorgen dat de resultaten van de analyse van het vakgebied worden weerspiegeld in een vrij eenvoudige, visuele maar tegelijkertijd geformaliseerde en voldoende informatieve vorm.

In die zin is het ER-diagram een ​​zeer goede oplossing. Het combineert functionele en informatieve benaderingen, waardoor het mogelijk wordt om zowel de reeks uitgevoerde functies als de relaties tussen systeemelementen, gespecificeerd door datastructuren, weer te geven. Tegelijkertijd kunt u met de grafische vorm in een compacte vorm (vanwege visuele symbolen) de typologie en eigenschappen van entiteiten en relaties weergeven, en dankzij de formalismen die ten grondslag liggen aan de ER-diagrammen kunt u bij de volgende stap een strikt normalisatieapparaat gebruiken. van het ontwerpen van de logische structuur van de database.

Entiteiten Elk entiteitstype in ER-diagrammen wordt weergegeven als een rechthoek met daarin de naam van de entiteit. Zelfstandige naamwoorden (of zinnen van een zelfstandig naamwoord) in het enkelvoud worden meestal als naam gebruikt. Om entiteiten van zwakke typen weer te geven, worden rechthoeken gebruikt, waarvan de zijkanten zijn getekend met dubbele lijnen. Bijvoorbeeld in degene die wordt gepresenteerd op dia 9 In het ER-diagram is SUBJECT een entiteit van een zwak type.

Eigenschappen.Eigenschappen dienen om de toestand van een entiteit of relatie te verduidelijken, identificeren, karakteriseren of uitdrukken. Eigenschappen worden weergegeven als ellipsen die de naam van de eigenschap bevatten. De ellips is door een lijn verbonden met de overeenkomstige entiteit of relatie.

De namen van belangrijke eigenschappen zijn onderstreept. Bijvoorbeeld de eigenschap 'Tabelnummer' van de entiteit WERKNEMER.

De omtrek van de ellips wordt getekend met een dubbele lijn als de eigenschap meerdere waarden heeft. Bijvoorbeeld de eigenschap 'specialiteit' van de entiteit WERKNEMER.

De omtrek van de ellips wordt getekend met een stippellijn als de eigenschap is afgeleid. Bijvoorbeeld de eigenschap 'hoeveelheid' van de entiteit LEVERANCIER.

De ellips is verbonden door een stippellijn als de eigenschap voorwaardelijk is. De eigenschap 'In.

Ik ben de taal van de entiteit WERKNEMER.

Als een eigenschap samengesteld is, worden de samenstellende eigenschappen ervan weergegeven door andere ellipsen die met de samengestelde ellips zijn verbonden. De eigenschap “Adres” van de entiteit WERKNEMER bestaat bijvoorbeeld uit de eenvoudige eigenschappen “Plaats”, “Straat”, “Huis”.Verbindingen ER Een relatie is een grafisch weergegeven associatie tussen entiteiten. Elk type verbinding

-Het diagram wordt weergegeven als een ruit met de naam van de verbinding erin. Verbale zelfstandige naamwoorden worden meestal als naam gebruikt.

Communicatiedeelnemers zijn via lijnen met de communicatie verbonden. De dubbele lijn geeft de volledige deelname van de entiteit aan in verband met deze zijde. Bijvoorbeeld de relatie 'Ondergeschiktheid', vanaf de kant van de entiteit ONDERWERP.

De relatie kan worden gewijzigd door een rol op te geven. Voor de recursieve verbinding “Compositie” worden de rollen bijvoorbeeld aangegeven: “Part bestaat uit..." en "Onderdeel inbegrepen opgenomen in …».

Het verbindingstype wordt aangegeven door de indices “1” of “M” boven de overeenkomstige regel. De relatie “Beheer” is bijvoorbeeld van het type één-op-veel: één medewerker kan vele projecten beheren; De “Participatie”-relatie is van het veel-op-veel-type: één medewerker kan aan veel projecten deelnemen, en veel medewerkers kunnen aan een project deelnemen.

Een voorbeeld van een genormaliseerde vorm van een ER-diagram wordt getoond in dia 10.

Een van de varianten van het entiteit-relatiemodel wordt gebruikt in de IDEF1X-notatie, die deel uitmaakt van de IDEF-standaardfamilie.

De grafische taal van het model en een voorbeelddiagram worden gepresenteerd op dia 11 .

Optionele relaties tussen entiteiten Afdeling En Werknemer, werknemer En Ondergeschikt een één-op-veel-kardinaliteit hebben (het einde van de ‘veel’-relatie wordt aangegeven door een vetgedrukte punt) en een verplichte relatie tussen entiteiten Medewerker En Project heeft veel-op-veel-macht.

Grafische elementen van de belangrijkste notaties van het ‘entiteitsrelatie’-model worden gepresenteerd in dia 12 .

Deze definitie van een verbinding als een entiteit van een speciaal soort weerspiegelt de essentie van de relationele benadering, die wordt gekenmerkt door een uniforme representatie van alle soorten entiteiten, inclusief verbindingen, door middel van relatievariabelen.

Volgens de bepalingen van het relationele model is een ‘juiste’ relatie slechts een relatie van het type ‘ veel tegen veel", omdat er voor de implementatie ervan een aparte relatievariabele wordt gemaakt. Verbindingen "één op één", "één op veel" kan altijd worden weergegeven met behulp van een refererend sleutelmechanisme van een van relatievariabelen.

Logisch model De (entiteits)gegevens zijn een onafhankelijke logische representatie van de gegevens.

Fysiek model(Tabelvormige) gegevens bevatten definities van alle geïmplementeerde objecten in een specifieke database voor een specifiek DBMS.

Modellen zijn de hoeksteen van design. Ingenieurs moeten een model van de auto bouwen en alle details uitwerken voordat deze in productie wordt genomen. Op dezelfde manier ontwikkelen systeemingenieurs eerst modellen om bedrijfslogica te bestuderen en hun begrip van de databasestructuur te verdiepen.

In de laatste lezing hebben we kennis gemaakt met de IDEF0- en DFD-methodieken, waarmee we bedrijfsprocessen kunnen beschrijven die plaatsvinden in een informatiesysteem. In het DFD-model hebben we een element overwogen: een gegevensopslag, die de soorten informatie laat zien waarop het systeem werkt. Deze methodologie is echter niet bedoeld om de structuur van opgeslagen informatie te beschrijven. Hiervoor zijn diverse Entity Relationship diagrammen (entiteitsdiagrammen) geschikter, die tot doel hebben de structuur van de opgeslagen gegevens en de relaties daartussen te beschrijven. Er zijn methoden ontwikkeld waarmee u dergelijke gegevens kunt omzetten in een reeks opdrachten die de benodigde opslag (tabellen) in de database van het informatiesysteem creëren.

ER-modellering

In informatiesystemen worden gegevens onderverdeeld in afzonderlijke categorieën of entiteiten. We herinneren ons immers dat een database een verzameling gestructureerde gegevens is. Verschillende soorten gegevens worden afzonderlijk opgeslagen. De taak van het ER-model is om te laten zien welke soorten informatie in het systeem zijn opgeslagen, wat hun structuur is en hoe ze met elkaar verbonden zijn. Het ER-model is gebouwd op basis van een bedrijfsanalyse (geconstrueerd DF-diagram). In dit geval wordt elke winkel in het DF-diagram aanvankelijk een entiteit in het ER-diagram. Tijdens verdere analyse kunnen ze worden opgesplitst in hun samenstellende delen. Het is vermeldenswaard dat ER-modellen beter bestand zijn tegen veranderingen in de bedrijfsstructuur dan DF-diagrammen. Bedrijfsprocessen kunnen veranderen, maar de informatie die nodig is om deze te implementeren blijft vaak ongewijzigd.

De belangrijkste voordelen van ER-modellen:

• Een nauwkeurig en begrijpelijk formaat voor het documenteren van de structuur van informatie.
• Hiermee kunt u vereisten voor gegevens en relaties daartussen specificeren.
• Hiermee kunt u de opslagstructuur duidelijk weergeven om het databaseontwerp te vergemakkelijken.
• Er zijn methoden om ER-modellen aan databasetabellen toe te wijzen en omgekeerd.
• Legt de basis voor integratie met andere applicaties.

De belangrijkste typen objecten in het ER-diagram:

• Entiteit is een type object, waarvan informatie in de database wordt opgeslagen. Bijvoorbeeld: afdelingen, medewerkers, goederen, facturen.
• Attribuut - elementen waaruit entiteiten bestaan. Voor de entiteit ‘producten’ kunnen de attributen bijvoorbeeld ‘naam’, ‘beschrijving’, ‘hoeveelheid’, ‘prijs’ en andere zijn, afhankelijk van de behoeften van het informatiesysteem. Afhankelijk van de notatie van het ER-diagram, geeft u naast het attribuut, naast de naam, het type en de verplichte vulling aan. De dia toont een ER-diagram in de notatie “Information Engineering”, waarbij voor een attribuut een naam, type en of het een externe en/of primaire oproep betreft, worden aangegeven.
• Relaties tonen verbindingen tussen entiteiten. Een medewerker werkt bijvoorbeeld op een afdeling, waarbij ‘afdeling’ en ‘afdeling’ entiteiten zijn.

Een entiteit is een verzameling objecten uit de echte wereld, die elk de volgende kenmerken hebben:

• Uniek (kan op de een of andere manier van alle anderen worden gescheiden)
• Speelt een rol in het systeem dat wordt gemodelleerd
• Kan worden beschreven door een of meer stukjes informatie (kenmerk)

Voorbeeld: mensen, personeel, evenementen, bestellingen, verkopen, klanten, leveranciers

Een attribuut beschrijft enkele eigenschappen van een entiteit. Een entiteit kan veel attributen hebben, maar alleen de attributen die belangrijk zijn voor het systeem worden geselecteerd. Attributen zijn onderverdeeld in sleutel (Entiteitssleutels) en beschrijvend (Entiteitsdescriptoren). Sleutelkenmerken moeten instanties van een entiteit op unieke wijze identificeren. Voor elk attribuut moet een domein (type, onderwerpgebied) worden opgegeven.

De dia laat zien hoe entiteiten en attributen in verschillende ER-modelnotaties worden geschreven. In alle notaties is een entiteit een rechthoekig object, in het bovenste gedeelte waarvan de naam van de entiteit wordt aangegeven. De attributen worden vermeld onder de entiteitsnaam.

Laten we eens nader bekijken wat de belangrijkste kenmerken zijn. Dit is belangrijk voor het begrijpen van de soorten relaties tussen entiteiten.

Basisvoorwaarden

Het relationele model kan, indien nodig, worden beschreven in wiskundige taal, dat wil zeggen in de meest nauwkeurige taal die door de mens is uitgevonden. Hieronder vindt u losse definities van enkele concepten van het relationele model.

• "Gegevenstype" (type, domean - domein) - een reeks toegestane waarden ("domein") en bewerkingen. Alle typen hebben vergelijkings- en toewijzingsbewerkingen. Het is niet verboden dat hoeveelheden de structuur hebben van bijvoorbeeld een object.
• "Relatie" (relatie) - een reeks attributen: unieke namen met verduidelijking van het gegevenstype; plus een reeks “waardensets” (“reeksen”) die overeenkomen met de attributen. Waarden in sets kunnen alleen worden weergegeven door enkele waarden van de typen die overeenkomen met de attributen, dat wil zeggen dat ze scalairen kunnen zijn ("1e normaalvorm").
• “Key” (sleutel) is een groep attributen waarvan de waarden in alle sets verschillend zijn in verhouding, maar geen enkele subgroep van deze attributen heeft al zo’n eigenschap (de ‘minimaliteit’-eigenschap van de sleutel). In het bijzonder kan een groep uit één enkel attribuut bestaan. Er moet altijd een sleutel in een relatie aanwezig zijn, en als er meerdere zijn, moet één ervan als ‘primair’ worden aangemerkt.
• ‘Vreemde sleutel’ is een groep attributen waarvan de waarden in elke set relatiewaarden moeten overeenkomen met de waarden van een sleutel van mogelijk een andere relatie. Externe sleutels in een relatie zijn optioneel en worden gedeclareerd op basis van modelleringsbehoeften.
• “Operaties” (operatie) zijn een reeks algemene acties op het gebied van relaties, die wederom resulteren in relaties (“geslotenheid van operaties”). Ze worden gebruikt om nieuwe relaties te verkrijgen voor de behoeften van daaropvolgende modellering of bij het extraheren van de benodigde gegevens uit de database. De lijst met bewerkingen kan op verschillende manieren worden gedefinieerd; in de eerste voorstellen van het model werden acht bewerkingen gegeven (projectie, verbinding, selectie, enz.), niet langer een minimumset, als compromis tussen het gebrek aan redundantie en gebruiksgemak.
• " Relationele database" (relationele database) - een reeks relaties.

Een ‘gegevenstype’ wordt soms een ‘domein’ genoemd, maar soms verwijst ‘domein’ alleen naar het ‘domein van definitie’ van waarden. Een “reeks hoeveelheden” (tupel) in het Russisch wordt ook wel een “tupel” of “n-coy” genoemd.

Voor het gemak worden relaties vaak weergegeven in de vorm van tabellen, hoewel een dergelijke weergave onwettig is (noch de volgorde van attributen, noch de volgorde van waardensets wordt gedefinieerd in een relatie, in tegenstelling tot een tabel). In SQL, waarop het Oracle DBMS is gebouwd, wordt het concept van ‘relatie’ als modelleringstool vervangen door ‘tabel’. Een andere representatie van relatiegegevens kan een hyperkubus zijn, en het is soms ook handig om daar gebruik van te maken bij het redeneren over een bestaande database.

Als we het definiërende traceerwoord ‘relationeel’ achterwege laten, kan de term ‘relationele database’ worden vertaald als ‘relatiedatabase’ (meer precies: ‘database gebouwd door relaties"; relaties als hulpmiddel, niet als object van modellering: anders zou de oorspronkelijke term relatiedatabase zijn). Op dezelfde manier kan de term "relationeel model" worden vertaald als "relatiemodel", dat wil zeggen: "een systeem van concepten voor het construeren van een model van een vakgebied in de vorm van een reeks relaties." Om een ​​aantal redenen, waaronder historische en taalkundige redenen, werd dit destijds niet gedaan.

Alle datarelaties worden beschreven blijkbaar En alleen waarden in sets (dit kan bij andere modelleringsbenaderingen anders zijn). Er zijn geen “impliciete” afhankelijkheden (ook niet op het niveau van de programmalogica), behalve de relaties die door variabelen worden geformuleerd. De relationele benadering maakt onderscheid tussen de beschrijving van gegevens en de programmalogica die bij de applicatie hoort (in tegenstelling tot bijvoorbeeld de objectbenadering).

De bovenstaande weergave van een relationele database (een reeks relaties en bewerkingen) is typerend voor relationele algebra. Dit is niet het enige standpunt. Elke reeks waarden in een relatievariabele kan worden opgevat als een ware uitspraak ("predikaat"): er is zo'n en die werknemer met die en die eigenschappen; die en die afdeling enzovoort. De relationele database vertegenwoordigt dus op elk moment een reeks ware uitspraken over het vakgebied, geformuleerd door middel van relaties. In feite vormt een reeks uitspraken in relatievariabelen een domeinmodel dat wordt weergegeven door een database. Deze weergave van een relationele database is typerend voor relationele berekening. Beide visies op het relationele model zijn goed bestudeerd en hun expressieve gelijkwaardigheid is bewezen.

Voor de termen op de vorige dia zijn er informele equivalenten om het gemakkelijker te maken de betekenis ervan te begrijpen en te onthouden:

• Relatie → Tabel
• Tuple → Tekenreeks, opnemen
• Kardinaliteit → Aantal regels
• Attribuut → Kolom, veld
• Graad → Aantal kolommen
• Primaire sleutel → Identificatie
• Domein → Bereik van acceptabele waarden

Sleutelvelden

Sommige kenmerken van een relatie zijn sleutels of sleutels. Er zijn verschillende soorten sleutels:

• Een eenvoudige sleutel bestaat uit één attribuut, een samengestelde sleutel uit meerdere.
• Potentiële sleutel- een attribuut of een reeks attributen die elk van de tupels van een relatie kunnen identificeren. Met betrekking tot het paspoortkantoor zijn er bijvoorbeeld (“Paspoortnummer”) en (“Volledige naam” en “Geboortedatum”) potentiële sleutels waarmee u elke persoon op unieke wijze kunt identificeren.
• Elke relatie kan slechts één primaire sleutel hebben: een attribuut of een set attribuutwaarden waarvan de waarden elke record op unieke wijze identificeren. Als meerdere sets attributen dergelijke eigenschappen hebben, wordt één ervan als de primaire gekozen en worden alle andere als alternatieve sets gekozen.
• Buitenlandse sleutel - winkels betekenis de primaire sleutel van een andere relatie. Externe sleutels worden gebruikt om tussen relaties te communiceren.

Primaire sleutel

• Elke relationele relatie heeft slechts één primaire sleutel, alle andere zijn alternatieve sleutels.
• De waarde van alle primaire sleutelkenmerken Niet Misschien niet gedefinieerd. In een relatie wordt bijvoorbeeld informatie opgeslagen over de inwoners van een stad. De primaire sleutel is samengesteld (NAAM, ACHTERNAAM, geboortedatum). Het informatiesysteem is geïnstalleerd in IJsland, waar geen achternaam wordt gebruikt, wat betekent dat het attribuut “achternaam” voor de meeste tupels leeg zal zijn. Desondanks zal de samengestelde primaire sleutel elk van de tupels op unieke wijze blijven identificeren. Het is echter onaanvaardbaar dat de waarden van alle primaire sleutelattributen tegelijkertijd leeg zijn.
• De waarde van de primaire sleutel heeft geen invloed op de rangschikking van tupels in de tabelweergave van de relatie. Zelfs als de primaire sleutelwaarde een getal is (bijvoorbeeld 1,2,3...), garandeert dit in het algemeen niet dat de tupels in de database in dezelfde volgorde worden opgeslagen en in dezelfde volgorde worden uitgevoerd. In het “algemene geval” betekent dit dat soms, vanwege de specifieke kenmerken van een bepaald DBMS, rijen in volgorde kunnen worden opgeslagen op basis van de primaire sleutel, maar dit is eerder een uitzondering. Bij het uitvoeren van queryresultaten moeten we expliciet de volgorde opgeven waarin de rijen moeten worden uitgevoerd als die volgorde belangrijk is. De resultaten van de vraag “geef mij de eerste 5 mensen” zijn onvoorspelbaar als we niet specificeren op basis van welk criterium ze “eerste” zouden moeten zijn.
• De primaire sleutel heeft geen invloed op de toegang tot de attributen van een tuple. Met betrekking tot het “paspoortkantoor” wordt bijvoorbeeld het registratieadres van de persoon opgeslagen, samen met de volledige naam en geboortedatum. We kunnen de database vragen om alle adressen te extraheren zonder de volledige naam en geboortedatum te kennen.

Buitenlandse sleutel

Een externe sleutel wordt gebruikt om verbindingen tussen relaties tot stand te brengen. Laten we bijvoorbeeld twee relaties nemen: ‘Eigenaren’ (primaire sleutel ‘paspoortnummer’) en ‘Onroerend goed’. Om vast te stellen wie de eigenaar is van elk onroerend goed, verbinden we deze relaties aan de hand van de waarde van het kenmerk ‘paspoortnummer’. In tegenstelling tot de primaire sleutel kan de waarde van een externe sleutel ongedefinieerd zijn (regel 4 op de dia). Als we de eigenaar van het onroerend goed niet kennen, geven we dit niet aan. In tegenstelling tot de primaire sleutel kan de waarde van de externe sleutel worden herhaald (standen 1.3 op de dia) - één eigenaar kan meerdere vastgoedobjecten hebben. Het feit dat het attribuut ‘paspoortnummer’ in de relatie ‘Onroerend goed’ een externe sleutel is voor de primaire sleutel van de relatie ‘Eigenaar’ garandeert echter dat de waarde van het attribuut ‘pastornummer’ alleen waarden kan zijn uit de primaire sleutel. We kunnen het pastorienummer van een persoon niet opgeven als attribuutwaarde die nog niet bestaat in de relatie Eigenaar (regel 5).

Door een refererende sleutel in te stellen, kunt u expliciet het gedrag van het DBMS instellen als u de waarde van de primaire sleutel wijzigt of een tupel verwijdert. De regel “de externe sleutel slaat alleen de waarden op die in de primaire sleutel staan ​​of een ongedefinieerde waarde (NULL)” blijft echter hetzelfde.

Bij het ontwerpen van een database wordt meestal een externe sleutel tussen relaties opgegeven. Het kan echter op elk moment worden verwijderd of opnieuw worden geïnstalleerd als het toevoegen van deze beperking niet in strijd is met de eigenschappen van de externe sleutel. Het verwijderen/installeren van externe sleutels wordt meestal gedaan bij het invoegen van zeer grote hoeveelheden gegevens, om dit proces te versnellen - het DBMS kan geen inconsistente (onjuiste, foutieve) gegevens opslaan, dus controleert het elke beperking bij het invoegen van elke rij.

ER-modellen: verbindingen

In ER-modellen worden externe sleutels weergegeven als relaties.

Elke verbinding wordt gekenmerkt door 4 eigenschappen: kracht, macht, mate en deelname van de entiteit aan de verbinding.

Laten we naar deze kenmerken kijken.

Deelname van de entiteit aan de relatie

Op de verbinding aangegeven door een dwarslijn of cirkel.

De dwarslijn betekent verplicht (verplicht) de deelname van de entiteit aan de verbinding, en de cirkel - optioneel (optioneel).

In het geval van verplichte deelname van een entiteit aan een verbinding, het werkwoord " moeten". Als de entiteit niet noodzakelijkerwijs deelneemt aan de verbinding, wordt het werkwoord " Misschien".

Op de afdeling Misschien meerdere medewerkers in dienst. Medewerker moeten werken op een van de afdelingen.

Verbindingsgraad ( relatie rang) geeft het aantal geassocieerde entiteiten aan. Binaire communicatie ( binair relatie) beschrijft de associatie van twee entiteiten. Ternaire verbinding (ternair relatie) treedt op wanneer drie entiteiten zijn gekoppeld. Unaire communicatie (unair relatie) beschrijft associaties binnen een enkele entiteit.

De meest voorkomende zijn binaire verbindingen - ze verbinden twee verschillende entiteiten ("Afdeling" - "Werknemer", "Bestelling" - "Goederen", "Cursus" - "Lezingen", "Groep" - "Studenten"). Minder gebruikelijk, maar nog steeds vaak gebruikt, zijn unaire verbindingen. Met hun hulp zetten ze meestal een nestrelatie op objecten van hetzelfde type (de relatie “Onderdelen” - we kunnen aangeven van welk onderdeel dit specifieke onderdeel deel uitmaakt, de relatie “Werknemers” - we kunnen aangeven welke medewerker de baas is voor deze).

De verbindingssterkte laat zien hoeveel exemplaren van de ene entiteit zijn verbonden met exemplaren van een andere entiteit.

Macht kan zijn:

• één-op-één(1:1) - er is één hoofdman in een groep studenten;
• één-op-veel(1:N) - veel medewerkers werken op één afdeling;
• veel-op-veel(M:N) - één koper kocht veel goederen, veel kopers kochten goederen.

Sterkte van verbinding: sterke verbinding (identificerende relatie)

Een onderliggende entiteit kan niet bestaan ​​zonder een bovenliggende entiteit. (Er is geen antwoord zonder een vraag; er is geen product in de winkelwagen van de gebruiker als de winkelwagen zelf niet bestaat)

In dit geval migreert de primaire sleutel van de bovenliggende entiteit naar de onderliggende entiteit, waar deze onderdeel wordt van de primaire sleutel.

In een diagram wordt een sterke relatie weergegeven door een ononderbroken lijn tussen entiteiten.

Relatiesterkte: niet-identificerende relatie

De bovenliggende en onderliggende entiteiten zijn gerelateerd, maar de onderliggende entiteit kan eerst worden gemaakt. (De vracht hoort bij de bestelling, maar de vracht kan zich in het magazijn bevinden voordat de bestelling wordt aangemaakt).

De primaire sleutel migreert van de bovenliggende entiteit naar de onderliggende entiteit en maakt geen deel uit van de primaire sleutel (deze wordt eenvoudigweg een externe sleutel).

In het diagram wordt een sterke relatie weergegeven door een stippellijn tussen entiteiten.

Recursieve koppeling (unaire koppeling)

Meestal gebruikt om hiërarchieën op te bouwen.

Een leverancier KAN met NUL of MEER klanten werken (id_Customer).

De klant MOET met één leverancier werken (id_Sup).

Maar de leverancier en de klant – of het nu een bedrijf of een organisatie is – zijn objecten van hetzelfde type en zijn dus in dezelfde relatie opgeslagen.

Veel-op-veel-communicatie.

Voorbeeld: Leveranciers kunnen vele soorten goederen leveren. Verschillende leveranciers kunnen dezelfde soorten goederen leveren.

Veel-op-veel-relaties zijn geldig vanuit het oogpunt van het ER-model, maar kunnen niet rechtstreeks worden weerspiegeld in termen van relationele algebra.

De dubbelzinnigheid van de relatie wordt opgelost door overgangsentiteiten te introduceren, zoals weergegeven in de dia.

ER-modellen en realiteit

Bij nadere beschouwing van een één-op-één-relatie blijkt bijna altijd dat A en B eigenlijk verschillende subsets van hetzelfde zijn, of verschillende perspectieven daarop, alleen met verschillende namen en verschillend beschreven relaties en attributen.

Laten we ons voorstellen dat A de leverancier is, en B het product.

Verplicht-verplicht. Voor het voorbeeld op de dia betekent deze relatie dat elke leverancier moeten slechts één leveren uniek set goederen (factuur). Vanuit theoretisch oogpunt is alles hier in orde. In de praktijk is dit niet acceptabel: niemand zal op zoek gaan naar een nieuwe leverancier als de door u geverifieerde leverancier meerdere productassortimenten kan leveren. En nu over de emoties die de operator zal ervaren bij het invoeren van gegevens over een nieuwe leverancier. Hij kan geen gegevens in een van de tabellen invoeren. Dus alle bagage van onfatsoenlijk taalgebruik zal op u gericht zijn.

Optioneel-verplicht. Op de dia ziet u een voorbeeld van de aansluiting. Zoals we kunnen zien, gaat alles nu goed met de operator: hij kan gegevens invoeren. Het bedrijf heeft opnieuw een probleem: het moet op zoek naar een nieuwe leverancier, ook al kan de door u geverifieerde leverancier meerdere productlijnen leveren. Heeft het bedrijfsleven problemen nodig? Nee. Het moet functioneren. Hoe maak je een bedrijf tevreden? Het antwoord is eenvoudig. Bij het ontwerpen van een database moet u nadenken over normalisatie. Als Leverancier een entiteit is, gebruik dan optioneel-verplicht (verplicht-optioneel) of optioneel-optioneel relaties. Hoewel één-op-één-relaties meestal een vergissing zijn.

Optioneel-optioneel. Zoals we kunnen zien, gaat het weer goed met de operator, maar heeft het bedrijf opnieuw een probleem. Laten we het samenvatten voor één-op-één communicatie. Als entiteiten deelnemen aan een verbinding als: - verplicht-verplicht, dan heeft een dergelijke verbinding geen recht op leven; - optioneel-verplicht (verplicht-optioneel) of optioneel-optioneel, dan is bedrijfsondersteuning problematisch.

Een één-op-veel verplicht-verplicht-relatie is een tamelijk sterke constructie die impliceert dat een voorkomen van entiteit B niet kan worden gecreëerd zonder tegelijkertijd ten minste één exemplaar van entiteit A te creëren dat daaraan is gekoppeld. Meestal is dit een onjuiste relatie.

Een één-op-veel-verplicht-optioneel-relatie is de meest voorkomende relatievorm. Het veronderstelt dat elk voorkomen van entiteit A alleen kan bestaan ​​in de context van één (en slechts één) voorkomen van entiteit B. Op zijn beurt kunnen voorkomens van B zowel met als zonder voorkomens van A bestaan.

Eén-op-veel-relatie optioneel-optioneel - Zowel A als B kunnen bestaan ​​zonder dat er een relatie tussen bestaat.

In termen van de vorige dia kunnen deze diagrammen worden geïllustreerd met de volgende voorbeelden.

Eén-op-veel-relaties. Deze relaties houden in dat één record in de ene tabel logisch gerelateerd kan zijn aan meerdere records in een andere tabel.

Verplicht-verplicht. Voor het voorbeeld op de dia betekent deze relatie dat elke leverancier (A) een of meer sets goederen (B) moet leveren. Vanuit theoretisch oogpunt is alles hier in orde. In de praktijk zal de operator echter geen gegevens in een van de tabellen kunnen invoeren, omdat dit wel het geval moet zijn tegelijkertijd beide tabellen invullen.

Optioneel-verplicht. In dit geval is alles in orde voor de operator: hij kan gegevens invoeren, maar het bedrijf kan problemen ondervinden. Het punt is dat de optioneel-verplichte relatie ervan uitgaat dat de leverancier (A) moetenéén of meer sets goederen leveren (B), terwijl B Misschien behoren tot de leverancier. Met andere woorden: goederen kunnen bestaan ​​zonder leverancier, terwijl de leverancier de goederen heeft. Die. ongecontroleerd zakelijk gedrag is mogelijk: wie heeft de goederen geleverd? Aan wie moet ik het vragen? Heeft het bedrijfsleven problemen nodig? Nee. Er moet winst gemaakt worden. In dit geval kan beter gebruik worden gemaakt van verplicht-optioneel: de leverancier kan één of meerdere sets goederen leveren, terwijl de goederen eigendom moeten zijn van de leverancier. Met andere woorden: het product heeft een leverancier en gegevens over de leveranciers die het product ooit hebben geleverd, worden bewaard. En de schapen zijn veilig en de wolven worden gevoerd – de operator kan gegevens invoeren en de zakenman is op de hoogte.

Optioneel-optioneel. Zoals we zien is alles weer goed met de exploitant, maar het bedrijf heeft een probleem: gebrek aan controle: een product kan bestaan ​​zonder leverancier en een leverancier zonder product.
Laten we het samenvatten voor één-op-veel-communicatie. Als entiteiten deelnemen aan een relatie als: - verplicht-verplicht, dan heeft een dergelijke relatie geen recht op leven, aangezien het onmogelijk is om records tegelijkertijd in beide tabellen in te voeren; - optioneel-optioneel, dan is bedrijfsondersteuning problematisch.

Veel-op-veel-relaties zijn toegestaan ​​in ER-diagrammen, maar bij conversie naar een tabelweergave wordt de relatie vervangen door een tussenliggende entiteit.

Veel-op-veel verplicht-verplicht - deze constructie komt vaak voor aan het begin van de analysefase en betekent een relatie - die ofwel niet volledig wordt begrepen en aanvullende resolutie vereist, ofwel een eenvoudige collectieve relatie weerspiegelt - een bidirectionele lijst.

Veel-op-veel verplicht-optioneel - zelden gebruikt. Dergelijke verbindingen zijn altijd onderworpen aan verdere details.

Recursieve verbindingen. Deze relaties suggereren dat tabelgegevens logisch aan elkaar gerelateerd kunnen zijn.

Optioneel-optioneel één-op-één. Voor het voorbeeld op de dia betekent deze relatie dat elke man (vrouw) met één vrouw (man) kan trouwen. Deze verbinding is handig om de geschiedenis van degenen die trouwen te volgen: voor de eerste keer, opnieuw, ... Met andere woorden, een alternatief type relatie.

Optioneel-optioneel één-op-veel. Op de dia ziet u een voorbeeld van de aansluiting. Dit is een klassieke hiërarchie (boomstructuur). De relatie op de slide kan bijvoorbeeld als volgt worden geïnterpreteerd: iedere medewerker kan aan slechts één manager rapporteren, terwijl een manager één of meerdere medewerkers kan aansturen.

Optioneel-optioneel M:M Een voorbeeld van communicatie wordt getoond op dia 3. Dit is een netwerkstructuur.

Controlelijst met vragen over entiteiten

• Weerspiegelt de entiteitsnaam de essentie van dit object?
• Is er sprake van overlap met andere entiteiten?
• Zijn er minstens twee kenmerken?
• Er zijn in totaal niet meer dan acht attributen?
• Zijn er synoniemen/homoniemen voor deze entiteit?
• Is de entiteit volledig gedefinieerd?
• Is er een unieke identificatie?
• Is er minimaal één verbinding?
• Is er ten minste één functie voor het maken, zoeken, bewerken, verwijderen, archiveren en gebruiken van een entiteitswaarde?
• Is er een geschiedenis van veranderingen?
• Wordt er voldaan aan de beginselen van gegevensnormalisatie?
• Bestaat dezelfde entiteit in een ander applicatiesysteem, misschien onder een andere naam?
• Is de essentie te algemeen?
• Is het niveau van generalisatie dat erin besloten ligt voldoende?

Kenmerken checklist:

• Is de attribuutnaam een ​​enkelvoudig zelfstandig naamwoord dat de essentie weerspiegelt van de eigenschap die door het attribuut wordt aangegeven?
• Bevat de attribuutnaam niet de entiteitsnaam (dat zou niet moeten)?
• Heeft een attribuut slechts één waarde tegelijk?
• Zijn er dubbele waarden (of groepen)?
• Zijn het formaat, de lengte, aanvaardbare waarden, het verkrijgen van algoritme, enz. beschreven?
• Zou dit attribuut een ontbrekende entiteit kunnen zijn die nuttig zou zijn voor een ander applicatiesysteem (bestaand of voorgesteld)?
• Zou hij een gemiste verbinding kunnen zijn?
• Is er ergens een verwijzing naar een attribuut als een “ontwerpkenmerk” dat zou moeten verdwijnen als het naar het applicatieniveau gaat?
• Is er behoefte aan een veranderingsgeschiedenis?
• Hangt de betekenis ervan alleen af ​​van deze entiteit?
• Als de waarde van het attribuut vereist is, is deze dan altijd bekend?
• Is het nodig om een ​​domein aan te maken voor deze en soortgelijke kenmerken?
• Is de waarde ervan alleen afhankelijk van een deel van de unieke identificatie?
• Is de waarde ervan afhankelijk van de waarden van sommige attributen die niet zijn opgenomen in de unieke identificatie?

ER-modellen los van het onderwerp van het ontwerpen van relationele databases.

Maar als je tegelijkertijd de termen van het ER-model en het relationele datamodel moet gebruiken, dan moet je natuurlijk de termen gebruiken relatie En relatie verschillende Russische equivalenten. Er zitten heel verschillende concepten achter deze termen. In het relationele model is relatie de enige generieke gegevensstructuur. Ditzelfde mechanisme wordt gebruikt om “gerelateerde” entiteiten weer te geven (denk bijvoorbeeld aan externe sleutels). Zoals we later zullen zien, gebruikt het ER-model twee gelijkwaardige concepten om het databaseschema weer te geven: entiteit en relatie. Relaties in het ER-model spelen een andere rol dan relaties in het relationele datamodel.

Bovendien is pure transliteratie van de term ook in de Russischtalige terminologie terechtgekomen relatie precies in de zin houding. We praten bijvoorbeeld over een relationeel datamodel, relationele algebra, enz., terwijl we een op relaties gebaseerd datamodel, relationele algebra, enz. begrijpen. Bij deze gelegenheid is het, tenminste in de context van databases, redelijk om eindelijk te reserveren de voorwaarden relatie En houding om de concepten van het relationele datamodel aan te duiden, en voor de term relatie gebruik een ander aanvaardbaar Russisch equivalent: communicatie.

De meeste moderne benaderingen van databaseontwerp (voornamelijk relationeel) zijn gebaseerd op het gebruik van verschillende versies van het ER-model. Het model werd in 1976 voorgesteld door Peter Chen. Modellering vakgebied is gebaseerd op het gebruik van grafische diagrammen die een klein aantal heterogene componenten bevatten. Eenvoud en helderheid van presentatie conceptuele databasediagrammen in het ER-model leidde tot het wijdverbreide gebruik ervan in CASE-systemen die geautomatiseerde ondersteuning bieden relationeel databaseontwerp. Van de vele varianten van ER-modellen werd een van de meest populaire en ontwikkelde gebruikt in het Oracle CASE-systeem. We zullen een vereenvoudigde versie van dit model bespreken. Om preciezer te zijn, laten we ons concentreren op de structurele en integrale delen ervan.

Basisconcepten van het ER-model

De belangrijkste concepten van het ER-model zijn entiteit, relatie en attribuut. Essence is een reëel of denkbaar object, waarvan informatie moet worden opgeslagen en toegankelijk moet zijn. 4 Het is duidelijk dat deze ‘definitie’ feitelijk een tautologie is, aangezien we in de eerste plaats proberen de term entiteit te definiëren via de ongedefinieerde term object, en in de tweede plaats pogingen om de term object te definiëren net zo hopeloos zijn. Meestal proberen auteurs zichzelf te rechtvaardigen door te zeggen dat ze in een dergelijke context het ‘alledaagse’ bedoelen en niet een of ander geformaliseerd concept van een object. Dit maakt het uiteraard niet eenvoudiger, aangezien het begrip essentie in een vrij precieze zin moet worden begrepen. Maar deze tautologie is niet bedacht door de auteur van deze cursus; het is traditioneel op het gebied van semantische modellering. Op dit gebied proberen ze formaliteiten zoveel mogelijk te vermijden. In ER-modeldiagrammen wordt een entiteit weergegeven als een rechthoek met daarin de entiteitsnaam. In dit geval is de naam van de entiteit de naam van het type, en niet van een specifiek exemplaar van dit type. 5 Hoewel het juister zou zijn om altijd de termen entiteitstype en te gebruiken entiteitstype exemplaar Om breedsprakigheid te vermijden (en de traditie te volgen) in gevallen waarin dit niet tot dubbelzinnigheid leidt, zullen we de term entiteit gebruiken om het entiteitstype aan te duiden. Voor een grotere expressiviteit en een beter begrip kan de naam van een entiteit vergezeld gaan van voorbeelden van specifieke exemplaren van dat type.

Rijst. 9.1.

Op rijst. 9.1 de essentie van de luchthaven wordt afgebeeld met kopieën van Sheremetyevo en Heathrow bij benadering. Dit primitieve diagram bevat niettemin belangrijke informatie. Ten eerste laat het zien dat de database hetzelfde type datastructuren zal bevatten ( entiteitsinstanties), waarin luchthavens worden beschreven. Ten tweede, omdat er in het leven op luchthavens verschillende gezichtspunten zijn (bijvoorbeeld het gezichtspunt van een piloot, het gezichtspunt van een passagier, het gezichtspunt van een beheerder) en verschillende datastructuren overeenkomen met deze gezichtspunten. Met de gegeven voorbeelden van luchthavens kunnen we de aanvaardbare reeks standpunten enigszins beperken. In ons geval worden voorbeelden gegeven van internationale luchthavens, dus hoogstwaarschijnlijk is er een standpunt van een passagier of piloot van internationale vluchten.

Wanneer u een entiteitstype definieert, moet u ervoor zorgen dat elk entiteitsinstantie kan worden onderscheiden van elk ander exemplaar van dezelfde entiteit. Deze vereiste lijkt enigszins op de vereiste dat er geen dubbele tupels in relationele tabellen voorkomen.

Verbinding is een grafisch weergegeven associatie tussen twee entiteitstypen. Net als een entiteit is een relatie een algemeen concept; alle instanties van beide geassocieerde typen entiteiten zijn onderworpen aan vastgestelde associatieregels. Daarom is het juister om te praten over het type verbinding dat tot stand is gebracht tussen entiteitstypen, en over verbindingstype-instanties, geïnstalleerd tussen exemplaren van het entiteitstype. 6Net als bij het entiteitstype gebruiken we echter vaak de term relatie om het relatietype aan te duiden. In de hier besproken versie van het ER-model is deze associatie altijd binair en kan deze tussen twee verschillende bestaan entiteitstypen of tussen het type entiteit en zichzelf ( recursieve verbinding). Bij elke verbinding worden twee uiteinden geïdentificeerd (in overeenstemming met het bestaande paar verbonden entiteiten), op elk waarvan de naam van het uiteinde van de verbinding wordt aangegeven, mate van einde van de verbinding(hoeveel exemplaren van een bepaald entiteitstype moeten aanwezig zijn in elke instantie van een bepaald relatietype), verplichte communicatie(dat wil zeggen of een instantie van een bepaald entiteitstype moet deelnemen aan een instantie van een bepaald relatietype). 7 In sommige versies van het ER-model wordt het einde van de verbinding genoemd rol van communicatie in deze entiteit. Dan kunnen we praten over de naam van de rol, de mate van de rol en de verplichting van de communicatierol in deze entiteit.

Een verbinding wordt weergegeven als een ongerichte lijn die twee entiteiten verbindt of van een entiteit naar zichzelf leidt. In dit geval wordt op het verbindingspunt met de entiteit het volgende gebruikt:

• driepuntsinvoer in een entiteitrechthoek als voor die entiteit de relatie veel ( veel) entiteitsinstanties ;
• single-point entry, als er maar één kan (of zou moeten) deelnemen aan de verbinding entiteitsinstantie.

Het vereiste uiteinde van de verbinding wordt weergegeven met een ononderbroken lijn en het optionele uiteinde met een stippellijn.

De relatie tussen de entiteiten TICKET en PASSENGER, weergegeven in rijst. 9.2, verbindt tickets en passagiers. Een linkeinde met de naam "for" maakt het mogelijk dat meer dan één ticket aan dezelfde passagier wordt gekoppeld, waarbij elk ticket aan een andere passagier wordt gekoppeld. Het einde van de verbinding met de naam "has" geeft aan dat elk ticket slechts in het bezit kan zijn van één passagier en dat de passagier niet verplicht is om ten minste één ticket te hebben.

Rijst. 9.2.

• Elk TICKET is bedoeld voor één en slechts één PASSAGIER;
• Elke PASSAGIER kan één of meer TICKETS hebben, of helemaal geen.

In het volgende voorbeeld ( rijst. 9.3) is afgebeeld recursieve verbinding, die de essentie van MAN met zichzelf verbindt. Het einde van de verbinding met de naam "zoon" definieert het feit dat meerdere mensen zonen van dezelfde vader kunnen zijn. Het einde van de connectie met de naam "vader" betekent dat niet elke man zonen zou moeten hebben.

Een laconieke mondelinge interpretatie van het afgebeelde diagram is als volgt:

• iedere MAN is de zoon van één en slechts één MAN;
• iedere MAN kan de vader zijn van één of meerdere MANNEN.

Entiteitskenmerk is elk detail dat dient om de toestand van een entiteit te verduidelijken, identificeren, classificeren, numeriek te karakteriseren of uit te drukken. Attribuutnamen worden ingevoerd in een rechthoek met een afbeelding

Gegevensmodel voor entiteitsrelaties

Het entiteit-relatie datamodel werd in 1976 geïntroduceerd door P.P. Chen. Het heeft veel gemeen met hiërarchische en netwerkdatamodellen en kan, vanwege zijn oriëntatie op het ontwerpproces, worden beschouwd als een generalisatie en ontwikkeling van eerder besproken modellen. Het beschreven model maakt een directe weergave van verbindingen van het type mogelijk M: N.

Basisconcepten. Entiteitsmodel-verbinding" is gebaseerd op het idee dat de echte wereld bestaat uit verschillende entiteiten die met elkaar verbonden zijn door bepaalde relaties. De categorieën ‘essentie’ en ‘relatie’ worden fundamenteel verklaard, en hun verdeling wordt gemaakt in de fase van het creëren van specifieke representaties van een bepaald vakgebied.

Elke entiteit behoort tot een bepaalde klasse of heeft een overeenkomstig type. Er zijn verbindingen tussen entiteiten, waaraan de gebruiker een klasse (type) toewijst. Dus, entiteit klasse En obligatie klasse sets van specifieke objecten en verbindingen daartussen definiëren. Houd er rekening mee dat een entiteit tot meer dan één klasse kan behoren (een leverancier kan bijvoorbeeld ook een consument zijn). Op elk moment, de staat van communicatie S tussen entiteitsklassen E 1, E 2 ..., En n gedefinieerd door de relatie tussen DOM-sets E 1, DOM E2,..., DOM Nl, waar DOM E ik, i= - set objecten van het type E ik.

De reeks verbindingen in het ‘entiteitsrelatie’-model kan worden weergegeven als een wiskundige relatie N objectklassen:

Waar e ik- een entiteit die tot een reeks entiteiten behoort E ik, colonne<e 1 e 2 ... e n >- verbinding van vele verbindingen R. Het is niet nodig dat iedereen E ik, waarop het wordt bepaald R, waren anders. De verzameling entiteiten en relatieklassenvormen hoogste niveau van het model.

Entiteiten en relaties worden beschreven aan de hand van hun karakteristieke kenmerken. Onder de attributen van een entiteit of relatie wordt een sublijst onderscheiden waarvan de attribuutwaarden de entiteit of relatie binnen het type op unieke wijze identificeren. Entiteiten, relaties en attributen worden gevormd lagere niveau van het model.

Grafisch wordt het 'entiteitsrelatie'-model gepresenteerd in de vorm van een diagram waarin elke klasse objecten overeenkomt met een rechthoek en met de klasse van verbindingen - een zeshoek (Fig. 2.7). Onder de rechthoek en zeshoek worden de namen van de attributen van entiteiten en relaties aangegeven.

Rijst. 2.7. Grafische weergave van het entiteit-relatiemodel:

a) entiteitsklasse; b) klasse van verbindingen;

Bij het weergeven van een entiteitsklasse zullen we de volgende notatie aanhouden: sleutelattributen zijn onderstreept; twee verschillende entiteitsklassen kunnen niet dezelfde naam hebben.

De volgende beperkingen zijn van toepassing op communicatie:

soorten verbindingen tussen klassen worden in paren gespecificeerd (1:1, 1: N, N: 1, M: N). Wanneer waarden M en N gespecificeerd, wordt de maximale waarde genomen;

Eén relatie kan betrekking hebben op veel entiteiten en één entiteit kan veel relaties hebben. Bij aansluitingen van type 1:1, 1: N, N: 1 is het niet altijd nodig om de verbindingsnaam op te geven.

Laten we een voorbeeld bekijken van de representatie van een conceptueel databasediagram met behulp van het 'entiteitsrelatie'-model (Fig. 2.8). Laten er de volgende toepassingen zijn: beheer van voorraden, magazijn, productie en contracten. Deze applicaties kunnen de volgende entiteitsklassen gebruiken: SUPPLIER (leveranciers), BAZ-DET (basisonderdelen), IZD-UNIT (producten en samenstellingen), CONTRACT (contracten), WERKNEMER (medewerkers), DEPARTMENT (afdelingen).

Rijst. 2.8. Een voorbeeld van een entiteit-relatiemodeldiagram

Om aan de vereisten van bovengenoemde toepassingen te voldoen, worden de volgende relaties tussen entiteiten gebruikt:

SELECTEER - hiermee kunt u een leverancier van het basisproduct selecteren, afhankelijk van de verkoop- en leveringsvoorwaarden (deze voorwaarden worden gespecificeerd in het diagram);

ASSEMBLY-DB - geeft de basisonderdelen (materialen) aan die rechtstreeks worden gebruikt voor de productie van een product of assemblage, evenals hun aantal;

MONTAGE-EENHEID - geeft eenheden aan die rechtstreeks in andere eenheden of producten zijn opgenomen, evenals hun aantal;

POST-BAZ - verbindt leveranciers met basisgegevens in het contract;

AANWIJZING - karakteriseert producten en componenten in het contract;

VERANTWOORDELIJK - geeft de persoon aan die verantwoordelijk is voor het contract;

DEELT - bindt de overeenkomst en de mensen die deelnemen aan de uitvoering ervan;

WORKS - verbindt de afdeling en de mensen die er werken;

BEHEERT - geeft het hoofd van deze afdeling aan.

Het entiteit-relatiemodeldiagram kan worden beschreven zoals weergegeven in Fig. 2.8.

Entiteitsklassen:

E1/LEVERANCIER [NOM-POST, FAM-POST, ADRES];

E2/BAZ-DET [NOM-BDZ-DET, NAIM-BASE-DET, AANTAL-IN-VOORRAAD, MINIMUM-AANTAL];

E3/OVEREENKOMST [NOM-HOND, DATUM];

Lessen koppelen:

L 1/POST-BAZ L2/KIEZEN L3/ASSEMBLY-DB

[LEVERANCIER, BAZ-DET, CONTRACT];

[LEVERANCIER, BASIS-DET: PRIJS, DEADLINE];

[BASE-DET, ED-NODE: HOEVEELHEID-DB];

Namen van relatieattributen worden door een dubbele punt gescheiden van de namen van entiteitsklassen.

Het entiteit-relatiemodel omvat verschillende domeinkenmerken.

1. Een relatie kan betrekking hebben op verschillende klassen van entiteiten. De POST-BAZ-relatie verbindt bijvoorbeeld de entiteitsklassen LEVERANCIER, BAZ-DET, CONTRACT.

2. Een relatie kan meerdere keren verwijzen naar dezelfde entiteitsklasse, bijvoorbeeld een ASSEMBLY-NODE-relatie.

3. Veel relaties kunnen tot dezelfde entiteitsklasse behoren, bijvoorbeeld de relaties WORKS en MANAGES tussen de entiteiten WERKNEMER en AFDELING.

4. Het model geeft verschillende aansluitingen weer zoals 1:1, 1: N, M: N.

5. Door de aanwezigheid van twee klassen entiteiten voor onderdelen BAZ-DET en IZD-UZEL kunt u het volgende beheren: de levering van onderdelen en het vinden van leveranciers op basis van de BAZ-DET-klasse; het productieproces van producten met behulp van de IZD-UZEL-klasse.

6. Twee klassen entiteiten BAZ-DET en IZD-NODE hebben gemeenschappelijke en specifieke attributen. De aanwezigheid van gemeenschappelijke kenmerken leidt tot enige gegevensredundantie. Specifieke attributen zijn vereist vanwege de reikwijdte van de objecten.

In het diagram (Fig. 2.8) zou men alleen de functie van het verkopen van producten kunnen beschouwen. In dit geval zou het externe diagram alleen entiteiten bevatten: basisonderdelen, eenheden, producten die samen met de verbindingen daartussen uit het conceptuele diagram moeten worden gehaald. In het externe diagram moet onderscheid worden gemaakt tussen producten en samenstellingen, omdat sommige informatie die nodig is voor de verkoop alleen relevant is voor producten.

Om de problemen van het beheer van een magazijn en de productie van producten op te lossen, is het noodzakelijk om het assortiment producten en assemblages te beschrijven, met vermelding van: de samenstelling van producten uit assemblages en basisonderdelen, de samenstelling van assemblages uit subassemblages en basisonderdelen.

Om meer specifieke relaties tussen entiteiten aan te geven, zijn er direct En feedback. Elke dergelijke verbinding heeft een naam en een paar cijfers.

Rijst. 2.9. Schema van directe en feedbackverbindingen

In de relatie tussen de entiteiten WERKNEMER en AFDELING (Figuur 2.9) geeft de directe relatie WERKEN bijvoorbeeld aan dat de werknemer slechts op één afdeling werkt; De BEVAT-feedback geeft aan dat de afdeling minimaal één medewerker bevat (meestal veel medewerkers). Met andere woorden: verbinding L tussen twee entiteitsklassen A En IN geeft aan dat de entiteit A tenminste geassocieerd met M en, als maximum, met N entiteiten IN. Soms N mag niet worden bepaald.

Het entiteit-relatiemodel ontstond in verband met de behoeften van databaseontwerp. Het voldoet aan twee belangrijke criteria: ten eerste stelt de kracht van de instrumenten het in staat de structuren en beperkingen weer te geven die inherent zijn aan de echte wereld, en ten tweede is de kloof tussen de mogelijkheden van het model en industriële DBMS'en niet te groot. Deze modellen helpen ontwerpers om met gebruikers te communiceren tijdens het proces van het analyseren en ontwerpen van een database.

Relationeel model

Basisconcepten

In een relationeel datamodel wordt informatie opgeslagen in een of meer gerelateerde tabellen. Een enkele tabel vertegenwoordigt gewoonlijk een verzameling (groep) van echte objecten, of enkele abstracte concepten, of gebeurtenissen van hetzelfde type. Elke vermelding in de tabel identificeert één communicatieobject. Een tabel bestaat uit rijen en kolommen, respectievelijk records en velden genoemd. Tabellen hebben de volgende eigenschappen:

1. Elk tabelelement vertegenwoordigt één data-element, d.w.z. een groep waarden in één kolom van één rij is niet toegestaan;

2. Alle kolommen in de tabel zijn homogeen. Dit betekent dat de elementen van de kolom van dezelfde aard zijn. De kolommen krijgen namen;

3. Er zijn geen twee identieke rijen in de tabel;

4. De volgorde van rijen en kolommen in de tabel kan willekeurig zijn. Bij bewerkingen met een dergelijke tabel kunnen de rijen en kolommen ervan in elke volgorde worden bekeken, ongeacht hun informatie-inhoud of betekenis.

Tabellen met dergelijke eigenschappen zijn een exact prototype van een wiskundige tweedimensionale set: een relatie. Maar deze twee concepten zijn niet gelijkwaardig. Een relatie is een abstract wiskundig object, en een tabel is een concrete weergave van dat abstracte object. Het verschil komt tot uiting in hun eigenschappen. In een relatie kunnen de rijen en kolommen ongeordend zijn, maar in een tabel zijn de rijen van boven naar beneden geordend en de kolommen van links naar rechts. Rijen in een tabel kunnen herhaalde rijen zijn, maar niet in een relatie.

In het relationele model is elke rij in een tabel uniek. Dit wordt bereikt door sleutels te gebruiken die een of meer tabelvelden bevatten. Sleutels worden op een georganiseerde manier opgeslagen, waardoor tijdens zoekopdrachten directe toegang tot tabelrecords mogelijk is. De verbinding tussen tabellen wordt tot stand gebracht via de waarden van een of meer overeenkomende velden (meestal de belangrijkste).

Hier volgen een aantal termen die in het relationele model worden gebruikt:

· Houding (relatie) is een tweedimensionale set - een tafel die aan de bovenstaande vereisten voldoet;

· Attribuut is een eigenschap die een object karakteriseert. In de tabelstructuur heeft elk attribuut een naam en een bijbehorende tabelkolomkop. Het aantal attributen wordt opgeroepen mate van relatie ;

· Per colonne (tuple) is een tabelrij. Over het algemeen zijn tupels een set paren<атрибут>, <значение>. Elke waarde moet atomair zijn, d.w.z. kan niet meerwaardig of samengesteld zijn. Daarom worden meerwaardige en samengestelde attributen niet ondersteund in het relationele model. Het aantal tupels wordt genoemd hoofdtelwoord ;

· Domein vertegenwoordigt de verzameling van alle mogelijke waarden van een bepaald attribuut van een relatie.

· Primaire sleutel is een attribuut van een relatie dat elk van zijn tupels op unieke wijze identificeert. De sleutel kan samengesteld (complex) zijn, dat wil zeggen uit meerdere attributen bestaan.

· Potentiële sleutel is een subset van relatieattributen met de volgende eigenschappen:

De eigenschap van uniciteit. Er zijn geen identieke tupels met dezelfde kandidaat-sleutelwaarden;

De eigenschap van niet-redundantie. Geen enkele subset van een potentiële sleutel is uniek.

Elke relatie heeft noodzakelijkerwijs een combinatie van kenmerken die als sleutel kunnen dienen. Het bestaan ​​ervan wordt gegarandeerd door het feit dat een relatie een wiskundige verzameling is die geen identieke tupels kan bevatten, d.w.z. tenminste de gehele set attributen heeft de eigenschap om tupels van een relatie uniek te identificeren. Er kunnen gevallen zijn waarin een relatie meerdere combinaties van attributen heeft, die elk op unieke wijze alle tupels van de relatie identificeren. Al deze attribuutcombinaties zijn potentiële of mogelijke relatiesleutels. Eén kandidaatsleutel wordt geselecteerd als primaire sleutel, de rest wordt secundair (alternatief) genoemd. Er kunnen zich zelfs situaties voordoen waarin een van de kandidaatsleutels als primaire sleutel kan worden gekozen. Een voorbeeld is het periodiek systeem met de velden Naam, Symbool En Atoomnummer. Potentiële sleutels zijn erg belangrijk in de relationele theorie. Ze worden gebruikt om tupels te adresseren. Door de waarde van een potentiële sleutel op te geven, ontvangen we gegarandeerd niet meer dan één tupel. Voor relaties die gerelateerd zijn aan andere 'basis'-relaties zijn er ook externe sleutels die worden gebruikt om de relatie tot stand te brengen.

· Buitenlandse sleutel - Dit is een attribuut van een ondergeschikte relatie dat wordt gebruikt om een ​​verbinding tot stand te brengen met de basisrelatie. Het bevat waarden die altijd overeenkomen met enkele van de kandidaat-sleutelwaarden van de onderliggende relatie.

Op basis van de bovenstaande concepten kan de relatie wiskundig als volgt worden beschreven. Laat ze gegeven worden N sets Dl, D2, D3,..., Dn. Dan de houding R er zijn veel geordende tupels<d1, d2, d3 ,..., dn>, Waar dk Î Dk, dk – attribuut , A Dk – relatiedomein R.

Halverwege de jaren zeventig stelde IBM-ingenieur Codd een datamodel voor, gebaseerd op wiskundige bewerkingen van calculus en relationele algebra. De belangrijkste structurele eenheid van dit model was de relatie. Daarom wordt dit datamodel relationeel genoemd. Codd ontwikkelde ook een taal voor het manipuleren van gegevens die als relaties worden weergegeven. Hij stelde twee versies van de datamanipulatietaal voor die gelijkwaardig zijn qua expressieve mogelijkheden:

5. Relationele algebra. Het is een proceduretaal omdat de relatie die voortkomt uit een zoekopdracht in een relationele database wordt geëvalueerd door het uitvoeren van een reeks relationele operatoren die op de relaties worden toegepast. Operatoren bestaan ​​uit operanden, dit zijn relaties, en relationele bewerkingen. Het resultaat van een relationele operatie is een relatie. De bewerkingen van relationele algebra kunnen in twee groepen worden verdeeld. De eerste groep bestaat uit bewerkingen op verzamelingen, waaronder de bewerkingen van unie, snijpunt, verschil, deling en cartesiaans product. De tweede groep bestaat uit speciale operaties op het gebied van relaties: projectie, selectie en verbinding.

6. Relationele berekening. Het is een niet-procedurele taal van beschrijvende of declaratieve aard, die alleen informatie bevat over het gewenste resultaat. Het proces om dit resultaat te verkrijgen is verborgen voor de gebruiker. Talen van dit type zijn onder meer SQL en QBE. De eerste is gebaseerd op de tupel relationele calculus, de tweede op de domein relationele calculus.

Met deze talen kunt u een subset van de kolommen en rijen van een tabel ophalen, waardoor kleinere tabellen ontstaan, en u kunt gerelateerde gegevens uit meerdere tabellen combineren, waardoor grotere tabellen ontstaan. Bijgevolg kunnen verschillende gebruikers verschillende gegevenssets en relaties daartussen in een relationele database selecteren. Deze manier van data presenteren is voor de eindgebruiker het meest natuurlijk en begrijpelijk. Het relationele datamodel is zeer flexibel omdat elke representatie van gegevens met enige redundantie kan worden teruggebracht tot tweedimensionale tabellen.

Relatie

De theoretische basis van de relationele benadering van databases is de wiskundige relatietheorie. Basisconcepten en bewerkingen op relaties worden gebruikt in relationele databases.

Basisconcepten en manieren om relaties weer te geven. Elk systeem (wiskundig, informatief) is direct gerelateerd aan een groot aantal systemen voorwerpen, of elementen. In de wiskunde worden dus reeksen getallen gebruikt: natuurlijk, positief, reëel, enz. In de algebra wordt rekening gehouden met elementen die kunnen worden opgeteld, afgetrokken, vermenigvuldigd, enz., en in de meetkunde - reeksen punten: rechte lijnen, lijnen, vliegtuigen, enz.. Het informatiesysteem van een object, bijvoorbeeld een onderwijsinstelling, bevat informatie over docenten, studenten, afdelingen, faculteiten, laboratoria, lesroosters, etc.

Naast elementen omvat het systeem ook verbindingen en relaties daartussen. Ja, cijfers A En B kan gelijk zijn ( A = B), zijn niet gelijk ( A ≠ B), A groter dan of gelijk aan B (A ≥ B); cijfers A En IN kan congruent zijn ( A = IN), A mag bevatten IN (EEN B); twee recht A En IN kan parallel zijn ( A || IN), loodrecht (). Student A hoort bij het stel A(studenten van de afdeling).

Alle bovenstaande relaties hebben betrekking op twee objecten en worden daarom genoemd binaire relaties of gewoon relaties. De relatie tussen drie objecten wordt genoemd ternair, en tussen N voorwerpen - n-ary. De relatie tussen de objecten KLANT, LEVERANCIER en PRODUCT is dus drieledig.

Binaire relatie R tussen sets A En IN(aangeduid R(A, IN)) is een reeks geordende paren ( A, B), Waar A A, B IN. Als ( A,B) R, dan zeggen ze dat A staat in relatie R Naar B en schrijf op aRb, Omdat de set bestelde paren ( A, B), Waar A A, B IN, is een cartesiaans product A× IN, dan zal een binaire relatie elke subset van dit product zijn.

Voorbeeld 2.1. Denk eens aan de vele leveranciers en de vele aangeboden producten. Elke subset van LEVERANCIER-PRODUCT-relaties is een binaire relatie.

Voorbeeld 2.2. Laat gegeven sets A= (1, 2, 3) en IN= (2, 3, 4, 5, 6). Cartesisch product A× IN- dit is een set paren:

(1, 2), (1, 3), …, (1, 6),

(2, 2), (2, 3), …, (2, 6),

(3, 2), (3, 3), …, (3, 6).

Laten we een binaire relatie construeren R, waarvan het eerste element een deler is van het tweede. We krijgen de volgende binaire relatie: R={(1, 2), (1, 3), (1, 4), (1, 5), (1, 6), (2, 2), (2, 4), (2, 6), (3, 3), (3,6)}.

Voorbeeld 2.3. Laat Olga (O), Pavel (P), Ivan (I) de namen zijn van de kinderen in het gezin. Houding A- Broer B zullen:

R= ((P, O), (I, O), (P, Ik), (I, P)).

Met betrekking tot R(A, IN) set A, d.w.z. de verzameling van alle eerste coördinaten wordt aangeroepen domein van definitie van de relatie R, en het stel B, dat wil zeggen de verzameling van alle tweede coördinaten, - bereik van zijn waarden. Dus, bijvoorbeeld 3.3, is het definitiedomein de verzameling (P, I), en het bereik van waarden is de verzameling (O, P, I).

Complement van een binaire relatie R we zullen de relatie noemen die de deelverzameling definieert

= (A× B)\R,

die. een b als en slechts als ( A, B) R. Dus bijvoorbeeld 2.2

= {(2, 3), (2, 5), (3, 2), (3, 4), (3, 5)}.

Binaire relaties kunnen op verschillende manieren worden gespecificeerd: matrices, grafieken, tabellen (secties). Houding R(A, IN), Waar A = {A 1, A 2 , ..., ben}; B = {B 1, B 2 , ..., b n), kan worden weergegeven door een aangrenzende matrix, waarvan de rijen overeenkomen met de elementen A en kolommen - naar elementen IN; op het kruispunt en ik e lijn en b j de e kolom wordt geschreven als 1 als a ik Rb j en 0 als a ik Rb j. Nabijheidsmatrices voor relaties R en bijvoorbeeld 2.2 zien ze eruit

R

Binaire relatie R(A, IN) kan worden weergegeven als een gerichte grafiek. Elementen van de set A En IN- hoekpunten van de grafiek, en die en alleen die elementen zijn verbonden door een rand A A, B IN, waarvoor ( A, B) R. Dus in de vorm van een grafiek in Fig. 2.10 geeft een voorbeeldrelatie:

Rijst. 2.10. Weergave van relatie R als grafiek

Laat er drie sets gegeven worden A, IN, MET en twee relaties R(A, IN) En S(B, MET). Samenstelling, of vermenigvuldiging, relaties R En S een binaire relatie genoemd R.S.(of R*S) tussen elementen van sets A En MET zodanig dat aRSc dan en slechts dan als er minstens één element is B IN, waarbij waar aRb En bSc.

Voorbeeld 2.4. Laten we de sets eens bekijken

A = {A 1, A 2 , A 3 }, IN = {B 1 , B 2 , B 3 }, MET = {Met 1 , C 2 , C 3 , C 4 }

en relaties

R (A, B) = {(A 1 , B 2), (A 2 , B 1), (A 2 , B 3), (A 3 , B 4)},

S(B, C) = {(B 1 , C 2), (B 2 , C 1)}.

Vermenigvuldigingsverhoudingen R.S. kan worden weergegeven in de vorm van een grafiek (Fig. 2.11.).

Vermenigvuldiging van binaire relaties is associatief, dat wil zeggen ( R.S.)T= R(ST). Laat de relatie gegeven worden R(A, IN), S(B, MET) En T (MET, D). Dan A(R.S.)Td= aR(ST)D, d.w.z. element A A als en slechts dan in elk van de relaties zit ( R.S.)T En R(ST) naar element D D wanneer dergelijke elementen bestaan B IN En C MET, Wat aRb, bSc, cTd. Vermenigvuldiging van relaties is echter in het algemeen niet commutatief (commutatief), dat wil zeggen R.S.≠SR. Deze operatie vindt alleen plaats in speciale gevallen (in dit geval wordt dat gezegd R En S verplaatsbaar).

Voorbeeld 2.5. Laat gegeven sets

EEN = (a, b), B = (a, b, c), C = (b, c)

en relaties R (A, IN) = {(A, B), (B, Met)}, S (B, C) = {(B, Met), (A, B)). Dan aRSc = aSRc voor wie dan ook A A En C MET.

Vermenigvuldiging k betrekkingen R op een setje H, d.w.z. k-de graad R, aangegeven Rk, wordt recursief als volgt gedefinieerd:

1) aR l B waar wanneer waar aRb;

2) aR i B Voor i>0 is waar als dit bestaat Met A,
Wat boog En cR ik-l B zijn waar.

Laten we hebben aR 3 B. Dan is er zoiets Met 1, wat boog 1 en C 1 R 2 B. Voor C 1 R 2 B er is zoiets als dit Met 2 wat C 1 RC 2 en C 2 Rb, d.w.z. voor aR 3 B er bestaat zoiets Met 1, Met 2 A, Wat ARC 1 , C 1 RC 2 en Met 2 Rb.

Laat relaties in een of meer sets worden gegeven R ik (i loopt door vele indexen I) En S. Dan

, (2.1)

Volgens A[(U R ik)S]Met er is zo'n element B, Wat A(Ri)B En bSc. En dit komt op zijn beurt overeen met het bestaan ​​van een dergelijke index i 0 wat een R B En bSc, d.w.z.

Rijst. 2.11. Weergave van de werking van vermenigvuldigingsrelaties RS in de vorm van een grafiek

een(R S) c en daarom A(R ik S)C. Merk op dat in gelijkheden (3.1) de vereniging niet kan worden vervangen door een snijpunt. Uit (3.1) volgt dat als er relaties zijn gegeven R, R" En S, En R R", Dat

RS R"S, SR SR". (2.2)

Sinds inderdaad R R' Dat R R" = R", wat leidt tot gelijkheid ( R R’) S = RS R’S = R’S, wat gelijk staat aan inclusief RS R"S.a, indien voor een functionele relatie R de symmetrische relatie is ook functioneel.

Elke houding R(A, IN) kan aan de functie worden gekoppeld F(X), als de doorsnede voor elk X A leeg of een element van de set IN. Als F(X) wordt overal gedefinieerd, dat wil zeggen dat het domein van de definitie van de functie samenvalt met A, dan zeggen ze dat de verhouding R(A, IN) is een kaart van de set A V IN. Functionele relatie R(A, IN) wordt genoemd weergave A V IN, indien voor elk A A er is maar één element

Rijst. 2.12. Weergave van de functionele relatie R(A, B) in de vorm van een grafiek

B B, die de relatie bevredigt aRb. Element B genaamd manier element A en wordt aangewezen aR en het element A- prototype van een element B wanneer weergegeven R. De verzameling van alle prototypes van een element B V A wanneer weergegeven R genaamd een compleet prototype dit element erin A.

De weergave kan worden gespecificeerd door een tabel bestaande uit twee rijen. De elementen worden op de bovenste regel geschreven A A, en daaronder staan ​​de prototypes uit de set die overeenkomen met de genoemde elementen IN. Bijvoorbeeld tafel

definieert een mapping van de set (1, 2, 3, 4) naar de set (2, 5, 1, 4). Tegelijkertijd 1 R = 2, 2R = 5, 3R=1, 4R = 4.

Laten R- weergave A V IN, Q- weergave IN V MET. Vermenigvuldiging in kaart brengen PQ zal een kaart zijn A V MET, en voor iedereen X?A eerlijk X(PQ) = (xP)Q. Inderdaad, laat X(PQ)=C. Dan voor sommigen bij IN wij hebben xRu En yQc, waar xP = bij en daarom Met = (xP)Q. Terug, van ( xP)Q zou moeten X(PQ).

We zullen de vermenigvuldiging van toewijzingen gespecificeerd door tabellen laten zien aan de hand van een voorbeeld:

Weergave R genaamd surjectief (surjectie) of een set weergeven A voor velen IN, wanneer elk element B?IN heeft minstens één prototype van A.

Voorbeeld 2.6. Laten A En IN- sets van reële getallen. In kaart brengen (surjectief) A op IN kan een functie zijn die wordt gedefinieerd door de formule X→ Z X+ 5, d.w.z. X gaat in j = 3X + 5.

Functie X→bij=X 2 definieert de ingestelde weergave A V B, wat niet surjectief is, aangezien negatieve getallen uit IN zijn geen afbeeldingen van elementen uit A.

Weergave R sets A in de menigte IN wordt één-op-één genoemd als de omgekeerde relatie bestaat R- Ik ben een mapping IN V A. Voor een één-op-één mapping gedefinieerd met behulp van secties is het noodzakelijk en voldoende dat elk element van IN verscheen slechts één keer in de onderste rij van de tabel. De drie tabellen die eerder zijn gegeven als voorbeeld van vermenigvuldiging van mappings komen dus overeen met één-op-één mappings.

Een één-op-één mapping waarvoor R overal gedefinieerd, genoemd injectief (injectie).

Voorbeeld 2.7. Laten A- set van reële getallen, IN- de reeks positieve reële getallen. Weergave X→bij = ex is één op één, aangezien elk bij komt overeen X= loggen j. We hebben dus een injectieve mapping, waarvan het omgekeerde de mapping is bij→X=ln j.

Eén-op-één mapping R tussen elementen van één set, waarvoor R En R- Ik word overal gedefinieerd, gebeld zelf-referentieel of bijectieve mapping. Een bijectieve afbeelding is zowel surjectief als injectief.

Wanneer we een bepaalde set in zichzelf in kaart brengen, zeggen we dat de mapping aRb vertaalt punt A tot het punt B. Wanneer aRa punt a wordt aangeroepen vast punt weergave R. Als alle punten van de set A bewegingsloos zijn tijdens het in kaart brengen, wordt de mapping aangeroepen identiek en aanduiden E A. Dat is duidelijk E -1 =E en voor elke weergave R RE=ER = R. Wanneer u een toewijzing aan zichzelf specificeert met behulp van secties, zal de onderste rij van de tabel dezelfde elementen bevatten als de bovenste rij (mogelijk in een andere volgorde), en elk daarvan verschijnt slechts één keer:

De aangrenzende matrix die overeenkomt met de afbeelding op zichzelf is vierkant:

R

De grafische weergave van een afbeelding op zichzelf bestaat uit cycli (eindig of oneindig).