J'essaie d'obtenir une version définitive de ce qu'est la première forme normale. Tout ce que je lis a une tournure légèrement différente.

De nombreuses autorités, telles que Date, affirment que, par définition, une relation est toujours sous sa première forme normale, tandis que d'autres donnent une liste d'exigences. Cela signifie qu'il existe de zéro à de nombreuses exigences pour 1NF.

Je suppose que la différence est celle entre les tables et les relations: les tables peuvent être un gâchis complet, tandis qu'une relation suit certaines restrictions. Le fait qu'une relation soit représentée sous forme de table en SQL crée donc une certaine confusion.

Je me concentre spécifiquement sur 1NF en ce qui concerne les bases de données SQL. La question est: quelles propriétés sont nécessaires pour garantir qu'une table est dans la première forme normale?

De nombreuses autorités suggèrent que si un tableau représente une relation , il est déjà dans 1NF. Cela repousse la définition de 1NF à la définition d'une relation.

Voici quelques propriétés d'une table en 1NF:

• L'ordre des colonnes est insignifiant [1]
• L'ordre des lignes est insignifiant
• Toutes les lignes ont la même longueur (c.-à-d. Que les données de ligne correspondent aux en-têtes de colonne)
• Il n'y a pas de lignes en double (cela peut être garanti en utilisant une clé primaire de substitution, mais le PK n'est pas lui-même requis)
• Il n'y a pas de colonnes répétitives
• Chaque colonne contient une seule valeur (atomique)

[1] Techniquement, les attributs ne sont pas ordonnés, mais dans un tableau, les données de ligne doivent être dans le même ordre que les en-têtes de colonne. Cependant, la commande réelle est insignifiante.

Sur plusieurs données :

Le concept des données atomiques est qu'un élément ne peut plus être ventilé. Ce concept a été qualifié en ce que, bien que techniquement tout puisse être décomposé à la nausée , les données en question ne peuvent pratiquement plus être décomposées, selon la façon dont les données seront utilisées.

Par exemple, une adresse complète ou un nom complet devrait normalement être décomposé davantage, mais les composants tels que le nom donné ou le nom de la ville ne devraient probablement pas être décomposés davantage, malgré le fait qu'en tant que chaînes, ils puissent l'être.

En ce qui concerne les colonnes répétitives, c'est une colonne de conception médiocre d'avoir des colonnes presque répétitives, telles que phone1, phone2etc. En général, les données répétées indiquent la nécessité d'une table associée supplémentaire.

Dépendance

Il ne doit pas y avoir de relation entre les lignes, si ce n'est qu'elles sont conformes aux mêmes en-têtes.

Il ne devrait pas non plus y avoir de relation entre les colonnes, mais je pense que c'est le sujet des formes normales supérieures.

La question est: quelle proportion de ce qui précède se trouve dans la définition de 1NF? Le bit de lignes indépendantes y entre-t-il également?

Préliminaire

La définition de la forme normale (qui, à partir de la présentation de «Normalisation supplémentaire du modèle relationnel de la base de données» en 1971, est connue sous le nom de première forme normale ) et la définition du paradigme relationnel lui-même ont été publiées en 1970 dans l'article scientifique qui a fourni une solide fondement de la pratique de l'administration de bases de données, c'est-à-dire «Un modèle relationnel de données pour les grandes banques de données partagées» (RM pour la brièveté) créé par le Dr EF Codd , qui est un lauréat du prix Turing et l' autorité en ce qui concerne le cadre relationnel.

Oui, il y a beaucoup d'explications, d'interprétations, d'expositions, d'écarts et d'opinions sur le texte du Dr Codd, mais je préfère personnellement m'en tenir à la source originale et je vous suggère fortement de l'analyser par vous-même afin de pouvoir tirer vos propres conclusions.

Je ne comprends certainement pas la RM dans son intégralité, mais ce que je comprends d'elle me permet d'apprécier son excellence, sa vision, son intention et sa portée, et bien que des décennies plus tard on puisse noter qu'elle a quelques légères imprécisions, elles ne réduisent pas, en aucune façon, son génie et son élégance. Dans son domaine, la RM a résisté à l'épreuve du temps d'une manière unique et reste inégalée.

Le fait de souligner les imprécisions susmentionnées serait - en utilisant un terme caritatif - injuste parce que, vu à une distance considérable, ce matériau séminal nécessitait quelques raffinements et extensions, oui, mais le corps principal de l'œuvre était solide comme le roc du conception même (et, en fait, le Dr Codd a fait la plupart - sinon la totalité - de ces raffinements et extensions lui-même).

Je continue de relire le RM en permanence afin de renforcer ma compréhension de cette source exceptionnelle de connaissances (et mon estime continue de croître à chaque relecture); l'objectif est de se tenir sur les épaules des géants.

Relations et tableaux

Il est important de noter que, comme les relations sont des ressources abstraites , M. Codd a envisagé l’utilité de les représenter sous forme de tableau (il a initialement utilisé le terme «représentation de tableau» mais a ensuite utilisé «table» ou «r-table»), de sorte que les utilisateurs, concepteurs et administrateurs d'une base de données relationnelle (RDB) peuvent les approcher de manière plus familière ou concrète . Par conséquent, dans le contexte d'une implémentation RDB, il est valide d'utiliser la table comme raccourci pour la relation, tant que ce tableau représente une relation réelle. Cette caractéristique est - bien qu'évidente - assez importante car avant d'évaluer si une table représente ou non une relation conforme à la première forme normale (1NF), elle doit représenter précisément une relation.

Le RM contient naturellement les qualités qu'une table doit avoir pour déterminer si elle dépeint en fait une relation, mais je proposerai ici une interprétation informelle et sans prétention (une autre, oui!):

• Il doit avoir un nom (chaque relation particulière dans une structure de base de données doit être distinguée des autres).
• Chacune de ses lignes doit représenter exactement un tuple de la relation pertinente.
• L' ordre de ses lignes n'est pas du tout important.
• Chacune de ses colonnes doit avoir un nom qui représente la signification d'exactement un domaine de la relation concernée, et ledit nom doit être différent des noms des autres colonnes du tableau (une colonne doit être différenciée de façon unique et doit contenir un sens distinctif et, oui, le rôle joué par un modélisateur de base de données et les experts en affaires pour définir chaque domaine d'importance avec précision est primordial)
• L' ordre de ses colonnes n'a aucune signification.
• Toutes ses lignes doivent avoir le même nombre de colonnes.
• Il doit avoir au moins une colonne, ou une combinaison de colonnes, qui identifie de manière unique chacun des tuples représentés via des lignes; de cette façon, toutes les lignes doivent être différentes (oui, cela souligne l'importance d'avoir au moins une clé déclarée, et lorsqu'il y a deux clés ou plus, une doit être définie comme PRIMAIRE pour des raisons pragmatiques, tandis que le reste peut être considérée comme ALTERNATIVE, mais oui, avant de prendre la décision, chacune des CLÉS était «candidate» à une définition PRIMAIRE).

Il est essentiel d'avoir une table qui représente en fait une relation car, lorsqu'elle subit des opérations de manipulation de type relationnel, le résultat est, encore une fois, une table qui représente une relation. De cette manière, le comportement de ladite table est prévisible .

Domaines atomiques (colonnes)

Dans les premières sections de la RM, le Dr Codd présente plusieurs exemples de relations afin d'introduire certains concepts; ainsi, afin de comprendre la signification du domaine atomique , commençons par l'extrait suivant de la RM qui détaille certains points pertinents:

Jusqu'à présent, nous avons discuté d'exemples de relations qui sont définies sur des domaines simples - domaines dont les éléments sont des valeurs atomiques (non décomposables). Les valeurs non anatomiques peuvent être discutées dans le cadre relationnel. Ainsi, certains domaines peuvent avoir des relations en tant qu'éléments. Ces relations peuvent à leur tour être définies sur des domaines non simples, etc.

De cette façon, on peut dire que chacune des relations expositives susmentionnées correspond à l'un des deux types, soit le type A ou le type B :

• Le type A regroupe uniquement les relations (tables) qui sont structurées avec des domaines (colonnes) qui contiennent exclusivement des valeurs simples dans chacun de leurs tuples (lignes), c'est-à-dire que ces domaines (colonnes) ne contiennent pas de relations (tables) en tant que valeurs, qui en ce contexte signifie que les valeurs sont atomiques car elles ne peuvent pas être décomposées successivement en nouvelles relations (tables). Par conséquent, les relations de cette classe sont celles qui sont normalisées , c'est-à-dire qu'elles sont conformes à 1NF, leur forme est souhaitable.

• Le type B est exclusivement intégré par des relations (tables) qui ont un ou plusieurs domaines (colonnes) qui contiennent des relations en tant que valeurs dans chaque tuple (ligne) respectif, et cela signifie que lesdites valeurs sont non anatomiques puisqu'elles peuvent ensuite être décomposées en nouvelles relations (tableaux), c'est-à-dire qu'ils sont décomposables . Ainsi, les relations de ce type ne sont pas normalisées, c'est-à-dire qu'elles enfreignent 1NF, elles sont sous une forme indésirable.

Normalisation

Le Dr Codd présente la section sur la normalisation dans la RM avec le paragraphe suivant:

Une relation dont les domaines sont tous simples peut être représentée en mémoire par un tableau à colonnes homogènes bidimensionnel du type décrit ci-dessus. Une structure de données plus compliquée est nécessaire pour une relation avec un ou plusieurs domaines non simples. Pour cette raison (et d'autres à citer ci-dessous), la possibilité d'éliminer les domaines non simples semble être étudiée! Il existe en fait une procédure d'élimination très simple, que nous appellerons normalisation.

Puis il continue en montrant:

1. Un groupe de relations où l'on n'est pas normalisé (il a des domaines qui contiennent des relations en tant que valeurs, c'est-à-dire qu'elles ne sont pas anatomiques; c'est-à-dire qu'elles ne sont pas simples)

2. Un groupe de relations normalisées (c.-à-d. Une qui a été décomposée; c.-à-d. Une relation dont les domaines valorisés ont été décomposés en domaines simples qui signifient qu'ils sont atomiques)

Et puis il décrit la procédure pour obtenir des relations normalisées à partir de relations non normalisées.

À cet égard, les relations qu'il a utilisées pour illustrer un exercice de normalisation et la description de l'exercice lui-même sont assez claires, et je recommande à nouveau de les analyser vous-même (et j'espère également que cela encouragera certains lecteurs à s'engager dans le texte).

Heureusement, il indique:

D'autres opérations de normalisation sont possibles. Ceux-ci ne sont pas discutés dans cet article.

Et lesdites opérations, c'est-à-dire la deuxième et la troisième forme normale (2NF et 3NF) sont en fait détaillées dans «Normalisation supplémentaire du modèle relationnel de la base de données», et comme mentionné ci-dessus, après la présentation (et l'impression et la publication ultérieures) de ce document , la forme normale d' origine est devenue la première forme normale.

Comme un praticien peut le constater, le fait d'avoir des relations (tables) non normalisées introduit une convolution (presque toujours inutile) dans les implémentations RDB.

Une relation qui satisfait 1NF, facilite la définition des contraintes et des opérations de manipulation de données qui peuvent être mises en œuvre au moyen d'un sous-langage de données moins complexe que celui requis pour les relations non normalisées (tableaux), comme le souligne le Dr Codd dans les lignes suivantes:

L'adoption d'un modèle relationnel de données, tel que décrit ci-dessus, permet le développement d'un sous-langage de données universel basé sur un calcul de prédicat appliqué. Un calcul de prédicat de premier ordre suffit si la collection de relations est sous forme normale. Un tel langage fournirait une mesure de la puissance linguistique pour tous les autres langages de données proposés et serait lui-même un candidat solide pour l'incorporation (avec la modification syntaxique appropriée) dans une variété de langages hôtes (programmation, commande ou problème). […]

[…]

L'universalité de la sous-langue des données réside dans sa capacité descriptive (et non sa capacité informatique).

La perplexité

De mon point de vue, la confusion est apparue, en raison (a) de l'excès susmentionné d'interprétations, d'explications, etc., à propos de 1NF et de la RM elle-même, et en raison de (b) de nouvelles tentatives de redéfinir 1NF qui affirment avoir des relations avec des domaines qui contiennent des valeurs qui sont à leur tour des relations conformes à 1NF tant qu'elles ne représentent qu'une seule valeur pour chaque tuple correspondant.

Mon point de vue sur vos autres points

Il ne doit pas y avoir de relation entre les lignes, si ce n'est qu'elles sont conformes aux mêmes en-têtes.

Je ne sais pas si je comprends bien l'intention de cette déclaration mais, en plus de se conformer aux mêmes en-têtes, il doit y avoir une connexion entre les lignes (tuples) d'une relation (table) car chacune d'elles doit être une affirmation à propos d'un occurrence particulière du type d'entité spécifique (défini en termes de contexte commercial d'intérêt) que la relation (table) est censée représenter.

Il ne devrait pas non plus y avoir de relation entre les colonnes, mais je pense que c'est le sujet des formes normales supérieures.

Je ne sais pas non plus si j'interprète correctement le sens de cette déclaration, mais, en fait, et conformément à ma réponse à l'aspect précédent, il doit également y avoir une relation entre les domaines (colonnes) d'une relation (tableau) , c'est précisément pourquoi il s'agit d'une relation (la structure essentielle du modèle relationnel et d'une implémentation concrète RDB).

Pour illustrer, en ce qui concerne la relation hypothétique (tableau)

• Salary (PersonNumber, EffectiveDate, Amount)

le tuple (ligne)

• Salary (x, y, z)

donnerait le sens

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Par conséquent, chaque tuple (ligne) de la Salaryrelation (tableau) doit correspondre à la structure de l'assertion indiquée ci-dessus, et la différence serait le remplacement des valeurs de domaine (colonne) pertinentes, mais il doit exister une relation entre (a) tous les Salarydomaines (colonnes) et également entre (b) toutes leurs valeurs correspondantes par rapport à chaque tuple (ligne); une telle relation est indispensable.

Les formes normales supérieures (2NF et 3NF) sont utiles pour se débarrasser des dépendances fonctionnelles entre les domaines (colonnes) d'une relation (table), elles aident à éviter les connexions indésirables entre les domaines (colonnes), car lesdites connexions indésirables permettent l'introduction d' anomalies de mise à jour . Les deux 2NF et 3NF sont utiles pour tester la solidité de la structure des relations (tables) dans une certaine implémentation RDB.

Une illustration. Prenez une chaîne de texte qui contient une adresse américaine typique:

"123 Cornhusk Rd., South Succotash, NY 12345"

Écrire une requête pour trouver tous les résidents de Cornhusk Road ou un résident particulier de la ville de South Succotash ou de l'État de New York serait une tâche ardue. En particulier lorsque vous avez les chaînes suivantes dans les données:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Chacun d'eux spécifie la même adresse réelle (et cela ne prend même pas en compte les fautes d'orthographe probables comme "Succatash") mais écrire l'algorithme pour les comparer avec succès est quelque chose que je ne voudrais PAS consacrer à mes dernières années restantes sur cette Terre.

Entrez le premier formulaire normal. Je n'entrerai pas dans les détails de la façon dont cela se fait, il suffit de considérer un formulaire commun comme on le voit dans la plupart des bases de données:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Ce n'est pas une normalisation complète. Par exemple, vous pouvez encore diviser Street en StreetNum et StreetName, mais cela suffit pour une illustration simple et c'est vraiment aussi loin que le processus de normalisation est pris dans la vie réelle. Il y a toujours un petit problème pour trouver tous les habitants de Cornhusk Road, mais si vous recherchez dans la rue la sous-chaîne "Cornhusk" et qu'il se trouve qu'il y a une ville nommée Cornhusk quelque part, au moins cela ne causera pas de confusion.

Le problème avec la définition fournie par Date, et al, est qu'ils ne regardent pas à l'intérieur d'un élément de données et ne considèrent pas la signification de ces données. Non pas que je les blâme particulièrement, cela peut être assez difficile.

Nous devons donc prendre une "chaîne de caractères" et la transformer en une "adresse". Mais trouver une définition tout compris de l' adresse n'est pas aussi simple qu'il n'y paraît. Surtout lorsque vous travaillez avec des adresses dans plusieurs pays.

Tout d'abord, nous fixons le contexte. Rien n'a de sens sans contexte. Notre contexte ici est l' adresse . Dans ce contexte, nous pouvons voir des parties des données qui ont des significations spécifiques, telles que rue , ville , etc. Nous attribuons à chaque signification un champ distinct.

La partie difficile est que les données, comme les mots, peuvent avoir des significations différentes pour différentes personnes ou certaines personnes peuvent voir le sens là où d'autres ne le font pas. Il peut s'agir d'un projet en soi et nécessiter beaucoup d'efforts de coopération. Mais c'est un élément essentiel d'une bonne conception de base de données.

Le point de normalisation est d'éliminer ou au moins de minimiser les données anormales . Considérez le fait que, dans le tableau ci-dessus, une ville ou un code postal peut être entré qui n'existe pas dans l'état qui a été sélectionné. Ou une rue entrée qui n'existe pas réellement dans la ville sélectionnée. Ah, mais maintenant nous entrons dans la deuxième et la troisième forme normale et c'est un autre sujet.

Considérez 1NF comme une introduction au concept mathématique des relations, plutôt qu'une structure de données particulière ou un ensemble fixe de règles. Les structures mathématiques comme les relations peuvent être représentées de différentes manières - les tableaux ne sont que l'un des moyens les plus pratiques. Lors de l'utilisation de tables, il existe des restrictions pour garantir qu'elles représentent clairement leurs relations prévues et que les opérations sur les tables sont logiquement correctes par rapport aux relations représentées.

Lorsque nous disons que l'ordre et la duplication des colonnes et des lignes sont insignifiants, c'est pour garantir que toutes les informations importantes sont enregistrées en tant que valeurs dans le tableau et accessibles à nos requêtes, et non encodées dans la présentation du tableau. Bien que peu, le cas échéant, d'auteurs aient explicitement interdit l'utilisation de la couleur dans les tableaux, la compréhension de l'objectif des restrictions ci-dessus nous conduirait à exclure de la même manière l'utilisation de couleurs de présentation significatives de sorte que des valeurs de couleur significatives doivent être explicitement enregistrées. Date et d'autres auteurs déconseillent également les identificateurs de lignes masqués pour la même raison.

Le concept d'atomicité consiste à s'assurer que toute structure significative est exprimée sous forme de relations, afin que nous puissions analyser les dépendances dans toutes nos données et éviter les anomalies, et que toute structure significative soit uniformément accessible aux opérations relationnelles. Les valeurs composites ne sont pas invalides, mais elles nécessitent le décompactage d'opérateurs spécifiques au domaine, ce qui augmente la complexité et peut introduire une redondance. Bien sûr, dans la pratique, certains types composites simples et opérateurs associés sont pratiques et contribuent à augmenter la compacité et l'expressivité des requêtes, mais cela ne contredit pas la théorie.

Les dépendances de lignes comme les dépendances à valeurs multiples ne violent pas 1NF, mais comme les dépendances entre les colonnes, elles font l'objet de formes normales plus élevées. Près de colonnes de répétition aiment phone1, phone2, etc ne violent 1FN non plus , même si elles sont une mauvaise conception.

La définition et l'explication de WikiPedia sur 1NF, je pense que c'est assez bon. - joanolo

Développer une phrase dans l'article Wikipedia:

Vu comme des numéros de téléphone, le texte n'est pas atomique

Cela peut vous expliquer pourquoi il y a tant de confusion. Si ce n'est qu'un bout de texte, alors c'est atomique. Mais si c'est vu comme des numéros de téléphone, ce n'est pas atomique. Date et d'autres contournent ce problème. Cela a à voir avec la signification des données. Lorsque vous analysez le sujet, vous devez vous attaquer à la signification des données.

La question de savoir s'il y a lieu de le décomposer davantage est pertinente pour la question de savoir si la première forme normale a été remplie. Le point derrière 1NF est de fournir un accès par clé à toutes les données. Mais si la chose que vous récupérez via l'accès à clé possède une sous-structure, vous n'avez pas d'accès à clé à la sous-structure. - Walter Mitty

«1NF» est utilisé pour désigner un tas de choses différentes , dont beaucoup sont à la fois absurdes et courantes. Voir ma réponse à "Normalisation dans le système de gestion de base de données" , y compris ses liens. L'une d'elles est ma réponse à "Qu'est-ce que l'atomicité dans les dbms" . (Les deux à Stack Overflow.) - philipxy

_{Réponse Wiki de la communauté créée à partir des commentaires laissés sur la question}