Bonsoir,
Envoyé par
escartefigue
Une table est le résultat de ce qu'on a modélisé, elle n'est pas par vocation en première forme normale, je connais pléthore de cas prouvant le contraire !
Comme tu as raison, Capitaine ! Une table est a priori un sac (ainsi on peut y trouver des lignes en double), tandis qu’une relation de la théorie relationnelle est un ensemble : les doublons sont forcément interdits.
Envoyé par
martinbrait
Un rappel des règles de conception m'a interloqué, proposant d'introduire des champs multivalués.
Plutôt que de champs, en relationnel parlons plutôt d’attributs (voire de colonnes en SQL). Sinon, CinePhil risque de faire les gros yeux et de vous taper sur les doigts avec son patatographe...
Ceci dit, voici la définition de la première forme normale telle que nous la fournit C. J. Date, auteur inlassable et grand contributeur de la théorie relationnelle (définition qu’il donne par exemple dans Database Design and Relational Theory, Second Edition) :
Definition (first normal form): Let
relation r have attributes
A1, ...,
An of types
T1, ...,
Tn, respectively. Then
r is in first normal form (1NF) if and only if, for all tuples
t appearing in
r, the value of attribute
Ai in
t is of type
Ti.
Il est évidemment sous-entendu que les tuples en double sont interdits puisqu’un relation est un ensemble. Date poursuit :
To say it in different words, 1NF just means that each tuple in the relation in question contains exactly one value, of the appropriate type, for each attribute. Observe in particular, therefore, that 1NF places absolutely no limitation on what those attribute types are allowed to be. They can even be relation types! That is, relations with relation valued attributes– RVAs for short– are legal (you might be surprised to hear this, but it’s true). An example is given in Figure 4-1 below.
Notez bien que l’attribut (RVA) PQ prend des valeurs qui sont des relations, lesquelles ont donc nécessairement un en-tête (en l’occurrence {PNO, QTY}).
Par contraste, dans le cas de l’extension NF² on sort carrément du cadre de la théorie relationnelle proprement dite. Par exemple, dans Verso, système orienté NF², au paragraphe II.1 l’attribut BOOK prend des valeurs qui ne sont pas des relations au sens habituel, car dépourvues d’en-tête.
Les auteurs se départissent volontairement de la première forme normale.
A juste titre Verso peut interloquer le partisan de la modélisation traditionnelle... Pour plus d’information au sujet du rejet de la NF² par la théorie relationnelle orthodoxe, celle à laquelle j’adhère, je vous renvoie aux paragraphes 2.2. 2.3. et 2.6. de mon article Bases de données relationnelles et normalisation : de la première à la sixième forme normale. (A noter que la mise en forme de l’article a été massacrée par quelqu’un ayant certainement de bonnes intentions, mais qui aurait mieux fait de s’abstenir).
A signaler encore une précision apportée par Date dans son ouvrage :
Definition (normalized): Relation r is normalized if and only if it’s in 1NF.
In other words,
normalized and first normal form mean exactly the same thing– all normalized relations are in 1NF, all 1NF relations are normalized. The reason for this slightly strange state of affairs is that
normalized was the original (historical) term; the term 1NF wasn’t introduced until people started talking about 2NF and higher levels of normalization, when a term was needed to describe relations that weren’t in one of those higher normal forms.
Au passage, ne pas confondre 2NF (deuxième forme normale) et NF² (non first normal form, prononcer « NF squared »).
Une précision concernant la distinction entre relations et relvars, en observant que dans ce qui précède, Date n’a parlé que de relations. Je le cite à nouveau :
Observe now that all of the discussions in this section so far (the definitions in particular) have been framed in terms of relations, not relvars. But since every relation that can ever be assigned to a relvar is in 1NF by definition, no harm is done if we extend the 1NF concept in the obvious way to apply to relvars as well– and it's desirable to do so, because (as we'll see) all of the other normal forms are defined to apply to relvars, not relations. In fact, it could be argued that the reason 1NF is defined in terms of relations and not relvars has to do with the fact that it was, regrettably, many years before that distinction (I mean the distinction between relations and relvars) was properly drawn, anyway.
Envoyé par
martinbrait
Utilisez-vous souvent des stockages multivalués, dans des colonnes à valeur complexe ? Avez-vous des exemples parlants, de stockages multivalués, dans des colonnes à valeur complexe ?
En l’absence d’une définition pour les « colonnes à valeur complexe », à défaut servons-nous des v-relations de Verso : je réponds négativement à votre question quant à l’utilisation de ma part de ce genre de colonnes. Concernant des exemples parlants, là aussi on peut se référer aux v-relations. Par contre, concernant les RVA qui ne sont certainement pas des « attributs à valeur complexe », il m’arrive de m’en servir, mais seulement à titre d’exercice, car la manipulation de ces attributs n’est pas aisée. Je vous renvoie à ce propos à nouveau au paragraphe 2.6 de mon article, plus particulièrement au sous-paragraphe « Inconvénients des RVA ».
Envoyé par
martinbrait
Les stockages multivalués dans des colonnes complexes, sont ils compatibles avec les règles de conception MERISE ?
Paprick vous répondrait mieux que moi. En tout cas la normalisation au sens de Merise l’interdit. Maintenant, si vous allez vers l’orientation objet dans Merise (OOM), alors tout est possible, comme le montre son métamodèle (attributs multivalués notamment), que je fais figurer ci-dessous et que je reprends de l’ouvrage Les Objets de Mokrane Bouzeghoub, Georges Gardarin et Patrick Valduriez :
A propos de l’atomicité.
Les définitions de la première forme normale font très souvent usage de l’atomicité.
Cela paraît suspect à Date qui écrit à peu de choses près ceci : hier la relation r était en première forme normale, aujourd’hui elle ne l’est plus... De fait, être atomique est temps dépendant...
Ainsi, avec SQL, avant que la norme et les SGBD ne nous fournissent la fonction Substring, les chaînes de caractères étaient atomiques, mais avec substring on peut aller farfouiller dedans...
Quant à l’atome lui-même (référence à Wikipédia) : avant la découverte de l’électron par Joseph Thomson (1897) et du noyau par Rutherford (1911), l’atome fut pendant 25 siècles... atomique. Puis en 1919 Rutherford mit en évidence les protons au sein du noyau. Les protons + les neutrons forment les nucléons et aujourd’hui on a les quarks et les gluons nichés dans les nucléons, et dissociables en paires quarks-antiquarks. A qui le tour ? L’atomicité a un côté Fregoli...
Bon, ben, à titre d’exercice y a plus qu’à modéliser tout ça...
Je vous renvoie à l’article dans lequel j’ai récupéré l’image : Antimatter in the proton is more down than up
[FORME NORMALE ETENDUE] Exemple pertinent de MCD avec tables contenant champ multivalué
Répondre avec citation
Partager