Module 1 : Les bases de données relationnelles

Page 1 sur 32Lecteur de document UniversityLib

Module 1 : Les bases de données relationnelles

Database Design and Modeling · notes

Browse all bases de données documents

Module 1 : Les base de données relationnelles

Section 1 : Conception

d’une base de données

Riadh ZAAFRANI

Octobre 2020

1ère année MP2L

1

Objectifs du cours

 Ce cours va vous permettre de maîtriser le

processus de conception d'une base de

données relationnelle :

 Connaître

les

concepts

du modèle

Entité/relation,

 Maîtriser la démarche de construction du

modèle Entité/relation.

 Connaître les erreurs à ne pas commettre.

2

1

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

3

Modélisation conceptuelle

 Avant de s'attaquer à tout problème,

il est

toujours nécessaire de réfléchir profondément

aux tenants et aboutissants de ce que l'on veut

réaliser.

 La phase de conception nécessite souvent de

choix qui auront parfois des

nombreux

répercussions importantes par

la suite. La

conception de bases de données ne fait pas

exception à la règle.

4

2

Modélisation conceptuelle

 Les théoriciens de l'information ont donc

proposé des méthodes permettant de

sa pensée et présenter de

structurer

manière abstraite le travail que l'on souhaite

réaliser.

 Ces méthodes ont donné naissance à une

un métier,

l'analyse,

et

discipline,

l'analyste.

5

Modélisation conceptuelle

 L'analyse est

la discipline qui étudie et

présente de manière abstraite le travail à

effectuer.

 La phase d'analyse est

très importante

puisque c'est elle qui sera validée par les

utilisateurs avant

la mise en œuvre du

système concret.

6

3

Modéliser les données

 Il existe de nombreuses méthodes d'analyse

la plus utilisée en

(AXIAL, OMT etc...),

France étant la méthode Merise.

 Merise sépare les données et les traitements

à effectuer avec le système d'information en

différents modèles conceptuels et physiques.

 Celui qui nous intéresse particulièrement ici

est le MCD ou le modèle Entité-Relation (ER)

.

7

Modèle Entité-Relation (ER)

 Le schéma conceptuel d’une base de

données décrit ses principaux objets,

leurs caractéristiques et leurs relations, à

l’aide d’un formalisme appelé modèle de

données.

 Nous

utiliserons

le modèle Entité-

Relation(ER), en raison de sa large

diffusion.

8

4

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

9

Les entités

 Une entité est définie comme un objet pouvant être

identifié distinctement.

 Cet objet peut représenter un individu (un client), un

(un compte

(un livre) ou abstrait

objet concret

bancaire) ayant une existence propre ou des

évènements (une commande).

 Un ensemble d'entités contient des entités similaires,

mais distinguables deux à deux.

 Exemples : des personnes, des voitures dans un

parking, une bibliothèque de livres...

10

5

Les entités

 Les entités sont décrites par des attributs,

caractéristiques ou propriétés.

 Chaque attribut associe à une entité une

réels,

valeur dans un domaine (entiers,

chaînes de caractères ...)

11

Les entités

 Exemples :

 L'ensemble d'entités personne a les attributs : nom,

prénom, age, adresse …

 nom associe à l’entité personne une chaîne de

caractères.

 Age associe à l’entité personne un entier court.

 livres a les attributs : numéro du livre (entier à 4

chiffres ) auteur(chaîne de 20 caractères) titre (chaîne

de 50 caractères) éditeur (chaînes de 25 caractères)

12

6

Les entités

 On

appelle

un

déclaration

ensemble constitué des attributs d'une

entité :

d'entité,

 Pour le livre :

 Livre(numéro_du_livre, auteur, titre, éditeur)

13

Les entités

 Il ne faut pas confondre la déclaration d'entité avec

l'instance de l'ensemble des entités à un instant donné :

 livres = {

(2004," François le Berre"," les bases de données

bretonnes", "les éditions du far"),

(1515," François 1er"," la bataille de Marignan","

historia"),

(12 693," gilles desrocques"," les bases du paramoteur","

cavole"),

(309," gilles desrocques"," introduction a l'ULM"," cavole")

…}

14

7

Les entités

 Différentes

entités

valeurs

identiques. Toutefois, elles doivent avoir une valeur au

moins distincte.

certaines

Advertisement

peuvent

avoir

 On appelle une surclé un ensemble d'attributs (parfois

réduit à un seul) caractérisant l'entité :

 Si l'ensemble d'entités E a les attributs A1, A2, ... Ap,

si e a les valeurs d'attributs (a1,a2, ..., ap),

et f a les valeurs d'attributs (a'1,a'2, ..., a'p),

alors si e est différent de f, l'un des ai au moins est différent

de l'un des a'i.

 L'ensemble A1, A2, ... Ap est une surclé pour l’entité.

15

Les entités

 Lorsque l'ensemble des Ai est minimal on

dira que la surclé est une clé.

 Une clé ou un identifiant est un ensemble

minimal

de

déterminer une et une seule entité à

l’intérieur de l’ensemble.

permettant

d'attributs

 Deux entités différentes doivent avoir des

clés différentes.

16

8

Les entités

 Exemple :

 un numéro de sécurité sociale caractérise une

personne : c'est une clé

 un

nom,

adresse

prénom et

caractérisent une personne, c'est une autre clé.

une

un

 On voit que deux clés d'une même entité

peuvent avoir un nombre d'attributs différent.

17

Les entités

 La clé est

représentée en souligné dans le

modèle (ER).

nom de l'entité

Clé

liste des propriétés

Représentation d'une entité

18

9

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

19

Les associations

 On appelle relation ou association une liste

ordonnée d'ensemble d'entités : A = (E1,E2, ... Ek).

 Où k est Le nombre d’entités impliquées dans une

relation. k est appelé dimension ou degré de la

relation.

 La relation peut être :

 dimension 1 : dans ce cas, elle ne concerne qu’une

entité type dont elle relie deux éléments. Elle est dite

réflexive. Par exemple, la relation a_pour_père relie

deux éléments de l’entité type PERSONNE ;

20

10

Les associations

 dimension 2 : c’est le cas le plus fréquent,

on dit que l'association est binaire ;

 dimension 3 : par exemple, une location de

voiture représente une relation entre un

véhicule, une personne et une date. Cette

relation est ternaire dans la mesure où elle

ne peut être décomposée en deux ou trois

relations binaires équivalentes.

21

Les associations

 De façon générale, une relation peut être

caractérisée par n dimensions.

 Les associations sont caractérisées, comme

les entités, par un nom et éventuellement

des attributs.

 L'identifiant d'une association est constitué

de la réunion des identifiants des entités qui

participent à l'association.

22

11

Les associations

 Le

schéma

peut-être

conceptuel

représenté

graphiquement pour en faciliter la lecture et

la

compréhension. Habituellement, on représente les

entités dans des rectangles et les relations dans

des ellipses. Les attributs identifiants des entités

sont soulignés.

Personne

Service

travaille dans un

23

Attributs associés à une association

 Lorsque l'on a déterminé un couple d'entités

(certaines valeurse1,e2) et que l'on souhaite

associer à ce couple, on associe un attribut à cette

association (comme pour une entité).

 Exemple 1 :

 Un employé peut passer 25% de son temps dans

un service et 75% de son temps dans un autre.

L'association "travaille dans" qui relie une personne

à un service portera la propriété "volume de

temps passé".

24

12

Attributs associés à une association

 Exemple 2 : lorsqu'une personne emprunte un livre on

d'emprunt.

souhaite

EmpruntéPar(personne, livre, dateEmprunt).

conserver

date

la

 Cette date n'aurait aucun sens dans l'entité personne,

ni dans l'entité livre, puisqu'il peut y avoir différentes

dates d'emprunts pour une même personne de même

que le livre peut-être emprunté à différentes dates.

 En définitive, un attribut d'association, ne peut être

connu que lorsque l'on connaît chacune des entités

associées.

25

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

26

13

Les cardinalités

 Une cardinalité est un couple de valeurs indiquant les

nombres minimum et maximum d'éléments associés.

C'est-à-dire les nombre maximum et minimum de liens

réels que peut recevoir une instance d’entité pour une

association donnée.

 Les cardinalités maximales sont nécessaires pour la

création de la base de données. Ces cardinalités

traduisent les règles de gestion ou les contraintes propres

aux entités et relations.

 Les cardinalités minimales sont nécessaires pour

exprimer les contraintes d'intégrité.

27

Les cardinalités

 Par exemple une personne peut avoir entre 0 et 30

enfants, un livre peut avoir entre 1 et 10 auteurs

etc.

 A un instant donné, un livre peut être emprunté 0

ou 1 fois.

 Lorsque l’on ne souhaite pas préciser on met 0,n

28

14

Relation entre cardinalité et type

de l'association

Type

E1

Advertisement

E2

exemple

1 :1

(0,1) ou (1,1)

(0,1) ou (1,1)

aPourConjoint

1 :n

(0,n) ou (1,n)

(0,1) ou (1,1)

edite

n :1

(0,1) ou (1,1)

(0,n) ou (1,n)

EditéPar

m :n

(0,m) ou (1,m)

(0,n) ou (1,n)

ecritPar

29

Exemple de schéma

Personne

Service

1-N

travaille dans un

1-N

Volume

 De ce schéma on en déduit que "une personne peut

travailler dans plusieurs services".

 On constate de plus que "dans chaque service il y a au

moins 1 personne mais qu'il peut y en avoir plusieurs".

Enfin, une mesure du "volume de travail" est stockée

pour chaque personne travaillant dans un service donné.

30

15

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

31

Modèle Entité-Relation étendu ou

enrichi (EER)

 Dans un modèle ER de base, on n’utilise

que les cardinalités maximales.

 Celui-ci peut–être utilement étendu en y

cardinalité

concepts

intégrant

minimale et de généralisation d’entités.

les

de

 Muni de ces extensions, il est généralement

appelé modèle ER étendu ou enrichi.

32

16

Modèle Entité-Relation étendu ou

enrichi (EER)

 La généralisation d’entités permet de décrire un

même ensemble d’entités à différents niveaux

d’abstraction.

 Ainsi, un même ensemble de personnes travaillant

dans une entreprise peut-être divisé selon la

qualification, le sexe, etc. Cette précision permet

par exemple d’enrichir le schéma conceptuel en

représentant, pour chaque relation, l’ensemble des

entités réellement impliquées dans la relation.

33

Modèle Entité-Relation étendu ou

enrichi (EER)

 On distingue deux catégories d’entités : les

entités faibles et les entités régulières.

 Une entité est dite faible si son existence

dépend de l’existence d’une autre entité.

 Par

exemple,

une

n’existe

entité

que

LIGNE DE

l’entité

si

COMMANDE

COMMANDE correspondante est présente.

34

17

Modèle Entité-Relation étendu ou

enrichi (EER)

 Cette dépendance d’existence se traduit souvent –

mais ce n’est pas une règle de conception – par

une dépendance au niveau de l’identification de

cette entité.

 Autrement dit,

l’entité faible aura un identifiant

composé de l’identifiant de l’entité dont elle dépend

et d’un autre attribut.

 Les entités qui ne sont pas faibles sont dites

régulières. Graphiquement, on peut encadrer les

entités faibles d’un double rectangle.

35

Modèle Entité-Relation étendu ou

enrichi (EER)

 A

toute

situation

peuvent

correspondre plusieurs schémas différents, avec

leurs avantages et leurs inconvénients.

à modéliser,

 Il est

souvent peu aisé de dégager une

modélisation largement supérieure aux autres.

 Se pose alors le problème d’évaluation des

différentes modélisations.

 En d’autres termes, cela revient à mesurer

la

qualité d’une modélisation ER ou EER.

36

18

Modèle Entité-Relation étendu ou

enrichi (EER)

 Pour ce faire, on peut combiner

les critères

suivants :

 l’expressivité : Elle traduit la richesse sémantique

du schéma. Elle peut être caractérisée par

exemple par

le nombre de concepts et/ou de

contraintes exprimés dans le schéma ;

 la minimalité : Elle tend à privilégier les schémas

redondances

nombre

de

un

introduisant

minimales ;

37

Modèle Entité-Relation étendu ou

enrichi (EER)

 la

: Elle

consiste

lisibilité

la

représentation graphique proprement dite, par

exemple en préférant un schéma où un minimum

d’arcs se croisent ;

évaluer

à

 la simplicité : Elle privilégie les

schémas

contenant un nombre de concepts minimum. On

le

peut, par exemple,

nombre d’entités et d’associations présentes sur

un schéma.

la mesurer en calculant

38

19

La démarche de conception

 La démarche d’un schéma conceptuel peut-être

conduite de la façon suivante :

 1) Déterminer la liste des entités

 2) Pour chaque entité :

 Etablir la liste de ses attributs

 Parmi ceux-ci ; déterminer un identifiant.

 3) Déterminer les relations entre les entités.

La démarche de conception

 4) Pour chaque relation :

 Dresser la liste des attributs propres à la

Advertisement

relation.

 Vérifier la dimension (binaire, ternaire, etc.).

 Définir les cardinalités (1-1, 1-N, ou M-N).

 5) Vérifier le schéma obtenu, notamment :

 Supprimer les transitivités.

 S’assurer que le schéma est connexe.

 S’assurer qu’il répond aux demandes.

 6) Valider avec les utilisateurs.

39

40

20

La démarche de conception

 Pour vérifier un schéma connexe, nous vérifions

qu’il existe un chemin de tout point (entité ou

relation) à tout autre dans le schéma.

 En effet, le schéma ER est supposé traduire une

seule réalité, même complexe. Les différents

éléments du schéma ER doivent « se retrouver »

autour d’entités et de relations fondamentales

représentant

aux

données

différents traitements.

nécessaires

les

41

42

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

21

Classes et attributs

 Classe : Groupe d’entités du monde réel

ayant les mêmes caractéristiques et le

même comportement

ex. ETUDIANT

 Attribut : Propriété de la classe

ex. Nom et Prénom de l’étudiant e

 Représentation graphique :

Types des attributs

 Type d’attribut :

 Nombre entier (Entier)

 Nombre réel (Réel)

 Chaîne de caractères (Chaîne)

 Date (Date)

43

44

22

Instances

 Objets(individus) de la classe ETUDIANT =

les étudiants :

Problème : Comment distinguer les Dupont ?

45

Identifiant (1/2)

 Solution : Ajouter un attribut numéro d’étudiant !

46

23

Identifiant (2/2)

 Le numéro d’étudiant est un attribut

identifiant.

 Un identifiant caractérise de façon unique les

instances d’une classe.

 Convention graphique :

NB: Ne pas confondre avec les attributs de

classe UML dont c’est la notation usuelle

47

Associations

 Association : liaison perçue entre des classes

ex. Les étudiants passent des épreuves.

 Les classes ETUDIANT et EPREUVE peuvent être

qualifiées de participantes à l’association PASSER.

 Degré ou arité d’une association : nombre de

classes participantes.

En général : associations binaires (de degré 2).

48

24

Associations récursives

 Une classe peut être associée à elle-même, chaque

instance pouvant jouer plusieurs rôles dans

l’association.

ex. Employés et supérieurs hiérarchiques

 Rôle : fonction de chaque

classe participante (+).

49

Multiplicité (ou cardinalité)

 Définition : Indicateur qui montre combien

d’instances de la classe considérée peuvent être

liées à une instance de l’autre classe participant à

l’association

– 1

– 0..1

– 0.. ou

– 1..*

– M..N

Un et un seul

Zéro ou un

Zéro ou plus

Un ou plus

De M à N (M, N entiers)

ex. 4..10 (de 4 à 10)

50

25

Classes-associations

 Il est possible de caractériser une association par

des attributs.

ex. Un étudiant e qui passe une épreuve obtient une

note.

NB : Une classe-association demeure une association.

51

Plan

Modélisation conceptuelle

Les entités

Les associations

Les cardinalités

Modèle Entité-Relation enrichi

Modèle conceptuel UML

Les erreurs à ne pas commettre

52

26

Les erreurs à ne pas commettre

 *) Surestimer la dimension d’une relation :

 Considérons par exemple la relation entre trois

entités : FOURNISSEUR, CLIENT et PRODUIT.

PRODUIT

Commande

CLIENT

Code_produit

Désignation

Prix

1-N

Quantité

Dernière_date

1-P

FOURNISSEUR

Code_fournisseur

nom

adresse

1-M

Code_client

Nom

Adresse

53

Les erreurs à ne pas commettre

 Cette relation caractérise le fait qu’un client donné

commande un produit donné à un fournisseur donné.

 Cette relation peut être caractérisée notamment par la

quantité commandée.

 Si cette relation est ternaire, la quantité commandée

peut être la quantité totale commandée de ce produit

par ce client à ce fournisseur.

 Elle peut être au contraire la dernière quantité

commandée de ce produit par ce client à ce

fournisseur.

54

27

Les erreurs à ne pas commettre

 Si on souhaite enregistrer toutes les commandes

de ce produit par ce client à ce fournisseur, alors la

relation

quatrième

dimension étant la date de la commande.

quaternaire,

devient

la

 Si on ne souhaite qu’une information synthétique,

la relation est alors ternaire, la date de la dernière

commande pouvant être une caractéristique de la

relation et non une dimension.

Advertisement

55

Les erreurs à ne pas commettre

PRODUIT

Code_produit

Désignation

Prix

CLIENT

Code_client

Nom

Adresse

1-N

Commande

1-M

Quantité

FOURNISSEUR

1-P

Code_fournisseur

nom

adresse

1-Q

DATE

Date

56

28

Les erreurs à ne pas commettre

 Notons que le problème de définition de la

dimension de la relation se pose très fréquemment

avec la notion de temps. Le problème sous-jacent

est celui de l’archivage des données détaillées.

 Quand la date est

participant à la relation, elle permet

intégral de tous les évènements ou transactions.

intégrée comme une entité,

l’archivage

 Dans le cas contraire,

les informations sont

agrégées dans la relation et la date peut-être un

attribut ;

57

Les erreurs à ne pas commettre

 *) Attribuer à une relation les

entités

attributs

participantes, ou inversement :

des

 Dans de nombreux cas,

la

pièce

il n’est

pas évident de déterminer

le

propriétaire d’un attribut. Dans

l’exemple ci-dessous, l’attribut prix

de

être

caractéristique de l’entité PIECE si

cette dernière provient toujours du

même fournisseur. Dans le cas

une

contraire,

le

relation

caractéristique

Provenance.

prix

de

peut

est

la

PIECE

PIECE

prix

Provenanace

Provenanace

prix

FOURNISSEUR

FOURNISSEUR

58

29

Les erreurs à ne pas commettre

 *) Exprimer

des

relations

redondantes,

c'est-à-dire

déductibles par transitivité :

 Lorsqu’un schéma ER contient un cycle de relations (deux, trois

ou plus) – en d’autres termes, le graphe présente une boucle- il

est nécessaire de s’interroger sur l’éventuelle redondance ainsi

exprimée.

Employé

1

Travaille

N

PROJET

1

1

Rattaché_à

Géré_par

N

N

DEPARTEMENT

59

Les erreurs à ne pas commettre

 Dans l’exemple précédent, la relation Rattaché_à exprime

la composition des relations Travaille et Géré_par. Ainsi un

employé est rattaché au département qui gère le projet pour

lequel il travaille.

 Si la relation Rattaché_à ne porte pas d’attribut spécifique,

si elle a la même durée de vie que les autres relations et si

les trois relations sont de cardinalité 1-N, alors elle est

redondante, n’exprimant que la transitivité des deux

autres. Dans ce cas, elle doit être supprimée.

 En revanche, si une des conditions citées n’est pas vérifiée,

la relation Rattaché_à doit être maintenue ;

60

30

Les erreurs à ne pas commettre

 *) Se tromper de niveau de discours :

 Le schéma ER doit représenter fidèlement le monde

réel.

 Ainsi, les entités doivent représenter des ensembles

d’objets ou de concepts.

 A titre d’exemple, si

l’on informatise la gestion d’un

ensemble de magasins, MAGASIN est une entité,

c'est-à-dire un ensemble d’entités magasin ayant des

caractéristiques du même type (code, nom, adresse,

gérant, etc.).

61

Les erreurs à ne pas commettre

 En revanche, si l’on conçoit la gestion d’un

l’univers du

magasin,

discours et ne recouvre pas un ensemble

d’entités.

le magasin est

 Il ne figure donc pas de façon explicite dans

le schéma ;

62

31

Les erreurs à ne pas commettre

 *) Introduire des attributs calculés :

 Sauf exception, un schéma conceptuel ne doit pas

contenir d’information redondante, tels des attributs

la valeur est calculable à partir d’autres

dont

attributs. Par exemple,

total d’une

commande, dont les différents éléments (ligne de

commande, montant hors taxe,

taux des taxes)

sont présents dans le schéma, ne doit pas figurer

sous forme d’attribut

le montant

63

Les erreurs à ne pas commettre

 Au niveau du schéma physique, les valeurs

stockées

pourront

les

pour

être

redondantes

délibérément

améliorer

performances de la base de données.

64

32