Announcement

Collapse
No announcement yet.

Datenbankdesign

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Datenbankdesign

    Hallo,

    ich bebschaeftige mich im Moment mit dem Datenbank - Design und erstellte ein ER-Modell und die Aufloesung
    des Modells in die ersten 3 Normalformen.

    Hier meine Fragen:
    - Darf aus einer Entitaet mehr als 1 Relation enstehen?
    - Darf sich eine Entitaet auf sich selbst beziehen? (Beisp.: Verzeichnisbaum mit Unterverzeichnissen)

    Falls jemand darauf eine Antwort weiss, waere es gut wenn ich einen Quellen- oder Literaturverweis
    haben könnte.
    Dank!

  • #2
    zu 1: Wennst Du damit meinst, das aus einer Entität mehr als eine Tabelle entstehen soll: Eigentlich nein. Jedes Tool erzeugt aus einer Entität eine Relation. Auch sollte die Normalisierung dafür sorgen, daß eine Entität nicht mehr sinnvoll auf mehr als eine Tabelle aufgespaltet werde muß (sonst wäre ja gewünschte Normalisierung nicht erreicht)

    zu 2: Eine Entität darf eine Relation auf sich selbst beziehen. Beispiel:<br>
    Entität Person -> Relation zu sich selbst mit der Bedeutung: Ist verheiratet mit, ist Kind von, ....

    Quellen (Bücher gibt es viele) z.B.<br>
    Relationale Datenbanken von Hermann Sauer, Addison-Wesley-Verlag, ISBN 3-8273-1381-3
    An introduction to Database Systems, Addison-Wesley, ISBN 0-201-52878-

    Comment


    • #3
      zu 1: Wennst Du damit meinst, das aus einer Entität mehr als eine Tabelle entstehen soll: Eigentlich nein. Jedes Tool erzeugt aus einer Entität eine Relation. Auch sollte die Normalisierung dafür sorgen, daß eine Entität nicht mehr sinnvoll auf mehr als eine Tabelle aufgespaltet werde muß (sonst wäre ja gewünschte Normalisierung nicht erreicht)

      zu 2: Eine Entität darf eine Relation auf sich selbst beziehen. Beispiel:<br>
      Entität Person -> Relation zu sich selbst mit der Bedeutung: Ist verheiratet mit, ist Kind von, ....

      Quellen (Bücher gibt es viele) z.B.<br>
      Relationale Datenbanken von Hermann Sauer, Addison-Wesley-Verlag, ISBN 3-8273-1381-3<br>
      An introduction to Database Systems, Addison-Wesley, ISBN 0-201-52878-

      Comment


      • #4
        Zur Anwort 1:
        Die Datenbank soll belieb viele Inhaltsverzeichnisse von CDs speichern. Dabei wird jede CD in Kategorien
        eingeteilt. Darus ergeben sich folgende Entitaeten:

        Kategorien
        Datentraeger
        Verzeichnisse
        Dateien

        Jeder Datentraeger, jede Verzeichnis, jede Datei hat sein eigenes Icon. Nur ein Icon kann doch keine
        eigene Entitaet sein, da es ja zum Datraeger, Verzeichnis oder Datei gehoert.
        Spaeter in der Aufloesung des ER-Modells will ich aber eine eigene Relation fuer die Icons bilden um
        eine erhoete Erweiterbarkeit der Datenbank zu garantiern.
        Daraus ergibt sich eine neue Relation, aber ohne vorherige Entitaet.
        Ist das dann so korrekt

        Comment


        • #5
          So wie ich es verstehe, willst Du das Icon im ersten Design als Datenfeld in den entsprechenden Entitäten ablegen. Später willst Du nur auf eine Entität verweisen (relation), welche die Daten der Entität beinhaltet, um z.B. zu erreichen, daß wenn viele Dateien das gleiche Icon benutzen, dieses nur einmal vorhanden sein muß (in einer eigenen Entität Icon). Ist das so richtig verstanden

          Comment


          • #6
            Ja, fast.
            Aber die Beziehung zwischen Datentraeger, Verzeichnisse, Dateien und Icons 1:1 ist.
            Ich will also nur die Icons in eine neue Tabelle auslagern um besser auf weitere Entwicklungen
            vorbereitet zu sein.
            Um noch mal auf das Problem zurückzukommen:
            Darf man nach der Definition von Chen aus einer Entitaet mehrere Tabellen bilden?

            Das gleiche wie mit dem Icons habe ich auch mit Dateiinhalten bestimmter Extensions vor. Es soll
            moelgich sein bei best. Dateitypen den Dateiinhalt zu speichern. Fuer die Dateiinhalte habe ich ebenfalls
            vor eine neue Tabelle zu bilen die dann auch 1:1 verknuepft wird mit der Ausnahme das nicht jede Datei
            zwigend einen Dateiinhalt hat (also auch 1:0 zugelassen wird).
            Ich hoffe ich konnte es einigermassen verstaendlich ausdruecken

            Comment


            • #7
              Ich würde sagen Du mußt für die Icons eine eigene Entität definieren.
              Soweit mir bekannt ist, wird aus einer Entität immer nur eine Tabelle gebildet. Was man bestimmen kann ist, daß bei einer 1:1 oder 1:n-Beziehung entweder aus dieser Beziehung eine eigene Tabelle gebildet werden soll (maximale Auflösung), oder ob die Beziehung als einfacher Foreign-Key in der entsprechenden Tabelle aufgenommen werden soll(minimale Auflösung).

              Bei der Auflösung ohne neue Tabelle für die Relation kann man noch angeben, ob NULL-Werte erlaubt sind (um eine 1:0-Beziehung zu ermöglichen

              Comment


              • #8
                Danke fuer Deine Antworten, wahrscheinlich werde ich es so machen.
                Denn es muss richtig sein, dies geht naehmlich in eine Entwicklungsdokumentation bei einer Projektarbeit ein, die ich
                erstellen muss.

                Vieleicht melden sich ja noch andere, die mir deine Anworten bestaetigen koennen.
                Auf jedenfall vielen DANK

                Comment


                • #9
                  Ich muß meine eine Antwort korrigieren. (Hab gestern noch mal mit meinen ehemaligen Prof. von der FH gesprochen)

                  Du kannst natürlich bei der Verfeinerung deines (E)ER-Modells in die pysikalische Gegebenheiten natürlich aufgrund
                  von Performance-, Sicherheitsaspekten oder Einschränkungen der DB eine logische Entität in mehrere Tabellen aufteilen.
                  (z.B. eine Entität Aufträge wird aufgeteilt in Tabelle Auftrag_Standort1, Auftrag_Standort2, damit nicht die Aufträge von Standort1 von den Benutzern von Standort2 angesehen werden können). Du kannst als meinen Anmerkung mit einer eigenen Entität Icons
                  als Designvorschlag vorsehen

                  Comment

                  Working...
                  X