Entity Relation diagrams: standaard / protocol?

[Anoniem: 48505]

Ik ben bezig met het maken van Entity Relation Diagrammen.

Ik heb twee boeken: Leerboek databases van Kroenke en "An introduction into Database systems". Deze leggen allebei uit wat ERD's zijn, maar de ER-dagrammen zijn totaal verschillend .

Ook als ik op het web zoek, kom ik ook allemaal verschillende soorten symbolen en manieren tegen.

Bestaat er een standaard voor het maken van ERDS, zoals die voor UML bestaat? Het zou mij erg helpen.

Alvast bedankt!

Ps: ik heb de search van tweakers gebruikt, maar kan er niets over vinden

[whoami]

Hmmm... Een standaard.
Een ERD is dus gewoon een schema van het datamodel, alleen de notatie kan wel eens verschilen bij verschillende personen, maar meestal geraak ik er wel wijs uit...
Ik heb gemerkt dat het bijna enkel bij het aangeven van de cardinaliteit van een relatie is dat men verschillende notatie-wijzen heeft. (En eigenlijk vind ik het vrij duidelijk wat die notatie in de verschillende schrijfwijzes wil zeggen).

[Goodielover]

Een eigenlijk gaat het dan alleen om het aangeven van het optioneel/verplicht zijn van de relatie. Voor de many wordt eigenlijk wel door iedereen een harkje gebruikt.
Soms worden er extra constraint-notatie methoden uit andere modeleringstechnieken gebruikt om bijv wederzijds exclusiviteit van relaties aan te duiden.

Classe-relaties zoals die binnen OO bekend zijn, zijn ook slecht weer te geven met ERD's dus ook daarvoor bestaan dialecten.

[Anoniem: 48505]

Drie zoekresultaten van google, 3 verschillende manieren:
http://www.ics.uci.edu/~t...-MidtermReview/sld008.htm

http://www.popkin.com/cus..._99/images/erdiagram2.gif

http://www.cs.tku.edu.tw/en/source/TamKangU.talk.1.1.pdf

Vraagje:
-wat kan je het beste in vibertjes zetten, de cardinaliteit, of korte omschrijving? (termen als "heeft een", "is een")
- Hoe geven jullie aan, of een relatie verplicht is? Is dat goed als je dat doet door 1 of 0 te zetten bij het begin en eind van de associatie?

[Goodielover]

Als die vibertjes in het midden van een lijn zitten de omschrijving. Ik doe dat alleen als het iets anders is dan "heeft/is". Het is zelfs verplicht als je meerdere relationtypes tussen twee entitytypes hebt.
Verplicht gaf ik altijd aan met een horizontaal streepje boven de many en optioneel met een rondje. Maar dus aan de zelfde kant als de many of de 1.

dus harkje met horizontaal streepje erboven betekende "heeft 1 of meedere"
normaal lijnuiteinde met rondje betekende dus "nul of één"

[Anoniem: 48505]

Nog een ERD vraagje: wat kan ik beter doen, bij een veel op veel relatie: een veel op veel wibertje, of een entiteit (tussentabel) toevoegen?

Iedereen bedankt voor de hulp en handige tips

[ Voor 3% gewijzigd door Anoniem: 48505 op 08-01-2003 11:55 ]

[Bootje]

Anoniem: 48505 schreef op 08 januari 2003 @ 11:20:
Nog een ERD vraagje: wat kan ik beter doen, bij een veel op veel relatie: een veel op veel wibertje, of een tussentabel toevoegen?

Iedereen bedankt voor de hulp en handige tips

Volgens mij moet je bij zo een relatie altijd een tussentabel invoegen.

[kenneth]

Een tussentabel is op implementatieniveau. Die moet dus niet in een ERD staan.

[drm]

hoezo? Staat toch leuk, een tabel in een entiteit-relatie diagram?
</flauw>

[whoami]

mithalph schreef op 08 januari 2003 @ 11:27:
Een tussentabel is op implementatieniveau. Die moet dus niet in een ERD staan.

Idd. Als die tussentabel geen extra velden bevat (als de enige velden in de relatietabel dus de 2 keys uit de 2 tabellen zijn), moet die eigenlijk niet in het ERD staan.
Maar zelf zet ik ze er wel altijd in, wegens duidelijkheid.

[Anoniem: 62810]

Bij een veel op veel relatie in ERD komt er tussen beide entiteiten een wybertje en je kan desgewenst bij dat wybertje een atrribuutje (of meer) opnemen....

[Anoniem: 48505]

Anoniem: 62810 schreef op 08 januari 2003 @ 12:04:
Bij een veel op veel relatie in ERD komt er tussen beide entiteiten een wybertje en je kan desgewenst bij dat wybertje een atrribuutje (of meer) opnemen....

Zo kan het idd. Maar als je weer een relatie naar dat wybertje krijgt van een andere entiteit, wordt het snel onoverzichtelijk...

[Anoniem: 62810]

Die verschillende notaties van erdees komt doordat er in de loop der tijd veel dialecten van deze technieken zijn bijgekomen. veel inzichten die veranderd zijn en mensen die dachten dat iets beter en duidelijker kon....je zult dus veel notaties tegenkomen...aan jou om uit te kiezen welke je het meest fijn/duidelijk vindt

[Zoijar]

Zoek anders is Fundamentals of Database Systems (3rd Edition) op in de bieb. Wordt het goed in beschreven hoe je die diagrammen moet maken aan de hand van gegevens. En later worden ook nog standaard manieren besproken om (E)ER naar een relationeel model te mappen dat in xx normaal vorm staat.
In principe is het allemaal vrij recht toe recht aan, waar je het meest op moet letten zijn dingen als weak entity types, "inheritance" en 3 voudige relaties. Verder zou ik gewoon de notatie voor cardinaliteiten gebruiken die aan beide kanten een getal zet. En in elke diamond (zo heten ze echt ipv wiebertje zeg dan "ruit" hehe) zet je een omschrijving.

En wat is dat over tabellen? (E)ER kent geen tabellen In fact kent zelfs het relationele model geen tabellen. Je moet echt niet aan een fysieke database denken bij het maken van (E)ER diagrammen. Er zijn weer methoden om de diagrammen om te zetten naar een relationeel model, en dan weer om dat model om te zetten naar een database. Er zitten echt nog twee stappen tussen diagram en database.

Idd. Als die tussentabel geen extra velden bevat (als de enige velden in de relatietabel dus de 2 keys uit de 2 tabellen zijn), moet die eigenlijk niet in het ERD staan.
Maar zelf zet ik ze er wel altijd in, wegens duidelijkheid.

Dit snap ik niet, waarom zou het niet in je diagram moeten staan? Er is toch een relatie tussen twee entiteiten dan? Zelfs al is die relatie 1-1 moet het er alsnog in staan. Velden, tabellen Keys zijn wel iets in (E)ER

[Zoijar]

Oh misschien heb je hier wel iets aan: http://www.cs.vu.nl/~martinc/databases/databases.html

En dan de powerpoint sheets van....ik denk hoofdstuk 2-4 ofzoiets.

[Anoniem: 48505]

Dit snap ik niet, waarom zou het niet in je diagram moeten staan? Er is toch een relatie tussen twee entiteiten dan? Zelfs al is die relatie 1-1 moet het er alsnog in staan. Velden, tabellen Keys zijn wel iets in (E)ER

Hij bedoelt hier dat de tussentabel er niet als entiteit in moet stan, maar als diamond (wiebertje )

[Zoijar]

Anoniem: 48505 schreef op 08 januari 2003 @ 12:30:
[...]

Hij bedoelt hier dat de tussentabel er niet als entiteit in moet stan, maar als diamond (wiebertje )

Ahhh ok op die manier. Dan moet ie er dus idd niet in

[EfBe]

ER/D's zijn eigenlijk niet bedoeld om in te ontwerpen, want het zijn bijna 1:1 afbeeldingen van je fysieke datamodel in een RDBMS. Beter is een echte modelleringstechniek te gebruiken zoals ORM (www.orm.net) waarmee je ER/D's genereert maar dus op een abstract niveau bezig bent (en dus niet fysiek met tabellen, daar ER/D's 1:1 afbeeldingen zijn van o.a. de tabellen).

Zoals het ge-emmer met 'tussentabel/koppeltabel' etc. Dat zijn details die volgen uit een goed ORM model.

[whoami]

Zoijar schreef op 08 January 2003 @ 12:23:
[...]


Dit snap ik niet, waarom zou het niet in je diagram moeten staan? Er is toch een relatie tussen twee entiteiten dan? Zelfs al is die relatie 1-1 moet het er alsnog in staan. Velden, tabellen Keys zijn wel iets in (E)ER

Je geeft het dan gewoon weer in de relatie (dmv de cardinaliteit enzo).

[Goodielover]

EfBe schreef op 08 January 2003 @ 13:08:
ER/D's zijn eigenlijk niet bedoeld om in te ontwerpen, want het zijn bijna 1:1 afbeeldingen van je fysieke datamodel in een RDBMS. Beter is een echte modelleringstechniek te gebruiken zoals ORM (www.orm.net) waarmee je ER/D's genereert maar dus op een abstract niveau bezig bent (en dus niet fysiek met tabellen, daar ER/D's 1:1 afbeeldingen zijn van o.a. de tabellen).

Zoals het ge-emmer met 'tussentabel/koppeltabel' etc. Dat zijn details die volgen uit een goed ORM model.

Wat een onzin (in mijn ogen dan).

Natuurlijk gebruik je ERD's wel om te ontwerpen, ook op functioneel niveau.
Je kan ERD ook gebruiken om een weergave te doen van tabellen, maar daar is het zeker niet voor bedoeld.
Je mag gewoon een N:M relatie modelleren, ondaks dat je die nooit zo in een RDBMS krijgt. Bovendien zijn minimale cardinaliteit naar een many kant ook iets waar een RDBMS het moeilijk mee heeft.

Motto: gebruik het lekker om te modelleren. Het geeft een plaat om over te praten en aan iedereen duidelijk te maken wat je bedoelt