Petit guide d'analyse des données à l'aide de la méthode MERISE


précédentsommairesuivant

2. Du vocabulaire et comment on le représente graphiquement

Le modèle entité-association est constitué de deux éléments de base :

  • Les entités, qui sont des regroupements d'informations, et possèdent des attributs (caractéristiques)
  • Les associations qui sont les liens logiques entre les entités (et sont quantifiées par des cardinalités)

2.1. Les entités (des ensembles)

Ce sont des regroupements d'informations. Les informations contenues dans les entités (informations que l'on appelle "attributs") doivent être des informations variables, mais communes à une même classe d'objets.

Par exemple, si l'on considère l'entité "être humain" les informations communes aux être humains peuvent être :

  • le nom
  • le ou les prénoms
  • la date de naissance
  • le lieu de naissance
  • le sexe
  • l'adresse

etc...

On considère souvent qu'il s'agit de "classes" d'entités.

Une entité donnée peut elle-même être constituée de sous-classes.
Par exemple, un être humain donné peut habiter au même endroit qu'un autre (si deux personnes vivent sous le même toit parce qu'ils sont mariés). Dans ce cas, l'adresse constitue une sous-classe de l'entité "être humain", c'est à dire une nouvelle entité à part entière.

D'un autre côté, il arrive souvent que plusieurs personnes résident au même endroit, sans même se connaître (cas d'un immeuble collectif par exemple). Dans ce cas on peut considérer l'adresse, comme une entité et la décrire de la manière suivante :

  • Pays
  • Région
  • Département
  • Rue

etc...

On schématise une entité par un rectangle.

Exemple :

Image non disponible

2.2. Les attributs (des caractéristiques)

Les attributs sont les caractéristiques décrivant les entités et doivent être représentés comme une liste de mots, la plus simple possible, dans le cadre de l'entité correspondante. On devra préciser le type des données attendues pour chaque attribut.

Exemple :

Image non disponible

Les types associés aux attributs sont les suivants :

D Date
Annn Caractères de longueur nnn
BL Booléen (vrai / faux)
T Temps
DT Date Temps
N Nombre
S (Smallint) entier court
S (Integer) entier

etc...

2.3. Les associations (ou relations)

Ce sont des liaisons logiques entre les entités.
Elles peuvent être de nature factuelle, ou de nature dynamique.
Par exemple, une personne peut acheter un objet (action d'acheter), mais si l'on considère qu'une personne est propriétaire d'un objet, alors l'association entre l'objet et cette personne est purement factuelle.

Les associations se représentent dans une ellipse (ou un rectangle aux extrémités rondes), reliée par des traits aux entités qu'elles lient logiquement.

Exemple :

Image non disponible

2.4. Les cardinalités (ou "combien" ?)

Les cardinalités, au sens arithmétique du terme, permettent de dénombrer les éléments de l'entité d'arrivée en relation avec un élément de l'entité de départ, et vice versa.

Exemple :

Considérons le cas de l'association "habite" et les deux entités "être humain" et "appartement" du schéma précédent, les cardinalités minimales et maximales sont les suivantes :

  • sens "être humain" vers "appartement" : 1 (minimum) et 1 (maximum)
  • sens "appartement" vers "être humain" : 0 (minimum) et n (maximum)

Ce qui signifie que dans cette modélisation un être humain réside dans un appartement et un seul à la fois, mais qu'un appartement peut se trouver vide ou être pourvu de plusieurs résidents.
Bien entendu tout être humain ne réside pas forcément dans un appartement, ce peut être dans une maison, à l'hôtel ou à la belle étoile (SDF…). Mais il convient de se concentrer sur ce que l'on doit modéliser et non sur l'univers entier.
En outre nous avons convenu qu'un même être humain ne pouvait résider dans plusieurs appartements à la fois (notion de « résidence principale » par exemple).

On note les cardinalités de chaque côté de l'association, sur les traits faisant la liaison entre l'association et l'entité.

Image non disponible

Dès cet instant, on peut en déduire le type de relation parmi les types suivants : : 1/1, 1/n ou n/1 ou encore n/m.
Ici c'est une relation de type 1,n.
Pour déduire le type d'une relation, il suffit de récupérer les cardinalités maximales des deux côtés de l'association, sans tenir compte de leur valeur exacte.

On peut s'y aider à l'aide des diagrammes de Wen et des notions de mathématiques ensemblistes, bien connus de ceux qui ont pratiqués les maths modernes dès leur plus jeune âge...
Entrent alors en jeu les notions de bijection, interjection, surjection...

Image non disponible

Attention ! Des relations différentes entre mêmes entités peuvent posséder des cardinalités différentes; c'est même souvent le cas.

Exemple :

Image non disponible

La relation « loue » est de type n:m.
La relation « réside » est de type 1:n.
La relation « possède » est de type n:m.

2.5. Clef d'une entité (la base de la relation)

C'est un attribut (ou un ensemble d'attributs) qui permet (tent) de distinguer un élément de l'entité de manière unique et sans aucune ambiguïté par rapport à l'ensemble des autres éléments, et à l'univers de tous les éléments qui peuvent entrer un jour ou l'autre dans cette entité.

Par exemple la clef de l'entité "être humain" pourrait être le nom. Mais comme le cas d'homonymie est assez fréquent, surtout lorsque l'on manipule des fichiers volumineux, alors cet attribut constitue une mauvaise clef en général.

En revanche, il n'est pas impossible que la clef d'une entité soit composée de plusieurs attributs. Par exemple, la clef de l'entité "être humain" pourrait être le nom et le prénom. Cependant il n'est toujours pas impossible d'avoir deux perosnnes dont le nom et le prénom soient identiques...

On note qu'un attribut est une clef en le soulignant dans le schéma entité association. Si c'est une clef composée, alors plusieurs entités seront soulignées.

Exemple :

Image non disponible

On voit ici que dans le cas de l'entité "appartement" tous les attributs sont utilisés pour composer la clef. Cette clef naturelle n'étant pas pratique, il est plus judicieux de créer un nouvel attribut qui servira expressément de clef à l'association.

Pour l'entité "être humain, on pourrait se servir du numéro de sécurité sociale (plus exactement du numéro INSEE) , comme clef de l'entité. En revanche, pour ce qui est de l'entité "appartement" il est conseillé de créer un nouvel attribut clef qui serait, par exemple, un numéro.

Exemple :

Image non disponible

Pour une entité de type « Voiture » il pourrait être fait usage de l'immatriculation du véhicule comme clef de l'entité.

MAIS... lisez attentivement ce qui suit !

2.5.1. Discussion sur la qualité d'une clef

De manière générale il convient de limiter les clefs composées. Chaque fois que l'on aura le choix entre la création d'une clef numérique, et une clef naturelle mais composée, il sera préférable de créer une clef numérique, à de très rares exceptions près.
En effet les SGBDR sont plus « à l'aise » lorsqu'ils ont à manipuler des clefs purement numérique. De plus une clef est un concept purement informatique.
Par exemple le n° de sécurité sociale est une mauvaise clef en générale : un individu étranger qui arrive sur le sol français est doté d'une immatriculation provisoire et ne connaît son numéro définitif que plusieurs mois après avoir rempli les conditions requises par l'administration.
Par exemple l'immatriculation d'un véhicule est une mauvaise clef : en effet, du fait de la fiscalité sur les véhicules à moteur (et en particulier les vignettes), les sociétés n'hésitent pas à faire immatriculer leur parc de véhicules dans le département où les taxes sont les moins élevées (le 51). Cette immatriculation peut donc être amenée à changer.
Or toute clef évolutive est un danger pour le système informatique : si la valeur de la clef change, nous verrons qu'il faut la modifier dans tous les fichiers dans laquelle elle est référencée. Il est vrai que certains SGBDR autorise automatiquement ce genre de manœuvre, mais cette automatisation très contraignante pénalise lourdement le fonctionnement du SGBDR.
On veillera donc à prendre une clef totalement indépendante des attributs ordinaires de l'entité.
De plus une clef a intérêt à être la plus courte possible afin que son stockage soit limité à quelques octets dans les fichiers et donc le temps de recherche le plus rapide possible.

Le plus simple consiste donc à introduire dans le descriptif de l'entité une clef strictement « informatique » qui se résumera en général à un numéro (entier long) que l'on pourra incrémenter automatiquement.

Parfois, il arrive qu'une clef ait été créée spécifiquement pour les besoins des systèmes informatiques. C'est en particulier le cas des indicatifs téléphoniques (33 pour la France) ou des code de pays (F pour France). Dans ce dernier cas on devra alors utiliser la clef commune, comme clef de l'entité.

2.5.2. La technique de la double clef

Une technique éprouvée consiste à introduire une double clef dans toutes les tables : la clef « informatique » et une clef « utilisateur ».
La clef informatique est l'index primaire de la table et doit posséder les caractéristiques suivantes :

  • purement numérique (par exemple un entier long)
  • unique bien entendu
  • obligatoire
  • sans mise à jour en cascade
  • avec intégrité référentielle
  • générée automatiquement
  • invisible pour l'utilisateur

La clef utilisateur doit être assez « souple », c'est à dire posséder dans la mesure du possible, les caractéristiques suivantes :

  • Index secondaire unique
  • Obligatoire
  • Utiliser un jeu de caractère réduit s'il s'agit d'un format alpha (par exemple les 26 lettres majuscules de l'alphabet et les chiffres de 0 à 9)
  • Limité à une faible taille (16/32 octets - 16 caractères maximum)

La présentation des données devant toujours s'effectuer suivant l'ordre établis par la clef utilisateur à défaut d'autre spécification.


précédentsommairesuivant

Livres
SQL - développement
SQL - le cours de référence sur le langage SQL
Avant d'aborder le SQL
Définitions
SGBDR fichier ou client/serveur ?
La base de données exemple (gestion d'un hôtel)
Modélisation MERISE
Mots réservés du SQL
Le SQL de A à Z
Les fondements
Le simple (?) SELECT
Les jointures, ou comment interroger plusieurs tables
Groupages, ensembles et sous-ensembles
Les sous-requêtes
Insérer, modifier, supprimer
Création des bases
Gérer les privilèges ("droits")
Toutes les fonctions de SQL
Les techniques des SGBDR
Les erreur les plus fréquentes en SQL
Les petits papiers de SQLPro
Conférence Borland 2003
L'héritage des données
Données et normes
Modélisation par méta données
Optimisez votre SGBDR et vos requêtes SQL
Le temps, sa mesure, ses calculs
QBE, le langage de ZLOOF
Des images dans ma base
La jointure manquante
Clefs auto incrémentées
L'indexation textuelle
L'art des "Soundex"
Une seule colonne, plusieurs données
La division relationnelle, mythe ou réalité ?
Gestion d'arborescence en SQL
L'avenir de SQL
Méthodes et standards
Les doublons
SQL Server
Eviter les curseurs
Un aperçu de TRANSACT SQL V 2000
SQL Server 2000 et les collations
Sécurisation des accès aux bases de données SQL Server
Des UDF pour SQL Server
SQL Server et le fichier de log...
Paradox
De vieux articles publiés entre 1995 et 1999 dans la défunte revue Point DBF

  

Copyright © 2003 Frédéric Brouard. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.