Le dictionnaire des données contient toutes les données nécessaires, relevées dans l'analyse de l'organisation (dans l'analyse du sujet). Il est organisé sous forme d'un tableau de cinq colonnes :

Exemple :

N° Donnée Code Donnée Description Type et longueur Observation 1 numFou Numéro du fournisseur Numérique 5 Numéro identifiant, à incrément automatique 2 nomFou Raison sociale du fournisseur Alphanumérique 30       Chiffre d'affaire global du fournisseur Numérique 15,5 Donnée calculée, somme des montants des commandes …

Les données relevées sont les données explicites (n°, description, date, ...) qui font parties des concepts énoncés dans le sujet.

Les concepts n'apparaissent en aucun cas dans le DD (qui c'est DéDé ?). si vous voulez, notez les dans une liste des concepts.

Les données calculées (totaux, prixTTC si on dispose du prix HT et du taux de TVA, …) ne sont pas retenues.
Retour

Cette liste et ce graphe font apparaître les dépendances fonctionnelles entre les données.
Une dépendance fonctionnelle relie deux données.
Lorsque la connaissance de la première donnée détermine l'autre de façon unique.

Exemples :

LDF NumFou -> nomFou je connais un numéro de fournisseur, je peux déterminer son nom sans ambiguïté CodeArticle -> descriptionArticle connaissant le code d'un article, je retrouve sa description CodeArticle, n°Commande -> quantitéArticle connaissant le code d'un article et le n° de commande, je retrouve la quantité commandée de cet article dans cette commande

Attention, une dépendance fonctionnelle n'est pas réversible.

LDF NumFou -> nomFou Je ne connais pas le numéro du fournisseur, son nom ne permet pas de déterminer son numéro de façon unique, il pourrait y avoir des homonymes (même nom mais autre adresse) n°Employé -> nomEmployé Connaissant le nom, je ne peux pas retrouver un et un seul n° (homonymes)

A partir de cette liste, on crée un graphe reproduisant les DF.
Chaque donnée n'apparaît qu'une seule fois et les concepts génériques ne sont par (encore) indiqués.

GDF

Retour

L'abus de langage identifie ce schéma (SCD) au modèle conceptuel des données (MCD) duquel il fait partie. Appelé aussi "modèle" entités/associations (MEA), décrit le quoi, quelles sont les données qui sont gérées.

Le schéma contient des Entités et des Associations. Les entités sont représentées par des rectangles, les associations par des ovales ou des ronds (ou des rectangles aux coins arrondis). Une valeur de l'entité ou de la relation est appelée occurrence. Les entités sont reliées aux associations par des traits représentant les dépendances fonctionnelles. Chaque dépendance (trait) possède un code indiquant le nombre d'occurrences de l'association qui correspondent à une occurrence de l'entité. Il y a deux indications : le minimum (0 ou 1) et le maximum (0, 1 ou n). Note : une entité ne peut pas être reliée à une autre entité, il y a toujours une association entre les deux. Idem pour les associations. Elles sont divisées en deux espaces : l'espace supérieur contient le nom de l'entité ou de l'association, l'espace inférieur peu contenir des propriétés (entités : mini 1) Chaque entité possède (au moins) une propriété soulignée. Cette propriété particulière identifie de façon unique chaque occurrence de la propriété : l'identifiant. Les associations n'ont pas d'identifiant mais peuvent être porteuses de propriétés.

Retour

Le MOD défini qui fait quoi et où.

Le schéma principal du MOD est un MCD enrichi par la limitation d'accès aux entités et aux propriétés pour chaque acteur (ou groupe d') du système d'information. En général, une vue limitée aux entités du modèle concernées par l'acteur ou par le domaine d'étude. Les types d'accès sont représentés dans un cadre ajouté aux associations et aux entités, contenant l'acronyme CIMS : création, interrogation, modification, suppression Selon le cas, seul les signes nécessaires (ou autorisés) sont indiqués. De même, on sera amené à supprimer des propriétés auxquelles l'acteur n'aura pas accès. Note : Dans nos études, on passera souvent du MCD au MR sans faire de MOD.

Retour

Appelé abusivement Modèle (MR et MLD)
Le SR contient des relations.
Chaque relation est composée d'attributs (au moins 1) dont l'un (ou groupe minimum d'attribut) identifie de façon unique chaque occurrence de la relation : la clé primaire.
Si un autre attribut ou groupe d'attribut permet de faire la même chose, il est appelé clé candidate.
Si un attribut est clé primaire dans une autre relation, il s'appelle clé étrangère.

Il existe trois formalismes pour représenter le modèle logique de données et le modèle relationnel.

a) forme graphique : schéma logique de données (SLD)

(produit, ici, par un logiciel d'analyse ou atelier de génie logiciel : AGL)

Les associations et entités sont transformées en relations représentées par des rectangles. Les clés primaires des associations sont indiquées en clair, elles sont héritées des identifiants des entités liées à l'association d'origine. Les clés primaires des relations issues des entités sont les identfiants de celles-ci. Dans certains cas, les AGL indiquent en outre l'égalité des clés de part et d'autre des liens, afin d'identifier clairement quelles sont les attributs des clés qui se correspondent. Le sens de la flèche indique quelle relation (ici Sponsorise) référence quelle attribut clé dans la relation visée. Note : la forme graphique est peu utilisée du fait de sa ressemblance avec le MCD et de la surface qu'il occupe. Cependant, certains logiciels de modélisation le construisent quasiment automatiquement.

b) forme textuelle courante

Les relations sont écrite en toute lettre, suivies de la liste des attributs.
La clé primaire est soulignée (en cas de groupe d'attributs, il sont tous soulignés d'un seul trait !).
Les clés étrangères sont suivies (ou précédées) d'un #.


Exemple :

Cette forme (implicite) est encore très courante, mais en voie de disparition dans l'Education Nationale, au profit de la forme explicite suivante.

c) forme textuelle explicite

Idem ci-dessus, sans soulignement ni caractère spéciaux.
On ajoute sous la relation :

• La description de la clé primaire,
• La liste des clés étrangères en indiquant, pour chacune :
  attributClé référence attributCléPrimaire dans RelationRéférencée
• La liste des contraintes sur les attributs :
  ne doit pas être nul, compris entre 0 et 10, etc. …

Relation(attribut1, attribut2, attribut3)
Clé Primaire : attribut1
Clé Etrangère : attribut3 référence attributCléPrimaireRéférencé dans RelationRéférencée attribut2 peut prendre les valeurs de 0 à 10
Exemple :

Sauf oubli de ma part, j'utiliserai cette forme dans la suite des documents.
Retour

Le modèle physique de données contient des tables.
Chaque table est composée de champs.
L'ensemble des lignes (valeurs) de la table est appelée extension de la table
Une ligne de la table est nommée tuple.
Les notions de clés sont conservées.

noFour (la clé primaire) raisonSociale Adresse ... (Commentaires) 123 Arobourg S.A. ici ... 124 Arobourg S.A. ici ... un tuple 125 Arobourg S.A. ici ...

La représentation est textuelle :
Cette représentation n'est pas sans rappeler la forme explicite du schéma relationnel, la notion de type (entier, réel, alphanumérique, date, …) et la longueur en plus.
Les contraintes sont du type :

• Clé primaire (si un seul champ constitue la clé primaire),
• Non nul,
• Référence attributRéférencé dans tableRéférencée (clé étrangère),
• Valeurs( 1 - 5) ou valeurs( 1, 5) (respectivement de 1 à 5 puis 1 ou 5), …

Exemple :

Il existe une forme graphique utilisée abondamant par un certain logiciel d'une suite bureautique bien connue.
Cependant, celle-ci a un défaut majeur, elle inverse les cardinalités et ne montre que la cardinalité maxi explicitement.
(par ailleurs, le logiciel est la propriété d'une marque qui frise le monopole ... mais c'est un autre débat.)
Retour

modèle "colonnes" "lignes" Informations MCD Quoi entité associations propriétés Occurrences MOD Qui fait quoi et où Accès, droits MR Comment relations Attributs Tuples Contraintes MPD Aspect technique tables Champs (colonnes) Enregistrements Types

Retour

8.1 Enoncé

Le club de plongée ACAL désire gérer la location de matériel.

Le matériel peut être des bouteilles, des détendeurs, des gilets de stabilisation, des combinaisons, …
Chaque matériel est identifié individuellement par un numéro d'inventaire et possède un numéro de série constructeur.

Les plongeurs sont gérés par le responsable des inscription qui enregistre leur nom, prénom, n° de licence, adresse complète, n° de téléphone.

Un matériel peut être emprunté ou non. On ne gardera pas l'historique des emprunts.

Chaque type de matériel est loué selon un prix spécifique au type.
Ainsi, une bouteille, quelle que soit son numéro d'inventaire sera louée au même prix que n'importe quelle autre.

8.2 Travail à faire

• Relever les données et construire le dictionnaire des données
• Etablir le graphe des dépendances fonctionnelles
• Construire le schéma conceptuel de données (SCD) puis le Schéma relationnel (SR, textuel courant).
• Détailler les tables du modèle physique.

Retour