Discussion:Forme normale (bases de données relationnelles)
Heu... a la reflexion il me semble qu'il existe une 4e forme normale. A verifier...
-- AlNo 18 déc 2003 à 00:44 (CET)
exemple???
modifierpersonne ne pourrait rajouter des exemples pour les autre forme normales (la 2 la 3 .. la 4..) ? de la même maniere que pour la 1 c'est bien plus clair. merci Fab97 31 jul 2004 à 23:38 (CEST)
concept bien plus large !!!
modifierIl n'y a pas qu'en SGBD qu'on parle de formes normales !!!
Une forme normale, de manière générale, dans un langage formel quelconque muni d'une relation d'équivalence (sémantique) est la donnée d'un moyen d'obtenir un représentant unique de chaque classe d'équivalence.
Par exemple : en calcul des propositions il existe une forme normale conjontive : (A1 ou A2 ou ... An1) et (B1 ou B2 ou ... Bn2) et (C1 ou c2 ou ... Cn3) et ... et une forme normale disjonctive : (A1 et A2 et ... An1) ou (B1 et B2 et ... Bn2) ou (C1 et c2 et ... Cn3) ou ...
Alors j'hésite entre deux modifications : rendre l'article plus général (en gardant le contenu dans une sous-partie), et modifier les inter-wiki, ou alors le déplacer vers Normalisation de bases de données (plus proche des titres suomi et anglais ... le titre allemand faisant la même erreur), et écrire un nouvel article sous l'ancien nom.
J'insiste, ce n'est pas un problème de terme ambigü ou d'homonymie : c'est vraiment que l'article courant n'est qu'un cas particulier.
--Ąļḋøø 20 aoû 2004 à 23:12 (CEST)
D'accord avec toi, mais l'article s'intitule quand-même "Forme_normale_(bases_de_données_relationnelles)". il faudrait créer un autre article et lier les deux. ~~Cedringen (d) 21 mars 2010 à 19:01 (CET)
- oui tout à fait 81.18.187.112 (discuter) 14 août 2024 à 18:10 (CEST)
De la normalisation des relations
modifierQuelqu'un écrit : " Il n'y a pas qu'en SGBD qu'on parle de formes normales !!! " : je confirme, car la normalisation des relations adhérant au Modèle relationnel de données ne relève que de ce dernier, il s'agit d'un cas très particulier. Cela dit, il ne faut pas rendre l'article en cause plus général, car l'objet des formes normales conjonctive/disjonctive est radicalement différent de celui du Modèle relationnel : dans le premier cas, il s'agit de formaliser des propositions dans le but (entre autres) de les manipuler plus facilement, alors que dans le second cas, il s'agit d'éliminer des sources d'anomalies dans les valeurs prises par les relations. (Attention aussi à l'homonymie et ne pas confondre la normalisation des relations Est-Ouest et la normalisation des relations du Modèle relationnel...)
Le sujet "normalisation des bases de données" ne doit donc être accessible qu'à partir des seuls thèmes "Modèle relationnel de données", "Systèmes de gestion de bases de données relationnelles" et apparentés.
Définition 1NF
modifierBonjour,
J'ai un doute sur cette partie de la définition de la 1NF:
"Toute propriété doit avoir un sens pour toute occurrence de la relation ou de l’entité"
Ce qui, à mon sens, signifie que pour bien faire, les champs autorisant le NULL doivent être interdits. Ce qui voudrait dire que pour une table (nom, prénom, date de naissance, adresse) On ne serait pas en 1NF dès lors que l'on introduirait des sdf dans les données... Or, d'après toutes les sources consultées, la seule chose imposée par la 1NF, c'est l'atomicité des valeurs.
quelques sources:
http://www.inrets.fr/nojs/js/js/ur/cir/bl/coursingres/oi_chap1.html
http://www.grappa.univ-lille3.fr/~torre/guide.php?id=coursbd
http://en.wikipedia.org/wiki/Database_normalization
http://oldweb.uwp.edu/academic/mis/baldwin/normal.htm
- Je confirme que le NULL entraine une dénormalisation. J'avais précisé dans la définition 1NF : Cette normalisation peut amener à créer des sous-types spécialisés pour les propriétés non systématiquement pertinentes (il me semble qu'on est là sur le bon sujet). Le fait qu'on autorise du NULL dans une table physique de données ne signifie pas que le modèle conceptuel de données n'est pas normalisé. Les modèles physiques de données sont toujours plus ou moins dénormalisés, et heureusement, pour des raisons d'optimisation de stockage ou d'accès.BMR
Mes récents cours de BD relationnelles en école d'ingé confirment ce qui est dit ici: 1NF = atomicité des valeurs. Ceci se confirme par des recherches un peu poussées sur internet.
Confusion entre Merise et la théorie relationnelle
modifierIl est écrit :
"Dans une base de données relationnelle, une forme normale désigne un type de relation particulier entre les entités."
Selon la théorie relationnelle, dans une base de données relationnelle, il n'y a pas d'entités, mais des variables relationnelles (informellement tables) qui prennent des valeurs appelées relations. Ces relations n'ont évidemment rien à voir avec les relations merisiennes qui sont des associations entre entités (voire entre relations si l'on passe à OOM). Étant donné qu'il est traité ici de la normalisation selon une vision merisienne, l'article doit changer de titre :
"Formes normales (Merise)"
Qui plus est, une relation au sens de la théorie relationnelle respecte par définition ce qui est appelé ici "Première Forme Normale".
Admettons malgré tout que l'on éprouve le besoin de définir une 1FN. Aucun théoricien authentique de la théorie relationnelle n'y fait intervenir la nécessité d'une clé (terme à remplacer par celui d'identifiant dans le contexte Merise). En effet, par définition une relation est un ensemble et doit être en conséquence dotée d'au moins une clé candidate, avant toute chose. Dans le même sens, je dirais qu'en Merise toute entité doit être identifiée, sinon on ne sait pas de quoi il s'agit. C'est un prérequis. Si vous tenez à parler de 1FN, limitez-vous au principe d'unicité (interdiction des listes de valeurs).
Dans chaque relation, chaque tuple contient exactement une valeur pour chacun de ses attributs. Une relation qui vérifie cette propriété est en première forme normale (1NF).
Concernant les dépendances fonctionnelles, c'est mal parti. En effet, une DF en Merise est une contrainte inter-entités : Étant données les entités A, B, ..., M, N participant à une relation R, on dit que le m-uplet (A, B, ..., M) détermine N et l'on note A X B X ... M -> N, si pour le m-uplet d'occurrences de (A, B, ... M), il y a exactement une occurrence de N (contrainte d'unicité inter-entités). Dans le cadre de la théorie relationnelle, une DF engendre aussi une contrainte d'unicité, mais intra-relation (relation au sens informel table) car entre sous-ensembles d'attributs d'une variable relationnelle donnée. Ces DF sont régies par un système axiomatique totalement étranger à Merise. Si vous tenez à établir des DF inter-relations (inter-tables), définissez à cet effet une vue de jointure et vous reviendrez ainsi à la case Départ. Bref, à part le principe d'unicité, les DF de la théorie relationnelle et celles de Merise sont des concepts différents.
Etc.
Autant dire que les définitions données ici des formes normales n'ont rien à voir avec celles de la théorie relationnelle, d'où mon observation renouvelée concernant la pertinence du titre de l'article.
=>
Article à reprendre à zéro.
Forme normale (bases de données relationnelles)
modifierLa définition de la forme normale 3 est fausse. La bonne définition est plutôt : la troisième forme normale respecte la deuxième forme normale et dont tous les attributs ne dépendant pas de la clé primaire ne dépend pas d'un attribut non clé. Autrement dit, si un attribut est non clé on utilise une clé étrangère pour référencer la valeur de l'attribut.
Exemple de normalisation forme normale 3
à mon avis l'exemple de normalisation choisi pour la forme normale 3 est mauvais
l'affirmation "Le pays de l'adresse [...] est fonction de la ville de l'adresse" est fausse
en effet, il y a plusieurs pays possibles pour une même ville
exemples : PARIS FRANCE mais aussi PARIS aux US dans l'illinois
BAGDAD IRAK mais aussi mexique, US et australie
BREST FRANCE mais aussi allemagne,bielorussie, croatie, serbie
voir la page homonymie de localités sur wikipedia http://fr.wikipedia.org/wiki/Catégorie:Homonymie_de_localités
bruno
213.41.175.97 (d) 2 mars 2009 à 12:22 (CET)
Attention : tu confonds la ville et le nom de la ville. pour un nom de ville, il y a plusieurs pays possible. mais pour une ville donnée, il n'y a qu'un pays. Reste à identifier correctement cette ville (en incluant le nom du pays en cas d'homonymie par exemple). ~~Cedringen (d) 21 mars 2010 à 19:13 (CET)
L'exemple ville-pays induit des confusions. Comme indiqué une ville ne peut pas appartenir à 2 pays mais un même nom de ville peut être utilisé dans 2 pays voire à l'intérieur du même pays. Le "en incluant le nom du pays en cas d'homonymie par exemple" pris au pied de la lettre peut faire penser qu'on va avoir dans un champ "LONDON UK"...ce qui consiste à briser la 1NF et si c'est dans 2 champs on retombe sur l'exemple. Un code pour la ville serait plus adapté.
première forme normale
modifierIl me semble que l'atomicité ne devrait concerner que des données "de gestion" mais qu'on pourrait avoir un champ qui contienne une liste libre de propriétés.
82.226.210.117 (d) 12 mai 2009 à 10:53 (CEST) Bernard
Non non. dans ce cas, on ne respecte pas la 1FN. Attention : on ne dit pas que les formes normales sont obligatoires... ~~Cedringen (d) 21 mars 2010 à 19:18 (CET)
Au sujet de la FNBC (Forme Normale de Boyce - Codd)
modifierDans la section "Les différentes formes normales", on peut lire au sujet de la FNBC:
* tous les attributs non-clé ne sont pas source de dépendance fonctionnelle (DF) vers une partie de la clé
Dans la section "Exemples de violation", on peut lire sur le même sujet:
* Si une entité ou une relation en troisième forme normale a une clé composée, aucune des propriétés élémentaires de cette clé ne doit être en dépendance fonctionnelle d’une autre propriété.
S'agit-il des attributs non-clé, ou bien des attributs élémentaires de la clé? Je pense qu'il y a là une erreur à corriger, ou une imprécision à clarifier.
--90.80.39.42 (d) 29 juillet 2009 à 10:35 (CEST) Philippe C.
Qu'est-ce qu'une anomalie transactionnelle ?
modifierJe ne comprends pas ce qu'est une anomalie transactionnelle. Peut-être que ceci pourrait être défini ? Merci --npettiaux (discuter) 21 novembre 2013 à 15:40 (CET)
Quid de réorganiser l'article autour d'exemples ?
modifierL'article en l'état est très abstrait et les exemples viennent très tard. Quid de réorganiser ? Fschwarzentruber (discuter) 5 septembre 2022 à 15:04 (CEST)