Discussion :

[marie_dupuy]

Bonjour,
je dois faire un schéma MCD pour le quel je ne suis pas tout à faire sûr de moi.
Je serais intéressé par votre avis. Je fais cela pour la première fois.

Le site web pour lequel je fais ce schéma est une plateforme pour mettre en relation artistes et entreprise.
il y a des utilisateurs artistes , des utilisateurs entreprise et les entreprises peuvent lancer des appel à projets.
les artistes peuvent postuler à ses appel à projets
les entreprises peuvent aussi like les profils des artistes qui sont ensuite enregistrer dans leur wishlist.

[escartefigue]

Bonsoir,

Pour que les lecteurs puissent vous aider a réaliser le MCD, il faut que vous donniez plus d'explications
Les règles de gestion ne sont pas clairement exprimées, mentionnez les sous la forme suivante : n° de règle + libellé sans équivoque

Par exemple
R01 : un artiste peut être sollicité par zéro à plusieurs compagnies
R02 : une compagnie sollicite un ou plusieurs artistes
R03 : etc...

Il faut ajouter les types (char, varchar, integer...) et les longueurs des attributs

[marie_dupuy]

Bonsoir,

Pour que les lecteurs puissent vous aider a réaliser le MCD, il faut que vous donniez plus d'explications
Les règles de gestion ne sont pas clairement exprimées, mentionnez les sous la forme suivante : n° de règle + libellé sans équivoque

Par exemple
R01 : un artiste peut être sollicité par zéro à plusieurs compagnies
R02 : une compagnie sollicite un ou plusieurs artistes
R03 : etc...

Il faut ajouter les types (char, varchar, integer...) et les longueurs des attributs

Voici ma liste :

• R n°1 : un "project" peut être avoir besoin d'au moins une à plusieurs "skill"
  R n°2 : un "artist peut postuler ("apply") à 0 ou plusieurs "project"
  R n°3: une "compagny" peut liker 0 ou plusieurs artistes.

Je ne sais pas ce que sont les types (char, varchar et integer). Pouvez-vous m'expliquer ?

Concernant les attributs, je me suis un peu renseigné sur le web, je dois donc en mettre sur les entités artistes "artist" et entreprises "compagny" , est ce bien ça ?

Voici ma deuxième version :

[escartefigue]

Voici ma liste :

• R n°1 : un "project" peut être avoir besoin d'au moins une à plusieurs "skill"
  R n°2 : un "artist peut postuler ("apply") à 0 ou plusieurs "project"
  R n°3: une "compagny" peut liker 0 ou plusieurs artistes.

Ces règles sont incomplètes et pas suffisamment claires :
Le mot "peut" indique une relation facultative, soit une cardinalité mini de zéro, ce n'est pas compatible avec "au moins une" (votre règle 1)
Pour une relation simple entre deux Entité-type, il faut au moins deux règles, voire plus s'il existe des contraintes d'intégrité fonctionnelles.
Par exemple pour ARTIST et COMPANY votre schéma est issu des règles suivantes :
Rxx : un artiste peut être liké par zéro à plusieurs compagnies
Ryy : un compagnie peut liker zéro à plusieurs artistes

Je ne sais pas ce que sont les types (char, varchar et integer). Pouvez-vous m'expliquer ?

Selon que les attributs sont des identifiants techniques, des libellés, des montants, des booléens etc... il faut choisir le type adapté
Il faut également définir la longueur, et pour les montants, le nombre de décimales.
Il faut aussi préciser pour chaque attribut, s'il est obligatoire ou non
Utilisez un logiciel de modélisation, il en existe des gratuits à télécharger, ce sera plus facile et ces contrôles seront faits automatiquement.

Il est préférable de ne pas faire d'entité-type "fourre tout", par exemple, un artiste peut habiter successivement à plusieurs adresses, et aussi posséder simultanément plusieurs lieux de résidence
C'est pourquoi il faut modéliser une entité-type "ADRESSE" et établir une relation entre "ARTISTE" et "ADRESSE"
Même raisonnement évidemment pour l'adresse des compagnies

[marie_dupuy]

Ces règles sont incomplètes et pas suffisamment claires :
Le mot "peut" indique une relation facultative, soit une cardinalité mini de zéro, ce n'est pas compatible avec "au moins une" (votre règle 1)
Pour une relation simple entre deux Entité-type, il faut au moins deux règles, voire plus s'il existe des contraintes d'intégrité fonctionnelles.
Par exemple pour ARTIST et COMPANY votre schéma est issu des règles suivantes :
Rxx : un artiste peut être liké par zéro à plusieurs compagnies
Ryy : un compagnie peut liker zéro à plusieurs artistes

Merci beaucoup pour votre aide et vos explications détaillés. Alors en essayant d'être plus claire concernant les relations entre entité-types :

Relation entre PROJECT et SKILL :
Un appel à projet (d'une entreprise) doit au moins avoir besoin d'une à plusieurs compétences.
Une compétence (d'un artiste) doit au moins être demandé par un à plusieurs appels à projet.

Relation entre SKILL et ARTIST :
Un artiste a au moins une à plusieurs compétences.
Une compétence est possédeé par au moins un à plusieurs artistes.

Relation entre PROJECT et ARTIST :
Un artiste peut postuler à zéro ou plusieurs appels à projet.
Un appel à projet peut avoir besoin d'au moins une à plusieurs candidatures d'artiste.

Relation entre COMPANY et ARTIST :
Un compagnie peut liker zéro à plusieurs artistes.
Un artiste peut être liké par zéro à plusieurs compagnies.

[marie_dupuy]

Utilisez un logiciel de modélisation, il en existe des gratuits à télécharger, ce sera plus facile et ces contrôles seront faits automatiquement.

Connaissez-vous un logiciel de modélisation pour mac ?

[escartefigue]

pour mac en particulier non, mais je sais que JMerise comme DBMain sont gratuits sur PC, je suppose donc qu'ils sont également gratuits sur Mac

Pour vos règles c'est beaucoup mieux, un numéro devant chaque règle aurait facilité la discussion : c'est plus facile de dire votre règle n°5 me pose question .... que je ne comprends pas bien la règle qui stipule "bla bla bla bla "

[marie_dupuy]

Il est préférable de ne pas faire d'entité-type "fourre tout", par exemple, un artiste peut habiter successivement à plusieurs adresses, et aussi posséder simultanément plusieurs lieux de résidence
C'est pourquoi il faut modéliser une entité-type "ADRESSE" et établir une relation entre "ARTISTE" et "ADRESSE"
Même raisonnement évidemment pour l'adresse des compagnies

D'accord, je comprend je rajoute donc une entité-type address. Je vous remercie pour votre temps.

Par contre, je ne sais pas trop comment modéliser cela : Tous les champs de l'entité-type address sont obligatoire pour les entreprises.

Mais pour les artistes, ils ne doivent rentrer que city et zip code

Voici la v3 du schéma :

[escartefigue]

Vous avez omis les cardinalités entre "ARTISTES" et "Apply" et entre "ARTISTES" et "GetSkill"

Une question : pourquoi nommez vous vos types d'entité et vos associations en anglais ? travaillez vous pour une entreprise ou des développeurs anglophones ?
Si non, faites simple et utilisez des termes français, de préférence des noms au singulier pour les entité-type et des verbes à l'infinitif (ou participe passé) pour les associations.
Même remarque concernant les attributs, bien sur

[marie_dupuy]

pour mac en particulier non, mais je sais que JMerise comme DBMain sont gratuits sur PC, je suppose donc qu'ils sont également gratuits sur Mac

DBMain fonctionne sur mac, merci beaucoup, je ferais le tutoriel dès demain matin

Pour vos règles c'est beaucoup mieux, un numéro devant chaque règle aurait facilité la discussion : c'est plus facile de dire votre règle n°5 me pose question .... que je ne comprends pas bien la règle qui stipule "bla bla bla bla "

D'accord, je comprend, je vais ajouter les règles pour entité-type adresse.

[marie_dupuy]

Vous avez omis les cardinalités entre "ARTISTES" et "Apply" et entre "ARTISTES" et "GetSkill"

Une question : pourquoi nommez vous vos types d'entité et vos associations en anglais ? travaillez vous pour une entreprise ou des développeurs anglophones ?
Si non, faites simple et utilisez des termes français, de préférence des noms au singulier pour les entité-type et des verbes à l'infinitif (ou participe passé) pour les associations.
Même remarque concernant les attributs, bien sur

Oui, je vais tout mettre en français pour plus de simplicité et préciser les cardinalités manquantes.

[escartefigue]

Puisque vous avez choisi DB-Main, je vous recommande cet excellent tutoriel du non moins excellent FSMRel, que l'on ne croise malheureusement plus guère ces derniers temps sur le forum

https://www.developpez.net/forums/bl...d-accueil-mcd/

[marie_dupuy]

Puisque vous avez choisi DB-Main, je vous recommande cet excellent tutoriel du non moins excellent FSMRel, que l'on ne croise malheureusement plus guère ces derniers temps sur le forum

https://www.developpez.net/forums/bl...d-accueil-mcd/

Je vous remercie, je vais faire ce tuto

[marie_dupuy]

Puisque vous avez choisi DB-Main, je vous recommande cet excellent tutoriel du non moins excellent FSMRel, que l'on ne croise malheureusement plus guère ces derniers temps sur le forum

https://www.developpez.net/forums/bl...d-accueil-mcd/

ça donne ça :

1. Relation entre* PROJECT*et*SKILL :
1.1. Un appel à projet (d'une entreprise) doit au moins*avoir besoin*d'une à plusieurs compétences.
1.2. Une compétence (d'un artiste) doit au moins*être demandé*par zéro à plusieurs appels à projet.

2. Relation entre*SKILL et*ARTIST*:
2.2. Un artiste*a*au moins une à plusieurs compétences.
2.2. Une compétence*est possédé*par au moins zéro à plusieurs artistes.

3. Relation entre*ARTIST et*COMPANY:
4.1. Un compagnie peut*liker zéro à plusieurs artistes.
4.2. Un artiste peut être*liké*par zéro à plusieurs compagnies.

4. Relation entre*COMPANY et*PROJECT:
4.1. Une entreprise peut*crée zéro à plusieurs appel à projets.
4.2. Un appel à projet peut être*créé par une seule entreprise.

5. Relation entre* ARTIST et*CANDIDATURE*:
5.1. Un artiste peut*postuler à zéro ou plusieurs candidatures.
5.2. Une candidature peut être créé par un seul artiste.

6. Relation entre* PROJECT* et*CANDIDATURE*:
6.1. Une candidature est rattaché à un seul appel à projet.
6.2. Un appel à projet peut*avoir zéro à plusieurs candidatures.

[escartefigue]

Bonjour,

Quelques remarques :

• Il ne faut jamais mettre d'identifiant dans les relations du MCD, lorsque vous dériverez le MLD à partir de ce MCD, les tables issues des relations intégreront automatiquement les identifiants issus des ENTITES-TYPE liées
• Vous avez oublié de matérialiser les relations entre "COMPANY" et "PROJECT, entre "ARTIST" et "CANDIDATURE" et entre "CANDIDATURE" et "PROJECT"
• Les identifiants id_artist et id_project ne doivent pas apparaitre dans l'entité-type CANDIDATURE.
  Si vous souhaitez que ces identifiants contribuent à l'identification d'une candidature, il faut utiliser l'identification relative.
  Cf. le mode d'emploi avec DBMAIN ici : https://www.developpez.net/forums/bl...tion-relative/
• il faut ajouter les types et longueur de chaque attribut

Des que vous utiliserez DB-Main, vous vous faciliterez la vie, car certaines erreurs ci-dessus ne seront plus possible

Une question : est-ce que l'attribut "image" de PROJECT sera un chemin d'accès à une image, ou l'image elle même ? si c'est l'image, et qu'il s'agit d'objets volumineux (des bit map par exemple), il peut être préférable de modéliser une entité-type supplémentaire.