Discussion :

[high4life]

Bonjours à tous, je suis nouveau sur le forum et j'aurais quelques questions à vous poser à propos de la conception de model de données.

Tous d'abord, voici le sujet sur lequel je travail : Application web pour la gestion des licences Netbackup d'un client.

Pour ce faire, j'ai créé plusieurs tables :
- Machine, qui référence toutes les caractéristiques des machines
- Projet, qui définit le projet sur lequel travail le client
- Licence, qui contient la version de Netbackup correspondant à la licence
- EB (Etude de besoin) et DemandeLicence qui sont fournis par le client
- Sauvegarde, qui contient les infos à sauvegarder par le client

Voici le MCD créé avec PowerAMC :


Le MPD :


J'ai utilisé la génération automatique de PowerAMC pour générer le MPD à partir du MCD.

Je n'ai pas d'erreurs à la génération du MPD, mais, à celle du script de base de données MySQL 5.0.

Et voici les erreurs que j'obtient en générant le script de base:
Vérification des packages en cours...
- Références circulaires
Erreur Certaines tables dépendent d'une autre table par le biais des références suivantes :
-> Chemin n°1 : "Données conceptuelles_1"
- Associé (ASSOCIE2)
- Associé (ASSOCIE)

N'ayant jamais reçu de cours, ni même fait d'exercices sur le sujet, je ne vois pas d'où vient l'erreur.

Est-ce que les cardinalités vous paraissent bonnes ?

Voilà, j'espère avoir été suffisamment explicite,
Thomas

[chewing-gum]

Est-ce que les cardinalités vous paraissent bonnes ?

Ton erreur vient justement d'un problème de cardinalité au niveau de tes deux entités "DemandeLicence" et "EB" (Etudes des besoins).

Tu ne peux pas utiliser les cardinalités 1,1 -- 1,1 des deux côtés, sinon tu créé une sorte d'interdépendance.
Ne sachant pas quelle est la règle de gestion concernant l'étude des besoins et la demande de licence (une étude de besoin concerne 1 seule demande de licence ? ou plusieurs ? Une demande de licence est associée à une étude de besoin ? ou plusieurs ?)
, je te dirais juste de changer l'une des deux cardinalités 1,1 en 0,1 (voire 1,N) pour que cela fonctionne.
Mais bon, il vaut mieux que tu nous dises quelle est ta règle de gestion pour qu'on t'indique le meilleur choix concernant les cardinalités.

[CinePhil]

C'est pas un peu gros des "caractère long" pour la plupart des colonnes ?

LONGBLOB, LONGTEXT : L+4 octets, avec L < 2^32

Une adresse IP, c'est actuellement 15 caractères maxi y compris les points.

Et une clé primaire textuelle n'est pas une bonne clé, a fortiori en LONGTEXT, je ne suis même pas sûr que ce soit possible !

Puisque DemandeLicence est associée à un seul EB et vice-versa, pourquoi ne pas fusionner les deux entités ?
Ce qui génère le message d'erreur est justement cette association pour laquelle PowerAMC a généré une clé étrangère dans chaque entité faisant référence à l'autre, ce qui produit une référence circulaire.
D'une association dans le MCD, tu te retrouves avec deux flèches dans le MLD.

[high4life]

Tout d'abord, merci beaucoup de vos réponses rapides

Oui, une demande de licence est associée à une et une seule EB (étude de besoin). Donc pour cette association vous me conseillez de fusionner ces deux tables en une seule ? (rajouter un champe "EB" dans la table demande licence)

Sinon pour les caractères long, je ne savais pas à quoi correspondent les types suivants de PowerAMC (caractère(%n), caractère long, caractère long(%), caractère long variable(%n), caractère variable, ...).
Je devrais remplacer les caractères long par caractère(%) ??

[JPhi33]

Bonjour,

Oui, une demande de licence est associée à une et une seule EB (étude de besoin). Donc pour cette association vous me conseillez de fusionner ces deux tables en une seule ? (rajouter un champe "EB" dans la table demande licence)

C'est une solution possible.

D'un autre côté, si tu as modélisé 2 entités différentes DemandeLicence et EB, c'est que, probablement, elles ne présentent pas la même sémantique. Donc la question que me vient immédiatement à l'esprit est : une étude de besoin débouche-t-elle systématiquement sur une demande de licence ? Si ce n'est pas le cas, tiens compte de ce qu'a proposé chewing-gum : changer l'un des couples de cardinalités de l'association "Associé" :

[ EB ]--0,1----( Associé )----1,1--[ DemandeLicence ]

Cette modélisation induit les règles :
- Une étude de besoin peut déboucher sur une demande de licence
- Certaines études de besoin n'aboutissent pas à une demande de licence
- Toute demande de licence est issue d'une et une seule étude de besoin

Lors de la génération du MLD, PowerAMC génèrera une clé étrangère dans DemandeLicence mais pas dans EB évitant ainsi la référence circulaire.

[high4life]

Merci, j'ai changé les cardinalités et la génération n'a pas posé de problème.

Par contre, je me pose toujours la question de la taille des caractères (caractère(%), caractère long, ...). J'ai mis caractère(%), qui me donne par défaut caractère(256). Ce qui veut dire que la mémoire retenue pour cette chaîne sera de 256 bits ?

[CinePhil]

Par contre, je me pose toujours la question de la taille des caractères (caractère(%), caractère long, ...). J'ai mis caractère(%), qui me donne par défaut caractère(256). Ce qui veut dire que la mémoire retenue pour cette chaîne sera de 256 bits ?

"caractère(%)" donnera une colonne de type VARCHAR(%) où % est le nombre maximum de caractères de cette chaîne de caractères de longueur variable. Si tu ne peux pas le faire directement dans le MCD, à toi de préciser la taille souhaitée dans le MLD.
Une adresse IP (V4) sera donc de type VARCHAR(15).
La taille maxi d'une chaîne variable est de 255 caractères, auxquels il faut ajouter un octet pour préciser la taille de cette chaîne, d'où le 256 qui signifie qu'un VARCHAR(255) occupera au maximum 256 octets.

[high4life]

Merci à tous

[high4life]

Je me permet de ré-ouvrir ce post car, je suis toujours sur le même projet et j'ai rencontré un nouvel obstacle : le passage de POWER AMC à MYSQL WORKBENCH.
Ne pouvant pas faire de MCD avec MySQL Workbench, j'ai fais directement le MPD. Et c'est là que je sèche, au niveau des cardinalités (ou plutôt des relations entre les tables) que propose Workbench.
Il y a les relations one-to-one et one-to-many en "identifying" relation et en non "identifying" relation.
D'après ce que j'ai lu dans l'aide, une relation "identifying" c'est quand la table enfant ne peut pas être uniquement identifiée par son parent.
Mais pour les relations non "identifying", je me pose la question : c'est quand la table enfant est uniquement identifiée par son parent ??

Efin, j'ai essayé quelque chose :



La structure de la base à changé par rapport à ce que j'avais fait avec POWER AMC (MCD).
J'ai ajouté des tables, changé les relations, ...

Mais j'aimerais bien avoir votre avis là dessus car je n'ai utilisé QUE des relations "identifying", ne sachant pas trop ce que je pouvais faire d'autre.

Pourriez-vous m'expliquer les relations entre les tables svp ?

[JPhi33]

Bonjour high4life,

Effectivement, ce n'est pas évident au premier abord de comprendre la différence entre ces deux types de liens. Elle est pourtant fondamentale et essentielle.

Lien identifiant ("identifying") entre A et B : l'ensemble d'attributs objet du lien est la clé primaire de A et fait partie de la clé primaire de B.

Lien non identifiant ("non identifying") entre A et B : l'ensemble d'attributs objet du lien est la clé primairede A et ne fait pas partie de la clé primaire de B. (= clé étrangère dans B)


Illustration avec ton MCD.

1. L'association contient:

[ EB ]--1,1----(contient)----1,n--[ Sauvegarde ]

donne :

[ EB ]>|- - - - - - - - - -||-[ Sauvegarde ]

C'est un lien non identifiant. La clé primaire de Sauvegarde se retrouve en tant que clé étrangère dans EB mais ne fait pas partie de la clé primaire de EB.


2. L'association "composé" :

[ EB ]--1,n----(composé)----1,n--[ Machine ]

donne :

[ EB ]-||----------|<[ composé ]>|----------||-[ Machine ]

Ce sont deux liens identifiants. La clé primaire de EB se retrouve en tant que partie de la clé primaire de "composé". De la même manière, la clé primaire de Machine se retrouve en tant que partie de la clé primaire de "composé".

En effet, la clé primaire de "composé" est constituée de l'ensemble {EB_ID, Machine_ID} qui sont respectivement les clés primaires de EB et Machine. Donc EB_ID est une partie de la clé de "composé" et Machine_ID en est l'autre partie.

[high4life]

Merci beaucoup pour cette explication, tout me paraît plus claire