Discussion :

[shimomura22]

Bonjour
Voici mon problème; j'ai plusieurs entités différentes et chacune d'entre elle possède une adresse.
Mon souci est que j'aimerais créer une entité de type association possédant les attributs des différentes adresses.
Mais je me pose la question de savoir si il n'est pas plus facile de mettre directement l'attribut adresse dans chacune de mes entités.
Voici mon MCD



Merci d'avance
PS: mes cardinalités sont de 1-1 que je corrigerais plus tard

[CinePhil]

j'ai plusieurs entités différentes et chacune d'entre elle possède une adresse.

D'après votre schéma, adresse est une association quaternaire entre les 4 "ENTITYs", ce qui entraînera la création d'une table associative dont la clé primaire sera composée des clés étrangères référençant chacune des 4 entitys.

J'ai plutôt l'impression qu'il vous faudrait 4 associations :
entity -1,1----posséder----0,n- adresse
entity_1 -1,1----posséder----0,n---|

À vous de déterminer les cardinalités qui vont bien.

Si vous nous dites plus concrètement ce qui se cache derrière ces "entitys", nous pourrons mieux vous aider à modéliser correctement votre système.

[shimomura22]

Merci pour ton post
Pour mes entités il s'agit d'un garage, de ses franchises, de ses clients et de ses fournisseurs.
Chacune d'entre elles possèdent une adresse donc je pensais en faire une association de type quaternaire ou alors garder l'attribut adresse dans chaque entité.
Je voulais savoir la démarche la plus efficace à effectuer face à ce cas précis


Merci

[CinePhil]

Et bien écrivons d'abord les règles de gestion et le MCD viendra tout seul.

Un garage est situé à une adresse et une adresse peut situer un garage. Ça m'étonnerait qu'il y ait plusieurs garages à la même adresse.
Une franchise est située à une adresse et une adresse peut situer une franchise. Idem.
Un fourniseur est situé à une adresse et une adresse peut situer plusieurs fournisseurs. On pourrait même dire qu'un forunisseur peut avoir plusieurs adresses (physique, de facturation...).
Un client est situé à une adresse et une adresse peut situer plusieurs clients. Idem que les fournisseurs.
Une adresse est située dans une localité et une localité peut situer plusieurs adresses.
Une localité est située dans un pays et un pays peut situer plusieurs localités.

MCD :
garage -1,1----situer----0,1- adresse -1,1----situer----0,n- ville -1,1----situer----0,n- pays
franchise -1,1----situer----0,1----|
fournisseur -1,1----situer----0,n--|
client -1,1----situer----0,n----------|

Ce qui donne les tables suivantes...
te_pays_pay (pay_id, pay_code, pay_nom...)
te_localite_loc (loc_id, loc_id_pays, loc_nom...)
te_adresse_adr (adr_id, adr_id_localite, adr_rue, adr_code_postal...)
te_garage_gar (gar_id, gar_id_adresse, gar_nom...)
te_franchise_fch (fch_id, fch_id_adresse, fch_nom...)
te_fournisseur_frn (frn_id, frn_id_adresse, frn_nom...)
te_client_clt (clt_id, cld_id_adresse, clt_nom...)

Demande toi aussi si une franchise n'est pas elle-même un garage, si un fournisseur ne peut pas être aussi un client et sont en fait deux sociétés...

[fsmrel]

Bonsoir,


Un autre scénario possible...

Si vous traitez des relations du seul garage Naudin avec les autres entités, le MCD suivant correspond à la généralisation de ces dernières :

On met dans le pot commun (surtype) ENTITE les propriétés partagées par ces entités, et les propriétés non partagées sont représentées dans les sous-types correspondants :




Si une entité-type peut être caractérisée par plus d’une adresse, on met en œuvre une entité-type (faible) en conséquence :





Si vous avez à gérer plusieurs garages, il faudra ajouter GARAGE en temps que sous-type d’ENTITE et faire figurer ses relations avec les autres sous-types.

[SQLpro]

C'est ce que je propose dans cet exemple depuis des lustres...
http://blog.developpez.com/exercices...n_de_personnes
http://blog.developpez.com/exercices..._d_une_adresse

Vous auriez pu chercher un peu !

A +

[shimomura22]

Merci beaucoup pour vos éclaircissement pour mon problème ma solution irait plus vers le schéma proposé par fsmrel.
Pourrais tu juste me dire quel est le logiciel que tu as utilisé pour modéliser ton exemple car avec le mien je n'arrive pas à modéliser l’héritage correctement.
Merci

[fsmrel]

Bonsoir,


J’ai utilisé l'excellent DB-MAIN de Jean-Luc Hainaut (version 9.2b).


Supposons que je crée une nouvelle entité-type ENTITY, devant être sous-type de CLIENT.

J’ouvre la « Property box » de ENTITY, et clique sur le bouton orné de 3 petits points, correspondant à la case « supertypes ». Cela provoque l’ouverture de la fenêtre « Multiple choice dialog », j’y sélectionne CLIENT et fais « Add first ».



Et l'héritage se produira quand j'aurais fait « OK » et cliqué dans le plan de travail.

Sommes-nous en phase ?

[shimomura22]

Merci c'est aussi celui que j'utilise mais je ne savais pas comment le faire
Je vous remercie tous pour vos infos
Bonne journée

[shimomura22]

Bonsoir à tous
Ayant un peu potassé le sujet, j'aurai encore quelques questions à poser.

1. J'aimerai savoir si il s'agit bien d'une spécialisation c'est à dire que L’entité sous-type (client,franchise,fournisseur) hérite de toutes les propriétés de l’entité sur-type (adresse) y compris de son identifiant ce qui explique le fait de ne pas avoir de Id dans les entités sous-type?

2. Si il est possible d'avoir les 2 types d'héritages ( spécialisation et généralisation ) dans un seul schéma?

2.1 Si une entité peut faire partie d'une part dans une association d'héritage de type spécialisation et d'une autre part dans une association de type généralisation ?
2.2 Si oui comment puis-je gérer le fait que dans ma spécialisation mon entité sous-type ne possède pas d'Id tandis que dans ma généralisation il me faut un Id??
Merci d'avance

[fsmrel]

Bonsoir shimomura22

J'aimerai savoir si il s'agit bien d'une spécialisation c'est à dire que L’entité sous-type (client, franchise, fournisseur) hérite de toutes les propriétés de l’entité sur-type (adresse) y compris de son identifiant ce qui explique le fait de ne pas avoir de Id dans les entités sous-type?

1) Revenons à la situation initiale.

On est dans un contexte de spécialisation, chaque sous-type hérite conceptuellement du surtype, y-compris de l’identifiant. On peut aussi faire de la généralisation, en ajoutant des identifiants propres aux sous-types. Par exemple, on définit un sous-type MAGASIN qui a son identifiant propre, MagasinId :





Passons maintenant au niveau du MLD (modèle logique des données), c'est-à-dire au niveau du modèle relationnel au sens de DB-MAIN (attention, il y a un clash sémantique, car depuis sa création en 1970, « modèle relationnel » est synonyme de « théorie relationnelle »). Pour cela, dans la barre de menus, vous cliquez sur l’onglet « Product » et choisissez l’option « Copy Product », afin d’avoir un clone de votre MCD, rattaché à ce dernier, clone que je nomme ici « MLD ». Je supprime la contrainte de partition en sélectionnant le surtype ENTITE pour y décocher les cases « total » et « disjoint », sinon au niveau SQL, j’aurais des cycles épouvantables...

Le diagramme est alors le suivant :




Pour produire le diagramme « relationnel », on choisit « Transform » > « Relational model » :





Vous noterez que les sous-types ont hérité de l’identifiant IdEntite du surtype ENTITE. En outre, MagasinId est toujours identifiant de MAGASIN, IdEntite y est identifiant alternatif. En outre le symbole « ref » signifie que pour chaque sous-type, IdEntite fait l’objet d’une contrainte référentielle : quel que soit le sous-type, une valeur de IdEntite est contrainte à être d’abord une valeur de IdEntite dans ENTITE.

En revanche, DB-MAIN n’a pas recopié dans les sous-types les autres attributs de ENTITE, ça serait effroyablement redondant et extrêmement pénible à maintenir !


2) Passons au MCD dans lequel figure l’entité-type ADRESSE :

A nouveau je crée un MLD, en commençant par créer un clone du MCD, débarrassé de la contrainte de partitionnement :





D’où le MLD (par Transform > Relational model) :




Où l’identifiant de ADRESSE est la paire {IdEntite, IdAdresse}, puisque ADRESSE avait été définie comme entité-type faible dans le MCD (utilisation de l’identification relative).

Dans tous les cas, au niveau MLD j'ai perdu la contrainte de partitionnement, mais je rattraperai le coup (au moins l'exclusion) au niveau SQL...

[shimomura22]

Merci à tous pour vos explications
Grâce à vous je vois enfin le bout du tunnel
Bonne journée