![]() |
Datenbank: MSSQL • Version: 2000 • Zugriff über: Ado
Primärschlüssel aus 2 Attributen, Beziehung auf eins davon
Also nehmen wir an ich habe folgende zwei Tabellen:
Strassen GruppenID: GUID GueltiVon: TDateTime; GueltigBis: TDateTime; Name: string; Abschnitte ID: GUID Strassen_ID: GUID Nummer: Integer Primärschlüssel ist GueltigVon+GruppenID bei Strassen, sowie ID bei Abschnitte. Eigentlich hab ich mir gedacht ich mach eine Fremdschlüsselbzeiuhg zwischen Strassen_ID und GruppenID. In Strassen_ID dürfen somit nur GUIDs eingetragen werden die in Strassen stehen, löscht man eine Strasse werden Abschnitte ebenfalls gelöscht. Nur leider geht das nicht da ich auch immer eine Bezihung für GueltigVon angeben muss: "A pair of matching columns is required to create relationshipt" bzw. "The Columns in Table 'Abschnitte' do not match an existing primary key or UNIQUE contrainst." (MSSQL2000) Hat jemand eine Idee (ausser einfügen einer neuen Tabelle die eine ID hat waruf beide dann verweisen?) bzw. Trigger? Im Grunde wäre das für folgendes Beispiel: Abschnitt X gehört zu Strasse Y. Strasse Y wird umbenannt (alte GueltigBis wird auf das Datum gesetzt, neue GueltigVon ebenfalls). Abschnitt X gehört somit zu der gleichen Straße (welche zeitabhängig ist). Strassen+Abschnitte wrden nicht aus der DB gelöscht, nur das GueltigBis Datum verändert wenn eine "gelöscht" wird. |
Re: Primärschlüssel aus 2 Attributen, Beziehung auf eins dav
Führe einen atomaren künstlichen Schlüssel ein
|
Re: Primärschlüssel aus 2 Attributen, Beziehung auf eins dav
Jepp, den bisherigen Primärschlüssel kannst Du ja immer noch als UNIQUE INDEX definieren.
|
Re: Primärschlüssel aus 2 Attributen, Beziehung auf eins dav
Eine Linktabelle wäre wohl der kanonische Weg, aber in dem Fall kannst du deiner Strassen-Tabelle auch direkt einen synthetischen PK verpassen und (GruppenID, GueltigBis) mit einer UNIQUE-Einschränkung belegen.
|
Re: Primärschlüssel aus 2 Attributen, Beziehung auf eins dav
Also wenn ich euch richtig verstanden habe einen neuen PK für Straßen anlegen. Was kommt dann in Abschnitte rein?
Irgendwie Blick ich da gerde nicht durch. Die normale Abschnitt:Strassen Beziehung wäre eine 1:n. (Eine Straße hat mehrere Abschnitte, ein Abschnitt gehört zu einer Straße) Da aber Straßen zeitabhängig sein können wäre das wieder eine n:m (Ein Abschnitt kann dann zu zwei Straßen gehören, die eigentlich die selbe sind jedoch Zeitlich aufeinanderfolgend) Das würde ich ja mit normaler n:m Beziehung hinbekommen Strassen ID: GUID [PK] GueltiVon: TDateTime; GueltigBis: TDateTime; Name: string; Gruppe: GUID StrassenGruppen StrasseID AbschnittID [beide PK] Abschnitte ID: GUID [PK] Nummer: Integer Ist es genau das was ihr alle 3 beschrieben hattet, oder hatte jemand eine eine andere Möglichkeit beschrieben? Im Grunde geht mir dann ja die Information verloren welche Straßen zusammengehören. Da müsset ich dann normal wieder eine GruppenID einführen richtig? (Siehe oben) und Gruppe + GueltigVon wäre wieder UNIQUE. Im Grunde kann ich da das Unqiue wieder rausschmeissen da über einen Trigger (bzw. Programm) geprüft werden müsste ob das Datum überhaupt möglich ist (keine Straßen in der selben Gruppe bei Datumsüberschneidung). |
Re: Primärschlüssel aus 2 Attributen, Beziehung auf eins dav
Hallo,
das Problem: Du hast Straßen. Eine Straße hat eine begrenzte Lebensdauer. Eine Straße hat einen oder mehrere Abschnitte. Ein Abschnitt gehört zu einer Straße für den Zeitraum der begrenzten Lebensdauer der Straße. Damit ist auch die Lebesndauer des Abschnittes begrenzt. Demnach wäre es nicht korrekt, wenn ein Abschnitt einer Straße zugeordnet wird, ohne den Zeitraum zu berücksichtigen. Lösungsvorschlag: Entweder muss der Zeitraum mit in den Abschnitt, damit für Straßen und Abschnitte der Schlüssel GruppenID+GueltiVon bzw. Strassen_ID+GueltiVon gilt oder Du benötigst eine "Übersetzungstabelle" zwischen GruppenID+GueltiVon und der Strassen_ID aus Abschnitte. Die Strassen_ID ist dann nicht mehr identisch mit der GruppenID der Strassen. Alternative: Führe in der Straßentabelle eine weitere GUID (z. B. Strassen_ID) ein, auf die dann die Strassen_ID aus Abschnitte verweist. Die Straßentabelle hätte dann zwei eindeutige Schlüssel, die neue Strassen_ID und die Kombination aus GruppenID+GueltiVon. |
Re: Primärschlüssel aus 2 Attributen, Beziehung auf eins dav
@brechi
Mir ist aus deinen Beschreibungen nicht klar geworden, wie den eigentlich die Beziehungen zwischen den Daten sind, bzw. welche zeitlichen Abhängigkeiten abgebildet werden müssen. Die Strasse bekommt erstmal eine eigene Tabelle:
Code:
Alle Daten die sich nicht ändern, werden entweder in dieser Tabelle gespeichert oder 1:N verknüpft.
Strassen
ID: GUID; <- PK Bleibt die Frage, was beschreibt 'Gueltig'? Zumindest scheint klar, das eine Historie gemeint ist, also eine zeitliche Abfolge von Werten oder Zuordnungen gespeichert werden soll (kein Protokoll).
Code:
Alle Daten die einen Zustand beschreiben, der zu einem bestimmten Zeitpunkt vorliegt/vorlag werden in dieser Tabelle gespeichert oder 1:N verknüpft. Der Zustand gilt ab GUELTIG, bis er durch einen neuen Eintrag für einen anderen Zustand ersetzt wird.
Strassen_Historie
ID: GUID; <- PK STRASSEN_ID: GUID; <- FK <- IDX GUELTIG_AB: TDateTime; <- IDX TYP: INTEGER; <- IDX (Optional, für mehrere unabhängige Historien) PK = Primärkey FK = Foreignkey IDX = eindeutiger Index (hier über mehrere Felder) Werden mehrere unabhägige Historien geführt, sind die eigentlichen Daten abhängig vom Typ in verschiedenen Tabellen gespeichert und 1:N oder 1:1 verknüpft. Ob die Strasse befahrbar ist oder nicht, könnte man als Boolean in der Historie Speichern. Da Änderungen im Namen der Strasse kaum relevant sind, wäre dieses Feld eher in der Tabelle Strasse unterzubringen. Ist die Aufteilung der Strasse in Abschnitte konstant, wird auf die Strasse verknüpft, sonst auf die Historie. Gehören die Abschnitte zur Historie, so kann es mehrere Abschnitte mit der Nummer 1 geben, aber zu einem bestimmten Zeitpunkt bzw. einem Eintrag in der Historie, ist nur einer gültig. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz