Diskussion:Entity-Relationship-Modell

Einleitungs-Abschnitt

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:29, 15. Nov. 2012 (CET)

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)

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)

---

Zu ERM und ERD:
Auch ich bin nicht der Meinung, daß die den beiden Kürzeln zugrundliegenden Bezeichner synonym sind. Das ER-Model (ERM) besteht aus dem ER-Diagramm (ERD) und einer Beschreibung der in der Graphik verwendeten Elemente; so fallen darunter die Definitionen der verwendeten Entitäten und ggf. deren Attribute.

salopp formuliert: ERM = ERD & description

Ich rege der besseren Verständlichkeit an, ein ERM, also eine ER-Grafik und die Beschreibung der Elemente als Beispiel mit in den vorliegenden Eintrag aufzunehmen. Wie seht Ihr das? -- tzeh 17:22, 27. Aug 2004 (CEST)

---

Habe 'ERD' als Abkürzung aufgenommen. Ein ERD als Grafikbeispiel ist schon drin. Was die Beschreibung enthalten kann, werde ich beispielhaft je Konstrukttyp noch ergänzen. --VÖRBY 17:16, 15. Okt. 2010 (CEST)

Selbstverständlich sind dies Synonyme, erzählt hier keinen Scheiss! Dumme Worterfinderei... --178.197.232.121 16:27, 15. Nov. 2012 (CET)

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)

Geschichte

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)

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)

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)

Krähenfuss-Notation

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)

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)

Also, ob SQL ein ER-Notation ist, darüber kann man wohl streiten (IMHO ist es eine, dann man kann die ER-Struktur ja vollständig damit abbilden). Aber SQL ist wohl schon in diesem Kontext erwähnenswert, desshalb hab' ich's wieder eingebaut - aber hoffentlich so, dass jetzt alle zufrieden sind ;) -- D. Düsentrieb (?!) 19:39, 23. Sep 2004 (CEST)

Praxiseinsatz

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)

Hallo Thomas,

da muss ich Dir Recht geben. Ich lösche den dritten Abschnitt.

Gruß Oliver

Beziehungen

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)

Hallo Andreas, richtig, die "is-a"-Beziehung (d.h. die Generalisierung resp. Spezialisierung) ist eine wichtige Beziehung; es gibt noch einige weitere wichtige Beziehungen wir die "is-element-of"-Beziehung und die "is-part-of"-Beziehung, die wir dann alle explizit aufführen müssten. Es ist eine Frage der Detaillierung resp. der Tiefe, ob wir dies tun wollen, oder ob wir es nicht bei Verweisen auf gängige Lehrbücher bewenden lassen.
tzeh 16:18, 30. Mai 2005 (CEST)

Hallo Tzeh, das stimmt meiner Ansicht nach nicht. Es wird zwischen Zwei oder Mehrstelligen Beziehungen (Relationships) und der is-a Beziehung unterschieden. Zumindest ist das in den Std-Lehrbüchern (z.B. Kemper-Eickler & Molina-Ullman-Widom) derzeit so. "is-element-of" und "is-part-of" sind gute Beispiele für normale 1-n Beziehungen. Die is-a Beziehung läßt sich aber in dieser Weise nicht modellieren. Die Unterscheidung würde ich schon erwähnen. o haben wir das an der Uni zumindest immer unterrichtet. Andreas75 22:16, 30. Mai 2005 (CEST)

Ich stimme Andreas zu, Generalisierung ist ein wichtiger Teil des Datenbank Lehrplans und ich denke wert hier gennant zu werden. Gruss -- Sparti 02:27, 31. Mai 2005 (CEST)

hallo Andreas, hallo Sparta, es trifft zu, dass es neben den zweistellige Beziehungen auch drei- und mehrstellige Beziehungen gibt, wobei mit x-stellig die Anzahl x der beteiligten Entitäts(typen) gemeint ist. Die is-a-Beziehung ist immer eine zweistellige Beziehung zwischen einem speziellen Entitätstyp und einem generellen Entitätstyp; so wird die Spezialisierung/Generalisierung modelliert. So gilt z.B. ein Hund ist ein (is-a) Säugetier; damit zeigt sich, dass sich die is-a Beziehung (entgegen Deiner Behauptung) durchaus "in dieser Weise" modellieren läßt. Zitiere doch mal bitte die Passage aus dem Lehrbuch Kemper-Eickler.
Achtung: Gelegentlich wird auch die is-a Beziehung im Sinne von ist-ein-Element-von (also Klasse-Instanz-Beziehung) verwendet. Hier tut man gut daran, stattdessen is-element-of als Bezeichnung für die Beziehung zwischen ebenfalls genau zwei Entitätstypen zu verwenden.

Wenn Du - wie auch Sparti - meinst, daß es die speziellen Beziehungstypen is-a, is-part-of, is-elemet-of etc. Wert sind, im Artikel explizit genannt zu weden, so werde ich in den nächsten Tagen eine Aufstellung nebst Beschreibung erstellen.
Ich grüße Euch herzlich tzeh 07:42, 31. Mai 2005 (CEST)

Hallo tzeh & Sparta,

nochmal, die is-a Beziehung ist keine spezielle 2-stellige Beziehung und läßt sich durch diese auch nicht ausdrücken (jedenfalls nicht verlustlos): Gegeben seine drei Enitäten A,B,C jede Enität besitzt ein Primärschlüssel-Attribut: jeweils a,b,c.

Es exitieren zwei is-a Beziehungen

• A<-B<-C (B ist eine Spezialisierug von A, C ist eine Spezialisierug von B)

Der komplette Primärschlüssel von:

• A ist a
• B ist a,b
• C ist a,b,c

D.h. die Entität C besitzt ebenfalls Attribute a und b. Bei einer normalen 2-stelligen Beziehung ist dies nicht der Fall. Die Bezeichnungen is-part-of und is-element-of im Zusammenhang mit ER-Diagrammen sind mir vollkommen unbekannt. Das ist kein UML. viele Grüße. -- Andreas75 08:22, 31. Mai 2005 (CEST)

---

Hallo Andreas(75),

ich habe den Eindruck, dass für Dich das ER-Modell, das relationale (Datenbank)modell
(und möglicherweise auch UML) eine Einheit bilden.

Dem ist nicht so; dies sind verschiedene Konzepte.

Im ER-Modell (und nur von diesem handelt der vorliegende Artikel) gibt es den Begriff der Identifikation, der Begriff Primärschlüssel gehört hingegen zur (anderen) Welt der relationalen Datenbanken bzw. Tabellen. Es gibt aber Zusammenhänge zwischen ER-Modell und relationalem Modell (und in der Folge relationalem Datenbanken). Ein Zusammenhang ist z.B. der, dass sich ein ER-Modell in ein relationales (Datenbank)modell bzw. Datenbankschema transformieren lässt.

Die Transformationsregeln sind z.B.:

Entität --> Tabelle;
1:n-Beziehung --> Fremdschlüssel in der „child“-Tabelle
n:m-Beziehung --> Tabelle mit zwei Fremdschlüsseln

Begeben wir uns in die Welt der ER-Modelle und deren Terminologie.
Dann mag es dort drei Entitäten (genauer gesagt Entitätstypen) geben, z.B. Hund, Säugetier und Tier.
Zwischen diesen drei Entitätstypen bestehen folgende Beziehungen:

Hund is-a Säugetier und
Säugetier is-a Tier.

Grafisch dargestellt wie folgt:

      is-a         is-a 

Hund <----> Säugetier <----> Tier

    c    1        c    1

In jeder is-a-Beziehung sind genau zwei Entitätstypen beteiligt. Es wird deutlich, daß das Säugetier die Generalisierung von Hund ist, wie auch, dass Tier die Generalisierung von Säugetier ist.
Welche Information soll in dieser Welt der ER-Modelle verloren gehen?

Ich grüße Dich freundlich tzeh 13:14, 31. Mai 2005 (CEST)

PS: Zu den binären Relationshiptypen is-part-of und is-element-of, die zur Welt der der ER-Modellierung gehören, werde ich mich im Zusammenhang mit den speziellen Relationship(typen) noch äußern. Es mag durchaus sein, dass in der Welt von UML diese Relationshiptypen unbekannt sind. Aber - wie gesagt - dies ist eine andere Welt...

Hallo Tzeh, ja und nein, ich möchte sehr wohl zwischen einem ER-Modell und einem relationalen Modell unterscheiden. Der Begriff Primärschlüssel war in der Tat falsch gewählt. Trotzdem kennt das ER-Modell einen Schlüsselbegriff (Abschnitt 2.3.3 im Molina-Ullman-Widom Buch, Kemper-Eickler habe ich gerade nicht zur Hand).
Mein Punkt war eigentlich, dass eine Entität durch eine is-a Beziehung Attribute besitzt, die sie von der jeweiligen Eltern-Entität erbt. Dies ist eine Eigenschaft, die durch ein normales Relationship nicht ausgedrückt werden kann. Die Unterscheidung zwischen Zweistelligen und Mehrstelligen Relationships fehlt im Artikel auch.
Frage: Überarbeitest du den Artikel, dann halte ich mich vorerst zurück. viele Grüße, andreas -- Andreas75 08:41, 1. Jun 2005 (CEST)

Hallo Tzeh und Andreas,

Der Begriff Primärschlüssel ist vollkommen in Ordnung, da dies eine notwendige Festlegung ist, um ein ER-Diagramm auf ein logische Datenbankschema abzubilden. Wie weiter unten erwähnt, ist eine saubere Trennung ziwschen den Begrifflichkeiten notwendig. Die Entitäten meines Andwendungsbereich werden repräsentiert durch eine Satz von Werten für die Attribute, die wiederum der Entityp (= Menge von Attributen) festlegt, zu dem das Entity gehört (Diese Zugehörigkeit muss im Vorfeld aus der Anwendungssemantik bestimmt worden sein). Das Bewusstsein für die zwei Ebenen - Strukturbeschreibungen (= ER-Diagramme) und Ausprägungen (= Wertesätze zu Attributmengen, entsprechend der Entitypen, zu den wir das jeweilige Entity zugeordnet haben) - ist von elementarer Bedeutung für eine exakte theoretische Betrachtung. Andernfalls sind Aussagen, die auf der ER-Modellierungen aufbauen, meist mehrdeutig, da wir sonst oft nicht unterscheiden können, ob eine Entity ("das Ding aus dem Ausschnit der realen Welt"), ein Entitytyp ("Das Konzept, das eine Menge ähnlicher Dinge aus dem Ausschnit der realen Welt durch Angabe gemeinsamer Merkmale strukturell beschreibt") oder eine Entityrepräsentation ("Die Repräsentation meiner Dinge aus dem Ausschnit der realen Welt, die zu einer vorher festgelegten Strukturbeschreibung passt") gemeint ist.

Gruss mopc --Mopc 10:35, 6. Dez 2005 (CET)

---

hallo Andreas,

Dank für Deine prompte Antwort! <-br>

Zum Schlüsselbegriff:
Im ER-Modell wird üblicherweise von Identifikation einer Entität gesprochen.

Zu den mehrstelligen Relationships haben wir im Artikel den folgenden (allerdings kurzen) Passus:
"Beziehung (Relationship): semantischer Zusammenhang zwischen i.d.R. zwei Gegenständen..."

Was hälst Du davon, wenn wir den Fall der mehrstelligen Beziehung durch ein weiteres Beispiel erläutern?
" Mitarbeiter x reist nach Zielort y mit Verkehrsmittel z. "

Ich werde in den nächsten Tagen die Liste der speziellen Beziehungstypen wie is-a, is-part-of
zusammenstellen und erläutern und zunächst hier auf der Diskussionsseite darstellen.
Herzlichen Gruß tzeh 11:02, 01. Juni 2005 (CEST)

---

Halo Sparti,
1. Relation vs Relationship
Teilst Du meine Auffassung, dass es einen Unterschied zwischen Relation und Relationship gibt? M.E. sind dise beiden Begriffe nicht synonym. Eine Relation ist ein Begriff in der Mathematik, der definiert ist als Teilmenge eines Kartesischen Produkts, also ein n-Tupel, das sich auch in relationalen Datenbanken als ein Datensatz mit n Attributen wiederfindet (in dem Artikel „Relation (Datenbanktechnik)“ ist dies falsch dargestellt). Hingegen ist ein Relationship als Beziehung definiert. Diese kann z.B. zwischen ein oder mehreren Entitäten definiert ist. In der Literatur (wie auch bei Wikipedia-Artikel „Relation“) werden diese beiden Begriffe manchmal (m.E. fälschlich) synonym benutzt. Wie siehst Du das?

2. Relationships mit spezieller Semantik

Wie versprochen habe ich hierzu etwas zusammengestellt, wobei ich mir nicht sicher bin, ob die Auflistung dieser Relationships nicht besser in dem (neuen) Artikel Relationship aufgehoben wäre anstelle eine möglichen Überfrachtung des Artikels ER-Modell. Wie siehst Du das?

Nachfolgend der Grundstock: ... Relationships mit spezieller Semantik

Die inhaltliche Bedeutung der Beziehung zwischen Entitäten kommt im ER-Diagramm lediglich durch einen kurzen Text in der Raute (meist ein Verb) bzw. als Beschriftung der Kante zum Ausdruck), wobei es dem Modellierer freigestellt ist, welche Bezeichnung er vergibt. Nun gibt es Relationships mit spezieller Semantik, die relativ häufig bei der Modellierung vorkommen. Daher hat man für diese Relationships spezielle Bezeichner und grafische Symbole definiert. Spezialisierung / Generalisierung und Zerlegung / Aggregation sind zwei ergänzende Beschreibungsmittel mit einer speziellen Semantik. Mid diesen beiden speziellen Relationships kann die Realwelt verfeinert / vergröbert modelliert werden. Mit fest definierten Namen und speziellen grafischen Symbolen wird gezeigt, dass es sich um semantisch vorbesetzte Relationships handelt.

2.1.Die Spezialisierung / Generalisierung mittels "is-a"-Relationship

Bei der Spezialisierung wird ein Entity als Teilmenge einer anderen Entity deklariert, wobei sich die Teilmenge (spezialisierte Menge) durch besondere Eigenschaften (spezielle Attribute und/oder Relationships) gegenüber der übergeordneten (generalisierten Menge) auszeichnet.

Da es sich bei einem Einzelobjekt einer spezialisierten Menge um dasselbe Einzelobjekt der generalisierten Menge handelt, gelten alle Eigenschaften – insbesondere die Identifikation - und alle Beziehungen des generalisierten Einzelobjektes auch für das spezialisierte Einzelobjekt.

Das Relationship Spezialisierung/Generalisierung wird durch "is-a" / "can-be" beschrieben. (Für "is-a" wird gelegentlich auch „a-kind-of“ benutzt. Quelle http://www.informatik.fh-kl.de/~brackly/download/SWE+DB/Skript/Neue%20Version/Kapitel%20I1_ERM.doc.)
Es handelt sich hierbei um ein 1:c-Relationship.

Beispiel zur "is-a"-relationship:
Grafik

Dackel <---------------------------> Hund

Es gilt: Dackel is-a Hund
und in anderer Leserichtung: Hund can-be Dackel

Die Spezialisierung erhält man durch Aufteilung, während die Generalisierung durch Zusammenführen von gleichen Einzelobjekten mit gemeinsamen Eigenschaften und Beziehungen, die in verschiedenen Entities vorkommen, in einem neuen Entity begründet ist. So können z.B. Kunden und Lieferanten zusätzlich zu Geschäftspartnern zusammengeführt werden, da Name, Anschrift, Bankverbindung etc. sowohl bei den Kunden wie auch bei den Lieferanten vorkommen.

2.2. Die Aggregation / Zerlegung mittels „is-part-of“-Relationship

Werden mehrere Einzelobjekte (z.b. Person und Hotel) zu einem eigenständigen Einzelobjekt (z.B. Reservierung) zusammengefaßt, dann spricht man von Aggregation. Dabei wird das übergeordnet eigenständige Ganze Aggregat genannt; die Teile, aus denen es sich zusammensetzt, heißen Komponenten. Aggregat und Komponenten werden als Entities deklariert.

Bei Aggregation / Zerlegung wird zwischen Rollen- und Mengenaggregation unterschieden:

Eine Rollenaggregation liegt vor, wenn es mehre rollenspezifische Komponenten gibt, diese zu einem Aggregat zusammengefasst werden und es sich um ein 1:c-Relationship handelt.

Beispiel zur "is-part-of"-relationship:
Grafik mit Fußballmannschaft bestehend aus Fußballspiel und Spielort
Es gilt:Fußballmannschaft is-part-of Fußballspiel.
Spielort is-part-of Fußballspiel
und in anderer Leserichtung: Fußballspiel besteht-aus Fußballmannschaft und Spielort.

Eine Mengenaggregation liegt vor, wenn das Aggregat durch Zusammenfassung von Einzelobjekten aus genau einer Komponente entsteht.

Hier liegt ein 1:cN-Relationship vor.

Beispiel zur Mengenaggregation
Grafik mit Fußballspieler und Fußballmannschaft
Es gilt: Fußballspieler is-part-of Fußballmannschaft
und in anderer Leserichtung: Fußballmannschaft besteht aus Fußballspieler

Literatur: Die Beschreibungsmittel Generalisierung und Aggregation gehen auf Smith/Smith (Smith, J.M. /Smith D.C.P.4 1977: "Database Abstractions: Aggregation and Generalization", In: ACM Transactions on Database Systems, Vol. 2, No. 2, S. 105-133) sowie auf Scheuermann/Schiffner/Weber (vgl. /SSW80/) zurück.
Lasse uns den vorstehenden Passus noch etwas verfeinern und die Beispiele durch eine Grafik mit der zugehörigen Symbolik ergänzen.
Ich grüße Dich freundlich tzeh 4. Jul 2005 08:23 (CEST)

Hallo Tzeh,

zu 1) Du hast voellig recht, dass dies zwei verschiedene Konzepte sind, die man eigentlich auch nicht verwechseln kann. Wir sollten die Definition von Relation vielleicht korrekt unter dem Relation (Datenbank) aufschreiben und erlaeutern. Die Quelle von Dir enthaelt uebrigens eine Definition fuer Beziehungen, die wir ebenfalls uebernehmen koennten. Damit wird die Diskussion auf eine solide Grundlage gestellt.

zu 2) Sehr gut. Den Text koennen wir soweit uebernehmen. Ich uebrigens bin auch kein Fan von Mammutartikeln, die einen ganzen Strauss Lemmata beinhalten (abschreckendes Beispiel: Objektorientierte Programmierung ). Allerdings halte ich es fuer sinnvoll einen Uebersichtsartikel zu haben, der jedes Thema anreisst und in einen Zusammenhang bringt. Redundanz ist da durchaus erwuenscht. Man kann dann die Details in die jeweiligen Lemmatas nocheinmal vertiefen.

Dann noch eine Frage zu der Tabelle in Entität (Informatik) mit dem Vergleich von Konzepten aus der Relationalen Algebra und dem ER-Modell. Dort steht, dass das Gegenstueck zu Entitytyp ein Relationstyp sei. Mein Verstaendnis ist aber, dass eine Relation bereits einen Entitytyp darstellt. Oder habe ich da was uebersehen?

Gruss -- Sparti 4. Jul 2005 23:24 (CEST)

Noch ein Nachtrag zu 1): Ich habe gerade nochmal in Relation (Mathematik) nachgesehen. Hier spricht man natuerlich eher von einer Beziehung zwischen Elementen aus zwei Mengen. Wahrscheinlich ist das die Ursache fuer die Verwechselung. Aber die beiden Defintionen unterscheiden sich eben. -- Sparti 4. Jul 2005 23:30 (CEST)

Hallo Sparti

zu deiner Frage: Der Begriff Relationstyp, den meisten unter Relationsschema bekannt, ist eine Strukturbeschreibung, genau gesagt eine Menge von Attribute, nach denen man Relatione, also Ausprägungen dieser Strukturbeschreibung, erstellen kann. Deshalb ist es richtig, dass ein Entityp immer auf ein Relationsschema (Synonym: Relationtyp) abgebildet werden muss, da ein Entitytyp eine Strukturbeschreibung aus der ER-Modellierung ist. Im allgemeinen ist zu beachten, dass es beim ER-Modell zwei Struktrubeschreibungs-Konzepte (Meta-Konzepte) - Entitytypen und Beziehungstypen - gibt, während es beim relationalen Modell nur eines gibt, nämlich Relationsschemata. Eine Abildung eines Entityp auf eine Relation ist somit grober Unfug. --Mopc 10:42, 6. Dez 2005 (CET)

Definition

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)

Das ist schon ok. Vielleicht waere wenn ueberhaupt "formal exakt" das bessere Wort gewesen? -- sparti 13:14, 2. Aug 2005 (CEST)

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)

Was komplett fehlt: Attribute! Und dann gibt es auch einen weiteren Unterschied zwischen Krähenfuss und zB Chen: Attribute bei Chen als Ovale an die Entitytypen angehängt, in der der Krähenfussnotation in den Entitytypen!

Präzise Terminologie

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)

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)

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

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)

Typ-Ebene im ERM?

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) zuletzt aktualisiert: --VÖRBY 11:29, 22. Okt. 2010 (CEST)

Liebe Leute, bitte keine Diskussion zu diesem Thema. Selbstverständlich modelliert man in der ER-Modellierung auf TYP-Ebene! IMMER! Bitte, bitte schaut in die Lehrbücher: Elmasri/Navathe; Kemper/Eickler; etc. Ein Kästchen steht für einen Entity-Typ eine Raute für einen Relationship-Typ. "Attributtyp" ist Nonsens weil "Attribut" bereits zur Typebene gehört! Auf Instanzebene reden wir von Attributwerten. JohnTB 15:18, 26. Okt. 2010 (CEST)

Danke JohnTB. Ist ja klar, dass man die Typen modelliert. Das ist aber halt die (zweistufige) Sicht des Modellierers und nicht die des Fachbereichs. Mein Anliegen war deshalb der Versuch, Nicht-Informatiker vor zu vielen Begriffen und mit 2 Ebenen zu verschonen. Vielleicht schafft man das mit einer etwas anderen Gliederung und Beschreibung im Kapitel Begriffe. Ich möchte es mal versuchen; bleibe bitte auch am Thema. Danke.
PS: Der Vollständigkeit halber sollte man 'Attributwert' auch im Text aufnehmen. Ich habe diesen Begriff auch schon mit 'Eigenschaft' kennengelernt.
--VÖRBY 18:22, 26. Okt. 2010 (CEST)

Nachtrag für @JohnTB: Deine Aussage zu 'Attributwerten' kann ich so nicht nachvollziehen: Die von mir 'gegoogelten' Beispiele definieren den 'Attributwert' als konkrete Ausprägung von Attributen / Tupels etc, also immer für 'Daten' gültig. Die reale Welt hat aber mit 'Daten' (noch) nichts zu tun. Entitäten unterscheiden sich durch 'Eigenschaften, Kennzeichen, Merkmale' usw., was man (nach http://dict.leo.org) in English einfach 'Attribute' nennen kann. Dieser Begriff ist aber in der ERM bereits der Typebene zugeordnet. Dieses Dilemma (Homonym) ist vielleicht auch der Grund dafür, dass 'Attribut' im bisherigen / früheren Text nur einmal auftrat.
Im ERM-Text sollte man insofern für die Ebene 'reale Welt' den Begriff 'Eigenschaft' benutzen - was ich in der Praxis vielfach festgestellt habe. 'Attribut' für beide Ebenen zu verwenden wäre insofern nicht korrekt als in der Modellierung auf dem Weg von 'Eigenschaft zu Attribut' (identisch wie von 'Entität zu Entitätstyp') eine Normierung, Umgestaltung erfolgen kann.
'Attributtyp' wäre natürlich falsch - weil man darunter weitere Typisierungen von 'Attribut' (wie 'Datum, Text, PLZ etc.) versteht.
Ich werde den Eintrag unter 'Begriffe' noch entsprechend aktualisieren.
--VÖRBY 10:21, 28. Okt. 2010 (CEST)

---

Dieser Diskussionspunkt ist ja soweit erledigt - mit dem Ergebnis, dass bei der Modellierung sowohl die Instanzenebene als auch die Typ-Ebene sprachlich verwendet wird. Daran will ich nichts ändern, aber trotzdem nochmal darauf hinweisen, dass z.B. in anderen Branchen Modelle sprachlich auch nicht zwei verschiedene Ebenen verwenden. Zum Beispiel Konstruktionsmodelle von Fahrzeugen: Dort werden u.a. verschiedene Bauteile (Räder, Fenster, Schrauben ...) beschrieben und auch (exemplarisch) dargestellt. Ich denke, dass in solchen Modellen niemand von 'Bauteiltyp' spricht, sondern immer nur von 'Bauteil'. Dass im Modell eine Typisierung erfolgt, ist jedem klar. Analog könnte man es auch in der ERM sehen - aber das haben die Schöpfer einfach anders definiert. Im Übrigen wird sich auch in der Datenmodellierung (in Projekten) kaum jemand wirklich mit Entitäten (im Einzelnen) beschäftigen; man hat da IMMER den ganzen Typ (Kunde, Produkt, Rechnung ...) im 'Hinterkopf'. Erst wenn man Kardinalitäten definiert, kommt die 'Menge' ins Spiel. Insofern zeigt ein ERD (als Modell) in seiner Notation (als Entitätstypen) immer Vertreter einer Klasse, auf die Realität bezogen muss man diese Konstrukte aber jeweils als 'mehrere' denken.
Keine Antwort erwartet: --VÖRBY 12:14, 13. Aug. 2011 (CEST)

Grenzen des ER-Modells

Ich fände es auch sinnvoll die Grenzen bei der Modellierung aufzuzeigen, zB. dass keine Verbindungen zwischen Relationships hergestellt werden können. Leider habe ich momentan keine Zeit etwas dazu zu schreiben. Ist mir nur aufgefallen als ich den Artikel überflogen habe.

Artikel schwer verständlich

Der Artikel ist für mich als Einsteiger mit minimalem Vorwissen äusserst schwer verständlich, und ich bezweifele, dass er für Leser ohne Vorwissen überhaupt zu verstehen ist. So wird zwar von Kardinalitäten gesprochen, erklärt werden sie aber nicht; sie waren bis vorhin noch nicht mal verlinkt. Und z. B. das 1:cN-Relasionship bzw. das 1:c-Relasionship wird erwähnt, aber weder hier noch im Artikel Kardinalität (Datenbanken) erklärt. Wäre schön, wenn jemand mit Fachwissen das ändern könte... :)
-Christian 12:32, 6. Jan 2006 (CET)

---

Ich habe in beiden Artikeln einiges geändert und auch Beispiele eingestellt. --VÖRBY 18:07, 15. Okt. 2010 (CEST)

Ich beziehe mich mal nur auf den Abschnitt "Praxistipps zur Erstellung von ER-Modellen". Leider veranschaulicht er das Lemma aus meiner Perspektive überhaupt nicht: (Das war schon mal die Überschrift, die auch den Teilartikel von 'Datenmodellieren' abdecken sollte - der aber noch in Diskussion war. --VÖRBY 12:55, 29. Okt. 2010 (CEST))

1. Ein Anwendungsfall wird benannt, aber nicht skizziert.
   • Der Sachverhalt ist allgemein bekannt. --VÖRBY 12:55, 29. Okt. 2010 (CEST))
     • Sorry, aber das ist er nicht! Und gerade ein Laie würde sich wundern: Worauf genau muss ich das Schema anwenden? --Zahnradzacken 19:11, 29. Okt. 2010 (CEST)
2. Dann folgen Schemata und konkrete Instanzen dieser.
3. Beide werden schließlich nochmal mit Worten beschrieben.

Es wird kein Vorgehen beschrieben (obwohl "zur Erstellung" nahelegt, dass hier ein Vorgang erläutert wird). Das Schema selbst finde ich nicht angebracht (aus prinzipiellen Gründen, siehe hier), es wird auch nicht eingeordnet (zum Beispiel mit den Worten „es kann helfen, so und so vorzugehen“, „erste vorläufige Modelle erhält man durch ...“, oder aber „Schema X funktioniert immer [dann, wenn]“). Auch die wörtliche Beschreibung fasst nur in Worte, was dort schematisch steht, nicht aber, was "zur Erstellung" zu tun ist. Ich glaube, es würde dem Verständnis mehr dienen, Kapitel 1 besser zu gliedern und zu formatieren (weniger Stichpunkte, mehr Absätze, vor allem bei 1.2) und dort die Beispiele ordentlich einzuarbeiten. --Zahnradzacken 22:19, 27. Okt. 2010 (CEST)

Ich habe nun die Tipps aus dem Artikel rausgenommen und beide Teile im hier nachfolgenden Kapitel eingestellt. Deine Hinweise habe ich versucht zu berücksichtigen. Danke. --VÖRBY 09:45, 29. Okt. 2010 (CEST)

Welche Hinweise genau und inwiefern berücksichtigt? Kann es gerade nicht rekonstruieren. --Zahnradzacken 19:11, 29. Okt. 2010 (CEST)

Anwendungsbeispiele zur Erstellung von ER-Modellen

Die nachfolgend hinterlegten Empfehlungen waren ursprünglich als Inhalt im Artikel selbst vorgesehen. Nach intensiveren 'Diskussionen' wurde jedoch festgestellt, dass solche Tipps lediglich persönliche Erkenntnisse sind und sie deshalb (ohne offizielle Quellenangabe) nicht im Artikel veröffentlicht werden sollten.

Rückfragen oder weitere Vorschläge bitte über meine Diskussionsseite. --VÖRBY 15:59, 7. Nov. 2010 (CET)

---

Bei der Erstellung von Datenmodellen, im Besonderen ERM's als semantischen Datenmodellen, können die folgenden Ausführungen helfen, die Komponenten zu finden, sie zu benennen und zu beschreiben. Die Kenntnis des Wikipedia-Artikels Entity-Relationship-Modell o.ä. wird vorausgesetzt.

Vorbemerkung: Alle verwendeten datenbezogenen Aussagen sind nur Beispiele und keine allgemeingültigen Feststellungen. Dabei wird unterstellt, dass die fachlichen Fakten aus vorhandenen, verbindlichen Unterlagen / Aussagen hervorgehen.

Entitäten, Beziehungen und Eigenschaften identifizieren

Zum Bilden der Inhalte eines Datenmodells können die folgenden Fragestellungen / Hinweise bei der Identifikation von Entitätstypen helfen:

• Ist die Information kontext-relevant?
• Wenn Ja: "Sie ist eine Information ÜBER <wen oder was>?" (<Entitätstypbezeichnung>). Bsp.: Kunden, Produkte
• Kandidaten für Entitätstypen (ET) sind häufig Substantive in Texten und Aussagen zur Aufgabenstellung. Unterscheide dabei aber ET von 'Funktionen' (das sind häufig substantivierte Verben wie 'Berechnung', 'Lieferung').
  

Zusammengesetzte Begriffe (Rechnungsnummer, Liefer(ungs)anschrift, Buchtitel ...) weisen implizit auf Entitätstypen hin.

Manche Begriffe können Funktion und Entitätstyp sein (z.B. 'Bestellung').

Unterscheide Entitätstypen auch von Datengruppen - die das System als Ein- oder Ausgabedaten verarbeiten muss und in denen Informationen aus mehreren Entitäten enthalten sein können. Beispiel 'elektronische Bestellung'.

• Empfehlung: Entitätstypen im Singular benennen, denn die Kardinalitätsaussage ist (wechselseitig) nur aus der Sicht genau 1 Entität passend.
• Attribute müssen vollständig von der jeweiligen Entität (lt. Typ) abhängig sein.
• Beziehungen mit Attributen sind Kandidaten für eigene (Beziehungs-) Entitäten.

Bsp: MITARBEITER gehört zu ABTEILUNG; Attribut: leitet oder gehört zu, seit Datum, ...

Neuer Entitätstyp 'Bz_MA_ABT' (formuliere nach den vorgegebenen Namenskonventionen)

• Mehrfach vorkommende Eigenschaften oder Eigenschschaftsgruppen (Anschrift1, 2 ... von KUNDE) sind Kandidaten für eigene Entitätstypen; neuer Entitätstyp ADRESSE.
• n:m-Beziehungen sind Kandidaten für 'Beziehungsentitäten'.
• Wähle 'stabile' Attibute als Kandidaten zur Identifikation der Entitätstypen.
• Das Datenmodell ist dann (quantitativ) vollständig, wenn sich alle datenbezogenen Aussagen in den Texten zur Aufgabenstellung (soweit die Daten zu speichern sind) auf Inhalte im Modell zurückführen lassen.

Beispiel: Gem. den Festlegungen zur Aufgabenstellung "soll eine Rechnung die Inhalte Kundenname, Artikelnummer, Anzahl bestellte Artikel und Rechnungssumme enthalten." Datenaspekte wie Adresse, Preis, MWSt etc. sind hier aus Gründen der Vereinfachung nicht genannt.

Überlegungen je gefundenem Datenbegriff: (> = daraus ergibt sich ...)

Sich daraus ergebendes ERD

• Rechnung: Über sie sind Informationen zu speichern. > Entitätstyp RECHNUNG
• Kundenname: gehört nicht eindeutig zu Rechnung. > Entitätstyp KUNDE mit Beziehung zu RECHNUNG; Beziehung benennen, Kardinalität festlegen
• Artikelnummer: gehört nicht eindeutig und ausschließlich zu Rechnung. > Entitätstyp ARTIKEL. Beziehung zu Rechnung wäre n:m. > Neuer Entitätstyp RECHNUNGSPOSITION
• Anzahl bestellte Artikel: gehört zu Entitätstyp > RECHNUNGSPOSITION
• Rechnungssumme: gehört zu > RECHNUNG ('abgeleitete' Information)

Beziehungstypen und ihre Kardinalität formulieren

Situation (beispielhaft):
In einem Softwareprojekt wurde ein 'Zusammenhang' zwischen Mitarbeiter und Projekt mit der Bedeutung 'Projektleitung' fachlich festgelegt. Die Kardinalität ist noch zu bestimmen.

Finden der Kardinalität
durch zweistufige Fragestellung zur Bedeutung der Beziehung und unter Anwendung des Worts JEDE(r):

1. Jeder MITARBEITER leitet wie viele (min,max) PROJEKTe? Antwort: 'min=0, max=n'

2. Jedes PROJEKT wird geleitet von wie vielen (min,max) MITARBEITERn? Antwort: 'min=1, max=1'

Resultat: Bezeichnung des Beziehungstyps mit Kardinalität:

MITARBEITER (1,1) leitet (0,n) PROJEKT (in diesem Beispiel)

In diesem textlichen Notationsbeispiel steht also direkt neben der Entitätsbezeichnung (als Zahlenangabe), zu wie vielen Entitäten (dieser Seite) jede einzelne Entität der anderen Seite in Beziehung stehen kann.
Konkret im Beispiel: Auf der Seite von PROJEKT steht, wie viele Projekte jeder (einzelne) MITARBEITER leiten kann; hier min. keines, max. mehrere. Umgekehrt steht auf der Seite von MITARBEITER, wie viele Mitarbeiter ein (konkret bestimmtes) PROJEKT leiten können; hier genau einer.
In ER-Diagrammen werden die Kardinalitätsaussagen je nach Notationsart grafisch (z.B. als 1 oder 2 Querstriche) oder in Form von Zahlen (siehe Kapitel ER-Diagramme) dargestellt.

Absatz Darstellungsformen

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)

Absatz Erweiterungen

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)

nur getestet

Welche Programme werden genutzt???

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)

SiSy sagt mir leider nichts, obwohl zu meinem Studium Geschäftsprozessmanagement gehörte. In dem betreffenden Artikel fehlt aktuell sogar der Name des Herstellers. Wir hatten uns da (leider) komplett auf ARIS beschränkt.. --SGOvD-Webmaster (Diskussion) 12:12, 14. Okt. 2006 (CEST)

Überarbeiten 13.12.2006

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)

Bin für Beziehung und Beziehungstyp. --EFR 10:03, 14. Dez. 2006 (CET)

ER-Diagramme

M.M.n. sind die Kardinalitäten bei der Min-Max/ISO-Darstellung nicht korrekt, nämlich in der Seite vertauscht, angegeben. Ja, ich habe auch schon gelesen dass bei dieser Art der Darstellung die Kardinalitäten "umgekehrt" (Umgekehrt wozu? Zur Chen-Notation, wie es scheint.) angegeben werden. Ist DAS tatsächlich so? Oder hat sich da möglicherweise eine falsche Interpretation verbreitet, weil z.B. Einer vom Anderen abgeschrieben hat? Auch ist für mich nicht nachvollziehbar, warum die "Erfinder" von Min-Max justament eine umgekehrte Darstellung gewählt haben sollten.

Der gleichen Meinung scheinen die Entwickler des Sybase PowerDesigners zu sein. Der zeigt bei folgender Definition einer Beziehung...

Person to Ort
Rolle: geboren in
Kardinalität: 1,1

Ort to Person
Rolle: Geburtsort von
Kardinalität: 0,n

...Folgendes, als Kombination aus Krähenfuß- & Min-Max-Notation (natürlich graphisch schöner, aber hier geht's ja ums Prinzip ;-):

+--------+                                 +-------+
|        |\ geboren in      Geburtsort von |       |
| Person |-o-----------------------------|-|  Ort  |
|        |/     0,n              1,1       |       | 
+--------+                                 +-------+

Das entspricht sehr wohl der Richtung n:1 nach Chen.

--Geri, 18:17, 20. Dez. 2006 (CET)

Ich habe gerade noch in der Bibliothek nachgeschaut, aber da findet sich gar nichts "Originales" zur Min-Max-Notation, nur Abschreiber ;). Eine Originalquelle würde mich denn auch interessieren.

Ich kann aber noch die Erfahrung beisteuern, dass die alten Datenmodelle eines großen Konzerns bis zum Anfang der 1990er mit der zu Chen umgekehrten Notation gearbeitet haben. Zur Begründung: Durch die Notation der Minima und Maxima beim Beziehungsnamen wird die Lesbarkeit des Diagramms im wortwörtlichen Sinne unterstützt:

+--------+                                  +-------+
|        | geboren in (1,1)                 |       |
| Person |----------------------------------|  Ort  |
|        |            Geburtsort von (0,N)  |       | 
+--------+                                  +-------+

führt beim Vorlesen zu: Eine Person ist geboren in einem bis einem Ort, ein Ort ist Geburtsort von null bis N Personen.

Gruß --EFR 09:27, 21. Dez. 2006 (CET)

Die Originalarbeit zur (min,max)-Notation stammt von Abrial aus dem Jahre 1974. Chens Arbeit datiert von 1976, jedoch ohne präzisierte Kardinalitätsvariante. Elmasri/Navathe erwähnen in ihrem Lehrbuch Grundlagen von Datenbanksystemen, dass die (min,max)-Angaben in ihrer originären Form jeweils am Anfang eines Beziehungstyps platziert sind. Einfache Kardinalitätsangaben bei Chen sowie präzisierte Kardinalitätsangaben in der UML finden sich jeweils am Ende eines Beziehungstyps.

Noch eine kurze Anmerkung zu der Aussage, dass die (min,max)-Angabe nach der Anzahl der Beziehungen fragt. Es spielt keine Rolle, ob die Beteiligungshäufigkeit einer Entität an einer Beziehung über die Anzahl der Entitäten (objektzählende Kardinalitätsinterpretation) oder über die Anzahl an Beziehungsinstanzen (beziehungszählende Kardinalitätsinterpretation) bestimmt wird.

Literatur: Schneider, Stephan: Konstruktion generischer Datenmodelle auf fachkonzeptioneller Ebene im betrieblichen Anwendungskontext. Methode und Studie. 2007. Aachen: Shaker Verlag.

Sachverhalt der Notationen

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)

Martin-Notation := Krähenfuß-Notation

Unter ER-Diagramme steht wörtlich: "Von besonderer − zum Teil historischer − Bedeutung sind unter anderem: [...] Die Martin-Notation (Krähenfuß-Notation) als weit verbreitete Werkzeug-Diagramm-Sprache (Information Engineering)."
Nachdem ich mich aufgrund dieser fragwürdigen Information wund gesucht habe, komme ich zum Schluss, dass der Krähenfuß mit Herrn (James) Martin nur am Rande zu tun hat.
Sie hierzu: http://www2.cs.uregina.ca/~bernatja/crowsfoot.html : `The crow's foot notation was invented by Gordon Everest, who originally used the term "inverted arrow" but now just calls it a "fork".´
Ich hätte an dieser Stelle gerne einen Verweis (Link) auf eine kundige Definition der Krähenfuß-Notation. Leider kann ich nicht beurteilen, ob das für obige Darstellung von bernatja der Fall ist.

Attribute und Fremdschlüssel

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)

Hallo! Noch eine Anmerkung, in dem Artikel ist die Rede davon, dass nur Entitäten Attribute haben können, allerdings ist es auch gebräuchlich den Relationen Attribute zu geben. --F GX 11:25, 19. Jan. 2009 (CET)

Hallo F GX, ich unterstelle, dass Du mit Relationen Relationshiptyps (also Beziehungstypen) meinst. Im Artikel steht über die Attribute von Beziehungstypen Folgendes: "Üblicherweise haben 1:n-Beziehungstypen keine Attribute, da diese immer einem der beteiligten Entitätstypen zugeordnet werden können. Im Falle eines n:m-Beziehungstyps kann aus dem Beziehungstyp ein eigenständiger Entitätstyp mit Beziehungstypen zu den ursprünglich beteiligten Entitätstypen geschaffen werden. Dem neuen Entitätstyp kann dann das Attribut zugeordnet werden (zum Beispiel Attribut Projektbeteiligungsgrad beim n:m-Beziehungstyp „Angestellter arbeitet am Projekt“ zwischen den Entitätstypen Angestellter und Projekt)."
Hieraus geht hervor, dass es nicht notwendig ist, für Beziehungstypen Attribute vorzusehen. Ich grüße Dich freundlich tzeh 17:24, 21. Jan. 2009 (CET)

Ternärer Beziehungstyp

Im Artikel steht "Ternäre und höhergradige Beziehungstypen lassen sich immer auf binäre Beziehungstypen durch Einführung eines neuen Entitätstyps, der den ursprünglichen Beziehungstyp beschreibt, zurückführen. Insofern kann ohne inhaltliche Einschränkung gelten: es gibt nur binäre Beziehungstypen." Das stimmt so nicht. Die angegebene Methode zur Umwandlung erlaubt zwar die Darstellung aller Beziehungen, die der ternäre Beziehungstyp auch erlaubt, aber es gehen ggf. Conststraints verloren. Beispiel N:N:1 Beziehung zwischen Projekt, Teil und Lieferant, besagt dass innerhalb eines Projekts ein Teil immer vom gleichen Lieferanten kommt. JohnTB 10:57, 7. Apr. 2008 (CEST)

---

Hallo JohnTB,

ich interpretiere Dein skizziertes Beispiel folgendermaßen:

Im ER-Diagramm habe wir einen ternären Beziehungstyp, den wir "liefert" / "wird geliefert" nennen und der durch eine Raute dargestellt wird, an der die folgenden Entitätstypen beteiligt sind:
1. Projekt mit der Kardinalität N
2. Teil mit der Kardinalität N und
3. Lieferant mit der Kardinalität 1

Welche Semantik steckt nun in dem ternären Relationship mit seinen Kardinalitäten?
Du liest ab: für ein Projekt werden alle Teile von einem Lieferanten geliefert.
Ich lese ab: ein Teil wird für alle Projekte von einem Lieferanten geliefert.

Kurzum: Ich will damit sagen, dass ternäre - und erst recht höhergradige - Beziehungstypen mit ihren Kardinalitäten semantisch mehrdeutig sind. Und da sie nicht eindeutig sind, ist beim Übergang zu binären Beziehungstypen auch kein Informationsverlust damit verbunden.

Ich grüße Dich freundlich tzeh 15:12, 7. Apr. 2008 (CEST)

---

Hallo tzeh, Die Semantik ist nicht mehrdeutig: Wenn an einer Kante eine 1 steht wird der entsprechende Entitytyp funktional durch die Kombination der übrigen bestimmt (Projekt x Teil) -> Lieferant. Das bedeutet je Projekt und Teil gibt es einen Lieferanten und nicht mehrere. (Das heisst nicht, dass alle Teile von einem Lieferanten kommen, sondern nur, dass in einem Projekt ein bestimmtes Teil nicht von mehreren Lieferanten kommen kann) Ebenfalls freundliche Grüsse, JohnTB

---

Hallo Thomas,
Ich ziehe den Einwand zurück. Ein n-stelliger Beziehungstyp lässt sich durch einen schwachen Entitytyp ohne partiellen Schlüssel nachbilden: mit identifizierenden Beziehungstypen zu allen n Enitytypen und 1:1 Beziehungen zu den Entitytypen an deren Kante beim n-stelligen Typ eine 1 stand. freundliche Grüsse, JohnTB 08:21, 8. Apr. 2008 (CEST)

---

Hallo Ich bin inzwischen wieder auf das gleiche Problem gestossen - Ternäre Beziehungstypen lassen sich i.A. **nicht** auf binäre zurückführen. Mein eigener Lösungsvorschlag von oben ist falsch! Und hier die Erläuterung: 1. Die Semantik der Kardinaltät in Chen-Notation am ternären Beziehungstyp ist eindeutig definiert: eine 1 bedeutet dieser Entitytyp ist funktional abhängig von der Kombination der übrigen (s.o. das war ja schon bekannt). 2. Angenommen wir haben den folgenden Sachverhalt: ternäre Beziehung zwischen Entitytypen A, B und C mit Kardinalitäten 1:1:N - das bedeutet:

  B,C -> A und A,C -> B. 

Wenn wir jetzt den ternären Beziehungstyp durch einen schwachen Entitytyp D modellieren, dann können wir die Entitytypen mit einer 1 an der Kante (A und B) eben nicht durch eine 1:1 Beziehung an D anbinden. Das würde nämlich hier bedeuten, dass es zB pro A-Entity nur ein D-Entity gäbe, also auch nur eine Instanz des ternären Beziehungstyps, und das ist falsch. Wir können aber den schwachen Entitytyp durch statt durch A,B und C nur durch B und C identifizieren, weil (wegen B,C->A) A nicht mehr zur Identifikation gebraucht wird. In dem Fall verlieren wir aber die funktionale Abhängigkeit A,C -> B, die nicht mehr darstellbar ist weil wir keine alternativen Identifizierungen für schwache Entitytypen modellieren können. Alternativ könnten wir natürlich auch A und C zur Identifikation verwenden, aber dann verlieren wir die andere funktionale Abhängigkeit. Ergo: Sobald an einem ternären Beziehungstyp mehr als eine 1 an den Kanten steht ist eine verlustfreie Zerlegung auf binäre Beziehungstypen nicht mehr möglich. Beste Grüße,

JohnTB 16:36, 22. Apr. 2010 (CEST)

---

Hallo John, sorry: ich sehe das Problem nicht. Lies doch mal die beiden Artikel die im unten stehenden Kapitel mit dem Titel "n-äre Beziehungen und deren Aufspaltung in n binäre Beziehungen" aufgeführt sind. Ich grüße Dich freundlich tzeh 20:51, 22. Apr. 2010 (CEST)

---

Hallo Thomas, die von dir angeführten Quellen gehen nicht auf die Abbildung von Kardinalitäten in ternären Beziehungstypen ein. Solange keine Kardinalitäten angegeben sind stimmt die Aussage, dass eine äquivalente Abbildung auf binäre Beziehungstypen möglich ist. Sobald an mehreren Kanten eine Kardinalität 1 aufgeführt ist stimmt das nicht mehr. Die pauschale Behauptung im Artikel ist also falsch. (Übrigens: Im angeführten Pearson Buch ist die Behauptung auch pauschal und auch definitiv falsch!). Bitte denk über mein Beispiel von oben nach, dann wirst du mir zustimmen. Das Problem besteht darin: Eine 1 an einer Kante definiert eine funktionale Abhängigkeit, die eine Integritätsbedingung für dieses Modell darstellt. Wenn mehrere Kanten eine 1 haben, können bei der Abbildung auf binäre Beziehungstypen nicht mehr alle diese Integritätsbedingungen modelliert werden. schöne Grüße, JohnTB 10:56, 23. Apr. 2010 (CEST)

---

Hallo John, Chen beschreibt in seinem Artikel lediglich die Bedeutung der Kardinalitäten zwischen zwei (nicht notwendig verschiedenen) Entitytypes und zwar in der Bedeutung: Anzahl der an einem beliebigen Entity beteiligten E n t i t i e s. Er sagt nichts über die Kardinalitäten bei drei oder mehr beteiligten Entitytypes. Das kann er auch nicht, da dies keinen Sinn macht. Was soll es denn bei einem ternären Relationship mit den Entitytypes A, B und C auch heißen, wenn am Entitytype A z.B. ein n steht? Heißt dies, ein Entity vom Entitytype A ist mit n anderen Entitäten von B in Beziehung, oder mit n Entitäten von C oder etwa mit n Entitäten von B und C?. Kurzum: alle Notationsformen, die an einem Relationship(type) beteiligten E n t i t ä t e n zählen (wie es bei der Chen-Notation der Fall ist) versagen, wenn es um höhergradige Beziehungen handelt. Anders verhält es sich, wenn die Kardinalitäten sich auf die beteiligten Ausprägungen von B e z i e h u n g e n handelt; und dies ist lediglich bei der (min,max)-Notationsform der Fall. Dort heißt z.B. eine 1 - geschrieben (1,1) - am Entitytype A, dass ein A-Entity an genau einer Beziehung mit B und C partizipiert. All dies ist in dem Artikel über Min-Max-Notation m-E. recht gut dargestellt.
Just dies ist bei der ternären Beziehungen, die in drei binäre Beziehungen aufgespalten wird, durchaus darstellbar, aber nur dann, wenn es sich um Kardinalitäten gemäß der (min,max)-Notation handelt, da nur diese bei höhergradigen Relationships Sinn machen. Insofern gilt die Aussage, dass n-äre Relationshipypes ohne inhaltliche Einschränkungen in binäre aufgespalten werden können. Ich grüße Dich freundlich tzeh 13:26, 4. Mai 2010 (CEST) PS: Ich würde dies gene an einem grafischen Beispiel verdeutlichen, wenn Grafiken hier nicht so schwer zu integrieren wären...

---

Lieber Thomas, du schreibst nun schon zum wiederholten mal, dass Constraints bei ternären und höhergradigen Beziehungstypen keinen Sinn machen würden. Tut mir sehr leid, Thomas, aber damit liegst du definitiv falsch. Vielleicht sind meine Erklärungen noch nicht detailliert genug gewesen, also versuche ich es nochmal etwas genauer: Nehmen wir an wir haben einen ternären Beziehungstyp zwischen den Entitytypen A, B und C. Jede einzelne Beziehung dieses Typs setzt dann genau drei Entities zueinander in Beziehung, nämlich ein a vom Typ A, ein b vom Typ B und ein c vom Typ C. Jede Beziehung kann also durch ein Tripel (a,b,c) beschrieben werden. Durch Constraints werden nun Einschränkungen in der Menge der möglichen Tripel definiert. Wenn an allen Kanten ein N steht gibt es keine Einschränkungen. Steht meinetwegen beim Etitytyp A eine 1, dann bedeutet das, dass A funktional abhängt von BxC - Das heisst: für eine Kombination (b,c) gibt es nur ein a in der Menge unserer Tripel, oder anders ausgedrückt: Eine gegebene Kombination (b,c) kommt nur einmal in der Menge unserer Tripel vor. Damit ist die Semantik der Constraints bei höhergradigen Beziehungstypen wirklich eindeutig definiert, und es besteht auch kein Zweifel daran, dass man so auch sinnvolle constraints spezifizieren kann. (Du kannst das zB nachlesen bei Elmasri/Navathe(5.Ed.)3.9.2 Constraints on Ternary Relationships). Bevor du meine Erklärung oben verstehen kannst musst du zuerst verstehen wie Constraints bei ternären Beziehungstypen definiert sind. Dann ist mein Beispiel von vorher eigentlich recht einfach. Wenn Du es aber genau wissen willst, dann kannst Du auch mal einen Blick in den folgenden Fachartikel werfen, in dem die Autoren versuchen festzustellen wann ternäre Beziehungstypen auf binäre abbildbar sind und wann nicht:
Jones, Song: Binary representation of ternary relationships in ER conceptual modeling (http://www.springerlink.com/content/f8m735m146285640/)
oder besser noch:
Jones, Song: Binary Equivalents of Ternary Relationships in Entity-Relationship Modeling: a Logical Decomposition Approach. Journal of Database Management, April-June, 2000, pp. 12 -- 19 (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.4274&rep=rep1&type=pdf).
Hier schreiben die Autoren u.a.: ... "We identify which ternary relationships have true, fully equivalent, binary equivalents and those which do not." ...
zur Definition der constraints:" Cardinalities for ternary relationships can take the form of 1:1:1, 1:1:M, 1:M:N or M:N:P. The cardinality constraint of an entity in a ternary relationship is defined by a pair of two entity instances associated with the other single entity instance. For example, in a ternary relationship R(X, Y, Z) of cardinality M:N:1, for each pair of (X, Y) there is only one instance of Z; for each pair of (X, Z) there are N instances of Y; for each pair of (Y, Z) there are M instances of X."
Und in der Conclusion: "Ternary relationships are an established and accepted construct within the realm of (N-ary) conceptual modeling. However, very little research has been completed which investigates the logical complexity of the construct, particularly when combined with additional, internal constraints, which are termed SCB relationships. There is a valid question of whether ternary constructs, which have been semantically constrained, have fully equivalent binary decompositions. We have shown in this paper, that logical (fully equivalent) decompositions do exist for certain combinations of ternary / binary cardinalities, but the majority do not have fully (logical and practical) equivalents."
Ich hoffe sehr dass dies nun zum Verständnis beiträgt.
Ich sende dir freundliche Grüsse, --
JohnTB 09:34, 5. Mai 2010 (CEST)

---

Lieber John,
Dank für Deine Belehrung! Noch mehr Dank für die Literaturhinweise. Im Artikel von Jones und Song wird akribisch untersucht, unter welchen Bedingungen ternäre Relationshiptypes ohne Informationsverlust in drei binäre Relationshiptypes ersetzt werden können. Dass dies nicht immer möglich ist, ist seit langem bekannt. So haben bereits in den 80er Jahren Schlageter und Stucky in ihrem Buch Datenbanksysteme auf diesen Umstand aufmerksam gemacht. Dies ist jedoch nicht unser Diskussionsgegenstand. Die Frage ist vielmehr, ob wir in der ER-Modellierungswelt ohne höhergradige Relationshiptypes - also nur mit binären Relationshiptypes - auskommen. Ich will dies an einem Beispiel verdeutlichen: Seien A, B und C Entitytypes zwischen denen ein ternärer Relationshiptype R3 existiert. Dann untersuchen Jones und Song,, ob die drei binären Relationshiptype A-B, B-C und C-D (im ER-Diagramm wäre dies dann ein Dreiecksstruktur) den ternären Relationshiptype R3 ersetzen können. Dies ist etwas anderes als die Frage, ob nicht unter Einführung eines neuen Entitytypes - nennen wir ihn ABC - und Definition von drei binären Relationshiptypes jeweils zwischen den drei Entitytypes A, B, C und dem Entititype ABC, also A-ABC, B-ABC und C-ABC (im ER-Diagramm wäre dies dann eine Y-Struktur mit dem Entititype ABC im Zentrum) ein hinreichender Ersatz für den ternären Relationshiptype R3 sind. Am konkreten Beispiel heißt dies: Haben wir die drei Entitytypes Produkt, Lieferant und Kunde und einen ternären Relationshiptype „Lieferant liefert Produkt an Kunde“, dann sind die drei binären Relationshiptypes zwischen Lieferant und Produkt, zwischen Produkt und Kunde und zwischen Kunde und Lieferant etwas ganz anders als das folgende Szenario. Anstelle des ternären Relationshiptypes „liefert“ führen wir einen neuen Entitytype „Lieferung“ ein und definieren drei binäre Relationshiptypes zwischen Lieferung und Lieferant, zwischen Lieferung und Produkt und zwischen Lieferung und Kunde.
Könnte es nicht sein, dass Dir dieser nicht ganz unwichtige Unterschied entgangen ist?
Kurzum: So wie wir in der Sprache über das Verb (hier liefert) und das substantiviertem Verb (hier Lieferung) verfügen können, so liegt es im Ermessen des Modellierers, ob er einen mehr oder weniger komplexen Relationshiptype oder einen Entitytype bei der Modellierung heranzieht.
Der Artikel von Jones und Song enthält (für mich erstmals ersichtlich) eine Definition der Kardinalitäten bei höhergradigen Relationshiptypes auf Basis beteiligter Entitäten. Die Definition der Kardinalitäten im Artikel über ER-Modellierung ist unvollständig, da sie sich dort nur auf binäre Relationshiptypes beschränkt. Sie müsste verallgemeinert werden. Ich schlage vor, dass wir uns gemeinsam Gedanken ueber eine korrekte und vollständige Formulierung machen.
Ich grüße Dich freundlich tzeh 15:39, 12. Mai 2010 (CEST)

---

Hallo Thomas, bei der verlustfreien Zerlegung geht es um die Erhaltung der funktionalen Abhängigkeiten, welche durch die Constraints definiert werden (vgl. Artikel von Jones und Song! vgl. meine gesammelten Postings seit 2008). Bisher hat hier niemand erklärt wie das gehen soll (und schon gar nicht belegt). Auch in deinem letzten Posting gehst du darauf mit keinem Wort ein. Ich habe 2008 einen Vorschlag gemacht (damals bereits unter Einbeziehung eines zusätzlichen Entitytyps - das ist mir also nicht entgangen. Wenn es nur drum ginge die verlustfreie Zerlegung ohne zusätzlichen Entitytyp zu diskutieren, müsste ich keinen Vorschlag machen, sondern könnte einfach auf die Lehrbücher oder Jones und Song verweisen). Mein Vorschlag war aber leider falsch. Elmasri/Navathe schlagen vor, einen schwachen Entitytyp mit drei identifizierenden Beziehungstypen statt des ternären Beziehungstyps zu verwenden (vgl. mein Posting von 2008)- gehen aber leider nicht darauf ein, wie man vorgeht wenn es constraints gibt. Ohne constraints klappt das auch wunderbar. In meinem Posting vom 22.4 habe ich auch erklärt wie man diesen Trick sogar erweitern kann, um eine funktionale Abhängigkeit mit abzubilden. Leider klappt das nicht mit mehreren FAs. Wenn man also versucht auf der Basis der Chen-Notation mehrstellige Beziehungstypen in binäre zu überführen dann hat man u.U. einen semantischen Verlust. Ich bin mir noch nicht ganz sicher, ob man nicht unter Verwendung der Min-Max-Notation eine verlustfreie Dekomposition zustande bringt. Wie allgemein bekannt, werden bei der Min-Max-Notation Beziehungen statt Entities gezählt, was einen fundamentalen Unterschied darstellt. Vielleicht kannst Du mir ja erklären wie es geht. Den Rest schlucke ich runter weils nichts mehr zur Sache tut ... freundliche Grüße, JohnTB 23:29, 12. Mai 2010 (CEST)

Nachtrag:
Hallo Thomas, Ich machs dir leicht. Ich gebe ein Beispiel vor, und Du brauchst mir nur noch zu sagen was ich tun muss um die constraints zu erhalten. Vereine (V) belegen an verschiedenen Spieltagen (S) verschiedene Tabellenpositionen (T). An EINEM Spieltag belegt EIN Verein immer nur EINE Tabellenposition (VxS -> T); An EINEM Spieltag wird EINE Tabellenposition immer nur von EINEM Verein belegt (SxT -> V); EIN Verein kann EINE Tabellenposition an verschiedenen Spieltagen belegen (Keine Einschränkung). Die impliziten binären Beziehungen zwischen je zwei Entitytypen sind immer n:m. Statt des ternären 1:1:N-Beziehungstyps, den wir hier haben, verwenden wir einen Entitytyp E zur Simulation der ternären Beziehung. Dann haben wir drei binäre Beziehungen RS, RV und RT. Jetzt geht es darum die Kardinalitäten zu bestimmen.
Ich mache es dir noch leichter und gebe dir bereits vor was wir schon sicher sagen können. Um sicherzustellen, dass jede Beziehungsinstanz des simulierten ternären Beziehungstyps genau einen Verein und eine Tabellenposition und einen Spieltag betrifft muss für jedes E-Entity schon mal gelten dass es an jeweils genau einer Beziehung von RS, RT und RV partizipiert (Das haben wir in meinem früheren Beispiel durch den schwachen Entitytyp erreicht). Wir haben also jetzt mit Min-Max folgende Situation:
S -(?:?)-<>-(1,1)-E
V -(?:?)-<>-(1,1)-E
T -(?:?)-<>-(1,1)-E
Die unteren Grenzen spielen keine Rolle, weil es da nur um die totale Teilnahme geht und nicht um die funktionalen Abhängigkeiten. Weil wir nicht wissen wie weit die Saison fortgeschritten ist und wir diesbezüglich auch nichts definiert haben können wir da also sicher 0 reinschreiben. Jetzt haben wir:
S -(0:?)-<>-(1,1)-E
V -(0:?)-<>-(1,1)-E
T -(0:?)-<>-(1,1)-E
Jetzt fragen wir uns an wievielen Beziehungen denn ein Verein am Ende der Saison teilnimmt. Sicher mehr als eine, denn sonst hätte ein Verein auch nur eine Tabellenposition und einen Spieltag - Mit einer 1 würden wir also spezifizieren: V-> SxT! Das ist aber nicht das was wir wollen. Das gleiche gilt für alle anderen Entitytypen. Es bleibt nur noch N. Also haben wir jetzt:
S -(0:N)-<>-(1,1)-E
V -(0:N)-<>-(1,1)-E
T -(0:N)-<>-(1,1)-E
Jetzt haben wir die Constraints die wir wollen leider nicht in unserem Modell - Welchen Trick kennst Du jetzt noch um sie reinzubekommen? Freundliche Grüße, JohnTB 08:57, 13. Mai 2010 (CEST)

---

Lieber John,
zu Deinem Beispiel darf ich Dein Augenmerk auf den folgenden Passus des Artikels über die Min-Max-Notation lenken. Dort findest Du folgende Aussage, die - so meine ich - Dein Problem lösen kann. „Die Ausdrucksstärke der Min-Max-Notation ist nicht mit der Chen-Notation (bzw. Multiplizitätsangaben in UML) vergleichbar, d.h. keine Notation subsumiert die jeweils andere. Es gibt für beide Notationen Konsistenzbedingungen, die sich in der jeweils anderen Notation nicht ausdrücken lassen.“
Du schreibst in einem Deiner Beiträge „Bei der verlustfreien Zerlegung geht es um die Erhaltung der funktionalen Abhängigkeiten.“ Diese Forderung mag dort berechtigt sein, wo Funktionale Abhängigkeiten der Art A,B → C (allgemein bei n-ären Relationen: n-1 Merkmale bestimmen das n. Merkmal) unterstützt werden. Diese von Dir jedoch allgemein gültig formulierte Aussage (also für jegliche Art von Funktionaler Abhängigkeit) gilt nicht für die Min-Max-Notation, da dort die Kardinalitätsangaben eine andere Bedeutung haben. Dort können mittels Kardinalitätsangaben Funktionale Abhängigkeiten der Art A → B,C unterstützt werden (allgemein bei n-ären Relationen: genau ein. Merkmal bestimmt die n-1 anderen Merkmale; das eine Merkmal hat somit identifizierenden Charakter ).
In Deinem Beispiel forderst Du jedoch eine spezielle Konsistenzbedingung, nämlich eine Funktionale Abhängigkeit der Art A,B → C, und dies dargestellt in der Min-Max-Notationsform. Dies ist bei höhergradigen Relationshiptypes schlicht nicht möglich.
Ich darf Dir die verlustfreie Zerlegung auf Basis der Min-Max-Notationsform anhand eines einfachen Beispiels demonstrieren. Nehmen wir folgende Datensituation (Produkt, Hersteller, Kunde) an:
Konsistenzbedingung: Jedes Produkt wird von genau einem Hersteller für genau einen Kunden angefertigt. Es handelt sich somit um Sonderanfertigungen.
Entitätstypen und Ausprägungen:
Produkt: P1, P2, P3, P4
Hersteller: H1, H2, H3, H4 und
Kunde: K1, K2
Relationshiptype und Ausprägungen:
Produkt P wird vom Hersteller H für Kunde K angefertigt (P-H-K).
P1-H1-K1
P2-H2-K2
P3-H1-K1
P4-H3-K2
Kardinalitätsangaben an den drei Entitätstypen (für genau diesen also statischen Datenbestand)
P (1,1) ← hierin steckt die Konsistenzbedingung P → H,K
H (0,2)
K (2,2)
Nach der Zerlegung haben wir folgendes ER-Modell mit dem weiteren Entitätstyp Anfertigung A und den drei binäre Relationshiptypes:
P-A
H-A
K-A
mit den gleichen Kardinalitätsangaben an den drei alten Entitätstypen P,H,K und dem einen neuen Entitätstyp A (dort immer (1,1):
P (1,1) <> (1,1)-A
H (0,2) <> (1,1)-A
K (2,2) <> (1,1)-A
Kurzum: Liegt ein ER-Modell in der Min-Max-Notationsform vor, dann kann jeder höhergradige Relationshiptype verlustfrei in binäre Relationshiptypes (unter Einführung eines weiteren Entitytypes) zerlegt werden. Zuvor existierende Kardinalitätsangaben bleiben bei der Zerlegung erhalten, wenn (zuvor und danach) die Min-Max-Notationsform verwendet wird. Du siehst: die verlustfreie Zerlegung „klappt“ mit durch Kardinalitätsangaben ausgedrückten Konsistenzbedingungen, auch wenn nur relativ wenige aus dem Spektrum der Konsistenzbedingungen möglichen Kardinalitätsangaben in der jeweiligen (aber gleichbleibenden!) Notationsform dafür verwendet werden können.
Ich grüße Dich freundlich. Thomas tzeh 10:28, 19. Mai 2010 (CEST)

---

Lieber Thomas, ein konstruktiver Dialog ist nur möglich wenn jeder das auch liest und versteht was der andere schreibt. Du versuchst mich hier ein ums andere Mal zu korrigieren, ohne verstanden zu haben worum es hier eigentlich geht. Bitte lies doch mal den ganzen Thread hier von vorne bis hinten durch. Und bitte lies GENAU was ich schreibe. Und bitte geh endlich davon aus, dass ich ein Experte auf diesem Gebiet bin, der genau weiss was er sagt. Wir haben einen ternären Beziehungstyp mit 1:1:N Constraints (CHEN NOTATION!!!!!!! HALLO!!!!!!- Die FAs, die ich beschreibe sind nur in CHEN-NOTATION darstellbar!). Ich behaupte diesen ternären Beziehungstyp kann man nicht verlustfrei in binäre Beziehungstypen zerlegen auch wenn man bei der Zerlegung die Min-Max-Notation verwendet (MIR IST VÖLLIG KLAR DASS DIE MIN-MAX-NOTATION ANDERS DEFINIERT IST UND DAS HABE ICH VORSORGLICH IN MEINEM LETZTEN POSTING AUCH ERWÄHNT).
STOCKSAUER!!!!!!!!!!
JohnTB 11:48, 19. Mai 2010 (CEST)
Nachtrag: Allerletzter Versuch: Bitte nimm MEIN BEISPIEL von vorher (Verein, Tabellenposition, Spieltag). Die Constraints, die ich definiere sind mit einem ternären Beziehungstyp in Chen-Notation darstellbar. Bitte gib mir für DIESES Beispiel eine verlustfreie Zerlegung an (Egal in welcher Notation). Ich behaupte es gibt keine. Wenn es keine gibt, dann kann man nicht behaupten jeder ternäre Beziehungstyp sei verlustfrei zerlegbar. Darum und nur darum geht es hier.
Ich hoffe dass Du nun verstehst, dass man nicht im Artikel behaupten kann JEDER ternäre Beziehungstyp sei VERLUSTFREI zerlegbar. Wenn nicht, dann möchte ich die Diskussion lieber abbrechen - in dem Fall wünsche ich dir alles Gute.
JohnTB 12:22, 19. Mai 2010 (CEST)

---

Lieber John, Deinem einleitenden Satz stimme ich uneingeschränkt zu.
Zur Sache: Du hast recht, wenn Du behauptest, dass in der Min-Max-Notation die in Deinem Beispiel genannte FA vom Typ A,B → C nicht darstellbar ist. Just dies habe ich Dir in meinem letzten Beitrag bereits bestätigt. Ich zitiere mich selbst nur ungern, aber damit Du erkennst, wo und wie ich dies tat, hier nochmals meine zustimmende Aussage: „In Deinem Beispiel forderst Du jedoch eine spezielle Konsistenzbedingung, nämlich eine Funktionale Abhängigkeit der Art A,B → C, und dies dargestellt in der Min-Max-Notationsform. Dies ist bei höhergradigen Relationshiptypes schlicht nicht möglich.“
Damit stimme ich auch Deinem 3. und vor allem 4. Satz Deines letzten Beitrags - auf gegenseitiger Basis - zu.  ;-))
Ich denke inzwischen , dass wir gar nicht soweit auseinander sind. Du schreibst: „Wir haben einen ternären Beziehungstyp mit 1:1:N Constraints (CHEN NOTATION!!!!!!! HALLO!!!!!!- Die FAs, die ich beschreibe sind nur in CHEN-NOTATION darstellbar!). Ich behaupte diesen ternären Beziehungstyp kann man nicht verlustfrei in binäre Beziehungstypen zerlegen auch wenn man bei der Zerlegung die Min-Max-Notation verwendet .“ Diese Aussagen sind korrekt und wurden von mir auch nicht bezweifelt (lediglich mit den vielen Ausrufezeichen und dem HALLO kann ich nichts anfangen) . Insofern brauche ich auch nicht weiter auf Dein Beispiel eingehen, da Du ja damit Deine Aussagen (auch für mich) hinreichend belegt hast.
Konstruktiver Ansatz: Du hast also recht, dass es bestimmte in Chen-Notation formuliert Konsistenzbedingungen gibt, die bei der Zerlegung verloren gehen. Ich bin Deinen im 3. und 4. Satz aufgeführten Aufforderungen nachgekommen und habe mir vor allem den strittige Passus im Artikel unter der Historie näher angeschaut. In der Version vom 6.3.2010 lautet er: „Ternäre und höhergradige Beziehungstypen lassen sich immer auf binäre Beziehungstypen durch Einführung eines neuen Entitätstyps, der den ursprünglichen Beziehungstyp beschreibt, zurückführen. Insofern kann auf die Verwendung (expliziter) höhergradiger Beziehungstypen im ER-Modell vollständig verzichtet werden.“ Hier muss ich Dir nochmals recht geben, er ist in seiner absoluten Formulierung mit den Termen „immer“ und „vollständig“ nicht korrekt, nämlich dann, wenn „immer“ interpretiert wird als „für alle Notationsformen geltend“. Ich denke, dass dieser mir bisher nicht bewusste Umstand die eigentliche Ursache für unsere Kommunikationsschwierigkeiten ist. Wenn Du das auch so siehst, dann bitte ich Dich in aller Form um Entschuldigung für meine Fehlinterpretation.
Wenn Du unter diesen Umständen jetzt noch bereit bist, mit mir zu diskutieren, dann schlage ich Folgendes vor: Wegen seiner absoluten und daher nicht korrekten Formulierung ist der obige Passus zu relativieren, da es offensichtlich von der Notationsform abhängt, ob die Zerlegung verlustfrei ist oder nicht. Was hältst Du von folgende Formulierung als Ersatz für den obigen Passus?
„Ternäre und höhergradige Beziehungstypen lassen sich auf binäre Beziehungstypen durch Einführung eines neuen Entitätstyps, der den ursprünglichen Beziehungstyp beschreibt, zurückführen. Der Erhalt der Kardinalitätsangaben ist jedoch abhängig von der gewählten Notationsform; wenn die Kardinalitäten in der Chen-Notation formuliert sind, können sie bei der Transformation verloren gehen, während die in der Min-Max-Notation beschriebenen Kardinalitätsangaben erhalten bleiben.“
Den letzten Sachverhalt habe ich versucht, durch mein Beispiel zu verifizieren. Die Allgemeingültigkeit sollten wir sicherheitshalber noch prüfen.
Da es mir darum geht, den für die Praxis überaus wichtigen Umstand festzuhalten, dass man bei der Modellierung mit binären Beziehungstypen auskommt, was einige Werkzeuge auch voraussetzen, möchte ich den Passus mit der folgenden Aussage abschließen: „Insofern kann, wenn die Min-Max-Notation gewählt wird, auf (explizite) höhergradige Beziehungstypen im ER-Modell verzichtet werden.

Ich hoffe, das Du meine Entschuldigung annimmst und weiter, dass durch diese Ausführungen Dein pH-Wert wieder normal ist.
Ich wünsche Dir frohe Pfingsten und grüße Dich freundlich Thomas tzeh 13:12, 23. Mai 2010 (CEST)

---

Hallo Thomas, Deine Entschuldigung nehme ich an. Vielen Dank. Zur Erläuterung für das "HALLO": "In Deinem Beispiel forderst Du jedoch eine spezielle Konsistenzbedingung, nämlich eine Funktionale Abhängigkeit der Art A,B → C, und dies dargestellt in der Min-Max-Notationsform" WO BITTE HÄTTE ICH GEFORDERT DAS MAN DAS IN MIN-MAX-NOTATION DARSTELLEN SOLL?.

(Einschub von tzeh: In Deinem Beitrag vom 13.5.2010, wo Du schreibst. "Wir haben also jetzt mit Min-Max folgende Situation:" Ende des Einschubs von tzeh, 30.05.2010)

Das hast Du so misverstanden. Du hast erkannt, dass das nicht sein kann, aber statt bei mir nachzufragen wie es gemeint ist unterstellst du mir einen Fehler. Wir diskutieren hier seit 2008 drüber was die Kardinalitäten in Chen Notation bedeuten. Natürlich geht es die ganze Zeit darum wie ich FAs dieser Art bei der Zerlegung erhalten kann. Sicherheitshalber habe ich dir ein Beispiel vorgegeben, damit du auch ganz sicher verstehst was ich meine. Wenn ich von FAs der Form A,B--> C rede dann ist doch wohl klar dass wir hier von ternären Beziehungstypen in der Chen Notation reden. Tut mir sehr leid, Thomas- aber für mich ist das hier zu anstrengend. Ich wollte hier nur einen Fehler korrigieren, mehr nicht. Ich ziehe mich lieber zurück. Da die Misverständnisse nun auch weitgehend ausgeräumt sind werde ich wohl auch nicht mehr gebraucht.
Nur noch eine Anmerkung: Ich würde die Notation, ob Chen, oder Min-Max erst dann wählen wenn ich weiss welche Constraints in meinem realen Szenario tatsächlich vorkommen und welche mir wichtig sind. Wenn es da ternäre Beziehungen gibt mit FAs der Form A,B->C, dann nehme ich halt die Chen Notation. Es gibt sogar Leute die beide Notationen kombinieren um Ausdrucksmächtigkeit zu gewinnen. Bei einem a-priori Verzicht auf die Chen-Notationm und auf ternäre Beziehungen verliert man Ausdrucksmächtigkeit. Alles Gute. JohnTB 23:06, 25. Mai 2010 (CEST)

(Einschub von tzeh: In Deinem Beitrag vom 13.5.2010, wo Du schreibst. "Wir haben also jetzt mit Min-Max folgende Situation:" Ende des Einschubs von tzeh, 30.05.2010)

ES IST WIRKLICH UNGLAUBLICH! NACH DEM DOPPELPUNKT FOLGT DIE ZERLEGUNG IN BINÄRE BEZIEHUNGSTYPEN AUF DER BASIS DER MIN-MAX NOTATION. DER SATZ IST ABSOLUT KORREKT. ICH ZEIGE DASS DIESE ZERLEGUNG NICHT VERLUSTFREI IST. Ich habe einen ternären 1:1:N Beziehungstyp (CHEN), den ich versuche mit MIN-MAX in binäre Beziehungstypen zu zerlegen. Ist das so schwer zu verstehen? Vorher habe ich bereits gezeigt, dass auch die Zerlegung in Chen-Notation verlustbehaftet ist. Verstehst du wenigstens warum das hier unglaublich nervenaufreibend für mich ist. Ein konstruktiver Dialog ist auf dieser Basis wirklich nicht möglich. Nichts für ungut. JohnTB 09:51, 31. Mai 2010 (CEST)

Bezeichnung Deutsch/Englisch

Guten Tag ihr DB-Cracks!

Ich habe mich soeben beim Verfassen einer Arbeit gefragt, ob der Name Entity-Relationship-Modell wirlich korrekt ist, oder sich da ein Deutsches Wort eingeschlichen hat: Modell. Meiner Meinung (und der des Übersetzungstools) nach, schreibt sich im Englischen Modell mit nur einem l. Da es sich beim Ausdruck Entity-Relationship-Modell doch offensichtlich um einen englischen Begriff handelt, müsste es also Entity-Relationship-Model heissen (auch ER-Model etc.). Erst die Eindeutschung in der Einleitung wäre dann Korrekt mit 2 l!

Sonst ist der Artikel super informativ!

Fippu

Anzahl beteiligter Einzelobjekte bei einer Beziehung

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)

Lieber Anonymus, Dein Einwand ist berechtigt (z.B.: Angestelter Müller arbeitet an Projekt 3232 in der Rolle des Qualitätssicherungsbeauftragten). Daher habe ich dies entsprechend im Artikel korrigiert. Allerdings gilt aber auch, dass sich jeder Beziehungstyp mit mehr als 2 beteilgten Entitätstypen auf binäre Beziehungstypen reduzieren läßt, was im Artikel auch beschreiben ist. Ich grüße Dich freundlich

Modellierung von Relationship-Attributen per UML ?

Attribute von Entitäten kann man statt mit Ellipsen in der Chen-Notation mit Einträgen im zweiten Feld von Klassen in der UML modellieren - aber wie kann man Attribute von Relationen in der UML darstellen? Weiß hier jemand bescheid? Gibt es da Vorschläge/Einigungen/gar nichts ...? 217.236.223.130 01:14, 15. Okt. 2008 (CEST)

In UML gibt es ja keine Unterscheidung Entity<-->Relationship. Ebensowenig wie im Relationenmodell. Genau so, wie du ein ERM ins Realtionenmodell(also in "Tabellen") umsetzt, so lassen sich diese auch in Klassen umsetzen. Und zwar vollkommen analog. Entweder als eigene Klasse oder als Attribut(e) in einem Eintity bzw. in einer Klasse. Eine Umsetzung 1:1 ohne Informationsverlust ist also in den wenigsten Fällen möglich. Weder in die eine noch in die andere Richtung. UML bzw. genauer: UML-Klassendiagramme und ERM haben eben verschiedene Zielsetzungen und mögen zwar auf den ersten Blick recht ähnlich aussehen, sind aber gar nicht als äquivalente Alternativen gedacht.

Aber bevor du gleich ganz aufgibst: Es gibt in UML etwas, was dem, was du willst, sehr nahe kommt: Assoziationsklassen. Leider gibts da noch keinen Artikel dazu(vielleicht änder ich das mal). Im Prinzip modellierst du eine Klasse für die Assoziation, die mit einer gestrichelten Linie mit dieser verbunden ist. Da sich sowas aber nicht direkt implementieren lässt, muss das letztendlich(d.h. im Entwurf) auch wieder wie oben beschrieben umgesetzt werden. Das ist also eher eine Notation für die Analysephase. -- Der Hâkawâti ✉ 09:05, 15. Okt. 2008 (CEST)

Natürlich gibt es keine direkte Unterscheidung Entity-Relationship in der UML bzw. keine direkte Entsprechung ... es geht mir einfach darum, die Grundidee, die hinter der ER-Modellierung steht, mit der UML-Notation auszudrücken – ebenso wie man Flowcharts und Petrinetze in Aktivitätsdiagramme überführen kann – ganz einfach um bei einer Notation zu bleiben, wenn es nicht anders erforderlich ist.

Danke für den Tipp. Die Assoziationsklassen sind offensichtlich eine verwendete Lösung – in folgendem Paper von IBM habe ich gefunden was ich suchte:

Entity Relationship Modeling with UML

mfg, 217.236.213.20 10:47, 15. Okt. 2008 (CEST)

Genau das hab ich gemeint. Den entsprechenden Artikel hab ich jetzt auch verfasst und hier verlinkt. So sollte klarer werden, was gemeint ist.-- Der Hâkawâti ✉ 17:35, 15. Okt. 2008 (CEST)

"part-of" Beziehung

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)

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)

Entsprechungen im Relationenmodell

In der Auflistung unter "Begriffe" hatte ich die Äquivalente des Relationenmodells an einigen Stellen dazu geschrieben. Dies wurde wieder entfernt, mit einer Begründung, die offenbar länger war als es Mediawiki speichern wollte. Also warum nochmal dürfen diese Angaben da nicht stehen? --Bernd vdB 11:53, 19. Nov. 2008 (CET)

Hallo Bernd, der Umstand, dass das konzeptionelle Datenmodell nicht selten in ein Datenbankdesign (ob für eine relationale DB oder eine andere) überführt wird bzw. dazu genutzt wird, steht bereits im Folgesatz. Auch hat der Verwendungszweck meiner Meinung nach im ersten, die wesentlichen Charakteristika des ERM beschreibenden Definitionsteil nichts zu suchen. Auch der Umstand, dass Entitäten und Attribute beim DB-Design in Tabellen und Spalten (beim Design in eine rel. DB) übergehen, steht bereits ausführlich am Ende des Artikel im Abschnitt Überführung in ein relationales Modell. Diese beiden Aspekte gehören meiner Meinung nach auch nicht in den Definitionsteil von Entität und Attribut. Auch werden hierbei die Prozesse Konzeption (durch ERM) und Implementierung (Erstellung des Datenbankschemas) vermengt, was in der Praxis bedauerlicherweise häufig auftritt, aber nach ordentlicher Ingenieurskunst (und SW-Engineering hat diesen Anspruch) tunlichst zu vermeiden ist.

Ich grüße Dich freundlich tzeh 13:37, 19. Nov. 2008 (CET)

Hallo, dieser thread bezog sich erstmal nur auf die Frage zu dem Kapitel Begriffe, nicht auf die Einleitung. Lass uns das bitte nun auch trennen.

• Zur Einleitung: Hier hatte ich versehentlich den alten Absatz stehen lassen. Der Satz "Es wird überwiegend zur Modellierung relationaler Datenbank eingesetzt." gehört da aber herein; habe ich nun mit zwei Worten in den vorhandenen hinzugesetzt. Falls du das nicht richtig findest, bitte erklären, für welche anderen DB es deiner Meinung nach genutzt werde.
• Zu den Begriffen: Es ist für das Verständnis des Modells sehr hilfreich, wenn der Bezug zu den (eher bekannten) Begriffen des Relationenmodells in dem jeweiligen Absatz hergestellt werden. WP ist keine Ansammlung von Fachlexika, sondern ein Universallexikon. Gruß --Bernd vdB 17:54, 19. Nov. 2008 (CET)

Hallo Bernd,

• Zur Einleitung: Die Formulierung "Grundlage für das Design der - überwiegend relationalen - Datenbank." ist zutreffend.
• Zu den Begriffen des Relationenmodells bzw. der relationalen Datenbanken bei der Einführung der Begriffe Entität und Attribut: Der Artikel heißt "Entity-Relationship-Modell"; da geht es um Entitäten, Beziehungen und Attribute. Die mögliche Abbildung des ER-Modells auf das Schema einer relationalen Datenbank ist ein Nebenaspekt, und da muss ich auf meinen bereits aufgeführten obigen Einwand - insbesondere auf die Trennung von Konzeption und Implemnetierung - hinweisen.

Ich grüße Dich freundlich tzeh 14:07, 20. Nov. 2008 (CET)

Die "mögliche" Abbildung des ER-Modells ist, wie du zum ersten Aspekt richtig schreibst, ja nun kein "Nebenaspekt", sondern die typische, hauptsächliche Anwendung. Daher ist es auch sinnvoll und für eine Enzyklopädie IMHO notwendig, den Begriffen des einen die des anderen zuzuordnen.

Das kann man gerne auch woanders machen, zB in dem Abschnitt "Überführung in ein relationales Modell", wo es bisher nicht stattfindet und der jetzt mehr nach Mathebuch aussieht. Das mit dem Univerallexikon hatte ich schon erwähnt? - Also, wo sollte die Zuordnung der Begriffe deiner Meinung nach hin? --Bernd vdB 19:22, 21. Nov. 2008 (CET)

Hallo,

ich finde die jetztige Formulierung garnicht so schlecht. Sie ist formal korrekt und wie ich finde verständlich. Eine Gegenüberstellung der Begriffe gibt es auch hier Relationale Datenbank. Eine Wiederholung hier kann aber nichts schaden. Gruss -- sparti 21:05, 21. Nov. 2008 (CET)

Hallo Bernd, hallo Sparti,

Wenn die Gegenüberstellung der Begriffe bzw. deren Abbildung von Euch aus Verständlichkeitsgründen mehrfach - so auch hier im Artikel über ER-Modell - als zweckmäßig erachtet wird, dann sollten wir dies m.E. keinesfalls im Definitionsteil tun, sondern - wie von Bernd als Alternative vorgeschlagen - in der Einleitung vom Abschnitt "Überführung in ein relationales Modell"; sinngemäß in der Form: "Die Überführung des ER-Modells in das Relationen-Modell basiert i.w. auf den folgenden Abbildungen:

Entitätstyp --> Relation, Beziehungstyp --> Fremdschlüssel, Attribut --> Attribut.

Die genaue Überführung, die automatisiert werden kann, erfolgt in 7 Schritten:..."

Ich grüße Euch freundlich tzeh 14:01, 22. Nov. 2008 (CET)

Gute Lösung, tzeh - schreibst du das herein (vielleicht als ul-Liste)? --Bernd vdB 23:03, 23. Nov. 2008 (CET)

Hat er nun gemacht, habe mir erlaubt, das als Liste zu formatieren und als "erste Phase" zu bezeichnen.

Noch ein Punkt: Der Entitätstyp wird IMHO in eine _Tabelle_, nicht eine Relation (wie es jetzt heisst) umgesetzt; andernfalls wir einen Zirkelschluss anlegen - denn dann wäre die Frage, warum diese Relation (von Tabellen) nicht mit dem ER-Modell beschreibbar sei. Ok, das zu ändern? --Bernd vdB 17:07, 24. Nov. 2008 (CET)

Hallo Bernd, ich habe den Eindruck, dass hier eine Verwechselung vorliegt. Eine Relation ist keine Beziehung (von Tabellen) sondern die mathematische Definition einer Tabelle. Gruss -- sparti 17:56, 24. Nov. 2008 (CET)

Fein, dann sollte man gleich "Tabelle" hinschreiben - denn im Zweifel sollte die verständliche Formulierung vorrang vor derjenigen der Mathematik haben. Ok? --Bernd vdB 18:30, 25. Nov. 2008 (CET)

Hallo Bernd, Im Relationenmodell spricht man von Relationen, nicht von Tabellen. Tabelle ist ein Begriff aus der Welt der Relationalen Datenbanken, deren Tabellen aus den Relationen gebildet werden können. Daher bitte die jeweiligen Begriffe dort, wo sie verwendet werden. Da die Überschrift "Überführung in ein relationales Modell" heißt, ist hier Relation angebracht (habe dies auch in meiner obigen mail vom 22.Nov. korrigiert). Ich grüße Dich freundlich tzeh 17:01, 25. Nov. 2008 (CET)

Tja, dann muss es wohl stehen bleiben.

Im Ergebnis finde ich aber diesen Artikel nun ein eher schlechtes Beispiel für einen Lexikon-Artikel. Anders gesagt, er ist ein typisches und trauriges Beispiel geworden, wie man mit Fachsprache eine eigentlich zur Vereinfachung entworfene Sache (das ERM-Modell) als reine Verumständlichungsformel erscheinen lassen kann. Habe keine Zeit, das hier weiter auszufechten, also lassen wir die Mathematik weiter in ihrem Sud schwimmen ... --Bernd vdB 20:44, 25. Nov. 2008 (CET)

Hmm, ich hatte garnicht den Eindruck, dass hier gefochten wurde. Ich finde Deinen Einwand nachvollziehbar auf der anderen Seite geht es Thomas nur darum, daß alles korrekt dargestellt wird. Es wäre aber doch schön, wenn wir beiden Anforderungen gerecht werden könnten. In diesem Falle bräuchten wir ein Kapitel "Überführung in ein relationales Datenbankschema". Dann darf man auch über Tabellen reden. Gruss -- sparti 13:58, 26. Nov. 2008 (CET)

n-äre Beziehungen und deren Aufspaltung in n binäre Beziehungen

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)

Begriffe

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)

Standard

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)

Relation für Beziehung? Zutreffender Ersatz bei der ER-Modellierung?

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)

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)

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)

Zu Zweck und Entstehung der ER-Modellierung und zu Spezialisierung, Generalisierung, Aggregation

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)

-- Erläuterung zur letzten Änderung Text vorher: "Kardinalität: mögliche Anzahl der an einer Beziehung beteiligten Entitäten". Das ist leider falsch. Bei einem binären Beziehungstyp sind das immer genau 2. Hans arbeitet in Abteilung 123. Das ist eine Beziehung (Instanz), und sie verbindet genau zwei Entities, nämlich von jedem der beteiligten Entititypen genau eins. Das hat nichts mit der Kardinalität zu tun, sondern mit dem Grad des Beziehungstyps. Jede Ausprägung eines Beziehungstyps vom Grad n verbindet exakt genau n Entities miteinander. Text neu: "Die Kardinalität eines Beziehungstyps legt fest an wievielen Beziehungen (ggf. mehrere) ein Entity teilnehmen kann"

Rechtschreibfehler

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) Ist mir auch gerade aufgefallen. Wäre gut! --88.74.19.41 (18:29, 4. Nov. 2010 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Gegenstands-Beziehungs-Modell als deutsche Bezeichnung für das Entity-Relationship-Modell

Lieber Shahrzad, Du hast die obige deutsche Bezeichnung abgelehnt und meine Wiederherstellung mit "was soll der Unsinn?" kommentiert. Was hälst Du davon, wenn Du Dich zunächst in der Literatur etwas umsiehst und Deinen Umgangston mäßigst?
Ich grüße Dich freundlich tzeh 18:10, 16. Okt. 2009 (CET)

Es hat nichts mit Umgangston zu tun, wenn man etwas als "Unsinn" bezeichnet. Es ist allenfalls ein Zeichen von schlechten, allerdings sehr weit verbreiten Umgangsformen, das als schlechten Umgangston zu bezeichnen. Unsinn wird auch nicht dadurch zum Sinn, daß einer vom anderen abschreibt. Man müsste also erstmal den Nachweis führen, daß irgendjemand das so bezeichnet hat, bevor es WP tat. Aber insgesamt ist mir das zu albern. Meinen Segen hast du. --Shahrzad 18:28, 16. Okt. 2010 (CEST)

Ich glaube, man darf HIER sachliche Diskussionen erwarten. Die Bezeichnung ERM ist wohl allgemeingültig so bekannt, dass das 'Eindeutschen' wirklich keinen Sinn macht. --VÖRBY 08:04, 17. Okt. 2010 (CEST)

Dem kann ich nur zustimmen. Sachlich, d.h. an der Sache diskutieren. Und wenn etwas "keinen Sinn macht", ist es eben "Unsinn". --Shahrzad 11:40, 17. Okt. 2010 (CEST)

Du, VÖRBY, schreibst: „Die Bezeichnung ERM ist wohl allgemeingültig so bekannt, dass das 'Eindeutschen' wirklich keinen Sinn macht.“ Dies mag für die Informatiker und ggf. auch für die Linguisten so sein; trifft dies auch darüber hinaus für alle Leser zu? Die Aufnahme der deutschen Bezeichnung sollte nicht abhängig sein von gewissen Kenntnisständen irgendwelcher Lesergruppen. So steht bei den Grundsätzen von Wikipedia unter Verständlichkeit: „Die Wikipedia ist eine allgemeine Enzyklopädie und kein Fachbuch und sollte auch für Laien verständlich sein." und weiter, dass der Text „so allgemeinverständlich wie möglich“ sein solle.

Was die deutsche Bezeichnung des Begriffs Entity-Relationship-Modell angeht, so schreibst Du, Shahrzad: „Eine wörtliche deutsche Übersetzung ist hier völlig fehl am Platze, da Entity und Relationship Termini sind, die im Rahmen des Modells erst definiert werden.“ Die Logik in diesem Versuch einer Begründung verstehe ich überhaupt nicht. Weiterhin ist m.E. Folgendes bestimmend: Ob für den Begriff eine deutsche Bezeichnung neben der englisch-deutschen Mischbezeichnung im Artikel ihren Platz finden soll, ist ausschließlich durch die Sprachpraxis, d.h. durch die Verwendung der Begriffsbezeichner in der (hier deutschen) Sprache bestimmt. Nun ist dem so, siehe z.B. im Informatik-Lehrmaterial Datenmodellierung von Glinz, Uni Zürich, http://www.ifi.uzh.ch/req/ftp/inf_II/SS04/kapitel_02.pdf aus dem Jahr 2003 und in den Lehrbüchern Wirtschaftsinformatik Grundlagen der Wirtschaftinformatik (Seite 133) von Ferstl und Sinz und Datenbanksysteme (Seite 23) von Kemper und Eickel. Die deutsche Bezeichnung wurde im Wikipedia-Artikel erstmals am 21.4.2006 erwähnt (aufgenommen durch Benutzer 84.61.121.191 ), kann also zumindest nicht von Glinz „abgeschrieben“ worden sein.

Daher plädiere ich dafür, dass die deutsche Bezeichnung auch im Artikel erwähnt wird. Offen für mich ist, ob nicht die ebenfalls häufig in der Literatur vorkommende Schreibweise Gegenstand-Beziehung-Modell (ohne Beugungs-s) ergänzend aufgenommen werden soll. Wie seht Ihr das?

Noch eine letzte Frage zum Umgangston und zm Stil: Was bezweckst Du, Shahrzad, damit, ernsthafte Bemühungen von Wikipedia-Benutzern als "albern" abzutun und Mitarbeiter zu "segnen"?

„...wenn etwas "keinen Sinn macht", ist es eben "Unsinn"“. Diese Aussage hingegen teile ich mit Euch. Nur darf der Schluss erst gezogen werden, wenn die Voraussetzung erfüllt ist. Ich grüße Euch freundlich tzeh 22:40, 17. Okt. 2010 (CEST)

Zunächst mal zur Sache:

"'Eine wörtliche deutsche Übersetzung ist hier völlig fehl am Platze, da Entity und Relationship Termini sind, die im Rahmen des Modells erst definiert werden.' Die Logik in diesem Versuch einer Begründung verstehe ich überhaupt nicht."

Und genau da liegt das Problem, denn wenn du das nicht verstehst, verstehst du im Grunde rein gar nichts.

Trotzdem und auch für andere: Eine wörtliche Übersetzung eines zusammengesetzten Terminus schafft nur Verwirrung. Solange der Leser nicht weiß, wie der zusammengesetzte Terminus sowie die einzelnen Termini definiert sind und was damit in der realen Welt gemeint ist, wird er sie mit seinem eigenen Alltagsverständnis, mit anderen ihm bekannten Bedeutungen oder mit spekulativen Inhalten auf seinem eigenen Kenntnisstand belegen. Das ist bei einem Verständnis hinderlich. Insoweit schießt auch dein Plädoyer für den Laien voll am Ziel vorbei. Gerade im Interesse von fachlich unvorbelasteten Lesern ist es nicht sinnvoll, Begriffe zu "übersetzen". Statt dessen läuft das Verständnis in diesem Fall doch wohl so ab: Zunächst versteht der Leser (hoffentlich) warum dieses Modell benutzt wird. Vor diesem Hintergrund versteht er dann, warum eine Entity als a. als Denkmodell und b. als Begriff notwendig war, desgleichen mit der Relationship. Ab diesem Zeitpunkt kann er auf eine deutsche Übersetzung übrigens vollkommen verzichten, er weiß ja, was gemeint ist.

So war mein von dir zitierter Satz zu verstehen - und, sei mir nicht böse: Er war wesentlich kürzer und von A bis Z verständlich. Zu deinen Gunsten nehme ich daher an, daß du dich absichtlich dumm stellst. Und damit zum Schluß zum Thema "Umgangsformen":

Du, Tzeh, bist - wie ich bereits vermutete - derjenige, der hier seine Umgangsformen überprüfen sollte. Klartext: Du möchtest unser Recht, unsere Meinung zu äußern, reglementieren. Sonst würdest du einen Satz wie deinen vorletzten nicht schreiben.

Und... und... und... - das überprüfe bitte selbst.

Deine Umgangsformen sind nicht freundlich - daran ändert auch dein "freundlicher" Gruß nichts.

Fazit: Eigentlich hast du die besten Gründe geliefert, bei der Version von VÖRBY zu bleiben. Aber das ganze lohnt nicht - es würde nur ein unendlicher Edit-War folgen, und den "gewinnt" i.d.R. der, der die besseren Karten bei den Admins hat, nicht der, der Recht hat. Das ist mir zu ermüdend. Deshalb: Erfreue dich deines "Durchsetzungsvermögens" und gute Nacht. Die wünsche ich dir übrigens ehrlich, weil ich letztlich auch was davon habe... --Shahrzad 00:45, 18. Okt. 2010 (CEST)

Liebe Leute, jeder von Euch hat doch wohl soviel Selbstbewusstsein, dass er auch mal ein etwas unbedachtes Wort eines anderen toleriert - und nicht gleich nach dem Motto "Aug um Aug ..." dagegen schießen muss. Solche 'Religionskriege' fressen nur Kraft und schaden der Sache. Bringt bitte weiterhin Eure Fachkompetenz ein - und setzt sie für nützliche Beiträge ein; der Textumfang HIER sollte nun wirklich genügen.
Zur Sache: Ich denke, die jetzige Formulierung wird allen Sichtweisen gerecht. Die Idee 'ohne -s' hatte ich auch schon. Da die deutsche Entsprechung wohl nie "in die Gefahr gerät", sprachlich tatsächlich verwendet zu werden (in der Aussprache wäre das ohne 's' wohl zu 'holprig'), bin ich auch für das Weglassen der beiden 's' - und stelle das nun im Text auch so ein. Danke für Eure Mitarbeit.
--VÖRBY 10:01, 18. Okt. 2010 (CEST)

Danke, VÖRBY Ich grüße Dich freundlich tzeh 13:00, 18. Okt. 2010 (CEST)

Im Sinne von Vörby belassen wir dies jetzt so ... , lg -- Agruwie  ^Disk   17:58, 18. Okt. 2010 (CEST)

Danke zusammen, das wäre also geschafft. Übrigens: Die Deutsch-English-Enzyklopädie http://dict.leo.org liefert für 'Entity' Begriffe wie Ding, Einheit, Gesamtheit, Gebilde, Instanz*, Objekt*, Wesen. 'Gegenstand' ist nicht dabei, sondern wird mit item, article, matter, object, topic ... übersetzt. Ich persönlich habe übrigens 'Gegenstand' auch noch nicht gehört; zumal dieser Begriff auch nicht präzise ist; denn als Entität gibt es wohl auch Personen, Zustände, Rollen, Länder, Zeiteinheiten usw. Aber: Lassen wir es mal so; der Begriff ist tatsächlich schwer 'einzudeutschen'.
(*) wahrscheinlich aus der Informatik ins Englische übernommen. Viele Grüße! --VÖRBY 19:05, 18. Okt. 2010 (CEST)

Die Übersetzung "Einheit" ist hier schon die am ehesten treffende. Es geht um "das eine Ding oder die eine Person", die von einem Datensatz einer Tabelle repräsentiert wird. So entspricht es auch der alten Lesart für Datenbanktabellen, deren Datensätze "Gegenstände, Personen oder Sachverhalte" abbilden. Differenziert man hier zwischen Tabellen, die "Entities" enthalten, und denen, die Relationships beinhalten, wie das ERM dies tut, bleiben hauptsächlich Gegenstände und Personen übrig. Auch insoweit ist also die Übersetzung "Gegenstand" ein Fehlgriff, degradiert sie doch eine Person zu einem Ding.

Noch unglücklicher verhält es sich mit "Relationship". Es gibt hier eine Doppeldeutigkeit der Begriffe, denn die Beziehung wird für die Datenbeziehung zwischen den Tabellen verwendet und würde bei dieser Übersetzung auch für Relationship gelten (allerdings gibt es diese Doppeldeutigkeit auch im Englischen).

Dennoch: Tzeh hat Recht: Wenn der Begriff in der Literatur zu finden ist, haben wir uns nicht darum zu kümmern. Insofern verstehe ich nicht, warum er jetzt klein beigibt, aber das ist seine Entscheidung... --Shahrzad 20:50, 18. Okt. 2010 (CEST)

Identifizierbares Objekt

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)

Ob "Müller" oder Müller, das macht m.E. keinen Unterschied: Unter 'Entität' soll lediglich (für DM-Laien) die Tatsache unterstrichen werden, dass eine ganz bestimmte Instanz von Angestellten (oder Projekten) gemeint ist; schließlich ist "Müller" i.d.R. auch kaum eindeutig. Bei "3232" könnte das schon sein - wenn die PNr identifizierendes Attribut wäre. Im Detail hast Du recht: Das Anführungszeichen könnte den Eindruck erwecken, es solle auf eine Art "Key" verwiesen werden. Aber von Attribut (und auch von Datenspeicherung) ist ja bei 'Entität' noch nicht die Rede.
Insofern ist 'ohne Anführungszeichen' etwas besser; Tzeh hat Deinen Vorschlag schon umgesetzt. Danke für den Hinweis.--VÖRBY 15:23, 29. Nov. 2010 (CET)

Nochmal Gegenstand-Beziehung-Modell

In der Einleitung heißte es, Gegenstand-Beziehung-Modell sei nicht gebräuchlich. Das stimmt jedoch nicht. Bei Google hat dieser Begriff in Anführungszeichen mehrere 100 Treffer. 85.179.36.70 12:59, 11. Jul. 2011 (CEST)

Siehe Antwort unter Diskussion:Gegenstand-Beziehung-Modell. --VÖRBY 13:14, 11. Jul. 2011 (CEST)

Für "Entity Relationship Modell" gibt es 29.700 Treffer. Die ca. 300 Treffer für ~GBM bestätigen also die verschwindend geringe Verbreitung dieses (unkorrekten!) Begriffs. Ich habe die Anmerkung deshalb von 'nicht gebäuchlich' auf 'selten benutzt' geändert. Da hier auch keine tatsächlich wörtliche Übersetzung vorliegt, habe ich 'wörtlich' durch 'etwa' ersetzt.

--VÖRBY 17:37, 11. Jul. 2011 (CEST), aktualisiert: --VÖRBY 18:48, 11. Jul. 2011 (CEST)

Visio Datenbankmodelldiagramm

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)

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)

Eingedeutscht

Hab mal normales deutsch eingefügt zum besseren Verständnis. (nicht signierter Beitrag von 79.195.181.67 (Diskussion) 09:57, 18. Mär. 2015 (CET))

Ich habe diesen Disk-Text nach hierhin verschoben; ursprünglich wurde er ganz vorne vor dem ersten ==Abschnitt eingefügt, das ist unüblich.

Abgesehen von diesem formalen Aspekt wurde hier "verschlimmbessert": An zahlreichen Stellen wurden etablierte Begriffe durch die 'eingedeutschten' ersetzt. Dies ist aber gerade nicht besser verständlich, denn diese Ausdrücke trifft man in der Liteeratur und in der Praxis kaum an; es genügt, wenn die deutsche Entsprechung je Ausdruck einmal erläutert wird. Außerdem ist ein Teil der Änderungen methodisch inkonsistent: zB ist Eigenschaft kein Synonym für Attribut: Eigenschaften gehören zu Entitäten, Attribute zu Entitätstypen.

Sorry, das war vielleicht gut gemeint, das Ergebnis ist aber das Gegenteil. --VÖRBY (Diskussion) 12:58, 18. Mär. 2015 (CET); ergänzt: --VÖRBY (Diskussion) 13:00, 18. Mär. 2015 (CET)

Der IP-User antwortete auf meiner Disk-Seite. Siehe auch dort.

Es ist so das diese Begriffe als Standard in der Software und insbesondere der Datenbankentwicklung dienen. Sie sind jedoch zum Verständnis der entsprechenden Sachverhalte nicht förderlich. Ich denke die Wikipedia sollte da auch auf Menschen rücksicht nehmen die einfahc nur entwas nachlesen wollen und es auch verstehen möchten, da sind Sinngemäßre deutsche Übersetzung besser als eine kryptische Fachsprache. Von einem IP-User.

Hierher von Disk-Seite von VÖRBY kopiert zum besseren Verständnis. --Sebastian.Dietrich ✉ 19:02, 18. Mär. 2015 (CET)

Liefere bitte Belege dafür, dass die von dir gesetzten eingedeutschten Begriffe in der einschlägigen Literatur so verwendet werden - wobei ich wirklich umfassendes 'Verwenden' meine, nicht nur Hinweise auf die deutsche Beedeutung. Bis dahin lösche ich deine Änderungen wieder. Wenn jemand in Wikipedia Begriffe sucht, dann deshalb, weil er diese irgendwo vorfindet und dann etwas darüber nachlesen möchte. Da wird man aber immer nur die Standardbegriffe finden - und diese dann auch suchen wollen. Es muss also genügen, in Artikeln mit zB engliscchen Standardbegriffen nur einmal zu erläutern, was das auf Deutsch bedeutet. Und nicht den ganzen Text auf für die allermeisten Leute ungewöhnliche und auch nahezu unaussprechliche Wortgebilde abzuändern. --VÖRBY (Diskussion) 17:36, 18. Mär. 2015 (CET)

Mein Senf dazu: Die englischen Begriffe sind so etabliert. Auch in der deutschsprachigen Literatur. "Gegenstand-Beziehung-Modell" ist ein nicht existierender Begriff. Die deutsche Sprache zeichnet sich nunmal dadurch aus, dass sie (z.B. im Gegensatz zum Französischen) gerne etablierte Begriffe aus anderen Sprachen übernimmt. Darum heisst es auch Computer (und nicht Ordinateur oder Rechenmaschine). --Sebastian.Dietrich ✉ 19:11, 18. Mär. 2015 (CET)

Hab jetzt Halbsperre des Artikels beantragt, da er laufend (nicht nur deutschdeutsch) vandaliert wird. --Sebastian.Dietrich ✉ 19:25, 20. Mär. 2015 (CET)

Begriffe - Bild

Das im Abschnitt Begriffe gezeigte Bild entspricht weder - wie behauptet - der modifizierten Chen-Notation, noch einer anderen gängigen Notation.

Bitte daher um Änderung des Bildes. Die Seite scheint für Bearbeitungen meinerseits gesperrt zu sein. Jaing10 (Diskussion) 15:41, 9. Apr. 2017 (CEST)

Ich denke, das Bild an dieser Stelle soll nur einen grundsätzlichen Eindruck davon liefern, wie ERDs aussehen können, d.h. insbesondere, welche Symbole was bedeuten. Offensichtlich kennt die 'erweiterte Chen-Notation' (siehe dort) keine Sterne für Kardinalitätsangaben; hier steht der * aber wohl für 'n' und ohne die Min-Max-Angaben aus der erweiterten Chen-Notation.

Ich habe die Bildunterschrift geändert in 'angelehnt an die Chen-Notation'; das trifft zweifellos zu, und man kann das m.E. so stehen lassen. Weitere Notationen werden weiter unten erklärt - und in den Detailartikeln. --VÖRBY (Diskussion) 19:33, 9. Apr. 2017 (CEST)

Objektbeziehungsmodell

@Vörby: Das Objektbeziehungsmodell kenne ich lediglich aus der Psychologie nicht aber aus der Informatik. Kannst Du belegen, ob Objektbeziehungsmodell tatsächlich auch in der Datenmodellierung verwendet wird? Ich grüße Dich freundlich --tzeh (Diskussion) 15:25, 29. Mai 2019 (CEST).

Hi, mir ist dieser Ausdruck auch nie untergekommen. Früher war er im Artikel mal als 'Gegenstand-Beziehung-Modell' beschrieben. Beide Versionen sollen wohl nur die wörtliche Bedeutung / Übersetzung des Englischen Ausdrucks klarstellen. Am 20.sept. 2010 war nur "deutsch Gegenstands-Beziehungs-Modell" in der Einleitung vorhanden. Am 16.10.2010 hatte diese Erläuterung jemand gelöscht, DU hattest sie aber wieder eingesetzt. Am 17.10.2010 [1] erweiterte ich nach einigen Edits mit Reverts auf "(in deutsch wörtlich "Gegenstand-Beziehungs-Modell", nicht gebräuchlich)". Irgendwann wurde daraus "diese Bezeichnung wird aber selten benutzt".

ch denke, die Änderung auf "nicht gebräuchlich" entspricht der Realität. "Objekt" wurde wohl irgendwann als allgemeingültiger empfunden als "Gegenstand". --VÖRBY (Diskussion) 20:49, 29. Mai 2019 (CEST)

Danke Vörby für Deine zutreffenden Angaben zur Historie. Die Bezeichnung Entität-Beziehung-Modell wurde am 21.April 2006 von 84.61.121.191 eingeführt und von mir - leider nicht gestrichen - am 24.April umbenannt in Gegenstands-Beziehungs-Modell. Weder diese ursprüngliche Bezeichnung noch die aktuelle Bezeichnung Objektbeziehungsmodell sind mir in der Informatik begegnet. In der Psychologie versteht man darunter ein Modell, das bestimmte Beziehungen zwischen Menschen beschreibt. Siehe z.B. www.newbooks-services.de/MediaFiles/Texts/6/9783794528356_Excerpt_001.pdf Da ich in der Literatur über ER-Modellierung keinen Nachweis über die beiden Bezeichner finden kann, schlage ich vor, den aktuellen Bezeichner Objektbeziehungsmodell ebenfalls zu streichen. Wie siehst Du das? --tzeh (Diskussion) 22:45, 29. Mai 2019 (CEST)

Vielleicht ist es ein guter Kompromiss, das wie folgt zu formulieren:

Bedeutung in Deutscher Sprache in etwa: Modell (zur Darstellung) von Dingen, Gegenständen, Objekten (= entity) und der Beziehungen/Zusammenhänge (= Relationship) zwischen diesen.

Auch Du hattest früher schon mal revertiert- mit dem Hinweis, eine Übersetzung sei zweckmäßig. Zum Verstehen des Ausdrucks sollte schließlich niemand zum googeln gezwungen sein.

Die Übersetzungen habe aus LEO [2] verwendet. Auf jeden Fall wird so nicht der Eindruck erweckt, das Ganze sei eine offizielle Bezeichnung. --VÖRBY (Diskussion) 11:29, 30. Mai 2019 (CEST); alternativ: --VÖRBY (Diskussion) 11:59, 31. Mai 2019 (CEST)

Deinen Änderungsvorschlag begrüße ich sehr. Er vermeidet eine Homonymsituation noch dazu eine Übersetzung, die nicht belegt ist. Dass die Darstellung auf der Typ-Ebene erfolgt, muss m.E. hier nicht explizit erwähnt werden. Dank und Gruß --tzeh (Diskussion) 16:06, 31. Mai 2019 (CEST)

Möchte es so in den Artikel einstellen:

(kurz ER-Modell oder ERM; deutsch soviel wie: Modell (zur Darstellung) von Dingen, Gegenständen, Objekten (= ‚entities‘) und der Beziehungen/Zusammenhänge zwischen diesen (= ‚relationship‘)) dient dazu, im Rahmen der semantischen Datenmodellierung den in einem gegebenen Kontext (z. B. einem Projekt zur Erstellung eines Informationssystems) relevanten Ausschnitt der realen Welt zu beschreiben und darzustellen. Das ER-Modell besteht im Wesentlichen aus einer Grafik (ER-Diagramm, Abk. ERD) sowie einer Beschreibung der darin verwendeten Elemente. Wäre das so ok? Die Sache mit der Typ-Ebene kommt hier nicht vor, wäre eine eigene Diskussion. 'Semantik' und Datenstruktur passt in der bisherigen Form nicht in die Einleitung. Danke fürs Mitdiskutieren. --VÖRBY (Diskussion) 20:37, 31. Mai 2019 (CEST)