Boyce-Codd, quatrième et cinquième formes normales

«Ceci est la quatrième partie de la série, les cinq formes normales. La forme normale de Boyce-Codd est abrégée BCNF. Il est également connu sous le nom de 3.5nf. 3.5 est 3½. Il vient après la troisième forme normale. La quatrième forme normale est abrégée 4NF et vient après la forme normale de Boyce-Codd. La cinquième forme normale est abrégée 5NF et vient après la quatrième forme normale.

Ce tutoriel (article) est la quatrième partie de la série de tutoriels, les cinq formulaires normaux. Ce tutoriel explique BCNF, 4NF et 5NF.

Ce tutoriel suit un scénario comme suit: un père est mort. Il a laissé de l'argent à son fils. Son fils a décidé d'utiliser l'argent pour ouvrir (démarrer) un magasin de commodité. Le magasin de commodité est déjà approvisionné et fonctionne depuis un certain temps. Le fils a des employés, appelés Clerks, dans cette série de tutoriels. Le fils est le propriétaire. Avant que le magasin ne devienne opérationnel, le propriétaire et les commis ne connaissaient pas les formulaires normaux.

Vous, le lecteur, avez rempli cette série de didacticiels de formulaire normal et êtes également un développeur de base de données. Le fils de la fin du père est votre ami. Vous avez visité sa boutique au cours des trois derniers jours. Le premier jour, vous leur avez visité; Vous avez formé le propriétaire et ses employés sur la façon de mettre un tableau de base de données en 1NF. Le deuxième jour, vous les avez formés sur la façon de déplacer une table de 1NF à 2NF. Le troisième jour, vous les avez formés sur la façon de déplacer une table de 2NF à 3NF.

Aujourd'hui, le quatrième jour, vous avez visité la boutique pour former uniquement le propriétaire de BCNF, 4NF et 5NF dans son bureau."

Forme normale de boyce-codd

Le problème de BCNF se produit lorsqu'il y a une clé primaire composite et un attribut de clé non primaire (colonne), et la clé non primaire dépend fonctionnellement de la pièce (e.g., un) des attributs de clé primaire, tandis que le tableau est déjà dans la troisième forme normale.

Cela implique que la colonne non primaire (clé non primaire) et la colonne principale dépendent de la forme d'une entité et doivent être supprimées en tant que table distincte, où la colonne non prime sera la clé principale. L'autre partie de la clé primaire composite formera une nouvelle table avec la colonne non pris. L'autre partie de la clé primaire composite reste une clé primaire. Les dépenses possibles liées de la table parent accompagnent de manière appropriée les tables des deux enfants.

La séparation des tables pour la forme normale de Boyce-Codd n'est pas vraiment la même que la séparation des tables en 2NF et 3NF.

Un tableau est sous forme normale de Boyce-Codd si les règles suivantes sont obéies:

1. Le tableau doit déjà être sous la troisième forme normale.
2. Aucun attribut non prison (colonne) ne devrait dépendre de la partie de la clé primaire composite.

Ce deuxième point, comme cité, est simplifié.

Exemple

Dans la partie précédente de cette série, le tableau Saledetails (avec une certaine modification) a été donné comme suit:

Saledetails (SaleID, produit, nombre, nombres, prix Unitselling, réduction)

Un tableau correspondant avec les données est:

Le prix de vente unitaire est de type, de flotteur ou de numéro. La clé principale de ce tableau est une clé composite composée de venteid et de produit.

Ce tableau est en 3NF. Le nombre de produits vendus peut être considéré comme dépend du produit et non de la venteid. En d'autres termes, une clé non prison ne peut dépendre que de la partie de la clé primaire composite. Cela ne devrait pas arriver; Et donc à partir de ces trois colonnes, les deux tables suivantes pourraient en résulter:

Quantité (nombres, produit)

et

Saledetails (SaleID, nombres)

Pour le tableau, la quantité, la clé principale est Numbersold. Pour la nouvelle table Saledetails, la clé principale est toujours SaleID.

Depuis le tableau des parents Saledetails, le seul dépendance pour nombres est le produit. Du tableau des parents Saledetails, les dépendances à vendre sont nombres, un prix unités, une remise et sans produit. Et donc les tables devraient être:

Quantité (nombres, produit)

et

Saledetails (SaleID, Numbersold, Numbersold, UnitsellingPrice, Discount)

À ce stade, le propriétaire fait le commentaire suivant:

«Je ne pense pas que je voudrais jamais connaître la quantité d'un produit particulier vendu sans vouloir connaître le SaleID, qui dépend du trio (acheter le client, de vente d'employé et de la date de la transaction).«Vous, le développeur de la base de données, répond comme suit:

«Dans ce cas, permettons à la table SaleDetails et OrderDetails à 3NF. Après tout, de nombreuses bases de données commerciales ne vont pas au-delà de la 3NF, et les entreprises sont à l'aise. Cependant, chaque fois que vous voulez savoir que pour une table similaire, divisez la table parentale en tables BCNF."

Quatrième forme normale

1NF, 2NF, 3NF et BCNF s'appuient sur la dépendance fonctionnelle. 4NF s'appuie sur un type spécial de dépendance fonctionnelle, qui est plutôt «dérangeant», surtout sinon bien compris. Cette dépendance plutôt troublante est appelée dépendance à plusieurs valeurs.

La dépendance fonctionnelle est simplement appelée dépendance. Cependant, la dépendance multivalerie n'est pas simplement appelée dépendance, car cela entraînerait une confusion. Il s'appelle la dépendance multivalerie.

Vous, le développeur de la base de données, dites au propriétaire ce qui suit: «Il doit vous intéresser que pour qu'un tableau soit en 1NF, chaque cellule doit avoir une seule valeur. Un problème quelque peu similaire se produit ici, mais avec une table qui est déjà en BCNF après 3NF. La dépendance multivalerie est avec la clé primaire composite, et chaque cellule de l'ensemble du tableau a déjà une seule valeur. Dans le problème 1NF, les multiples valeurs d'une cellule n'ont pas à concerner une clé. Avec le problème 4NF, il y a au moins trois colonnes. S'il n'y a que trois colonnes, alors les trois colonnes forment la touche composite principale. Dans ce cas, la première colonne de cellules peut déterminer la deuxième colonne des cellules, mais la deuxième colonne est indépendante de la troisième colonne. 4NF ne permet pas cela."

En d'autres termes, le problème peut être que la deuxième colonne dépend de la première colonne, et que la troisième colonne dépend toujours de la première colonne et n'a rien à faire en termes de dépendance à la deuxième colonne. 4NF ne permet pas cela.

Avant de poursuivre l'explication de la dépendance multivalerie, la façon dont le problème de la quatrième forme normale peut se produire doit être expliqué en premier.

Comment le problème de 4NF peut survenir avec une boutique de commodité

Imaginez qu'après un certain temps, vous avez des rivaux (autres magasins de commodité) dans votre quartier, et vous ne vendez pas autant que vous vendiez avant. Cela ne pouvait pas être prévu lorsque vous avez commencé le magasin de commodité.

Il vous arrive que si vous pouvez réduire vos prix, pas en dessous du prix du coût, bien sûr, pour vos clients qui achètent le plus, alors ils achèteront plus, et vos ventes et vos profits augmenteraient du niveau abandonné. Cela signifie que vous devez savoir où ces clients quittent et leurs adresses (rues) afin que vous puissiez même livrer des produits à leurs maisons. Encore une fois, ce problème n'était pas prévu au début.

Et donc vous trouvez le tableau suivant, que vous travaillerez, jusqu'à BCNF, avant que le problème de 4NF ne puisse se montrer:

Livraison

Pour vous, le propriétaire, votre intérêt est la catégorie du produit, le produit lui-même à livrer et l'adresse à livrer à. En regardant toute la table, le reste des sections de ligne commençant de Customerner à l'extrémité droite déterminent les trois premières colonnes. En d'autres termes, les trois premières colonnes forment la clé principale pour le reste des colonnes. C'est-à-dire que les trois premières colonnes dépendent du reste des colonnes par lignes. Et donc, les trois premiers titres de colonne doivent être soulignés avec des lignes uniques. Avec cela, ce tableau est maintenant dans sa première forme normale. Chaque combinaison de cellules horizontales dans les trois premières colonnes est unique.

Ce tableau est également sous la deuxième forme normale car chaque combinaison de cellules horizontales dans les trois premières colonnes est unique, et il n'y a pas de dépendance partielle (avec des groupes répétés). Cependant, ce n'est pas dans le troisième formulaire normal car les sections (pièces) de lignes commençant de CustomName à l'extrémité droite déterminent CustomerId (CustomerId dépend d'eux). Donc, tout ce qui doit être supprimé, vous laissant avec une copie du CustomerId. CustomerId est désormais à la fois une clé étrangère ainsi que dans le cadre de la clé primaire. La table est maintenant en 3NF.

Avant vous, le développeur et le formateur de la base de données pourrait continuer, le propriétaire dit: «Au lieu de travailler avec la colonne de catégorie, la colonne de produit et la colonne d'adresse, je travaillerai avec la colonne de catégorie, la colonne de produit et la colonne CustomerID, car une fois que le client est Connue, l'adresse peut être connue, et ce serait plus pratique, en particulier pour l'ordinateur."

Votre réponse: «C'est bien, propriétaire. Vous êtes sur la bonne voie. C'est ce qui sera fait."

N'oubliez pas que le tableau des clients existe déjà. Cela a été produit dans la partie précédente de cette série de tutoriels. Ainsi, la seule table à produire maintenant est une table qui a juste les trois clés principales.

Permutations de livraison de catégorie, par produit

Malheureusement, les colonnes de cette clé primaire composite ne sont pas en 2NF entre elles. Il y a des répétitions de valeurs cellulaires descendant, avec une dépendance partielle dans la clé composite. Ces répétitions ne sont pas aussi constructives qu'elles semblent.

Notez que la confiserie est associée au client 1, et elle est également associée au client 2. La boisson gazeuse est associée au client 1, et elle est également associée au client 2.

Si le client 1 a demandé des bonbons aujourd'hui, il demandera le chocolat demain (non illustré dans la table). La confiserie est associée au client 1 via des bonbons sur la table, mais il peut également être associé au client 1 via des chocolats dans les livraisons demain. Si le client 1 a demandé Sprite aujourd'hui, il demandera Coca-Cola demain. La boisson gazeuse est associée au client 1 via Sprite, dans le tableau, mais il peut également être associé au client 1 via Coca-Cola. Le même problème de livraison se produit avec le client 2. Ce type de répétition est appelé dépendance multivalerie.

Notez que dans le tableau ci-dessus, la colonne du produit n'a pas de répétition (du moins pour l'instant).

Pour résoudre ce problème, il est préférable de mettre d'abord ces répétitions des valeurs de colonne, de la clé primaire, sous la première forme normale pour aboutir à ce qui suit:

Compléter les permutations de livraison de catégorie par produit

La permutation signifie modifier l'ordre d'un arrangement. Dans cette situation, cela signifie donner toutes les différentes commandes possibles de produits dans la colonne du produit. Maintenant, il y a plus de répétitions (plus de redondance) dans ce tableau que dans ce qui précède. La bonne nouvelle est que ces trois colonnes sont maintenant bien, sous forme normale. 2NF et 3NF doivent être envisagés pour ces trois colonnes.

Rappelons que la livraison n'était pas prévue au tout début lorsque la boutique a commencé (devenu opérationnel). S'il avait été prévu, le tout premier tableau de transaction dans la première partie de cette série de tutoriels aurait été comme ceci:

Notez que les multi-valeurs de chaque cellule de cette colonne de produit ont plus de facteurs pris en considération que ce qui s'est passé dans le tout premier tableau de transaction dans la première partie de la série. Amener ce tableau dans la première forme normale entraînerait le tableau précédent, qui est réimprimé ici, pour une référence facile au lecteur, avec quelques modifications dans la colonne du produit:

Les deux tables en forme de première normale sont les mêmes car la permutation dans la colonne du produit est relative à la colonne CustomerId. N'oubliez pas que chaque clientrid ici identifie une ligne dans le tableau des clients.

La définition de la dépendance multivalerie signifie que s'il y a trois colonnes, x, y et z, et pour une ligne particulière de valeurs x, y et z respectivement, une dépendance multivalerie x - >> y, signifie que si nous choisissons un X se produisant réellement dans le tableau (appelez ce choix x_c), et compiler une liste de tous les x_ccombinaisons yz qui peuvent se produire dans le tableau, comme fait ci-dessus, nous constaterons que x_c est associé aux mêmes entrées y, quel que soit le z. Donc essentiellement, la présence de z ne fournit aucune information utile pour contraindre les valeurs possibles de y.

Dans le tableau ci-dessus, x_c, Par exemple, est la confiserie, et une valeur y correspondante est des bonbons. La combinaison de confiserie et de bonbons n'a rien à voir avec la colonne CustomerId, où la valeur peut-être 1 ou 2 dans les lignes. Si x est pris comme une boisson gazeuse, une valeur y correspondante serait sprite. La combinaison de la boisson gazeuse et de Sprite n'a rien à voir avec les colonnes CustomerId, où la valeur peut-être 1 ou 2 dans les lignes.

Vu à partir d'une deuxième forme normale et des points de vue de dépendance fonctionnelle, la colonne de catégorie dépend de la colonne du produit et dépend également de la colonne CustomerId mais ne dépend pas des deux colonnes lorsqu'elles sont combinées. Les valeurs de la colonne du produit se répètent, déterminant les valeurs de la colonne de catégorie; et les valeurs de la colonne CustomerID Repeuve, déterminant les valeurs dans la colonne de catégorie; Mais ces deux colonnes ensemble ne déterminent pas les valeurs dans la colonne de catégorie.

Ainsi, le tableau doit être divisé en deux, avec la catégorie et les colonnes de produits qui se déroulent dans un sens et la catégorie et les colonnes CustomerID dans l'autre sens, comme suit:

Catégorie - Tableau de produits

Catégorie - Table du client

Ces deux tables pour enfants sont maintenant en 1NF, 2NF, 3NF, BCNF et surtout, 4NF. Le tableau des producteurs de catégorie a des clés primaires composites. Le tableau de catégorie-client possède également des clés primaires composites. Chacune des touches de colonne est déjà une clé principale dans une autre table dans la base de données, soit une clé étrangère dans une autre table dans la même base de données.

Ces deux tables remplaçant la table parent, ne sont pas les seules tables de toute la base de données. En fait, ils sont liés à d'autres tables de la base de données. Il y a donc encore des travaux d'entretien ménager dans le projet de conception de la base de données à faire concernant toute la base de données et ces deux nouvelles tables.

En référence à la table de catégorie-produit, n'oubliez pas qu'il existe déjà un tableau de produits en 4NF et une table de catégorie en 4NF dans la base de données. Pour qu'une table soit sous une forme normale, elle ne devrait pas violer les règles de ce formulaire normal. Le tableau des produits ou des produits a un produit comme clé et catégorie ou catégorie ou catégorie comme clé étrangère.

Ainsi, le tableau des produits de catégorie produits ici, en 4NF, devrait être abandonné car les deux tableaux suivants, qui sont en 4NF, ont toutes ses informations (et plus):

Catégories (catégoriesid, catégoriename, description)
Produits (ProductId, catégorieID, fournisserid, productName, Unitprice, QuantityInstock, ReortreLevel)

D'un autre côté, le tableau de catégorie-client en 4NF ne peut pas être abandonné, car il est livré avec de nouvelles relations sur la livraison. En fait, la table doit être mieux appelée, catégorie de livraison. L'appeler ProductDelivery serait trompeur pour les programmeurs de base de données, mais ne serait pas trompeur pour les clients, qui sont analphabètes dans la base de données. Alors appelez-le catégorie de livraison. Dans le formulaire de notation du tableau, c'est:

CatégoriedDelivery (catégorie, CustomerID)

N'oubliez pas que chaque clientId fait référence à une ligne dans la table des clients. La clé principale composite est: catégorie, clientId. Puisqu'il y a déjà un tableau de catégories avec catégorieId, ce tableau devrait en fait être:

CatégoryDelivery (catégorieId, CustomerId, catégorie)

où la catégorie dépend de la catégorie (nom) et du vice-versa.

La question de la livraison apporte donc un tableau supplémentaire en 4NF. Les autres tables de la base de données sont déjà en 4NF, car ils ne violent pas les règles 4NF indiquées ci-dessous.

Le problème de livraison n'était pas prévu avant le début de leurs différentes classes, au début. S'il avait été prévu comme indiqué ci-dessus, la livraison de catégorie serait arrivée; à ou avant la troisième étape de forme normale sans aucune mention de 4NF.

Quatrième règles de formulaire normal

Une table est en 4NF si elle ne viole pas les règles suivantes:

1. Il est déjà sous forme normale de Boyce-Codd.
2. Le tableau n'a pas de dépendance multi-valeurs.

Cela signifie qu'une table peut être conçue la première fois, et elle est déjà en 4NF.

Cinquième forme normale

5NF Les situations se produisent rarement, mais lorsqu'elles se produisent, la cinquième forme normale doit être prise en considération afin d'éviter tout problème de comptabilité connu. La cinquième forme normale est également connue sous le nom de projection de jointure normale. Avec la cinquième forme normale, il y a au moins trois colonnes. S'il n'y a que trois colonnes d'intérêt, alors il y a une clé primaire composite, qui est composée des trois colonnes.

Imaginez que vous, le propriétaire, avez eu jusqu'à deux magasins de commodité dans la même ville et que vous êtes fourni par le même ensemble de fournisseurs. Appelez ces magasins, shop1 et shop2. Les fournisseurs voient ces deux magasins différents comme deux clients différents. Alors ici, le client a une signification différente. Cela signifie faire du shopping et pas la personne. Le sens du produit reste le même.

Il y a donc une table avec les clés principales: fournisseur, produit et client. C'est-à-dire:

Table (fournisseur, produit, client)

Le numéro 5NF apparaît lorsqu'un fournisseur donné peut fournir un produit donné à plus d'un client (les deux magasins). De plus, un client donné peut recevoir un produit donné de plus d'un fournisseur. Et un client donné peut recevoir de différents fournisseurs différents produits. C'est-à-dire que l'un des trois partenaires peut faire les mêmes choses aux deux autres partenaires.

C'est-à-dire qu'un fournisseur peut correspondre à plus d'un client. Un client peut correspondre à plus d'un produit. Et un produit peut correspondre à plus d'un fournisseur. Cela signifie que les trois tables binaires suivantes peuvent en résulter:

Table de fournisseur-client
Tableau client-produit
Tableau de soutien-produit

Si une table parent peut être divisée en trois tables plus petites sans aucune perte ou ajout d'informations, et si lorsque les tables sont retenues, il n'y a toujours pas de perte ou d'ajout d'informations, alors la table parent doit être décomposée. Les petites tables sont en 5NF. Dans ce cas, la dépendance à la jointure a été éliminée. La perte d'informations signifie perdre des relations de lignes et l'ajout d'informations signifie ajouter de nouvelles relations avec les lignes.

Si cette décomposition et le remise en place entraîneraient une perte ou un ajout d'informations, alors le tableau ne doit pas être décomposé. Dans ce cas, le tableau parent est déjà sous la cinquième forme normale.

À ce stade, vous, le développeur et le formateur de la base de données, dites: «Propriétaire, je laisse la mise en place de données dans les tables (table parent et trois petites tables) comme exercice pour vous. Je vais vérifier ça demain."

Cinquième règles de forme normale

Une table est en 5NF si elle ne viole pas les règles suivantes:

1. Il est déjà dans la quatrième forme normale.
2. Le tableau n'a pas de dépendance.

Cela signifie qu'une table peut être conçue la première fois, et elle est déjà en 5NF.

Conclusion

Un tableau est sous forme normale de Boyce-Codd si les règles suivantes sont obéies:

1. Le tableau doit déjà être sous la troisième forme normale.
2. Aucun attribut non prison (colonne) ne devrait dépendre de la partie de la clé primaire composite.

Une table est en 4NF si elle ne viole pas les règles suivantes:

1. Il est déjà sous forme normale de Boyce-Codd.
2. Le tableau n'a pas de dépendance multi-valeurs.

Une table est en 5NF si elle ne viole pas les règles suivantes:

1. Il est déjà dans la quatrième forme normale.
2. Le tableau n'a pas de dépendance.

Le propriétaire dit maintenant: «Cela appelle une grande célébration pour nous deux."

Vous, le développeur de la base de données, répond: «Pourquoi n'attendons-nous pas demain quand je vais rassembler toutes les tables et améliorer la table des produits?"

Le propriétaire réagit en souriant: «Que ferais-je sans toi?"

Vous, le développeur de la base de données, ajoutez, souriant: «A demain alors, dans votre bureau." et part.