Bonsoir,
Envoyé par
mullinski
A une date et un horaire donné, un film ne peut être projeter que dans une seule salle.
A une date et un horaire donné, une salle ne peut projeter qu'un seul film.
Considérons donc les deux contraintes :
(C1) A une date et un horaire donné, un film ne peut être projeté que dans une seule salle.
(C2) A une date et un horaire donné, une salle ne peut projeter qu'un seul film.
Abrégeons ainsi les noms :
F pour film
S pour salle
D pour Date (de projection)
H pour horaire (de projection)
Du point de vue du Modèle Relationnel de Données l’expression des contraintes ne pose aucun problème.
(C1) et (C2) donnent respectivement lieu aux DF (dépendances fonctionnelles) suivantes (parmi d’autres) :
(DF1) : {F, D, H} → {S}
(DF2) : {S, D, H} → {F}
N.B. L’utilisation des accolades signifie que les DF mettent en jeu non pas des attributs, mais des ensembles d’attributs.
Soit T la table dont l’en-tête est composée des attributs S, F, D, H.
Selon le Modèle Relationnel de Données, je devrais utiliser le terme variable relationnelle (relvar), plutôt que celui de table, mais il est inutile d’exposer ici ce qui les différencie.
T fait l’objet de la déclaration suivante :
1
2
3
4
5
6
|
VAR T {S INT, F INT, D DATE, H TIME}
KEY {F, D, H}
KEY {S, D, H}
FOREIGN KEY {F} REFERENCES FILM
FOREIGN KEY {S} REFERENCES SALLE ; |
Selon le modèle SQL, la déclaration devient la suivante :
1
2
3
4
5
6
|
CREATE TABLE T {S INT, F INT, D DATE, H TIME}
PRIMARY KEY {F, D, H}
UNIQUE {S, D, H}
FOREIGN KEY {F} REFERENCES FILM
FOREIGN KEY {S} REFERENCES SALLE ; |
Vous noterez que cette deuxième déclaration met en évidence un problème de symétrie qui n’existe pas dans la première déclaration. En effet, alors que le Modèle Relationnel de Données ne propose pas de privilégier une clé par rapport à une autre, le modèle SQL vous y oblige : une des deux clés {F, D, H} ou {S, D, H} est nécessairement clé primaire, {F, D, H} dans l’exemple, tandis que l’autre est clé est dite alternative, en l'occurrence {S, D, H}. Évidemment, les rôles auraient pu être inversés, et mon choix a été purement subjectif.
Avec Power AMC, on peut par exemple définir le MLD (SQL) correspondant suivant (dans lequel j’ai remplacé le nom de la table T par Projection) :
MLD.jpg)
Dans cette représentation graphique, <pk> est l’abréviation de <primary key>, <ak> celle de <alternate key> (équivalent de la clause UNIQUE de SQL) et <fk> l’abréviation de <foreign key>.
Ainsi, dans la représentation, la table Projection a les propriétés suivantes :
Clé primaire : {FilmId, DateProj, HoraireProj}
Clé alternative : {SalleId, DateProj, HoraireProj}
Clé étrangère 1 : {FilmId}
Clé étrangère 2 : {SalleId}.
Tout va bien. Maintenant, les choses se compliquent si l’on veut procéder à la rétroconception du MLD en MCD. En effet, par propagation de l’effet d’asymétrie, l’AGL fournit la représentation graphique suivante :
MCD.jpg)
Représentation dans laquelle, la cardinalité 1,1 mise entre parenthèses, traduit l’identification relative (cf. la patte connectant Projection et PF). L’entité-type Projection est identifiée relativement à l’entité-type Film, ce qui fait que l’identifiant de celle-ci participe implicitement à l’identifiant de celle-là. Maintenant, il y a une mauvaise nouvelle : l’attribut SalleId apparaît à la fois dans les entités-types Salle et Projection, mais le comportement de l’AGL est parfaitement justifié. Cela est dû au fait, à ma connaissance, que selon l’approche Entité/Relation (Merise en particulier), il n’a pas été prévu de pouvoir signifier que l’identifiant d’une l’entité-type (Salle en l’occurrence) participe à un identifiant alternatif d’une autre l’entité-type (Projection dans cet exemple). Ainsi, on est coincé quant aux processus de dérivation/rétroconception, la redondance inhérente fait que le résultat ci-dessus est incorrect, puisque lors de la dérivation, la table Projection comportera deux attributs SalleId : il faudra intervenir manuellement pour parvenir à une situation correcte.
Maintenant, changeons d’AGL. Win’Design est peut-être capable de produire un résultat correct dans le cas de la rétroconception, je n’en sais rien. En revanche, du point de vue de la dérivation, il s’en sort sans problème si l’on transforme l’entité-type Projection en une association-type (appelons-la Projeter) et si l’on utilise des CIF (contraintes d’intégrité fonctionnelle) pour en arriver à une modélisation du genre (qui font les yeux se croiser...) :
CIF.jpg)
CIF1 se comporte comme une DF : le triplet Film, Date, Horaire joue le rôle de déterminant (source) et Salle celui de dépendant (cible).
CIF2 se comporte comme une DF : le triplet Salle, Date, Horaire joue le rôle de déterminant (source) et Film celui de dépendant (cible).
Le lien figurant entre l’association-type Projeter et une CIF est représenté en pointillés, et explicite ce qu’on appelle le pivot, liste des entités-types composant la source de la CIF. Je vous renvoie à la FAQ Merise.
En principe, le résultat de la dérivation devrait être le MLD décrit ci-dessus.
Envoyé par
mullinski
Finalement pour construire ce MCD, j'ai l'impression d'être "déconcentrer" par la base de données qui en résultera : car évidemment, une fois le MCD terminé, je souhaite générer automatiquement ou créer manuellement cette base. Et le comble du paradoxe, c'est parce que j'avais du mal à créer cette base directement (tu m'étonnes) que je me suis décidé à commencer par un MCD. J'abandonne ?
La construction d’un MCD relève d’une approche synthétique, descendante, tandis que celle d’un MLD relève d’une approche analytique, ascendante. Pour s’en sortir, il est préférable de pratiquer simultanément les deux approches, descendre, remonter, redescendre, etc., autrement dit faire du yoyo. J’ai vu bien des projets partir à la poubelle, ou à rafistoler au niveau MLD parce qu’en amont on s’était contenté de synthétiser, sans validation analytique. Et ça en a fait des sous dilapidés. Évidemment, l’approche synthétique est plus tentante, parce que l’on s’occupe de sémantique, alors que l’approche analytique est plus austère, aride, mathématique, sans que l’on ait à s’intéresser au «métier» (la vie des cinémas par exemple). Il faut s’entraîner à la double approche.
Quant aux goûts de chacun, tendance sémantique ou mathématique, c’est un peu comme en programmation. Certains ne jurent que par l’approche récursive, d’autres par l’approche impérative, Là encore, l’idéal est d’être à l’aise dans les deux styles.
programme de cinéma sur plusieurs semaines
, je me résigne à demander de l'aide pour avancer un peu dans mon MCD
...
).
.
, si ce n'est de me rendre compte que le mot débutant est peut-être encore un peu trop fort pour moi
, ou bien je n'arrive pas à "transposer" les exemples de ces PDF dans mon cas de figure (ce qui me parait être le coeur du problème... et accessoirement confirmer mon petit QI
...
.
. J'abandonne ?
Répondre avec citation
. En ce qui concerne les cardinalités, en revanche 
. J'ai bon 
ou je mélange tout 
.
? Ne serait-il pas plus juste/logique de considérer ces semaines comme existantes mais sans film 
? Ce qui permettrait de tenir compte de ces semaines pour... des stats éventuelles ? Pour pouvoir afficher, par exemple, le nombre de films joués par semaine réelles. Bon j'exagère peut-être mais l'idée ne me parait pas ridicule 
.
. 
?
Partager