Announcement

Collapse
No announcement yet.

Datenbank Konzept

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

  • Datenbank Konzept

    Morgen...hab da mal eine allgemeine Frage bezüglich eines Datenbankkonzeptes:<BR>
    Zum Aufbau 5 Tabellen:<BR>
    1. Tabelle Abteilungsverwaltung<BR>
    AbtId=char=Identity=True Primärschlüssel<BR>
    Bezeichnung=nvarchar=255<BR><BR>
    2. Tabelle Adressen<BR>
    AdrId=int=Identity=True Primärschlüssel<BR>
    Vorname=nvarchar=100<BR>
    Nachname=nvarchar=100<BR>
    Usw...<BR><BR>
    3. Tabelle AbteilungAdressen:<BR>
    ID=int=Identity=True Primärschlüssel<BR>
    AbtId=char<BR>
    AdrId=int<BR><BR>
    4. Tabelle Bezeichnungen:<BR>
    BezId=int=Identity=True Primärschlüssel<BR>
    Adressenbezeichnung = nvarchar =100<BR><BR>
    5. Tabelle AdressenBezeichnungen<BR>
    BezId=int<BR>
    ID=int<BR>

    Zu meinen Überlegungen:<BR>
    1 Abteilungen hat mehrere Adressen und 1 Adresse kann in mehreren Abteilungen vorhanden seinè Eine n:m Beziehung

    1.Abteilung hat mehrere Adressbezeichnungen 1:n

    Und 1 Adresse in der Abteilung kann mehrere Adressbezeichnungen haben und eine Bezeichnung hat mehrere Adressen n:m Beziehung

    Zu meiner Frage:
    1. ist das Tabellenkonzept richtig????? Es entsteht doch ein Kaskadierendes Produkt (Bewege mich im Kreis zwischen Abteilung, AbteilungAdressen, Abteilungadressenabteilungsbezeichnung und Abteilungsbezeichnung?????
    2. Wie könnte man das anderes Lösen????(ohne mich im Kreis zu bewegen

    Ich wäre für jede Hilfe dankbar

  • #2
    hallo john, <BR>
    <BR>
    hoffe, ich habe es richtig verstanden - du suchst ein dbmodell zurverwaltung von abteilungen und ihren adressen, wobei diese bei unterschiedlichen typen (bei dir tab. adressbezeichnung) auch unterschiedlich sein können.<BR>
    <BR>
    also gehen wir von drei urspungstabellen aus:<BR
    1. TAbteilung - mit AbtId, Kurzbezeichnung, ...<BR>
    2. TAdressTyp - mit TypId, Kurzbezeichnung, Langbezeichnung, ... <BR>
    3. TAdresse - mit AdrId, Ort, ... <BR>
    verknüpft werden diese über (meiner meinung nach)nur über eine tabelle: <BR>
    4. TAbteilungAdresse mit AbtId, AdrId UND TypId und das müsste reichen. >BR>
    dieses zu meiner idee. wenn ich schief liege, melde dich einfach ..

    Comment


    • #3
      Danke für deine Antwort...<BR>
      Leider ist das eigentliche Problem das eine Adresse in der Abteilung mehrere Adressbezeichnungen hat und eine Abteilung auch mehrere Adressbezeichnung haben kann...
      also meiner Meinung nach eine n:m Bindung

      Sprich:<BR>
      Abteilung 1:n AbteilungAdressen<BR>
      Adressen 1:n AbteilungAdressen<BR>
      AbteilungAdressen 1:n Zwischentabellebezeichnung<BR>
      Adressenbezeichnung 1:n Zwischentabellebezeichnung<BR>
      Abteilung 1:n Zwischentabellebezeichnung<BR>

      Die Frage ist ob ich richtig liege<BR>
      Das Problem ist nämlich, das bei den Abteilungen jederzeit Adressbezeichnungen dazu kommen können (die dann eine einzelne Adresse in der Abteilung wieder verwenden kann)<BR>
      <BR><BR>
      Joh

      Comment


      • #4
        hallo john,<BR>
        <BR>
        ... um gegen die n:m Beziehung 'anzukämpfen', sollte die 4.Tabelle sein, die eigentlich nur die Verknüpfungen zwischen den verschiedenen Adressen und einer Abteilung realisiert. Die unterschiedlichen Adressen sollen über den Typ abgefragt werden.<BR>
        Aber vielleicht kannst Du mir auch einfach ein paar Beispiele nennen. Habe schon einige Erfahrungen mit DBdesign im großen Stil gemacht und mache so etwas gerne.<BR>
        Wenn Du willst, kannst Du mich auch direkt anmailen ([email protected]).

        conn

        Comment

        Working...
        X