De belangrijkste concepten van de entiteit-relatiemethode zijn de volgende:

Essence,

Entiteitskenmerk

Entiteitssleutel

Relatie tussen entiteiten

Mate van verbinding

De lidmaatschapsklasse van entiteitsinstanties,

Diagrammen van ER-instanties,

ER-type diagrammen.

Essence is een object, waarover informatie in de database is opgeslagen. Entiteitsinstanties verschillen van elkaar en zijn uniek geïdentificeerd. De namen van entiteiten zijn in de regel: zelfstandige naamwoorden, bijvoorbeeld: LERAAR, DISCIPLINE, AFDELING, GROEP.

Attribuut vertegenwoordigt een eigenschap van een entiteit. Dit concept is vergelijkbaar met het concept van een attribuut in een relatie. De attributen van de entiteit LERAAR kunnen dus zijn achternaam, functie, ervaring (lesgeven), enz. zijn.

Entiteitssleutel- een attribuut of een reeks attributen die worden gebruikt om een ​​exemplaar van een entiteit te identificeren. Zoals uit de definitie blijkt, is het concept van een entiteitssleutel vergelijkbaar met het concept van een relatiesleutel.

Relatie tussen twee of meer entiteiten - impliceert een afhankelijkheid tussen de attributen van deze entiteiten. Meestal wordt de naam van de verbinding weergegeven werkwoord. Voorbeelden van relaties tussen entiteiten zijn de volgende: LERAAR LEIDING DISCIPLINE (Ivanov LEIDT “Databases”), LERAAR LERAAR-B GROEP (Ivanov doceert - IN GROEP 256), LERAAR WERKEN-AAN AFDELING (Ivanov WERKT BIJ Afdeling 25).

De gegeven definities van essentie en verbinding zijn niet volledig geformaliseerd, maar zijn acceptabel voor de praktijk. Houd er rekening mee dat als resultaat van het ontwerp verschillende versies van één database kunnen worden verkregen. Dus twee verschillende ontwerpers, die hetzelfde probleem overwegen verschillende punten weergave, kan verschillende sets entiteiten en relaties ontvangen. Beide opties kunnen echter werken, en het kiezen van de beste zal een gevolg zijn van persoonlijke voorkeur.

Om de duidelijkheid en het ontwerpgemak te vergroten, worden de volgende grafische hulpmiddelen gebruikt om entiteiten, instanties van entiteiten en relaties daartussen weer te geven:

ER-instantiediagrammen,

ER-muna-diagrammen, of ER-diagrammen.

In afb. Figuur 1 toont een diagram van ER-instanties voor de entiteiten TEACHER en DISCIPLINE met een verbinding LEIDING.

Figuur 1 - Diagram van ER-instanties

Het ER-instancediagram laat zien welke specifieke discipline (DBMS, PL/1, etc.) door elke docent wordt onderwezen. Figuur 2 toont een ER-typediagram dat overeenkomt met het beschouwde ER-instantiediagram.

Figuur 2 - ER-type diagram

In de beginfase van het databaseontwerp worden de attributen waaruit de entiteitssleutels bestaan ​​geïdentificeerd.

Op basis van de analyse van ER-type diagrammen worden de relaties van de ontworpen database gevormd. Hiermee wordt rekening gehouden mate van verbinding tussen entiteiten En hun klasse van behoren, die op hun beurt worden bepaald op basis van de analyse van ER-instantiediagrammen van de overeenkomstige entiteiten.

Mate van verbinding is een kenmerk van de relatie tussen entiteiten, die van het type kan zijn: 1:1, 1:M, M:1, M:M.

De lidmaatschapsklasse (CP) van een entiteit kan zijn: verplicht En optioneel.

De lidmaatschapsklasse van een entiteit is verplicht als alle exemplaren van deze entiteit noodzakelijkerwijs betrokken zijn bij de relatie in kwestie, anders is de lidmaatschapsklasse van de entiteit dat wel optioneel.

Door de lidmaatschapsklasse van entiteiten voor elk van de genoemde verbindingstypen te variëren, kunt u verschillende opties verkrijgen voor diagrammen van het ER-type. Laten we voorbeelden van enkele daarvan bekijken.

Voorbeeld 1. 1:1-relaties en optionele lidmaatschapsklasse.

In de getoonde figuur. 1 in het diagram is de mate van verbinding tussen entiteiten 1:1 en is de lidmaatschapsklasse van beide entiteiten optioneel. De figuur laat inderdaad het volgende zien:

Elke docent onderwijst maximaal één discipline, en elke discipline wordt door maximaal één docent onderwezen (graad van aansluiting 1:1);

Sommige leraren onderwijzen in geen enkele discipline, en er zijn disciplines die door geen van de leraren worden onderwezen (de lidmaatschapsklasse van beide entiteiten is optioneel).

Voorbeeld 2. 1:1-type relaties en verplichte lidmaatschapsklasse.

In afb. Figuur 3 toont diagrammen waarin de mate van verbinding tussen entiteiten 1:1 is en de lidmaatschapsklasse van beide entiteiten verplicht is.

In dit geval geeft elke leraar les in één discipline en wordt elke discipline gegeven door één leraar.

Figuur 3 - Diagrammen voor 1:1-communicatie en verplichte CP van beide entiteiten

Er zijn twee tussenliggende opties met een optionele lidmaatschapsklasse van een van de entiteiten. Opmerkingen.

Op ER-type diagrammen verplicht deelname aan de verbinding van instanties van een entiteit wordt gemarkeerd door een blok met een stip erin, grenzend aan het blok van deze entiteit (Fig. 6.3b).

Bij optioneel deelname van entiteitsinstanties aan communicatie extra blok het entiteitsblok is niet bevestigd, maar het punt wordt op de communicatielijn geplaatst (Fig. 6.2).

Symbolen op de communicatielijn geven de mate van communicatie aan.

Onder elk blok dat met een bepaalde entiteit correspondeert, wordt de sleutel ervan aangegeven, gemarkeerd door onderstreping. Een weglatingsteken achter sleutelattributen betekent dat andere attributen van een entiteit mogelijk zijn, maar geen van deze kan deel uitmaken van de sleutel ervan. Deze attributen worden geïdentificeerd nadat de relatie is gevormd.

In de praktijk wordt de mate van verbinding en klasse van entiteiten bij het ontwerpen van een database bepaald door de specifieke kenmerken vakgebied. Laten we voorbeelden bekijken van opties met een verbindingsgraad van 1:M of M:1.

Voorbeeld 3. Type 1:M-aansluitingen.

Elke docent kan meerdere disciplines onderwijzen, maar elke discipline wordt door één docent gegeven.

Voorbeeld 4. M-type aansluitingen: 1.

Elke docent kan één discipline onderwijzen, maar elke discipline kan door meerdere docenten worden gegeven.

Voorbeelden met een relatietype 1:M of M:1 kunnen een aantal opties hebben, die verschillen in de lidmaatschapsklasse van een of beide entiteiten. Laten we de verplichte lidmaatschapsklasse aanduiden met het symbool “O”, en de optionele met het symbool “H”, dan kunnen de opties voor een 1:M-type verbinding conventioneel worden weergegeven als: O-O, OH, N-O, N-N. Voor communicatietype M:1 zijn er ook 4 vergelijkbare opties.

Voorbeeld 5. Aansluitingen type 1:M optie N-O.

Elke leraar kan meerdere disciplines onderwijzen of geen enkele, maar elke discipline wordt door één leraar onderwezen (Fig. 4).

Naar analogie is het eenvoudig om diagrammen voor andere opties te maken.

Voorbeeld 6. M:M-type aansluitingen.

Elke docent kan meerdere disciplines onderwijzen, en elke discipline kan door meerdere docenten worden gegeven.

Net als bij andere soorten verbindingen zijn er voor een verbinding van het M:M-type 4 opties, die verschillen in de klasse van entiteiten die erbij horen.

Voorbeeld 7. Aansluitingen van het M:M-type en een variant van de O-N-lidmaatschapsklasse.

Laten we aannemen dat elke leraar minstens één discipline onderwijst, en dat een discipline door meer dan één leraar kan worden onderwezen. Er zijn ook disciplines waarin niemand lesgeeft; De diagrammen die met dit geval overeenkomen, worden getoond in Fig. 5.

Figuur 4 - Diagrammen voor communicatietype 1:M van de H-O-optie

Identificatie van entiteiten en verbindingen daartussen, evenals de vorming van ER-type diagrammen op basis daarvan, wordt uitgevoerd met behulp van beginfasen methode entiteit-relatie. Laten we eens kijken naar de fasen van de implementatie van de methode.

Figuur 5 - Diagrammen voor communicatietype M: M en optie O-H

Een voorbeeld van het ontwikkelen van een eenvoudig ER-model

Bij het ontwikkelen van ER-modellen is het noodzakelijk om de volgende informatie over het vakgebied te verkrijgen:

1. Lijst met domeinentiteiten.

2. Lijst met entiteitsattributen.

3. Beschrijving van de relaties tussen entiteiten.

ER-diagrammen zijn handig omdat het proces voor het identificeren van entiteiten, attributen en relaties iteratief is. Nadat u een eerste ruwe versie van de diagrammen heeft ontwikkeld, kunt u deze verfijnen door domeinexperts te interviewen. In dit geval zijn de documentatie waarin de resultaten van de gesprekken worden vastgelegd de ER-diagrammen zelf.

Taak:een ER-model ontwikkelen voor de AIS van een groothandelsbedrijf.

Belangrijkste fasen van het oplossen van het probleem

1. Het bestuderen van het vakgebied en de processen die daarin plaatsvinden- dit gebeurt in de regel door het interviewen van werknemers van het bedrijf, het lezen van documentatie, het bestuderen van bestelbonnen, facturen, enz.

Tijdens een gesprek met een salesmanager bleek bijvoorbeeld dat hij (de manager) van mening is dat het ontworpen AIS de volgende acties moet uitvoeren:

· Klantgegevens opslaan.

· Facturen afdrukken voor vrijgegeven goederen.

· Bewaken van de beschikbaarheid van goederen in het magazijn.

2. Definitie van entiteiten. Om dit te doen, is het noodzakelijk om alle zelfstandige naamwoorden te markeren in zinnen die de processen beschrijven die plaatsvinden in het vakgebied dat wordt bestudeerd. Dit zullen potentiële kandidaten zijn voor entiteiten en hun attributen. Laten we ze analyseren (we zullen onduidelijke termen markeren met een vraagteken):

· Koper- kandidaat-entiteit.

· Factuur- kandidaat-entiteit.

· Product- kandidaat-entiteit.

· (?) Magazijn- Hoeveel magazijnen heeft het bedrijf in het algemeen? Als er meerdere zijn, is het een kandidaat voor een nieuwe entiteit.

· (?) Beschikbaarheid van producten- dit is hoogstwaarschijnlijk een attribuut, maar een attribuut van welke entiteit?

3. Relaties tussen entiteiten definiëren. Voor het beschouwde voorbeeld ontstaat onmiddellijk een voor de hand liggend verband tussen de entiteiten: “ Kopers kan veel kopen Producten " En " Goederen kan aan velen verkocht worden Voor kopers " De eerste versie van het diagram ziet er als volgt uit:

Door aanvullende vragen te stellen aan de manager kwamen nieuwe gegevens aan het licht:

· het bedrijf beschikt over meerdere magazijnen en elk product kan: in meerdere magazijnen worden opgeslagen; vanuit elk magazijn worden verkocht;

· kopers kopen goederen en ontvangen facturen met gegevens over de hoeveelheid en prijs van de gekochte goederen;

· elke koper kan meerdere facturen ontvangen;

· elke factuur wordt opgemaakt voor één koper;

· elke factuur bevat minimaal één product (er zijn geen lege facturen);

· elk product kan op zijn beurt via meerdere facturen aan meerdere kopers worden verkocht;

· Elke factuur moet vanuit een specifiek magazijn worden uitgegeven, en veel facturen kunnen vanuit elk magazijn worden uitgegeven.

Rekening houdend met de nieuwe informatie zal het diagram er als volgt uitzien:

4. Entiteitsattributen definiëren. Tijdens een gesprek met werknemers van het bedrijf werden de volgende omstandigheden verduidelijkt:

· elke koper is een rechtspersoon en heeft een naam, adres en bankgegevens;

· elk product heeft een naam, een prijs en wordt ook gekenmerkt door meeteenheden;

Elke factuur heeft uniek nummer, datum van uitgifte, goederenlijst met hoeveelheden en prijzen, evenals het totaalbedrag van de factuur; de factuur wordt afgegeven vanuit een specifiek magazijn en aan een specifieke koper;

· Elk magazijn heeft zijn eigen naam.

Laten we alle zelfstandige naamwoorden die potentiële attributen zullen zijn, opnieuw opschrijven en analyseren:

· Juridische entiteit- omdat het bedrijf werkt alleen met rechtspersonen (werkt niet met individuen), dan heeft het geen zin om een ​​dergelijk attribuut te benadrukken.

· Naam van de koper- kenmerken van de koper.

· Adres- kenmerken van de koper.

· Bankgegevens- kenmerken van de koper.

· Productnaam- kenmerken van het product.

· (?) Productprijs- het lijkt erop dat dit een kenmerk van het product is. Verschilt dit kenmerk van de prijs op de factuur?

· Meeteenheid- kenmerken van het product.

· Factuurnummer- een uniek kenmerk van de factuur.

· Factuurdatum- kenmerken van de factuur.

· (?) Lijst met goederen op de factuur- een lijst kan geen attribuut zijn. Waarschijnlijk moet u deze lijst in een afzonderlijke entiteit opsplitsen.

· (?) - dit is een kenmerk, maar een kenmerk van wat? Dit is niet alleen een kenmerk van een “product”, maar van een “product op de factuur”.

· (?) Productprijs op de factuur- kenmerken van de goederen op de factuur. Maar de prijs van het product is hierboven al gezien: is dit hetzelfde?

· Factuurbedrag- kenmerken van de factuur. Dit kenmerk is niet onafhankelijk. Het bedrag van de factuur is gelijk aan de som van de kosten van alle goederen die op de factuur zijn vermeld.

· Naam magazijn- kenmerken van het magazijn.

Tijdens een aanvullend gesprek met de manager kon er duidelijkheid komen diverse concepten prijzen Het bleek dat elk product een bepaalde huidige prijs heeft. Dit is de prijs waartegen het product momenteel wordt verkocht. Uiteraard kan deze prijs in de loop van de tijd veranderen. De prijs van hetzelfde product op verschillende facturen die op verschillende tijdstippen worden uitgegeven, kan verschillend zijn. Zo is het twee prijzen- de prijs van de goederen op de factuur en de huidige prijs van de goederen.

Met het opkomende concept van “Lijst van goederen op de factuur” is alles vrij duidelijk. Entiteiten Factuur En Product zijn met elkaar verbonden door een relatie zoals veel-op-veel. Een dergelijke verbinding moet worden verdeeld in twee verbindingen van het type één-op-veel. Hiervoor is een extra entiteit nodig. Deze essentie zal de essentie zijn Lijst met goederen op de factuur . De verbinding met entiteiten Factuur En Product gekenmerkt door de volgende zinnen: “Elke factuur moet meerdere vermeldingen uit de goederenlijst op de factuur bevatten”, “Elke vermelding uit de goederenlijst op de factuur moet in precies één factuur voorkomen”, “Elk product kan in meerdere vermeldingen uit de goederenlijst op de factuur”, “Elke vermelding uit de goederenlijst op de factuur moet aan precies één product gekoppeld zijn.”

Kenmerken Aantal goederen op de factuur En Productprijs op de factuur zijn attributen van een entiteit Lijst met goederen op de factuur .

Laten we hetzelfde doen met de verbinding die entiteiten verbindt Magazijn En Product . Laten we een extra entiteit introduceren Product op voorraad . Het attribuut van deze entiteit zal zijn Hoeveelheid goederen op voorraad. Het product zal dus in elk magazijn worden vermeld en de hoeveelheid in elk magazijn zal anders zijn.

Als gevolg hiervan zal het ER-diagram de volgende vorm aannemen:

Gegevensmodellen

Het domeinmodel wordt bijgehouden in het computergeheugen met behulp van een DBMS. Hierdoor is het modelleringsresultaat niet alleen afhankelijk van het vakgebied, maar ook van het gebruikte DBMS Elk DBMS biedt zijn eigen hulpmiddelen voor het weergeven van het onderwerpgebied. Deze toolkit wordt meestal genoemd datamodel.

Het datamodel wordt gedefinieerd door drie componenten:

· aanvaardbare gegevensorganisatie;

· integriteitsbeperkingen (semantisch);

· reeks bewerkingen die zijn toegestaan ​​op gegevensmodelobjecten.

Acceptabele gegevensorganisatie bepaald door de verscheidenheid en het aantal soorten datamodelobjecten, beperkingen op de datastructuur.

Integriteitsbeperkingen worden ondersteund door middelen die in het datamodel worden geboden voor het uitdrukken van beperkingen op datawaarden en associaties die (beperkingen) de betrouwbare toestanden van de database karakteriseren.

Een aantal integriteitsbeperkingen worden ondersteund door het standaarddatamodel en zijn op iedereen van toepassing typische situaties, waarvan het optreden mogelijk is wanneer er wijzigingen in de database worden aangebracht. Als er bijvoorbeeld een hiërarchische relatie tot stand wordt gebracht tussen records van het type GROUP en STUDENT, zal het DBMS voorkomen dat informatie over een studentengroep wordt verwijderd als er ten minste één record over een student aan is gekoppeld.

Andere integriteitsbeperkingen kunnen expliciet worden gesteld en zijn ook van toepassing op veel vergelijkbare situaties of op de waarden van individuele velden. Stel bijvoorbeeld dat bij het definiëren van een record voor een veld de eigenschap van unieke waarden is ingesteld, dan zal het DBMS voorkomen dat er twee records in de database verschijnen met dezelfde waarde dit veld.

Veel operaties definieert de soorten verwerking die datamodelobjecten kunnen ondergaan. In de eerste plaats zijn dit gegevensophaalbewerkingen en bewerkingen die de status van de database wijzigen.

Datamodellen ondersteund door DBMS worden traditioneel onderverdeeld in: netwerk, hiërarchisch, relationeel(andere datamodellen zijn ook beschikbaar). Deze classificatie is voorwaardelijk, omdat elk DBMS ondersteunt zijn eigen DBMS origineel model gegevens. En zelfs als het datamodel tot een van de geselecteerde varianten behoort, kan het behoorlijk wat onderscheidende kenmerken bevatten. De meest voorkomende modellen zijn relationele datamodellen(RMD).

Bij het daadwerkelijke ontwerp van de databasestructuur wordt een methode gebruikt: de zogenaamde semantische modellering. Semantische modellering is het modelleren van de datastructuur op basis van de betekenis van die gegevens. Gebruikt als hulpmiddel voor semantische modellering verschillende opties entiteit-relatiediagrammen(ER - Entiteitsrelatie).

De eerste versie van het entiteit-relatiemodel werd in 1976 voorgesteld door Peter Ping-Sheng Chen. Vervolgens ontwikkelden veel auteurs hun eigen versies van vergelijkbare modellen (Martin-notatie, IDEF1X-notatie, Barker-notatie, enz.). Bovendien kunnen verschillende softwaretools die dezelfde notatie implementeren, qua mogelijkheden verschillen. In feite zijn alle varianten van entiteit-relatiediagrammen gebaseerd op hetzelfde idee: een tekening is altijd duidelijker dan een tekstbeschrijving. Al dergelijke diagrammen gebruiken een grafische weergave van domeinentiteiten, hun eigenschappen (attributen) en relaties tussen entiteiten.

We zullen het werken met ER-diagrammen die dicht bij de notatie van Barker liggen beschrijven als vrij eenvoudig om de basisideeën te begrijpen. Dit hoofdstuk is meer een illustratie van semantische modelleringstechnieken dan een volledige introductie in het vakgebied.

Basisconcepten van ER-diagrammen

Definitie 1: Essence is een klasse objecten van hetzelfde type, waarvan informatie in het model in aanmerking moet worden genomen.
Elke entiteit moet een naam hebben die wordt uitgedrukt door een enkelvoudig zelfstandig naamwoord. Voorbeelden van entiteiten kunnen objectklassen zijn als "Leverancier", "Werknemer", "Factuur". Elke entiteit in het model wordt weergegeven als een rechthoek met een naam:

Rijst. 1

Definitie 2: Entiteitsinstantie is een specifieke vertegenwoordiger van een bepaalde entiteit.
Een vertegenwoordiger van de entiteit “Werknemer” kan bijvoorbeeld “Werknemer Ivanov” zijn. Entiteitsinstanties moeten onderscheidbaar zijn, d.w.z. entiteiten moeten een aantal eigenschappen hebben die uniek zijn voor elk exemplaar van die entiteit.

Definitie 3: Entiteitskenmerk is een benoemd kenmerk dat een eigenschap is van een entiteit.
De naam van het attribuut moet worden uitgedrukt als een enkelvoudig zelfstandig naamwoord (eventueel met kenmerkende bijvoeglijke naamwoorden). Voorbeelden van attributen van de entiteit 'Werknemer' zijn onder meer attributen zoals ' Personeelsnummer", "Achternaam", "Voornaam", "Patroniem", "Functie", "Salaris", etc. Attributen worden weergegeven in een rechthoek die de entiteit definieert:

Rijst. 2

Definitie 4: Entiteitssleutel is een niet-redundante set attributen, waarvan de waarden samen uniek zijn voor elk exemplaar van de entiteit. Niet-redundantie betekent dat het verwijderen van een attribuut uit een sleutel de uniciteit ervan verbreekt. Een entiteit kan er meerdere hebben verschillende sleutels. De belangrijkste kenmerken worden onderstreept weergegeven in het diagram:

Rijst. 3

Definitie 5: Verbinding- dit is een associatie tussen twee entiteiten. Eén entiteit kan verbonden zijn met een andere entiteit of met zichzelf.
Relaties zorgen ervoor dat een entiteit andere entiteiten kan vinden die ermee verband houden. Verbindingen tussen entiteiten kunnen bijvoorbeeld worden uitgedrukt door de volgende zinsneden: “Een WERKNEMER kan meerdere KINDEREN hebben”, “Elke WERKNEMER moet op precies één AFDELING zijn ingeschreven”. Grafisch wordt de relatie weergegeven door een lijn die twee entiteiten verbindt:

Rijst. 4

Elke link heeft twee uiteinden en een of twee namen. De naam wordt meestal uitgedrukt in een onbepaalde verbale vorm: “hebben”, “erbij horen”, enz. Elke naam verwijst naar het eigen uiteinde van de verbinding. Soms worden namen niet geschreven omdat ze voor de hand liggen.

Elke link kan een van de volgende hebben soorten communicatie:

Rijst. 5

Communicatietype één-op-één betekent dat één exemplaar van de eerste entiteit (links) is gekoppeld aan één exemplaar van de tweede entiteit (rechts). Een één-op-één-relatie geeft meestal aan dat we eigenlijk maar één entiteit hebben, die ten onrechte in tweeën is verdeeld.

Communicatietype één-op-veel betekent dat één exemplaar van de eerste entiteit (links) is gekoppeld aan verschillende exemplaren van de tweede entiteit (rechts). Dit is de meest gebruikte vorm van communicatie. De linker entiteit (aan de "één" kant) wordt aangeroepen ouderlijk, rechts (vanaf de “veel”-kant) - dochteronderneming. Een typisch voorbeeld van een dergelijke verbinding wordt getoond in Fig. 4.

Communicatietype veel-op-veel betekent dat elk exemplaar van de eerste entiteit kan worden geassocieerd met meerdere exemplaren van de tweede entiteit, en dat elk exemplaar van de tweede entiteit kan worden geassocieerd met meerdere exemplaren van de eerste entiteit. Het veel-op-veel-relatietype is een tijdelijk relatietype dat acceptabel is tijdens de vroege stadia van modelontwikkeling. In de toekomst moet dit type relatie worden vervangen door twee één-op-veel-relaties door een tussenliggende entiteit te creëren.

Elke verbinding kan een of twee hebben communicatiemodaliteiten:

Rijst. 6

Modaliteit" Misschien"betekent dat een exemplaar van de ene entiteit kan worden geassocieerd met een of meer exemplaren van een andere entiteit, of niet kan worden geassocieerd met een exemplaar.
Modaliteit" moeten"betekent dat een exemplaar van de ene entiteit moet worden gekoppeld aan ten minste één exemplaar van een andere entiteit.
De verbinding kan aan verschillende uiteinden verschillende modaliteiten hebben (zoals in figuur 4). Met de beschreven grafische syntaxis kunt u diagrammen ondubbelzinnig lezen met behulp van de volgende zinsstructuur:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>

Elke link kan van links naar rechts of van rechts naar links worden gelezen. Aansluiting in afb. 4 leest als volgt:

Van links naar rechts: "elke werknemer kan meerdere kinderen hebben."
Van rechts naar links: “Elk kind moet tot precies één medewerker behoren.”

Een voorbeeld van het ontwikkelen van een eenvoudig ER-model

Bij het ontwikkelen van ER-modellen moeten we de volgende informatie over het vakgebied verkrijgen:

1. Lijst met domeinentiteiten.
2. Lijst met entiteitskenmerken.
3. Beschrijving van de relaties tussen entiteiten.

ER-diagrammen zijn handig omdat het proces voor het identificeren van entiteiten, attributen en relaties iteratief is. Nadat we de eerste benaderende versie van de diagrammen hebben ontwikkeld, verfijnen we deze door vakdeskundigen te interviewen. In dit geval zijn de documentatie waarin de resultaten van de gesprekken worden vastgelegd de ER-diagrammen zelf.

Laten we aannemen dat we voor de taak staan ​​om een ​​informatiesysteem te ontwikkelen voor een bepaald groothandelsbedrijf. Allereerst moeten we het vakgebied en de processen die daarin plaatsvinden bestuderen. Om dit te doen, interviewen we werknemers van het bedrijf, lezen we documentatie, bestuderen we bestelformulieren, facturen, enz.

Tijdens een gesprek met een salesmanager bleek bijvoorbeeld dat hij (de manager) van mening is dat het systeem dat wordt ontworpen de volgende acties moet uitvoeren:

• Klantgegevens opslaan.
• Facturen afdrukken voor vrijgegeven goederen.
• Bewaken van de beschikbaarheid van goederen in het magazijn.

Laten we alle zelfstandige naamwoorden in deze zinnen selecteren - dit zijn potentiële kandidaten voor entiteiten en attributen, en deze analyseren (we zullen onduidelijke termen markeren met een vraagteken):

• De koper is een duidelijke kandidaat voor de entiteit.
• De factuur is een duidelijke kandidaat voor een entiteit.
• Product is een duidelijke kandidaat voor entiteit
• (?)Magazijn - hoeveel magazijnen heeft het bedrijf in het algemeen? Als er meerdere zijn, is het een kandidaat voor een nieuwe entiteit.
• (?) Beschikbaarheid van een product is hoogstwaarschijnlijk een attribuut, maar een attribuut van welke entiteit?

Er ontstaat onmiddellijk een voor de hand liggend verband tussen de entiteiten: ‘kopers kunnen veel goederen kopen’ en ‘goederen kunnen aan veel kopers worden verkocht’. De eerste versie van het diagram ziet er als volgt uit:

Rijst. 7

Nadat we aanvullende vragen hadden gesteld aan de manager, kwamen we erachter dat het bedrijf meerdere magazijnen heeft. Bovendien kan elk product in meerdere magazijnen worden opgeslagen en vanuit elk magazijn worden verkocht.

Waar moet ik de entiteiten “Factuur” en “Magazijn” plaatsen en waar moet ik deze aan koppelen? Laten we ons de vraag stellen: hoe verhouden deze entiteiten zich tot elkaar en tot de entiteiten “Koper” en “Product”? Kopers kopen goederen en ontvangen facturen met gegevens over de hoeveelheid en prijs van de gekochte goederen. Elke koper kan meerdere facturen ontvangen. Elke factuur moet aan één koper worden uitgereikt. Elke factuur moet meerdere goederen bevatten (er zijn geen lege facturen). Elk product kan op zijn beurt via verschillende facturen aan meerdere kopers worden verkocht. Bovendien moet elke factuur vanuit een specifiek magazijn worden uitgegeven en kunnen veel facturen vanuit elk magazijn worden uitgegeven. Na verduidelijking ziet het diagram er dus als volgt uit:

Rijst. 8

Het is tijd om na te denken over entiteitsattributen. Toen we met medewerkers van het bedrijf spraken, kwamen we het volgende te weten:

• Elke koper is een rechtspersoon en heeft een naam, adres en bankgegevens.
• Elk product heeft een naam, prijs en wordt ook gekenmerkt door meeteenheden.
• Elke factuur heeft een uniek nummer, de datum van uitgifte, een goederenlijst met hoeveelheden en prijzen, evenals het totaalbedrag van de factuur. De factuur wordt verzonden vanuit een specifiek magazijn en naar een specifieke koper.
• Elk magazijn heeft zijn eigen naam.
• Laten we alle zelfstandige naamwoorden die potentiële attributen zullen zijn, opnieuw opschrijven en analyseren:
• Juridische entiteit is een retorische term; wij werken niet met individuen. Wij letten niet op.
• De naam van de koper is een duidelijk kenmerk van de koper.
• Het adres is een duidelijk kenmerk van de koper.
• Bankgegevens zijn een duidelijk kenmerk van de koper.
• De naam van het product is een duidelijk kenmerk van het product.
• (?) De prijs van het product - het lijkt erop dat dit een kenmerk van het product is. Verschilt dit kenmerk van de prijs op de factuur?
• Een meeteenheid is een duidelijk kenmerk van een product.
• Het factuurnummer is een duidelijk uniek kenmerk van de factuur.
• De factuurdatum is een duidelijk kenmerk van de factuur.
• (?) Lijst met goederen op de factuur - de lijst kan geen attribuut zijn. Waarschijnlijk moet u deze lijst in een afzonderlijke entiteit opsplitsen.
• (?) De hoeveelheid goederen op de factuur is een voor de hand liggend kenmerk, maar een kenmerk van wat? Dit is niet alleen een kenmerk van een “product”, maar van een “product op de factuur”.
• (?) De prijs van het product op de factuur - nogmaals, dit moet niet alleen een kenmerk van het product zijn, maar een kenmerk van het product op de factuur. Maar de prijs van het product is hierboven al gezien: is dit hetzelfde?
• Het factuurbedrag is een expliciet kenmerk van de factuur. Dit kenmerk is niet onafhankelijk. Het bedrag van de factuur is gelijk aan de som van de kosten van alle goederen die op de factuur zijn vermeld.
• De naam van het magazijn is een duidelijk kenmerk van het magazijn.

Tijdens een aanvullend gesprek met de manager was het mogelijk om verschillende prijsconcepten te verduidelijken. Het bleek dat elk product een bepaalde huidige prijs heeft. Dit is de prijs waartegen het product momenteel wordt verkocht. Uiteraard kan deze prijs in de loop van de tijd veranderen. De prijs van hetzelfde product op verschillende facturen die op verschillende tijdstippen worden uitgegeven, kan verschillend zijn. Er zijn dus twee prijzen: de prijs van de goederen op de factuur en de huidige prijs van de goederen.

Met het opkomende concept van “Lijst van goederen op de factuur” is alles vrij duidelijk. De entiteiten "Factuur" en "Product" zijn aan elkaar gerelateerd door een veel-op-veel-relatie. Een dergelijke relatie moet, zoals we eerder hebben opgemerkt, worden opgesplitst in twee één-op-veel-relaties. Hiervoor is een extra entiteit nodig. Deze entiteit is de entiteit 'Lijst met goederen op de factuur'. De verbinding met de entiteiten "Factuur" en "Product" wordt gekenmerkt door de volgende zinnen - "elke factuur moet verschillende vermeldingen uit de lijst met goederen op de factuur bevatten", "elke vermelding uit de lijst met goederen op de factuur moet worden opgenomen in precies één factuur”, “elk product kan worden opgenomen in verschillende vermeldingen uit de goederenlijst op de factuur”, “elke vermelding uit de goederenlijst op de factuur moet aan precies één product zijn gekoppeld.” De attributen "Aantal goederen op de factuur" en "Prijs van de goederen op de factuur" zijn attributen van de entiteit "Lijst van goederen op de factuur".

We zullen hetzelfde doen met de verbinding die de entiteiten “Magazijn” en “Product” verbindt. Laten we een extra entiteit introduceren: 'Artikel in magazijn'. Het kenmerk van deze entiteit is 'Aantal goederen op voorraad'. Het product zal dus in elk magazijn worden vermeld en de hoeveelheid in elk magazijn zal anders zijn.

Nu kun je dit allemaal in een diagram zetten:

Rijst. 9

Conceptuele en fysieke ER-modellen

Het hierboven ontwikkelde voorbeeld-ER-diagram is een voorbeeld conceptdiagram. Dit betekent dat het diagram geen rekening houdt met de kenmerken van een bepaald DBMS. Vanuit dit conceptuele diagram kunt u construeren fysiek diagram, waarin al rekening wordt gehouden met kenmerken van het DBMS zoals toegestane typen en namen van velden en tabellen, integriteitsbeperkingen, enz. Fysieke versie van het diagram getoond in Fig. 9 zou er bijvoorbeeld zo uit kunnen zien:

Rijst. 10

In dit diagram vertegenwoordigt elke entiteit een databasetabel, elk attribuut wordt een kolom van de overeenkomstige tabel. Houd er rekening mee dat in veel tabellen, bijvoorbeeld "CUST_DETAIL" en "PROD_IN_SKLAD", die overeenkomen met de entiteiten "Factuurlijstrecord" en "Artikel in magazijn", nieuwe kenmerken zijn verschenen die niet in conceptueel model- dit zijn de belangrijkste kenmerken van de bovenliggende tabellen, gemigreerd in onderliggende tabellen om relaties tussen tabellen te bieden met behulp van externe sleutels.

Het is gemakkelijk op te merken dat de resulterende tabellen onmiddellijk in 3NF staan.

Conclusies

Het echte middel voor datamodellering is niet de formele methode om relaties te normaliseren, maar de zogenaamde semantische modellering.

Er worden verschillende opties gebruikt als hulpmiddel voor semantische modellering entiteit-relatiediagrammen(ER - Entiteitsrelatie).

Met entiteit-relatiediagrammen kunt u visuele grafische notaties gebruiken om entiteiten en hun relaties te modelleren.

Onderscheiden conceptueel En fysiek ER-diagrammen. Conceptuele diagrammen houden geen rekening met de specifieke kenmerken van specifieke DBMS'en. Fysieke diagrammen zijn gebaseerd op conceptuele diagrammen en vertegenwoordigen een prototype van een specifieke database. Entiteiten gedefinieerd in een conceptueel diagram worden tabellen, attributen worden tabelkolommen (rekening houdend met de gegevenstypen en kolomnamen die zijn toegestaan ​​voor een bepaald DBMS), verbindingen worden geïmplementeerd door migratie sleutelkenmerken van bovenliggende entiteiten en het maken van externe sleutels.

Als entiteiten correct zijn gedefinieerd, staan ​​de resulterende tabellen onmiddellijk in 3NF. Het belangrijkste voordeel van de methode is dat het model wordt opgebouwd door opeenvolgende verfijningen van de initiële diagrammen.

Dit hoofdstuk, dat een illustratie is van ER-modelleringsmethoden, behandelt niet de complexere aspecten van het maken van diagrammen, zoals subtypen, rollen, exclusieve relaties, niet-overdraagbare relaties, het identificeren van relaties, enz.

Wat is ER-modellering?

Modellering van entiteitsrelaties(ER Modeling) is een grafische benadering van databaseontwerp. Het gebruikt Entiteit/Relatie om objecten uit de echte wereld weer te geven.

Een Entiteit is een ding of object in de echte wereld dat te onderscheiden is van de omringende omgeving. Elke medewerker van een organisatie is bijvoorbeeld een afzonderlijke entiteit. Hieronder volgen enkele van de belangrijkste kenmerken van entiteiten.

• Een entiteit heeft een reeks eigenschappen.
• Entiteitseigenschappen kunnen waarden hebben.

In deze tutorial leer je-

Laten we ons eerste voorbeeld nog eens bekijken. Een medewerker van een organisatie is een entiteit medewerker) bij Microsoft kan hij hebben attributen ( eigenschappen) zoals naam, leeftijd, gewicht, lengte, etc. Het is duidelijk dat zij waarden koesteren die voor hem relevant zijn.

Elk attribuut kan hebben Waarden. In de meeste gevallen heeft een enkel attribuut één waarde. Maar het is mogelijk dat er attributen zijn meerdere waarden Ook. De leeftijd van Peter heeft bijvoorbeeld één enkele waarde. Maar zijn eigenschap 'telefoonnummers' kan meerdere waarden hebben.

Entiteiten kunnen hebben relaties met elkaar. Laten we een eenvoudig voorbeeld bekijken. Stel dat elke Microsoft-programmeur een computer krijgt. Dat is duidelijk Peter's computer is ook een entiteit. Peter gebruikt die computer en dezelfde computer wordt door Peter gebruikt. Er is met andere woorden sprake van een onderlinge relatie tussen Peter en zijn computer.

In Modellering van entiteitsrelaties, we modelleren entiteiten, hun attributen en relaties tussen entiteiten.

Verbeterd entiteitsrelatiemodel (EER).

Enhanced Entity Relationship (EER) Model is een datamodel op hoog niveau dat uitbreidingen biedt op het origineel Entiteitsrelatie(ER)-model. EER Models ondersteunt meer detailsontwerp. EER Modeling is naar voren gekomen als een oplossing voor het modelleren van zeer complexe databases.

EER maakt gebruik van UML-notatie. UML is de afkorting voor Unified Modeling Language; het is een modelleringstaal voor algemene doeleinden die wordt gebruikt bij het ontwerpen van objectgeoriënteerde systemen. Entiteiten worden weergegeven als klassendiagrammen. Relaties worden weergegeven als associaties tussen entiteiten. Het onderstaande diagram illustreert een ER-diagram met de UML-notatie.

Waarom het ER-model gebruiken?

Nu denk je misschien: waarom zouden we ER-modellering gebruiken als we eenvoudigweg de database en al zijn objecten kunnen maken zonder ER-modellering? Een van de uitdagingen bij het ontwerpen van een database is het feit dat ontwerpers, ontwikkelaars en eindgebruikers de neiging hebben om gegevens en het gebruik ervan anders te bekijken. Als deze situatie niet wordt gecontroleerd, kunnen we uiteindelijk een databasesysteem produceren dat niet voldoet aan de eisen van de gebruikers.

Communicatiemiddelen die door alle belanghebbenden (zowel technische als niet-technische gebruikers) worden begrepen, zijn van cruciaal belang bij het produceren van databasesystemen die voldoen aan de eisen van de gebruikers. ER-modellen zijn voorbeelden van dergelijke tools.

ER-diagrammen verhogen ook de productiviteit van gebruikers, omdat ze eenvoudig kunnen worden vertaald in relationele tabellen.

Casestudy: ER-diagram voor videotheek "MyFlix".

Laten we nu gaan werken met het databasesysteem MyFlix Video Library om het concept van ER-diagrammen te helpen begrijpen. In de rest van deze tutorials zullen we deze database gebruiken voor alle praktische oefeningen

MyFlix is ​​een zakelijke entiteit die films verhuurt aan haar leden. MyFlix heeft zijn gegevens handmatig opgeslagen. Het management wil nu overstappen naar een DBMS

Laten we eens kijken naar de stappen om het EER-diagram voor deze database te ontwikkelen-

1. Identificeer de entiteiten en bepaal de relaties die ertussen bestaan.
2. Elke entiteit, attribuut en relatie moet passende namen hebben die ook door niet-technische mensen gemakkelijk kunnen worden begrepen.
3. Relaties mogen niet rechtstreeks met elkaar verbonden zijn. Relaties moeten entiteiten verbinden.
4. Elk attribuut in een gegeven entiteit moet een unieke naam hebben.

Entiteiten in de bibliotheek "MyFlix".

De entiteiten die in ons ER-diagram moeten worden opgenomen zijn;

• Leden- deze entiteit bewaart ledeninformatie.
• Films- deze entiteit bewaart informatie over films
• Categorieën- deze entiteit bevat informatie die films in verschillende categorieën plaatst, zoals 'Drama', 'Actie' en 'Epic' enz.
• Film verhuur- deze entiteit bewaart informatie over films die aan leden zijn verhuurd.
• Betalingen- deze entiteit bewaart informatie over de betalingen van leden.

Het definiëren van de relaties tussen entiteiten

Leden en films

Het volgende geldt met betrekking tot de interacties tussen de twee entiteiten.

• Een lid kan in een bepaalde periode een meer dan film huren.
• Een film kan in een bepaalde periode door meer dan één lid worden gehuurd.

Uit het bovenstaande scenario kunnen we zien dat de aard van de relatie veel-op-veel is. Relationele databases ondersteunen geen veel-op-veel-relaties. We moeten een knooppuntentiteit introduceren. Dit is de rol die de entiteit MovieRentals speelt. Het heeft een één-op-veel-relatie met de ledentabel en een andere één-op-veel-relatie met de filmtabel.

Films en categorieënentiteiten

Het volgende geldt voor films en categorieën.

• Een film kan slechts tot één categorie behoren, maar een categorie kan meer dan één film bevatten.

Hieruit kunnen we afleiden dat de aard van de relatie tussen de categorieën en de filmtabel één-op-veel is.

Leden en betalingsentiteiten

Het volgende geldt voor leden en betalingen

• Een lid kan slechts één account hebben, maar kan wel een aantal betalingen doen.

Hieruit kunnen we afleiden dat de aard van de relatie tussen leden en betaalentiteiten een-op-veel is.

Laten we nu een EER-model maken met MySQL Workbench

In de MySQL-werkbank, Klik op de knop "+".

Dubbelklik op de knop Diagram toevoegen om de werkruimte voor ER-diagrammen te openen.

Het volgende venster verschijnt

Laten we eens kijken naar de twee objecten waarmee we gaan werken.

De leden" entiteit heeft de volgende kenmerken

• Lidmaatschapsnummer
• Volledige namen
• Geslacht
• Geboortedatum
• Fysiek adres
• Postadres

Laten we nu de ledentabel maken

1.Sleep het tabelobject vanuit het gereedschapspaneel

2. Zet het neer in de werkruimte. Er verschijnt een entiteit met de naam tabel 1

3. Dubbelklik erop. Het onderstaande eigenschappenvenster verschijnt

1. Wijzig tabel 1 in Leden
2. Bewerk de standaard idtable1 naar lidmaatschapsnummer
3. Klik op de volgende regel om het volgende veld toe te voegen
4. Doe hetzelfde voor alle kenmerken die zijn geïdentificeerd in de ledenentiteit.

Uw eigenschappenvenster zou er nu zo uit moeten zien.

Herhaal de bovenstaande stappen voor alle geïdentificeerde entiteiten.

Uw diagramwerkruimte zou er nu uit moeten zien zoals hieronder weergegeven.

Laten we een relatie creëren tussen leden en filmverhuur

1. Selecteer de plaats relatie, waarbij ook bestaande kolommen worden gebruikt
2. Klik op lidmaatschapsnummer in de tabel Leden
3. Klik op referentie_nummer in de MovieRentals tabel

Herhaal bovenstaande stappen voor andere relaties. Uw ER-diagram zou er nu als volgt uit moeten zien:

Samenvatting

• ER-diagrammen spelen een zeer belangrijke rol in het databaseontwerpproces. Ze dienen als een niet-technisch communicatiemiddel voor technische en niet-technische mensen.
• Entiteiten vertegenwoordigen dingen uit de echte wereld; ze kunnen worden opgevat als een verkooporder of fysiek zoals een klant.
• Alle entiteiten moeten een unieke naam krijgen.
• Met ER-modellen kunnen databaseontwerpers ook de relaties tussen entiteiten identificeren en definiëren.

Het volledige ER-model is hieronder bijgevoegd. U kunt het eenvoudig importeren in MySQL Workbench

pedagogische wetenschappen

• Khusainova Guzaliya Yadkarovna, Kandidaat Wetenschappen, universitair hoofddocent, universitair hoofddocent
• Staatsuniversiteit van Basjkir

• ONTWERP
• DATABASES
• ER-DIAGRAM

In dit artikel wordt het maken van een ER-diagram besproken aan de hand van het voorbeeld van een kinderwinkel.

• Ontwikkeling van de applicatie “Verwijzing naar de programmeertaal Pascal” voor Android OS
• Werken met een database in Delphi aan de hand van het voorbeeld van een kinderwinkel
• Vergelijking van programmeertalen met behulp van het voorbeeld van array-sortering
• Vorming van motivatie onder schoolkinderen om deel te nemen aan lichamelijke opvoeding en sport

Een domeininformatiemodel is een beschrijving van een onderwerpdomein zonder verwijzing naar de software en hardware die in de toekomst zal worden gebruikt. Bevat achtergrondinformatie over het vakgebied. De stap van het creëren van een informatiemodel wordt informatieontwerp genoemd.

Het doel van informatiemodellering is het creëren van een nauwkeurige en volledige weergave van de echte wereld, die in de toekomst kan worden gebruikt als informatiebron voor het bouwen van een database.

De reeks taken van deze fase bestaat uit het identificeren van gemeenschappelijke kenmerken informatie objecten en verbindingen daartussen. De resultaten van informatieontwerp kunnen worden uitgedrukt als een informatie- of conceptueel model dat de structuur van de gegevens weergeeft. Om een ​​conceptueel model te bouwen, wordt de Entity-Relationship-modelleringsmethode of ER-diagram gebruikt.

Bij het ontwikkelen van een standaard organisatieschema werden de volgende personeelsleden geïdentificeerd, waaronder: directeur, beheerders, verkoopadviseurs, schoonmakers, chauffeurs. Bij het organiseren van een winkel belangrijke factor is een mobiel, gekwalificeerd personeelsbestand dat in staat is om het klantenserviceproces zo snel en efficiënt mogelijk te organiseren.

Het werk van een verkoopadviseur is een proces dat kan worden onderverdeeld in de volgende fasen:

• zoeken naar het juiste product;
• het opstellen van een goederenlijst;
• het toevoegen van informatie over klanten;

Informatieprocessen fasen worden weergegeven in tabelvorm (Tabel 1).

Tabel 1. Informatieprocessen van fasen

Na het bestuderen van het vakgebied en het analyseren van de structuur van het systeem, werden objecten geïdentificeerd. De lijst met entiteiten en relaties wordt weergegeven in de tabellen 2 en 3.

Tabel 2. Lijst met domeinentiteiten

Naam	Entiteitssleutel	Entiteitsattributen
Kinderwinkel	Winkelcode	Naam AchternaamEigenaar_naam Winkeladressen
Medewerkers	Medewerker_code	Functietitel AchternaamWerknemernaam Paspoortgegevens Geboortedatum Onderwijs Apparaatdatum Winkelcode
Leveranciers	Leverancierscode	Product_merk Leveringsdatum Hoeveelheid
Kopers	Koper_code	Achternaam Koper_naam Paspoortgegevens Vaste_klant
	Bestelcode	Achternaam Klantnaam Productnaam Hoeveelheid Besteldatum Bestelkosten Leveringscode
	Productcode	Naam Materiaal Op voorraad (stuks) Besteld/verwacht Afbeelding Hoeveelheid Leverancierscode Winkelcode

Tabel 3. Lijst met relaties tussen entiteiten

Op basis van de beschikbare gegevens wordt het mogelijk een ER-diagram te construeren dat nodig is voor het verdere ontwerp van het informatiesysteem (Fig. 1).

Figuur 1. ER-diagram.

De volgende ontwerpstap is het creëren van de logische structuur van de relationele database. Elk gegevensmodelinformatieobject wordt toegewezen aan een overeenkomstige relationele tabel. De structuur van een relationele tabel wordt bepaald door de vereiste samenstelling van de overeenkomstige tabel informatie-object, waarbij elke kolom (veld) overeenkomt met een van de objectdetails. De sleuteldetails van het object vormen een unieke sleutel van de relationele tabel. Voor elke kolom specificeert u het formaat en de grootte van de gegevens. Tabelrijen (records) komen overeen met objectinstanties en worden gegenereerd wanneer de tabel wordt geladen.

Relaties tussen objecten van het datamodel worden geïmplementeerd door dezelfde details: verbindingssleutels in de overeenkomstige tabellen. De join-sleutel is altijd de unieke sleutel van de hoofdtabel. Een sleutel in een subtabel maakt deel uit van een unieke sleutel daarin, of is een veld dat daar geen deel van uitmaakt primaire sleutel. De relatiesleutel in een ondergeschikte tabel wordt een externe sleutel genoemd. In Access kunt u een gegevensdiagram maken dat de logische structuur van uw database visueel weergeeft. De definitie van één-op-veel-relaties in dit schema moet consistent zijn met het geconstrueerde gegevensmodel. Het uiterlijk van het datadiagram valt vrijwel samen met de grafische weergave van het informatielogische model. Tabellen 4 en 5 tonen de structuren van de objecten “Producten” en “Werknemers”. Op dezelfde manier kunt u andere databasetabellen verkrijgen.

Tabel 4. Structuur van de tabel “Producten”.

Sleutelveld	Veldnaam
	Productcode
		Tekst
		Tekst
	Naam	Tekst
		Numeriek
	Materiaal	Tekst
	Op voorraad (stuks)	Tekst
	Besteld/verwacht	Tekst
	Afbeelding	OLE-objectveld
		Monetair
	Hoeveelheid	Numeriek
	Leverancierscode	Numeriek
		Numeriek
	Winkelcode	Numeriek

Tabel 5. Structuur van de tabel “Medewerkers”.

Sleutelveld	Veldnaam
	Medewerker_code
	Functietitel	Tekst
	Volledige naam van de werknemer	Tekst
	Paspoortgegevens	Numeriek
	Geboortedatum	Datum/tijd
		Tekst
	Onderwijs	Tekst
		Numeriek
	Foto	OLE-objectveld
	Datum van apparaat	Datum/tijd
		Tekst
		Tekst
	Winkelcode	Numeriek

Met behulp van de regels voor het vertalen van een ER-diagram naar een logisch diagram, kunt u het uiteindelijke diagram voltooien: een logisch gegevensdiagram (Fig. 2)

Figuur 2. Logisch diagram van de database.

Dit werk bespreekt dus in detail de productie van ER-diagrammen en logische diagrammen voor voorbeelden van een kinderwinkel.

Referenties

1. Ainurov K.I. Gebruik van informatietechnologie in het onderwijs. – Magnitogorsk: MGPU, 2014. – 85 p.
2. Viktorov S.U. Ontwikkeling van informatietechnologieën – Perm: LNA, 2011. – 74 p.
3. Khusainov I.G., Rakhimova R.A. De rol van interactieve technologieën in informaticalessen bij de ontwikkeling van ethisch onderwijs aan leerlingen // Hedendaagse vraagstukken wetenschap en onderwijs. – 2015. – Nr. 3. – Blz. 488.
4. Khusainova G.Ya. Studie van temperatuurvelden tijdens stationaire stroming van afwijkende vloeistoffen // Automatisering. Moderne technologieën. 2016. Nr. 7. blz. 13-16.