Diskussion:Entity-Relationship-Modell

message: === Begriff ERD fehlt (erledigt) ===
Ist ERM ein Synonym zu ERD (entity relationship diagram). ich finde den begriff ERD viel häufiger, aber in der wikipedia schcoeint es keinen einzigen(!) eintrag dazu zu geben. sollte man redirects von ERD zu ERM erstellen? -- Qopep 07:59, 7. Okt 2006 (CEST)
replies: text: ERD ist - wie der Name schon sagt - ein Diagramm, also ein unter Verwendung einer Notationsform zu Papier gebrachtes ERM. --Orcus 09:03, 12. Jul 2004 (CEST)
replies: text: Du hast Recht, wenn du es nur oberflächlich oder umgangssprachlich siehst. Aber ein Diagramm ist eben nur eine Darstellung, das Modell ist mehr, siehe oben. Aber: Dieses Kapitel ist längst erledigt. --VÖRBY (Diskussion) 17:29, 15. Nov. 2012 (CET)
thread_title:  Einleitungs-Abschnitt 

message: Ist ERM ein Synonym zu ERD (entity relationship diagram). ich finde den begriff ERD viel häufiger, aber in der wikipedia schcoeint es keinen einzigen(!) eintrag dazu zu geben. sollte man redirects von ERD zu ERM erstellen? -- Qopep 07:59, 7. Okt 2006 (CEST)
replies: text: ERD ist - wie der Name schon sagt - ein Diagramm, also ein unter Verwendung einer Notationsform zu Papier gebrachtes ERM. --Orcus 09:03, 12. Jul 2004 (CEST)
replies: text: Du hast Recht, wenn du es nur oberflächlich oder umgangssprachlich siehst. Aber ein Diagramm ist eben nur eine Darstellung, das Modell ist mehr, siehe oben. Aber: Dieses Kapitel ist längst erledigt. --VÖRBY (Diskussion) 17:29, 15. Nov. 2012 (CET)
thread_title:  Begriff ERD fehlt (erledigt) 

message: Ein anonymer Benutzer hat gerade folgenden Abschnitt entfernt:
: Als Grundlage dieses Werkes haben sich viele weitere Dialekte des ER-Modells gebildet, unter anderem das Extended Entity Relationshipmodel (EER) von Atzeni und Chen, das Entity-Category-Relationship-Modell (ECR) von Elmasri, das Strukturierte Entity-Relationship-Modell (SERM) von Sinz, das ER+ Model von Hull und King, das IDEFIX der US Air Force, sowie das Semantically Enriched Extended Entity Relationship Model (E3R-Modell) von Mario Jeckle.	
Wieso? Stimmt das nicht? könnte das jehmand überprüfen? -- D. Düsentrieb (?!) 13:29, 8. Sep 2004 (CEST)
replies: text: Ich habe den Abschnitt nicht entfernt, möchte aber den Hinweis geben, dass der Datenmodellierungsstandard IDEF1X heißt (eine eins vor dem X). Siehe www.idef.com --Michael R. 15:43, 23. Sep 2004 (CEST)

text: Habe IDEF1X erstellt und unter Notation verlinkt. Den IDEF http-Link habe ich dort bewusst nicht aufgenommen, da kommerziell und nicht Urheber des IDEF. --EFR 11:17, 31. Mär 2005 (CEST)
thread_title:  Geschichte 

message: Ich habe diese "Notation" entfernt, da es sich nicht um eine komplette Darstellungs-Notation von ER-Modellen handelt sondern um eine grafische Darstellung der Kardinalitäten. Dies sollte vielleicht unter der Chen-Notation eingefügt werden, da es mehrere Darstellungsformen von Kardinalitäten gibt. Dies sind die Numerische (0,1), die MC-Notation, die Krähenfuss-Notation und die Pfeil-Notation.
Ausserdem stellt SQL kein ERM dar, sondern sollte für die Implementation verwendet werden. Die SQL-Notation schliesst die Chen-Notation nicht aus.
: soweit ich weiß ist es möglich, ein ERM vollständig über SQL zu definieren, oder? Alle Entitäten, Relationen, Kardinalitäten etc lassen sich abbilden - somit ist SQL eine Notation. Dass diese zur Implementation benutzt wird, und die grafischen Notationen eher zum Entwurf, steht da ja schon. -- D. Düsentrieb (?!) 15:45, 15. Sep 2004 (CEST)
replies: text:  Mit Notation ist hier üblicherweise eine grafische Darstellungsform genannt. Deshalb gehört die Krähenfuss-Notation auf jeden Fall dazu! SQL ist eine Sprache zur Datenbankdefinition (create table...), zur Datenmanipulation (insert, update, delete, ...) und zur Abfrage (select...). Ich würde daher SQL nie im Zusammenhang mit konzeptuellen Datenmodellen sehen. Gruß --Michael R. 15:32, 23. Sep 2004 (CEST)
thread_title:  Krähenfuss-Notation 

message: hallo Oemmler,
Du hast Dich beim ER-Modell dem Teil  Praxiseinsatz gewidmet und dabei die  Modellierung der Relationships ergänzt.
Die derzeitige Version enthält folgendne Passus:
* Erkennen und Zusammenfassen von Beziehungen zwischen je zwei Objekten zu einem Relationship (z.B. der Angestellte Paul Lehmann leitet das Projekt Verbesserung des Betriebsklimas und der Angestellte Fritz Maier leitet das Projekt Effizienzsteigerung in der Verwaltung). Dies führt zu dem  Relationship "Mitarbeiter leitet Projekt". 
* Bestimmung der Kardinalitäten, d.h. der Häufigkeit des Auftretens (z.B. wird  ein Projekt immer von genau einem Angestellten geleitet und ein Angestellter  darf höchsten drei Projekte leiten.) 
* Erkennen und Zusammenfassen von Beziehungen und Zugehörigkeiten von  Einzelobjekten untereinander (z.B. im Rahmen der Erstellung einer Stückliste  beim Fertigen von Produkten).
Im obigen Text behndeln der erste und der dritte Abschnitt die gleiche Sache,
nämlich die Modellierung der Beziehungen; sei es die Beziehung "leitet", seien es (wie bei Stücklisten) die beiden Beziehungen "hat als Oberteil"" und "hat als Unterteil".
Daher schlage ich vor, daß wir den dritten Teil streichen.
Wenn wir die Stückliste auch in der Grafik hätten, dann könnten wir sie als Beispiel im ersten Teil auch mit dazunehmen.
Ich denke aber, daß gerade die Stücklisten mit ihren beiden Beziehungen nicht gerade einfach zu verstehen sind und daher nicht auftauchen sollten.
Wie siehst Du das?
Gruß Thomas tzeh 08:47, 26. Nov 2004 (CET)
thread_title:  Praxiseinsatz 

message: Gibt es einen speziellen Grund weshalb die Generalisierung nicht als Beziehungstyp genannt wird ? Die "is-A" Beziehung ist eine unverzichtbare Modellierungskomponente. Andreas75 13:28, 28. Mai 2005 (CEST)
thread_title:  Beziehungen 

message: Ich habe die Definition leicht geändert: Statt der „realen Welt“ wird lediglich ein „Ausschnitt der realen Welt“ modelliert. Die Modellierung ist in den meisten Fällen nicht „semantisch exakt“, als Beispiel möge die begrenzte Ausdruckskraft der Kardinalitäten dienen. --Thetawave 12:11, 2. Aug 2005 (CEST)
replies: text: Das ist schon ok. Vielleicht waere wenn ueberhaupt "formal exakt" das bessere Wort gewesen? -- sparti 13:14, 2. Aug 2005 (CEST)
replies: text: Ich habe über etwas im Stil von „in einem sauber definierten mathematischen Rahmen“ nachgedacht, fand dann aber den Einleitungssatz ohne jegliche Ergänzungen griffig und gut verständlich. Ich denke, der Verweis auf Datenmodell macht deutlich, dass es sich um ein formales semantisches Konzept handelt.  --Thetawave 14:36, 2. Aug 2005 (CEST)
thread_title:  Definition 

message: Die Begriffe Entity, Entitymenge, Entitytyp, Beziehung, Beziehungsmenge, Beziehungstyp werden leider hier nicht exakt auf den Punkt gebracht. Folgende Terminologie hat sich bewährt.
- Entity ist ein realer oder gedanklicher Gegenstand aus den zu modellierenden Anwendunsbereich
- Entittyp ist eine Menge von Merkmalen, sog Attributen, die eine Menge von Entities, die aus unserer Anwendungssemantik als gleichartig aufzufassen sind, gemeinsam haben.
Man beachte hier die klare Trennung zwischen Entitytyp (= Menge von Attributen) und der Entitymenge, die diese  Attribute gemeinsam haben
Außerdem ist es wichtig, zwischen einem Entity und der Repräsentation eines Entities in der ER-Modellvorstellung zu unterscheiden: 
- Jedes Entity wird in der Modellvorstellung repräsentiert durch den Satz von Werten, die es für die Attribute seines Entitytyps hat. Man nennt diesen Satz von Werten Entityrepräsentation.
Ebenso konsequent und präzise muss man Beziehunge, Beziehungsmengen, Beziehungstypen und Beziehungsrepräsentation umgehen.
Gruss mopc --Mopc 10:34, 6. Dez 2005 (CET)
replies: text: Hi mopc, das klingt plausibel. Bitte erweitere doch einfach den Artikel entsprechend. Wenn es Einwaende dagegen gibt, kann man sie jederzeit rueckgaengig machen. Gruss -- sparti 15:05, 6. Dez 2005 (CET)

text: Mich stören die Homonyme auch und ich fang mal an, den Artikel gerade zu ziehen. Gruß --EFR 15:26, 7. Apr 2006 (CEST)

text: Hat ein wenig gedauert, aber den Begriffsteil hab ich jetzt mal überarbeitet. Im Rest gibt's wahrscheinlich immer noch Unsauberkeiten. Im Abgleich mit dem Lemma Entität habe ich Entity eingedeutscht. Gruß --EFR 11:44, 15. Okt. 2006 (CEST)
thread_title:  Präzise Terminologie 

message: ERLEDIGT
Hallo ER-Community! Bin jetzt erst in dieses Thema eingedrungen und bin der Ansicht, dass die Typisierungs-Diskussionen in dem Artikel überbewertet bzw. sogar fehl am Platz sind.  
Begründung: Ein ERM ist ein 'Modell'. Als solches ist es (siehe Modell) ein 'Abbild der Wirklichkeit. Es zeigt somit in seinen Konstrukten 'Stellvertreter' für gleichartige Objekte / Gegebenheiten, zum Beispiel eine 'Entität' mit der Bezeichnung 'MITARBEITER' - wie gesagt als Stellvertreter für alle gleichartigen (MA). 
Das ist aber in jedem Modell so. Da ein ERM ein semantisches Modell ist, soll es nur die fachlich relevante Realität abbilden. Und hierzu gehören die Typ-Begriffe ganz klar nicht. Und die Begriffe 'Entität ...' sind vergleichbar mit den Begriffen 'Satz', 'Wort', 'Punkt', 'Komma' etc für jemanden, der einen beliebigen Text schreibt: Er kennt sie und wendet sie an, sie kommen aber in seinen Texten nicht vor.   
Fazit: Zwischen Typ und 'konkret' zu unterscheiden, ist zwar grundsätzlich korrekt. Im ER-Modell, und schon gar nicht im 'ERD' des semantischen Modells, sollte der Typ aber nicht erscheinen. Er kommt erst 'eine Ebene höher' Ins Spiel, wenn der Datenadministrator das fachlichen Modell (dies ist 'seine Welt') in sein Modell überführt.
Folglich würde ich die Typ-Ausprägungen gerne so beschreiben, dass diese für die weitere Bearbeitung in der Datenadministration von Bedeutung sind. Hinweis: Für 'Attribute' gibt es nur 1 Beschreibung; eigentlich müsste man auch den Attributetype nennen - oder von Eigenschaften (Entity) und von Attributen (Entitytype) sprechen.
Textlich müsste man da natürlich noch einiges umstellen. 
Anmerkung: In meiner eigenen Praxis habe ich (im Umgang mit fachlichen Mitarbeitern) die Typ-Ebene noch nie verwendet - und niemand hat sie vermisst. 
PS: Vergleichbar ist die Situation mit der Prozessmodellierung, wo grundsätzlich auch zwischen Typ und Instanz zu unterscheiden ist - was allerdings sprachlich (mit 'Prozess'; was ist das nun?) auch nur bedingt zum Ausdruck kommt.   
Was denkt Ihr? Feedeback von 'beiden Fraktionen' (Methodiker, Anwender) erbeten.
--VÖRBY 18:04, 15. Okt. 2010 (CEST)
thread_title:  Typ-Ebene im ERM? 

message: Ich wollte erst an dieser Stelle einiges zum Absatz Darstellungsformen und zu der Grafik dort schreiben, habs mir dann aber doch anders überlegt und den ganzen Absatz neu geschrieben. Die Diagramme waren zum größten Teil syntaktisch falsch und wo ich grad dabei war habe ich den Text hoffentlich auch etwas verbessert. Grundsätzlich finde ich diesen Artikel auch immer noch nicht so rund. Die Verständlichkeit wird in der Diskussion mMn zu Recht bemängelt. Außerdem wärs toll, wenn man die lustige Sammlung von Werkzeugen auslagern würde - ich denke da an eine eigene Liste, wo dann jeder seine Lieblingswerkzeuge reintun kann. Beste Grüße --EFR 17:11, 21. Mär 2006 (CET)
thread_title:  Absatz Darstellungsformen 

message: Ich habe den Absatz Erweiterungen entfernt, weil es erstens (zu) viele Erweiterungen des ER-Modells gibt, um sie einzeln aufzuführen und zweitens der dort formulierte Satz fachlich falsch war. Tatsächlich behandelt bereits Chen Existenzabhängigkeiten in seiner Veröffentlichung unter 3.3.1. --EFR 10:53, 23. Mär 2006 (CET)
thread_title:  Absatz Erweiterungen 

message: Hallo,
ich beschäftige mich zurzeit mit diesem Thema. Ich frage mich aber, mit welchem Programm so ein ER-Modell abgebildet wird und in zB Access übertragen wird. Es wird mit keinem Wort erwähnt.
Na ja, zumindest gibt es unter "Siehe auch" die Datenmodelierungsliste, die ich erweitert habe mit SiSy
Ich würde mich freuen, wenn ihr, die ein bisschen Ahnung davon haben, den Artikel von SiSy bearbeitet. Es gibt ne ganze Menge noch die fehlt und vielleicht gibt es einige Sachen, die falsch sind.
--Magigstar 11:44, 14. Okt. 2006 (CEST)
thread_title:  Welche Programme werden genutzt??? 

message: In dem Artikel wechseln sich ständig "Relationship" und "Beziehung" ab, scheinbar wahllos. (Bestes Beispiel: Überschriften) Man sollte sich auf eine Bezeichnung einigen. Ich würde letzteres bevorzugen, da "Relationship" wirklich kein Fachbegriff ist, den man ins Deutsche übersetzt nicht verstehen würde. Wer ist anderer Meinung? --Der fette Mo 22:34, 13. Dez. 2006 (CET)
replies: text: Bin für Beziehung und Beziehungstyp. --EFR 10:03, 14. Dez. 2006 (CET)
thread_title:  Überarbeiten 13.12.2006 

message: Die Aussage "Ein Ort kann ein Geburtsort sein, muss es aber nicht sein." stimmt nicht mit "Bis auf das Chen-Diagramm..." überein, da die n in Chen-Notation im Sinne von 0..∞ zu verstehen ist. Ich korrigiere das (ebenso die "konkreten" Adjektive die absolut keinem konkreten Informations- bzw. Verständnisgewinn dienlich sind ;-).
"Eine Person muss in einem Ort geboren sein." kann, wie richtig erwähnt, aus der Chen-Notation nicht abgeleitet werden, da die 1 in Chen-Notation im Sinne von 0..1 zu verstehen ist.
Vgl. dazu Peter P. Chen, S. 4, Abs. 1: "For example, the “1” or “N” on the lines between the entity types and relationship types indicated the upper limit of the entities of that entity type participating in that relationships."
--Geri, 18:17, 20. Dez. 2006 (CET)
thread_title:  Sachverhalt der Notationen 

message: Das ER-Modell wird sehr sehr Häufig zur Datenbankmodellierung eingesetzt. Unter diesem Gesichtspukt finde ich, dass der Artikel folgende Mägel aufweißt:
* Es wird viel zu wenig auf Attribute eingegangen
* Beispiele sind ohne Atributte
* Identifzizierende Attribute werden nur erwähnt, aber nicht erklärt(Unterstrichen).
Des Weiteren entsteht oft die Diskusion ob identifizierende Attribute der jeweiligen Beziehungspartner(Fremdschlüssel) in eine Beziehung gehören. Meiner Meinung nach ist das völlig falsch, da diese durch die Beziehung und deren Kardinalitäten selbst ausgedrückt werden. Gerade hier sollte jemand der sich sicher ist (und vielleicht die passende Literatur besitzt) Klarheit schaffen.
  
Hallo, lieber Anonymius,
Deine Einwände sind berechtigt. Ich habe daher versucht, sie im Artikel zu berücksichtigen.
Zu den identifizierenden Attributen:
In der ER-Modellierung haben lediglich Entitätstypen (nicht hingegen Beziehungen) identifizierende Attribute. Somit ist Deine Einschätzung korrekt. 
Der Terminus Fremdschlüssel hat in der ER-Modellierung nichts zu suchen. Er gehört in das Gebiet des Datenbankdesigns, zu dem die ER-Modellierung eine Vorstufe ist. Leider gibt es Werkzeuge, die die Datenmodellierung (mit dem semantischen oder konzeptionellen Datenmodell als Ergebnis) und das Datenbankdesign (das auch technische Aspekte berücksichtigt) in einem Zug abwickeln und somit vermengen (z.B. ErWin). Streng genommen müßte zwischen dem semantischen Datenmodell und dem Datenbankdesign ein Transformationsschritt liegen.  
Ich grüße Dich freundlich tzeh 14:05, 10. Sep. 2007 (CEST)
thread_title:  Attribute und Fremdschlüssel 

message: Laut dem Artikel stellt ein Beziehungstyp eine semantische Beziehung zwischen zwei Objekten dar. Sollte es aber nich heißen "zwei oder mehr", da meiner Meinung nach eine Beziehung auch zwischen mehreren Entitätstypen existieren kann. 84.161.184.63 17:16, 5. Sep. 2008 (CEST)
thread_title:  Anzahl beteiligter Einzelobjekte bei einer Beziehung 

message: Hallo,
ich finde das Beispiel "Person,Hotel,Reservierung" im Abschnitt über die Aggregation nicht wirklich geeignet, um die "part-of" Beziehung zu erläutern. Besser wäre ein Beispiel, wo man die Relation auch mit "besteht aus" beschreiben könnte. Das Fußballmannschaft Beispiel ist gut. Aber eine Reservierung besteht aus Hotel und Person klingt nicht intuitiv.
--Humbrie 13:36, 27. Okt. 2008 (CET)
replies: text: Hallo Humbrie, ich habe das Aggregationsbeispiel "Reservierung" bewußt gewählt, um u.a. zu zeigen, dass das Aggregat (die "Reservierung" ) nicht notwendig materieller Art sein muß, auch wenn die Komponenten ("Person" und "Hotel") materiell sind. Ein "intuitives" Verständnis ist didaktisch/ergonomisch sicher wünschenswert; aber dieses Verständnis läßt sich auch erreichen, wenn das zu "besteht aus" synonyme "setzt sich zusammen aus" als Erläuterung des Relationships verwendet wird. Alles Gute für Dich und liebe Grüße tzeh 19:39, 3. Nov. 2008 (CET)
thread_title:  "part-of" Beziehung 

message: Hallo, lieber Anonymus, 
Du behauptest:
"Allerdings sollte beachtet werden, dass eine Aufspaltung von n-ären Beziehungen in binäre Beziehungen einen Informationsverlust mit sich bringen kann."
Kannst Du diese Behauptung belegen? 
Beachte hierzu, dass im Artikel neben den n binären Beziehungen ein Entity-Typ eingeführt wird.
Siehe hierzu auch die folgenden web-links: 
http://stubber.math-inf.uni-greifswald.de/~irrgang/Datenbanken/03_ERModell.pdf 
http://www.pearson-studium.de/media_remote/katalog/bsp/9783827372666bsp.pdf 
Ich grüße Dich freundlich tzeh 18:29, 16. Dez. 2008 (CET)
thread_title:  n-äre Beziehungen und deren Aufspaltung in n binäre Beziehungen 

message: Ich habe eine Frage zur Definition des starken Entitättyp:
Starker Entitätstyp: Die Identifikation einer Entität ist durch ein oder mehrere Attribute einer anderen Entität des gleichen Typs möglich.
Mir ist absolut nicht klar, wie das gemeint ist. Nehmen wir den Entitätstyp Bank mit den Attributen BLZ und vielen mehr und zwei Entitäten Sparda Bank Nürnberg, BLZ 90504030 und Sparda Bank Frankfurt, BLZ 90504031. Den Satz würde ich jetzt so verstehen, dass die Sparda Bank Nürnberg durch ein oder mehrere Attribute von der Sparda Bank Frankfurt identifiziert werden können müsste, das ergibt aber keinen Sinn, sie wird durch das Attribut BLZ und zwar ihr eigenes! identifiziert, oder nicht.
:Hallo lieber Anonymus, Dank für den Hinweis auf die falsch formulierte Definition des Starken Entitätstyps! Def. wurde inzwischen korrigiert.
Allerdings ist Deine Argumentation auf Instanzen-Ebene (also auf der Ebene der Entitäten) nicht zutreffend. Bei der ER-Modellierung spielt sich alles auf der Typ- (in UML Klassen-)Ebene ab.
:Ich grüße Dich freundlich tzeh 13:37, 28. Dez. 2008 (CET)
thread_title:  Begriffe 

message: Im Artikel steht "Das ER-Modell ist der Standard für die Datenmodellierung, auch wenn es unterschiedliche grafische Darstellungsformen gibt.". Wenn mit "der Standard" sowas gemeint ist wie "standardisiert", dann glaub ich das nicht - kenne zumindest keine IEEE Norm oder sonstwas dazu. Wenn damit gemeint ist, dass es jeder verwendet (wenn auch unterschiedlich), dann kann ich dem zustimmen. Aber dann sollte es mMn heissen "Der Einsatz von ER-Modellen ist der de-facto Standard für die Datenmodellierung, auch wenn es unterschiedliche grafische Darstellungsformen gibt.".
Habs mal entsprechend geändert. --Sebastian.Dietrich 16:56, 5. Aug. 2009 (CEST)
thread_title:  Standard 

message: Lieber Sebastian.Dietrich, ich habe Deinen Terminus Relation (anstelle von Beziehung) rückgängig gemacht, denn Relation hat zunächst mit der ER-Modellierung nichts zu tun. Erst wenn das ER-Modell in ein relationales Datenmodell transformiert wird, kommt die Relation in´s Spiel. Ich grüße Dich freundlich tzeh 18:07, 1. Nov. 2009 (CET)
replies: text: Hi Tzeh! Danke für die Info. Verstehe ich das jetzt richtig: das "R" in ER bedeutet "Beziehung" (also eng. Relationship) und nicht "Relation" (also engl Relation). Und Entities und Relationships sind beides Relationen. Wenns stimmt, sollte das vielleicht wo kurz angemerkt werden - weil in der Praxis wird meiner Erfahrung nach "Relation", "Beziehung" und "Relationship" in der DB Modellierung & bei DB Admins (offensichtlich fälchlischerweise) gleich verwendet. lg Sebastian.Dietrich 19:04, 1. Nov. 2009 (CET)
replies: text: Hallo Sebastian, so ist es.  Die Sprachwelt der Datenmodellierung und die der relationalen Datenbanksysteme werden bedauerlicherweise nicht sauber getrennt. Hinzu kommt, dass im Englischen der Terminus Relation sowohl die Beziehung zwischen Objekten wie auch die Teilmenge des Cartesischen Produkts bezeichnet. So steht in der englischen Wikipedia: "In mathematics, a binary relation on a set A is a collection of ordered pairs of elements of A. In other words, it is a subset of the Cartesian product A2 = A × A. More generally, a binary relation between two sets A and B is a subset of A × B." Zwar lässt sich eine Beziehung durch eine Teilmenge des Cartesischen Produkts beschreiben, aber Beschreibungen sind halt etwas anders als das, was beschrieben wird. "A simulation isn’t the same as what’s simulated. A map is not the country. " Ich grüße Dich freundlich. tzeh 15:11, 2. Nov. 2009 (CET)
thread_title:  Relation für Beziehung? Zutreffender Ersatz bei der ER-Modellierung? 

message: Lieber Geof, 
Du schreibst: "Charakteristikum und Zweck der Entity-Relationship-Modelle ist die  Typisierung von Objekten und deren Beziehungen untereinander. Die Mehrzahl der Entitätstypen entstehen durch
* Spezialisierung übergeordneter Typen und sind als deren Teilmengen definiert. Ihre speziellen Eigenschaften heißen Attribute, wodurch die Teilmenge zur Obermenge eine Beziehung der Art „is-a“/„can-be“ erhält (z.B. Terrier is-a Dog bzw. umgekehrt Dog can-be Terrier). Gegenteilig zur Spezialisierung (immer feinere Attribute) wirkt die
* Aggregation, die Zusammenfassung von Einzelobjekten (Komponenten, z.B. Bauteile) zu einem Aggregat (Maschine). Die Art der Beziehung  wird „is-part-of“ genannt."   
Dies wirft einige Fragen auf und bedarf der Richtigstellung: 
1. Wieso ist der Zweck der ER-Modelle die Typisierung?
2. Wie kommst Du darauf, dass Die Mehrzahl der Entitätstypen durch Spezialisierung übergeordneter Typen entstehen und als deren Teilmengen definiert sind? 
3. Wieso "wirkt" die Spezialisierung (und nicht die Generalisierung) "gegenteilig" zur Aggregation? 
4. Was sind "feinere Attribute"? 
Ich grüße Dich freundlich tzeh 12:50, 13. Nov. 2009 (CET)
thread_title:  Zu Zweck und Entstehung der ER-Modellierung und zu Spezialisierung, Generalisierung, Aggregation 

message: Kann einer den Rechtschreibfehler "leitetet" aus der Grafik entfernen? Hört sich reichlich doof an. :)
-- 84.187.104.211 10:03, 3. Apr. 2010 (CEST)
thread_title:  Rechtschreibfehler 

message: Der Text
"Entität (Entity): individuell identifizierbares Objekt der Wirklichkeit (zum Beispiel Angestellter „Müller“, Projekt „3232“)"
ist meiner Ansicht nach überarbeitungsbedürftig. Das Problem hierbei sind "Müller" und "3232". Denn im Grunde ist "Müller" eine Eigenschaft / ein Attribut des Objektes, genauso wie es "3232" ist. Ein Objekt bedarf keines Attributes, um identifizierbar zu sein. Das muss zwar im Datenmodell so gemacht werden, damit ich später was damit anfangen kann, ist aber grundsätzlich erst einmal nicht nötig. Qua Existenz ist das Objekt eindeutig; das ist eine modellinhärente Wahrheit.
Vorschlag:
Entität (Entity): individuell identifizierbares Objekt der Wirklichkeit (zum Beispiel der Angestellte Müller, das Projekt 3232)
Kleiner, aber feiner Unterschied.
--Rhouvus 14:24, 29. Nov. 2010 (CET)
thread_title:  Identifizierbares Objekt 

message: Irgendwie hat MS Visio 2010 ein Datenbankmodelldiagramm in einer Art, die im Artikel gar nicht auftaucht. Leider konnte ich auch keinen Standard dazu finden. Weiß jemand, was das ist? -- 93.197.169.96 22:11, 22. Jul. 2012 (CEST)
replies: text: Hallo, diese Diagramme entsprechen wohl der erweiterten Chen-Notation, zumindest nach den Ergebnissen, die ich über Google zu 'Visio ERM' fand. Hier im Artikel sind die Attribute nicht dargestellt, in der Beschreibung wird aber auf diese erweiterte/modifizierte Notation verwiesen. --VÖRBY (Diskussion) 20:52, 23. Jul. 2012 (CEST)
thread_title:  Visio Datenbankmodelldiagramm