Hinweis zu Design-Beziehungen zwischen Tabellen

Question

Ich habe Informationen über Musikalben, die ich in RDBMS-Tabellen mit Beziehungen zwischen ihnen organisieren möchte. Ich habe folgende Informationen für jedes Album: Interpret, Albumname, Jahr, Label, Genre, Stil, Bewertung. Bis jetzt denke ich, um 4 Tische zu machen - Künstler, Alben (Name, Jahr, Etikett, Bewertung), genre1 und genre2 (jedes Genre mit seinen Stilen). Auf dem Diagramm sieht es wie folgt aus:

Aber wissen noch nicht, wie kann ich eine Verbindung zwischen den Alben und den anderen drei Tabellen etablieren? Wenn ich zum Beispiel eine Frage select name from artists ausführen möchte, möchte ich ein Album mit dem entsprechenden Künstler und Genre-Stil erhalten.

Wie sollte ich eine Beziehung zwischen den Tabellen in diesem Fall herstellen?

Answer 1

Sie müssen eine Einführung in relationale Datenbanktabellen & Abfrage lesen.

Die "Relationen" zwischen Tabellen, von denen Sie sprechen, sind FKs (Fremdschlüssel). Ein FK besagt, dass Werte für eine Liste von Spalten in einer Tabelle als Werte für eine andere Liste von Spalten in einer Tabelle angezeigt werden, die dort einen PK (Primärschlüssel) oder einen UNIQUE-Satz bilden. Sie müssen FKs nicht zur Abfrage deklarieren oder verwenden. Wie alle Einschränkungen, einschließlich PK & UNIQUE, sind sie für das DBMS, um fehlerhafte Datenbankzustände auszuschließen.

A (Basis- oder Abfrageergebnis) Tabelle repräsentiert eine (Geschäfts-/Anwendungs) -Beziehung (Schiff)/Assoziation. Eine Tabelle enthält die Zeilen, die einige echte Proposition (Anweisung) von einem zugeordneten Prädikat (Anweisung Vorlage) machen. Das Prädikat einer Basistabelle wird vom DBA angegeben. Das Prädikat einer Abfrageergebnistabelle folgt aus den Basistabellen, den Verknüpfungsoperatoren & logischen Operatoren im Abfrageausdruck des Benutzers. Das Prädikat eines JOIN ist das UND der Prädikate seiner Tabellen. UNION der OR; AUSSER die UND NICHT; ON und WHERE einer Bedingung UND diese Bedingung mit dem JOIN-Prädikat; etc.

-- artist A has name N 
Artist(A, N) 
-- album A has name N and ... 
Album(A, N, ...) 
-- genre G has name N 
Genre(G, N) 
-- artist A authored album A2 
ArtistAlbum(A, A2) 
-- album A is of genre G 
AlbumGenre(A, G) 

SELECT DISTINCT ... 
FROM 
    --  album ag.A is of genre ag.G AND genre g.G has name g.N ... 
    -- AND ag.G = g.G ... 
    AlbumGenre ag JOIN Genre g ON a.G = g.G ... 

Beachten Sie, dass es nicht wie viele Genres egal ein Album haben kann oder wie viele Alben ein Genre haben kann, oder ob ein Genre mehrere IDs und/oder Namen haben kann, gibt die Abfrage noch die Zeilen, die befriedigen dieses Prädikat. Constraints (einschließlich FKs) sind nicht erforderlich, um abzufragen oder zu aktualisieren.

Beachten Sie, dass wir dieselben Prädikattransformationen und andere zum Schreiben von Constraints anwenden können. (Ich habe A für beide Autoren & Alben verwendet, also müsste ich hier ein Umbenennungsbeispiel geben.

)

-- for all A & A2, if artist A authored album A2 then artist A has some name 
-- for all A & A2, if artist A authored album A2 then for some N, artist A has name N 
-- for all A & A2, if (A, A2) in ArtistAlbum then for some N, Artist(A, N) 
-- SELECT A FROM ArtistAlbum ⊆ SELECT A FROM Artist 
FOREIGN KEY ArtistAlbum (A) REFERENCES Artist (A) 

-- for all A & A2, if artist A authored album A2 then album A2 has some name 
-- for all A & A2, if artist A authored album A2 then for some N, ..., album A2 has name N and ... 
-- for all A & A2, if (A, A2) in ArtistAlbum then for some N, ..., (A2, N, ...) in Album 
-- SELECT A2 FROM ArtistAlbum ⊆ SELECT A AS A2 FROM Album 
FOREIGN KEY ArtistAlbum (A2) REFERENCES Album (A) 

-- for all A & G, if album A is of genre G then album A has some name and ... 
-- for all A & G, if album A is of genre G then for some N, ..., album A has name N and ... 
-- for all A & G, if (A, G) in AlbumGenre then for some N, ..., (A, N, ...) in Album 
-- SELECT G FROM AlbumGenre ⊆ SELECT A FROM Album 
FOREIGN KEY AlbumGenre (A) REFERENCES Album (A) 

-- for all A & G, if album A is of genre G then genre G has some name 
-- for all A & G, if album A is of genre G then for some N, genre G has name N 
-- for all A & G, if (A, G) in AlbumGenre then for some N, (G, N) in Genre 
-- SELECT G FROM ArtistAlbum ⊆ SELECT G FROM Genre 
FOREIGN KEY AlbumGenre (G) REFERENCES Genre (G) 

Statt mit zwei Tabellen Album & AlbumGenre und ihre FK wir nur Album2 haben könnte, dass ihr verbinden ist, mit Prädikat, das die UND/Verbindung ihrer Prädikate album A has name N and ... and album A is of genre G mit FOREIGN KEY Album2 (G) REFERENCES Genre (G) ist. Dann Normalisierung würde uns sagen, wenn es ein Genre pro Album gibt, dann ist das ein OK Design, aber ansonsten, dass das Original besser ist. Ähnliches gilt für Artist2, das ArtistAlbum mit Artist kombiniert (sinnvoll, wenn ein Künstler ein Album authorisiert). Oder beide ArtistAlbum & AlbumGenre in Album3 (sinnvoll, wenn ein Album einen Autor und ein Genre hat). Aber unabhängig davon, ob es wichtig ist, die Abfrage zu überprüfen, sind die Prädikate, nicht die Kardinalitäten oder Einschränkungen.

So fehlt Ihrem Design entsprechende Prädikate/Spalten/Tabellen wie die von ArtistAlbum & AlbumGenre. (Welche Sie vielleicht mit anderen Tabellen wie oben kombinieren möchten.)

PS Ihre Frage ist nicht klar über "genre", "genre1" & "genre2".

Answer 2

Die Quintessenz ist, dass Sie Fremdschlüssel benötigen. Ihre Tabellen haben derzeit eine eindeutige ID für jede Tabelle namens id:

Schlüsselwort ist "relational" hier. Sie müssen die Tabellen beziehen. Vielleicht möchten Sie diesen Entwurf, indem Sie Ihre IDs besser zu benennen:

artist.artist_id 
album.album_id 
genre.genre_id 

dann in dem Album Tabelle finden Sie Spalten für KUENSTLER_ID und genre_id speichern, um sie zurück zu den Künstler und Genre Tabellen

beitreten kann, ohne FKs, Sie werden ein kartesisches Produkt haben. So einfach ist das.