MODULE

Système d’information et Bases de données

Pr. Nour El Houda Chaoui

École Nationale des Sciences Appliquées de Fès

Université Sidi Mohamed Ibn Abdellah
Année Universitaire 2019/2020
 Les Méthodes d ’Analyse et de Conception des Systèmes d ’information

But d ’une méthode :

* Analyser la réalité du S.I en vue d ’une informatisation
* Formaliser son activité à l ’aide de modèles
Techniques de modélisation => Domaine en pleine évolution

Quelques méthodes de modélisation

Approche relationnelle
MERISE ( 1ère génération/79 ; 2ème génération/88 et 94 ) de H.Tardieu et A.Rochfeld
SSADM ( Structured System Analysis And Design Method ) Royaume Uni /1987
AXIAL
Approche orientée objet
OOD ( Object Oriented Design ) de G.Booch / 1986
OOA ( Object Oriented Analysis ) de P.Coad et E.Yourdon / 1991
OOM ( Orientations Objet dans Merise ) de A. Rochfeld / 1992
OMT ( Object Modeling Technique ) de J.Rumbaugh / 1991
UML (Unified Modeling Language) de l ’OMG /1995 (Object Modeling Group)
La Méthode MERISE (2ème Génération)

MODELES

MCC

MCD MCTA
Niveau conceptuel

CVO

MOD MOTA Niveau

Organisationnel

MLD MLT Niveau logique

Niveau physique
MLDR MLTR
 Le Système d’Information vu selon la méthode MERISE
MODELES Système Modélisé Description

MCC
Description des fonctions majeures du S.I en réponse aux stimuli provenant de
+ MCD Système d’information
l’environnement extérieur ( acteurs externes ) sans
+ MCTA Conceptuel ( SIC ) référence aux ressources nécessaires à sa mise en œuvre
+ CVO ( Concentration sur le Quoi )

MOD Système d’information Description des ressources nécessaires à la mise en œuvre des activités
+ MOTA Organisationnel ( SIO ) du SIC du point de vue du gestionnaire ( moyens techniques et humains , espace
, temps , données ) et choix d ’une organisation pour ces ressources (
Concentration sur le Comment du gestionnaire )

Description d’une solution informatique permettant d’assurer

le fonctionnement du SIO :
MLD Système d’information - Choix techniques concernant les outils de gestion de données
+ MLT Informatisé ( SII ) ( SGBD ) et les outils de développement informatiques .
- Représentation de la structure logique des données ( base de données )
et des traitements ( interaction homme-machine au niveau des postes de
travail )
- Description de l’architecture informatique ( répartition des
traitements et des données )
( Concentration sur le comment de l’informaticien )

Mise en œuvre opérationnelle d’une solution informatique

- Description de la base de données dans la syntaxe du SGBD choisi
MPD Système d ’information - Codage des procédures logiques de traitement en langage informatique
+ MPT Opérationnel ( SIOp ) évolué ( programmation )
- Mise en place d’une architecture de fonctionnement en réseau
( architecture centralisée , distribuée ou répartie )
 Le Modèle Conceptuel de données ( MCD )

Formalisme = Modèle Entité-Association

développé par CHEN aux U.S.A ( 1976 )
puis TARDIEU en France ( 1979 )

Exemple :
1,N
COMMANDE
Commander
Qté commandée N° Commande
0,N Date Commande
1,1
PRODUIT Passer
Ref-Produit commande
Désignation
Prix-unitaire 1,N
CLIENT
Code-Client
Nom-Client
 Notion d’ENTITE

Entité = Représentation d’un objet concret ou abstrait

du S.I caractérisé par :
Nom Entité
* des propriétés ( attributs ) : P1, P2, P3, …..Pn P1
* un identifiant = Propriété ( P1 ) dont les valeurs P2
sont discriminantes Pn
* des occurrences ( instances ) multiples
( au moins 2 )
Etudiant
Exemple Etudiant
Etudiant 125
235
Etudiant 918 ALAMI
SEBASTIEN

N° Inscription DAOUDI ALBERT

DRISS
Nom MOUNIR FRANCAISE
MAROCAINE
Prénom MAROCAINE
Nationalité
Une occurrence d ’entité = 1 jeu de valeurs prises par les
propriétés de l’entité
 Notion d’ASSOCIATION
Une Association traduit les liens sémantiques existant entre 2 ou
plusieurs entités du S.I et de son environnement
Elle est caractérisée par : * Absence d ’existence intrinsèque
* des occurrences ( au moins une )
* des propriétés portées ( nombre M ) M = 0, 1, 2, 3, …
* une dimension N ( N = nombre d ’entités rattachées )
* un identifiant obtenu par concaténation des identifiants
des entités rattachées

Exemple Véhicule Client

Loué par N° Client
N° Immatr.
Date mise en service Nom
Association binaire non Adresse
Kilométrage
porteuse d’identifiant
(N°Immatr.+N° Client )
Service
Salarié N° Service
Matricule Affecté à
Désignation
Date affect.
Nom

Association binaire porteuse d ’1 propriété ( Date Affect ) et d’identifiant ( Matricule.+ N° Service )

 Occurrences d’association
SALARIE
SERVICE
A01
IDRISSI 125
18/05/92 Comptabilité
SALARIE
SERVICE
A12 11/10/91
ALAMI 124
Commercial
SALARIE 04/03/93
SERVICE
A05
RAMI 106
Magasin
SALARIE
A09 * A01-125 , A12-125 et A05-106 sont des instances
DAOUDI de l ’association « Affecté à »

* Les instances A09 ( entité Salarié ) et 124 ( entité Service )

ne participent pas à l’association « Affecté à »
 Cardinalités d ’une Association ( Interprétations )
E1 E2 E1 E1 E2
Assoc. E2 Assoc.
Assoc.

0,1 1,1 1,1 1,1 1,1

E1 E2 0,N
Assoc.
Cardinalités mini :
0 : Certaines occurrences de l’entité peuvent ne pas participer à l’assoc.
1 : Toute occurrence de l’entité participe obligatoirement à l’association
Cardinalités maxi :
1 : Toute occurrence de l’entité participe au plus une fois à l’association
N : Toute occurrence de l’entité peut participer plusieurs fois à l’assoc.
0,N 1,N
Conclusion
* La cardinalité mini traduit la capacité d ’une occurrence à exister
indépendamment ou non des occurrences de l’association .
* La cardinalité maxi traduit la capacité associative de l’association pour
l’entité considérée
 Cardinalités d ’une ASSOCIATION
Cardinalités = Couple de valeurs représentant la fréquence
(mini et maxi ) de participation d’une occurrence d ’entité à une
association )

Entité 1 i1 , j1
Entité 2
Association
i2 , j2
i1 , i2 = cardinalités mini
j1 , j2 = cardinalités maxi
Exemple
Service
Salarié 1,N 1,8 N° Service
Matricule Affecté à
Date affect. Désignation
Nom

Règles de gestion : RG1 - Un salarié est affecté à un et ou pls services le long de sa carrière
RG2 - A un service , on peut affecter un à plusieurs salariés (maximum 8)
 Identifiant d’une Association
Il est obtenu par concaténation des identifiants des entités reliées par l’association

Exemple : Employé Médecin

N° Employé 0,N 0,N N° Médecin
Visiter
Nom Employé Nom Médecin
Nom Employé Date Visite Spécialité
Adresse Client Téléphone

Identifiant = ( N° Employé , N° Médecin )

Occurrences de « Visiter »
N° Employé N° Médecin Date Visite
La dernière occurrence de l’association « Visiter » n’est
23 1 26/06/01 pas permise en raison de la discriminance de l’identifiant .
12 3 05/07/01
39 2 10/08/01
La duplication de l’occurrence ( 42 , 4 ) n’est pas possible !
42 1 15/08/01
42 4 22/08/01
42 4 05/09/01 !!

Question : Un employé peut-il effectuer plusieurs visites chez le même médecin à des dates différentes ?

Réponse : Ce modèle ne le permet pas même si la propriété « Date Visite » est portée par l’association « Visiter »
 Identifiant d’une Association ( Suite )

Solution du Problème : Association ternaire

Employé Médecin
N° Employé 0,N 0,N N° Médecin
Visiter
Identifiant de l’association Nom Employé Nom Médecin
Nom Employé Spécialité
« Visiter » : Adresse Client 0,N Téléphone

Calendrier
( N° Employé , N° Médecin , Date )
Date

Les triplets ( 42 , 4 , 22/08/01 ) et ( 42 , 4 , 05/09/01 ) sont maintenant des occurrences possibles de

l’association « Visiter » car elles représentent des valeurs distinctes de son identifiant .

Ce modèle permet , à l’inverse du précédent , de représenter le fait qu’un employé peut visiter le même
médecin plusieurs fois à des dates différentes .

Généralisation : Une association N-aire ( de dimension N ) possède un identifiant sous forme de

N-uplet dont les valeurs sont distinctes .
Comment doit-on interpréter les cardinalités d’une association ternaire ?
Exemple : Association ternaire ( i2 , j2 )
Médecin
( i1 , j1 ) Visiter
Employé

( i3 , j3 ) Calendrier
• Identification de ( i1 , j1 )
Pour un employé fixé ( occurrence E ) , le couple de N° Employé ( N° Médecin , Date Visite )
cardinalités ( i1 , j1 ) traduit le nombre minimal 1 ( 12 , 08/05/01 )
et maximal d’occurrences du couple d’entités 1 ( 10 , 15/06/01 ) Occurrences
( Médecin , Calendrier ) qui sont associées à 1 ( 6 , 09/06/01 ) de « Visiter »
l’occurrence E . 3 ( 10 , 02/06/01 )
Ici : ( i1 , j1 ) = ( 0 , 3 ) 4 ( 12 , 14/06/01 )
4 ( 10 , 14/06/01 )
5 ( 10 , 02/06/01 )
• Identification de ( i2 , j2 )
N° Médecin ( N° Employé , Date Visite )
Pour un médecin fixé ( occurrence M ) , le couple de
cardinalités ( i2 , j2 ) traduit le nombre minimal 12 ( 1 , 08/05/01 )
et maximal d’occurrences du couple d’entités 10 ( 1 , 15/06/01 )
6 ( 1 , 09/06/01 )
( Employé , Calendrier ) qui sont associées à
10 ( 3 , 02/06/01 )
l’occurrence M . 12 ( 4 , 14/06/01 )
Ici : ( i2 , j2 ) = ( 0 , 4 ) 10 ( 4 , 14/06/01 )
10 ( 5 , 02/06/01 )
• Identification de ( i3 , j3 )
En raisonnant de même pour ( i3 , j3 ) on trouve : ( i3 , j3 ) = ( 0 , 2 )
 Rôles dans une Association
Rôle = Notion précisant le rôle particulier joué par un ensemble
d’occurrences relatives à une entité dans une association .
Les rôles sont portés sur le schéma Entité-Association .
Exemple 1 Livrer Dépôt expéditeur
Nbre colis livrés DEPOT
0,N 0,N

Dépôt destinataire
Code dépôt
CLIENT Recevoir
Adresse dépôt
Code Client Nbre colis reçus 0,N
Nom client 0,N
Adresse client

Dépôt Client Nbre colis livrés Nbre colis reçus

D1 C6 1 - Occurrences de l’association
Dépôt
« Livrer »
expéditeur D3 C2 2 -
D1 C9 - 2
Occurrences de l’association
Dépôt D2 C2 - 5 « Recevoir »
destinataire D4 C6 - 4
 Rôles dans une Association ( suite )
Exemple 2 : Cas d ’une entité réflexive
A pour chef
0,1
SALARIE Encadrer

N° Salarié
Nom Est chef de
Prénom 0,N
Fonction
Salarié
N° Subalterne N° Chef
1 2 Occurrences de
1
5 2 l’association
2 2 4
6 1
3
* Les salariés N° 1 et 2 participent aux 2 rôles de l’association .
4
* Le salarié N° 3 ne participe à aucun des rôles de l ’association .
5
6 * Les salariés N° 4 et 5 participent à un seul des rôles de l ’association.
 Notion d’entité faible et d’identification relative
Une entité faible possède un identifiant relatif qui se rapporte toujours à
celui d’une entité classique . L’identifiant absolu de l’entité faible est
obtenu en concaténant les identifiants des 2 entités.

Formalisme MERISE 2: E1 (1,1)  -,N E2

Exemple :
ETAGE
1,N 
CHAMBRE  N° Etage HOTEL
( 1,1 )
N° Chambre Nbre de toilettes 1,N Code Hotel
( 1,1 )
Surface Adresse Hotel
Nom Hotel

Entité Identifiant relatif Identifiant absolu

HOTEL - Code Hotel -
ETAGE N° Etage Code Hotel + N° Etage
CHAMBRE N° Chambre Code Hotel + N° Etage + N° Chambre
 Notion de Dépendance Fonctionnelle
Définition : 2 propriétés A et B sont en DF si la connaissance d’une
valeur de A détermine une et une seule valeur de B . On dit que A
détermine fonctionnellement B .

Formalisme : A B : 1 source , 1 but

( A, B, …) X : plusieurs sources , 1 but
A ( X, Y, …) : 1 source , plusieurs buts

Exemples : N° Client Nom Client

Nom Client N° Client ( pas de DF )

Prénom Client N° Client ( pas de DF )

( Réf-prod , N° Commande ) Qté prod. commandée

Réf-prod ( Libellé prod. , Prix unit. Prod. )

 AXIOMES ET PROPRIETES DES
DEPENDANCES FONCTIONNELLES
AXIOMES
1 - Réflexivité : X X
2 - Augmentation : X Y => X , Z Y
3 - Additivité : {X Y et X Z } => X Y,Z
4 - Projectivité : X Y,Z => { X Y et X Z }

5 - Transitivité : {X Y et Y Z } => X Z

6 - Pseudo-transitivité : {X Y et Y, Z W } => X, Z W

PROPRIETES
* DF élémentaire : X Y élémentaire si il  Z  X tel que Z Y
* DF directe : X Y directe si il  Z tel que X Z et Z Y
 DEPENDANCES FONCTIONNELLES

1 - Cas d’une Entité

Code Client Nom

CLIENT
Prénom
Code Client Adresse
Nom
Téléphone
Prénom
Adresse Code Client ( Nom , Prénom , Adresse , Téléphone )
Téléphone

Toutes les Propriétés d’une Entité sont en dépendance fonctionnelle directe

avec la propriété identifiante de cette Entité
 DEPENDANCES FONCTIONNELLES
2 - Cas d’une Association hiérarchique ( monovaluée )

COMMANDE CLIENT
1,1 PASSER 0,N Code Client
N° Commande
Nom
Date Commande
Adresse
Montant

DF représentant l’assoc.
N° Commande Code Client Nom

Adresse

Date Commande Montant Téléphone

Occurrences de « PASSER » Une Association Hiérarchique est une association binaire (dimension = 2)
N° Commande Code Client dont l’une des pattes possède une Cardinalité Maxi égale à 1 .
1 4 Ce type d’association est toujours orienté suivant le sens de la
2 9 dépendance fonctionnelle qui relie les identifiants de ses Entités .
3 4
4 6 Remarque : La dépendance fonctionnelle Code Client ---> N°Commande
5 2 n’existe pas car un Client peut passer plusieurs commandes
( exemple du Client N° 4 )
6 4
 DEPENDANCES FONCTIONNELLES
3 - Cas d’une Association N-aire multivaluée non porteuse de propriétés
* Exemple 1 : Association binaire non porteuse
Une Association multivaluée
ACTEUR FILM est une association dont toutes les
JOUER pattes possèdent une Cardinalité
N° Acteur 0,N 1,N N° Film
Maxi égale à N ( N >= 2 ) .
Nom Titre
Prénom Date N° Auteur ( Nom , Prénom )
Production
N° Film (Titre , Date Product. )
DF représentant l’assoc. ( sans but )
( N°Acteur , N° Film ) -
Calendrier
* Exemple 2 : Association ternaire non porteuse
0,N Date

Employé 0,N VISITER

N°Employé ( Nom , Prénom ) N° Employé Médecin
N°Médecin ( Nom Médecin , Spéc. ) Nom
N° Médecin
Prénom 0,N Nom Médecin
DF représentant l’assoc. (sans but) Spécialité
( N° Employé , N° Médecin , Date ) -
 DEPENDANCES FONCTIONNELLES
4 - Cas d’une Association N-aire multivaluée porteuse de propriétés
* Exemple 1 : Association binaire porteuse
PRODUIT
FACTURE 0,N COMPORTER 1,N
N° Facture Réf. Produit
Quantité Produit Désignation
Date Facture
Montant Prix Unitaire

DF représentant l’assoc.
( N° Facture , Réf. Produit ) Quantité Produitc

* Exemple 2 : Association ternaire porteuse

VILLE 0,N Route

TRAJET 1,N
N° Ville
Ville départ N° Route
Nom Ville 0,N Distance Type Route
Nbre Habitants Ville arrivée Etat route

DF représentant l’assoc.
( N° Ville Départ , N° Ville Arrivée , N° Route ) Distance
 DEPENDANCES FONCTIONNELLES

5 - Cas d’une Association Hiérarchique Réflexive

1,1
EMPLOYE N° Employé ( Nom , Prénom , Date Emb. )
Subalterne
N° Employé A pour Chef
Nom
Prénom
1,N DF représentant l’association
Date Embauche Chef

6 - Cas d’une Association Multivaluée Réflexive

PERSONNE 0,N
Parent PARENTE
N° CIN ( Nom , Prénom )
N° CIN
Nom
Enfant

Prénom 0,2
DF représentant l’assoc.
( N° CIN Parent , N° CIN Enfant ) -
 DEPENDANCES FONCTIONNELLES
7 - Cas d’une Association de Cardinalités Maxi égales à 1
Exemple :

FACTURE REGLEMENT
0,1 PAYER 1,1
N° Règlement
N° Facture
Date Règlement
Date Facture
Montant Règlement
Montant Facture

Règles de gestion:
Ce type d’association est orienté
RG1 - Une facture fait l’objet d ’un seul règlement dans les 2 sens pour indiquer
l’existence de 2 dépendances
RG2 - Un règlement compense toujours une seule facture
fonctionnelles entre les identifiants
RG3 - A un instant donné , certaines factures peuvent être impayées . des entités de l’association .

N° Facture N° Règlement

Date Montant
Date Montant Règlement Règlement
Facture Facture
 DEPENDANCES FONCTIONNELLES
8 - Cas des entités faibles
Exemple :
ETAGE
CHAMBRE 
1,N  HOTEL
N° Etage
( 1,1 )
N° Chambre Nbre de toilettes 1,N N° Hotel
( 1,1 )
Surface Adresse Hotel
 1,N
1,1

0,N RESERVATION Code Hotel + N° Etage + N° Chambre

Réserver 1,N N° Réservation

Durée Date Réservation Durée

N° Réservation
Avance en DH + Code Hotel

Règles de gestion:
RG1 - Une réservation est effectuée sur une ou plusieurs chambres
RG2 - Une réservation de client à l’hôtel précise le nombre de nuits relatif à chaque chambre ( durée )
RG3 - Une chambre est identifiée relativement à un étage et à un hôtel particuliers
 Graphe de Dépendances Fonctionnelles

GDF = Représentation graphique de l’ensemble des DF unissant les

propriétés dans un domaine d’activité du système d’information . Ces
propriétés sont obtenues à partir du dictionnaire de données du domaine .

Exemple : GDF du domaine « Gestion commerciale » dans une entreprise

Date
N° Produit Libellé
N° Client
produit
N° Catégorie
Nom Adresse Tél.
Libellé
Client Client Client Qté prod.commandée, catégorie
Mont. ligne commande

N° fournisseur

Nom Adresse Prix achat

fournisseur fournisseur produit
 Le Modèle Logique des Données ( MLD )
But : Représentation de la structure logique des données du S.I sous une forme
adaptée à l’utilisation d’un Système de Gestion de Base de Données
( SGBD ) ou d’un Système de Gestion de Fichiers ( SGF ) .

Différents types de modèles logiques ( machinables ) sont exploités dans le marché des SGF et SGBD :

* Le Modèle Hiérarchique ( années 60 )

Il permet de gérer des données dans un ensemble de fichiers sous forme d’un ensemble d’arbres ou de
hiérarchies . Seuls les liens 1 à N entre enregistrements sont permis ( liens père-fils ) .
Les liens multivaluées ( N à N ) doivent être transformés sous forme de liens 1 à N .
La recherche d’enregistrements se fait en parcourant l’arbre général par une gestion de pointeurs :
du père vers le 1er fils , puis de celui-ci vers le 2ème ou du père vers le grand-père , etc…
Les utilisateurs ne peuvent accéder aux données que par l’intermédiaire de programmes de gestion
de fichiers ( SGF ) écrits spécifiquement pour eux ( Niveau de réutilisation faible ) .
Exemples de SGF : IMS ( IBM )

* Le Modèle Réseau ou CODASYL ( 1971 )

Son but est de lever certaines des contraintes du modèle hiérarchique . Il fonctionne selon le même
principe navigationnel , c’est à dire par pointeurs . Il permet de représenter les liens N à N entre
enregistrements par liaison d’un enregistrement à un ou plusieurs pères et / ou à un ou plusieurs fils.
Il est basé sur les notions de RECORD ( enregistrement ) et de SET ( lien entre 2 enregistrements ) .
Les premiers SGF et SGBD supportant ce modèle sont apparus en 1978 :
Exemples : IDS2 ( Bull ), DBMS ( DEC ), IDMS (Culliname ), ADABAS ( Software AG ), etc...
 Le Modèle Logique des Données ( suite )
* Le Modèle Relationnel ( Codd - 1970 )
C’est le modèle de plus répandu actuellement sur le marché des SGBD ( 85 % en 1995 ).
Il lève toutes les contraintes des modèles précédents ( hiérarchiques et réseau ).
Il a été crée par des mathématiciens . Il permet de gérer les données sous forme de tables
d’enregistrements . En reliant ces tables à l’aide d ’un système de clés , il est possible de
rechercher des données dans une table ou de collectionner des données à partir de plusieurs tables
( requêtes ) satisfaisant un critère fixé .
Exemples de SGBDR ( SGBD Relationnels ) :
INGRES et INFORMIX ( sur UNIX et DEC/VMS )
ORACLE ( sur tous les systèmes )
DB400 ( sur IBM/AS400 )
DB2 et SQL/DS ( sur gros systèmes IBM )
MS-SQL Server ( sur Windows NT/Server )
MS-ACCESS et Borland PARADOX ( sur MS-DOS et Windows )

* Le Modèle Objet ( Années 1990 )

C’est le successeur potentiel du modèle relationnel . Il repose sur la théorie des objets .
Dans cette théorie , le système d’informations peut être représenté comme un ensemble d’objets
possédant des propriétés et des méthodes et communiquant entre eux par échange de messages .
Il s’appuie en amont sur des méthodes de conception de S.I orientées objet comme O.M.T
( Object Modeling Technique ) ou U.M.L ( Unified Modeling Language ) ou O.O.M ( Orientations
objet dans Merise ) , etc…Ce modèle est encore peu utilisé dans le marché commercial mais est appelé
à remplacer le modèle relationnel dans quelques années pour sa puissance et sa sémantique intuitive .
Exemples de S.G.B.D.O ( SGBD Objets ) : O2 ( IBM )
 Le Modèle Logique de Données Relationnel ( MLDR )
Ce modèle permet de constituer une base de données au sens logique au moyen de tables
désignées aussi sous le terme de relations .

Les Concepts du MLDR

1 ) L’attribut : C’est le plus petit élément d’information enregistré dans une base de données .
Il possède un nom et prend des valeurs dans un domaine de valeurs bien déterminé .
Exemples :
Attribut Domaine de valeurs
N° Client Entier naturel
Adresse Client Alphanumérique
Mode de paiement Liste alphabétique (Espèces,Chèque ,Traite)

2 ) La Relation : Une relation ( appelée aussi table ) est un ensemble d’attributs significativement
associés ( dont l’association a un sens au niveau du S.I ) .

Représentation d’une relation : R ( A1, A2 , A3, …….., An ) Représentation en intention

ou Schéma de la relation

R A1 A2 A3 ….. An Représentation en extension

tuple 1 ……… …….. …….. ….. ……… ( montrant les tuples de la relation )
tuple 2 valeur valeur valeur ….. Valeur
……. …….. …….. …….. ….. …….. R : Nom de la relation
tuple n …….. ……… …….. ….. …….. A1, A2 , …., An : Attributs de la relation
 Le Modèle Logique de Données Relationnel ( suite 1 )
Une relation est un sous-ensemble du produit cartésien des domaines de valeurs associés à ses attributs.

Exemple : Soient 2 attributs dont les domaines de valeurs sont :

D1 = ( Ahmed , Brahim , Ali ) et D2 = ( Mineur , Majeur )

D1 x D2 Nom Statut R Nom Statut

Ahmed Mineur Ahmed Mineur
Brahim Mineur Brahim Majeur
Ali Mineur Ali Mineur
Ahmed Majeur Ahmed Majeur
Brahim Majeur
Ali Majeur R est un exemple de relation incluse dans D1 x D2 .
( Toutes les relations qu’il est possible de créer à partir
Le produit cartésien D1 x D2 représente la des attributs ‘Nom’ et ‘Statut‘ sont incluses dans D1 x D2 )
relation dont le nombre de tuples est le plus grand

3 ) Les clés d’une relation : soient 3 relations comportant certains attributs communs :
R1 ( A1# , A2 , A3, …….., An )
R2 ( B1# , B2 , B3 , …….., Bn , A1# )
R3 ( A1# , B1# , C1, C2 , C3 , ….., Cn )

Les attributs suivants jouent un rôle particulier :

- A1# dans R1 et B1# dans R2 sont appelés clés primaires : Chacun de ces attributs a été choisi pour
identifier de manière discriminante
les tuples de sa relation .
 Le Modèle Logique de Données Relationnel ( suite 2 )
- A2 est une clé candidate pour R1 à condition que A2 soit un attribut discriminant pour les tuples
de R1 comme c’est le cas de A1#. Une clé candidate est un
attribut ou un groupe d’attributs qui aurait pu servir de clé
primaire mais qui n’a pas été retenu .

- A1# dans R2 est une clé étrangère : c’est un attribut défini sur un domaine primaire ( celui de R1 )
mais qui est présent dans une autre relation ( R2 ) dans le but
de créer un lien entre les relations R1 et R2 .

- A1# et B1# dans R3 représentent une clé primaire composée :

C’est un groupe d’attributs définis chacun sur un domaine
primaire . Les occurrences de ce groupe ( couples de valeurs
de A1# et B1# ) sont utilisées pour identifier de manière
discriminante les tuples de la relation R3 .

- Remarques: * une clé primaire ( simple ou composée ) est toujours soulignée dans une relation .
* une clé étrangère ( ou externe ) peut être composée comme dans le cas d’une clé primaire
* l’attribut ou les attributs constituant une clé primaire ou étrangère possèdent un nom
qui se termine par le symbole #
* une relation est toujours identifiée par une clé primaire
* une relation peut présenter une ou plusieurs clés candidates (clés primaires de substitution)

4 ) Schéma relationnel : C’est un ensemble de relations logiques présentant des liens sémantiques .
Cet ensemble est destiné à la création d’une base de données physique .
 Le Modèle Logique de Données Relationnel ( suite 3 )

5 ) Les Contraintes d’Intégrité :

Elles représentent un ensemble de règles fondamentales dont l’application permet de garantir

la cohérence du schéma relationnel d’une base de données .

Ces règles contrôlent la cohérence des valeurs prises par :

* les attributs par rapport à leur domaine de valeurs (contrainte d’intégrité de domaine)
Exemple : Si l’attribut ‘ N° Client ’ est défini sur un domaine de valeurs numériques , il ne
peut pas contenir de lettres .

* les clés primaires des relations ( contraintes d’intégrité de relations )

L’intégrité de relation concerne les valeurs d ’une clé primaire qui doivent être uniques
( pas de doublons ) et non nulles ( toujours spécifiées ) .

* les clés étrangères des relations ( contraintes d’intégrité référentielles )

L’intégrité référentielle stipule qu’une clé étrangère ne peut prendre que les valeurs définies dans
le domaine primaire de la clé primaire à laquelle elle est associée .
 Construction du Modèle Logique de Données Relationnel
Le MLDR est construit à partir du MCD en appliquant des règles de transformation simples
aux entités et aux associations .
Les entités donnent toujours lieu à des relations dans le MLDR .
Les associations , selon leur cardinalités , peuvent ou non donner lieu à des relations .

1 ) Transformation des Entités

Relation A
ENTITE A Ao A1 A2 A3
Clé
Identifiant Ao
Propriété A1
Propriété A2
Propriété A3

Une entité A du MCD devient la relation ( ou table ) : A ( Ao# , A1 , A2 , A3 )

L’identifiant Ao de l’entité A devient la clé primaire Ao# de la relation A .

Les autres propriétés deviennent les attributs de la relation A .
Les occurrences de l’entité deviennent les tuples de la relation A .
Le degré de la relation A est le nombre d’attributs de cette relation ( ici deg (A) = 4 )
La cardinalité de la relation A désigne le nombre de tuples de cette relation
 Construction du Modèle Logique de Données Relationnel ( suite 1 )

2 ) Transformation des Associations

2.1 ) Association multivaluée plusieurs [ 0, N ou 1, N ] à plusieurs [ 0, N ou 1, N ]

ENTITE A ENTITE B

*,N *,N Identifiant Bo

Identifiant Ao Association Propriété B1
Propriété A1 Propriété B2
Propriété A2
Propriété A3

Représentation graphique du MLDR

Relations obtenues : A , B et C
A ( Ao# , A1 , A2 , A3 )
A C
B ( Bo# , B1 , B2 )
Cas d’une association non porteuse : C ( Ao# , Bo# ) Ao # B
Ao #
Cas d’une association porteuse des propriétés : C1, C2,... A1 Bo # Bo #
C ( Ao# , Bo# , C1 , C2 , …) A2 B1
A3 B2
Exemple :
Relations obtenues :
DEPOT ARTICLE
1,N 0,N
N° Dépôt Code Article DEPOT ( N° Dépôt # , Adresse, Ville )
Stocker
Adresse Libellé ARTICLE ( Code Article # , Libellé , Qté Stock )
Ville Qté stock STOCKER ( N° Dépôt # , Code Article # )
 Construction du Modèle Logique de Données Relationnel ( suite 2 )
2.2 ) Association hiérarchique Un [ 0, 1 ou 1, 1 ] à Plusieurs [ 0, N ou 1, N ]

ENTITE A ENTITE B

*,1 *,N Identifiant Bo

Identifiant Ao Association Propriété B1
Propriété A1
Propriété B2
Propriété A2

Cette association traduit la dépendance fonctionnelle inter-entités : Ao Bo

L’entité A qui émet la dépendance fonctionnelle reçoit au niveau logique l’identifiant de l’autre entité B .
La clé primaire Bo # migre dans la relation A comme attribut clé étrangère ou externe .

Relations obtenues : A,B Représentation graphique du MLDR

A ( Ao# , A1 , A2, Bo# ... ) A B

B ( Bo# , B1 , B2 , ...) Ao # Bo #
A1 B1
Exemple : A2 B2
Bo #
Employé Relations obtenues :
Matricule 1, 1 1, N SERVICE
EMPLOYE ( Matr. # , Nom , Prénom ,
Nom CIF N° Service Fonction , N° Service # )
Prénom Libellé Service SERVICE ( N° Service # , Libellé Service )
Fonction
 Construction du Modèle Logique de Données Relationnel ( suite 3 )
2.3 ) Association hiérarchique Un [ 0, 1 ou 1, 1 ] à Un [ 0, 1 ou 1, 1 ]

ENTITE A ENTITE B
Identifiant Ao *,1 Association *,1 Identifiant Bo
Propriété A1 Propriété B1
Propriété A2 Propriété B2

Cette association traduit l’existence de 2 dépendances fonctionnelles inter-entités : Ao Bo et Bo Ao

La migration de clé peut se faire dans un sens ou l’autre selon les besoins du système d’information .
Si la cardinalité d’un côté de l’association est 1, 1 ( exemple côté Entité A ) , il est conseillé de choisir
la migration de la clé primaire Bo # dans la relation A comme clé étrangère ( règle équivalente au cas
d’une association hiérarchique )
Relations obtenues : A,B Représentation graphique du MLDR

A ( Ao# , A1 , A2, Bo# ... ) A B

B ( Bo# , B1 , B2 , ...) Ao # Bo #
A1 B1
A2 B2
Exemple : Bo #

FACTURE Relations obtenues :

REGLEMENT
0, 1 1, 1
N° Facture N° Règlement FACTURE ( N° Facture # , Date Facture ,
Date Facture Payer
Date Règlement Montant TTC )
Montant TTC Montant Règl. REGLEMENT ( N° Règl. # , Date Règl. ,
Montant Règl. , N° Facture # )
Construction du Modèle Logique de Données Relationnel ( suite 4 )
2.4 ) Association réflexive multivaluée Plusieurs [ 0, N ou 1, N ] à Plusieurs [ 0, N ou 1, N ]

*,N
ENTITE A
Représentation graphique
Identifiant Ao Association du MLDR
Propriété A1
Propriété A2
A
*,N
Ao #
Relations obtenues : A,B A1
A2 B
A ( Ao# , A1 , A2 , ... )
Ao1 #
B ( Ao1# , Ao2# ) : Cas d’une assoc. non porteuse Ao2 #
B ( Ao1# , Ao2# , B1 , B2 , ...) : Cas d’une assoc. porteuse B1
B2
Exemple :
Est parent de Relations obtenues :
PERSONNE 0, N
N° CIN PERSONNE ( N° CIN # , Nom , Prénom )
Parenté
Nom
Prénom 0, 2 PARENTE ( N° CIN_Parent # , N° CIN_Enfant # )
Est enfant de
Construction du Modèle Logique de Données Relationnel ( suite 5 )
2.5 ) Association réflexive hiérarchique Un [ 0, 1 ou 1, 1 ] à Plusieurs [ 0, N ou 1, N ]

*,N
ENTITE A
Représentation graphique
Identifiant Ao Association du MLDR
Propriété A1
Propriété A2
A
*,1
Ao #
A1
Relation obtenue : A A2
Ao‘ #
A ( Ao# , A1 , A2 , ... , Ao’ # )

Exemple :

Est Chef de Relation obtenue :

SALARIE
0, N
Matricule SALARIE ( Matricule # , Nom , Prénom ,
Nom
Encadrement Fonction , Matricule_Chef # )
Prénom 0, 1
Fonction A pour Chef
Construction du Modèle Logique de Données Relationnel ( suite 6 )
2.6 ) Association relative incluant une entité faible

ENTITE A ENTITE B

(1,1) *,N Identifiant Bo

Ident. Relatif Ao
Propriété A1  Propriété B1
Propriété B2
Propriété A2

Cette association traduit le rattachement d’une entité faible ( A ) à une entité classique ( B ) .
L’identifiant absolu de l’entité A est : Ao + Bo .

Relations obtenues : A,B Représentation graphique du MLDR

A ( Ao# , Bo# , A1 , A2, ... ) A B

L ’attribut Bo # dans A est
B ( Bo# , B1 , B2 , ...) Ao # Bo # une clé étrangère qui forme
Bo # B1 avec Ao # une clé primaire
A1 B2 composée .
Exemple : A2

PROJET
PHASE Relations obtenues :
( 1, 1 ) 1, N N° Projet

N° Phase PROJET ( N° Projet # , Nom Projet , Date début )
Nom Projet
Désignation PHASE ( N° Projet # , N° Phase # ,
Date début
Durée Désignation , Durée )
 Construction du Modèle Logique de Données Relationnel ( suite 7 )
4 ) Application : Schéma relationnel d’un service clientèle dans un café

SERVEUR MLDR
1# 1,N 0,N CALENDRIER
AFFECTER
2 SERVEUR ( 1 # , 2 )
9#

1,N 1,N
CALENDRIER ( 9 # )

0,N AFFECTER ( 1 #, 9 # , 3 # )
SUIVRE 1,N TABLE
3#
CONCERNER TABLE ( 3 # )
1,1 TRAITER
1,1 COMMANDE ( 11 #, 12, 10 ,
1,1
COMMANDE 1 #, 3 #, 9 # )
11 # CONSOMMATION
FIGURER 1,N FIGURER ( 11 # , 4 # , 7 , 8 )
12 1,N 4 #
10 5
7 CONSOMMATION ( 4#, 5 , 6 )
8 6

Dictionnaire de données

1 - N° de serveur 7 - Quantité d ’une consommation commandée

2 - Nom de serveur 8 - Montant d ’une ligne de commande
3 - N° de table 9 - Date de commande
4 - N° de consommation 10 - Heure de la commande
5 - Libellé consommation 11 - N° de la commande
6 - Prix unitaire consommation 12 - Montant total de la commande
 LE LANGAGE DE REQUETES SQL
1 – Origines et évolutions
- SQL est dérivé de l’algèbre relationnelle et du langage SEQUEL ( Structured English Query Language )

- Il a été intégré dès 1986 aux plateformes SQL / DS, DB2 , puis ORACLE , INGRES ,
INFORMIX , etc…

- Il existe 3 versions normalisées , du plus simple au plus complexe :

* SQL 1 ( 1986 ) : le langage de base
* SQL 1 ( 1989 ) : addendum ( contraintes d’intégrité sur les données )
* SQL 2 ( 1992 ) : langage complet à 3 niveaux
* SQL 3 ( 1998 ) : Les évolutions orientées objet ( SQL 3 n’est pas encore le nouveau standard )

2 – Les 3 niveaux du langage SQL

* Langage de définition de données ( LDD ) : Il permet de spécifier un schéma conceptuel de BD
CREATE , ALTER et DROP ( tables , indexes et vues )

* Langage de manipulation de données ( LMD ) : Il permet d’interroger et de manipuler les données

SELECT , INSERT , UPDATE , DELETE , OPEN , FETCH , CLOSE , etc…

* Langage de contrôle de données ( LCD ) : Il permet de gérer la sécurité des données, les transactions
et les accès concurrents
GRANT et REVOKE , BEGIN et END TRANSACTION , COMMIT et ROLLBACK, etc…
 LE LANGAGE DE MANIPULATION DE DONNEES ( LMD )

Les ordres LMD sont des instructions SQL créées à partir des commandes suivantes :
Commande Rôle
SELECT Interroger une base de données en vue d’extraire les enregistrements qui répondent à
des critères particuliers
INSERT Insérer ( charger ) des lots de données dans la base de données en une seule opération
UPDATE Modifier ( mettre à jour ) des valeurs d’attributs dans une table ou bien des valeurs
d’enregistrements entiers répondant à des critères particuliers
DELETE Supprimer des enregistrements dans une table de base de données sélectionnés d’après
un critère donné .

Chaque commande peut utiliser une ou plusieurs clauses obligatoires et des clauses optionnelles .
Les clauses permettent de définir l’origine et la nature des données qu’il faut sélectionner ou manipuler .
Clause Rôle
FROM Nommer une ou plusieurs tables ou vues à partir desquelles les enregistrements doivent
être sélectionnés
WHERE Spécifier des conditions de jointure et / ou de sélection sur les enregistrements
GROUP BY Spécifier les attributs de regroupement lors d’une opération de calcul et / ou
regroupement
HAVING Spécifier des conditions de sélection sur les enregistrements obtenus après une
opération de regroupement
ORDER BY Trier les enregistrements sélectionnés pour être projetés dans un ordre particulier
 LE LANGAGE DE DEFINITION DE DONNEES ( LDD )

Les ordres LDD sont des instructions SQL créées à partir des commandes suivantes :

Commande Rôle

CREATE Création de la structure d’une table , d’un index ou d’une vue de

données en spécifiant des contraintes structurelles ou d’intégrité
référentielle à respecter sur les données

DROP Supprimer une table , un index ou une vue ( structure et données )

ALTER Modifier la structure d’une table ( ajout , suppression ou mise à jour

d’un ou plusieurs attributs )

Chaque commande peut utiliser une ou plusieurs clauses obligatoires et des clauses optionnelles