Discussion :

[dancom5]

Bonjour.

Si quelqu'un peut me dire si c'est correcte mon MCD
en fonction de mes règles.

REGLE à la base:
La photo est liée forcément dans un album.
L'album est lié forcément dans une catégorie.

MCD:
photos 1,1 contenir 0,n albums
Une photo est forcément dans un album mais un seul.
L'album peut contenir aucune photo ou plusieurs.

albums 1,1 contenir 0,n categories
Un album est forcément dans 1 catégorie mais une seule.
Une catégorie peut contenir aucun album ou plusieurs.

Pour donner ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
categories 
  |___ album1
          |___photo1
  |___ album2
  |___ album3
          |___photo2
          |___photo3
          |___photo4

[escartefigue]

Bonjour

Oui vos cardinalités sont bien conformes à vos règles

Juste une remarque : vos 2 relations ont le même nom, "contenir", ici pas de souci puisqu'elles ne deviendront pas des tables (cardinalité max 1 d'un coté), mais si toutefois les cardinalités changeaient, il faudrait alors soit mettre des noms distincts, soit intervenir manuellement après dérivation du MLD pour éviter les homonymes.

[dancom5]

Pour commencer, merci pour l'évaluation escartefigue. Je trouve très pertinent et ça va me faire avancer. J'apprécie. 1+

Si je comprends bien, les verbes peuvent devenir des tables. Donc, les verbes doivent porter un nom parlant afin de connaître la signification de la table lorsqu'il est consulté ou s'il y a des requêtes dessus.

Un album CONTIENT des photos.
Une catégorie CONTIENT des albums.

Mais, si dans un cas le mot contient deviendrait une tables, il faudra choisir un autre verbe.

Je ne me rappelle pas d'avoir vu des tables qui sont des verbes dans des scripts comme les CMS ou autres.

Je ne sais pas s'il y aurait une alternatives aux verbes?

[escartefigue]

Si je comprends bien, les verbes peuvent devenir des tables. Donc, les verbes doivent porter un nom parlant afin de connaître la signification de la table lorsqu'il est consulté ou s'il y a des requêtes dessus.

Lors de la dérivation du MLD depuis le MCD
- par défaut, toutes les entités-type deviennent des tables (mais on peut demander dans certains cas de ne pas générer de table)
- certaines relations deviennent des tables : toutes celles dont toutes les pattes ont une cardinalité maxi à n

Je ne me rappelle pas d'avoir vu des tables qui sont des verbes dans des scripts comme les CMS ou autres.
Je ne sais pas s'il y aurait une alternatives aux verbes?

L'utilisation de verbes pour les relations dans le MCD est une préconisation mais pas une obligation
S'il s'agit d'une base de données privée, vous pouvez utiliser les noms comme bon vous semble et conserver les noms du MCD dans le MLD puis MPD
Par contre, s'il s'agit d'une base d'un projet d'entreprise, vous avez le plus souvent des règles de codification des objets à respecter, du coup les noms des tables, index et autres objets n'ont éventuellement plus rien à voir avec les noms du MCD.

[dancom5]

...vous avez le plus souvent des règles de codification des objets à respecter, du coup les noms des tables, index et autres objets n'ont éventuellement plus rien à voir avec les noms du MCD.

En fonction de mon exemple MCD, ça pourrait quoi les noms que je pourrait utiliser?

emplacer CONTENIR par quoi?

Je pourrais remplacer ces verbes par ces noms?

PS, j'aime bien vos réponses.

[escartefigue]

Et bien ça dépend de la norme de codification des objets dans l'entreprise

Exemple de codif (très proche de cas réel rencontré en entreprise) :
- tous les objets codés sur 7 caractères, 8 pour les vues et index
- 1 er caractère = type d'objet (T=Table, V=Vue, I=Index etc...)
- 2ème caractère = code brique applicative
- 3ème caractère = code quartier applicatif
- 4 à 7 = libre
- 8 = n° de version (vues, index)


Soit l'urbanisme suivant
Codes briques
A=Comptabilité
B=Gestion du personnel
C=Production
etc...


Codes quartiers
Pour la compta
A=compta analytique
C=compta client
F=compta fournisseurs
G=compta géné

Pour la gestion du personnel
C=gestion des carrières
P=paye
etc...

On peut imaginer les objets suivants
TACCNT1 table brique compta, quartier compta client, usage contentieux
TAGPLAN table brique compta, quartier compta générale, usage plan comptable
VBPCOTP2 vue brique gestion du personnel, quartier paye, usage cotisations patronales, version 2
IAGPLANP index primaire de la table TAGPLAN
IAGPLAN0 autre index de la table TAGPLAN
etc...
Avec un peu d'habitude, ce type de nomenclature permet d'avoir des noms concis et de reconnaitre facilement où se situent les objets dans le parc applicatif.

[dancom5]

Et bien ça dépend de la norme de codification des objets dans l'entreprise...

Je comprends beaucoup mieux maintenant avec ce poste.

Les noms de l'association, on peut y mettre une convention que l'entreprise établi pour s'y retrouver dans sa base de données.
A condition que de faire une sorte de légende pour savoir lire les noms de ces tables.

Merci pour votre aide escartefigue.

Je marque résolu mais si j'ai des questions liés à ce poste, je vais les écrire ici
plutôt que de faire un autre poste sur le même sujet si c'est permis de le faire.

[dancom5]

Bonjour Webmestres.

C'est pour noter cette discussion. Je croyais qu'il était possible de modifier la réponse pour noter la discussion.
J'aurais une suggestion qui serait d'ajouter la notation lors d'une modification à cause des oublis de le faire.

Suggestion aussi: Peut-être ajouter le bouton Résolu quand on édit pour ne pas oublier d'indiquer Résolu et que
ça se fasse en une seule étape.

J'en profite pour dire merci pour vos interventions.

[dancom5]

J'ai trouvé un document PDF qui explique toutes mes interrogations au sujet du MCD
qui me permet de mieux cerner le sujet.
http://www.ai.univ-paris8.fr/~lysop/bd/seance2-ModeleEA.pdf

[escartefigue]

Oui ce doc semble pas mal

Notez qu'il existe d'autres outils de modélisation que ceux mentionnés, et notamment DBMain et JMerise parmi les gratuits

Par contre il y a une boulette en page 12, les cardinalités mises entre parenthèses ne concernent que l'identification relative : l'entité-type faible hérite de l'identifiant de l'entité-type forte, identifiant sans lequel l'identification n'a pas de sens. Cas typique, le n° de ligne de facture qui a besoin du n° de facture associé.
Les parenthèses sont du coté de l'entité-type faible

[dancom5]

Bonjour escartefigue et merci de vous être donné la peine de lire la doc.

Il me semble que j'aurais plutôt mis : 1,n et 1,1 sans les parenthèses.

Un client possède un à plusieurs compte bancaire mais, un compte appartient à un seul client.

Pourquoi les parenthèses et que ça veut dire?

Un autre point qui me chicotte:

Un client peut ne pas posséder un compte bancaire et peut en posséder 1 à plusieurs.
Le compte peut ne pas être posséder par un client comme il peut être posséder par 1 à plusieurs clients (compte conjoint).

[escartefigue]

Bonjour escartefigue et merci de vous être donné la peine de lire la doc.
Il me semble que j'aurais plutôt mis : 1,n et 1,1 sans les parenthèses.

De rien, je ne l'ai que parcouru rapidement et 12 pages ca va vite
En effet, il suffit d'ôter les parenthèses pour que le schéma soit correct

Pourquoi les parenthèses et que ça veut dire?

Comme j'essayai de l'expliquer précédemment, mais visiblement je n'étais pas suffisamment clair, les parenthèses autour des cardinalités sont utilisées pour caractériser une identification relative.
Prenons l'exemple d'un modèle de donnée facture, ligne facture avec les règles de gestion :
- 1 facture possède au moins une ligne
- 1 ligne appartient à une et une seule facture
- 1 ligne concerne 1 et un seul article

Ce qui peut se traduire par le MCD suivant :
FACTURE 1,n --- posséder --- 1,1 LIGNE
dans ce cas les tables résultantes seront
FACTURE (FAC_id integer PK, FAC_NUM char(10), FAC_DATE date, etc...)
LIGNEFAC (LIG_id integer PK, FAC_id integer FK references FACTURE(FAC_id), ART_ID integer FK references ARTICLE(ART_ID), LIG_QTE decimal(9,3), etc...)
La table ligne facture possède un identifiant propre, complètement indépendant de celui de la table facture, et a pour foreign key l'identifiant de la facture (FAC_ID) et aussi la FK vers la table article.


Une autre traduction MCD est la suivante :
FACTURE 1,n --- posséder --- (1,1) LIGNE
en ce cas, les tables résultantes sont
FACTURE (FAC_id integer PK, FAC_NUM char(10), FAC_DATE date, etc...)
LIGNEFAC (FAC_id integer PK references FACTURE(FAC_id), LIG_id integer PK, ART_ID integer FK references ARTICLE(ART_ID), LIG_QTE decimal(9,3), etc...)
Ici, la PK de la table facture est composée de l'identifiant facture + l'identifiant ligne
L'identification relative présente plusieurs avantages, si vous voulez en savoir plus, je vous recommande cet sujet commenté par l'excellent Fsmrel
http://www.developpez.net/forums/d33...fiant-relatif/

Un autre point qui me chicotte:

Un client peut ne pas posséder un compte bancaire et peut en posséder 1 à plusieurs.
Le compte peut ne pas être posséder par un client comme il peut être posséder par 1 à plusieurs clients (compte conjoint).

Pour la première assertion, si l'on est dans le domaine bancaire, il est fort possible qu'un client ne soit connu qu'à partir du moment où il possède un compte, en tout cas ce n'est pas aberrant de modéliser ainsi, tout dépend des règles de gestion fournies et validées par les experts du métier.
Concernant la deuxième assertion, je ne pense pas qu'un compte bancaire puisse n'appartenir à aucun client. par contre un compte peut avoir des co-titulaires (ex : compte joint)