Discussion :

[Krystal_]

Bonjour,

Dans la conception d'un schéma, je butte sur un point qui me chatouille les neurones.

J'ai trois notions :
- Des services
- Des étages
- Des localisations

Les règles sont les suivantes :
- Un service peut être sur 1 ou plusieurs étage
- Un étage peut accueillir un ou plusieurs services
- Une localisation est à un étage et à un service

Avec ça j'arrive à un schéma assez simple ou j'ai une entité service(ID, Nom), une entité étage (ID, niveau) et la localisation est simplement l'association n,n reliant les deux saupoudrées d'une propriété supplémentaire "libellé".
L'ennui c'est qu'alors, on peut mettre n'importe quelle localisation à n'importe quelle association service --- étage. Or, je voudrais qu'une localisation ne puisse être associée qu'à certains couple étage --- service.
Pour répondre à ce nouveau besoin, la solution que j'ai trouvé est de considérer la localisation comme une entité et de faire une relation ternaire. Physiquement, j'obtiens donc les tables suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
- Service(Service_ID, Nom)
- Etage(Etage_ID, Niveau)
- Service_Etage(
    Service_ID, -- fk Service.Service_ID
    Etage_ID    -- fk Etage.Etage_ID
)
- Localisation(
    Localisation_ID
    Service_ID,
    Etage_ID,
    Libelle
) -- fk(Service_ID, Etage_ID) reference Service_Etage(Service_ID, Etage_ID)

Ca semble respecter toutes mes contraintes, mais je ne peux m'empêcher de trouve cela peu élégant. Est-ce rigoureusement correct ? Ne devrais-pas introduire une clé primaire auto-incrémentée dans Service_Etage pour éviter la fk composée dans Localisation ? Une autre façon de faire qui m'aurait échappée ?

D'avance merci.

[JPhi33]

Bonjour Krystal_,

Les règles exprimées concernant la localisation méritent d'être précisées.

- Une localisation est à un étage et à un service

Or, je voudrais qu'une localisation ne puisse être associée qu'à certains couple étage --- service.

Avec des exemple cela aurait été plus clair mais ce qu'on comprend de prime abord, c'est :
- A une localisation on ne trouve qu'un couple {étage, service}
- A un couple {étage, service} peuvent correspondre plusieurs localisations

A toi de confirmer, et si c'est le cas, la modélisation correspondante est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
   [ SERVICE ]
        |
       0,n
        |
        |
( SERVICE-ETAGE )<-0,n----( )----1,1--[ LOCALISATION ]
        |
        |
       0,n
        |
    [ ETAGE ]

La dérivation de ce MCD en modèle relationnel donne les tables (pk soulignées, fk en italique) :

SERVICE(serv_id, serv_nom)

ETAGE(etag_id, etag_niveau)

SERVICE-ETAGE(serv_id, etag_id) ---> serv_id référence SERVICE, etag_id référence ETAGE

LOCALISATION(loca_id, loca_libelle, serv_id, etag_id) ---> {serv_id, etag_id} référence SERVICE-ETAGE

Cette description des tables est identique à la tienne.

Ne devrais-pas introduire une clé primaire auto-incrémentée dans Service_Etage pour éviter la fk composée dans Localisation ?

Non, c'est inutile mais surtout, c'est faux. Le couple {serv_id, etag_id} identifie de manière unique toutes les lignes de la table SERVICE-ETAGE. Y introduire une clé primaire auto-incrémentée, c'est prendre le risque d'introduire des doublons dans cette table. La fk composée dans LOCALISATION est correcte et parfaitement légitime.

[Krystal_]

Bonjour,

Merci pour ta réponse qui me conforte dans mon idée de départ. Ton interprétation est tout à fait correcte, le modèle doit répondre aux contraintes que tu as énumérées.