Discussion :

[dancom5]

Salut à tous et à toutes.

J'ai lu des tutoriels sur Workbench et la conception de shema mais je n'arrive pas à me mettre en tête l'ordre de lecture des cardinalités.

J'ai fais ce shema de base:

CLIENT 1 --- possède--- 1.* OEUVRES

Et je me demande si c'est comme ceci que je dois lire pour bien construire mon shema:

Je dit client qui possède 1 ou plusieurs oeuvre (1.*)
et une oeuvre est posséder par un seul client (1.1)

En partant de CLIENT à 1.* pour lire et à l'inverse de OEUVRE à 1. C'est correcte?

Voir mon image:



J'ai tendance à lire à partir de l'entité CLIENT et interpréter 1.*
et de l'entité OEUVRE et interpréter 1

J'apprécierai une aide pour me vulgariser cela puisque je suis dedans présentement pour créer ma base de donnée.

[fsmrel]

Bonsoir dancom5,


Avez-vous lu cet article ?

[dancom5]

Tiens, si quelqu'un peut me confirmer ma façon d'interpréter le shema.

J'ai rien vu dans le tutoriel sur le sens de lecture d'un shema.

Entre CLIENTS et oeuvres, J'ai oublié de mettre le verbe POSSÉDER

Voici mon image corrigée:

[fsmrel]

Allons-y pour le verbe « Posséder », mais l’énoncé de la règle corespondant à « 1..* » n’est pas :

Un client peut posséder une ou plusieurs œuvres ;

Mais

Un client possède au moins une œuvre et au plus plusieurs.

Sinon, selon votre énoncé, « 1..* » doit être remplacé par « 0..* »

[dancom5]

1..* au moins une oeuvre
0..* entre rien ou plusieurs oeuvres

donc l'étape serait :

La table CLIENT
ensuite, le verbe
et après la cardinalité 1..*

Merci pour l'info.

[fsmrel]

J'ai rien vu dans le tutoriel sur le sens de lecture d'un schéma.

Voyez par exemple le paragraphe 5, Associations de un à plusieurs.


En tout cas, Je vous engage à utiliser la notation UML pour les associations :






Car cette fois-ci, la lecture est sans conteste :

—Un client est associé à au moins une œuvre et au plus plusieurs ;

— Une oeuvre est associée à au moins et au plus un client.

En effet, la notation que vous utilisez est la notation « Classic » et là il peut y avoir ambiguïté.

Dans son article fondateur The Entity-Relationship Model - Toward a Unified View of Data, Peter Chen père du modèle Entité-Relation symbolise les associations par un losange (voyez à la page 11 de l’article) :




Et la notation « Classic » de MySQL Workbench est bien « chennienne ».

Le problème qui se pose est lié à l’utilisation de la version française de l’approche Entité-Relation, selon laquelle l’entité-type CLIENT participe de 1 à N fois à l’association POSSEDER, et l’entité-type OEUVRE y participe au moins et au plus une fois, ce qui conduit à permuter l’emplacement des cardinalités :




Cette participation d’une entité-type à une association est quelque chose de subtil, mais ça fait pratiquement 40 ans qu’il en est ainsi...


=> Pour ne pas avoir à douter, on peut éviter les notations avec lesquelles les associations sont symbolisées par des losanges et des ovales, allons-y pour la notation UML :

[dancom5]

j'ai un peu de misère à cerner la notion: Non-Identifying Relationship ET Identifying Relationship
dans le concret.

Dans le tuto:
«La patte entre DEPOT et REGION est en pointillés : c'est la façon qu'a l'outil de signaler que DEPOT n'est pas une propriété (multivaluée) de REGION. DEPOT et REGION sont bien des types d'entités fortes, indépendantes (kernels) au sens de Codd, et DEPOT se contente de désigner REGION.»

Dans mon cas, client et oeuvres c'est une antitié Identifying Relationship?

Pourquoi?

[fsmrel]

j'ai un peu de misère à cerner la notion: Non-Identifying Relationship ET Identifying Relationship dans le concret.

Dans mon cas, client et oeuvres c'est une antitié Identifying Relationship?

Bonne question, pour laquelle il n’y a pas de réponse péremptoire...

On utilise volontiers l’identification relative (identifying relationship) quand une entité-type n’a de sens que relativement à une autre entité-type. Par exemple, si FACTURE et LIGNE_FACTURE sont deux entités-types, la 2e n’a de sens que par rapport à la 1ere, une ligne de facture sans facture ça ne veut rien dire. Par ailleurs, quand on supprime une facture, les lignes de facture n’ont pas leur mot à dire, elles disparaissent avec leur « maman » (clause ON DELETE CASCADE de SQL). Incidemment, si vous avez pratiqué UML, on a une relation de composition entre FACTURE et LIGNE_FACTURE.


Vous me direz qu’à son tour, une facture sans client ça n’a pas de sens non plus. Mais pour autant utilisera-t-on automatiquement l’identification relative ? J’aurais tendance à répondre affirmativement, mais je ne suis pas choqué quand je vois des modèles où FACTURE n’est pas identifiée relativement à CLIENT, le facteur psychologique est alors partie prenante... En passant, FACTURE est une entité-type forte, car elle est en droit — et elle a même le devoir ! — d’émettre un veto lors d’une tentative de suppression du client concerné (clause ON DELETE NO ACTION ou RESTRICT).

Dans ce genre de situation, j’utilise l’identification relative pour résoudre par exemple les problèmes de chemin (contraintes de chemin), comme dans le cas de la discussion avec champomy62, que je vous incite à éplucher.

Dans votre cas, si la disparition d’un client entraîne celle des œuvres qu’il possède, OEUVRE est une entité-type faible (weak entity type de Chen) et vous pouvez l’identifier relativement à CLIENT (et surtout, coder ON DELETE CASCADE). Si ses œuvres s’opposent à la suppression d’un client (ON DELETE NO ACTION ou RESTRICT), vous avez le choix entre l’identification absolue et l’identification relative, mais là encore c’est surtout une réflexion en rapport avec les contraintes de chemin qui vous pousseront à pencher vers l’identification relative.


En passant, n’oubliez pas de voter pour telle et telle réponses qui auront pu vous éclairer...

[dancom5]

Merci pour l'aide.

Je vais aller voir si je trouverais une vidéo sur le sujet.

Si je supprime le CLIENT, je supprime aussi les oeuvres, ça c'est clair mais pas nécessairement l'inverse puisqu'un client peut avoir d'autres oeuvres. C'est relation identifiée.