Discussion :

[seabs]

Bonjour,

J'étudie actuellement la normalisation présentée dans le document de fsmrel "Base de données relationnelles et normalisation".
Je pensais avoir compris la 1ère forme normale définie par Chris Date.
J'ai cherché sur internet pour examiner mon approche et vérifier ma réflexion.
Or, j'ai relevé dans un article de "Jean Luc Perrenoud", la présentation ci-après :

Exemple 1. La définition suivante n'est pas en 1ère forme normale:

Personne (#-personne, nom-prénom, date-naissance, sexe, adresse)
Elle n'est pas en 1ère forme normale parce que les attributs nom-prénom et adresse ne sont pas atomi-
ques. Parlons d'abord du second: une adresse se compose dans la pratique de plusieurs éléments tels
que rue, code postal, localité, pays. On peut bien imaginer des applications simples où elle se réduirait
à une localité (mieux vaut alors changer le nom de l'attribut pour être précis), mais toute gestion
d'adresse sérieuse nous oblige à décomposer cet attribut.
De même pour nom-prénom. Procéder de la sorte fera que certaines lignes de la table contiendront le
prénom suivi du nom et d'autres le nom suivi du prénom, ne permettant pas de trier correctement les
listes de personnes. Sans oublier que certains prénoms sont aussi des noms de famille, ce qui ajoutera
encore à la confusion.
Pour être précis et éviter les ennuis nous recommandons de déstructurer tous les attributs dans la mesure du possible.

Personnellement, je suis, à tort ou raison, en désaccord avec cette définition et pour moi cette relation est bien en première forme normale.

Si je transforme ma table en relation R(#-personne, nom-prenom,date-naissance, sexe, adresse), j'ai bien pour chaque tuple une valeur pour chacun des attributs.

En effet, ma relation sera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#-personne | nom-prenom | date-naissance | sexe | adresse
    1        Nom_1+P       15/12/1936        M     Adresse_1
    2        Nom_2+P       18/03/1956        F     Adresse_1

Certes, je ne retiendrai pas ce schéma pour créer ma table, mais il n'empêche que je réponds bien à la définition de Chris Date.

D'autre part, je pense que le terme atomique n'est plus d'actualité, il est remplacé par unicité.

Pour cet intervenant, pour être en 1ère forme normale, la table doit avoir la présentation ci-après :

Personne (#-personne, nom, prénom, date-naissance, sexe, rue, no, code-localité, nom-localité)

Je ne vois pas en quoi cela modifie la normalisation, sauf qu'il a créé de nouveaux attributs dans le but de mieux répondre aux nécessités de gestion.

Par contre, si relvar devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#-personne | nom-prenom | date-naissance | sexe | adresse
 1           Nom_1+P       15/12/1936        M     Adresse_1
 1           Nom_1+P       15/12/1936        M     Adresse_2
 2           Nom_2+P       18/03/1956        F     Adresse_1

Alors dans cette situation, relvar n'est plus en 1ère forme normale.

Je demande si une âme charitable veut bien m'éclairer et dire si je suis sur la bonne voie. En effet, pour moi, les développements faits par fsmrel me semblaient très explicites, mais mon approche est peut être complètement fausse.
D'avance merci

[fsmrel]

Bonsoir seabs,

Nous ne nous étions pas croisés depuis un an et demi, comment vont les devis, commandes et factures de vos chers clients ?

Pour en venir à cette histoire de 1re forme normale, soit c’est Chris Date qui a raison, soit c’est M. Perrenoud...

En réalité, décomposer une donnée telle que l’adresse répond seulement à un besoin de gestion. Si la base de données doit répondre à une question du genre : « Quelles personnes habitent Avenue Foch à Paris XVIe ? », alors l’adresse est effectivement à décomposer. Si vous vous contentez d’envoyer des réclames pour vos produits, et si les utilisateurs n’ont pas besoin de ce niveau de finesse, vous pouvez encapsuler les données de l'adresse. Disons que l’habitude dans les entreprises (et c’est une très bonne habitude) consiste à se caler sur la norme, avec ses 6 lignes d’adresse, mais ceci n’a évidemment strictement rien à voir avec la 1re forme normale.

Je rappelle ce qu’a écrit Date :

« the notion of atomicity has no absolute meaning »

L’atomicité est un concept tout à fait relatif et comme dit Date, tel physicien en restera au niveau de l’atome, alors que tel autre aura besoin de descendre au niveau du proton, de l’électron, et tel autre s’intéressera aux quarks, etc.

Date poursuit :

« It follows that the notion of absolute atomicity has to be rejected ».

Etc.

Et comme vous l’avez bien noté, c’est le principe d’unicité qui joue, selon lequel à l’intersection de chaque ligne et colonne, il y a exactement une valeur du type applicable, nothing more and nothing less (cf. The Relational Database Dictionary).

M. Perrenoud devra revoir sa copie. Quant à vous, votre approche est la bonne.

Keep up the good job!

[Oishiiii]

Bonjour,

Par contre, si relvar devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#-personne | nom-prenom | date-naissance | sexe | adresse
 1           Nom_1+P       15/12/1936        M     Adresse_1
 1           Nom_1+P       15/12/1936        M     Adresse_2
 2           Nom_2+P       18/03/1956        F     Adresse_1

Alors dans cette situation, relvar n'est plus en 1ère forme normale.

Là je ne suis pas d'accord. Il y a respect de la première forme normale ici aussi.

C'est la notion de répétition de valeur à l'intersection d'une ligne et d'une colonne qui est déterminante en ce qui concerne la 1NF et non pas la "répétition" ou l'éventuelle redondance au niveau des lignes (ou des colonnes).

L'élimination de ces redondances, source notamment d'anomalies de mise à jour, intervient dans la suite du processus de normalisation.
Lisez le début du chapitre sur la deuxième forme normale à ce sujet.

[seabs]

Bonjour,

Effectivement, tu as raison Oishiiii. Pour perdre la 1NF, il faudrait que ma relation devienne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#-personne | nom-prenom | date-naissance | sexe | adresse(AdrId, AdrDen)
 1           Nom_1+P       15/12/1936        M     Adresse(1, "34, rue..."
                                                           2, "45, allée...")
 2           Nom_2+P       18/03/1956        F     Adresse(1, "17 boulevard...")

Merci de me confirmer si mon exemple est exact.

[fsmrel]

Bonjour,

Par contre, si relvar devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#-personne | nom-prenom | date-naissance | sexe | adresse
 1           Nom_1+P       15/12/1936        M     Adresse_1
 1           Nom_1+P       15/12/1936        M     Adresse_2
 2           Nom_2+P       18/03/1956        F     Adresse_1

Alors dans cette situation, relvar n'est plus en 1ère forme normale.

Là je ne suis pas d'accord. Il y a respect de la première forme normale ici aussi.

Je n’avais pas fait attention à cette partie du message (vu l’heure...), mais heureusement, Oishiiii veille !


En complément : j’ai survolé de qu’écrit le Jean-Luc. On trouve notamment ceci :

La définition suivante n’est pas en première forme normale :

Personne (#-personne, nom, prénom, sexe, date-naissance, langue 1, langue 2, langue 3)

Cette définition n’est pas en 1re forme normale parce qu’elle contient une table, la table des langues parlées par ces personnes.

Il est évident que langue 1, langue 2, langue 3 ne sont que des attributs de la relvar Personne, donc la 1NF est respectée. Encore un qui est tombé dans le panneau, à l’image du rédacteur de DB2 Version 9.1 for z/OS, Administration Guide (cf. Le 1er exemple du bêtisier).

Effectivement, tu as raison Oishiiii. Pour perdre la 1NF, il faudrait que ma relation devienne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#-personne | nom-prenom | date-naissance | sexe | adresse(AdrId, AdrDen)
 1           Nom_1+P       15/12/1936        M     Adresse(1, "34, rue..."
                                                           2, "45, allée...")
 2           Nom_2+P       18/03/1956        F     Adresse(1, "17 boulevard...")

Merci de me confirmer si mon exemple est exact.

Voilà un bon exercice pour Oishiiii qui vous parlera des RVA.

[Oishiiii]

Bonjour fsmrel et seabs,

Le sujet des RVA est relativement important et je n'ai pas encore eu le temps de l'étudier autant que je le voudrais, mais je vais essayer de répondre à seabs.

Chaque n-uplet doit posséder exactement une valeur pour chaque attribut de la relation à laquelle il appartient.
Le contenu de cette valeur dépend du type de donnée sur lequel est définit l'attribut.

Pour un attribut quantitéProduit de type Entier les n-uplets prendrons des valeurs comme 1, 89, ou 12, qui font parti de l'ensemble des entiers naturels.

Le fait est que la théorie relationnelle ne dit rien sur les types.
Un SGBDR supporte généralement des types de données basiques et indispensables; les chaînes de caractères, les entiers, les dates, etc; mais il n'est pas limité dans la complexité des types à gérer.
Sans contrevenir à la théorie, un SGBDR pourrait nous proposer des types prenant comme valeur des images, des fichiers audio, des coordonnées géographique et même des relations.

Pour perdre la 1NF, il faudrait que ma relation devienne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#-personne | nom-prenom | date-naissance | sexe | adresse(AdrId, AdrDen)
 1           Nom_1+P       15/12/1936        M     Adresse(1, "34, rue..."
                                                           2, "45, allée...")
 2           Nom_2+P       18/03/1956        F     Adresse(1, "17 boulevard...")

Donc, si on considère que l'attribut adresse est de type Relation, il y a respect de la 1NF.
Il y a bien exactement une valeur à chaque intersection des lignes et des colonnes, même si pour la colonne Adresse cette valeur est de type Relation :



Pour violer la 1NF, il faudrait qu'un n-uplet possède un groupe, une liste, un ensemble de valeur du type sur lequel l'attribut est définit.


Ici il a viol de la 1NF puisque pour Vincent il n'y a pas une seule valeur (de type Relation) pour l'attribut Adresse, mais bien deux.

Pour conclure sur la 1NF, à moins de se retrouver face à ce genre de bizarrerie ou à la présence de NULL (et autres produits d'une logique multivaluée), toute relation est par nature en première forme normale.

Concernant les RVA, elles sont donc légales dans la théorie relationnelles et sont certainement utiles pour présenter les informations aux utilisateurs.
Mais elles semblent difficiles à utiliser en tant que relvar.
Si une valeur de RVA peut à son tour être une RVA, avec par exemple dans la relation Adresse, un attribut LigneAdresse de type Relation, la manipulation semble difficile.

Voilà.
Si j'ai commis des sottises fsmrel n'hésitera pas à me taper sur les doigts mais ça devrait aller pour cette fois.

[fsmrel]

Bonsoir les rois de la 1NF,

si on considère que l'attribut adresse est de type Relation, il y a respect de la 1NF

Attention, si vous relisez l’annexe A.2, vous observerez que l’attribut Adresse n'est pas du type RELATION, mais du type

RELATION {NumAdresse NumAdresse, Adresse Adresse}

RELATION n’est pour sa part qu’un un générateur de type, qui vous sert justement pour définir vos propres types (il est d'ailleurs possible que j’ai aussi un jour ou l’autre abusé de ce raccourci...)

Sinon, ce que vous décrivez est conforme à la lettre et à l’esprit des RVA, voyez les exemples pages 111 (Figure 8-2) et 129 (Figure 8-13) de l’ouvrage que j’ai déjà mentionné (page 112).

Mais ne traumatisez pas outre mesure l’ami seabs qui est quelqu'un de sérieux, qui veut savoir, mais n’en demande certainement pas tant...

[seabs]

Bonjour,

Je vous remercie tous les deux pour vos explications, même si je n'ai pas encore tout compris.
Pour répondre fsmrel, mes clients, commandes, factures vont parfaitement et donnent satisfaction.

Pour ce qui me concerne, il faut bien savoir que mon objectif n'est pas d'aller modéliser les bases de données des banques. L'analyse et la programmation ne sont pas mon premier métier, mais un job venu au moment de ma retraite pour traiter des difficultés de certaines petites entreprises qui ont des soucis dans leur gestion. Elles ont peu de compétences et encore moins de moyens. Je fais donc le social de gestion. (A chacun son humanitaire)

Partant du principe qu'il vaut mieux essayer de faire bien, je me suis intéressé, depuis trois ans, aux bases de données à l'aide des MCD et autres outils. Aujourd'hui, à 68 ans, je pense qu'il est temps que je maîtrise plus amplement la normalisation. Certains membres de ma famille me prennent pour un fou et disent que je ferais mieux de profiter de ma retraite (C'est-à-dire ne rien faire, la seul chose que je ne sais pas faire).

C'est pour cette raison que j'étudie avec beaucoup de soins le tutorial rédigé par fsmrel. Oui, mais les neurones sont un peu endormies, il faut donc plus de temps pour comprendre. De plus, mon anglais étant insuffisant, je n'envisage pas de lire les ouvrages de base de Codd ou de Chris Date. Sachant que pour la théorie des ensembles, etc, je ne suis pas tombé dedans quand j'étais petit.

Revenons à l'essentiel du sujet, ce qui me manque le plus dans tout cela se sont des exercices avec leur correction. En plus, si internet est une source formidable de documentation, il comporte un nombre impressionnant d'inexactitudes. Cette carence, pour des gens qui ne maîtrisent pas le sujet, demande un effort supplémentaire.

Cependant, à partir de ce vous m'avez expliqué, il ressort que si nous passons en SQL, une table est toujours en 1NF. Si ce n'est pas le cas, merci de m'en indiquer les raisons.

Si déjà ce point acquis, je n'aurai pas perdu mon temps. Pour ce qui est de la 2NF, 3NF et BCNF, je pense avoir compris les principes. Maintenant, il faut approfondir axiomes Amstrong, etc.

Si vous pouviez me citer un ou deux ouvrages à acquérir (en français) pour améliorer mes connaissances, je vous remercie par avance.

En tout cas bravo pour le temps que vous consacrez au forum pour traiter les sujets de normalisation, MCD, etc et surtout la patience dont vous faite preuve.

Encore merci

[fsmrel]

Bonsoir seabs,


Nous avons quelques points communs. Nous avons à peu près le même âge et nous n’avons pas pu nous résoudre à une retraite passive. Vous aidez les petites entreprises et je vous en félicite. Pour ma part, ayant un passé informatique de plus de 45 ans, à barouder en France ou à l’étranger, j’ai accumulé les satisfactions (et les claques) et je ne peux qu’essayer de faire profiter les autres de mes connaissances, d’autant plus quand ils veulent progresser, qu’il s'agisse de seabs ou du tout jeune Oishiiii (la valeur n'attend pas le nombre des années...)

La bible de Date, incontournable, An Introduction to Database Systems a été traduite en français sous le titre Introduction aux bases de données (avec quelques erreurs grossières de traduction (ou de typographie ?) du genre confusion entre intégrité d'entité et intégrité référentielle, mais on répare facilement). Le coût de l’ouvrage (la 8e édition) est d’environ 60 euros, mais on doit pouvoir le trouver d’occasion et Oishiiii qui est fort dégourdi pourrait vous aider dans la recherche d’un tel exemplaire. Par exemple, j’en ai aperçu un à 15 euros, il s'agit de la 7e édition et non pas de la 8e, mais bon, tout ce qui nous intéresse s'y trouve (notamment les corrigés des exercices, dont n'existent autrement que la version en anglais, dans un document à part). En français encore, les ouvrages de Georges Gardarin sont excellents. Voir par exemple : http://georges.gardarin.free.fr/Livre%20BD.htm, que je n'ai pas relu, sachant qu'il y traîne peut-être quelques coquilles que j'avais déjà signalées à l'auteur, fin des années quatre-vingts. Concernant Merise, l’ouvrage de Dominique Nanci Ingénierie des systèmes d’information Merise deuxième génération est sans conteste le meilleur. Fouillez sur la Toile pour le trouver... Et n’oubliez surtout pas les écrits de Michel Diviné.

Pour la 1NF, pas de problème, considérez que le débat est académique et que les tables SQL traditionnelles la respectent. Simplement, tout le monde cherche à montrer des situations, des contenus de tables qui la violent, mais 99% des explications et démonstrations sont folkloriques et bonnes pour la poubelle (l'expliquer, voilà encore du grain à moudre pour Oishiiii...)

Quant à la théorie des ensembles, rassurez-vous, les bases minimales sont suffisantes et rapides à acquérir.

Si vous éprouvez des difficultés dans la compréhension de ce que j’ai écrit sur la normalisation ou autre, n’hésitez surtout pas à me le faire savoir.

Relationnellement vôtre,

fsmrel

[seabs]

Bonjour fsmrel,

Je vous remercie pour vos précieux conseils.

J'ai commandé le livre Introduction aux bases de données chez Amazon. Pour progresser, il faut bien investir un minimum.

Il faut également acquérir le vocabulaire et là, je m'aperçois que la mécanique intellectuelle est moins performante qu'à 20 ou 30 ans. Alors, il faut insister.

Au fur et à mesure de mes lectures, j'aurai certainement des explications à obtenir. Le moment venu, je vous demanderai conseil.

Encore merci à tous ceux qui m'ont aidé.

[fsmrel]

Bonjour seabs,

A propos de l'ouvrage Introduction aux bases de données :

Page 613 : Un gros bug que j’ai déjà signalé. On trouve plusieurs fois l’expression « intégrité référentielle », qui doit être systématiquement remplacée par « intégrité d’entité ».

Pages 281 et 614 : « matching » a été traduit par « unifiable », ce qui ne veut rien dire dans le contexte... A partir de la version en anglais « The database must not contain any unmatched foreign key values » je reformulerais les choses à peu près ainsi : Dans la base de données, aucune clé étrangère ne doit contenir de valeur sans correspondance ».

Page 763 : Figure 23.3, 2e relation : remplacer S_SINCE par SP_SINCE.

Page 771 - Au milieu de la page, je pense qu’on peut remplacer « conditions de température et de tension » par « conditions de température et de pression » .

Page 773 - Au milieu de la page, remplacer

« AND d08PDURING » par « AND d08 ∈ DURING »

Page 786 - Même chose, remplacer

« WHERE d04 P DURING » par « WHERE d04 ∈ DURING »

Page 810 : le texte est parfois effacé. A la 4e ligne, il faut lire : « le fournisseur S1 habite à Londres », ... « le fournisseur S1 fournit la pièce P1 ».

Je n’ai pas lu l’ouvrage dans sa totalité (loin s’en faut !), donc il doit traîner ça et là des approximations ou erreurs, mais espérons que celles-ci ne soient pas aussi graves que celle de la page 613. De votre côté, si vous avez le moindre doute quant à la pertinence d’un énoncé ou d’une phrase quelconque, n’hésitez pas à me le faire savoir.

Bonne lecture !

[seabs]

Bonjour,

Je vous remercie pour toutes vos remarques et corrections. Si je trouve des anomalies, je ne manquerai pas de vous en faire part.

Mais avant de corriger les autres, il faut déjà pouvoir comprendre ce qu'ils ont écrit ou démontré. Je dis souvent commençons par le début, cela sera plus facile ensuite.

Pour le moment, j'ai fait la lecture des deux premiers chapitres. J'avais déjà une approche des connaissances développées dans ces 50 premières pages, mais cela permet de travailler le vocabulaire et de remettre les idées en place.

Je vous remercie encore de votre aide et surtout la manière pédagogique dont vous présentez vos interventions.

Il ne reste plus qu'à me mettre au travail

[fsmrel]

Bonsoir seabs,

avant de corriger les autres

Bien sûr, mais je tiens à préciser que si la traduction que vous avez entre les mains est parfois défaillante, l'ouvrage original ne comporte quant à lui que très, très peu de coquilles (inévitables puisqu'il comporte près de 1000 pages...)

En tout cas, n'hésitez pas à signaler tout ce qui vous paraît suspect.

Bon apprentissage !