Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Kleine Frage zu Vorlesungsfolie 2 / Zum E/R Modell / Seite 22
Ich würde die allgemeine Definition besser verstehen, wenn dort Anstelle von Beziehungs-Typ eher Beziehungs-Menge stehen würde?
Der Grund ist, dass in der Definition steht R sei eine Teilmenge (mein Mathe ist lange her, vielleicht interpretiere ich auch die Zeichen falsch) von E1 x E2 x … x EN. Und E1 x E2 x … x EN ist die Menge aller überhaupt möglichen Entity Kombinationen (=> unendlich groß), richtig? Wenn R eine Teilmenge aller möglichen Kombinationen von Entities ist, dann ist es zumindest potentiell eine konkrete Anzahl an Entities. Das hört sich für mich eher nach einer Extension als einer Intension an. Somit würde es eher Sinn machen, wenn die Definition eine Menge an kronketen Beziehungen darstellt. Weiter unten wird auch im 3. Bullet Point von Beziehungsmenge R gesprochen.
Das ist jetzt nicht besonders Klausurrelevant, und ich brauch auch keine schnelle Antwort. Mich interessierts einfach nur, was ich falsch verstehe.
So wie ich das sehe, siehst du da was nicht ganz korrekt. Das Kreuzprodukt von n Mengen, wobei n beliebig, aber fest, sei, ist endlich. Wo ich dir Recht gebe, ist, dass man „definiert“ und „ist“ hier schwer auseinanderhalten kann. Es steht ja da:
Ein Beziehungstyp R zwischen n Entity-Typen E1, …, En
definiert eine Menge von Beziehungen (Relationship-Set oder
Beziehungsmenge) zwischen Entities der beteiligten Entity-Typen
R \subseteq E1x E2 x … x En
In „Javaspeak“, ungefähr: Eine Methodensignatur gibt dir an, welche Referenzen auf welche Objekte du brauchst, um eine Methode zu beschreiben, die dir entweder ein Verhältnis zwischen zwei Objekten instanziert (unsauber), oder dir Referenzen innerhalb der Objekte setzt oder, wenn’s nicht anders geht, ein Objekt instanziert, welches für eine Beziehung zwischen besagten n Objekten steht.
Bedenke stets: Der „Typ“ wäre hier sowas wie „fressen“: Ein „Informatiker“ „frisst“ N „Obstkuchen“. Das bedeutet: „Fressen“ definiert eine Menge von Fressbeziehungen: Neo frisst Erdbeerkuchen No. 1 und Bananenkuchen Alpha, währen Henry Dorsett Case sich an Erdbeerkuchen No. 2 und Zitronenkuchen Gamma vergeht.
Du hast halt immer das Kreuzprodukt von endlich vielen, selbst endlichen Mengen - dies beschreibt hier jene in Beziehung stehende Mengen. (Regards, Dolan)
Ich schätze, das hilft dir nicht groß weiter, aber ich denke, es hapert am „ist“ und „definiert“ - beantwortet das deine Frage einigermaßen, oder nicht? Wenn nicht, seh’ ich mir das noch gern mal an. (Komm’ außerdem in meine Klausurfragestunde morgen ;P)
Hi Jerry,
danke für deine Antwort. Leider hatte ich die Woche noch eine andere Prüfung und habs nicht zur Fragestunde geschafft.
Darf ich vielleicht dein Beispiel etwas verändert aufgreifen? Angenommen, ein Student ist Entity Typ, E1, mit Attribut Name und StudententenID. Die Definition des Typs wäre dann E1 = Name x StudentenID . Für mich sind der Typ alle möglichen Kombinationen von Name und StudentenID, die der Wertebereich zulässt. Angenommen alle Wertebereiche sind endlich, dann sind auch die Kombinationen endlich. Ist ein Wertebereich unendlich, sind die Kombinationen unendlich. Die Entity Menge, die tatsächlich in der Datenbank ist, wäre z.B. die Untermenge ES1 von Name x StudentenID mit der ID Constraint. Somit wäre in jeder beliebigen echte Datenbank eine Untermenge von den möglichen Kombinationen des Entity-Typs.
Jetzt haben wir z.B. noch ne zweite Entity Essen mit Name als Attribut mit dem Wertebereich String mit beliebiger Länge. Dann ist jetzt Typ E2 = jeder beliebiger String. Die aktuelle Datenbank enthält einen Entity Menge welche eine Untermenge von E1 ist.
Als letztes hätten wir eine Relationship zwischen E1 und E2, nennen wir sie “isst gerne”. Für mich wäre jetzt der Typ R = E1 x E2 . Sie enthält also die Kombination aller möglichen Entity Ausprägungen, die die Entity Typen E1 und E2 zulassen. Die echte Menge in der Datenbank, nenen wir sie Relationship Set RS, wäre somit RS ein Untermenge von E1xE2 oder eine Untermenge von R. Von meinen Verstädnis ist also die Relationship in der echten Datenbank eine Untermenge von allen möglichen Kombinationen von E1xE2 und die Typ Defintion von R ist gerade gleich des Kreuzprodukts aus E1xE2.
Wäre, wie in der Definition angenommen, der Typ (und nicht die Relationship Menge) eine Untermenge aus E1 x E2, dann könnte es Einträge in z.B. (für relatioelle Datenbanken) Tabelle Student geben und einen Eintrag in der Tabelle Essen, die zwar Teil der Menge E1xE2, aber nicht Teil des Typs R (weil es eine Untermenge ist) sind. D.h. wir dürften diese echten Einträge nicht in die Tabelle “ist_gerne” schreiben, obwohl sie aus den richtigen Tabellen kommen. Dass ein Relationship Typ eine Einschränkung hat, welche Einträge in Beziehung gesetzt werden können, kenne ich nicht. Deshalb hatte ich das Gefühl, dass entweder das Teilmengen Zeichen in der Definition durch “=” ersetzt oder das Wort “Entity-Typ” durch Entity-Menge ersetzt werden sollte. Aber wahrscheinlich habe ich einfach einen Fehler in meinem Denken. Aber vielleicht wurde es durch das Beispiel klarer, wo mein Fehler liegt.
Ich denke, du musst da zwei Dinge bedenken. Erstens solltest du E/R und relationale Datenbanken schärfer trennen - Mir ist z.B. nicht bekannt, dass Attribute in E/R bereits (ausgezeichnete) Wertebereiche hätten. Vermische am besten auch nicht die Begriffe “Schlüssel” im E/R und “Primärschlüssel” im Relationalen - das sind unterschiedliche Dinge.
Zweitens hab’ ich das Gefühl, der “Fehler” liegt bei deiner Auffassung, der Typ sei die Menge aller möglichen Instanzen. In der Definition ist ja auch erwähnt, sie beschreibt diese Menge. Was ist zum Beispiel ein Punkt im R²? Ein Tupel aus zwei reellen Zahlen. Der Typ “2D-Punkt” ist also charakterisiert durch R x R. Obschon wir hier unendlich viele Punkte beschreiben können, ist die Typbeschreibung endlich. Jetzt hab’ ich deinen Studenten-Entity-Type, das wäre sowas wie C* x Z (für C als Zeichen, Z als ganze Zahl und C* als Verkettung beliebig vieler Zeichen). Mit der maximalen Extension hat das erstmal nicht viel zu tun.
Der Typ definiert aber auf diese Weise, also, indem er Wertebereiche angibt, wie Entities (oder auch Relationships, für deren Typen) beschrieben werden können - er erfasst damit alle möglichen Instanzen, und alle auftretenden sind auch dadurch beschreibbar.
Fies an dieser Folie übrigens: Intension und Extension heißen beide R, das steht auch im ersten Stichpunkt so drin. Also: Oben denkst du dir “R-Type” (lol) und unten “R-Set”. Dann kommst du auch mit sowas aus wie:
“Ein n-stelliger Relationship-Typ R-Type mit m Attributen ist charakterisiert durch ein i[/i]-Tupel aus n Wertebereichen der Schlüssel der teilnehmenden Entities (diese können mehrstellig sein, aber du verstehst die Definition bestimmt auch so.) und m Wertebereichen der Attribute.”
Setzt man diese anschließend in’s Kreuzprodukt, hat man die Menge aller Beziehungsinstanzen, die es geben kann. Davon ist R-Set eine Teilmenge.
Natürlich widerspreche ich mir selbst, wenn ich in der Definition wieder Wertebereiche verwende - eigentlich würdest du hier ja Entity-Typen und Attribute an sich verstehen, also sowas wie “Student x Essen” statt “Z x C*”. Trotzdem denke ich, dass die falsche Definition meinen Punkt besser unterstreicht. Verstehst du, was ich meine?