Discussion :

[catcat]

Bonjour,

Je me pose une question d'ordre méthodologique.
On m'a appris que la bonne façon de concevoir une base de donnée est de commencer par élaborer un modèle conceptuel (MCD) puis de le dériver en modèle logique (MLD), et ensuite de construire la BDD correspondante.
Je lis d'autre part des discours qui évoquent le processus de normalisation des schémas relationnels.
Ils disent, et là je simplifie certainement beaucoup, que cette normalisation est le gage d'une BDD cohérente. Mais ce travail s'effectue sur des relations, et non pas sur des types d'entité ou des types d'association, donc pas au niveau conceptuel mais au niveau logique.
Alors ce qui me pose question, c'est que dans la démarche, c'est sur le MCD qu'on place toute notre réflexion. Et qu'une fois le MCD terminé, le MLD se déduit presque automatiquement.
A quel moment doit-on alors procéder à la vérification des formes normales 1, 2, 3, 4, FNBC, etc. ?
Doit-on revenir sur la modélisation conceptuelle ensuite ?

Bref, je suis un peu perdue. Y-a-t-il une bonne méthode. Et quelle est-elle alors ?

Merci d'avance de vos avis éclairés et des conseils de lecture.
Catcat

[fsmrel]

Bonsoir,

On m'a appris que la bonne façon de concevoir une base de donnée est de commencer par élaborer un modèle conceptuel (MCD) puis de le dériver en modèle logique (MLD), et ensuite de construire la BDD correspondante.

Ce que l’on vous a appris est exact. J'ajouterai ceci : Le MCD lui-même est élaboré à partir des règles de gestion des données fournies dans le dossier de conception détaillé. A vous de vous assurer — en posant les bonnes questions au chef de projet — que ces règles sont les plus complètes possible, sinon votre travail sera bon pour le pilon. Et n’oubliez pas que de leur côté, les utilisateurs changent d’idées en permanence (ce qui ne réjouit du reste pas le chef de projet, qui a des impératifs calendaires et budgétaires...)

Je lis d'autre part des discours qui évoquent le processus de normalisation des schémas relationnels... 1, 2, 3, 4, FNBC, etc.

Le travail de normalisation 1, 2, 3, 4, FNBC, etc. est incontournable : il s’agit de repérer des maladresses de modélisation à l’origine de redondances pouvant rendre les relations (tables SQL) composant la base de données inconsistantes, et pouvant rendre périlleuses, sinon impossibles les opérations de mise à jour. Cela dit, la normalisation n’est pas la panacée. D’autres redondances ne relevant pas de la normalisation peuvent aussi rendre incohérente la base de données. Prenez par exemple le cas d’une entité-type Facture pour laquelle vous prévoyez un attribut Montant de la facture : une fois la base de données opérationnelle, si le contenu de la base de données n’est pas cohérent, en l’occurrence parce que la valeur du montant est parfois différente de la valeur de la somme des montants figurant dans les lignes de cette facture, la Production informatique en prendra pour son grade et à son tour ne nous ratera pas. Vous demanderez alors (un peu tard) au DBA de mettre en œuvre un trigger ad-hoc, mais ceci est une autre histoire.

A quel moment doit-on alors procéder à la vérification des formes normales 1, 2, 3, 4, FNBC, etc. ?

Évidemment le plus tôt possible. Donc en même temps que l'on construit le MCD.

Doit-on revenir sur la modélisation conceptuelle ensuite ?

Si certaines anomalies ou omissions ne sont détectées que dans le MLD, il est évident qu’il faut répercuter sur le MCD les corrections nécessaires (ce qui du reste n’est pas toujours possible, cas de certaines contraintes d'unicité pour lesquelles une rétroconception échoue).

Y-a-t-il une bonne méthode

J’espère vous avoir confortée quant aux grandes lignes :
S’assurer de la complétude et de la pertinence des règles de gestion des données, puis élaborer le MCD dans les règles de l’art (voyez les ouvrages de Nanci ou de Diviné). S’assurer au niveau du MCD du respect des formes normales, inventées par Ted Codd en 1971-1974 dans le cadre du Modèle Relationnel de Données, mais parfaitement applicables aux entités-types et associations-types des MCD :
En effet, une relation au sens de Codd (une table au sens SQL, une entité-type ou une association-type d’un MCD, une classe OO) fait l’objet d’un prédicat. Prenons par exemple le cas d’un stock de pièces.
Relation coddienne (ayant pour clé PieceId) :

Piece (PieceId, PieceNom, PieceCouleur, PiecePoids, PieceVille)

Le prédicat de cette relation ressemble à quelque chose comme ceci :

La pièce PieceId a pour nom PieceNom, elle a pour couleur PieceCouleur, elle pèse PiecePoids et elle est stockée dans la localité PieceVille.

Une proposition (instance de ce prédicat) est par exemple la suivante :

La pièce 314116 a pour nom boulon, elle est de couleur violette, pèse 20 grammes et est stockée à Montpellier.

Ne pensez-vous pas que ce prédicat et cette proposition valent aussi pour une table SQL, une entité-type, une classe ?

Seul bémol : les associations-types de l’approche E/R posent un problème. Supposons en effet qu’en plus de la relation Piece, la base de données comporte une relation des fournisseurs et une relation (associative) des couples pièces/fournisseurs (clés soulignées) :

Fournisseur (FourId, FourNom, FourVille, ...)
FourPiece (PieceId, FourId, Quantite)

Dans le MCD, FourPiece fait l’objet d’une association-type et par définition les attributs PieceId et FourId n’y figurent pas. A vous de les faire figurer dans le prédicat qui vous servira pour vérifier la normalisation, sinon votre travail sera forcément incomplet.

[catcat]

Bonsoir fsmrel,

Et merci d'avoir pris le temps de faire cette longue réponse.

Évidemment le plus tôt possible. Donc en même temps que l'on construit le MCD.

C'est effectivement ce dont je me doutais.
La démarche demande que le "modélisateur" effectue des allers-retours en nombre suffisant entre les deux niveaux conceptuel et logique.
J'espérais plutôt une réponse dans le genre. Une fois le MCD terminé, on s'attelle au MLD, et donc à tout ce qui a trait au relationnel (normalisation des relations).
Mais hélas non !!!

Si certaines anomalies ou omissions ne sont détectées que dans le MLD, il est évident qu’il faut répercuter sur le MCD les corrections nécessaires (ce qui du reste n’est pas toujours possible, cas de certaines contraintes d'unicité pour lesquelles une rétroconception échoue).

Lorsque vous parlez de rétroconception qui échoue, pensez-vous à un processus automatisé, par ex. avec un AGL ? Le travail "à la main", c'est à dire avec la tête n'est-il pas plus efficace en rétroconception ?

J’espère vous avoir confortée quant aux grandes lignes :

Mmm... Mmoui sur les grandes lignes.

S’assurer de la complétude et de la pertinence des règles de gestion des données, puis élaborer le MCD dans les règles de l’art (voyez les ouvrages de Nanci ou de Diviné).

On est d'accord là-dessus.
Merci des références que vous donnez.
Je n'ai pas encore lu celui de Nanci (commandé hier).
Je n'ai lu que le chapitre 1 concernant le conceptuel, du document de Diviné. C'est un pur régal à lire. Mais je dois assimiler progressivement.
Je continue donc l'assimilation ...

S’assurer au niveau du MCD du respect des formes normales, inventées par Ted Codd en 1971-1974 dans le cadre du Modèle Relationnel de Données, mais parfaitement applicables aux entités-types et associations-types des MCD :
En effet, une relation au sens de Codd (une table au sens SQL, une entité-type ou une association-type d’un MCD, une classe OO) fait l’objet d’un prédicat. Prenons par exemple le cas d’un stock de pièces.
Relation coddienne (ayant pour clé PieceId) :

Piece (PieceId, PieceNom, PieceCouleur, PiecePoids, PieceVille)

Le prédicat de cette relation ressemble à quelque chose comme ceci :

La pièce PieceId a pour nom PieceNom, elle a pour couleur PieceCouleur, elle pèse PiecePoids et elle est stockée dans la localité PieceVille.

Une proposition (instance de ce prédicat) est par exemple la suivante :

La pièce 314116 a pour nom boulon, elle est de couleur violette, pèse 20 grammes et est stockée à Montpellier.

Ne pensez-vous pas que ce prédicat et cette proposition valent aussi pour une table SQL, une entité-type, une classe ?

Oui, je le pense en effet. Le prédicat et la proposition sont tout aussi valables aux deux niveaux.
Mais, si je puis me permettre, les règles de validation sont vraiment différentes selon que l'on se trouve un niveau ou à l'autre.
Je m'explique : Au niveau conceptuel on valide le modèle en fonction de la conformité au règles de gestion issues de l'analyse. Et au niveau logique on le valide en fonction de règles de normalisation formelles et "externes".

Seul bémol : les associations-types de l’approche E/R posent un problème. Supposons en effet qu’en plus de la relation Piece, la base de données comporte une relation des fournisseurs et une relation (associative) des couples pièces/fournisseurs (clés soulignées) :

Fournisseur (FourId, FourNom, FourVille, ...)
FourPiece (PieceId, FourId, Quantite)

Dans le MCD, FourPiece fait l’objet d’une association-type et par définition les attributs PieceId et FourId n’y figurent pas. A vous de les faire figurer dans le prédicat qui vous servira pour vérifier la normalisation, sinon votre travail sera forcément incomplet.

Aie !!! Maintenant je suis perdue.
OK. Dans l'association-type FourPiece, je n'ai pas les propriétés correspondant aux attributs PieceId et FourId.
Pourquoi devrais-je les faire figurer dans le MCD puisque ce n'est pas à ce niveau (conceptuel) que je vais vérifier la normalisation, mais au niveau relationnel ?
Je subodore que quelque chose m'a échappé.
Encore merci pour vos interventions lumineuses. Je suis désolée de me montrer aussi obtuse
catcat

[fsmrel]

Bonsoir,

La démarche demande que le "modélisateur" effectue des allers-retours en nombre suffisant entre les deux niveaux conceptuel et logique.
J'espérais plutôt une réponse dans le genre. Une fois le MCD terminé, on s'attelle au MLD, et donc à tout ce qui a trait au relationnel (normalisation des relations).
Mais hélas non !!!

Si la normalisation représente pour vous un exercice trop délicat (pour le moment), concentrez-vous d’abord sur les règles de gestion des données, mais avant de procéder à la dérivation du MCD en MLD, quitte à vous faire aider par quelqu’un qui connaisse véritablement le sujet, assurez-vous malgré tout soigneusement de cette normalisation, sinon c’est reculer pour mieux sauter.

Variation sur le thème. Que lit-on dans les livres ? Commencer par produire un MCD conforme aux règles de gestion des données, puis une fois celui-ci validé par le chef de projet, l’administrateur de données et autres parties prenantes, procéder à sa dérivation en MLD. La normalisation (au sens relationnel) passe à la trappe. En outre, les spécialistes de l’approche E/R ne connaissant pas le Modèle Relationnel de Données, ils le relèguent au niveau du MPD (Modèle Physique de Données). En vérité, le MPD a à voir avec la tuyauterie, les fichiers qui hébergeront les données, les turbos (les fameux index), tout cela en fonction du SGBD dans son état technologique du moment, avec des DBA impatients de voir enfin mises en œuvre les fonctionnalités permettant d’améliorer définitivement les performances et toutes ces sortes de choses.

Permettez-moi encore une digression... Le MLD relève donc du Modèle Relationnel de Données, lequel est concerné par la logique du premier ordre et l’algèbre, et n’a évidemment rien à voir avec la plomberie. Pour vous en persuader et vous imprégner de l’atmosphère, je vous conseille de jeter un œil sur l’article de Codd "Relational Completeness of Data Bases sublanguages". Malheureusement, autant un auteur comme Michel Diviné excelle dans sa partie, autant ce qu’il écrit dans son chapitre consacré au "MPD" montre qu’il n’a pas lu les bons auteurs et n’a strictement rien compris au Modèle Relationnel de Données, il mélange tout. Je n’en veux pas à Diviné, mais il est assez représentatif ès matière de ses contemporains et de leurs successeurs d'aujourd’hui. Tout ce qu’il a écrit sur la normalisation relève de l’incantation pure et peut être mis à la poubelle.

Pour en venir à la normalisation, celle-ci peut être considérée comme une branche des mathématiques appliquées. Elle est orthogonale au Modèle Relationnel de Données, je veux dire par là qu’elle n’en dépend pas. Certes, il s’agit d’une théorie qui fait l’objet d’un (long) chapitre dans tous les ouvrages traitant des bases de données relationnelles (voire dans des ouvrages traitant de l’approche E/R, mais de façon très incomplète, sinon erronée), simplement parce qu’elle fut inventée par un mathématicien, Ted Codd, père du Modèle Relationnel de Données, dont les travaux furent poursuivis par d’autres mathématiciens tels que Ronald Fagin. Mais cette théorie aurait pu être inventée par un mathématicien qui se serait spécialisé dans l’approche Entité/Relation auquel cas, au plan méthodologique, les auteurs auraient assigné la tâche de normalisation dès la mise en chantier du MCD. Alors, pourquoi ne pas s’y attaquer affectivement au plus tôt ? Si vous attendez que le MLD soit produit pour vous y atteler (vous et le DBA), considérez alors que votre MCD pourra être encadré, mis sous verre et accroché à un mur du bureau, considéré comme une œuvre plastique plus ou moins esthétiquement réussie, mais sans aucune valeur pour la suite des opérations d’un point de vue technique. Maintenant, vous pouvez très bien produire un tel MCD synthétique et esthétique, disons non normalisé, vous permettant de discuter avec votre entourage des données et de leurs règles de gestion, et travailler simultanément sur un second MCD moins synthétique et esthétique, mais qui servira véritablement à la production d’un MLD bien plus pertinent. Je répète ce que j’ai écrit plus haut :
Si l'exercice de normalisation vous perturbe, différez, concentrez-vous sur les règles de gestion des données, mais avant de procéder à la dérivation du MCD en MLD, vérifiez soigneusement la normalisation, en vous faisant aider par quelqu’un qui soit rompu à cet exercice.

J’ai aussi écrit que la théorie de la normalisation ne dépend pas du Modèle Relationnel de Données. En conséquence de quoi, ce Modèle n’interdit en rien que la 2NF et suivantes ne soient pas respectées, ça n’est pas son problème, mais le vôtre, sachant ce qu’il vous en coûtera de ne pas avoir normalisé.

si je puis me permettre, les règles de validation sont vraiment différentes selon que l'on se trouve un niveau ou à l'autre.
Je m'explique : Au niveau conceptuel on valide le modèle en fonction de la conformité au règles de gestion issues de l'analyse. Et au niveau logique on le valide en fonction de règles de normalisation formelles et "externes".

Concernant les règles de normalisation, je vous renvoie à ce que j’ai écrit plus haut. Je suis d’accord que ces règles sont orthogonales aux règles de gestion des données, à savoir que si je ne mets pas tel attribut dans la bonne entité-type (donc en aval dans la bonne table), je pourrais être délinquant selon les règles de la normalisation. Mais, sauf en cas d'incompétence sur le sujet, qu’est-ce qui nous empêche de normaliser au mieux dès la construction du MCD, en même temps que l’on s’applique à traduire correctement les règles de gestion des données ? Je ne vois pas de contre-indication. Et croyez moi, j’ai des heures de vol dans ce genre d’exercice...
Je ne crains pas de dire une fois de plus :
Si le sujet de la normalisation vous fait un peu peur, concentrez-vous d'abord sur les règles de gestion des données, etc.

Une question : Qu’entendez-vous par règles de normalisation "externes" ?

Aie !!! Maintenant je suis perdue.
OK. Dans l'association-type FourPiece, je n'ai pas les propriétés correspondant aux attributs PieceId et FourId.
Pourquoi devrais-je les faire figurer dans le MCD puisque ce n'est pas à ce niveau (conceptuel) que je vais vérifier la normalisation, mais au niveau relationnel ?
Je subodore que quelque chose m'a échappé.

Je n’ai pas dit de faire figurer les attributs PieceId et FourId dans le MCD ailleurs que dans les entités-types FourPiece et Fournisseur.
J’ai suggéré de les faire figurer dans un prédicat, disons sur papier :

La pièce PieceId a été fournie par le fournisseur FourId en quantité Quantite

En donnant quelques exemples de propositions :

La pièce 314116 a été fournie par le fournisseur 007 en quantité 1000
La pièce 314116 a été fournie par le fournisseur 123 en quantité 5000
...

Travail de que vous pourrez faire figurer en annexe du dossier de conception ou autre, accompagné du commentaire suivant :

«Le schéma FourPiece (PieceId, FourId, Quantite) qui fera l’objet d’une table après production du MLD a été vérifié en amont et il est conforme à la cinquième forme normale au sens de Fagin.»

Lorsque vous parlez de rétroconception qui échoue, pensez-vous à un processus automatisé, par ex. avec un AGL ? Le travail "à la main", c'est à dire avec la tête n'est-il pas plus efficace en rétroconception ?

Je pense effectivement à un processus automatisé, en relation avec un MLD conséquent (des centaines de tables, tant qu’à faire). On peut reprendre manuellement certaines parties du modèle que l’outil de rétroconception n’est pas à même de traiter de façon satisfaisante (je pense à certaines contraintes d’unicité issues de clés candidates). Cela dit, les outils font quand même globalement bien les choses et il serait dommage de ne pas en profiter.

[catcat]

Si la normalisation représente pour vous un exercice trop délicat (pour le moment), concentrez-vous d’abord sur les règles de gestion des données,

Oui, c'est vrai que c'est un exercice que je ne maîtrise pas suffisamment, et c'est pour cela que j'en ai un peu peur. Il faut dire que l'énoncé des règles n'est pas un modèle de limpidité.
Mais surtout, je ne savais pas vraiment à quel moment procéder à ce travail de normalisation.
Votre réponse est claire : aussi tôt que possible.

Concernant les règles de normalisation, je vous renvoie à ce que j’ai écrit plus haut. Je suis d’accord que ces règles sont orthogonales aux règles de gestion des données, à savoir que si je ne mets pas tel attribut dans la bonne entité-type (donc en aval dans la bonne table), je pourrais être délinquant selon les règles de la normalisation. Mais, sauf en cas d'incompétence sur le sujet, qu’est-ce qui nous empêche de normaliser au mieux dès la construction du MCD, en même temps que l’on s’applique à traduire correctement les règles de gestion des données ?

Délinquant ? Comme vous y allez !
Plus sérieusement, ce qui me gênait dans le fait de normaliser dès la construction du MCD, c'est que je pensais que c'était un raisonnement qui, par définition, ne pouvait s'appliquer qu'à des relations, et non pas à des entités-type ou à des associations-type.
Mais vous avez raison, ce sont des objets qui sont proches par leur nature.

Une question : Qu’entendez-vous par règles de normalisation "externes" ?

J'essayais d'exprimer cette notion que vous décrivez bien mieux que moi : le fait que les règles de normalisation sont orthogonales aux règles de gestion des données. Et j'ajouterai que si les règles de gestion dépendent du domaine que l'on modélise (on peut dire "internes" à ce domaine), les règles de normalisation proviennent d'un système de lois qui n'en dépendent pas. D'où mon sentiment que ce sont des règles dont la logique est "externe" au domaine.

J’ai suggéré de les faire figurer dans un prédicat, disons sur papier :

La pièce PieceId a été fournie par le fournisseur FourId en quantité Quantite

En donnant quelques exemples de propositions :

La pièce 314116 a été fournie par le fournisseur 007 en quantité 1000
La pièce 314116 a été fournie par le fournisseur 123 en quantité 5000
...

Travail de que vous pourrez faire figurer en annexe du dossier de conception ou autre, accompagné du commentaire suivant :

«Le schéma FourPiece (PieceId, FourId, Quantite) qui fera l’objet d’une table après production du MLD a été vérifié en amont et il est conforme à la cinquième forme normale au sens de Fagin.»

Cette fois-ci je comprends.
Je vais m'appliquer à cette façon de procéder.
Je vais aussi lire les écrits que vous m'avez conseillés. Par petites doses pour l'article de Codd qui n'a pas l'air de se laisser lire comme un roman.

En tous cas merci de votre patiente pédagogie. Vous m'avez ouvert des portes que je compte bien franchir.
catcat

[fsmrel]

Bonjour,

Envoyé par fsmrel
Si la normalisation représente pour vous un exercice trop délicat (pour le moment), concentrez-vous d’abord sur les règles de gestion des données

Oui, c'est vrai que c'est un exercice que je ne maîtrise pas suffisamment, et c'est pour cela que j'en ai un peu peur. Il faut dire que l'énoncé des règles n'est pas un modèle de limpidité.
Mais surtout, je ne savais pas vraiment à quel moment procéder à ce travail de normalisation.
Votre réponse est claire : aussi tôt que possible.

C’est un peu comme lorsque l’on rédige un roman ou un modeste article : à quel moment se préoccuper des règles grammaticales ?

ce qui me gênait dans le fait de normaliser dès la construction du MCD, c'est que je pensais que c'était un raisonnement qui, par définition, ne pouvait s'appliquer qu'à des relations, et non pas à des entités-type ou à des associations-type.
Mais vous avez raison, ce sont des objets qui sont proches par leur nature.

Utiliser la forme prédicative permet de faire abstraction du contexte.

Je vais aussi lire les écrits que vous m'avez conseillés. Par petites doses pour l'article de Codd qui n'a pas l'air de se laisser lire comme un roman.

J’ai attiré votre attention sur l’article de Codd pour que vous compreniez que la logique du premier ordre et l’algèbre relationnelle n’ont guère de rapports avec la tuyauterie et ne méritent vraiment pas d’être pris en compte au niveau du MPD. Cela me rappelle la question posée à la TV par un journaliste à André Frossard : « Maître, quels sont les rapports entre Science et Religion ? » Réponse : « Ce sont les rapports qui existent entre la Compagnie du gaz et Léonard de Vinci. » Il y a de l’orthogonalité dans cette réponse concise... En tout état de cause, ne plongez pas d’emblée dans la lecture de l’article de Codd, sauf bien sûr si vous êtes à l’aise avec la logique et l’algèbre. Si vous voulez découvrir le Modèle Relationnel de Données, la référence incontournable est l’ouvrage de Date (tiré à ce jour à 750 000 exemplaires) : An Introduction to Database Systems.

Bon courage à vous,

fsmrel

[catcat]

Bon courage à vous,

Merci beaucoup. Et à une autre fois peut-être dans ces lieux accueillants.
Catcat