TL;DR Vous devez suivre un algorithme publié pour décomposer en une forme normale donnée.
PS Vous n'avez pas obtenu Artiste du CD original via la normalisation, puisque vous avez introduit une nouvelle colonne. Mais supposons que la table Artist ait une signification évidente. Pourquoi pensez-vous qu'il "n'est pas encore en troisième forme normale pour autant que je le comprenne" ? Si artiste -> année dans le CD original, cela se produit également dans Artiste. Mais alors {artist} est, avec {artist_id}, un CK (clé candidate) de Artist, et Artist est en 3NF (et 5NF).
À partir de la version originale de votre question et de la version actuelle, vous avez un CD de table de base proposé avec des colonnes cd_id, titre, groupe et année, contenant des tuples où cd cd_id intitulé titre a été réalisé par le groupe groupe qui s'est formé l'année année . La colonne cd_id est unique, donc est un CK. FD {groupe} -> l'année est également valable.
La normalisation n'introduit pas de nouveaux noms de colonne. Il remplace une table de base proposée par d'autres, chacune avec un sous-ensemble plus petit de ses colonnes, qui se joignent toujours à ce que sa valeur aurait été. La normalisation jusqu'à BCNF est basée sur les FD (dépendances fonctionnelles), qui déterminent également les CK d'une table de base. Votre question ne contient donc pas de décomposition. Une décomposition possible rappelant votre question, qui pourrait ou non avoir des propriétés particulières, serait des tables avec des ensembles de colonnes {cd_id, title, group} et {group, year}.
D'autres FD tiennent dans l'original. Certains tiennent à cause de ce que sont les colonnes; certains tiennent à cause du CK; certains tiennent parce que {groupe} -> année tient ; en général, certains tiennent parce que tous les trois le font. Et peut-être que d'autres tiennent à cause des tuples censés entrer dans la relation et des situations qui peuvent survenir. Vous devez décider pour chaque FD possible si elle tient.
Bien sûr, on vous a peut-être prévenu que les seuls qui tiennent sont ceux qui doivent tenir dans ces circonstances. Mais vous ne le ferez pas on m'a dit que le seul FD qui tient est {groupe} -> année, parce qu'il y en a des FD triviaux et chaque sur-ensemble d'un CK détermine fonctionnellement chaque ensemble de colonnes .
Une définition de 3NF est qu'une relation est dans 2NF et qu'aucune colonne non première n'est fonctionnellement transitivement dépendante de n'importe quelle CK. (Remarquez que chaque condition implique d'autres définitions.) Si vous voulez l'utiliser pour savoir si votre relation est en 3NF, vous devez ensuite savoir ce que tous les CK le sont. Vous pouvez le faire plus rapidement via un algorithme approprié, mais vous pouvez simplement voir quels ensembles de colonnes déterminent fonctionnellement chaque colonne mais ne contiennent pas un tel ensemble plus petit, puisque ce sont les CK. Vérifiez ensuite les deux conditions dans la définition.
Si vous souhaitez normaliser en 3NF, vous devez suivre un algorithme de décomposition en 3NF. Vous n'expliquez pas quel processus vous pensez devoir suivre. Mais si vous ne suivez pas un algorithme éprouvé, tous les composants que vous choisissez peuvent ou non toujours se joindre à l'original et peuvent ou non être chacun sous une forme normale supérieure particulière. Notez que des exemples de décompositions que vous avez vues ne sont pas des présentations d'algorithmes de décomposition .
Les définitions NF (forme normale) donnent les conditions qu'une relation doit remplir pour être dans cette NF. Ils ne vous disent pas comment décomposer sans perte (en préservant les FD lorsque cela est possible) en relations dans des NF supérieurs. Les gens ont élaboré des algorithmes pour produire des décompositions en NF particuliers. (Et la décomposition en un NF donné n'implique généralement pas une première décomposition en NF inférieurs. Passer par des NF inférieurs peut en fait empêcher la génération de bonnes décompositions de NF supérieur de l'original lorsque vous arrivez à décomposer selon un NF supérieur.)
Vous ne réalisez peut-être pas non plus que lorsque certains FD tiennent, certains autres doivent tenir. Ce dernier peut être déterminé via les axiomes d'Armstrong à partir du premier. Donc, ce n'est pas parce que vous vous êtes décomposé pour vous débarrasser d'un FD particulier dont la présence viole un NF particulier qu'il n'y en a pas eu un tas d'autres qui l'ont violé et que vous n'avez pas traité. Ils peuvent être présents dans les nouveaux composants. Ou ils peuvent ne pas être présents de manière problématique, de sorte que vous ne les avez pas "préservés" alors que vous auriez pu, ce qui conduit à de mauvaises conceptions.
Découvrez des algorithmes NF spécifiques, et d'ailleurs les NF et la normalisation elle-même, dans un manuel/cours/présentation collégial/universitaire. Beaucoup sont en ligne.
