Foreign keys ?

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo,
Frage an die Profis:

Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf einen Primary-Key eines Datensatzes in Tabelle „b“ und verbindet so beide miteinander.

Heißt das, Tabelle „b“ ist die Mastertabelle???

Wenn jetzt Daten in Tabelle b eingegeben werden, wie wird dann gleichzeitig ein dazugehöriger Datensatz in Tabelle a erzeugt?
Geht das überhaupt?
Oder muß anschließend (manuell) ein Datensatz in Tabelle a erzeugt werden der DANN den Key-Wert des grade erzeugten Satzes aus b erhält?

Danke schon mal.

Gruß

#2

Auch hallo.

Hallo,
Frage an die Profis:

oh, welches DBMS ?

Der Foreign Key eines Datensatzes der Tabelle „a“ :verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.

Also eine Join Operation

Heißt das, Tabelle „b“ ist die Mastertabelle???

Also noch sind die jeweiligen Tabellen eigenständig. So gesehen eher nein. Aber man werfe einen Blick auf die Mindmap unter http://www.schnydrig.ch/Mindmap_PDF/I-10-Datenbank-G…
(suche nach fremd)

Wenn jetzt Daten in Tabelle b eingegeben werden, wie :wird dann
gleichzeitig ein dazugehöriger Datensatz in Tabelle a :erzeugt?

Wenn kein Trigger oder eine gemeinsame Tabelle D mit gemeinsamen Schlüssel verwendet wird: gar nicht

Geht das überhaupt?

s.oben

Oder muß anschließend (manuell) ein Datensatz in :Tabelle a
erzeugt werden der DANN den Key-Wert des grade :erzeugten
Satzes aus b erhält?

via Trigger oder manuell: ja

HTH
mfg M.L.

***noch ein wenig Werbung***
http://www.datenbank-portal.de
http://www.plsql.de

#3

Hi Reiner,

Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.

Heißt das, Tabelle „b“ ist die Mastertabelle???

im SQL gibt es den Begriff Master nicht. a ist die referierte Tabelle, manchmal auch als parent table bezeichnet.

Wenn jetzt Daten in Tabelle b eingegeben werden, wie wird dann
gleichzeitig ein dazugehöriger Datensatz in Tabelle a erzeugt?

Gar nicht.

Oder muß anschließend (manuell) ein Datensatz in Tabelle a
erzeugt werden der DANN den Key-Wert des grade erzeugten
Satzes aus b erhält?

Andersrum: Erst muss der Key in a vorhanden sein, dann kann von b aus ein Bezug auf a hergestellt werden.

In Dialogen können natürlich beliebige Tricks versteckt werden, so zB das heimliche Anlegen eines Satzes in a und das anschließende Einrichten von b sowie das Aufbauen der Verknüpfung. Ist aber nicht empfehlenswert.

Gruß Ralf

#4

Hallo,
ein CONSTRAINT wie der PRIMARY KEY oder der FOREIGN KEY, der CHECK und der UNIQUE definieren Einschränkungen.
Ein FOREIGN KEY schränkt die erlaubten Werte auf die Werte ein, die bereits in der anderen Tabelle stehen.
Automatisch geht da nichts. Wie denn auch. Die DB kann schließlich nicht ahnen, welche Werte du eingeben willst.

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#5

Hallo Ralf,
also für mich ist das:

Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.

Andersrum: Erst muss der Key in a vorhanden sein, dann kann
von b aus ein Bezug auf a hergestellt werden.

nicht richtig. Erst muss ich doch den Satz haben, auf den der Foreign Key zeigen soll, also in diesem Fall: erst b, dann a. Hast du das falsch gelesen oder bin ich unterkoffeiniert?

Und zum eigentlichen Thema: Wann du welchen Datensatz in die Tabellen schreibst, sollte dir die Geschäftslogik für deine Applikation vorgeben. Aber (wenn man von solchen Sachen wie vorübergehendem Ausschalten der referentiellen Integrität absieht) erst muss der „Parent“ da sein, bevor irgendwelche „Children“ eingefügt werden können. Beispiel: Erst Auftragskopf, dann Auftragsposition etc.

Grüßt: Guido

#6

Hallo,

und danke für die Antworten.
Haben mir weitergeholfen - glaube ich :o)

D.h., ich könnte also 2 tabellen kreieren.
Tabelle „b“ (parent), und die referierende „a“ (child).

Wenn ich jetzt einen Datensatz in „b“ anlege, könnte also ein Trigger dafür sorgen, dass „geleichzeitig“ ein Datensatz in „a“ erzeugt wird, der automatisch die id des in „b“ erzeugten Satzes enthält und somit seine Verknüpfung erhält?!?

Gruß

#7

Hallo,

jein. Je nach Datenbank.

Oracle - kein Problem (sag ich jetzt mal so einfach)
SQL-Server - mit deferrable Constaints sicher auch
MySQL - was sind Trigger?
Access - Hahahahaaaaaaaaa

Welche DB nimmst Du?

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#8

Hallo an dieser Stelle.

jein. Je nach Datenbank.

Stimmt

Oracle - kein Problem (sag ich jetzt mal so einfach)

könnte man mit OracleXE und einem guten Skript ja mal herausfinden :wink:

SQL-Server - mit deferrable Constaints sicher auch

Kann sein (ab der 2005’er Version)

MySQL - was sind Trigger?

Seit der Version 5.0 ‚drin‘: http://www.mysql.com/training/courses/mysql_5_new_fe…

Access - Hahahahaaaaaaaaa

*ggg*

mfg M.L. (Schlachtpotential: Oracle10g XE, SQL Server 2005, MySQL 4.x -5.x :smiley:)

#9

Hallo,

Hallo,

jein. Je nach Datenbank.

Oracle - kein Problem (sag ich jetzt mal so einfach)
SQL-Server - mit deferrable Constaints sicher auch
MySQL - was sind Trigger?
Access - Hahahahaaaaaaaaa

Welche DB nimmst Du?

Mysql
hat seit Version 5.x(?) jetzt Views und Trigger … :o)
(werd´s zumindest mal ausprobieren obs so funktioniert wie ich´s mir vorstelle)

Gruß

Peter

Hallo,

und danke für die Antworten.
Haben mir weitergeholfen - glaube ich :o)

D.h., ich könnte also 2 tabellen kreieren.
Tabelle „b“ (parent), und die referierende „a“ (child).

Wenn ich jetzt einen Datensatz in „b“ anlege, könnte also ein
Trigger dafür sorgen, dass „geleichzeitig“ ein Datensatz in
„a“ erzeugt wird, der automatisch die id des in „b“ erzeugten
Satzes enthält und somit seine Verknüpfung erhält?!?

Gruß

Gruß

#10

Hi Guido,

Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.

wo der primary key als Quelle für den foreign key steht, da ist das parent. Beim Antworten ist meine Logik Amok gelaufen: Ich käme nicht auf die Idee, erst das child in die Diskussion zu werfen und dann das parent :smile:))

Gruß Ralf

#11

Hallo,

Mysql
hat seit Version 5.x(?) jetzt Views und Trigger … :o)
(werd´s zumindest mal ausprobieren obs so funktioniert wie
ich´s mir vorstelle)

Gruß

Hallo,

und wie übergibst du dem Trigger die Daten (außer dem Key, den hat er ja), die er in die „Child-Tabelle“ schieben soll?

Grüßt fragend: Guido

#12

Fachlicher Hintergrund
Moin, Reiner,

D.h., ich könnte also 2 tabellen kreieren.
Tabelle „b“ (parent), und die referierende „a“ (child).

das könntest Du.

Wenn ich jetzt einen Datensatz in „b“ anlege, könnte also ein
Trigger dafür sorgen, dass „geleichzeitig“ ein Datensatz in
„a“ erzeugt wird, der automatisch die id des in „b“ erzeugten
Satzes enthält und somit seine Verknüpfung erhält?!?

Wozu sollte das gut sein? b heiße zB Bestellung, a Bestellposition. Dann legst Du zur Bestellung eine leere Bestellposition an, die außer der ID des parents nichts enthält. Und dann?

Gruß Ralf

#13

Hallo,

als Default-Werte entweder …

oder (denkbares Bsp. …)
Adressdaten stehen in der Parent + Infos zu den Adressdaten in der Child.

Adressdaten sind vorhanden und werden eingespielt.
Die Infos sollen nachträglich zugefügt werden.

Jetzt hat also - nach dem Einfügen - jede Adresse eine Verknüpfung mit einem leeren Info-Datensatz.

Die Daten-Bearbeiter sehen über eine view die ausgewählten Adress- und Infodaten und können sie bearbeiten ohne dass sie eigene Datensätze anlegen können müssen.

(über views kann man in mysql editieren etc.)

Gruß

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]