Les bases de données

Pr Daoudi Imane
Le plan
 Introduction
 Base de donnée
 SGBD
 SI entreprise
 Merise
 Niveau conceptuel
 Niveau Logique
 Niveau physique
 Introduction
- Bases de données

Qu’est qu’une base de données??

3
 Introduction
- Bases de données

 Une base de données

 Ensemble de données modélisant les objets d'une partie du monde
réel et servant de support à une application informatique

 Ensemble de données interrogeable par le contenu

• Exemple :
les produits de prix >100 DH

 Ensemble de données interrogeable à partir des relations entre

données
• Exemple:
Les produits commandés par un client habitant Casablanca

4
 Introduction
- Bases de données

 Une base de données (autre définition)

un ensemble structuré de données (1) enregistrées sur des

supports accessibles par l’ordinateur (2) pour satisfaire
simultanément plusieurs utilisateurs (3) de manière
sélective (4) en un temps opportun (5).

– (1) : Organisation et description de données

– (2) : Stockage sur disque
– (3) : Partage des données
– (4) : Confidentialité
– (5) : Performance

5
 Introduction
- SGBD

Qu’est qu’un SGBD?

6
 Introduction
- Bases de données

 SGBD= Système de Gestion de Base de données

DATA BASE MANAGEMENT SYSTEM (DBMS)

 Ensemble de logiciels systèmes permettant de gérer

(d'insérer, modifier et de rechercher des données) une BD
partagée par plusieurs utilisateurs simultanément

Base de données Programme 1

Fichier 1 SGBD Programme 2
Fichier 2
Fichier 3 Programme 3
7
 Introduction
- Système d’information dans l’entreprise

o L’entreprise est un système complexe dans lequel transitent de très nombreux

flux d’informations. Sans un dispositif de maîtrise de ces flux, l’entreprise peut
très vite être dépassée et ne peut plus fonctionner avec une qualité de service
satisfaisante.

o L’enjeu de toute entreprise industrielle ou de services consiste donc à mettre

en place un système destiné à collecter, mémoriser, traiter et distribuer
l’information.

o Ce système d’information assurera le lien entre deux autres systèmes de

l’entreprise : système de pilotage et le système opérant

8
 Introduction
- Système d’information dans l’entreprise

o Le système de pilotage décide les actions à exécuter par le système opérant

en fonction des objectifs et des politiques de l’entreprise.
o Le système opérant englobe toutes les fonctions liées à l’activité propre de
l’entreprise : facturer les clients, régler les salariés, gérer les stocks, …

9
 Introduction
- Architecture d’un système d’information

o Le système d’information doit décrire (ou représenter) le plus fidèlement

possible le fonctionnement du système opérant. Pour ce faire, il doit
intégrer une base d’information dans laquelle seront mémorisés la description
des objets, des règles et des contraintes du système opérant. Cette base subit
des évolutions.

o Le système d’information doit être doté d’un mécanisme (appelé processeur

d’information) destiné à piloter et à contrôler ces changements.

10
 Introduction
- Architecture d’un système d’information

o Le processeur d’information produit des changements dans la base

d’information à la réception d’un message.
o L’architecture présentée ci-dessus induit une double conception :
• Celle de la base d’information (aspect statique),
• Celle du processeur de traitement (aspect dynamique).
o Pour aider le concepteur dans ces deux tâches, la méthode Merise propose
un ensemble de formalismes et de règles destinées à modéliser de manière
indépendante les données et les traitements du système d’information.

11
 Présentation de la méthode Merise

• Pour la méthode MERISE, la conception des systèmes

d’information (SI) est réalisée selon la démarche suivante :

12
 Présentation de la méthode Merise

o Le schéma directeur : dont le rôle est de définir, de manière globale, la

politique d’organisation et d’automatisation du système d’information.
Pour ce faire, il est nécessaire de répertorier l’ensemble des applications
informatiques existantes à modifier et à développer.
• L’étude préalable (par domaine) : doit aboutir à une présentation
générale du futur système de gestion (modèles de données et de
traitements) en indiquant les principales novations par rapport au
système actuel,
• L’étude détaillée (par projet) consiste d’une part à affiner les solutions
conçues lors de l’étude préalable et d’autre part à rédiger, pour chaque
procédure à mettre en œuvre, un dossier de spécifications détaillé
décrivant les supports ainsi que les algorithmes associés aux règles de
gestion… A l’issue de cette étude, il est possible de définir le cahier des
charges ainsi que le fonctionnement détaillé du futur système, du point
de vue de l’utilisateur.
• La réalisation l’objectif est l’obtention des programmes fonctionnant sur
un jeu d’essais approuvés par les utilisateurs.

13
Présentation de la méthode Merise
- Niveaux d’abstraction

14
 Présentation de la méthode Merise
- Niveaux d’abstraction

Niveau Conceptuel
• Ce qu’il faut faire
• Quoi ?
Niveau Organisationnel
• La manière de faire
• Pour les traitements
Niveau Logique
• Choix des moyens et ressources
• Pour les données
Niveau Physique
• Les moyens de le faire
• Comment ?
15
 Présentation de la méthode Merise
- Le niveau conceptuel

Exprime les choix fondamentaux de gestion.

Définit
• Des activités
• Des choix de gestion
• Des informations
Indépendamment
• Des aspects organisationnels
• Des aspects techniques de mise en œuvre

16
 Présentation de la méthode Merise
- Le niveau organisationnel

Exprime les choix organisationnels de ressources humaines et

matérielle
Définit:
– La répartition géographique et fonctionnelle des sites de travail (du
point de vue des données et des traitements)
– Le mode de fonctionnement : temps réel ou temps différé.
– La répartition du travail homme/machine (degré et type
d’automatisation)
– Les postes de travail et leur affectation,
• Indépendamment des moyens de traitement et de stockage de
données actuels ou futurs

17
 Présentation de la méthode Merise
- Le niveau logique

• Exprime la forme que doit prendre l’outil informatique pour être

adapté à l’utilisateur, à son poste de travail
• Indépendamment des langages de programmation ou de gestion
des données
• Décrit
– Le schéma de la base de données (relationnel, hiérarchique ou
réseau)
– La répartition des données sur les déférentes unités de stockage
– Les volumes par unité de stockage

18
 Présentation de la méthode Merise
- Le niveau physique

• Traduit les choix techniques et la prise en compte de leurs

spécificité

• Répond aux besoins des utilisateurs sur les aspects logiciels et

matériels.

19
 Présentation de la méthode Merise
- Exemple de niveaux d’abstraction
Exemple :
Niveau Conceptuel
• Le client effectue une demande de service à la compagnie pour assurer
son véhicule. Cette dernière lui propose un devis
Niveau Organisationnel
• Un client effectue une demande de service à l’agence de son choix, par
courrier, pour assurer un véhicule. Un agent de service concernée, si le
client est fiable (consultation d’un fichier central inter assurances), prend
contact par téléphone pour une visite à domicile (après 17 heures) afin
d’examiner plus précisément ses besoins et établir un devis
Niveau Physique
• Le fichier central inter assurances est accessible par internet. Les
agences sont connectées au siège de la compagnie par liaison ADSL.
Chaque agence dispose de micro-ordinateurs de type PC et peut traiter
ses données en local grâce au SGBD Access

20
Présentation de la méthode Merise
- Les modèles

21
 Niveau conceptuel

Modèle Conceptuel de Données (MCD)

 Modèle conceptuel de données (MCD)

La problématique des données

• Il ne suffit pas de s’intéresser au nom et aux propriétés des données :

type, longueur, valeurs.
• Il faut s’intéresser à la donnée elle-même, ses sens et ses usages.
• Exemple: sens du mot « client »

Libellé FR Sens

Client Correspond à la personne donneur d’ordre

Client de
Désigne la personne destinataire des factures
facturation
Client payeur Désigne la personne qui paye les factures

23
 Modèle conceptuel de données (MCD)

La problématique des données

 Il faut aussi se poser des questions sur la qualité des données existantes et
les exigences de qualité.
Contradiction Hors nomenclature
(pb de cohérence) (pb de conformité et Incohérence
d’intégrité)

Date Code
n°ss Nom Prénom sexe Adresse Ville Téléphone
naissance Postal

3, rue de la
171046734543621 Dupond Albert 10/04/1971 F 99999 Strasbourg 01 32145678
gare

Rue des
268065415498494 Durant Lise 18/06/1968 F 54000 Nancy 0345762345
Lilas

0345762345
268065415498494 Durant Lisa 18.06.1968 F 54000 Null

Erreur de Format
(pb de conformité)
Doublon Pb d’intégrité
Erreur de saisie (pb Absence de valeur 24
(pb d’unicité) référentielle
d’exactitude) (pb de complétude)
 Modèle conceptuel de données (MCD)

Objectif du MCD

Ecrire de façon formelle les données d’une base de données. Il s'agit

donc d'une représentation des données, facilement compréhensible,
permettant de décrire la base de données à l'aide d'entités.

 Il est à la base de tous les SGBD dits relationnels (Access,

Oracle, DB2…) qui sont les plus utilisés actuellement dans les
entreprises.

 Il est généralement représenté à l’aide du formalisme «entités-

associations » sous la forme de :

ENTITES, ASOCIATIONS et ATTRIBUTS.

25
 Modèle conceptuel de données (MCD)

Entité
Concept concret ou abstrait (un fait, un moment…) identifié du
monde réel caractérisé par un nom et une liste de propriétés.

 Une entité concrète possède une existence physique : client,

équipement, et produit
 Une entité abstraite a une existence conceptuelle : une transaction,
un tarif, l’annulation d’un vol d’avion
 Exemples
 Le client Jean Dupond est une entité concrète
 La commande COM0001 est une entité abstraite
 L’entité Personne(nom, prénom), et l’entité Voiture(nom , puissance
fiscale) ne peuvent pas être groupés en une même entité car ils ne
partagent pas leurs propriétés
.
Client

L’ entité se représente par un cadre contenant

26
le nom de l’entité
 Modèle conceptuel de données (MCD)

Attribut (Entité)
Propriété d’une entité ou d’une association caractérisée par un nom et
un type élémentaire.
 Est un élément d’une entité :
– a un nom unique,

– permet de mémoriser une valeur,

– doit avoir un sens (donc une valeur) pour chacune des occurrences de l’entité.
 Exemple

Client Entité
N_client
Nom Attributs
Prénom

Représentation graphique d’une entité comportant trois attributs

27
 Modèle conceptuel de données (MCD)

Règles concernant les attributs

Règle 1
Un attribut ne peut en aucun cas être partagé par plusieurs
entités/associations.

Règle 2
Un attribut est une donnée élémentaire, ce qui exclut des données
calculées ou dérivées.

Règle 3
Une entité et ses attributs doivent être cohérents entre eux (i.e. ne
traitent qu’un seul sujet).

28
 Modèle conceptuel de données (MCD)

Occurrence: entité

Elément particulier d’une entité, identifiable de façon unique (instance)

 Deux occurrences de l’entité ne peuvent pas avoir la même valeur d’identifiant.

 Exemple

L’entité client1 dont le N° est 06464M est une

occurrence de l’entité client
Client 1 Client 2
064646M 012646M
Dupont Revaud
Frank jerome
23 BD zola 2 BD alpha

29
 Modèle conceptuel de données (MCD)

Identifiant: entité

Attribut ou groupe d’attributs permettant d’identifier chaque

occurrence d’une entité.

Règle 4
Chaque entité possède au moins un identifiant, éventuellement
formé de plusieurs attributs.

 Exemple

Client
N°client Identifiant
Nom simple
Prénom
Adresse

30
 Modèle conceptuel de données (MCD)

 identifiant : entité (suite)

 Il existe 2 types d’identifiants: simple et composé

 Un identifiant est simple s’il est formé d’un seul attribut

 Un identifiant est composé s’il est formé de plusieurs attributs,

 Exemple:
 Entité avec identifiant composé

Appartement
N°Appt Identifiant
Adresse composé
Superficie

31
 Modèle conceptuel de données (MCD)

Association

Lien logique entre entités dont le type est défini par un verbe et une
liste éventuelle de propriétés

 On appelle collection de l’association l’ensemble des entités qu’elle relie.

Règle 5
Un attribut peut être placé dans une association uniquement
lorsqu’il dépend de toutes les entités liées par l’association.

32
 Modèle conceptuel de données (MCD)

 Association : exemple

Nom de l’association

Client Commande
N°client Effectuer N°Commande
Nom Date Date livraison
Prénom Commande Total commande
Adresse

Extrémités de
l’association

collection de
l’association

33
 Modèle conceptuel de données (MCD)

 Association : identifiant

 Il est implicite !
– C’est un ensemble composé des identifiants de la collection de l’association.

Règle 6
La concaténation des identifiants des entités liés à une
association constitue l’identifiant de cette association (cet
identifiant n’est pas mentionné sur le modèle (il est implicite).
 Exemple:
– l’identifiant de l’association « effectuer » est le couple (N° client, N° commande)

Client
Commande
N°client Effectuer N°Commande
Nom Date Commande
Prénom Date livraison
Adresse Total commande

34
 Modèle conceptuel de données (MCD)

 Association : cardinalités (1)

Contrainte inscrite à chaque extrémité d’une association comportant un
couple de valeurs (min-max) qui établit, pour chaque entité de
l’association, le nombre minimum et maximum d’occurrences d’une
association auxquelles elle peut participer

 Exemple
– Un client peut effectuer de 0 à n commande, mais une commande ne
peut être effectuer que par un seul client

Source Sens de lecture Destination

Client Commande
N°client (0,n) Effectuer (1,1) N°Commande
Nom Date Commande
Prénom Date livraison
Adresse Total commande
35
 Modèle conceptuel de données (MCD)

 Association : cardinalités (2)

Règle 7&8
Règle 7: L’expression de la cardinalité est obligatoire pour chaque
patte d’une association
Règle 8: Une cardinalité minimal est toujours 0 ou 1, et une cardinalité
maximale est toujours 1 ou n

 Remarques
– Une cardinalité maximale de 0 n’a pas de sens
– Si une cardinalité maximale est connu et vaut 2, 3 ou plus, alors nous
considérons qu’elle est indéterminée et vaut n
– Les cardinalités minimales qui valent plus de 1 sont modélisées par 1

 Les seules cardinalités admises sont:

cardinalités signification
0,1 Au plus un
1,1 (ou 1) Un seul
0,n (ou *) Un nombre indéterminé
1,n Au moins un
36
 Modèle conceptuel de données (MCD)

 Association : cardinalités (2)

Une extrémité sans contrainte aura

pour cardinalité (0,n)

Client Commande
N°client (0,n) Effectuer (1,1) N°Commande
Nom Date Commande
Prénom Date livraison
Adresse Total commande

37
 Modèle conceptuel de données (MCD)

 Association : cardinalités (3)

Client Commande
N°client (0,n) Effectuer (1,1) N°Commande
Nom Date Commande
Prénom Date livraison
Adresse Total commande

 Sur l’extrémité client, le 0 signifie que le client peut ne pas être reliée à la commande
lors de sa création.

 Le 1 en minimum de l’extrémité commande signifie qu’en aucun cas on ne peut créer

une occurrence de l’entité commande sans la relier en même temps à une occurrence
de l’entité client…Cette dernière doit donc avoir été créée avant !

38
 Modèle conceptuel de données (MCD)

 Occurrence d’une association

Une occurrence d’une association relie une seule occurrence de chacune des
entités participant à l’association

 Exemple:
 Le client 1 effectue la commande 1
 Le client 2 effectue la commande 2
 La commande 1 est effectuée par le client 1
 La commande 2 est effectuée par le client 2

Client Commande
N°client (0,n) Effectuer (1,1) N°Commande
Nom Date Commande
Prénom Date livraison
Adresse Total commande

39
 Modèle conceptuel de données (MCD)

 Règles absolues!! (1)

Une association binaire de cardinalité minimale et

maximale égale à un ne peut en aucun cas porter de
propriétés !

Entité1 Entité2
N°Entité 1 (0,n) Association (1,1) N°Entité 2
Nom Entité 1 Nom Entité 2
Prénom Entité 1 Attribut Prénom Entité 2
etc etc

Faux

40
 Modèle conceptuel de données (MCD)

 Règles absolues!! (2)

Une association binaire ne peut en aucun cas porter

des cardinalités 1,1 des deux extrémités !

Entité1 Entité2

N°Entité 1 (1, 1) Association (1,1) N°Entité 2

Nom Entité 1 Nom Entité 2
Prénom Entité 1 Prénom Entité 2
etc etc

Faux

41
 Modèle conceptuel de données (MCD)

 Les associations plurielles

Deux mêmes entités peuvent être plusieurs fois en associations

Personne Livre
(0,n) Être l’auteur (1,n)
Nom Titre
Prénom Editeur
Adresse (0,n) Avoir critiqué (0,n)

42
 Modèle conceptuel de données (MCD)

 Les associations réflexives

Une association réflexive est une association reliant des

occurrences de la même entité

Parent
Personne
(0,n) Être parent
N°
Nom
Prénom Enfant
Adresse
(1,n)

43
 Modèle conceptuel de données (MCD)

 Les associations ternaires

Une association ternaire est une association qui décrit un

lien sémantique entre trois entités

A (0,n) (0,n)
Association B
idA
idB

(0,n)
C

idC

Difficile à gérer en pratique !!!

Il faut essayer d’en avoir le moins possible
44
 Modèle conceptuel de données (MCD)

 Les associations ternaires

Créneau horaire Salle

(0,n) Projeter (1,n)
N° Créneau N° Salle
Date Capacité
Heure de début
(0,n)
Film

N° Film
Titre
Durée

45
 Modèle conceptuel de données (MCD)

 Les associations ternaires: décomposition

 On remplace l’association ternaire (ou n-aire) par une entité et on lui attribut
un identifiant

 On crée des associations binaires entre la nouvelle entité et toutes les

autres entités de la collection de l’ancienne association

 La cardinalité de chacune des associations binaires crées est 1,1 du côté

des entités créé et 0,n ou 1,n du côté des entités de la collection de
l’ancienne association

46
 Modèle conceptuel de données (MCD)

 Les associations ternaires

Créneau horaire Salle
N°créneau N°Salle
0,n 1,n Capacité
Date
H de début Projeter

0,n
Créneau h
Film Projection 1,1 Avoir lieu 0,n
dans N°créneau
N°Film N°projection
Titre Date
Tarif
Durée Heure de début

1,1
Salle
Concerner Film
N°Salle
Capacité N°Film
0,n Titre
Durée

47
 Modèle conceptuel de données (MCD)

Entités A retenir….

Règle 1 Toute entité présente dans un MCD doit obligatoirement comporter un

identifiant

Règle 2 Pour chaque occurrence d’une entité, chaque attribut ne peut prendre
qu’une valeur

Règle 3 Un attribut ne peut en aucun cas être partagé par plusieurs entités/associations

Règle 4 Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou
dérivées

Règle 5 Deux occurrences de l’entité ne pourraient avoir la même valeur pour leur
identifiant

48
 Modèle conceptuel de données (MCD)

Associations
A retenir….
Règle 6 Un attribut peut être placé dans une association uniquement lorsqu’il dépend
de toutes les entités liées par l’association

Règle 7 La concaténation des identifiants des entités liés à une association constitue
l’identifiant de cette association (cet identifiant n’est pas mentionné sur le
modèle (il est implicite).

Règle 8 L’expression de la cardinalité est obligatoire pour chaque patte d’une

association
Règle 9 Une cardinalité minimal est toujours 0 ou 1 est une cardinalité maximale est
toujours 1 ou n
Règle 10 Une association binaire de cardinalité (1,1) ne peut en aucun cas porter de
propriétés !

Règle 11 Une association binaire ne peut en aucun cas porter des cardinalités 1,1 des
deux extrémités !

49
 Modèle conceptuel de données (MCD)

 Règles portant sur les noms

Dans un modèle entités-associations, le nom d’une entité, d’une

association, ou d’un attribut doit être unique

Enseignant Etudiant Personne

N° Enseignant N° Etudiant Fusionner N° Personne

Nom Nom Nom
Prénom Prénom Prénom

Client Facture
N° client Correspondre N° Facture
0,n 0,n
Nom Date
Prénom Adresse de facturation
Adresse de facturation

50
 Modèle conceptuel de données (MCD)

 Règles de normalisation des attributs

un attribut multiple doit être remplacé par une association et une entité
supplémentaires

Employé Adresse

N° Employé 1,n N°adresse

Nom Code postal
Employé Habiter Ville
Prénom Normaliser
Adresse principale
N°Employé 1,n
Adresse secondaire
Nom
N° tél domicile principale
Prénom
N° tél domicile
secondaire 1,n
N° portable Num tél
Posséder
N°num tél
1,n
type

51
 Modèle conceptuel de données (MCD)

 Règles de normalisation des attributs

Un attribut est une donnée élémentaire, ce qui exclut des données

calculées ou dérivées

Commande Article

N° commande 0,n Contenir 0,n N° Article

Date Quantité Désignation
Montant total Prix unitaire

52
 Modèle conceptuel de données (MCD)

 Règles de fusion/ suppression entités/associations

Il faut factoriser les entités quand c’est possible

Généraliste Dentiste Ophtalmologue

N°généraliste N°dentiste N°Ophtalmologue

Nom Nom Nom
Prénom Prénom Prénom
Adresse Adresse Adresse

Médecin
N°médecin
Nom
Prénom
Adresse
Spécialité 53
 Modèle conceptuel de données (MCD)

 Règles de fusion/ suppression entités/associations

Il faut factoriser les entités quand c’est possible, mais l’introduction
d’un attribut supplémentaire n’est pas toujours nécessaire

Ecrivain
Ecrire
N°Ecrivain 0,n Ecrire
Nom
Prénom 0,n 0,n
Adresse
Personne Livre

Abonné 0,n N°Personne N°Livre

Nom Titre
0,n
Livre Prénom Editeur
N°Ecrivain
Emprunter Adresse
Nom N°Livre
0,n
Prénom 0,n 0,n
Titre
Adresse Editeur Emprunter

54
 Modèle conceptuel de données (MCD)

 Règles de fusion/ suppression entités/associations

Il faut factoriser les associations quand c’est possible

Joueur de Tennis Joueur de Tennis

N°joueur
Nom N°joueur
0,n Prénom 0,n Nom
Genre Prénom
Classement Genre
Classement
0,n

0,n 0,n
Jouer
Jouer en tant Jouer en tant Jouer en tant Jouer en tant Type
que joueur 1 que joueur 2 que coéquipier que coéquipier
1 2
1,1 0,1 1,n
Match de Tennis
Match de Tennis
N°Match
1,1 0,1
N°Match Type
Type

55
 Modèle conceptuel de données (MCD)

 Règles de fusion/ suppression entités/associations

Il faut aussi se poser la question de l’intérêt de l’association quand les
cardinalités maximale sont toutes de 1

Fournisseur

N°fournisseur
Nom 1,1
Prénom
Adresse Fournisseur

Travailler chez Fusionner N°fournisseur

Nom
Prénom
Contact Adresse
Nom contact
N°contact
1,1 N°tél contact
Nom contact
N°tél contact

56