La normalisation nécessite de connaître les dépendances fonctionnelles (FD) et les dépendances de jointure (FD). Vous ne leur avez pas donné.
Votre candidature Nous ne pouvons vous dire les FD et les JD que si nous savons exactement quelle est "la relation que je voulais exprimer" (c'est-à-dire le prédicat) pour chaque table (c'est-à-dire au point où nous pourrions examiner une situation et savoir pour chaque ligne possible si il fait une proposition vraie à partir du prédicat et appartient donc à la table) et exactement quelles situations possibles peuvent survenir (via des "règles métier" sur les situations d'application possibles, équivalentes à des contraintes sur les états possibles de la base de données).
Vos "clés" Vous n'avez pas donné de FD. Vous venez de donner une clé candidate (CK) et une "clé unique". Mais vous ne pouvez pas déterminer certains ou tous les CK sans connaître certaines choses sur les FD. Donc, quand vous donnez des CK, cela revient à dire qu'il y a et qu'il n'y a pas certains FD. Vous devez nous dire ce que vous nous avez donné lorsque vous donnez des ensembles de colonnes étiquetés PK ou "clé unique":une "clé unique" est-elle un CK (ne contenant aucun sous-ensemble unique plus petit) ou juste une super clé (unique) ? Avez-vous donné tous les CK ou pourrait-il y en avoir d'autres ? Pourrait-il y avoir d'autres super-clés que les sur-ensembles de celles données ? Il est plus utile que vous nous disiez exactement quels FD vous savez détenir (via une couverture minimale) et lesquels vous savez ne pas détenir.
Devinettes
Je n'ai aucune idée de ce que is_calculated est pour.
Peut-être une date donnée et meal la paire a exactement un content ?
TL;DR Vous devez vraiment vérifier chaque ensemble de colonnes possible pour voir s'il détermine fonctionnellement chaque autre colonne. C'est-à-dire si pour chaque état de la base de données, une sous-ligne de valeurs pour l'ensemble de colonnes n'apparaît qu'avec une seule valeur pour la colonne. Nous ne pouvons que deviner sans une compréhension claire de vos prédicats et de votre application. Vous pouvez réduire le travail comme suit :si un ensemble de colonnes est unique, ses sur-ensembles déterminent toutes les autres colonnes. Si un ensemble de colonnes est minimalement unique (est un CK), aucun de ses plus petits sous-ensembles ne détermine toutes les autres colonnes. Vous pouvez rechercher des contre-exemples de DF putatifs, où deux lignes peuvent avoir la même sous-ligne de valeurs pour un déterminant putatif mais avoir des valeurs différentes pour un attribut déterminé putatif. Les axiomes d'Armstrong génèrent tous les FD impliqués par ceux donnés.
JD La normalisation en 4NF et 5NF implique de diviser la table en plusieurs tables pour éliminer les JD qui ne sont pas impliqués par les CK. Le prédicat d'une table peut être exprimé comme l'ET des autres exactement lorsqu'un JD correspond aux ensembles de colonnes des prédicats. Une relation est en 5NF lorsque chaque conjoint dans chaque JD chevauche un autre sur au moins un CK. (Algorithme d'appartenance de Fagin.)
PS Si vous vous souciez des contraintes, en avez-vous perdu une lorsque vous êtes passé d'une table à deux ?
