Bonsoir Éric,
Envoyé par
debutant001
c'est vrai : pourquoi ne pas inclure les deux dans la propriété "adr_s_rue" ?
C’est la bonne option. Plus généralement, l’essentiel est d’être à même de produire les 5 lignes d’adresse à partir des données contenues dans la base de données.
Envoyé par
debutant001
Si j'ai bien compris, voici comment je pense maintenant gérer ces derniers
C’est bon. N’oubliez pas de sous-traiter à PostgreSQL le contrôle des valeurs prises pas le type et la catégorie de téléphone (CREATE TABLE, contrainte CHECK).
Envoyé par
debutant001
concernant le dernier point, ce que vous vouliez me dire initialement c'était qu'il y avait forcément un lien entre "com_i_id" et "use_i_id" du fait que la cardinalité de l'association "Posséder" entre les entités "tUser" et "tCommentaire" est de type :
tUser --(0,1)----(Posséder)----(1,1)--tCommentaire
Qu’il y ait un lien entre "com_i_id" et "use_i_id" (voir plus bas) est une conséquence de la présence dans votre dictionnaire d’attributs artificiels, les identifiants, alors qu’un dictionnaire ne devrait concerner que les attributs naturels, par exemple le nom, le prénom d’un inscrit (attributs dont certains possèdent la propriété d’unicité et sont donc des identifiants naturels, cas par exemple du numéro de téléphone d’un inscrit).
Pour illustrer, par référence au tableau ci-dessous des éléments chimiques (source Wikipedia), lors de la constitution du dictionnaire des données, en plus des attributs naturels qui y figurent, quelle serait l’utilité d’y ajouter d’office un attribut ElementId qui en soit l’identifiant ? Du point de vue de l’information, objectivement aucune, j’ai envie de dire que ça tient du parasitisme. Qu’on le fasse au niveau du MCD, d’accord et c’est même nécessaire, parce qu’on en arrive au stade du traitement informatisé, mais en amont, c'est-à-dire pour l’utilisateur final de votre application (disons la maîtrise d’ouvrage) il n’y a évidemment pas de valeur ajoutée (au contraire...) à lui exposer des attributs artificiels et autres avatars purement techniques.
Ajouter mécaniquement des identifiants artificiels peut avoir des effets secondaires conduisant à une modélisation sujette à correction (si l’on tient compte de ce qu’a écrit Ockham...)
Je m’explique. Si l’on vous suit, au stade du MCD on aura la représentation suivante :
tUser --0,1----(Posséder)----1,1--tCommentaire
J’ai supprimé les parenthèses encadrant les cardinalités, car le métamodèle du MCD merisien ne les prend pas en considération (cf. l’ouvrage de référence La méthode Merise, Tome 1 : Principes et outils de Tardieu, Rochfeld, Colletti) et elles peuvent être cause d’ambiguïté lors de l’utilisation de certains AGL qui leur affectent un rôle particulier (cas de PowerAMC).
Quoi qu’il en soit utilisons les services d’un AGL (ce qui est très fortement recommandé), par exemple DB-MAIN (gratuit, fiable et sérieux).
MCD selon DB-MAIN (outre les identifiants, je n’ai fait figurer que quelques attributs).
Envoyé par
debutant001
Désolé je n'avais pas compris votre remarque. (en fait, c'est la citation de Guillaume d’Ockham qui m'a induit en erreur : j'ai cru qu'il y avait quelque chose d'inutile dans mon entité)
Considérons le MLD déduit par DB-MAIN du MCD précédent.
MLD
Où id’ symbolise la clé étrangère branchant COMMENTAIRE sur USER, et « ref » est synonyme de « clé étrangère ».
Code SQL correspondant :
create table USER
(
UserId int not null,
UserNom varchar(48) not null,
constraint USER_PK primary key (UserId)
);
create table COMMENTAIRE
(
CommentaireId int not null,
UserId int not null,
CommentaireContenu varchar(255) not null,
constraint COMMENTAIRE_PK primary key (CommentaireId),
constraint COMMENTAIRE_AK unique (UserId),
constraint COMMENTAIRE_USER_FK foreign key (UserId)
references USER (UserId) ON DELETE CASCADE
);
{UserId} —> {CommentaireId}
{CommentaireId} —> {UserId}
Considérons maintenant le MLD suivant :
Traduction en SQL :
create table USER
(
UserId int not null,
UserNom varchar(48) not null,
constraint USER_PK primary key (UserId)
);
create table COMMENTAIRE
(
UserId int not null,
CommentaireContenu varchar(255) not null,
constraint COMMENTAIRE_PK primary key (UserId),
constraint COMMENTAIRE_USER_FK foreign key (UserId)
references USER (UserId) ON DELETE CASCADE
);
Cette fois-ci, l’attribut UserId fait l’objet à la fois de la clé primaire de la table COMMENTAIRE et de la clé étrangère référençant la clé primaire {UserId} de la table USER. L’attribut CommentaireId est devenu inessentiel, superflu, donc parasite, ce qui justifie son élimination au nom de la proposition d’Ockham.
Envoyé par
debutant001
vous ne m'avez pas répondu à propos de l'obligation ou non de nommer différemment toutes les associations dans un MCD...
De fait, je n’y avais pas fait attention. Donner un nom pertinent à une association n’est pas un exercice facile. En plus faire en sorte que les noms soient systématiquement différents relève de la haute voltige, exercice fort à la mode à l’époque où les AGL de modélisation des MCD n’existaient pas ou peu (imaginez en plus ce que cela peut représenter si le MCD comporte 500 entités-types et plus...)
Quand il s’agit de présenter un MCD à l’interlocuteur non informaticien, à savoir la maîtrise d’ouvrage qui en général préfère les bandes dessinées aux dossiers de conception austères, souvent obscurs et ambigus, donner un nom sémantiquement pertinent à chaque association est nécessaire. Mais que les noms des associations soient systématiquement différents, ça ne concerne pas cet interlocuteur, il n’est sensible qu’à la signification des associations.
Quand il s’agit de construire un MCD au moyen d’un AGL, si celui-ci exige que les associations aient des noms différents, on doit évidemment s’y conformer (par exemple, un AGL comme PowerAMC permet que les associations aient le même nom dans la partie visible (le diagramme qu’on affiche), mais il l’interdit pour les noms sous le capot, là où ils noms donneront lieu le cas échéant au nom des tables).
Pour ma part, je veille soigneusement au nom des associations qui donneront lieu à des tables (niveau SQL), mais pour les autres, je n’ai pas de temps à perdre, si par exemple le mot « appartenir » est pertinent, je l’utilise, et si c’est plus d’une fois, ça ne me dérange aucunement puisque ces noms d’associations ne feront pas l’objet de tables, elles disparaîtront en fumée (ou feront à la limite partie des noms des clés étrangères).
Répertoire téléphonique
)
Répondre avec citation
) que pour un petit projet avec peu d'utilisateurs, PostgreSQL n'était peut-être pas recommandé (en terme de vitesse) par rapport à MySQL.
Du coup je n'ai pas d'autre choix que d'ajouter un champ "adr_s_complement" en ce cas ?
). Bien faire et laisser dire, le tout est de partir sur la base d’un MCD correct et une fois dans la soute, procéder à des prototypages de performance (pertinence des index, campagnes d’EXPLAINS...)
Partager