Discussion :

[stargatejojo]

Bonjour,

Voici une partie de mon modèle logique de données :



Cependant dans mon application web, il devient difficile de gérer cette table associative, puisque pour l'identifier, je dois passer l'ID du spectacle, l'ID du lieu ainsi que la date et non plus simplement un identifiant unique pour la représentation.

Alors il m'est venu à l'esprit de faire comme ceci, mais je ne sais pas si c'est une bonne façon de faire les choses :



Cette deuxième solution permet d'éviter les doublons avec l'index unique qui est fait sur ID_Spectacle, ID_Lieu et Date.

Pouvez-vous me dire si la deuxième méthode que je propose ci-dessus est une méthode acceptable ou si cela ne se fait surtout pas ?
Ou y a-t-il d'autre méthode que je n'aurais pas envisagé ?

[fsmrel]

Bonsoir,


Vos deux représentations graphiques montrent que le même jour :

- un spectacle peut avoir lieu dans plusieurs endroits,
- un lieu accueillir plusieurs spectacles.

En est-il bien ainsi ?

A cela près, je ne vois pas en quoi une clé primaire mono-attribut vous simplifie la vie.

[stargatejojo]

Bonsoir,

Vos deux affirmations sont en effet correcte. A ceci prêt qu'un ne peuvent pas se produire au "même moment" dans un même lieu.

Pour savoir, est-ce que ma modélisation présentée en premier est correcte ?

Avec une clé primaire pour identifier un enregistrement, il me suffit de la passer en paramètre à mes pages qui gèrent les représentations de spectacle.

Si maintenant la clé primaire se compose de plusieurs éléments comme le montre le premier schéma, je suis obligé de TOUS les passer en paramètre pour identifier de manière unique une ligne de la table des représentations.

Au final je ne sais pas si mon deuxième se fait ou si c'est contraire à "l'éthique" de modélisation de base de données, vu que la table est en fait une table associative.

[fsmrel]

Vos deux affirmations sont en effet correcte. A ceci prêt qu'un ne peuvent pas se produire au "même moment" dans un même lieu.

Dans le principe, il serait peut-être bon de prévoir un attribut de type tranche horaire.

Si maintenant la clé primaire se compose de plusieurs éléments comme le montre le premier schéma, je suis obligé de TOUS les passer en paramètre pour identifier de manière unique une ligne de la table des représentations.

Au final je ne sais pas si mon deuxième se fait ou si c'est contraire à "l'éthique" de modélisation de base de données, vu que la table est en fait une table associative.

Table associative ou pas, la règle est que l’organisation des traitements et celle des données sont liées par un pacte d’indépendance : L’organisation des traitements ne doit en aucune façon avoir d’influence sur la structure des données, sinon il n’y aurait pas de raison que chaque programme (y compris ceux qui seront développés dans x années) n’ait son mot à dire et fasse évoluer la structure des données.

Cela dit, vous pouvez en passer par une phase d’« optimisation » et ajouter l’attribut id_représentation, mais si vous en faites une clé primaire, alors de l’ancienne clé primaire, faites une clé alternative (clause UNIQUE dans l’instruction CREATE TABLE). Vous avez évoqué un index UNIQUE, mais le concept d’index est du niveau physique (fer à souder et compagnie), tandis que le concept de clé est du niveau logique (théorie relationnelle).

[patmaba]

Bonjour,

Avec quel outil graphique avez-vous fait ces schéma ?
Je recherche un outil pour faire le même model de schéma.

Merci

[fsmrel]

En cherchant ceci vous devriez trouver ce qui vous intéresse :

MySQL Workbench 5.0 OSS

(freeware)

[CinePhil]

Je rebondis sur cette remarque :

Vos deux représentations graphiques montrent que le même jour :

- un spectacle peut avoir lieu dans plusieurs endroits,
- un lieu accueillir plusieurs spectacles.

J'aurais intuitivement fait la même chose (1er schéma quand même !)

On est bien d'accord qu'un spectacle peut avoir lieu plusieurs fois au même endroit et qu'on ne peut donc se contenter d'une clé primaire (id_lieu, id_spectacle).

On est bien d'accord aussi que l'ajout de la date à la clé primaire autorise cette fois un spectacle à se dérouler en plusieurs lieux à la même date.

Comment résoudre ce problème ?

Remontons aux règles de gestion...
1) Un spectacle peut être programmé en plusieurs lieux et un lieu peut programmer plusieurs spectacles.

Le MCD qui en découle est le suivant :
Lieu -0,n----Programmer----0,n- Spectacle

Il en découle les tables :
Lieu (id_lieu,...)
Spectacle (id_spectacle, ...)
Programme (id_lieu, id_spectacle)

Supposons pour simplifier qu'un spectacle n'a qu'une représentation par jour et changeons la règle de gestion :
2) Un spectacle peut être programmé à plusieurs dates en un lieu et un lieu peut programmer un spectacle à plusieurs dates.

Nous voyons que dans la première version, nous allons de un (lieu ou spectacle) vers plusieurs (spectacles ou lieux) et que dans la seconde version nous allons de un (lieu et spectacle) vers plusieurs dates.

Pour prendre en compte l'exigence de la seconde version, il faut donc associer le couple (lieu, spectacle) à des dates.

Où se trouve ce couple dans notre premier MCD ?
Dans l'association Programmer qui engendre la table Programmation.

On peut donc transformer l'association Programmer en entité Programme puis l'associer à une entité (généralement fictive) Date ou plus concrêtement Séance.

Lieu -0,n----Programmer----1,1- Programme -1,1----Représenter----0,n- Spectacle
Séance -1,1----Concerner----1,n------|

Nous arrivons aux tables :
Lieu (id_lieu,...)
Spectacle (id_spectacle, ...)
Programme (id_programme, id_lieu, id_spectacle, ...)
Seance (id_seance, id_programme, date_seance, ...)

Avec un index unique sur le couple (id_programme, date_seance)

[fsmrel]

Bonjour,

Nous arrivons aux tables :
Lieu (id_lieu,...)
Spectacle (id_spectacle, ...)
Programme (id_programme, id_lieu, id_spectacle, ...)
Seance (id_seance, id_programme, date_seance, ...)

Avec un index unique sur le couple (id_programme, date_seance)

L’index est un objet du niveau physique alors que nous en sommes toujours au niveau logique : conformément à la 8e des 12 règles de Codd il ne faut pas mélanger les genres. En conséquence, on mettra en œuvre une clé alternative pour la paire {id_programme, date_seance} de la table SEANCE, c'est-à-dire qu’on utilisera la clause UNIQUE dans l’instruction CREATE TABLE (le SGBD ou le DBA se chargeant dans la soute de créer l’index ou d’utiliser tout autre moyen pour garantir la règle d’unicité) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 CREATE TABLE PROGRAMME
(    Id_Programme    CHAR(4)     NOT NULL 
   , Id_Lieu         CHAR(4)     NOT NULL
   , Id_Spectacle    CHAR(4)     NOT NULL
  , CONSTRAINT PROGRAMME_PK PRIMARY KEY (Id_Programme)
  , CONSTRAINT PROGRAMME_AK UNIQUE (Id_Lieu, Id_Spectacle)
); 
CREATE TABLE SEANCE
(    Id_Seance       CHAR(4)     NOT NULL
   , Id_Programme    CHAR(4)     NOT NULL 
   , Date_Seance     CHAR(10)    NOT NULL
  , CONSTRAINT SEANCE_PK PRIMARY KEY (Id_Seance)
  , CONSTRAINT SEANCE_AK UNIQUE (Id_Programme, Date_Seance)
  , CONSTRAINT SEANCE_FK FOREIGN KEY (Id_Programme)
        REFERENCES PROGRAMME ON DELETE CASCADE 
);

On remarquera que la table PROGRAMME est aussi à doter d’une clé alternative {Id_Lieu, Id_Spectacle}.

En fait, on retrouve (sous forme d’une vue) la 2e version de la table REPRESENTATION de stargatejojo :

Code :

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

1
2
3
4
5
6
CREATE VIEW REPRESENTATION (Id_Representation, Id_Lieu, Id_Spectacle, Date)
AS
    SELECT x.Id_Seance AS Id_Representation, y.Id_Lieu, y.Id_Spectacle, x.Date_Seance
    FROM   SEANCE AS x JOIN PROGRAMME AS y
              ON x.Id_Programme = y.Id_Programme

D’un point de vue logique, votre solution et la 2e version de stargatejojo sont équivalentes.

Comment résoudre ce problème ?

Quel problème ?


Pour ma part, une question demeure, celle de la simultanéité des événements : un spectacle peut-il être programmé le même jour, dans deux endroits différents, au même instant (c'est-à-dire à la même heure) ?

Par exemple, le spectacle « Le chat de Schrödinger » peut-il être programmé ce jeudi 15 octobre 2009 de 20h à 21h à Toulouse et de 20h30 à 21h30 à Bordeaux ?

[CinePhil]

Pour ma part, une question demeure, celle de la simultanéité des événements : un spectacle peut-il être programmé le même jour, dans deux endroits différents, au même instant (c'est-à-dire à la même heure) ?

Par exemple, le spectacle « Le chat de Schrödinger » peut-il être programmé ce jeudi 15 octobre 2009 de 20h à 21h à Toulouse et de 20h30 à 21h30 à Bordeaux ?

OK, il y a encore un grain de sable dans mon raisonnement !

Ce matin, en écrivant ceci :

J'aurais intuitivement fait la même chose (1er schéma quand même !)

On est bien d'accord qu'un spectacle peut avoir lieu plusieurs fois au même endroit et qu'on ne peut donc se contenter d'une clé primaire (id_lieu, id_spectacle).

On est bien d'accord aussi que l'ajout de la date à la clé primaire autorise cette fois un spectacle à se dérouler en plusieurs lieux à la même date.

Comment résoudre ce problème ?

J'avais écrit aussi :

J'ai peut-être les neurones un peu rouillés mais je ne vois pas !

Puis j'ai quand même pris un temps de réflexion pour essayer d'aller un peu plus loin mais apparemment j'ai vraiment les neurones un peu rouillés !

Ceci dit vous avez peut-être trouvé la solution parce qu'on sait bien que le chat de Shrödinger peut se trouver en deux endroits à la fois !

[fsmrel]

j'ai quand même pris un temps de réflexion pour essayer d'aller un peu plus loin mais apparemment j'ai vraiment les neurones un peu rouillés !

Don’t worry, les neurones c’est pas grave, et comme dit le poète, ce qui fait mal, ce sont les dents...

http://www.actionext.com/names_g/geo...testament.html