1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, Oracle, Sql-Server, Postgres, Access uvm
    Information ausblenden

2 Fragen zur Datenbanken-Theorie

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von FKFKFK, 1 März 2011.

  1. FKFKFK

    FKFKFK Neuer Benutzer

    Hallo zusammen,

    habe mich frisch angemeldet und gleich zwei Fragen zu Datenbanken, die mir bisher nirgendwo beantwortet werden konnten. Ich hoffe mal, dass das hier richtig ist. Zwar hängen Datenbanken nicht zwingend mit Webanwendungen zusammen, aber da da meine Fragen reine Theorie sind, ist das egal.

    Als erstes zum ER-Modell allgemein:

    Ich habe mir Gedanken gemacht, ob man eine Beziehung zu 4 Entitys erstellen könnte (nur von der Theorie). Normal besteht ja eine Beziehung zu maximal 2 ganz selten auch zu 3 Entitys.
    Ich habe einfach aus einer bereits existierende Übersicht, die 3 Entitys hat, das hier genommen und noch das Entity Bar hinzugefügt. Das Bild habe ich in Paint gemacht, deswegen siehts auch etwas speziell aus ;)
    [​IMG]

    Die unterstrichenen Attribute, sind gemäß Norm natürlich Primary Keys (PK). Ich nehme der Einfachheit halber an, dass der Inhalt jedes PK-Attributs nur einmal vorkommt, damit keine künstlichen Keys vergeben werden müssen. Das sollte aber wohl nicht von besonderer Bedeutung sein.
    Es läuft so ab: Die Rolle Empfehler, welche einen bestimmten Namen und ein bestimmtes Alter hat, empfiehlt der Rolle Koster, die auch einen bestimmten Namen und ein bestimmtes Alter hat, einen Cocktail, welcher auch wiederum einen bestimmten Namen und auch einen bestimmten Alkoholgehalt hat. Dazu gibt er auch noch die Bar (die nach seiner Meinung den Cocktail am besten macht).
    Es herrschen überall N:N-Beziehungen. Der Betrachter möchte gerne wissen, welcher Cocktail von wem wem empfohlen wurde und auch, welche Bar der Empfehler mitempfohlen hat.
    Nun stellt sich mir die Frage, ob man das ganze noch vereinfachen und auflösen kann, so dass z.B. eine zweier- und eine Dreierbeziehung entstehen würde.

    So, die Frage war schon ziemlich lang:)
    Jetzt zur zweiten Frage:
    Es geht um ein relationales Modell. Es sind Attribute gegeben, welche funktionale Beziehungen untereinander haben und nach der 3. Normalform entsprechend in verschiedenen Tabellen untergebracht werden.

    Hier die Vorgabe:

    R{A,B,C,D,E} mit den funktionalen Abhängigkeiten
    A->{B,C},
    {C,D}->E,
    B->D,
    E->A


    Ich habe sogar schon die Lösung:

    R1{A,B,C,E}
    R2{B,D}
    FK:B{R1}->B{R2}

    Nun verstehe ich an dem ganzen aber nicht, wieso man dies in zwei Tabellen und nicht in drei macht (E noch auslagern), weil es bestehen ja noch funktionelle Abhängigkeiten?

    Das sind jetzt enorm herausfordernde Fragen, aber ich hoffe mal, dass mir da jemand weiterhelfen kann, sonst muss ich nämlich in einem Datenbankforum nachfragen:)

    Schon einmal vielen Dank für die Antworten!

    LG FKFK
     
  2. Charly

    Charly Datenbank-Guru

    Hallo FKFKFK,

    die Raute ist die grafische Darstellung einer Relation zwischen 2 Entitäten.
    Natürlich kann eine Entität mehr als 3 Relationen zu anderen Entitäten eingehen.
    Das wird dann aber in der Regel in mehreren separaten Relationen dargestellt.

    In der späteren Datenbank wäre das eine Zuordnungstabelle die 4 oder mehr Tabellen miteinander verbindet. Da würde ich ins der späteren Datenabk aber noch mehr Zwischentabellen einbauen.

    Beispiel:

    Entität Ansprechpartner (Kontaktdaten)

    Relation "für"

    Entität Firma (Zentrale oder so)
    Entität Angebot
    Entität Auftrag
    Entität Anfrage

    Hier geht die Entität Ansprechpartner eine Relation zu 4 anderen Entitäten ein.

    Ich würde das aber in mehrere Teilmodelle zerlegen (nur wegen der Übersichtlichkeit).
    Sollte also nur ein Problem mit der grafischen Darstellung sein.

    Weis gar nicht warum da immer Chen genommen wird. Ich benutze immer die 'Krähenfuß-Notation'. Die 'Min-Max-Notation' ist auch nicht schlecht.

    Für Frage 2 brauche ich noch ein bisschen:D

    Gruß Charly
     
  3. ukulele

    ukulele Datenbank-Guru

    Zu 1)

    Ich würde immer künstliche Schlüssel verwenden, grade Personen Namen sind immer nur normale Atribute. Außerdem bin ich der ansicht das eine Zwischentabelle völlig ausreicht bei einer so simplen geschichte. Zumal, wenn ich das richtig verstehe, alle Angaben zu Bar und Cocktail Pflichtfelder sind. Dann kann man in dem Fall auch einen Primary Key aus den 4 Foreign Keys der Tabelle und schon kann keine Empfehlung mehr doppelt vor kommen (wenn man das nicht möchte...)

    Hier mal ein Entwurf nach deiner Skize:
    Tabelle Personen
    id PK
    vorname
    nachname
    geburtsdatum

    Tabelle Bars
    id PK
    bezeichnung
    strasse
    plz
    ort

    Tabelle Cocktails
    id PK
    bezeichnung
    alkoholgehalt

    Zwischentabelle
    id PK
    id_koster FK referenziert die Person, die den Cocktail kostet
    id_empheler FK referenziert die Person, die den Cocktail empfohlen hat
    id_bar FK referenziert die Bar
    id_cocktail FK referenziert den Cocktail
     
  4. FKFKFK

    FKFKFK Neuer Benutzer

    Als erstes Mal ein richtig großes Lob für euer Forum!
    Bisher eines der besten, die ich gesehen habe, besonders von der Benutzerfreundlichkeit und den wenig nötigen Seitenwechseln :)

    Ja, das mit den künstlichen Schlüsseln würde man dann wirklich so machen, aber wie ich ich glaube ich auch schon geschrieben habe, habe ich sie der Einfachheit halber in der Übersicht weg gelassen :)

    Bei Nr.1 gings mir auch eher darum, ob das laut Chen theoretisch möglich wäre bzw. keine überflüssigen Redundanzen usw. erzeugt und das nach der 3. Normalform auch richtig wäre. Obwohl diese in der Übersicht ohne Tabellen noch nicht so die großen Auswirkungen hat. Naja, ich glaube, dass man sie ja sowieso erst bei einer Relation anwendet und noch nicht in der Übersicht oder?

    Auch schon einmal vielen vielen Dank für die Antworten. Als erstes hatte ich im Gulli-Board nachgeschaut, wie man vielleicht am Host des Bildes, welches ich eingefügt habe, erkennen kann. Leider konnte mir dort keiner weiterhelfen (keine Antworten). Jetzt weiß ich zumindest, wohin ich mich ab sofort wenden sollte :)
     
  5. Charly

    Charly Datenbank-Guru

    Hallo FKFKFK,

    ich hab mal bei Chen (The Entity-Relationship Model--Toward a Unified View of Data) und anderen im Internet nachgeschlagen und leider keinen Hinweis darauf gefunden das mehr als 3 Entitäten über eine Relation verbunden werden können.

    [EDIT]
    Bin jetzt bis Seite 20 vorgedrungen. Da schreibt er:
    Ich habs zwar nirgens sonst gefunden aber so wie Chen hier schreibt gibts da keine Obergrenze

    Und hier dann noch die Möglichkeit mehrerer Relationen zwischen 2 Entitäten.

    So, jetzt habe mich weit genug durch die Literatur gequält. Wer mehr daruber wissen will findet auf der Seite von Chen bestimmt genug Stoff. http://www.csc.lsu.edu/~chen/

    Gruß Charly
    PS: So langsam werde ich hier zum ERM-Freak:D
     
    Walter gefällt das.
  6. FKFKFK

    FKFKFK Neuer Benutzer

    Ja, danke :)
    Es gehen auf jeden Fall mehr wie 2 Relationen, aber normalerweise gibt es nur wenige Fälle, wo so etwas nötig ist. Ich hatte eine ganze Woche Datenbanktheorie in Seminarform und der Dozent, der schon lange Zeit in dem Bereich, auch als Entwickler arbeitet bzw. gearbeitet hat, hatte auch gesagt, dass er in ganz seltenen Fällen mal mit 3 Beziehungen arbeiten musste, er aber nie mehr wie 3 benutzen musste. Ab 3 Dimensionen soll es ja wohl auch für unser Hirn kompliziert werden...

    //edit: Was ist eigentlich ein ERM-Freak?[​IMG]
     
Die Seite wird geladen...

Diese Seite empfehlen