DU MODÈLE CONCEPTUEL DE DONNÉES AU

SCHÉMA PHYSIQUE DE LA BASE

1 - Introduction
Pourquoi l'analyse conceptuelle? Qu'est-ce que l'analyse conceptuelle?

1.1 - La situation :

La situation est toujours ainsi au point de départ :

Un problème de gestion Un outil informatique

Un utilisateur doit décider, agir… dans son Un ordinateur + ses logiciels
organisation. Il a besoin d'information pour
résoudre un problème particulier. Il veut PC… + Access ou StarOffice...
automatiser certains traitements.

L'usage de l'outil n'est pas immédiat ; une préparation est indispensable pour définir une
solution informatisée.
La construction méthodique d'une solution informatique repose sur deux principes :
- une progression par étapes (cf. 1.2),
- la distinction de différents niveaux d'analyse (cf. 1.3).

1.2 - La démarche par étapes

1.2.1 - L'analyse préalable

Faire le tour du problème : interview, discussion, documents

Proposer une idée de solution avec les choix majeurs (dans la situation étudiée, tel problème
de gestion peut être traité avec Access, plutôt que avec Excel…)
Evaluer le projet de solution (la matériel, le logiciel, le travail de saisie, les volumes à
traiter…)

1.2.2 - La conception de la solution

Définir les données (toutes les informations)

Et les traitements (la saisies, les mises à jour, les éditions…)

1.2.3 - Le développement du projet

La description détaillée de l'organisation des données c'est à dire de la saisie, l'édition, les
bases de données.
La réalisation (phase essentielle) et tests.

1.2.4 - La mise en œuvre

Saisie complète des données

Formation des utilisateurs
Démarrage et mise au point finale

1.3 - Les différents niveaux d'analyse

Conception 1 - Le niveau conceptuel : le La solution (cad l'expression du problème :

MCD Quoi faire?) est définie de manière abstraite
le Modèle Conceptuel des Données par un modèle conceptuel: le modèle entité-
association appelé aussi modèle entité-
Conception 2 - Le niveau logique ou relation ou encore modèle relationnel.
organisationnel: modèle logique des
données avec son Schéma conceptuel des
données

Développement - Le niveau technique

avec le Schéma physique de la base
[voir2.1.5]
Il faut rendre le MCD (conçu à l'étape
précédente) exploitable par le logiciel de
base de données prévu. On intègre à la
solution, les caractéristiques du logiciel. On
transforme le modèle selon un formalisme
fourni par le "modèle relationnel". Celui-ci
est à la base des SGBDR, tel Access. C'est la
description détaillée de la solution (écrans,
états...) avec les modes opératoires…

1.4 - L' "analyse conceptuelle des données" est :

• La recherche des information élémentaires d'un problème de gestion / système de

gestion.
• La compréhension des règles de gestion : "remise de 2% pour paiement au comptant",
"un élève ne fait partie que d'une seule classe"…
• La représentation normalisée du système d'information c'est à dire la modélisation. Le
"Modèle conceptuel de données" (MCD ) que nous utiliserons est le "Modèle Entité
Association".
• La schématisation du modèle (SCD, Schéma conceptuel de données). La
représentation sous forme de schéma visuel d'une base de données conceptualisée se
 fait selon un modèle dont la définition constitue une sorte de norme universelle. Le
schéma réalisé conformément au modèle constitue un support / moyen de
communication entre les acteurs du système et les informaticiens (éventuellement).

L'analyse conceptuelle débouche bien entendu sur la mise en oeuvre technique, accompagnée
de la réalisation de supports visuels : le schéma physique de la base, par exemple...

2 - Le vocabulaire et les règles du MCD

Le vocabulaire précis et les règles sont indépendants des logiciels.

2.1 - L'entité

2.1.1 - Définition

La connaissance de l'activité de l'organisation étudiée et des procédures de gestion, permet de

définir les ensembles de données nécessaires à la gestion : les entités.
C'est donc un ensemble d'information existant dans l'organisation étudiée et repéré par le
responsable de l'étude, en raison de son utilité dans la gestion.
Exemple 1 : le service commercial gère les commandes reçues des clients et comportant les
produits à livrer. Les mots soulignés sont les entités de l'application "gestion commerciale".
Comparaison entre l'entité "commandes" et les autres : une commande regroupe un ensemble
d'information à gérer. Habituellement une commande a une certaine existence, une certaine
matérialisation.
Exemple 2 : une coopérative viticole veut gérer ses produits en stocks (vin en bouteille de
qualités différentes).
Exemple 3 : une chambre de commerce organise des salons professionnels…
Pour une entité "client", chaque client particulier est dit "occurrence de l'entité client".

2.1.2 - Les attributs de l'entité

Les informations élémentaires (principe de l'atomicité) qui décrivent une entité (n'importe
quelle entité) sont appelées "attributs" de l'entité (ou "propriétés"). [voir 3.1.1]

Exemples :

Code client Raison sociale Civilité du Nom du Prénom du Fonction du

responsable responsable responsable responsable
411001 Pomagalski Monsieur Juanito ZHERFLUS Directeur
com
411002 Alsthom Madame Anita DICAPRI Directeur
rech

Adresse rue Code postal Adresse ville … … …

 …

"Adresse client" ne peut pas être un attribut d'une entité client si la gestion nécessite des
éditions automatiques des noms et adresses sur des enveloppes, sur du courrier…

2.1.3 - L'identifiant de l'entité

Un attribut dont la valeur particulière (occurrence de l'attribut) permet d'identifier une

occurrence de l'entité est l'identifiant de cette entité.
Exemple 1 : numéro = attribut de l'entité client. Un numéro permettra d'identifier sans
ambiguïté, sans équivoque, un client particulier. C'est le "code client" ou "numéro client". Un
nom ne peut pas être un identifiant.
Exemple 2 : la description d'un produit est sans équivoque mais elle est difficile à utiliser en
informatique. On va la remplacer par un code-produit qui sera l'identifiant de l'entité. Ce code
peut être signifiant (codification selon une grille) ou non (codification séquentielle).

2.1.4 - Représentation de l'entité et de ses attributs (Modèle du MEA)

Nom entité
Identifiant
…

2.1.5 - Correspondance avec un logiciel SGBDR : les tables

On passe ici du modèle logique (en l'occurrence le modèle relationnel) au niveau technique ou
physique. Pratiquement, on réalise ce passage sur l'ordinateur.
Une entité est représentée habituellement par une table. La table est un objet informatique
regroupant ici tous les individus (les occurrences) de l'entité.
La table a une forme de tableau à l'écran (lors de l'affichage en mode "feuille de donnée" avec
Access):

les colonnes ou champs : dans la table de l'entité, chaque colonne correspond à un attribut
de l'entité.
un attribut particulier est l' "identifiant" de chaque "individu" (occurrence), c'est à dire un
numéro unique pour chaque individu. C'est la "clé primaire" de la table.
les lignes : chaque ligne correspond à une occurrence de l'entité, ou "enregistrement".
Une occurrence est notée sur une seule ligne.

Retour au sommaire.

2.2 - L'association

2.2.1 - Définition

Une association définit un type de lien, un type de relation, entre deux ou plusieurs entités.
Dans un système d'information considéré, une association correspond à une ou plusieurs
règles générales d'organisation ou de logique
Exemple : un club sportif (ASL, 24 pl. de la gare à Lyon) organise des stages de ski d'une
journée pour ses membres (nom, prénom, numéro, date de naissance, adresse rue, code postal,
adresse ville…). Des moniteurs professionnels sont recrutés et payés pour l'encadrement :
Serge MARTIN, 14 rue de champs, 69002 LYON; Stéphane DUBOIS, 123 bd de la
Martinière, 69005 LYON; Claire DUBOURG… ; Coralie LAVAL… Les stages ont un nom
qui change chaque année : étoile, cristal, paillette, colonne, granule, dendrile, aiguille pour la
saison 1998-1999. Ils ont un niveau, un contenu, une date, un lieu…
Un stage n'est encadré que par un seul moniteur. Un adhérent peut suivre plusieurs stages
pendant une saison
Les deux dernières phrases de l'exemple ci-dessus sont des règles de gestion ou
d'organisation.
Trouvez les entités, les attributs, les idées de relation, les idées de codification…

Réponses :

Le nom de l'association est en général un verbe.

2.2.2 - L'identifiant de l'association

C'est une idée importante. Il faut dire : les entités x et y "participent" à l'association z.
Chaque occurrence (ou réalisation) d'une association se réalise par la réalisation des diverses
entités qui "participent" à cette association.
Exemples : 1/ Moniteurs - Stage 2/ Adhérents - Stage
Ceci est de la logique. Avant de voir concrètement comment on le réalise, il faut comprendre
l'idée.
L'identifiant de l'association est formé par les deux identifiants pris ensembles des deux
entités reliées par l'association.
Exemple: Identifiant moniteur + Code stage, soit 17 + 31

Dans certaines situations, la date permet l'identification de l'association. La date est

considérée alors comme une entité (on dit que c'est une pseudo entité).
Exemple : à l'occasion des contrôles écrits dans chaque matière, une note est attribuée à
chaque élève (dans chaque matière).
2.2.3 - Les attributs de l'association

L'association peut avoir des attributs propres, outre les identifiants des entités associées.
Exemple : la note au devoir, la quantité commandée…
Une telle association est dite "porteuse de données".
Les identifiants des entités (associées) qui participent à l'association sont des attributs
obligatoires de l'association. En conséquence, ils ne sont pas notés en principe dans la
représentation de l'association.

2.2.4 - Représentation de l'association

(Modèle Entité Association)

Nota 1 : le nom de l'association est souvent un verbe.

Nota 2 : les coins du rectangle de l'association doivent être arrondis.
Nota 3 : les règles du modèles voudraient que les identifiants des entités ne soient pas notés
dans le cartouche de l'association. Toutefois, dans la pratique, on les note.

2.2.5 - Correspondance avec un logiciel SGBDR

Vous le savez déjà, on passe ici du MCD au modèle logique et plus spécialement au modèle
relationnel.
On utilise une table pour regrouper toutes les occurrences de l'association c'est à dire toutes
les occurrences de la réalisation de la relation entre les entités.
On le sait, la table a une forme de tableau à l'écran :

les premières colonnes ou champs permettent de noter les identifiants des entités associés.
C'est obligatoire. On les appelle les clefs externes de l'association.
les colonnes suivantes sont celles de données propres lorsque l'association est porteuse
de données.

2.3 - L'association hiérarchique ou CIF

Elle ne ressemble pas à l'association présentée ci-dessus. C'est un autre type de relation.

2.3.1 - Définition et terminologie

Une association entre deux entités est hiérarchique si la réalisation de l'une des entités
détermine la réalisation de la seconde.
Exemple 1 : La gestion des commandes clients obéit à une règle tout à fait générale qui est :
une commande n'est passée que par un seul client. Une deuxième règle de gestion est : chaque
commande est identifiée par un numéro. Il résulte de ces deux règles que la connaissance d'un
numéro de commande permet la connaissance du client qui a passé cette commande. L'inverse
n'est pas possible bien sûr. La relation "une commande est passée par un client" sera donc
représentée par une association hiérarchique.
Exemple 2 : Dans les établissement scolaires on trouve ces deux règles de gestion : un élève
appartient obligatoirement à une classe ; un élève n'appartient qu'à une seule classe.
L'identification de l'élève entraînera l'identification de sa classe. L'inverse n'est pas possible.
La relation "un élève fait partie d'une classe" sera donc représentée par une association
hiérarchique.
La terminologie est à connaître. Une "association hiérarchique" est aussi appelée "Contrainte
d'intégrité fonctionnelle" (CIF).
Elle est aussi appelée "Relation père-fils" car, vous l'avez constaté dans les deux exemples ci-
dessus, la relation d'identification ne fonctionne que dans un sens. Un fils n'a qu'un père ; un
père a plusieurs fils. Un élève n'appartient qu'à une classe ; une classe comporte plusieurs
élèves. 2.3.2 - Des caractéristiques particulières

L'occurrence de la relation hiérarchique est unique. Par exemple, la relation élève-classe ne

peut exister qu'une fois pour chaque élève. Il en résulte :

• que cette relation n'a pas besoin d'être identifiée.

• que cette association n'est jamais porteuse de données.

2.3.3 - Représentation

Remarque : les cardinalités (ex : 1,1 ; 1,n) sont expliquées ci-dessous.

Dans la table fils, l'identifiant de la table père est une clef externe.

2.3.4 - Correspondance avec Access

Comme les CIF n'ont pas besoin de tables, elles n'apparaissent pas visuellement sur les
écrans de Access.
Elles sont créées par l'installation d'un lien (trait visuel) entre la clef primaire de la table père
et la clef externe de la table fils, sur le schéma général des relations, ou sinon au moment de
créer une requête.
Concrètement, on clique glisse l'Identifiant P de la table père (clef primaire) vers l'Identifiant
P de la table fils (clef externe).

2.4 - Les cardinalités

2.4.1 - Définition

Une cardinalité, dans une association, exprime le nombre de participations possibles d'une
occurrence de chaque entité à l'association. Ce nombre étant variable, on note la cardinalité
minimum et la cardinalité maximum. Comme il y a deux entités (au moins) associées, la
cardinalité est précisée pour chaque entité (voir la représentation : 2.4.2).
Exemple : un éditeur gère sur système informatique, son catalogue de livres et leurs auteurs.
Beaucoup d'ouvrages sont élaborés par plusieurs auteurs sans dépasser huit pour le même
ouvrage. Bien entendu, un ouvrage est élaboré par au moins un auteur.
Les cardinalités sont les suivantes:

Un livre est écrit par 1 à 8 auteurs

Chaque auteur participe à l'écriture de 1 à "n" livres. "n" veut dire que le maximum n'est pas
déterminé. Le chiffre 1 veut dire que les personnes de la base auteurs sont auteurs d'au moins
"1" livre, sinon elles ne seraient pas dans la base. "1" est le minimum. Ceci est une règle de
gestion évidente implicite dans de nombreuses bases.

2.4.2 - Représentation

L'association "Ecrire" est une association normale.

2.4 3 - Cardinalité de l'association hiérarchique

La cardinalité de l'entité fils est "1,1" (voir l'exemple ci-dessus).

(Remarque : Electre est une base de données utilisées par les documentalistes, les libraires ou
les particuliers. Elle affiche les titres de ouvrages et le nom de l'éditeur.)
Règles de gestion : Un ouvrage est publié par un éditeur et un seul.
Retour au sommaire.

3 - La méthode de construction d'un MCD

3.1 - La recherche des données de la base

3.1.1 - Généralités

Il s'agit ici de trouver et de définir précisément :

les attributs ou propriétés des entités,

les attributs des associations,
les données calculées dont on peut avoir besoin dans le traitement des informations
(exemples : totaux, montants HT, montants TTC, etc.). Elles ne sont pas enregistrées. Elles
sont calculées dans les requêtes ou bien dans les formulaires ou bien dans les états. Elles
apparaissent lors de l'affichage à l'écran du résultat des requêtes (tableaux appelés "feuilles de
données" avec Access) ou lors de l'impression des documents.

L'ensemble de ces informations constituent les données de la base.

Cette recherche aboutira à la mise en évidence des entités.

3.1.2 - Les règles de la recherche et de la définition des données

On est au stade de la conceptualisation. Rien n'est encore informatisé.

Cette analyse du système informationnel se fait à partir des documents utilisés et des
interviews données par les utilisateurs.

1 - Supprimer les rubriques génériques : le principe de l'atomicité [revenir à 2.1.2] doit être
respecté : l'information doit être divisée jusqu'au niveau limite des traitements informatiques.
Par exemple, l' "adresse complète" ne peut pas être une donnée car certains traitements
peuvent porter sur le code postal ou sur le nom de la ville. 2 - Supprimer les synonymes :
deux termes différents trouvés dans les documents ou au cours des interviews désignent la
même information. Par exemple : code-client et numéro-client désignent la même réalité. Il ne
faut retenir qu'un terme. 3 - Supprimer les polysèmes : un terme est dit "polysème" quand il
désigne deux informations différentes. Cette situation traduit un manque d'analyse. Par
exemple, le terme "code-produit" désigne les produits finis en catalogue et les matières
premières ! 4 - Délimiter les rubriques calculées.

5 - Délimiter les paramètres. Par exemple, un taux de TVA s'il est unique dans l'entreprise
doit être intégré aux fonctions de traitement.

3.2 - Le dictionnaire des données

3.2.1 - Définition
Le dictionnaire des données est à la fois le support du travail et le résultat de la recherche et
analyse des données. Il se présente sous la forme d'un tableau

3.2.2 - Présentation
Dans ce tableau, chaque donnée est représentée par : 1/ son nom informatique, c'est à dire un
mnémonique ou un nom en clair, 2/ une description, 3/ son type numérique, alphabétique,
logique... 3/ sa dimension en nombre de caractères, 4/ éventuellement les calculs qui
permettent de la générer,

3.2.3 - Elaboration
L'outil informatique est bien entendu pour élaborer le dictionnaires de données. En général, il
est élaboré au stade de l'analyse du problème, puis complété au moment de la modélisation si
on a besoin de créer des identifiants pour des entités.
3.3 - Le schéma de la base [aller à 1.4]

Au stade de la conception, on réalise le schéma conceptuel des données.

Au stade de la mise en oeuvre, on réalise le schéma physique de la base :

(le graphisme du schéma est obtenu par copier-coller à partir d'un écran de Access)