Discussion :

[aurore973]

Bonjour,
Voilà j'ai réalisé un MCD mais j'ai un petit problème entre 2 entités. Voici l'énoncé :
La ville TOURISTA est l’une des plus anciennes villes du monde. Le maire de la ville a des difficultés à assurer le contrôle des visites des différents sites touristiques. Actuellement, les billets sont vendus à l’entrée, et aucun moyen n’est utilisé pour connaître exactement le nombre de billets vendus. Pour résoudre ces problèmes, la solution suivante a été proposée.
• Les billets seront imprimés à des points de vente (hôtels, restaurant, mairie,..) par un appareil jouant aussi le rôle de caisse enregistreuse;
• Les informations suivantes seront inscrites sur le billet :
o No passeport visiteur No vendeur
o Pays visiteur No série du billet (incrément)
o Nom visiteur Date/heure de vente
o No site Date expiration
• Un lecteur magnétique sera utilisé à l’entrée du site pour autoriser l’accès à partir du billet ;
• En fin de jour, chaque appareil placé chez un vendeur produira automatiquement un rapport du nombre de billets vendus par site.

Règles de gestion
Un billet est émis pour un site et doit être utilisé une seule fois;
Le prix du billet est fixé par site.
Travail à réaliser
1. Dresser le Modèle Conceptuel de Données
2. Dessiner le graphe des dépendances fonctionnelles
3. Réaliser les Modèle Logique et Physique de données
4. Rechercher
a. Les noms des touristes venant d’Italie qui ont visité le site B le 1e septembre 2006 ;
b. Toutes les visites (site, date) effectuées par le touriste « Ashley » ;
c. Les noms des points de vente, leurs adresses et personnes responsables.

Voici mon MCD :


Je sais qu'il y a un problème pour l'association entre site et rapport, mais je n'arrive pas à préciser que le rapport édite le nombre de billet PAR SITE.
Merci de juste me mettre sur la voie car là je bloque depuis un moment.
Merci d'avance
Aurore

[fsmrel]

Hello Aurore,

Un lecteur magnétique sera utilisé à l’entrée du site pour autoriser l’accès à partir du billet

Donc, vous savez repérer qu’un billet vendu par tel point de vente a été utilisé et validé (ou invalidé) à telle date pour tel site. En conséquence, l’entité-type Billet doit comporter une propriété Date de validation du billet (ou Date validée d’accès au site).
Vous êtes alors en mesure de calculer le nombre de billets validés par le regroupement qui vous convient. Par exemple, par date, par point de vente et par site.

En paraphrasant SQL :

Code :

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

1
2
3
4
5
Select Date_Validation, Num_Point_Vente Num_Site, Count(*) 
From   Billet 
Where  Date_Validation is not null         /* cas des dates non validées */
Group by Date_de_Validation, Num_Point_Vente, Num_Site ;

L’entité-type Rapport est en principe hors du champ du MCD, puisqu’au niveau opérationnel, en définissant une vue Rapport, vous définissez une table virtuelle reflétant exactement la situation jour par jour. Définir une entité-type serait une redondance (si vous le faites, supprimez la table correspondante lors de la dérivation) :

La vue Rapport permet d’obtenir le montant comptabilisé par date, site, point de vente

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Create View Rapport as (
Select  N.Date_Validation, N.Num_Site, N.Num_Point_Vente, 
          N.Nb_Billets * Site.Tarif_Site As Montant
From    Site, (Select Date_Validation, Num_Site, Num_Point_Vente, 
                      Count(*) As Nb_Billets 
                   From   Billet 
                   Where  Date_Validation is not null 
                   Group by Date_Validation, Num_Site, Num_Point_Vente
              ) As N
Where Site.Num_Site = N.Num_Site 
);

Cette vue mérite sans doute quelques raffinements, toutes les variations sur ce thème sont possibles.

Ai-je répondu à votre question ?

[aurore973]

Rebonjour,

Alors pour le premier point j'ai bien compris, en rajoutant une propriété date_validation_billet, cela résolu mon problème.
Par contre pour le deuxième point, puis je vous demandez ce que vous appellez une "vue" (vue RAPPORT), si je comprends bien cette entité RAPPORT ne sert plus à rien donc je la supprime de mon MCD ?

Cordialement,
Aurore

[aurore973]

Pendant que j'ai quelqu'un qui s'y connait est ce que vous connaissez un tutoriel sur les graphes de dépendances fonctionnelles, ou pouvez vous m'expliquer les grands principes car j'ai l'impression de refaire simplement le MCD avec quelques légères modifications (j'enlève l'entité et je mets l'identifiant puis je rajoute les proriétés).
Y a -t-il de grands principes, de grandes règles à suivre ?

Double merci encore,
Aurore

[TheLeadingEdge]

Bonjour,

si je comprends bien cette entité RAPPORT ne sert plus à rien donc je la supprime de mon MCD ?

Oui. Ton rapport n'est pas 1 entité. Il a sa place ds les modèles de ttmt, pas de données. Le reste du MCD semble correct pour fournir ce que qui t'es demandé.

...est ce que vous connaissez un tutoriel sur les graphes de dépendances fonctionnelles, ou pouvez vous m'expliquer les grands principes car j'ai l'impression de refaire simplement le MCD avec quelques légères modifications (j'enlève l'entité et je mets l'identifiant puis je rajoute les proriétés).
Y a -t-il de grands principes, de grandes règles à suivre ?

C'est normal que tu aies l'impression de faire presque la même chose.
La finalité est la même. Regrouper les propriétés en entités et de les relier.
Par contre ce qui est etonnant c'est que tu fasse d'abord le MCD.
D'habitude on fait le contraire. (enfin si on fait tout. Si l'étude est simple et que tu te sentes à l'aise, tu peux attaquer direct le MCD.
Utiliser la matrice ''guide'' 1 peu plus ds la découverte des entités).
D'abord 1 dictionnaire des données, puis la matrice des DF, puis le graphe SRE (systeme entite-relation) duquel enfin on dérive le MCD.

Sinon désolé j'ai pas de ref. à te donner. Mais si tu as 1 doute postes ta matrice.

A +

[fsmrel]

Bonsoir Aurore,

Puis-je vous demandez ce que vous appelez une "vue" (vue RAPPORT), si je comprends bien cette entité RAPPORT ne sert plus à rien donc je la supprime de mon MCD ?

Dans votre MCD, vous avez défini les entités-types Site, Billet, Point_De_Vente : elles sont indispensables pour votre Système d’information. Maintenant, Rapport peut être perçue comme une entité-type dérivée des précédentes : sa matérialisation ne s’impose pas. De façon imagée je dirais que, si Point_De_Vente, Site, Billet, hébergent des axiomes alors Rapport héberge des théorèmes.
A strictement parler, Rapport n’a donc pas à figurer dans votre MCD.

Ce qu’est une table de base

Au niveau de votre SGBDR (au fait, en utilisez-vous un ? Si oui, lequel ?), vous mettez en œuvre des tables telles que Site, au moyen de l’instruction Create Table. Par exemple

____Create Table Site (Num_Site Integer, Nom_Site Char(64), ...) ;

Puis vous pouvez procéder à des requêtes d’interrogation (Select) ou de mise-à-jour (Insert, Update, Delete) :

Select Num_Site, Nom_Site, ...
From Site, ...
Where ...

Dans le processus de conceptualisation de la base de données, les tables Point_De_Vente, Site, Billet sont la conséquence relationnelle de votre MCD. Je les appellerai tables de base, car elles comportent un ensemble de valeurs regroupées en lignes, assimilables à des axiomes comme je l’ai suggéré.

Ce qu’est une vue

Le concept de vue fait partie du Modèle Relationnel de Données et il a été repris par les SGBDR.
Prenons l’exemple de Rapport : ça n’est jamais qu’une requête SQL que je nomme Rapport, à l’aide d’une instruction particulière « Create View » :

Code :

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

1
2
3
4
5
6
7
Create View Rapport as
 (
    Select ...
    From ...
    Where ...
);

En fait, l’utilisateur perçoit Rapport comme une table, puisqu’il peut la manipuler comme n’importe quelle table de base. Ainsi, pour obtenir les ventes par jour et par site, tous points de vente confondus, il lui suffit d’exploiter la « table » Rapport :

Code :

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

1
2
3
4
Select Date_Validation, Num_Site, Sum(Montant)
From Rapport
Group by Date_Validation, Num_Site, Montant ;

Conceptuellement parlant, on peut conclure qu’ au sens Merise du terme, il y a une entité-type Table, comportant deux sous-types :

- Table de base (définie par la commande Create Table).
- Table dérivée virtuelle (ou vue) (définie par la commande Create View).

La nature profonde d’une table peut être ignorée de l’utilisateur : il ne manipule que des tables.

On retiendra qu’une vue est bien virtuelle, et que sa valeur se déduit de la valeur des tables participant à sa définition (en notant qu'une vue peut faire référence directement ou indirectement à des tables de base ou à d’autres vues).

Ce qu’est un instantané (snapshot)

Si l’interrogation de la table (virtuelle) Rapport est consommatrice de ressources, dans la mesure où l’instruction Select ... From Rapport, ... est systématiquement exécutée par plusieurs personnes, vous pouvez matérialiser le résultat de la requête sous forme d’un instantané (snapshot), qui peut être automatiquement rafraîchi par le SGBDR selon une fréquence donnée. Par exemple :

Create Snapshot Rapport as
(
Select ...
From ...
Where ...
) Refresh every day;

Du point de vue du Modèle Relationnel de Données, l’entité-type Table comporte désormais trois sous-types :

- Table de base (définie par la commande Create Table).
- Table dérivée virtuelle (ou vue) (définie par la commande Create View).
- Table dérivée persistante (ou instantané) (définie par la commande Create Snapshot).

Si l’interrogation de la vue Rapport consomme trop de ressources, l’utilisation d’un instantané est sans doute ce qui vous convient le mieux.
Attention, chaque SGBDR ayant son propre patois, l’expression Create Snapshot est à traduire (Create Materialized View, Create Table ... materialized-query-definition, j’en passe et des meilleures, c'est la jungle).

A ce stade, vous ayant fourni quelques éléments de réflexion, je vous laisse à votre choix.

Concernant les dépendances fonctionnelles :

Je répondrai dès que je peux. Prenez la précaution d’avoir un tube d’aspirine à portée de main, si vous voulez en calculer la fermeture.

[fsmrel]

Bonsoir à nouveau Aurore,

Pendant que j'ai quelqu'un qui s'y connait est ce que vous connaissez un tutoriel sur les graphes de dépendances fonctionnelles, ou pouvez vous m'expliquer les grands principes car j'ai l'impression de refaire simplement le MCD avec quelques légères modifications...

Je ne connais pas particulièrement de tutoriel (ça viendra...) mais je peux déjà vous parler des grands principes.

Mettons à plat les propriétés des entités-types Site, Point_De_Vente, Billet et regroupons-les dans une entité-type unique et, pour faire bonne mesure, complétons avec l’entité-type Visiteur. Soit R la table relationnelle inférée de cette entité-type.

Je commencerai par changer de vocabulaire : par référence au Modèle Relationnel de Données, je parlerai de R-relation plutôt que de table (je devrais parler de relation mais j’utiliserai le terme R-relation pour éviter toute confusion avec la relation de Merise).

la R-relation R est la seule de la base de données : il est d’usage de la nommer relation universelle.

Elle a pour attributs :

Num_Site, Nom_Site, Adresse_Site, Date_Acces, Heure_Acces, Tarif_Site,
Num_Point_Vente, Nom_Point_Vente, Adresse_Point_Vente, Nom_Responsable,
Num_Serie_Billet, Date_Vente, Heure_Vente, Date_Expiration, Date_Validation (propriété que nous avons ajoutée pour compléter le MCD),
Num_Visiteur, Num_Passeport, Nom_Visiteur, Prenom_Visiteur, Pays_Visiteur.

On laissera tomber l’entité-type « dérivée » Rapport. On dénombre 20 attributs ci-dessus.

Je rappelle qu’une dépendance fonctionnelle (DF) est en gros une instruction de la forme A --> B où A et B sont deux sous-ensembles d’attributs de R, et répondant à la règle : pour une valeur de A, il y a au plus une valeur de B. Pour faire court, une dépendance fonctionnelle est une association de plusieurs à un.

Bon courage !

Sachant que l’ensemble des parties d’un ensemble E comporte 2^n sous-ensembles (compte tenu de l’ensemble vide), le nombre de dépendances fonctionnelles pour R a pour limite supérieure 2^2n. Ceci pour vous dire que la recherche des dépendances fonctionnelles nécessite d’apprécier 2^40 dépendances potentielles en ce qui vous concerne. Imaginez le travail quand la R-relation universelle comporte 20000 attributs...

De l’approche ascendante

Comment mettre en évidence l’ensemble des dépendances fonctionnelles de R ? La première solution consiste à prendre son courage à deux mains et pour tous les attributs de R se poser la question : Pour une valeur de A ai-je au plus une valeur de B ? Pour chaque couple {A, B}, ai-je au plus une valeur de C ? Pour chaque triplet {A, B, C} ai-je au plus une valeur de D ? Etc.
Quelques jours plus tard, vous aurez découvert les DF suivantes :

____Num_Site --> Nom_Site
____Num_Site --> Adresse_Site
____Num_Site --> Date_Acces
____Num_Site --> Heure_Acces
____Num_Site --> Tarif_Site

ce que l’on peut encore écrire :

____Num_Site --> {Nom_Site, Adresse_Site, Date_Acces, Heure_Acces, Tarif_Site}

mais vous découvrirez aussi :

____Nom_Site --> {Num_Site, Adresse_Site, Date_Acces, Heure_Acces, Tarif_Site}
____Adresse_Site --> {Num_Site, Nom_Site, Date_Acces, Heure_Acces, Tarif_Site}

Sans oublier

____Num_Serie_Billet --> {Date_Vente, Heure_Vente, Date_Expiration, Date_Validation}

et, fort intéressant

____Num_Serie_Billet --> {Num_Site, Nom_Site, Adresse_Site, Date_Acces, Heure_Acces, Tarif_Site}
____Num_Serie_Billet --> {Num_Point_Vente, Nom_Point_Vente, Adresse_Point_Vente, Nom_Responsable}

etc.

Mais je sens que l’attention commence à se relâcher. Si vous continuez ainsi, votre chef de projet va carrément ronfler.

N’empêche qu’à ce petit jeu vous produisez des paquets de dépendances fonctionnelles qui vont permettre de construire des schémas de R-relations, la partie à gauche de la flèche portant le doux nom de déterminant et celui de droite le non moins poétique nom de déterminé, sachant qu’un déterminant devient clé « candidate » de sa R-relation.

Bref, en partant d’une R-relation universelle, on est à même par les dépendances fonctionnelles que l’on a su y repérer, casser cette R-relation en R-relations plus petites, telles que par jointure de celles-ci ont soit à même de recomposer très exactement la R-relation universelle.

L’exercice que j’ai présenté de manière très informelle finit à la longue par provoquer des nausées. Dommage, car bien maîtrisé il permet de modéliser de façon mécanique. Deux difficultés quand même : être sûr de ne pas avoir oublié de DF en route et être limité par le temps.

De l’approche descendante

Dans l’exercice qui précède, on est parti du ras des pâquerettes pour grimper vers les cimes et produire un beau modèle qui en définitive constituera le modèle conceptuel des données (MCD). En réalité, sortie du modeste cas d'étude, l’approche est utopique.

Il est de loin préférable d’éviter la R-relation universelle et de construire des R-relations plus petites, beaucoup plus faciles à maîtriser : c’est ce que l’on fait quand on construit un MCD : il faut s’appuyer sur une approche sémantique, et procéder comme vous l’avez fait : savoir distinguer des concepts forts, comme le Site, le Point de vente et le Visiteur. Se poser des questions sur la chose Billet : c’est-y du lard ou du cochon ? autrement dit est-ce une entité plus faible que les autres, une propriété multivaluée du visiteur ou du point de vente ou que sais-je, ou encore une propriété multivaluée partagée par le point de vente, le site et le visiteur, etc. ?

Quoi qu’il en soit, il est plus facile de reprendre le travail de recherche des dépendances fonctionnelles sur des R-relations plus petites que la R-relations universelle : vous remplacez un produit de problèmes par la somme de ces problèmes (et encore...)

Bref, vous descendez cette fois-ci des hauteurs, des entités-types, pour étudier plus en profondeur les attributs qui les composent. On peut alors parler d’approche descendante, beaucoup plus réaliste que l'autre approche.

De l’art du yoyo

Il est clair que ces deux approches sont complémentaires, sachant que l’approche descendante précède normalement sa cousine. Personnellement je pratique le yoyo, c’es-à-dire que je pratique les deux approches de façon alternative, jusqu’à ce que j'estime devoir arrêter.

Du graphe des DF

Ce graphe est fourni au niveau de chaque entité-type et des relations-types (attention, il ne s’agit pas des R-relations du Modèle relationnel !) Prenons le cas de l’entité-type Billet.
Son graphe des DF est défini par les DF dont l’identifiant de l’entité-type constitue le déterminant :

____Num_Serie_Billet --> {Date_Vente, Heure_Vente, Date_Expiration, Date_Validation}

complété par les DF inférées des cardinalités maximales 1 liant Billet à Site, Point de vente et Visiteur :

____Num_Serie_Billet --> {Num_Site, Nom_Site, Adresse_Site, Date_Acces, Heure_Acces, Tarif_Site}
____Num_Serie_Billet --> {Num_Point_Vente, Nom_Point_Vente, Adresse_Point_Vente, Nom_Responsable}
____Num_Serie_Billet --> {Num_Visiteur, Num_Passeport, Nom_Visiteur, Prenom_Visiteur, Pays_Visiteur}

tout en essayant d’en savoir plus, par exemple existe-t-il des DF plus subtiles telles que l’identifiant de l’entité-type constitue le déterminé :

____{Num_Site, Num_Point_Vente, Num_Visiteur} --> Num_Serie_Billet

Et après ?

Maintenant, pour étudier vraiment les dépendances fonctionnelles, nous devons commencer par le commencement, c'est-à-dire l’étude des axiomes d’Armstrong et des règles d’inférence qui en découlent, pour aboutir à la fermeture des dépendances, à la couverture minimale d’icelles et enfin à l’étude de la normalisation.

Je suppose que le graphe que l’on vous demande est une préparation à vérification de la 3e forme normale. Supposons en effet que dans l’entité-type Num_Serie_Billet se soit glissée la propriété Nom_Site. Étant donné que l’on a les DF :

____Num_Serie_Billet --> {Num_Site, Nom_Site}
____Num_Site --> Nom_Site

On sait alors que la 3e forme normale ne sera pas respectée.

Notons que sans la connaissance et l’application des axiomes d’Armstrong, nous ne savons pas réellement construire un graphe de DF.

Mais ceci sera pour une autre fois, quand nous trouverons le temps nécessaire.

Si vous trouvez des coquilles et autres copier/coller malheureux, merci de me le faire savoir,

Fsmrel