Bei der Planung einer neuen Datenbank für die Firma kam eine bestimmte Frage auf die ich zunächst mit einer klaren Antwort quittierte und mir dieser beim Nachdenken immer unsicherer wurde. Kann mir jemand Argumente dafür oder dagegen sagen?
Es geht um folgendes:
Ein Datensatz einer Tabelle hat eine 1:n Beziehung zu einer anderen Tabelle die man vereinfacht als "Koordinate" bezeichnen könnte. Also ein bestimmter Datensatz bezieht sich auf eine andere Tabelle in der die Koordinaten des Datensatzes gespeichert sind.
tbl_Daten
Daten
FK_Koordinate -> bezieht sich auf tbl_koordinaten
Ich wollte diese Koordinaten-Tabelle nun so aufbauen, dass die drei Koordinaten jeweils aus Lookuptabellen stammen, die eigentliche Koordinatentabelle sich also aus Verknüpfungen aufbaut.
In der Datenbank sind die Koordinaten keine Zahlen, aber zur Vereinfachung nehmen wir das mal an.
tbl_koordinaten
FK_X-> bezieht sich auf tbl_X
FK_Y-> bezieht sich auf tbl_Y
FK_Z-> bezieht sich auf tbl_Z
Je länger ich darüber nachdenke desto unsinniger finde ich das.
Ist es sinnvoll die Koordinaten direkt in tbl_koordinaten zu speichern ohne den Umweg über eine verknüpfte Tabelle?
(also:
tbl_Koordinaten
X
Y
Z
)
Ist es vielleicht sogar sinnvoll die Koordinaten direkt in der Haupttabelle tbl_Daten zu speichern und nicht mit einer 1:n Tabelle?
(also:
tbl_Daten
Daten
X
Y
Z
)
Ich habe darüber jetzt so viel nachgedacht dass ich mir nicht mehr traue.
Hallo,
ZitatIst es vielleicht sogar sinnvoll die Koordinaten direkt in der Haupttabelle tbl_Daten zu speichern und nicht mit einer 1:n Tabelle?
Diese Frage lässt sich leicht beantworten:
Wenn es zu einem Hauptdatensatz immer nur
eine Koordinatengruppe gibt > Koordinaten in die tbl_Daten
Wenn es mehrere gibt 1:n Tabelle erforderlich.
Ja, es gibt eindeutig die Möglichkeit dass zwei Datensätze die selbe Koordinate besetzen.
Das habe ich bei dem Planungstreffen auch gesagt.
Aber bedeutet das auch, dass die X,Y,Z-Koordinaten eigene Tabellen kriegen sollten weil diese ja eindeutig 1:n Beziehungen mit der Koordinaten-Tabelle haben?
Hallo,
ich versteh jetzt ehrlich gesagt, Dein Problem nicht.
ZitatWenn es mehrere gibt 1:n Tabelle erforderlich.
ZitatAber bedeutet das auch, dass die X,Y,Z-Koordinaten eigene Tabellen kriegen sollten weil diese ja eindeutig 1:n Beziehungen mit der Koordinaten-Tabelle haben?
Das würde ich auch so sehen. Sind eigenlich die X,Y,Z-Koordinaten immer gleich innerhalb der 3 Werte?
oder kann bei einem Datensatz x=3, y=5, z=7 sein und beim nächsten dann x=5, y=9, z=3 sein?
Wenn ja, sind nach meiner Auffassung 3 n-Tabellen erforderlich nämlich für x, y und z.
Hallo,
irgendwie kommt mir das ein wenig seltsam vor - oder ich verstehe da was nicht ganz.
Koordinaten dienen doch in der Regel dazu einen bestimmten Punkt, Ort oder was auch immer in einem geordneten Umfeld zu identifizieren zu orten oder zu bestimmen.
Also hätte ich einen Ort mit seinen beschreibenden Attributen in einer Tabelle stehen.
Wenn es denn so sein soll, sind die Koordinaten, die diesen Ort lokalisierbar machen in
einer eigenen Tabelle und zwar alle 3 zusammen mit dem PK des Ortes.
ZitatJa, es gibt eindeutig die Möglichkeit dass zwei Datensätze die selbe Koordinate besetzen
Wenn ich davon ausgehe, dass sich X,Y, und Z auf irgendwelche geographische Längen, Breiten und Höhen beziehen ist das eigentlich nicht möglich, da sich 2 unterschiedliche Dinge nicht am selben Ort befinden können.
Werden mit den Koordinaten aber bewegliche Dinge beschrieben - OK, dann käme meine obige Tabellenanordnung in Form von 1:n zum Tragen.
Zitat von: OPS am März 25, 2011, 08:22:38
Ja, es gibt eindeutig die Möglichkeit dass zwei Datensätze die selbe Koordinate besetzen.
Das habe ich bei dem Planungstreffen auch gesagt.
Hi,
sorry, wenn ich mich da einschalte, Du wirst ja schon verarztet, aber ich meine, Du solltest Deine Anwendung noch einmal ausführlicher in Prosa beschreiben.
Ein 1:n-Beziehung ist genau das, was Du nicht zu brauchen scheinst. 1:n-Beziehung ist die Beziehung Vater zu Kind(ern). Wenn ein Datum aber eindeutig einer Koordinatengruppe zugeordnet werden, dann soll ist das ein n:1-Beziehung, also lege dafür eine extra Tabelle für Koordinatengruppen an und mache einen Fremdschlüssel.
Das ist wie wenn du eine Tabelle Häuser hast (mit geographischen Daten) und jede Person einem Haus über Fremdschlüssel zugeordnet wird.
Die "Koordinaten" sind Einbauplätze auf einem Bedienpanel.
Ein normaler Datensatz beschreibt das Signal.
Jetzt gibt es Fälle in denen mehrere Signale auf den selben Einbauplatz gehen.
Die 3 Koordinaten sind:
Welches Panel (es gibt 15)
Welche X-Koordinate (von 001 bis ca. 030)
Welche Y-Koordinate (von AA bis ca. CB)
Welche Beziehung zwischen tbl_Signale und tbl_Einbauort besteht jetzt?
Ein Signal hat nur einen Einbauort, aber mehrere Signale können auf den selben Einbauort gehen.
Das wäre dann das Häuser-Beispiel von Wurliwurm:
Die Koordinaten sind Häuser und die Signale Menschen die darin wohnen. Und in einem Haus können mehr Menschen wohnen.
Ist das dann n:1?
Okay aber die Frage ist dann grundsätzlich geklärt: Einbauorte NICHT in die selbe Tabelle wie Signale.
Die andere Frage bleibt bestehen:
Die Tabelle tbl_Einbauorte kann nun die drei Teile direkt enthalten oder ich kann jedes einzelne der drei Teile über jeweils eine Tabelle mit tbl_Einbauorte verknüpfen.
Bei dem Planungstreffen war mein erster Instinkt das auch genau so zu machen und meine Kollegen meinten es wäre besser die Koordinaten direkt in die Tabelle zu schreiben.
Als ich erklären wollte warum die Konstruktion über verlinkte Tabellen und FK hatte ich nur das Argument: "Das macht man eben so."
Die Kollegen haben noch weniger Ahnung von Access als ich und lassen sich zum nächsten Treffen am Montag umstimmen wenn ich eine Erklärung habe warum meine Idee besser ist.
Aber außer: "das macht man so" fällt mir da nichts ein.
Okay, dann ist das mit der Beziehung Signal und Einbauort geklärt. :)
Primärschlüssel für die Tabelle Einbauort ist z.B. ein Integer oder String-Wert (EinbauortID o.ä.)
Fremdschlüssel für die Tabelle Signale ist ein Attribut (am besten auch EinbauortID) mit referenzieller Integrität und NOT NULL.
Damit ist jedes Signal immer eindeutig einem Einbauort zugeordnet.
Ich würde, sie wie ich Deine Einbauplätze verstanden habe, das Panel ganz weglassen, weil Einbauplatz und Panel das gleiche ist.
Ob die Tabelle Einbauorte doch noch weiter aufgeteilt gehört?
Die Faustregel ist, daß alle Spalten, die keine Schlüsselspalten sind, von der Schlüsselspalte und nur von der Schlüsselspalte abhängen müssen.
Wenn also das Panel in irgendeiner Weise die Koordinaten bestimmt (das heißt, wenn Du den Wert des Panel kennst, auch den Wert der Koordinaten kennst), dann solltest Du das weiter aufteilen, weil Du dann konsistentere Daten bekommst. Falls nicht, solltest Du das auch nicht weiter aufteilen. Es gibt keinen Grund dafür!
Hallo,
ZitatPrimärschlüssel für die Tabelle Einbauort ist z.B. ein Integer oder String-Wert (EinbauortID o.ä.)
Das läßt du besser gleich bleiben!
EinbauortID und JEDER andere Primärschlüssel sollte ein Long Integer-Wert sein welcher durch einen Autowert entsteht!
Strings als Primärschlüssel sind vollkommen unangebracht und Integerwerte sind zu vermeiden, da sie erstens durch
ihren Wertebereich MAXIMAL 32767 Datensätez zulassen würden und nicht durch Autoinkrement (Autowert) gebildet werden können.
Autowerte stellen zu dem die sicherste Methode dar, Primärschlüssel wirklich UNIQUE zu erstellen.
Also der Großteil der Frage ist damit geklärt.
Was mir noch nicht klar ist:
Die Tabelle der Einbauorte:
@Wurliwurm
Alle drei Daten sind wichtig. Die "Koordinaten" (001 bis 030 und AA bis CB) sind je Panel.
Also Panel 1 hat Koordinaten von AA001 bis CB030, Panel 2 auch usw.
Die Frage die bleibt, ist ob ich nur die Tabelle "Einbauorte" mache, und für die "Koordinaten" ein einfaches Datenfeld nehme, mit einem Wertebereich (Gültigkeitsregel).
Oder ob die Tabelle Einbauorte nur eine Sammlung von Fremdschlüsseln ist und über drei n:1-Beziehungen jede Koordinate mit einer eigenen Tabelle verknüpft ist in denen der Wertebereich erfasst ist.
(dass ich überall IDs zur Identifikation verwende ist klar)
Als Faustregel habe ich bisher angenommen, wenn ein Datensatz mehr als 1 Mal verwendet wird, sollte man ihn über eine verknüpfte Tabelle einlesen, nicht über einzelne Datenfelder. Und Koordinaten werden ja deutlich öfter als 1 Mal verwendet.
Es geht mir nicht nur darum zu wissen ob das besser ist, sondern auch wie ich es vor Laien begründen kann.
---
Nochmal als Beispiel falls ich mich unklar ausgedrückt habe:
Entweder so:
Tbl_Einbauort_Direkt
ID
Panel (String, Gültigkeitsregel)
X (String, Gültigkeitsregel)
Y (String, Gültigkeitsregel)
Oder so:
tbl_Einbauort_Verlinkt
ID
FK_Panel (Zahl, Foreignkey)
FK_X (Zahl, Foreignkey)
FK_Y (Zahl, Foreignkey)
tbl_Panel
ID
Panel (String- Tabelle wird vorher von mir angefertigt und ist für den Benutzer nicht editierbar)
tbl_X
ID
X (String- Tabelle wird vorher von mir angefertigt und ist für den Benutzer nicht editierbar)
tbl_Y
ID
Y (String- Tabelle wird vorher von mir angefertigt und ist für den Benutzer nicht editierbar)
Wenn Panel und Koordinaten skalare Werte sind, dann sehe ich keinen Nutzen darin, noch drei extra Tabellen anzulegen.
Nochmal der Vergleich mit dem Haus, weil das mir den Panels ist mir zu speziell:
Haus hat Grundstücksnummer (~Panel) und Koordinaten im Grundstück
Dann sollte die Tabelle drei Nichtschlüssel-Spalten (GrStuckNr, X, Y) haben.
Es sei denn, es gibt noch Daten die direkt von der Grundstücksnummer (~Panel) abhängen (z.b. Eigentümer, Farbe, kontaminiert...).
Außerdem kann es einen Unterschied machen, wenn es nur eine bestimmte Menge von Koordinaten gibt (also z.B. links oben, Mitte, halbrechts, unten) Dann könnten externe Tabellen sinnvoll sein. Es wäre dann aber eher sinnvoll, eine Koordinaten-Kombination (X,Y) unter einem gemeinsamen Schlüssel in einer extra Tabelle zu führen (also linke oben = 0,0, Mitte = 1,1 rechts unten = 2,2).
also
Tabelle Haus: *Haus, GrdStuckNr, linksUnten
Tabelle Koordinate: *linskunten, 2,2
Wenn aber die Gültigkeitsregeln zu komplex werden würden, wäre das auch bei unabhängigen X,Y-Koordinaten sinnvoll, zwei extra Wertetabellen zu haben.
Das ganze ist nicht eindeutig zu entscheiden, es kommt viel auf Intuition an. Ich meine Deine Zerlegung, die Du vorgeschlagen hast ist verlustfrei, sie erfordert aber etwas mehr Aufwand in den SQL_Abfragen.
P.S.: Hör nicht auf den anderen! ;D
ZitatAutowerte stellen zu dem die sicherste Methode dar, Primärschlüssel wirklich UNIQUE zu erstellen.
ist Käse, weil Primärschlüssel per definitionem unique sind. Die Modellierung mit Surrogatschlüsseln ist nicht nötig, und bei einer kleinen SOHO-Datenbank spielt es keine Rolle, ob String oder Zahl als Schlüssel. Selbst im SAP zum Beispiel sind Schlüssel ständig Strings und das ist kein SOHO.
Hallo,
Zitatist Käse
bist du dir da ganz sicher oder baut das auch auf einer Vermutung auf?
ZitatSelbst im SAP zum Beispiel sind Schlüssel ständig Strings
Ist ja dann auch wahrscheinlich mit ein Grund, warum die Software aus Pakistan so performant läuft.
Vielleicht solltest du dir besser die Mühe machen und dem FS erklären warum Strings
nicht als PK geeignet sind - hierbei wäre es dann angebracht den technischen Hintergrund zu erwähnen ...
Zitat von: database am März 28, 2011, 14:00:18
Hallo,
Zitatist Käse
bist du dir da ganz sicher oder baut das auch auf einer Vermutung auf?
http://www.dbwiki.net/wiki/Prim%C3%A4rschl%C3%BCssel
"... Im Bereich der Relationalen Datenbanken bezeichnet der Primärschlüssel ein Attribut einer Relation (Tabelle), das einen Datensatz dieser Relation eindeutig identifiziert / kennzeichnet.
Damit dieses gewährleistet wird, kann ein Primärschlüsselwert nur ein einziges Mal in einer Tabelle vorkommen. Ein Primärschlüsselwert ist daher UNIQUE (einzigartig)..."
http://office.microsoft.com/de-ch/access-help/hinzufugen-festlegen-andern-oder-entfernen-des-primarschlussels-HA010014099.aspx
" ...In Access wird automatisch ein Index für den Primärschlüssel erstellt, durch den Abfragen und andere Vorgänge beschleunigt werden können. In Access wird auch sichergestellt, dass jeder Datensatz einen Wert im Primärschlüsselfeld enthält und dass dieser immer eindeutig ist...."
Es braucht keinen zusätzlichen Kunst-Schlüssel, und schon gar nicht in einer so kleinen Datenbank. Bei Access: Ob String_PK oder nicht numerisch, ist der Unterschied zwischen Trabbi mit und ohne Spoiler.
Zitat
Ist ja dann auch wahrscheinlich mit ein Grund, warum die Software aus Pakistan so performant läuft.
Rischtisch!!! Da spricht der Fachmann!!! ;-)
Ich denke mal dass du dir besondere Mühe gibst Dinge aus dem Zusammenhang zu reissen...
Was ein Primärschlüsel ist und was der kann brauchst DU mir nicht erklären!
Wie Access funktioniert dürfte ich inzwischen auch schon begriffen haben.
Was du aber noch nicht überrissen haben scheinst, ist die Tatsache, dass es einem FS absolut nichts bringt, wenn man ihm schon von Anfang an Dinge reinwürgt, die bei der nächsten Gelegenheit zu Problemen führen. Ob nun Strings bei einer DB-Größe von ... blabla oder du Access mit einem Trabbi vergleichen willst wird einem FS wohl kaum die große Erkenntnis liefern können.
Und um das Ganze nicht in eine Richtung abgleiten zu lassen die hier sowieso keinen interessiert und auch keinem was bringt, sehe ich die Diskussion mit dir als beendet an.
Würde mich freuen, wenn du das ähnlich sehen könntest
Meine Überzeugung ist, daß ein Anfänger in relationalen Datenbanken unbedingt verstehen muß, daß ein Primärschlüssel aus mehreren Attributen zusammengesetzt sein kann. Deshalb meine ich, daß es den Zugang zum Verständnis von relationaler Algebra verstellt, wenn dogmatisch gefordert wird, als "Primärschlüssel" ein Attribut hinzuzufügen, das in keinerlei Beziehung zu den restlichen Attributen einer Relation steht.
Was den Trabbi-mit-Spoiler-Vergleich angeht, so meine ich damit gerne polemisch, daß Access eine SOHO-Anwendung ist und alles "Tuning" nichts daran ändern kann. Die Frage, ob Access für sicherheits- und performancekitische Anwendungen geeignet ist, ist keine Ketzerfrage und muß auch in einem Access-manischen Forum gestellt werden dürfen .
Ich zweifle nicht daran, daß Du sehr gute theoretische und praktische Kenntnisse mit relationaler Algebra und MS-Access hast und bewundere Deinen Einsatz und Deine Geduld hier im Forum. Einen Lehrauftrag hast Du hier allerdings nicht und als Vielschreiber kein Recht, andere Gelegentlichschreiber abzukanzeln. Mir wäre es recht, wenn Du davon in Zukunft absehen würdest.
Hallo,
ich habe aber auch die Erfahrung gemacht (nicht zuletzt aus verschiedenen Foren), dass man zunächst auf einen expliziten PK verzichten kann und der zusammengesetzte PK aussreicht. Im späteren Verlauf der Entwicklung der DB kommt man aber plötzlich zur Notwendigkeit doch einen eindeutigen PK zu haben. Der dann erforderliche Umbau der DB ist aufwendiger als den PK gleich einzubauen. Daher neige ich aus rein pragmatischen Gründen auch dazu immer einen PK zu erstellen und nie einen zusammengesetzten PK zu verwenden.
Auch unbetrittene Access Gurus (Allen Browne) verwenden diesen künstlichen PK.
Microsoft Access Tips for Casual Users (http://allenbrowne.com/casu-23.html)
Zitat von: MzKlMu am März 29, 2011, 10:44:22
Im späteren Verlauf der Entwicklung der DB kommt man aber plötzlich zur Notwendigkeit doch einen eindeutigen PK zu haben.
Der PK ist immer per definition eindeutig, auch wenn er viele Attribute umfasst. Ich meine mit PK den relationalen PK und nicht die technische Umsetzung. Das sind zwei unterschiedliche Ebenen, wo man perfekt aneinander vorbeireden kann, wenn man darüber nicht im klaren ist. Strenggenommen ist der Surrogatschlüssel eine Verletzung der 3. Normalform.
Hallo!
ZitatMeine Überzeugung ist, daß ein Anfänger in relationalen Datenbanken unbedingt verstehen muß, daß ein Primärschlüssel aus mehreren Attributen zusammengesetzt sein kann.
Dem stimme ich zu 100% zu. Es kommt für mich beim Lesen der obigen Beiträge allerdings so rüber, als wären Surrogatschlüssel "ganz böse" und man darf die niemals einsetzen. ... Das betrachte ich allerdings wiederum als Quatsch. Es kommt einfach darauf an, was man erreichen will. Meiner Ansicht nach kann man keine pauschale - immer gültige - Regel für PK-Bildung (mehrer Attribute vs. Surrogatschlüssel) aufstellen, da das zu sehr von den Anforderungen abhängt, was mit der Tabelle passieren soll.
Das Argument "die Verknüpfung ist bei mehreren Felder umständlicher" sollte meiner Meinung nach aber kein Argument gegen einen FK mit mehreren Attributen sein. Ich vermeide aber z. B. FK mit mehreren Attributen, wenn sich im Lauf der Zeit ein Wert aus diesen Attributen im dazugehörenden eindeutigen Index (muss nicht zwangsweise der PK sein) ändern könnte.
Autowerte (Sequences) verwende ich z. B. gerne, wenn ich es dem Anwendungsuser (bzw. der Geschäftsregel) nicht zutraue eine geeignete eindeutige Kennung für einen Datensatz zu formulieren.
Beispiel "Rechnung": hier ist ja bereits aus gesetzlichen Vorschriften eine eindeutige "Rechnungsnummer" vorgeschrieben => diese kann man auch gleich als PK verwenden, da sie einmal festgelegt und später nie wieder geändert werden wird.
Rechnungspositionen: Sollte man die Rechnungsnummer und die Positionsnummer als PK verwenden? Was ist dann aber mit den davon abhängigen Tabellen, die diese beiden Felder als FK verwenden, wenn der Anwender die Postionen in der Rechnung "umsortiert"? => für diesem Fall setze ich einen Surrogatschlüssel (bzw. eine intern erstelle laufende Nummer je Rechnungsnummer) ein, damit keine Abhängigkeit zu einem vom User änderbaren Attribut entsteht.
Klar, man könnte die Indexänderung übers DBMS weitergeben lassen (update cascade) - damit verliere ich aber die Zugehörigkeit dieses Datensatzes zur DS-Kennung aus früheren Backups. => Surrogatschlüssel bzw. "intern erstellte" laufende Nummer, die nach der Erstellung nicht mehr geändert wird, ist mir lieber.
ZitatDie Frage, ob Access für sicherheits- und performancekitische Anwendungen geeignet ist, ist keine Ketzerfrage und muß auch in einem Access-manischen Forum gestellt werden dürfen .
Das ist einfach zu beantworten: Da Access nur eine RAD-Umgebung ist und kein DBMS, kann man jedes andere DBMS für solche Fälle einsetzen. ;)
Das mit Access mitgelieferte DBMS (JET/ACE) ist file-basiert und wird somit in einer Mehrbenutzerumgebung niemals so performat wie ein aktives DBMS (mit genügend Server-Kapazität) sein. Bei überschaubaren Strukturen und lokaler DB-Ablage kann Jet aber sogar schneller als eine aktives DBMS sein - und wenn man das aktive DBMS nicht ausnutzt, wird damit die Performance auch nicht begeistern. ;)
ZitatIm späteren Verlauf der Entwicklung der DB kommt man aber plötzlich zur Notwendigkeit doch einen eindeutigen PK zu haben. Der dann erforderliche Umbau der DB ist aufwendiger als den PK gleich einzubauen.
Das machte ich auch schon öfters. In so einem Fall ergänze ich den Autowert in der Tabelle, stelle dafür einen eindeutigen Index ein und verwende bei Bedarf diesen Index als Fremdschlüssel. Die bereits vorhandenen Tabellen, welche den PK mit mehreren Attributen verwenden, müssen aber deswegen nicht umgestellt werden.
Typischer Fall: n:m-Tabelle
Normalerweise verwende ich in diesen Tabellen die 2 "Verknüpfungsfelder" als PK, wenn die Kombination nur 1x vorkommen darf. Irgendwann erweitere ich aber vielleicht das DB-Modell und erstelle Tabellen, die sich auf so einen DS beziehen. => FK mit 2 Attributen wäre denkbar. Jetzt könnte es aber sein, dass der Anwender eines dieser beiden Attribute nachträglich ändern darf => Damit ich nun trotz Änderung des PK immer erkennen kann, welchem DS das in früheren DB-Backups entspricht, füge ich einen Autowert als weiteren eindeutigen Schlüssel ein und nutze in den abhängigen Tabellen diesen Schlüssel als PK.
mfg
Josef
Zitat von: Josef P. am März 29, 2011, 11:38:37
Es kommt für mich beim Lesen der obigen Beiträge allerdings so rüber, als wären Surrogatschlüssel "ganz böse" und man darf die niemals einsetzen.
Nein. Ärgern tut mich, wenn ein "Access-Meister" daher kommt und meint, Surrogatschlüssel müsse man immer einsetzen, weil sich "das so gehört". Wie gesagt, für den Anfänger erschwert das das Verständnis des Schlüsselkonzepts.