M.

KOUYATE

Module de l’ingénierie des systèmes d’information

Modibo Kouyaté
Bioinformatic analyst-programmer
70037267/66572939
 M.KOUYATE

 Présentation du SI
 Les composantes du SI
 Les méthodes de conception du SI
 Méthode MERISE
 Méthode UML
 La méthode Merise
 Conception du système d’information avec la méthode Merise
 applications théoriques
 Application pratique(Analyse SI /JMERISE)
 Transformation du SI en base de données(SGBD)
Manipulation de la base de données avec le langage SQL
 M.KOUYATE

DEFINITION
L’information: Tout événement, tout fait, tout jugement porté à la
connaissance d'un public plus ou moins large, sous forme d'images, de
textes, de discours, de sons. (Abréviation familière : info.)
D’un point de vu informatique, un système d’information doit permettre de:

Le système Informatique: désigne l’ensemble des équipements matériels et

logiciels qui permettent la collecte, le traitement, le stockage et la
transmission de l’information.
Le système d'Information: SI - représente l'ensemble des éléments
participant à la gestion, au traitement, au transport et à la diffusion de
l'information au sein de l'organisation.
Le SI est l’ensemble des ressources (matériels, logiciels, données, procédures, humains,
…) structurés pour acquérir, traiter, mémoriser, transmettre et rendre disponible
l’information (sous forme de données, textes, sons, images, …) dans et entre les
organisations. »
 M.KOUYATE

ENTREPRISE
Système
d’information saisie
Opérationnel Système de pilotage
Stockage
traitement
restitution
communication

Flux d’information Système d'Information Flux d’information

Système Opérant
Matières premières Produits et Services
 M.KOUYATE

Les éléments du système sont eux-mêmes des systèmes (ou sous-systèmes)

Système de décision
Système d’information /informatique
Système opérant
Environnement
•L’entreprise peut se décomposer en 3 sous-systèmes :
–Le système de décision
–Le système d’information
–Le système opérant
M.KOUYATE
M.KOUYATE last_course /05/07
 M.KOUYATE

Le système de pilotage : (appelé également système de décision)

–Exploite les informations qui circulent
–Organise le fonctionnement du système
–Décide des actions à conduire sur le système opérant
–Raisonne en fonction des objectifs et des politiques de l’entreprise

Le système opérant:
Le système opérant :
–Reçoit les informations émises par le système de pilotage
–Se charge de réaliser les tâches qui lui sont confiées
–Génère à son tour des informations en direction du système de
pilotage
•Qui peut ainsi contrôler les écarts et agir en conséquence
–Il englobe toutes les fonctions liées à l’activité propre de
l’entreprise :
•Facturer les clients, régler les salaires, gérer les stocks
 M.KOUYATE

Le système d’information/informatique

Pour organiser son fonctionnement, le système a besoin de mémoriser des informations

–Pour comparer, prévoir, …
•Ce rôle est joué par le Système d’Information
•Ce système a aussi la charge de :
–Diffuser l’information
–Réaliser tous les traitements nécessaires au fonctionnement du système

Le SI peut être défini comme étant :

–l’ensemble des flux d’information circulant dans l’organisation
–associé aux moyens mis en oeuvre pour les gérer
•Infrastructure matérielle et logicielle
–Réseau, Serveurs, Postes individuels, …
–Progiciels, SGBD, Applications de gestion, Applications métier…
 M.KOUYATE

Est un outil de communication il permet l’interaction entre le système et son

environnement possible grâce à des flux d’informations. Ces flux circulent aussi à
l’intérieur du système, ce qui lui permet d’analyser son propre fonctionnement
 M.KOUYATE

Comme outil de communication interne

 M.KOUYATE

Un outil d’aide à la décision

Pour décider, il est nécessaire d’avoir des informations :
 M.KOUYATE

LE SI ET LES TYPES D’ENTREPRISE

L’entreprise-type peut se résumer ainsi par:

 Comptabilité et gestion de stocks
 Informatique bureautique
 Ventes et marketing
 Bureau d’études
 Production et fabrication
 Logistique et relation client fournisseur
 Management et direction
M.KOUYATE
 M.KOUYATE

Dans la mesure du possible (et selon le type d’information)

l’entreprise aura tendance à stocker l’information sur des
supports informatisés :
 Faciliter la consultation, l’extraction

 Faciliter l’automatisation des traitements

 Faciliter la diffusion
M.KOUYATE
M.KOUYATE
M.KOUYATE
 M.KOUYATE

M éthode d'
E tude et de
R éalisation,

I nformatique pour les

S ystèmes d'
E ntreprise
 M.KOUYATE

Merise est une méthode d'analyse, de conception et de

gestion de projet informatique
MERISE est caractérisée par :
 Une approche systémique de l’entreprise

 La séparation des données et des traitements

 Une conception par niveaux. La conception d'un système d'information n'est pas
évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception
nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer. La modélisation
consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on
s'intéresse.
 Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la méthode la plus utilisée est la
méthode MERISE. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des
données et des traitements à effectuer en plusieurs modèles conceptuels et physiques.
La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les
traitements le sont plus fréquemment.
 M.KOUYATE

 Cycle d'abstraction de conception des systèmes d'information

 La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel
reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les
résultats de la phase précédente.
 Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information
 M.KOUYATE

 L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information
automatisé, il faut pour cela :
• faire l'inventaire des éléments nécessaires au système d'information
• délimiter le système en s'informant auprès des futurs utilisateurs
 Cela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux
d'informations à prendre en compte.
 L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle
conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.
 Le modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les
contraintes dues à l'environnement (organisationnel, spatial et temporel).
 Le modèle logique représente un choix logiciel pour le système d'information.
 Le modèle physique reflète un choix matériel pour le système d'information.
M.KOUYATE
 M.KOUYATE

Objectif du MCD
Décrire les données du SI, indépendamment
de tout choix d'implantation physique.

1. Le dictionnaire des données

 Inventaire exhaustif des données du domaine
étudié.
 On utilise habituellement :
 une fiche "descriptif de document" (une par
document),
 une fiche récapitulative "descriptif des données".
 M.KOUYATE

2. Le modèle conceptuel des données : le

modèle entité/association (cf. cours BD
1°A)
a) les concepts de base du modèle E/A,
b) vérification et normalisation du modèle E/A,
c) les contraintes d'intégrité dans le modèle
E/A.
 M.KOUYATE

a) Les concepts de base

Entité : tout objet concret ou abstrait ayant une
existence propre et conforme aux besoins de
gestion de l’organisation.
Ex: le client «Dupond», le produit de référence «a456», …
Classe d’entités (ou entité-type) : ensemble des
entités décrites par les mêmes caractéristiques.
Ex: la classe CLIENT dont «Dupond» est une occurrence
(ou instance).
Association : n-uplet d’entités « sémantiquement
liées ».
Ex: («Dupond»,  «1367 VS 54») indiquant que la personne
Dupond est propriétaire de la voiture immatriculée 1367 VS
54.
 M.KOUYATE

Classe d’associations (ou association-type) :

regroupe toutes les associations constituées des
mêmes types d’entités jouant le même rôle dans
l’association.
Ex: PROPRIETAIRE(PERSONNE, VOITURE)
Les occurrences de cette classe d’association sont un
sous ensemble du produit cartésien PERSONNE x
VOITURE (c.à.d. une partie de l’ensemble des couples
possibles de personnes et de voitures).

PERSONNE VOITURE

PROPRIETAIRE
 M.KOUYATE

Remarques
 On peut avoir plusieurs classes d’associations
sur les mêmes classes d’entités.
Ex : PROPRIETAIRE(PERSONNE, VOITURE)
et CONDUIRE(PERSONNE, VOITURE)
 On peut avoir une classe d’association sur une
seule classe d’entités (on parle d’association
‘réflexive’). On ajoute souvent dans ce cas des noms
de rôles pour distinguer les deux occurrences.
Ex : CONJOINT(PERSONNE, PERSONNE)

PERSONNE
époux
CONJOINT
épouse
 M.KOUYATE

 On peut avoir une classe d’association

définie sur n classes d’entités (association n-
aire ou d’arité n ou de dimension n ou à « n
pattes »).
Ex: COURS(MATIERE, CLASSE, PROF)

Attention : les arités élevées sont rares. Elle

dénotent souvent des faiblesses dans
l’analyse. arité 2 : 80%
arité 3 : <20%
arité > 3 : 
 M.KOUYATE

Propriété : donnée élémentaire permettant de

caractériser les entités et associations
Ex : nom, prénom, adresse propriétés de
PERSONNES

PROFESSEUR MATIERE
COURS
Nom, Jour, Refmat,
Prénom, Heuredeb, Intitulé
Adresse, Heurefin
Age

CLASSE
Refclasse,
Numsalle
 M.KOUYATE

Identifiant : propriété ou groupe de propriétés

permettant d’identifier de manière unique
chaque occurrence de la classe d’entités.
Ex : N° immatriculation pour VOITURE. Nom ne suffit
pas pour PERSONNE. N° Client pour CLIENT (propriété
ajoutée)
Les identifiants sont en général soulignés.
Cardinalités : indiquent pour chaque classe
d’entités de la classe d’association, les nombres
mini et maxi d’occurrences de l’association
pouvant exister pour une occurrence de l’entité.
La cardinalité minimum est 0 ou 1.
La cardinalité maximum est 1 ou n.
 M.KOUYATE

Une cardinalité minimum à 0 signifie qu’il est possible

d’observer (un jour) une occurrence d’entité sans
occurrence d’association.
Donc 4 combinaisons possibles :
0,1 au plus 1
1,1 1 et 1 seul
1,n au moins 1
0,n un nombre quelconque

Ex: PROPRIETAIRE(PERSONNE [0,n],

VOITURE [1,1])
Une personne a 0 à n voitures; une voiture a 1 et 1
seul propriétaire.
 M.KOUYATE

CONDUIT(PERSONNE [0,n], VOITURE [1,n])

Une personne conduit 0 à n voitures; une voiture est
conduite par 1 à n personnes.

Représentation graphique :
Sens de lecture destination
source
PERSONNE VOITURE
0,n PROPRIETAIRE 1,1

!! Dans les méthodes anglo-saxonnes la cardinalité est

placée du côté opposé à l’entité source !!
 M.KOUYATE

COURS(MATIERE [1,n], CLASSE [1,n], PROF[1,n])

Un prof. a 1 à n cours dans la semaine, une matière a 1 à
n cours dans la semaine, une classe a 1 à n cours dans la
semaine.

PROF MATIERE
COURS
Nom, 1,n Jour, Refmat,
1,n Intitulé
Prénom, Heuredeb,
Adresse, Heurefin
Age
1,n
CLASSE
Refclasse,
Numsalle
 M.KOUYATE

Difficultés : choix entre entité et association ?

1) Solution avec association
CLIENT PRODUIT

nocli, 1,n commande 0,n noprod,

nomcli désignation

Dans cette première solution la commande n’est pas

une entité gérée pour elle même. Elle existe tant que le
client et le produit existent.
Ce peut être le SI du domaine ‘fabrication’ : on a juste
besoin de savoir que les produits sont destinés à des
clients.
 M.KOUYATE

2) Solution avec entité

PRODUIT
CLIENT
noprod,
nocli, désignation
nomcli
COMMANDE
1,n 1,n 0,n
passe 1,1 porte
nocde
datecde

Dans cette seconde solution, les commandes sont

identifiées (identifiant nocde) et décrites : on les gère
en tant que telles.
Ce peut être le SI du domaine financier.
 M.KOUYATE

Quelques ‘critères’ de choix :

 Une entité a une existence propre et un
identifiant.
 Une association n’existe que si ses
extrémités existent et n’a pas d’identifiant
explicite.
 Une entité peut être associée à d’autres
entités, une association non.
 M.KOUYATE

Difficultés : choix des cardinalités

0, n ou 0, n ou
CLIENT LOCAL
1, n ? 0,1 ?
LOCATION

Un client peut il avoir 0 location ? Est-ce encore un

client ?
Un local peut il être loué plusieurs fois ? Non si la
base représente une situation instantanée et si le
local n’est pas partageable. Oui si on gère un
historique ou si le local est partageable.
Les cardinalités sont élément essentiel pour
définir la sémantique des données, pas une
« décoration » accessoire. Derrière cette notion
on trouvera des contrôles (par le SGBD ou les
programmes).
 M.KOUYATE

Pour une situation donnée, il n’existe pas

une «solution» unique.
Un modèle exprime un point de vue et
reflète des besoins en information.
Le bon modèle est celui qui est
accepté par les personnes concernées
par le projet.
 M.KOUYATE

b) Vérification et Normalisation
Contrôler la qualité du modèle vis-à-vis :
 des fondements du modèle d’une part (règles
de vérification),
 de la redondance de données d’autre part
(règles de normalisation) .
Permet de détecter certaines incohérences dans
la construction des modèles.  
1. Règles Générales  
 Toute propriété doit apparaître une seule fois
dans un modèle.
Il faut éliminer la redondance des propriétés dans la
même entité (avec des noms différents) ou dans des
entités distinctes :
 M.KOUYATE

PRODUIT PRODUIT TARIF

1,n
prix1 coûte
code-tarif
prix2 prix libellé-tarif

CLIENT PROSPECT CONTACT

code-client code-prospect code-contact

nom-client nom-prospect nom-contact
type (C, P)

Pas d’héritage dans le modèle E/A de base !

 Toutes les propriétés identifiées doivent

apparaître dans le modèle.
 M.KOUYATE

2. Règles sur les entités

 2.a Règle de l’identifiant
Toutes les entités ont un identifiant.
 2.b Règle de vérification des entités
Pour une occurrence d’une entité, chaque
propriété ne prend qu’une seule valeur (cf. la
1FN du modèle relationnel); MONO-VALUEE

Employé Employé Enfant

Matricule Matricule Matricule
Nom Nom Prénom-
Prénom- enfant
enfant

On décompose l'entité Employé en deux entités : Employé, et Enfant

 M.KOUYATE

2.c Règles de normalisation des entités

a) Les dépendances fonctionnelles (DF) entre
les propriétés d’une entité doivent vérifier la
règle suivante : toutes les propriétés de l’entité
dépendent fonctionnellement de l’identifiant et
uniquement de l’identifiant.
Rappel :  une DF XY si à une valeur de X correspond
une et une seule valeur de Y (réciproque pas vraie).
Voiture Voiture Propriétaire
N°immatric. N°immatric. N° insee
Type
Type Nom
N° insee
Adresse
Nom
Adresse

La DF: N°insee Nom, Adresse contredit la règle.

 M.KOUYATE

b) Une partie de l’identifiant ne peut pas

déterminer certaines propriétés.
Commande

N°comm Commande LigneCom

N°prod
N°comm N° comm
Qté
DateCom
DateComm
N°Client 0,n 1,1 N°prod
N°client Qté

La DF n°-comm  date-comm, n°-client contredit la

règle. On décompose l’entité Commande en deux
entités.
Ces règles correspondent aux 2FN et 3FN du modèle
Relationnel (dépendance pleine et directe des clés).
 M.KOUYATE

3. Règles sur les associations

3.a Règle de vérification des associations
Pour une occurrence d’association, chaque propriété
ne prend qu’une seule valeur.
3.b Règle de normalisation sur les propriétés
des associations
Toutes les propriétés de l’association doivent
dépendre fonctionnellement de tous les identifiants
des entités portant l’association, et uniquement d’eux.
Voiture autorisé Personne
Date-aut N°insee
N°immatr
Date-permis

N°-insee  Date-permis pose problème (donc déplacer

Date-permis vers Personne)
 M.KOUYATE

3.c La décomposition des associations n-aires

Il faut garder un minimum d’associations d’arité > 2.
Si on observe une DF entre un sous-ensemble des
entités d’une association, on peut la décomposer en
deux associations (on parle aussi de ‘contrainte
d’intégrité fonctionnelle’ ou CIF).
Prof Matière
N°prof N°mat
0,n 0,n
Nom
cours
salle, heure
Classe
0,n
N°classe

Une éventuelle DF N°prof  N°mat donne la décomposition :

 M.KOUYATE
Prof 1,1 1,n Matière
assure N°mat
N°prof
Nom
cours
0,n
salle, heure Classe
0,n N°classe

C’est le cas, quand une patte a une cardinalité 1,1.

Par exemple à 1 contrat est associé un client et un local :
Client Local

Client 0,n 0,n Local 0,n 0,n

location
concerne porte-sur
1,1
Contrat 1,1 1,1
Contrat
 M.KOUYATE

3.d La suppression des associations transitives

Toute association pouvant être obtenue par transitivité de n autres
associations peut être supprimée.

Facture 1,1 1,n Commande

concerne

1,1
1,1 obtenue_par
associée_a
1,n
Représentant
1,n

On supprime l'association associée_a, car elle peut être

obtenue par transitivité sur les associations concerne et
obtenue_par
 M.KOUYATE

c) Les Contraintes d’Intégrité

Les CI définissent des propriétés qui doivent
être vérifiées par les données de la base.
1. Contraintes liées au schéma
1.a Contrainte d’identifiant
Les valeurs prises par l’identifiant sont uniques et
toujours définies.
1.b Contraintes de cardinalité
Les cardinalités portées par les entités membres
d’association imposent des nombres minis et maxis
d’occurrence dans l’association.  
Une cardinalité mini de 1 rend l’existence d’une
occurrence d’entité dépendante de l’existence d’une
occurrence d’une autre entité.
 M.KOUYATE

Station 0,n a lieu 1,1 Compétition

NomStat RefCompet

Une compétition ne peut exister que si la station où

elle se déroule existe
Une station peut exister de manière indépendante de
toute compétition.
 M.KOUYATE

2. Contraintes additionnelles
Contraintes de participation des entités aux associations.

 2.a Exclusivité de participation d’une entité à

plusieurs associations
  Si l’entité E participe à l’association A1, elle ne peut
participer à l’association A2.

1,n
acheter Fournisseur
0,n

Article X
1,n Stock
0,1 trouver

Un Article est soit acheté

auprès d’un fournisseur, soit figure dans le Stock
 M.KOUYATE

2.b Inclusion de participation d’une entité à plusieurs

associations 
La participation d'une entité E à une association A1
implique sa participation à l'association A2. 

0,n
souscrit Abonnement
Client 1,1
I
emprunte Ouvrage
0,n 0,1

La participation de client dans l’association emprunte

implique sa participation à l'association souscrit.
 M.KOUYATE

2.c Exclusion de participation entre associations

  Il y a exclusion de participation entre associations si la
participation des entités à l'association A1 exclut leur
participation à l'association A2.

0,n
0,n disponible
Datejour Personne

X
0,n 0,n
en formation

Une personne à une même date ne peut pas figurer

simultanément dans les deux associations: disponible et
en formation.
 M.KOUYATE

2.d Inclusion de participation entre associations 

Il y a inclusion de participation entre associations si la
participation des entités à l'association A1 implique leur
participation à l'association A2.

1,n ligneCde 0,n

Commandes Produits

I
0,n 0,n
ligneLiv

Tout couple commandes, produits figurant dans

l'association ligneLiv doit figurer dans l'association
ligneCde
Le problème va être de vérifier toutes ces contraintes
dans les programmes qui mettent à jour les données !
 M.KOUYATE

Certains auteurs suggèrent la démarche suivante :

1 Analyser l'existant et constituer le dictionnaire des données
2 Épurer les données (éliminer synonymes et polysèmes)
3 Dégager les ‘entités naturelles’ grâce aux identifiants
existants déjà dans l’organisation
4 Rattacher les propriétés aux entités
5 Recenser les associations entre entités et leur rattacher
leurs éventuelles propriétés
6 Déterminer les cardinalités
7 Décomposer si possible les associations n-aires (cf. règles)
8 S'assurer de la conformité du modèle aux règles de
construction (cf. règles)
9 Normaliser le modèle : s'assurer qu'il est en 3FN
 M.KOUYATE

Malheureusement, dans le monde réel, il n’y a pas

d’énoncé ! L’existant n’est pas complètement connu au
départ, ni toutes les données. Imaginer avoir un
dictionnaire exhaustif au départ n’est pas réaliste dans
les cas complexes.

Il n’y a donc pas une suite linéaire d’étapes mais plutôt un

ensemble d’itérations :
- ébaucher un modèle avec les entités et associations
qui semblent essentielles,
- évaluer si ce qui est modélisé est correct et
correspond à ce que les utilisateurs comprennent,
- itérer en complétant progressivement jusqu’à ce
que le modèle semble raisonnablement complet.
 M.KOUYATE

Du Modèle Conceptuel des données MCD

pour réfléchir
Au modèle Logique de données MLD
modèle « mathématique »
Au modèle Physique de données MPD
pour programmer
 M.KOUYATE

 La modélisation conceptuelle a décrit de

manière exhaustive les données du système
d’information et leurs structures avec deux
outils:
 ENTITES - ASSOCIATIONS
 Comment intégrer les contraintes
techniques pour une implantation
informatique, un SI automatisé ?
 M.KOUYATE

IMPLANTATION SUR MACHINE = MODELE PHYSIQUE

 Le modèle fichier (S.G.F)

 Le modèle SGBD :
On implante le SI à partir d’un logiciel appelé
Système de Gestion de Bases de Données
 M.KOUYATE

 Le MLD prend en compte la nature de

l’outil logiciel avec lequel sera implanté la
future base de données.
 Différents SGBD basés sur
 le modèle hiérarchique ou réseau IMS/DL1 chez IBM
 le modèle relationnel ORACLE, MySQL
 le modèle objet db4O
 M.KOUYATE

 Edgar Frank Codd : A Relational Model of Data for Large

Shared Data Bank ; CCAM 13; N°6, june 1970
 Simple à appréhender
 Basé sur la théorie des ensembles en mathématique
 Représentation de l’ORGANISATION : Manipulation de
listes de données
 Indépendance totale avec le système d’exploitation et le
stockage physique
 Règles de normalisation
 M.KOUYATE

1- Exemples de bases de données

relationnelles.
2- Définitions du modèle relationnel.
3- Passage du MCD au MLD relationnel.
4- Exemples complexes.
M.KOUYATE
 M.KOUYATE

 « résider »
M.KOUYATE
 M.KOUYATE

 « commander » et « obtenir »
 M.KOUYATE

 Les fournisseurs de cadeaux:

 M.KOUYATE

 Les entités sont-elles transformées en tables ?

 Toute association est-elle transformée en tables ?

 Si non , quelles sont les associations transformées

en tables ? Quelle est la structure de ces tables ?
 M.KOUYATE

 ENFANT ( noEnfant , nomEnfant, prénomEnfant,

gentil, codeAdresse )
 ADRESSE ( codeAdresse, rueAdresse, cp , ville,
cheminée, fénêtre, souterrain )
 COMMANDER ( noEnfant, noCadeau )
 OBTENIR(noEnfant, noCadeau )
 FOURNISSEUR ( noFsseur, nomFsseur, adrFsseur )
 CADEAU ( noCadeau, nomCadeau, noFsseur )
 M.KOUYATE

 Une base de données relationnelle est

constituée d’ un ensemble de tables aussi
appelées relations liées entre elles.
 La table ou relation ENFANT:
ENFANT ( noEnfant , nomEnfant,
prénomEnfant, gentil, codeAdresse )
 Clé primaire : noEnfant ; la connaissance
de la valeur de la clé primaire permet de
connaître la valeur des autres propriétés.
 M.KOUYATE

ENFANT ( noEnfant , nomEnfant, prénomEnfant,

gentil, codeAdresse )

 Clé étrangère: codeAdresse

Clé présente dans une table dont elle n’est pas la
clé primaire,
tout en étant clé primaire d’une autre table.
 M.KOUYATE

 Les tables statiques:

aucune colonne n’est clé primaire d’une
autre table :
(exemples : tables ADRESSE, FOURNISSEUR)
 Les tables dynamiques:
Il existe au moins une colonne qui est clé
primaire d’une autre table
(exemples : tables COMMANDER , OBTENIR ,
etc)
 M.KOUYATE

 Règle 0 : traitement des entités

Une entité est traduite par une table ( une

relation ) de même nom dont les colonnes
correspondent aux propriétés de l’entité .

La clé primaire de cette table est l’identifiant

de l’entité
 M.KOUYATE

Traitement des associations :

Tenir compte des cardinalités maximales de chaque association :

1 et n
 M.KOUYATE

Règle 1 : association binaire

avec cardinalités maximales : 1 et n

L’association n’est pas transformée en table .

L’identifiant de l’entité but (0, n) devient clé

étrangère dans la table source (1,1)
 M.KOUYATE

source but

CREATE TABLE PRODUIT ALTER TABLE PRODUIT

( REFPRODUIT VARCHAR(5) NOT NULL, ADD CONSTRAINT FK_PRODUIT_FOURNISSEUR
NOMPRODUIT VARCHAR(60), FOREIGN KEY NOFOURNISSEUR
NOFOURNISSEUR VARCHAR(5) NOT NULL REFERENCES FOURNISSEUR (NOFOURNISSEUR);
)
 M.KOUYATE

MCD

MLD

NB : Le no de messager n’est pas obligatoirement renseigné dans

COMMANDES
 M.KOUYATE

Traitement des associations :

Tenir compte des cardinalités maximales de chaque association :

1 et 1
 M.KOUYATE

 Règle 1 bis : association binaire

avec cardinalités maximales : 1 et 1

La cardinalité 1,1 est une contrainte plus forte

que la cardinalité 0,1. Donc:

L’ identifiant de l’entité but du lien 1,1 devient

clé étrangère dans la table issue de l’entité
source.
 M.KOUYATE

MCD

MLD
 M.KOUYATE

Pour chaque occurrence, 1 valeur à mémoriser

 une propriété suffit
 M.KOUYATE

Traitement des associations :

Tenir compte des cardinalités maximales de chaque association :

n et n
 M.KOUYATE

Règle 2 : association binaire

avec cardinalités maximales : n et n,
non porteuses de données:

L’association est traduite en table avec pour clé

primaire, la concaténation des identifiants des
entités reliées par l’association.

Cette table contient deux clés étrangères.

 M.KOUYATE

 Exemple de la règle 2 :

MCD

MLD
 M.KOUYATE

 Règle 2 bis : association binaire

avec cardinalités maximales : 1 et n
porteuse de données:

L’association est traduite en table avec pour clé

primaire , la concaténation des identifiants des
entités reliées.

Cette table contient deux clés étrangères et les

propriétés portées par l’association.
 M.KOUYATE

MCD

MLD
 M.KOUYATE

CREATE TABLE DETAILCOMMANDES

(REFPRODUIT VARCHAR(5) NOT NULL,
NOCOMMANDE
QUANTITE INTEGER,
INTEGER NOT NULL,
MPD
REMISE INTEGER
);

ALTER TABLE DETAILCOMMANDE

ADD CONSTRAINT PK_DETAILCOMMANDE PRIMARY KEY (REFPRODUIT, NOCOMMANDE);

ALTER TABLE DETAILCOMMANDE

ADD CONSTRAINT FK_DC_PRODUIT FOREIGN KEY (REFPRODUIT)
REFERENCES PRODUITS(REFPRODUIT);

ALTER TABLE DETAILCOMMANDE

ADD CONSTRAINT FK_DC_COMMANDE FOREIGN KEY (NOCOMMANDE)
REFERENCES COMMANDES(NOCOMMANDE);
 M.KOUYATE

Pour chaque occurrence, n valeurs à mémoriser

 une table supplémentaire
 M.KOUYATE

 Règle 3 : une association ternaire et plus

de cardinalités 0,n- 0,n – 0,n –

L’association est traduite par une table ayant

pour clé primaire :

la concaténation des clés étrangères

provenant des entités participant à
l’association.
 M.KOUYATE

MCD MLD
 M.KOUYATE

On convient de ne pas créer les tables

comportant comme unique propriété son
identifiant.

Exemple : la table DATE ………..

Et qui voudrait la remplir à chaque réveillon ?

 M.KOUYATE

Si le modèle physique de données est

conforme au modèle logique relationnel, on
est sûr de ne pas avoir de soucis de
redondance d’informations. Les traitements
en seront simplifiés.
On garde cette garantie en STS1
Le modèle physique de données peut être
dénormalisé (dans les règles !!) s’il est
nécessaire d’optimiser certains traitements.