Discussion :

[hugouu]

Bonjour à tous, j'ai des questions assez basiques, j'ai cherché sur google mais je n'ai pas trouvé de réponses claires et précises. J'aimerais savoir qu'est ce que ca change en terme de sens de faire une entité et de mettre date en tant qu'attribut dans une entité.
De plus, de manière générale, quand est ce qu'on doit mettre un attribut dans une association ??
Merci d'avance pour le temps passé à répondre à mes questions.

[Metafire18]

J'aimerais savoir qu'est ce que ca change en terme de sens de faire une entité et de mettre date en tant qu'attribut dans une entité.

Pourrais tu être plus précis? As tu un exemple?

Pour les associations porteuses d'attributs, elles sont nécessaire pour définir certains concepts entre deux entités. Par exemple, pour un service de location de DVD, un client loue un DVD à une date donnée. Dans ce cas, on a une relation entre l'entité client et l'entité DVD. Cette dernière porte la date de location. Je ne vois pas comment énoncer ca de façon plus formelle.

[hugouu]

Merci de m'avoir répondu si vite.Par exemple, on a une entité commande, une client. On a une association "passe". On peut mettre la date dans l'association "passe", dans la commande ou faire une entité date.
Quelle est la différence entre ces trois choix?
J'espère qu'avec cet exemple, vous comprendrez ma question de départ.

[CinePhil]

Restons au niveau des entités pour commencer...

Cas du client qui passe commande.

Règle de gestion :
Un client peut passer plusieurs commandes et une commande est passée par un seul client.

MCD :
Client -0,n----Passer----1,1- Commande

La cardinalité 1,1 fera que la future table Commande recevra en clé étrangère l'identifiant du client. Cette association ne sera matérialisée que par cette clé étrangère et il n'y aura que les deux tables Client et Commande. Du coup il n'y a pas d'autre solution que de mettre de la date de la commande dans l'entité Commande.

Tables :
Client (cl_id, cl_nom...)
Commande (cd_id, cd_id_client, cd_date...)

Maintenant le cas de la location d'un DVD.

Règle de gestion :
Un client peut louer plusieurs DVD et un DVD peut être loué par plusieurs clients... mais pas à la même date !

MCD :
Client -0,n----Louer----0,n- DVD

Ici la date est un attribut porté par l'association Louer car les cardinalités maximales à n des deux côtés de l'association font qu'il y aura une table associative qui en découlera. Du coup la date n'est ni un attribut propre au client, ni propre au DVD mais bel et bien propre à la location et la date se retrouvera dans la table associative.

Tables :
CLient (cl_id, cl_nom...)
DVD (d_id, d_titre...)
Louer (l_id_client, l_id_dvd, l_date)

[hugouu]

D'accord!! Merci beaucoup, c'est plus clair comme ca !
Pardon, si j'insiste mais on aurait pu faire une entité date pour historiser non ?

[Metafire18]

Une association ternaire avec une entité date?

[CinePhil]

L'entité Date n'est vraiment utile que lorsque tu as besoin d'un calendrier.
Voir l'article de SQLPro sur le temps, sa mesure, ses calculs.

[fsmrel]

Bonsoir,

Règle de gestion :
Un client peut louer plusieurs DVD et un DVD peut être loué par plusieurs clients... mais pas à la même date !

MCD :
Client -0,n----Louer----0,n- DVD

Ici la date est un attribut porté par l'association Louer car les cardinalités maximales à n des deux côtés de l'association font qu'il y aura une table associative qui en découlera. Du coup la date n'est ni un attribut propre au client, ni propre au DVD mais bel et bien propre à la location et la date se retrouvera dans la table associative.

Les tables que vous proposez sont celles-ci :

Client (cl_id, cl_nom...)
DVD (d_id, d_titre...)
Louer (l_id_client , l_id_dvd, l_date)

Attention, il y a une différence sensible entre l’énoncé de la règle de gestion — selon laquelle le DVD n’étant pas quantique, il ne peut pas être emprunté simultanément par deux clients différents — et la contrainte exprimée par la clé de la table Louer.

En effet, cette clé exprime la contrainte suivante :

Un client ne peut louer qu’une seule fois un certain DVD :

Code :

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

1
2
3
4
Louer {l_id_client, l_id_dvd, l_date}
           c1           v1      j1
           c2           v1      j1 
           c1           v1      j2       // pas permis

Pour exprimer la contrainte selon laquelle deux clients ne peuvent pas emprunter le même DVD le même jour, au niveau tabulaire, la clé de la table Louer doit être composée de la paire {l_id_dvd, l_date} :

Louer (l_id_client, l_id_dvd, l_date)

Si au niveau du MCD on utilise la notation Entité/Relation, la représentation graphique correspondante est la suivante (Outil Power AMC) :


Le mickey porté par la patte connectant les entités-types Louer et DVD symbolise l’identification relative de l’entité-type (faible) Louer par rapport à l’entité-type (forte) DVD.
Le mickey porté par la patte connectant les entités-types Louer et Client symbolise une association banale entre les entités-types Louer et Client. Pour la petite histoire, Louer peut donc être qualifiée d’entité-type associative.

La transposition bestiale en Merise donne la représentation graphique suivante (Power AMC) :


La cardinalité 1,1, mise entre parenthèses et portée par la patte connectant les entités-types Louer et Client symbolise l’identification relative de l’entité-type (faible) Louer par rapport à l’entité-type (forte) DVD.

En utilisant une CIF (Merise 2), on en revient au (trop) traditionnel trio dans lequel on retrouve une entité-type Date :


Maintenant, il y a un certain nombre d’observations à faire.

1) Le client c2 peut emprunter au jour j2 = j1+1 le DVD v1 emprunté par le client c1 à j1 (et qui bien sûr ne l’a pas rendu) :

Code :

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

1
2
3
Louer {l_id_client, l_id_dvd, l_date}
           c1           v1      j1
           c2           v1      j2

Autrement dit, Louer doit se lire : « location en cours » et il faudra interdire (par exemple par un trigger SQL) que cette situation ne se produise.

2) hugouu a évoqué le problème de la gestion des historiques. Évidemment, on doit (au niveau tabulaire) définir une table supplémentaire qui a priori a la structure suivante :

LouerHisto {l_id_client, l_id_dvd, l_date_debut, l_date_fin}

Là encore, la clé primaire n'est pas d'un grand secours, les chevauchements de dates peuvent se manifester tant et plus.

On est en réalité aux prises avec l’univers des données temporelles, dans lequel la première chose à faire — pour le cas qui nous intéresse — est de définir un type intervalle composé de deux éléments, la date de début et la date de fin. Par exemple, si un emprunt a eu lieu de la date d01 à la date d45 et un autre de la date d28 à la date d84, une valeur de la table LouerHisto pourra être :

Code :

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

1
2
3
4
LouerHisto {l_id_client, l_id_dvd, l_intervalle}
                 c1          v1      [d01:d45]
                 c2          v2      [d28:d84]

Et la structure de la table sera la suivante :

LouerHisto {l_id_client, l_id_dvd, l_intervalle}

De clé :

{l_id_dvd, l_intervalle}

A charge du système de rejeter l’ajout d’une ligne telle que :

<c2, v1, [d28:d84]>

Tout ceci conduit en fait à étudier l’ouvrage commis par C.J. Date, Hugh Darwen et Nikos Lorentzos (pour lequel je me suis fendu d’un commentaire).

[ame=http://www.amazon.fr/Temporal-Data-Relational-Model-Investigation/dp/1558608559]Temporal Data and the Relational Model[/ame]
Attention, comme dirait Fernand Naudin, « Faut reconnaître, c’est du brutal »...

[TheLeadingEdge]

Avec ce Modèle Relationnel

Louer (#l_id_client, #l_id_dvd, l_date)

un même client ne peut pas emprunter 2 fois le même DVD, avec comme corrolaire l'impossibilité de gérer l'indisponibilité d'un DVD sur plusieurs jours consécutifs, et un même DVD pourra être loué à la même date par plusieurs clients différents.
Cette DF {Client, DVD} --> Date n'existe pas.

Par contre il existe 1 DF {DVD, Date} --> Client.
Cette Dépendance Fonctionnelle va être mise en évidence sur le MCD par la présence d'une Contrainte d'Intégrité Fonctionnelle (CIF).

On pourrait en rester là. Les id des 3 entités Client, Date et DVD vont migrer pour constituer la PK de la table qui va résulter de l'assoce Louer. Ce qui fait perdre la DF. Mais la présence de la CIF rappelle sa présence, et attire l'attention sur la nécessité de créer un trigger lors de la création du schéma pour respecter la DF.

Ttefois la présence d'une CIF indique généralement que la relation n-aire peut être réduite en une relation d'arité n-1.

Les 2 relations identifiantes entre Date et Location et entre DVD et Location correspondent à la CIF du 1er schéma.
Le schéma que produit ce modèle interdira de réserver plusieurs fois le même DVD à une même date, et fait faire l'économie d'un trigger.

Pour autant Il existe une Dépendance Multivaluée {Client, Date} --> DVD qui n'a pas été prise en compte.
Et il en résulte une certaine redondance.
Les id client et date sont répétées autant de fois qu'il a de ligne pour une location.
Ce qui introduit un risque de potentielles anomalies de mises à jour et de suppression.



La relation identifiante disparait entre Date et Location et la cardinalité 1,1 entre Location et DVD devient 1,n.
La Date et le Client ne sont plus répétés inutilement et on les retrouve par transitivité.
Comme le précédent ce modèle est Sans Perte d'Information (SPI), mais pas Sans Perte de Dépendance (SPD).
la contrainte d'unicité du couple Date, DVD a disparue.
Il va falloir recourir à un trigger pour la retrouver.

[fsmrel]

Bonsoir,


Au sujet de la représentation des CIF de Merise :

Pour alléger le MCD, on peut suivre la suggestion de D. Nanci et B. Espinasse (Ingénierie des systèmes d’information Merise (3e édition, page 156)) :

« Lorsque ce type de contrainte est la seule portée par la relation, nous suggérons de l’intégrer à la relation en fléchant la patte la connectant à l’entité cible »

En ce sens, on peut observer que la représentation graphique

est équivalente à celle que j’ai proposée dans mon précédent message (au nom des entités-types et des propriétés près) :

Les id des 3 entités Client, Date et DVD vont migrer pour constituer la PK de la table qui va résulter de l'assoce Louer. Ce qui fait perdre la DF. Mais la présence de la CIF rappelle sa présence, et attire l'attention sur la nécessité de créer un trigger lors de la création du schéma pour respecter la DF.

Nul besoin d’un trigger.

Soit l’AGL sait traduire la CIF au niveau du MLD et produit automatiquement une clé primaire pour la table Louer qui soit représentée par la paire {d_id, date} ;

Soit l’AGL ne sait pas faire et l’on intervient manuellement en éliminant l’attribut cl_id du triplet {d_id, date, cl_id}, lequel constitue une surclé mais pas une clé primaire ;

Soit on transforme l’association-type Louer en entité-type (cf. mon précédent message) :



Soit on passe par une solution (drastique...) qui consiste à utiliser la représentation Entité/Relation plutôt que la représentation Merise (cf. mon précédent message) :




Soit on utilise la représentation que vous proposez :






Mais dans tous les cas, le but de la manœuvre est d’arriver au MLD :

Pour autant Il existe une Dépendance Multivaluée {Client, Date} --> DVD qui n'a pas été prise en compte.

Qu’entendez-vous par dépendance multivaluée ?

Dans le cadre de la théorie relationnelle, ce concept a été défini indépendamment par Fagin (Multivalued Dependencies and a New Normal Form for Relational Databases, 1977) et Zaniolo (Analysis and Design of Relational Schemata for Database Systems, 1976). Je rappelle la définition (dans laquelle le terme relation est à interpréter comme table au sens SQL) :

Soit une relation R {X, Y, Z} où X, Y et Z représentent des sous-ensembles d’attributs de R (non nécessairement disjoints).
La dépendance multivaluée X —>—> Y est vérifiée dans R si et seulement si à chaque fois que <x, y, z> et <x, y’, z’> sont des tuples de R, alors <x, y’, z> et <x, y, z’> sont aussi des tuples de R.

Je rappelle aussi que si Z est l’ensemble vide, la dépendance multivaluée est triviale, c'est-à-dire quand l’union de X et de Y (au sens de la théorie des ensembles) est égale à l’en-tête H de la relation R.

Ainsi, l’en-tête de la table Louer est le suivant :

{d_id, l_date, cl_id}

Et la dépendance multivaluée {cl_id, l_date } —>—> {d_id} est triviale, c'est-à-dire que du point de vue de la théorie relationnelle, elle n’offre d’intérêt qu’à l’occasion de la définition de la quatrième forme normale et de l’extension des axiomes d’Armstrong.

Et il en résulte une certaine redondance.

Mais pas de redondance inutile. On apprend seulement une fois que tel DVD a été loué à telle date par tel client, ni plus, ni moins. En réalité, cette table est en 6e forme normale. Que demander de plus ?

Certes, on peut apprendre que tel client a loué plusieurs fois le même DVD, mais toujours à une date différente. Supprimer la moindre ligne de la table Louer entraînerait une perte d’information.

Les id client et date sont répétées autant de fois qu'il a de ligne pour une location.

???

Ce qui introduit un risque de potentielles anomalies de mises à jour et de suppression.

Par exemple ?

La relation identifiante disparait entre Date et Location et la cardinalité 1,1 entre Location et DVD devient 1,n.
La Date et le Client ne sont plus répétés inutilement et on les retrouve par transitivité.
la contrainte d'unicité du couple Date, DVD a disparue.
Il va falloir recourir à un trigger pour la retrouver.

Outre que l’on perd une règle de gestion (à rattraper par trigger), rien n’empêchera que le client Cx apparaisse n fois dans la table Entête et que le DVD Vy apparaisse m fois dans la table Ligne. Quelque chose doit m'échapper...