Grundsatzfrage Tabellen und ER-Modell

[OPS]

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.

[MzKlMu]

Hallo,

Ist 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.

[OPS]

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?

[MzKlMu]

Hallo,
ich versteh jetzt ehrlich gesagt, Dein Problem nicht.

Wenn es mehrere gibt 1:n Tabelle erforderlich.

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?

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.

[database]

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.

Ja, 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.

[Wurliwurm]

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.

[OPS]

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.

[Wurliwurm]

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!

[database]

Hallo,

Primä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.

[OPS]

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)

[Wurliwurm]

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!  

Autowerte 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.

[database]

Hallo,

ist Käse

bist du dir da ganz sicher oder baut das auch auf einer Vermutung auf?

Selbst 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 ...

[Wurliwurm]

Hallo,

ist 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.

Ist ja dann auch wahrscheinlich mit ein Grund, warum die Software aus Pakistan so performant läuft.

Rischtisch!!! Da spricht der Fachmann!!!  ;-)

[database]

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

[Wurliwurm]

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.