Maison  >  Article  >  base de données  >  Que sont la première forme normale, la deuxième forme normale et la troisième forme normale de base de données ?

Que sont la première forme normale, la deuxième forme normale et la troisième forme normale de base de données ?

一个新手
一个新手original
2017-09-09 14:56:163663parcourir

Paradigme : le nom anglais est Normal Form. Il a été résumé par le britannique E.F. Codd (l'ancêtre de la base de données relationnelle) après avoir proposé le modèle de base de données relationnelle dans les années 1970. Le paradigme est également la base de la théorie des bases de données relationnelles. base de notre travail en base de données relationnelle. Les règles et directives à suivre lors de la conception d’une structure de base de données. Il existe actuellement 8 paradigmes qui peuvent être retracés, dans l'ordre : 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF et 6NF. Habituellement, seules les trois premières formes normales sont utilisées, à savoir : la première forme normale (1NF), la deuxième forme normale (2NF) et la troisième forme normale (3NF). Ce qui suit est une brève introduction à ces trois paradigmes.
◆ Première forme normale (1NF) : elle met l'accent sur l'atomicité des colonnes, c'est-à-dire que les colonnes ne peuvent pas être divisées en d'autres colonnes.
Considérons un tel tableau : [Contact] (nom, sexe, numéro de téléphone)
Si dans un scénario réel, un contact a un numéro de téléphone personnel et un numéro de téléphone professionnel, alors cette conception de structure de tableau n'atteint pas 1NF . Pour respecter la 1NF, il suffit de diviser la colonne (téléphone), à ​​savoir : [Personne de contact] (nom, sexe, numéro de téléphone personnel, numéro de téléphone entreprise). 1NF est facile à distinguer, mais 2NF et 3NF se confondent facilement.
◆ Deuxième forme normale (2NF) : La première est 1NF, et elle contient également deux parties. Premièrement, la table doit avoir une clé primaire. Deuxièmement, les colonnes non incluses dans la clé primaire doivent être complètement dépendantes de la clé primaire ; clé, et ne peut pas s'appuyer uniquement sur la partie clé primaire de.
Considérez un tableau de détail de commande : [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName).
Parce que nous savons que plusieurs produits peuvent être commandés en une seule commande, un OrderID seul ne suffit pas pour être la clé primaire. La clé primaire doit être (OrderID, ProductID). Il est évident que Discount et Quantity dépendent entièrement de la clé primaire (OderID, ProductID), tandis que UnitPrice et ProductName ne dépendent que de ProductID. La table OrderDetail n’est donc pas conforme à 2NF. Les conceptions qui ne sont pas conformes à la norme 2NF sont sujettes à des données redondantes.
Le tableau [OrderDetail] peut être divisé en [OrderDetail] (OrderID, ProductID, Discount, Quantity) et [Product] (ProductID, UnitPrice, ProductName) pour éliminer les répétitions multiples de UnitPrice et ProductName dans le tableau de commande d'origine.
◆ Troisième forme normale (3NF) : Premièrement, il s'agit de 2NF De plus, les colonnes de clé non primaire doivent dépendre directement de la clé primaire, et il ne peut pas y avoir de dépendances transitives. Autrement dit, elle ne peut pas exister : la colonne de clé non primaire A dépend de la colonne de clé non primaire B et la colonne de clé non primaire B dépend de la clé primaire.
Considérons une table de commande [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) où se trouve la clé primaire (OrderID).
Parmi elles, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity et d'autres colonnes de clé non primaire dépendent entièrement de la clé primaire (OrderID), elles sont donc conformes à 2NF. Cependant, le problème est que CustomerName, CustomerAddr et CustomerCity dépendent directement de CustomerID (colonne de clé non primaire) au lieu de s'appuyer directement sur la clé primaire. Ils s'appuient sur la clé primaire via la transmission, ils ne sont donc pas conformes à 3NF.
Atteignez 3NF en divisant [Commande] en [Commande] (OrderID, OrderDate, CustomerID) et [Customer] (CustomerID, CustomerName, CustomerAddr, CustomerCity).
Les concepts de deuxième forme normale (2NF) et de troisième forme normale (3NF) se confondent facilement. Le point clé pour les distinguer est 2NF : si la colonne de clé non primaire dépend entièrement de la clé primaire, ou dépend de celle-ci. partie de la clé primaire ; 3NF : colonne de clé non primaire Si la colonne de clé primaire dépend directement de la clé primaire, ou dépend directement de la colonne de clé non primaire.

Paradigme : le nom anglais est Normal Form. Il a été résumé par le britannique E.F. Codd (l'ancêtre de la base de données relationnelle) après avoir proposé le modèle de base de données relationnelle dans les années 1970. Le paradigme est également la base de la théorie des bases de données relationnelles. base de notre travail en base de données relationnelle. Les règles et directives à suivre lors de la conception d’une structure de base de données. Il existe actuellement 8 paradigmes qui peuvent être retracés, dans l'ordre : 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF et 6NF. Habituellement, seules les trois premières formes normales sont utilisées, à savoir : la première forme normale (1NF), la deuxième forme normale (2NF) et la troisième forme normale (3NF). Ce qui suit est une brève introduction à ces trois paradigmes.
◆ Première forme normale (1NF) : elle met l'accent sur l'atomicité des colonnes, c'est-à-dire que les colonnes ne peuvent pas être divisées en d'autres colonnes.
Considérons un tel tableau : [Contact] (nom, sexe, numéro de téléphone)
Si dans un scénario réel, un contact a un numéro de téléphone personnel et un numéro de téléphone professionnel, alors cette conception de structure de tableau n'atteint pas 1NF . Pour respecter la 1NF, il suffit de diviser la colonne (téléphone), à ​​savoir : [Personne de contact] (nom, sexe, numéro de téléphone personnel, numéro de téléphone entreprise). 1NF est facile à distinguer, mais 2NF et 3NF se confondent facilement.
◆ Deuxième forme normale (2NF) : La première est 1NF, et elle contient également deux parties. Premièrement, la table doit avoir une clé primaire. Deuxièmement, les colonnes non incluses dans la clé primaire doivent être complètement dépendantes de la clé primaire ; clé, et ne peut pas s'appuyer uniquement sur la partie clé primaire de.
Considérez un tableau de détail de commande : [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName).
Parce que nous savons que plusieurs produits peuvent être commandés en une seule commande, un OrderID seul ne suffit pas pour être la clé primaire. La clé primaire doit être (OrderID, ProductID). Il est évident que Discount et Quantity dépendent entièrement de la clé primaire (OderID, ProductID), tandis que UnitPrice et ProductName ne dépendent que de ProductID. La table OrderDetail n’est donc pas conforme à 2NF. Les conceptions qui ne sont pas conformes à la norme 2NF sont sujettes à des données redondantes.
Le tableau [OrderDetail] peut être divisé en [OrderDetail] (OrderID, ProductID, Discount, Quantity) et [Product] (ProductID, UnitPrice, ProductName) pour éliminer les répétitions multiples de UnitPrice et ProductName dans le tableau de commande d'origine.
◆ Troisième forme normale (3NF) : Premièrement, il s'agit de 2NF De plus, les colonnes de clé non primaire doivent dépendre directement de la clé primaire, et il ne peut pas y avoir de dépendances transitives. Autrement dit, elle ne peut pas exister : la colonne de clé non primaire A dépend de la colonne de clé non primaire B et la colonne de clé non primaire B dépend de la clé primaire.
Considérons une table de commande [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) où se trouve la clé primaire (OrderID).
Parmi elles, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity et d'autres colonnes de clé non primaire dépendent entièrement de la clé primaire (OrderID), elles sont donc conformes à 2NF. Cependant, le problème est que CustomerName, CustomerAddr et CustomerCity dépendent directement de CustomerID (colonne de clé non primaire) au lieu de s'appuyer directement sur la clé primaire. Ils s'appuient sur la clé primaire via la transmission, ils ne sont donc pas conformes à 3NF.
Atteignez 3NF en divisant [Commande] en [Commande] (OrderID, OrderDate, CustomerID) et [Customer] (CustomerID, CustomerName, CustomerAddr, CustomerCity).
Les concepts de deuxième forme normale (2NF) et de troisième forme normale (3NF) se confondent facilement. Le point clé pour les distinguer est 2NF : si la colonne de clé non primaire dépend entièrement de la clé primaire, ou dépend de celle-ci. partie de la clé primaire ; 3NF : colonne de clé non primaire Si la colonne de clé primaire dépend directement de la clé primaire, ou dépend directement de la colonne de clé non primaire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn