Discussion :

[PhildarZ]

Bonjour,

Pour mon inscription dans une société d'intérim, j'ai du effectuer un test.

Je devais concevoir le systeme de base de données d'une médiathèque.

Voici les exigences :

La médiathèque désire proposer des livres et connaître ces informations ( code, titre, année, éditeur, nombre de pages, collection,le ou les auteurs ).

La médiathèque désire proposer des CD et connaître ces informations ( code, titre, année, genre, label,format,durée totale, le ou les interprètes).
La médiathèque désire également connaître pour chaque CD le nombre de chansons, leurs durées et leurs titres respectifs.

La médiathèque désire proposer des films et connaître ces informations ( code, titre, année, genre, production,pays,durée totale, le nom des 3 acteurs principaux, le ou les réalisateurs)
De plus, un film peut être la suite d'un autre film.

Un livre peut avoir inspiré 1 ou plusieurs films.
Un film peut posséder la musique du film.

Pour chaque intervenant ( auteur, interprète, réalisateur ), on désire connaître son nom, prénom et son année de naissance.

J'aimerai savoir comment vous auriez fait parce que la solution que j'ai développé n'était pas très bonne.

Merci.

edit: après on m'a demandé de concevoir le diagrame de classe avec ( classe abstraite, agrégation, héritage... )

[hed62]

Postes toujours ce que tu as fais, on verra ensuite

[PhildarZ]

Voici donc ce que j'ai fait :



Après réflexion, je crois que j'aurai du faire une table œuvre reprenant les champs communs généraux ( titre, année, genre ).

Mais il y a surement beaucoup d'erreurs ou des choses à améliorer, je suis à l'écoute de vos critiques.

Merci

[fsmrel]

je suis à l'écoute de vos critiques.

Oyez donc.

Entité-type Auteur : en fait il s’agit d’une association entre Intervenant et Livre :
Au niveau tabulaire, la table Auteur comporte en conséquence les attributs Id_Intervenant et Code_Livre. L’attribut Id_Auteur n’apporte aucune valeur ajoutée et doit dégager. Un auteur pouvant écrire plusieurs ouvrages, Id_Intervenant entre donc dans la composition de la clé de la table Auteur. Si un livre n’a été écrit que par un seul auteur, la clé est complète. Si un livre peut avoir des co-auteurs (comme le laisse supposer votre énoncé), alors la clé de la table Auteur est composée du couple {Id_Intervenant, Code_Livre}.
Un auteur n’a pas de propriétés particulières le distinguant des autres types d’intervenants : il n’y a donc pas a priori à le spécialiser et faire intervenir un quelconque héritage.

Exemple avec Access 2003, dans lequel on suppose qu’un livre peut avoir des co-auteurs (j’ai un peu changé les noms des attributs) :




Concernant les CD :

Selon votre représentation, un interprète est associé au plus à un CD : sa carrière sera plutôt éphémère...
Comme l’auteur, il n’a pas de propriétés particulières le distinguant des autres types d’intervenants : il n’y a donc pas a priori à le spécialiser et faire intervenir un quelconque héritage.

Un CD est composé de plages numérotée de 1 à N. Plage peut être considérée comme étant une propriété multivaluée de CD. Au niveau tabulaire, on représente cela par une table, appelons-la Plage, dont la clé est composée du couple {CdId, PlageNumero}. Si pour une plage d’un CD on n’a qu’un seul interprète, alors on établit un lien entre l’intervenant (interprète) et la plage (IntervenantId a été renommé en InterpreteId dans Plage).





Si on a plusieurs interprètes pour une plage donnée, alors on passe par la représentation suivante, dans laquelle la table Interprétation a pour clé le triplet {CdId, PlageNumero, InterpreteId} :




Concernant les réalisateurs de films :

Comme pour les autres intervenants, l’héritage ne se justifie pas.
FilmRealisateurId est synonyme d'IntervenantId.

Petite difficulté pour exprimer qu’un film est la suite d’un autre film : Access 2003 n’est pas capable de traduire la contrainte selon laquelle un film peut avoir un successeur (et un seul), tandis que le successeur n’a qu’un antécédent, d’où l’espèce de gribouillage farfelu proposé par Access (et faux car Access impose qu’un film puisse avoir N films qui le suivent au lieu d’un seul) :





N.B. Vous écrivez qu’un film peut posséder la musique du film : sans plus informé, ceci s’interprète littéralement par OUI | NON (booléen).


Vous parlez de diagramme de classes :

Vous pouvez utiliser Power AMC ou autre outil pour réaliser un tel diagramme, qui ressemblera plus ou moins à celui-ci :



Bon courage pour la suite.

[fsmrel]

Je joins le MLD selon Power AMC :

[PhildarZ]

Bonjour,

Merci fsmrel pour ces critiques constructives

j'ai bien compris tes explications et j'ai retravaillé le schéma.
Pour les plages d'un CD, l'énoncé ne spécifié de connaître les intervenants. On part du principe qu'un cd est interprété par 1 ou n intervenant et c'est tout.

Dans une médiathèque, on peut envisager qu'une personne fasse une recherche sur tout ce qui concerne "le seigneur des anneaux" par exemple.
Il faut donc exécuter plusieurs une requête dans chacune des tables (livre, cd, film ).

Peut'on concevoir ce genre de modèle ?
( j'ai laissé tomber la contrainte "suite de film" et "musique de film").



La table participation fait le lien entre l'œuvre et son intervenant et donne sa fonction dans la participation ( auteur, interprète, réalisateur ) avec l'attribut ParticipationFonction

Merci

[fsmrel]

Bonjour PhildarZ,


Quelques remarques.

Concernant la table Participation :

Préciser quels attributs composent la clé de la table.

Concernant la table Film :

L’attribut RealisateurId n’a plus d’existence légale et doit disparaître. Pour retrouver le(s) réalisateur(s) d’un film, il faut mettre en œuvre une jointure impliquant les tables Film, Participation et Intervenant.

Concernant Plage :

A moins que vous prouviez le contraire, l’attribut PlageId n’apporte aucune valeur ajoutée et doit disparaître, au nom du rasoir d’Ockham.
En effet, j’avais écrit :

"Un CD est composé de plages numérotée de 1 à N. Plage peut être considérée comme étant une propriété multivaluée de CD. Au niveau tabulaire, on représente cela par une table, appelons-la Plage, dont la clé est composée du couple {CdId, PlageNumero}."

Précision : Quand je dis que Plage est une propriété multivaluée de CD, cela veut dire que lorsqu’on supprime un CD, les plages qui le composent disparaissent avec lui. On dit encore que, conceptuellement parlant, Plage est une entité faible (weak entity), qui n’a d’existence qu’au travers de CD.

Si l’on s’affranchissait de la première forme normale (1NF), la structure de CD absorberait celle de Plage et serait alors la suivante :

CD (CdId, CdLabel, CdFormat, OeuvreId, Plage (PlageNumero, PlageTitre, PlageDuree))

Mais, pour respecter la 1NF, l’application de l’algorithme proposé par Ted Codd, père du Modèle Relationnel de Données donne lieu à la décomposition suivante :

CD (CdId, CdLabel, CdFormat, OeuvreId)
Plage (CdId, PlageNumero, PlageTitre, PlageDuree)

En l’occurrence, vous pouvez vous reporter à l’article fondateur de Codd, A Relational Model of Data for Large Shared Data Banks, au paragraphe 1.4 : "Normal Form".

Concernant CD, Livre et Film :

Votre intention de mise en facteur commun au sein de la table Oeuvre de certains attributs est louable (titre, année, genre). Mais reprenons le cas du "Seigneur des anneaux". Si cette œuvre a pu faire l’objet chez différents éditeurs d’autant de livres, CD et films, les relations avec Oeuvre sont a priori correctes. Toutefois, vous perdez en souplesse et gagnez des contraintes pouvant s’avérer gênantes. Par exemple, la parution du livre en France date de 1972. Le film est sorti quelques années après. Selon votre modélisation comment distinguer les dates ? Même choses si le film a connu différentes versions. Comparez avec le diagramme de classes ou le MLD que je vous ai proposés.

[PhildarZ]

Bonjour fsmrel,

Encore merci pour ces remarques

# En effet, j'ai oublié la clé dans la table Participation.

# Ok pour la table Film.

#Je comprends mieux l'erreur dans la relation CD-Plage

# Et finalement, remarque très pertinente pour mon exemple du seigneur des anneaux.


En tout cas maintenant, je comprends mieux certains aspects...

Je te remercie. @ bientôt.