Modèle conceptuel des données - Free
3 Le graphe des dépendances fonctionnelle (S.A.T.) ... préciser la sémantique
utilisée dans la modélisation pour le N° de sécurité sociale le nom de famille
peut ..... pourrait être [0,n] il n'y a pas d'hypothèses explicite à ce propos dans le
sujet.
part of the document
ite uniquement de la démarche fonctionnelle.
TM \o "1-3" 1 Dépendance Fonctionnelle : RENVOIPAGE _Toc98169330 \h 2
1.1 Propriété : RENVOIPAGE _Toc98169331 \h 2
1.2 Définition de la dépendance fonctionnelle : RENVOIPAGE _Toc98169332 \h 2
1.3 Exemples de dépendances fonctionnelles RENVOIPAGE _Toc98169333 \h 3
2 Extensions de la notion de dépendance fonctionnelle RENVOIPAGE _Toc98169334 \h 4
2.1 Dépendance fonctionnelle partielle : RENVOIPAGE _Toc98169335 \h 4
2.2 Dépendances composées RENVOIPAGE _Toc98169336 \h 5
2.3 Extension de la notion de dépendance composée RENVOIPAGE _Toc98169337 \h 6
3 Le graphe des dépendances fonctionnelle (S.A.T.) RENVOIPAGE _Toc98169338 \h 7
4 Les règles de transformation de la S.A.T. au M.C.D. RENVOIPAGE _Toc98169339 \h 7
5 Exercices : "Bibliothèque" et "uvres d'art" RENVOIPAGE _Toc98169340 \h 8
5.1 Bibliothèque RENVOIPAGE _Toc98169341 \h 8
5.1.1 Règles de gestion : RENVOIPAGE _Toc98169342 \h 8
5.1.2 Dictionnaire des données RENVOIPAGE _Toc98169343 \h 8
5.2 uvres dArt RENVOIPAGE _Toc98169344 \h 9
5.2.1 Les règles de gestion sont les suivantes : RENVOIPAGE _Toc98169345 \h 9
5.2.2 Dictionnaire des données : RENVOIPAGE _Toc98169346 \h 9
5.3 Correction des exercices RENVOIPAGE _Toc98169347 \h 10
5.3.1 Correction S.A.T. Bibliothèque RENVOIPAGE _Toc98169348 \h 10
5.3.2 Correction de la S.A.T. : uvres dArt RENVOIPAGE _Toc98169349 \h 11
5.3.3 Préparation des S.A.T. (règles 1 et 2) RENVOIPAGE _Toc98169350 \h 12
5.3.4 MCD (règles 3 à 7) Bibliothèque RENVOIPAGE _Toc98169351 \h 13
5.3.5 MCD (règles 3 à 7) "uvre d'art" RENVOIPAGE _Toc98169352 \h 14
La seule notion à bien maîtriser est la dépendance fonctionnelle. Elle nécessite en préalable la définition de propriété et occurrence.
Dépendance Fonctionnelle :
Propriété :
Ensemble d'informations de même type et de même sémantique.
Exemple : DateFacture et DateNaissance ont le même type mais pas la même sémantique.
On parle d'occurrence d'une propriété comme l'on parle d'un élément particulier d'un ensemble.
Définition de la dépendance fonctionnelle :
On dit qu'une propriété B dépend fonctionnellement d'une propriété A (on note A(B) si pour toute occurrence de A il existe une et une seule occurrence de B
Bien entendu le lien entre les occurrences de A et celles de B correspond à une sémantique particulière (généralement triviale par rapport au domaine d'étude)
Exemples de dépendances fonctionnelles
Cas 11 : Tous les "Dubois" n'ont pas le même numéro de sécurité sociale (donc il existe au moins un Nom pour lequel on trouvera plusieurs occurrences de N°SS) la dépendance fonctionnelle n'est donc pas vraie.
Cas 12 et Cas 13 : là il faut préciser la sémantique utilisée dans la modélisation pour le N° de sécurité sociale le nom de famille peut avoir deux significations : nom de l'assuré ou nom du bénéficiaire des soins.
Dans le Cas 12 on exprime avec une dépendance fonctionnelle vraie que pour un N°SS il n'existe qu'un seul nom de famille d'assuré.
Dans le Cas 13 la dépendance fonctionnelle est fausse puisqu'une personne peut bénéficier (sous certaines conditions qui débordent du domaine d'étude) de l'assurance sociale d'une autre personne. Donc à partir d'un N° de sécurité sociales on peut obtenir plusieurs noms de famille (notamment pour les enfants ne portant pas le nom du parent par lequel ils sont couverts).
Cas 21 et Cas 22 : Pour qu'à chaque occurrence de Nom corresponde exactement un numéro de téléphone il faut poser sur le domaine certaines hypothèses. Si l'on décide de ne mémoriser qu'un seul n° de téléphone par personne (éliminer le problème Portable, domicile, bureau) et que d'autre part on ne veut mémoriser qu'un petit nombre de personne (de façon à ne jamais rencontrer deux fois le même nom) on peut envisager une dépendance fonctionnelle, c'est le cas 21. Par contre d'une manière général il est assez fréquent de disposer dans le système de mémoire de plusieurs personne distinctes disposant du même nom de famille alors la dépendance fonctionnelle est bien sur fausse, c'est le Cas 22.
Cas 23 et Cas 24 : C'est le même genre de problématique que pour les Cas 12 et Cas 13. Pour un opérateur de téléphonie (SFR, Bouygues, Orange - ex Itineris ou tous les autres), à partir d'un N° de téléphone on ne s'intéresse qu'à une seule personne, celle qui va payer l'abonnement et les communications. Par contre du point de vue communication on si l'on s'intéresse au nom du correspondant avec lequel il est envisageable d'établir une communication via le numéro de téléphone, il existe assez souvent (surtout sur les téléphones fixe) la possibilité de trouver plusieurs personnes de noms de famille distinct à l'autre bout du fil.
Extensions de la notion de dépendance fonctionnelle
La dépendance fonctionnelle est le seul concept nécessaire à la structuration de données toutefois, au sens strict, elle n'est pas suffisante pour représenter fidèlement les structures de données il faut au préalable étendre ou affiner ses possibilités.
Dépendance fonctionnelle partielle :
Pour toute occurrence de A il existe au plus une occurrence de B.
Exemple :
Un assuré social a obligatoirement une date de Naissance et il aura au plus (nous lui souhaitons le plus tard possible) une seule date de décès.
Dépendances composées
Parfois une propriété ne peut pas à elle seule identifier une autre propriété (la dépendance fonctionnelle à bien entendu comme utilité l'identification univoque d'information(s) à partir d'information fournie(s)).
Soit X le produit cartésien des propriétés A et B s'il existe une dépendance fonctionnelle partielle entre X et la propriété C on sait qu'il suffira de fournir une valeur de A et une de B pour obtenir au plus une information C.
Exemple :
Dans cet exemple on ne s'intéresse pas au titulaire du contrat, on s'intéresse simplement aux personnes enregistrées comme conducteurs occasionnel ainsi qu'à la fréquence d'utilisation prévue.
Certains couples "Immatriculation / N°Permis" donneront une fréquence et une seule d'autre bien sur seront sans objet.
Un N° de permis pourra donc avoir une fréquence associé à chaque véhicule pour lequel il est enregistré et une automobile sera éventuellement reliée à plusieurs conducteurs référencés.
Extension de la notion de dépendance composée
Ci-dessous quelques extension de la dépendance fonctionnelle composée
Il peut être nécessaire de fournir 3, 4 (ou plus) informations pour en identifier une autre. (Dans l'optique GEA 1ère année seule 3 pour 1 est utile)
Il peut être utile d'associer des information entre elles sans que pour cela elle ne fournisse une valeur lors de leur association le simple fait qu'elles soient associée fournissant déjà une information (cf. l'association entre AUTEUR et LIVRE dans l'exemple bibliothèque).
Lorsqu'un qu'un couple d'information (ou un triplet etc.) fournit plusieurs informations deux représentations sont alors à envisager.
Soit un couple (a, b) des propriétés A et B fourni aucune information ou une information c de la propriété C et une information d de la propriété D il faut utilisé la représentation "Simultanées".
Si par contre pour un couple (a, b) on obtient aucune information une information c (sans d) ou une information d (sans c) ou une information c et une information d, il faut alors utiliser la représentation "Indépendante".
Le graphe des dépendances fonctionnelle (S.A.T.)
Il s'agit d'un brouillon en vu de formaliser la structure de données nécessaire à une activité. Après avoir relevé les propriétés nécessaires au système, il faut essayer de les relier entre elles par des dépendances fonctionnelle. Le graphe des dépendances fonctionnelles une fois terminé s'appelle "Structure d'Accès Théorique" ce nom est intéressant car il permet de se rappeler que l'étude de la structure ne représente que l'accès à l'information pas la façon dont cette information est "fabriquée"
Les règles de transformation de la S.A.T. au M.C.D.
Transformation d'une S.A.T. en MCD 7 règles à appliquer
Voici les règles qui permettent de transformer une SAT en MCD sans aucune réflexion.
Souligner toutes les propriété "sources" de dépendance fonctionnelle y compris celle qui participent à une dépendance fonctionnelle composée
Regrouper chaque "source" avec toutes ses "cibles" à deux conditions toutefois :
La cible n'est pas elle même une source
La cible ne dépend que de la source (donc les propriété identifiées par des dépendances composées ne font pas partie de ces groupes).
Les groupes deviennent des entités
Les dépendances fonctionnelles entre groupes deviennent des relation 1 à n
Les dépendances composées donne lieu à la création de relation n à n
Donner des noms aux entités puis aux relations
Appliquer les cardinalités manquantes
Les cardinalités sont disposées entre les entités et les relations elles indiquent combien de fois une occurrence de l'entité intervient dans la relation au minimum puis au maximum.
Les cardinalités fréquente sont 0,1 (dépendance partielle) 1,1 (dépendance fonctionnelle standard) 0,n et 1,n (cardinalités "retour" de df ou cardinalité des relations provenant des dépendances fonctionnelles composées).
Attention si vous êtes familiarisé avec les notations UML les multiplicités UML sont disposées en sens inverse des cardinalités qui se trouve à coté de la classe sur l'association indique le nombre d'occurrences de l'autre classe.
Exercices : "Bibliothèque" et "uvres d'art"
Les deux exercices suivants sont à étudier par graphe des dépendances fonctionnelles
Bibliothèque
On désire obtenir le modèle conceptuel des données (MCD) d'une bibliothèque. Pour cela le bibliothécaire nous a indiqué quelles étaient les propriétés dont il avait besoin et quelles sont les règles qu'il entend suivre pour la gestion de sa bibliothèque.
Règles de gestion :
Un auteur peut être référencé dans la bibliothèque même si l'on ne possède aucun livre de cet auteur.
Un livre est toujours écrit par un auteur mais il a pu être écrit par plusieurs.
Certains auteurs peuvent être également des lecteurs mais il seront considérés alors comme deux objet distincts.
Un lecteur existe dés lors qu'il s'est inscrit à la bibliothèque, mais il n'emprunte pas forcément des livres.
Lorsque un livre est emprunté on mémorise l'emprunt avec une date de retour "Nulle" lorsque le livre est rapporté on remplace cette valeur "Nulle" par la date de retour effective.
Tous les ans on efface tous les emprunts qui ont été rendu mais on conserve le nombre de livre emprunté au total par un lecteur.
A n'importe quel moment on peut interroger le système pour savoir combien de livres a emprunté un lecteur depuis son premier emprunt et connaître sa moyenne d'emprunt par mois.
Un même lecteur doit pouvoir au cours de l'année emprunter plusieurs fois le même livre (bien sur à des dates différentes)
Dictionnaire des données
NomSignificationREFRéférence d'un livreDPARDate de parution d'un livre.TITRETitre d'un livreCAUTCode d'un auteurNAUTNom d'un auteurPAUTPrénom d'un auteurCLECCode d'un lecteurNLECNom d'un lecteurPLECPrénom d'un lecteurDEMPDate de début d'un empruntDRETDate de retour d'un livreNBEMPNombre d'emprunts total d'un lecteur à la fin d'une année.NBEMPMNombre d'emprunts total d'un lecteur à un moment donnéMOYENPMoyenne des emprunts effectués par un lecteur depuis son premier empruntDPREEMPDate de Premier emprunt d'un lecteur.
uvres dArt
On s'intéresse à la gestion des uvres d'art d'un musée.
Les règles de gestion sont les suivantes :
Une uvre d'art est réalisée par un artiste.
L'ouvre provient soit d'un donateur, soit d'un vendeur particulier, soit d'emprunts auprès d'autres musées.
Les uvres achetées peuvent être revendues par le musée, elles peuvent donc être rachetées plusieurs fois. Par contre, les uvres acquises par donation ne peuvent être revendues.
Les uvres sont exposées une fois pour toutes à un même emplacement qui dépend toujours lui-même d'une même salle.
Chaque salle ne regroupe que des uvres d'une même école. Par contre, une école n'est pas forcément regroupée dans une seule salle.
Un thème est affecté à chaque salle.
Un artiste a pu appartenir à plusieurs écoles mais une uvre ne se rattache qu'à une seule école.
Les uvres pouvant être empruntées à d'autres musées, on désire conserver la trace de tous les emprunts successifs que l'on a pu réaliser.
Plusieurs textes de présentation sont prévus, l'un caractérise l'uvre, un autre présente l'école et un troisième est présent dans toutes les salles qui traitent de l'école.
Dictionnaire des données :
PROPRIETESDESIGNATIONREFORéférence de l'uvreNOMONom de l'uvreNOMANom de l'artisteCODACode de l'artisteDATNAISDate de naissance de l'artisteDATDECDate éventuelle de décès de l'artisteNOM_VENDNom du vendeur de l'uvreDATE_VENTEDate de vente de l'uvreNOM_DONNom du donateur de l'uvreDATE_DONDate du donMUSEEMusée prêteur VILLE_MUSEEVille du musée prêteur DATEPRETDate du prêt de l'uvre par un muséeTEXTOEUVRETexte accompagnant l'uvreTEXTESALTexte accompagnant les uvres d'une même salleTEXTECOLTexte accompagnant chaque école AN_REALAnnée de réalisation de l'uvreSALLENuméro de la salle d'exposition de notre muséeEMPEmplacement de l'uvreTHEME_SALLEThème de la salle
Correction des exercices
Correction S.A.T. Bibliothèque
La dépendance entre CLEC et DPREEMP est partielle puisque le lecteur n'emprunte pas forcément donc il n'a peut être pas de date de premier emprunt. (on pourrait bien sur poser des df partielles entre CLEC et NBEMP, NBEMPM, et MOYEMP) toutefois comme ces valeurs sont des nombre la valeur 0 fera l'affaire (la notion de 0 n'existant pas pour les dates) de toute façon la notion de dépendance partielle n'est pas essentielle.
Les étudiants peuvent envisager une df de TITRE vers REF il faut leur expliquer que même dans le cas où sur un échantillon restreint la dépendance entre un intitulé et son code peut être vraie elle a toutes les chance de disparaître ici par exemple dés lors que la bibliothèque fera l'acquisition d'une autre édition de la même uvre cette dépendance deviendrait caduque tandis que celle de la référence vers le titre restera valide (c'est d'ailleurs pour çà que l'on trouve des codes et numéros partout).
Pour formaliser l'emprunt à premier vue il suffit d'établir une df composée (REF, CLEC) vers DEMP toutefois si comme dans la règle 8 le lecteur emprunte plusieurs fois le même livre, il y aura donc pour le même couple (REF, CLEC) plusieurs DEMP. D'où la solution représentée.
La relation entre CAUT et REF permet d'associé un livre à tous ses auteurs et bien sur un auteur à tous ses livre.
Correction de la S.A.T. : uvres dArt
L'artiste n'est pas forcément décédé.
L'uvre peut provenir d'un don et dans ce cas elle ne peut pas être vendue donc elle ne pourra être reçue par don qu'une seule fois.
Le prêt ou la vente peuvent avoir lieu plusieurs fois éventuellement avec les mêmes Musée ou vendeur donc il faut identifié les musées et vendeur par les couples respectifs (REFO, DATEPRET) et (REFO, DATE_VENTE)
On notera la double dépendance entre REFO et EMP si l'uvre n'a qu'un seul emplacement il va de soit que l'emplacement ne peut recevoir qu'une seule uvre (mais il peut rester vide).
Préparation des S.A.T. (règles 1 et 2)
MCD (règles 3 à 7) Bibliothèque
règles de transformation 3 et 5 dans cet exemple la règle 4 n'est pas utilisé puisqu'il n'y a pas de dépendance entre entité
On notera la présence d'une partie des cardinalités celle qui ne demande aucune réflexion.
Règles de transformation 6 et 7 les complément sont pris dans l'énoncé et la compréhension générale du système.
MCD (règles 3 à 7) "uvre d'art"
On notera la présence des Cardinalité 1,1 ou 0,1 provenant automatiquement des dépendances fonctionnelles. Bien entendu en face on trouve les cardinalités " ,n" puisque sinon il y aurait une dépendance fonctionnelle.
On notera que les relations en provenance de "df" ne sont pas coupées par un trait (en effet elles ne peuvent jamais porter de propriété).
La flèche entre la relation et l'entité qui contient MUSEE signifie que si la propriété MUSEE n'était pas identificateur de l'entité elle serait portée par la relation.
Les cardinalités : Salle/Situer, Artiste/Réaliser, Temps1/Vendre et Temps2/Preter pourrait être [0,n] il n'y a pas d'hypothèses explicite à ce propos dans le sujet.
Par contre : uvre/Prêter et uvre/Vendre sont obligatoirement à [0,n]
NB : il n'y a pas de cardinalité sur la flèche, puisque s'il existe une occurrence de la relation Prêter elle "contient" obligatoirement une et une seule occurrence de l'entité Musée.
MCD par les dépendances fonctionnelles page PAGE 1/ NBPAGES 15
