Bonsoir,
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
catcat
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...)
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
catcat
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.
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
catcat
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.
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
catcat
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).
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
catcat
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.
Partager