Conseils sur les relations de conception entre les tables

Question

J'ai des informations sur les albums de musique que je veux organiser dans les tables de SGBDR avec les relations entre eux. J'ai les informations suivantes pour chaque album: artiste, nom de l'album, année, étiquette, genre, style, note. Jusqu'à présent, je pense à faire 4 tables - artistes, albums (nom, année, étiquette, note), genre1 et genre2 (chaque genre avec ses styles). Sur le diagramme, il se présente comme suit:

Mais ne sais pas encore comment puis-je établir une connexion entre les albums et les trois autres tableaux? C'est-à-dire, quand je vais lancer une requête select name from artists je voudrais recevoir un album avec l'artiste correspondant et le genre-style.

Comment dois-je établir une relation entre les tables dans ce cas?

Answer 1

Vous devez lire une introduction aux tables de base de données relationnelles & interrogation. Les "relations" [sic] entre les tables dont vous parlez sont des FK (clés étrangères). Un FK indique que les valeurs d'une liste de colonnes dans un tableau apparaissent sous la forme de valeurs pour une autre liste de colonnes dans une table qui forment un ensemble PK (clé primaire) ou UNIQUE. Vous n'avez pas besoin de déclarer ou d'utiliser des clés FK pour interroger. Comme toutes les contraintes, y compris PK & UNIQUE, elles permettent au SGBD d'exclure les états de base de données erronés. A (résultat de base ou de requête) La table représente une relation (entreprise/application) (navire)/association. Une table contient les lignes qui font vrai proposition (déclaration) à partir d'un prédicat associé (modèle d'instruction). Le prédicat d'une table de base est donné par le DBA. Le prédicat d'une table de résultat de requête résulte des tables de base, des opérateurs de relation & des opérateurs logiques dans l'expression de requête de l'utilisateur. C'est-à-dire que le prédicat d'un JOIN est l'AND des prédicats de ses tables; UNION l'OR; SAUF l'ET NON; ON et WHERE d'une condition ET condition avec le prédicat JOIN; 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 ... 

Notez que peu importe combien de genres un album peut avoir ou combien d'albums un genre peut avoir ou si un genre peut avoir plusieurs cartes d'identité et/ou les noms, la requête renvoie toujours les lignes satisfaire ce prédicat. Les contraintes (y compris les clés FK) ne sont pas nécessaires pour interroger ou mettre à jour.

Notez que nous pouvons appliquer les mêmes transformées de prédicat et d'autres pour écrire des contraintes. (J'ai utilisé A pour les deux auteurs & donc je devrais donner un exemple de changement de nom ici.)

-- 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) 

Au lieu d'avoir deux tables album & AlbumGenre et leur FK, nous aurions pu nous contenter Album2 qui est leur jointure avec prédicat qui est le ET/conjonction de leurs prédicats album A has name N and ... and album A is of genre G avec FOREIGN KEY Album2 (G) REFERENCES Genre (G). Ensuite normalisation nous dirait que s'il y a un genre par album alors c'est un design OK mais sinon l'original est meilleur. De même pour Artist2 combinant ArtistAlbum en Artist (raisonnable si un artiste autorise un album). Ou les deux ArtistAlbum & AlbumGenre dans Album3 (raisonnable si un album a un auteur et un genre). Mais indépendamment de tout ce qui compte pour interroger & mettre à jour sont les prédicats, pas les cardinalités ou les contraintes.

Votre design ne contient donc pas de prédicats/colonnes/tables appropriés comme ceux d'ArtistAlbum & AlbumGenre. (Ce que vous pourriez vouloir combiner avec d'autres tables comme ci-dessus.)

PS Votre question n'est pas claire sur "genre", "genre1" & "genre2".

Answer 2

L'essentiel est que vous avez besoin de clés étrangères. Vos tables ont actuellement un identifiant distinct pour chaque table nommée id:

artist.id 
artist.name 
album.id 
album.album 
album.year 
album.label 
album.rating 
genre.id 
genre.name 
genre.id 
genre.name 

Le mot clé est "relationnel" ici. Vous devez relier les tables. Peut-être vous concevoir cela en nommant vos ids mieux:

artist.artist_id 
album.album_id 
genre.genre_id 

Puis dans la table album, vous pouvez ajouter des colonnes pour artist_id et genre_id afin que vous puissiez les rejoindre de nouveau aux tables artiste et genre

Sans FKs, vous aurez un produit cartésien. Aussi simple que cela.