Rebonsoir champomy62,
UTILISER va jouer le rôle de référentiel de produits, de catalogue pour les sites. Si UTILISER restait une association, vous ne pourriez pas l’associer avec des entités-types telles que SITE, je ne sache pas en effet que DB-MAIN propose le
concept d’agrégation (rien à voir avec celui d’UML) au sens de Smith & Smith (1978), repris notamment par Silberschatz et Korth : autrement dit, UTILISER va devenir une entité-type (que je renomme CATALOGUE pour la circonstance, mais sans doute trouverez-vous un terme plus approprié).
Maintenant, est-il préférable de définir pour CATALOGUE ex nihilo un identifiant supplémentaire qui fasse l’objet d’une clé primaire au niveau relationnel ?
Quelques éléments de réflexion :
Scénario 1. Définissons un nouvel attribut CatalogueId, qui devienne l’identifiant de l’entité-type CATALOGUE. Plaçons-nous au niveau relationnel et supposons que la table SITE soit en relation directe avec la table CATALOGUE, de clé primaire {CatalogueId} (à noter que le triplet {FabricantId, ModeleId, LogicielId} est toujours clé, mais alternative). Si pour un site on a besoin de connaître le nom (ou autre caractéristique) du logiciel il faudra effectuer une jointure de la table SITE avec la table CATALOGUE et la table LOGICIEL (même principe pour les modèles et les fabricants). En outre, la table CATALOGUE étant dotée d’une clé nouvelle, le SGBD créera un index supplémentaire (attention, les ajouts seront plus coûteux, la performance est pénalisée). Si le modèle M1 du fabricant F1 est associé au logiciel L1, et s’il faut remplacer L1 par L2 dans cette association, l’update correspondant n'a pas d'impact sur la table SITE.
Scénario 2. Si on n’a pas défini l’attribut CatalogueId, l’identifiant de l’entité-type CATALOGUE reste le triplet {FabricantId, ModeleId, LogicielId}. Pour récupérer le nom du logiciel, on aura une jointure en moins, puisqu’il suffira de joindre SITE et LOGICIEL. La table CATALOGUE n’étant pas dotée d’une clé nouvelle, le SGBD n’aura pas à créer d’index supplémentaire (on est moins pénalisé en mise à jour). Si le modèle M1 du fabricant F1 est associé au logiciel L1, et s’il faut remplacer L1 par L2 dans cette association, l’update correspondant est à répercuter sur la table SITE : cela reste transparent pour les applications, à condition de prévoir ON UPDATE CASCADE pour la contrainte référentielle établie entre SITE et CATALOGUE. S’il y a peu de modifications de ce genre, du point de vue des performances ça n’est pas un problème. Par contre, si elle sont fréquentes et touchent de nombreux sites, attention.
En gros, avantage au scénario 2, sauf si les modèles sont souvent détricotés des logiciels.
Scénario 1
create table CATALOGUE
(
CatalogueId int not null,
FabricantId int not null,
ModeleId int not null,
LogicielId int not null,
constraint ID_CATALOGUE primary key (CatalogueId),
constraint AK_CATALOGUE unique (FabricantId, ModeleId, LogicielId),
constraint FK_CAT_MOD foreign key (FabricantId, ModeleId)
references MODELE (FabricantId, ModeleId),
constraint FK_CAT_LOG foreign key (FabricantId, LogicielId)
references LOGICIEL (FabricantId, LogicielId)
) ;
Create table SITE
(
SiteId int not null,
SiteNom varchar(32) not null,
CatalogueId int not null,
constraint ID_SITE primary key (SiteId),
constraint FK_SITE_CAT foreign key (CatalogueId)
references CATALOGUE (CatalogueId)
) ;
Scénario 2
create table CATALOGUE
(
FabricantId int not null,
ModeleId int not null,
LogicielId int not null,
constraint ID_CATALOGUE primary key (FabricantId, ModeleId, LogicielId),
constraint FK_CAT_MOD foreign key (FabricantId, ModeleId)
references MODELE (FabricantId, ModeleId),
constraint FK_CAT_LOG foreign key (FabricantId, LogicielId)
references LOGICIEL (FabricantId, LogicielId)
) ;
Create table SITE
(
SiteId int not null,
SiteNom varchar(32) not null,
FabricantId int not null,
ModeleId int not null,
LogicielId int not null,
constraint ID_SITE primary key (SiteId),
constraint FK_SITE_CAT foreign key (FabricantId, ModeleId, LogicielId)
references CATALOGUE (FabricantId, ModeleId, LogicielId)
on update cascade
) ;
Rien n’interdit d’ajouter des attributs à l’association. C’est plutôt le fait d’avoir à définir des associations d’associations qui pousse à la transformation.
clés primaires de tables d'associations reférencées dans une autre table
Répondre avec citation
Envoyé par champomy62
Partager