Bonsoir,
A propos de l’identification des entités-types
Je cite Yves Tabourier qui écrit à la page 80 de son remarquable ouvrage (De l’autre côté de MERISE, Les Éditions d’organisation, 1986), ce qui constitue une règle d’or valant pour les identifiants des entités-types florissant dans les MCD merisiens (règle d’or trop souvent méconnue, hélas ! Et comme disent Goethe et Cie, « ceux qui ont oublié le passé sont condamnés à le revivre... ») :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »
Parce qu’il est au niveau conceptuel Merise, Tabourier parle d’identifiants, et ceux-ci ne doivent pas être porteurs d’information mais il suffit ensuite, au niveau SQL, de transcrire identifiant par clé, la règle reste valable, sinon plus ! En passant, on notera qu’une clé primaire n’accepte pas d’être polluée par le bonhomme Null, pour des raisons évidentes.
Après avoir passé plus de 45 ans à mettre en oeuvre, audité, réparé des wagons de bases de données, je confirme que Tabourier a totalement raison : j’ai vu des applications opérationnelles partir à la poubelle ne serait-ce que pour l’emploi d’identifiants significatifs. En passant, je vous renvoie à une histoire vécue, où les concepteurs ont compris le message et revu sagement leur MCD.
Vous me direz qu’un numéro de commande ou de facture ça ne change pas, mais quid si le législateur se mêlait de normer et nous imposer les choses ?
Pour ma part, je modélise l’entité-type COMMANDE en la dotant d’un identifiant non porteur d’information et donc invariant. Le numéro de commande fait alors l’objet d’un identifiant alternatif, point d’entrée dans le système, respectant la contrainte d’unicité des numéros de commande, et au stade SQL localisé dans la seule table COMMANDE, tandis que l’identifiant non porteur d’information donne lieu à la clé primaire de la table et peut se retrouver en tant que clé étrangère (foreign key) dans d’autres tables (CONCERNER par exemple).
Je verrais donc plutôt votre base de données ainsi :
CREATE TABLE CLIENT
(
CliId INTEGER NOT NULL
, Numcl INTEGER NOT NULL
, ...
, CONSTRAINT CLIENT_PK PRIMARY KEY (CliId)
, CONSTRAINT CLIENT_AK UNIQUE (Numcl)
) ;
CREATE TABLE ARTICLE
(
ArtId INTEGER NOT NULL
, Codeart INTEGER NOT NULL
, ...
, CONSTRAINT ARTICLE_PK PRIMARY KEY (ArtId)
, CONSTRAINT ARTICLE_AK UNIQUE (Codeart)
) ;
CREATE TABLE COMMANDE
(
ComId INTEGER NOT NULL
, Numcom INTEGER NOT NULL
, Datecom DATE NOT NULL
, CliId INTEGER NOT NULL
, CONSTRAINT COMMANDE_PK PRIMARY KEY (ComId)
, CONSTRAINT COMMANDE_AK UNIQUE (Numcom)
, CONSTRAINT COMMANDE_CLIENT_FK FOREIGN KEY (CliId)
REFERENCES CLIENT
) ;
CREATE TABLE CONTENIR
(
ComId INTEGER NOT NULL
, ArtId INTEGER NOT NULL
, Qtecom INTEGER NOT NULL
, CONSTRAINT CONTENIR_PK PRIMARY KEY (ComId, ArtId)
, CONSTRAINT CONTENIR_COMMANDE_FK FOREIGN KEY (ComId)
REFERENCES COMMANDE
ON DELETE CASCADE
, CONSTRAINT CONTENIR_ARTICLE_FK FOREIGN KEY (ArtId)
REFERENCES ARTICLE
) ;
Envoyé par
jrmpp
je ne comprends pas très bien le sens de cette relation (COMMANDE 1,n --- contenir --- (1,1) LIGNE_CDE 1,1 --- concerner --- 0,n ARTICLE)
Vous avez produit la table CONCERNER (renommée en LIGNE_CDE) par dérivation de l’association CONCERNER, ce qui est bien entendu tout à fait correct.
De son côté, l’ami escartefigue a considéré que la ligne de commande était une propriété multivaluée de la commande, d’où la mise en oeuvre d’une entité-type faible (weak entity type) LIGNE_CDE. Dans cette approche, il est d’usage en Merise d’identifier l’entité-type faible relativement à l’entité-type forte (regular entity type) : il y a effectivement plus d’une façon de modéliser les lignes de commande, mais en l’occurrence la vôtre est la plus naturelle.
Cela dit, reste le lettrage, c’est-à-dire rapprocher les lignes de facture et les lignes de commande, mais en prouvant que l’on ne pourra pas rapprocher les lignes de commande d’un client avec les lignes de facture d’un autre client, et cette fois-ci l’identification relative à CLIENT rendra bien service...
A suivre.
MCD gestion de la vente de moto verification des relation et cardinalité
Répondre avec citation
Partager