Discussion :

[bbsebb]

Bonjour,

j'ai ce cahier des charges :

Un magasin de vidéocassette souhaite s’informatiser.
Lors de la souscription d’un client, un numéro de client lui est attribué.
La location d’une cassette se fait sur un contrat client auquel sont rattachées les cassettes louées.
Les films sont répertoriés dans la base par catégorie.
A chaque cassette correspond un film, et à chaque film peut correspondre plusieurs cassettes.
Les acteurs d’un film ainsi que le ou les rôles qu’ils y tiennent peuvent également être répertoriés.
Donnez le schéma conceptuel

Et j'hésite entre ces deux représentations de la partie en gras. Est-ce qu'il y en a une meilleure que l'autre, ou une fausse ?


Merci d'avance

[escartefigue]

Le contrat a une existence propre : c'est un document signé par les deux parties, sur papier ou électroniquement et dont chaque partie conserve un exemplaire.
Il faut donc le matérialiser sous forme de type d'entité (un rectangle), comme dans votre deuxième schéma.

[bbsebb]

merci, de manière général, toutes ce qui existe de façon matériel doit être une entité ?

[escartefigue]

Si on a besoin d'en connaître les attributs, oui.

[escartefigue]

Une autre façon de voir les choses : dans votre premier modèle, le contrat n'existe qu'au travers de l'association.
Ce faisant, si la cassette disparaît (ex : détruite), le contrat disparaît. Or il y a bien eu un contrat dont il faut garder la trace même après disparition de la cassette

Par contre, dans le deuxième schéma, il faut revoir les cardinalités : une cassette peut être liée successivement à plusieurs contrats (la notion de date doit intervenir dans l'association)

[fsmrel]

de manière général, toutes ce qui existe de façon matériel doit être une entité ?

Pas forcément ! Prenez le cas d’une rate qui a une portée de ratons. Les ratons sont matériels, et la portée est une abstraction, mais la portée pourrait très bien faire l’objet d’une entité-type sans qu’on modélise pour autant les ratons (Escartefigue a bien donné les conditions). Autrement dit, la mise en oeuvre des entités-types est décidée par arbitrage entre la maîtrise d’oeuvre et le concepteur selon les besoins des applications. S’il est décidé que tel raton est utilisé pour telle expérience, alors la mise en oeuvre d’une entité-type RATON devient légitime (voyez à nouveau la réponse d’Escartefigue).

Notez aussi qu’avec Looping on peut déclarer des entités-types qui ne feront pas nécessairement l’objet de tables SQL, cas classique de l’entité-type DATE.

[bbsebb]

Une autre façon de voir les choses : dans votre premier modèle, le contrat n'existe qu'au travers de l'association.
Ce faisant, si la cassette disparaît (ex : détruite), le contrat disparaît. Or il y a bien eu un contrat dont il faut garder la trace même après disparition de la cassette

Par contre, dans le deuxième schéma, il faut revoir les cardinalités : une cassette peut être liée successivement à plusieurs contrats (la notion de date doit intervenir dans l'association)

Merci, j'ai bien compris cette fois.