Foreign Key MariaDB

[akretschmer]

Du verwechselst etwas. Datentypen sind Eigenschaften eines Feldes. Ein Feld kann nicht gleichzeit DATE und NUMERIC sein, der Datentyp eines Feldes muß eindeitig sein. Ein PRIMARY KEY ist eine Eigenschaft der Tabelle, er kennzeichnet eindeitig einen bestimmten Datensatz. Also, ein Feld kann nicht gleichzeitig 2 Datentypen haben, eine Tabelle nicht gleichzeitig 2 PK.

 

[Mikana]

So. Ich konnte nun zwei FKs setzen, jedoch keinen zweiten PK, der ja nun wichtig ist, um eindeutig zu sein.

MariaDB [funkel_reisen]> ALTER TABLE t_buchungen ADD FOREIGN KEY (KUNDENID) REFERENCES t_kunde (KUNDENID);
Query OK, 0 rows affected (0.056 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [funkel_reisen]> ALTER TABLE t_buchungen ADD FOREIGN KEY (FAHRTENID) REFERENCES t_fahrt (FAHRTENID);
Query OK, 0 rows affected (0.068 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [funkel_reisen]> ALTER TABLE t_buchungen ADD PRIMARY KEY (FAHRTENID);
ERROR 1068 (42000): Multiple primary key defined
MariaDB [funkel_reisen]>

 

[Mikana]

Du verwechselst etwas. Datentypen sind Eigenschaften eines Feldes. Ein Feld kann nicht gleichzeit DATE und NUMERIC sein, der Datentyp eines Feldes muß eindeitig sein. Ein PRIMARY KEY ist eine Eigenschaft der Tabelle, er kennzeichnet eindeitig einen bestimmten Datensatz. Also, ein Feld kann nicht gleichzeitig 2 Datentypen haben, eine Tabelle nicht gleichzeitig 2 PK.

Nee, nee. Verwechselt habe ich das nicht. Zumindest nicht in meinem Kopf.
Wenn ich eine Relation (Tabelle) erstelle, dann setze ich meine Attribute dort in das sogenannte Datenfeld, richtig? Und der Datentyp beschreibt die Form. Also sowas wie Varchar, INTEGER, und so weiter. So habe ich das zumindest verstanden.

 

[dabadepdu]

MariaDB [funkel_reisen]> ALTER TABLE t_buchungen ADD PRIMARY KEY (FAHRTENID);
ERROR 1068 (42000): Multiple primary key defined
MariaDB [funkel_reisen]>

DeepL Translate: The world's most accurate translator

Translate texts & full document files instantly. Accurate translations for individuals and Teams. Millions translate with DeepL every day.

www.deepl.com

Es gibt bereits einen Primärschlüssel in der Tabelle.

 

[akretschmer]

So. Ich konnte nun zwei FKs setzen, jedoch keinen zweiten PK, der ja nun wichtig ist, um eindeutig zu sein.

Jedes Feld einer Tabelle KANN eine Referenz auf eine andere Tabelle haben. Aber es gibt EXAKT keinen Grund, 2 PRIMARY KEYS definieren zu wollen.

 

[dabadepdu]

Primary Key = Primärschlüssel
Der "erste Schlüssel" dient der eindeutigen Identifikation eines Datensatzes in einer Tabelle.
Wenn man also primäre Schlüssel hat, könnte man gemäß Deiner Frage annehmen, dass es auch sekundäre Schlüssel gibt (Alternate Key, Surrogate Key, ..) Die gibt es auch, aber im Unterschied zum Primärschlüssel gibt es dazu meist kein direktes SQL Konstrukt, das diese Regel beschreibt.
Sekundärschlüssel haben hauptsächlich eine logische Bedeutung und wenn man die funktional nutzen will und sicherstellen will, dass sie nutzbar bleibt und eingehalten wird, dann definiert man dazu einen Unique Index.

Beispiel Tabelle benutzer:
Spalte ID, Integer, Primär Schlüssel
Spalte Kundennummer, Varchar

Die ID ist der technische Primärschlüssel, der in allen SQL Statements verwendet wird und auch für Foreign Keys (Fremdschlüssel) als Ziel dient. Er ist per Definition eindeutig, das wird per Primary Key Constraint (Primärschlüsselregel) garantiert und unterstützt durch einen Unique Index, der sowohl Eindeutigkeit als auch schnelle Auffindbarkeit schafft.
Die Kundennummer ist naturgemäß ebfenfalls eindeutig, sie wird in einer separaten Spalte geführt und über einen Unique Index abgesichert und schnell auffindbar gemacht. Das ist nicht ein 2. Primärschlüssel, sondern ein Sekundärschlüssel/Surrogate Key/Alternate Key...

 

[akretschmer]

um das von @dabadepdu eben gesagte in SQL zu formulieren:

postgres=# create table bla(id int primary key, b int not null unique, c int not null unique, d int not null unique);
CREATE TABLE
postgres=# 
postgres=# \d bla
                Table "public.bla"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 id     | integer |           | not null | 
 b      | integer |           | not null | 
 c      | integer |           | not null | 
 d      | integer |           | not null | 
Indexes:
    "bla_pkey" PRIMARY KEY, btree (id)
    "bla_b_key" UNIQUE CONSTRAINT, btree (b)
    "bla_c_key" UNIQUE CONSTRAINT, btree (c)
    "bla_d_key" UNIQUE CONSTRAINT, btree (d)

postgres=#

 

[dabadepdu]

Wenn ich eine Relation (Tabelle) erstelle, dann setze ich meine Attribute dort in das sogenannte Datenfeld, richtig? Und der Datentyp beschreibt die Form. Also sowas wie Varchar, INTEGER, und so weiter. So habe ich das zumindest verstanden.

Attribut = Datenfeld = Spalte = Eigenschaft eines Datensatzes in der Tabelle.
Datentyp = eine Eigenschaft eines Attributs

 

[dabadepdu]

Vielleicht noch als Ergänzung:
Ein Primärschlüssel hält keine Daten, die den Nutzer fachlich interessieren. Das ist eine reine Zweckveranstaltung, ein (zentrales) Hilfskonstrukt in relationalen DB. Den einzigen Zweck dafür hatte ich oben schon genannt. Deswegen gibt es keinen 2. Primärschlüssel.
Ein Sekundärschlüssel ist dagegen etwas, was eine fachliche Bedeutung hat. Ein Merkmal des Datensatzes, das allermeist auch dem Benutzer fachlich etwas sagt. (Kundennummer, E-Mail Adresse, Kontonummer..)
Randnotiz: Je nach Datenmodell kann ein Primärschlüssel aus mehreren Spalten bestehen. Die Schlüsselinformation steckt also nicht in einer Spalte (nicht eindeutig), sondern in 2 oder 3, erst damit ergibt sich Eindeutigkeit. Die 2. oder 3. Spalte des Primärschlüssels nennt man auch nicht 2. Primärschlüssel! Der Schlüssel insgesamt, besteht aus mehreren Spalten.

 

[Mikana]

Jedes Feld einer Tabelle KANN eine Referenz auf eine andere Tabelle haben. Aber es gibt EXAKT keinen Grund, 2 PRIMARY KEYS definieren zu wollen.

Aber wenn meine Relation aus der 3. NF eine m zu n Beziehung hat, dann wird der Beziehungstyp zu einer neuen Relation und erhält sowohl die beiden PKs der jeweiligen vorherigen Relationen und diese werden doch auch zeitgleich FKs.
So zumindest in meinen Schulunterlagen...

 

[Mikana]

Auf alle Fälle habt ihr mir hier schon ganz, ganz toll geholfen und ich bedanke mich an dieser Stelle. Meine 1 wird save =)

 

[akretschmer]

Aber wenn meine Relation aus der 3. NF eine m zu n Beziehung hat, dann wird der Beziehungstyp zu einer neuen Relation und erhält sowohl die beiden PKs der jeweiligen vorherigen Relationen und diese werden doch auch zeitgleich FKs.
So zumindest in meinen Schulunterlagen...

ich versteh nicht, was uns der Künstler damit sagen will ...

 

[dabadepdu]

erhält sowohl die beiden PKs der jeweiligen vorherigen Relationen und diese werden doch auch zeitgleich FKs.

Er erhält die Werte der PK, in verschiedenen Spalten (oft 2 Spalten z.B.), aber PK sind es nur in den Originaltabellen. In der (neuen) Relationstabelle wird es ein neuer PK, eigenständig, der sich aus den Werten (2 z.B.) der beiden Spalten zusammensetzt. Ergibt einen neuen PK, der aus (2 z.B.)FK besteht.
Tabelle bücher
bücher.id ist ein PK

Tabelle entleiher
entleiher.id PK ist ein PK

Tabelle entliehen

entliehen.bücher_id       ist ein FK>bücher       -\
                                                    - ist ein PK (von Tabelle entliehen)
entliehen.entleiher_id    ist ein FK>entleiher    -/

Buch A, Buch B, Buch C

Entleiher 1, Entleiher 2, Entleiher 3

entliehen
1, A
1, C
2, B

Entleiher 1 hat 2 Bücher geliehen, der andere 1. Die Foreign Keys auf Entleiher und Buch sind zusammengenommen ein eindeutiger Schlüssel in Tabelle entliehen und können als PK definiert werden.