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:
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)
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)
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.
