Einsteigerfrage

Datenbanklösungen mit AOO/LO

Moderator: Moderatoren

AndreasJBittner
*****
Beiträge: 473
Registriert: Fr, 09.10.2009 16:44
Wohnort: Bielefeld
Kontaktdaten:

Re: Einsteigerfrage

Beitrag von AndreasJBittner »

Hallo Oeli,

Du machst den dritten und vierten Schritt, bevor Du den ersten fertig gemacht hast. Wie sehen denn Deine Tabellen überhaupt aus? Bleibst Du in OOo oder hast Du MySQL, postgres,... oder eine andere DB im Hintergrund?

Deine Tabelle Fundorte müßte mindestens haben:
ID (integer autoincrement primary key); Ort (varchar) für den Namen; ?Koordinaten, ?Klima, ?Geologie, ???

Deine Tabelle Funde müßte mindestens haben:
ID (integer autoincrement primary key); FK_Ort (integer) für die ID aus T_Fundort; ?Alter, ?Werkstoff, ?Anzahl, ???

Dabei setze ich schon voraus, daß Du den Fundort dem Fund (s. FK_Ort; FK=Foreign Key) verbinden willst. Wenn hinter Werkstoff zB Knochen, Elfenbein, Bronze, Gold.... steht, sollte man dafür eine eigene Tabelle anlegen (mit ID,...) und in Fund nur wieder den FK_Werkstoff (integer) ablegen. Damit vermeidest Du übrigens auch Dein Problem mit dem Kombinationsfeld -- das gibt es dann nicht, Du hast ja die 1:n-Beziehung Fundort-Fund und über die Eigenschaft primary key, die Du dann mehreren Feldern geben müsstest, gibt es auch keine doppelten Einträge

Die von Dir gewünschte Tabelle 3 ist dann überflüssig, es reicht eine Abfrage bzw. ein VIEW auf Deine Daten aus den Tabellen 1 und 2, wenn nämlich bei Anlage eines Fundes in FK_Ort die ID des Ortes eingetragen wird, bekommst Du mit

Code: Alles auswählen

SELECT Ort, Tabelle2.ID AS FundNr, Werkstoff FROM Tabelle1, Tabelle2 WHERE ... {Bedingungen}
immer eine aktuelle "Tabelle" Deiner Daten auch ohne, daß Du eine dritte Tabelle so wie von Dir angedacht pflegen mußt.
Je besser Du Deine DB planst und die Tabellen aufstellst, umso leichter ist die zu pflegen und umso flexibler kannst Du Deine Daten abfragen.

Grüße
Andreas
LO 4.3
AMD Athlon 64 3700+, 2.21 GHz, 4 GB RAM, Win XP SP3
iMac 2 GHz, 16 GB RAM/MacBookPro, 8 GB RAM, Mac OS X 10.9.5
Intel Core2 Quad CPU Q6600 @ 2,4 GHz, 4 GB RAM, Suse 13.2

MySQL 5.1: Pentium III, 666 MHz, 512 MB, Suse 12.1
AndreasJBittner
*****
Beiträge: 473
Registriert: Fr, 09.10.2009 16:44
Wohnort: Bielefeld
Kontaktdaten:

Re: Einsteigerfrage

Beitrag von AndreasJBittner »

Oeli,

lies bitte noch einmal, was ich über die Foreign Keys geschrieben habe, dann wirst Du sehen, daß Deine Tabelle3 überflüssig und Dein Konsistenzproblem nicht vorhanden ist.
Die 1:n-Beziehung ergibt sich nur zwischen den Tabellen 1 und 2 durch den Eintrag der Fundort-ID in eine Spalte der Fund-Tabelle.
Schmeiß Deine Tabelle 3 weg...

Grüße
Andreas
LO 4.3
AMD Athlon 64 3700+, 2.21 GHz, 4 GB RAM, Win XP SP3
iMac 2 GHz, 16 GB RAM/MacBookPro, 8 GB RAM, Mac OS X 10.9.5
Intel Core2 Quad CPU Q6600 @ 2,4 GHz, 4 GB RAM, Suse 13.2

MySQL 5.1: Pentium III, 666 MHz, 512 MB, Suse 12.1
DPunch
*******
Beiträge: 1112
Registriert: Mo, 02.11.2009 16:16
Wohnort: Marburg

Re: Einsteigerfrage

Beitrag von DPunch »

Aloha
AndreasJBittner hat geschrieben:Die 1:n-Beziehung ergibt sich nur zwischen den Tabellen 1 und 2 durch den Eintrag der Fundort-ID in eine Spalte der Fund-Tabelle.
Schmeiß Deine Tabelle 3 weg...
Er schreibt doch, dass seine Tabelle 2 Deinem Vorschlag von einer "Werkstoff"-Tabelle entspricht.

Und dann braucht er *zwingend* eine Auflösung der n:m Beziehung.
Tabelle 1: Ort
Tabelle 2: Werkstoffe
Tabelle 3: Ort + Werkstoff + X
AndreasJBittner
*****
Beiträge: 473
Registriert: Fr, 09.10.2009 16:44
Wohnort: Bielefeld
Kontaktdaten:

Re: Einsteigerfrage

Beitrag von AndreasJBittner »

Hallo Oeli,

im Moment sehe ich die Notwendigkeit der n:m-Tabelle noch nicht. Ich habe eine Tabelle Orte (1..n) und ich kann über den FK einem Ort beliebig viele Funde zuordnen. Wenn ich die Daten richtig normalisiere (http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)), habe ich als dritte Tabelle erstmal die Werkstoff-Tabelle. Also sind Orte, Funde und Stoffe über die Kette T_Ort (FK) 1:n -> T_Fund (FK) 1:n -> T_Stoff abgebildet. Die eine (oder mehrere) Spalten, die in den drei Tabellen für die Eindeutigkeit des jeweiligen Datensatzes und -bestandes verantwortlich sind, sollten als Primary Key definiert werden. Beispiel: Vorname, Name und Geburtsort gemeinsam als Schlüssel reicht wohl nicht (Hans, Müller, München), man wird noch das Geburstdatum dazunehmen müssen.

Wenn Du dann eine dritte Tabelle, um die m:n-Beziehung darzustellen, brauchst, stehen aber in der nicht die Daten sondern nur die Fremdschlüssel aus beiden Tabellen, also nur die IDs der jeweiligen Daten. Bis jetzt habe ich bei den Fragen aber den Eindruck, daß die ersten Tabellen noch nicht vollständig durchdacht sind und verstehe noch nicht, was in einer eigenen Tabelle n:m abgebildet werden soll. Die Kombinationen Fundort/Fund stehen doch implizit in beiden Tabellen in den FK.
SELECT Orte, Funde FROM T_Fundort, T_Funde WHERE T_Fundort.ID = T_Fund.FK_Ort GROUP BY Orte ORDER BY Orte
liefert dann die Orte und alle Funde dazu. Wenn man noch die T_Stoffe einbaut, gibts auch dazu Informationen und wenn man das Statement anders sortiert, kann man Stoffe oder Funde an den Anfang stellen und sich die entsprechenden Orte auflisten lassen. Solange die Eindeutigkeit in allen drei Tabellen gewährleistet ist, brauche ich hier noch keine n:m-Tabelle.

Grüße & schönen Abend noch
Andreas
LO 4.3
AMD Athlon 64 3700+, 2.21 GHz, 4 GB RAM, Win XP SP3
iMac 2 GHz, 16 GB RAM/MacBookPro, 8 GB RAM, Mac OS X 10.9.5
Intel Core2 Quad CPU Q6600 @ 2,4 GHz, 4 GB RAM, Suse 13.2

MySQL 5.1: Pentium III, 666 MHz, 512 MB, Suse 12.1
Antworten