Une dépendance fonctionnelle complète est un état de normalisation de la base de données qui correspond au standard de normalisation de la seconde forme normale (2NF). En bref, cela signifie qu’il répond aux exigences de la première forme normale (1NF) et que tous les attributs non-clés dépendent entièrement de la clé primaire.
Ce n'est pas aussi compliqué que cela puisse paraître. Regardons cela plus en détail.
Résumé de la première forme normale
Avant qu'une base de données puisse être entièrement dépendante du point de vue fonctionnel, elle doit d'abord se conformer à First Normal Form.
Tout cela signifie que chaque attribut doit contenir une seule valeur atomique.
Par exemple, le tableau suivant ne ne pas se conformer à 1NF, car l’employée Tina est liée à deux sites, tous deux dans une même cellule:
| Employé | Emplacement |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Autoriser cette conception pourrait avoir un impact négatif sur les mises à jour ou les entrées de données. Pour garantir la conformité 1NF, réorganisez le tableau afin que tous les attributs (ou cellules de colonne) contiennent une seule valeur:
Première conformité au formulaire normal
Mais 1NF n'est toujours pas suffisant pour éviter des problèmes avec les données.
Comment 2NF fonctionne pour assurer une dépendance totale
Pour être totalement dépendants, tous les attributs de clé non candidats doivent dépendre de la clé primaire. (N'oubliez pas qu'un attribut de clé candidate est toute clé (par exemple, une clé primaire ou étrangère) utilisée pour identifier de manière unique un enregistrement de base de données.
Les concepteurs de base de données utilisent une notation pour décrire les relations de dépendance entre les attributs:
Si l'attribut A détermine la valeur de B, nous écrivons ceciA -> B- signifiant que B est fonctionnellement dépendant de A. Dans cette relation, A détermine la valeur de B, tandis que B dépend de A.
Par exemple, dans la suite Départements d'employés table, EmployeeID et DeptID sont deux clés candidates: EmployeeID est la clé primaire de la table, alors que DeptID est une clé étrangère.
Tout autre attribut (dans le cas présent, EmployeeName et DeptName) doit dépendre de la clé primaire pour obtenir sa valeur.
| ID employé | Nom de l'employé | DeptID | DeptName |
|---|---|---|---|
| Emp1 | John | Dept001 | La finance |
| Emp2 | Tina | Dept003 | Ventes |
| Emp3 | Carlos | Dept001 | La finance |
Dans ce cas, la table n'est pas totalement dépendante car, alors que EmployeeName dépend de la clé primaire EmployeeID, DeptName dépend à la place de DeptID. C'est appelé dépendance partielle .
Pour rendre cette table conforme à 2NF, nous devons séparer les données en deux tables:
| ID employé | Nom de l'employé | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Nous supprimons l’attribut DeptName de la Employés table et créer une nouvelle table Départements :
| DeptID | DeptName |
|---|---|
| Dept001 | La finance |
| Dept002 | Ressources humaines |
| Dept003 | Ventes |
Maintenant, les relations entre les tables sont totalement dépendantes ou en 2NF.
Pourquoi la dépendance totale est importante
La dépendance totale entre les attributs de base de données permet d’assurer l’intégrité des données et d’éviter les anomalies.
Par exemple, considérons le tableau de la section ci-dessus qui n’adhère qu’à 1NF. Le voici à nouveau:
| Employé | Emplacement |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina a deux disques. Si nous en mettons à jour un sans nous rendre compte qu'il y en a deux, le résultat serait des données incohérentes.
Ou bien, si nous voulons ajouter un employé à ce tableau, mais que nous ne connaissons pas encore l'emplacement? Il se peut que nous ne puissions même pas ajouter un nouvel employé si l'attribut Location n'autorise pas les valeurs NULL.
La dépendance totale n’est pas l’ensemble de la situation en matière de normalisation. Vous devez vous assurer que votre base de données est en troisième forme normale (3NF).
