Bonjour,
D'une façon générale, les énoncés des règles de gestion permettent d’y voir plus clair dans un projet, mais sont surtout utiles pour présenter celui-ci : ainsi sont-elles sont exigées dans un dossier de conception digne de ce nom, et cela depuis toujours. Il n'en demeure pas moins qu'elles ne sont pas la panacée, car selon le talent du rédacteur elles sont souvent ambiguës, incomplètes, obscures, voire contradictoires : c'est pour cela qu'il est important de les accompagner d'un MCD ou un diagramme de classes, bref d'une représentation dont le formalisme (la grammaire) est reconnu, diagramme qui bien sûr ne résout pas tout non plus, mais est d'une aide particulièrement efficace pour comprendre l'univers du discours et aussi recenser les anomalies.
Votre représentation est donc la bienvenue :
SITE| {1,n}----(contenir)----{1,1} |PRODUIT| {1,1}----(représenter)----{0,n} |MODELE|
N.B. Vous pouvez ôter les accolades, on les réserve pour les ensembles (au sens de la théorie des ensembles). Exemple (traduction en langage D de la représentation graphique) :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| VAR SITE BASE RELATION
{IdSite, NomSite, ...}
KEY {IdSite} ;
VAR MARQUE BASE RELATION
{IdMarque, NomMarque, ...}
KEY {IdMarque} ;
VAR PRODUIT BASE RELATION
{IdSerie, NoSerie, DateFinGarantie, IdSite, IdMarque, ...}
KEY {IdSerie}
KEY {NoSerie}
FOREIGN KEY {IdSite} REFERENCES SITE
FOREIGN KEY {IdMarque} REFERENCES MARQUE ; |
Dans la référence que vous proposez, je lis ceci :
« Lorsqu'autour d'une entité, toutes les associations ont pour cardinalités maximales 1 au centre et n à l'extérieur, cette entité est candidate pour être remplacée par une association branchée à toutes les entités voisines avec des cardinalités identiques 0,n. »
Il y a pas mal de remarques à faire sur la forme. Quant au fond, ce qui est écrit est parfois vrai, parfois faux, il ne faut surtout pas l’appliquer à la lettre. En ce sens je vous cite :
Envoyé par
Elindur
Or, en prenant l'identifiant du modèle, et l'identifiant du site, on n'aboutira pas à un unique produit, puisqu'il peut tout à fait y avoir sur un même site plusieurs modèles identiques mais de numéro de série différents (normal quoi).
Vous venez de montrer que la formulation de l’auteur auquel vous faites référence n'est pas vraie dans tous les cas, et mérite d’être sérieusement corrigée. C’est exactement comme si en logique on écrivait :
Prémisses :
1. Ma voiture est une Renault Clio ;
2. Les établissements Volfoni m’ont vendu ma voiture ;
Conclusion :
3. Volfoni n’aura pu vendre de Renault Clio qu’à un seul client (moi en l’occurrence)...
Moralité : ne prenez pas à la lettre ce qu’écrivent d’aucuns et qui vous choque.
Envoyé par
Kropernic
Pour ma part, la normalisation repose sur les attributs que l'on place dans chaque entité-type et entité-association.
Le tout est de se mettre d’accord sur le sens que l’on donne au mot « normalisation ». La référence que vous citez 
s’appuie sur la théorie relationnelle, mais, par exemple, Merise a sa propre définition (cf. le principal ouvrage de référence sur Merise : « H. Tardieu, A. Rochfeld, R. Colletti. La Méthode MERISE, Tome 1. Principes et outils. (Les Éditions d'organisation. 4ème impression, septembre 1989)) » :
« La normalisation permet de s’assurer que chacune des propriétés ne peut être vérifiée sur un sous-ensemble de la collection de la relation-type »
La normalisation selon l’auteur auquel vous faites référence est en fait un ensemble de conventions souvent utiles, mais à l’occasion trop simples et contestables.
Bref, Elindur, conservez votre schéma initial et ne faites pas confiance les yeux fermés.
Normalisation problématique pour de la gestion de stock
Répondre avec citation
Partager