Cours

Bases de Données Relationnelles

Dr. Safa Hachani

hachanisafaa@gmail.com

ENIB 2021/2022
Démarche de développement
• Le processus de conception des données passe par deux phases :
- Réalisation d’un modèle conceptuel
- Traduction en un modèle relationnel
 Chapitre 2 :

Validation du modèle E-A et

Passage au modèle relationnel
1. PROBLÉMATIQUE ET DÉMARCHE
Problématique Démarche Vérification Validation Passage ML Normalisation Application

Problématique
Qu’est-ce qu’une BD relationnelle ‘incorrecte’ ?

Une BD est incorrecte si :

- Elle implique des répétitions au niveau de sa population,
- Elle pose des problèmes lors des maj (insertions, modifications et suppressions),
Exemple : Livraison (N°fourn, adrF, N°prod, prixP, qté)

Exemple d'anomalies de MAJ

- Si un fournisseur change d’adresse et qu’un seul tuple est mis à jour ⇒ incohérence
- Si un nouveau tuple est inséré pour un fournisseur connu, avec une adresse différente
⇒incohérence
- Si un fournisseur n'a pas de livraison en cours, son adresse est perdue …
Problématique Démarche Vérification Validation Passage ML Normalisation Application

Démarche
Les conditions pour qu'une table soit correcte peuvent être définies formellement
⇒ Règles de validation du modèle E-A (validation des attributs, élimination de TA
redondants, etc.)
2. VERIFICATION ET VALIDATION
DU MODELE E-A
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Règles de vérification d'un modèle E-A

Une fois le modèle conceptuel EA établi, plusieurs types de vérification doivent être
effectuées:

Vérification "syntaxique": il s'agit de vérifier que les règles du modèle entité association
sont respectées (concepts du modèle + règles de vérification d'un schéma).

Vérification par jeu d'essai: le concepteur vérifie grâce à une mini base de données que:
- le schéma permet effectivement de stocker les informations nécessaires à l’application
- le modèle contient tous les types d'information nécessaires à l'exécution des
traitements prévus (complétude par rapport aux traitements).

Validation par retour auprès des utilisateurs: le concepteur présente le schéma

accompagné des définitions (DD et DF) aux personnes qui utiliseront la base de données et
vérifie que les informations contenues correspondent bien aux besoins.

→ Chaque oubli, erreur, modification, ...., détecté lors des vérifications entraîne une mise
à jour du modèle et relance les différentes phases de vérification.
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Vérification de la cohérence syntaxique

Vérification "syntaxique": il s'agit de vérifier que les règles du modèle entité association
sont respectées (concepts du modèle + règles de vérification d'un schéma).

Règles de vérification :
- Toute entité possède un identifiant
- Tous les attributs d’une entité sont atomiques et mono-valués
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Vérification de la cohérence syntaxique

Vérification "syntaxique": il s'agit de vérifier que les règles du modèle entité association
sont respectées (concepts du modèle + règles de vérification d'un schéma).

Règles de vérification :
- Toute entité possède un identifiant
- Tous les attributs d’une entité sont atomiques et mono-valués
- Pas de TA redondant : si les associations correspondantes peuvent être établies par
composition des associations d'autres TA.
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Vérification de la cohérence syntaxique

Vérification "syntaxique": il s'agit de vérifier que les règles du modèle entité association
sont respectées (concepts du modèle + règles de vérification d'un schéma).

Règles de vérification :
- Toute entité possède un identifiant
- Tous les attributs d’une entité sont atomiques et mono-valués
- Pas de TA redondant : si les associations correspondantes peuvent être établies par
composition des associations d'autres TA.
- Pas d’attributs d’entité traduisant une association: si l'on trouve dans un TE un attribut
qui est identifiant d'un autre TE, c'est que cet attribut exprime un lien entre les TE.
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Vérification de la cohérence syntaxique

Vérification "syntaxique": il s'agit de vérifier que les règles du modèle entité association
sont respectées (concepts du modèle + règles de vérification d'un schéma).

Règles de vérification :
- Toute entité possède un identifiant
- Tous les attributs d’une entité sont atomiques et mono-valués
- Pas de TA redondant : si les associations correspondantes peuvent être établies par
composition des associations d'autres TA.
- Pas d’attributs d’entité traduisant une association: si l'on trouve dans un TE un attribut
qui est identifiant d'un autre TE, c'est que cet attribut exprime un lien entre les TE.
⇒ Il convient donc de corriger le schéma: le lien doit être explicitement décrit comme un
TA entre les deux TE et l'attribut doit être supprimé du TE.
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Règles de Validation d'un modèle E-A

M. E-A Non
Valide
M. E-A Vérifiée
Vérification syntaxique
+ Jeu d’essai M. E-A Validé
Validation (Règles de DF)
Après la vérification syntaxique et par jeu d’essai d'un modèle entité association, il faut
valider le modèle auprès des utilisateurs (M. E-A, DD et DF).

Le concept de dépendance n'est pas propre au modèle entité-association; c'est un concept

générique qui est utilisé aussi bien en entité-association qu'en relationnel pour exprimer
les propriétés intrinsèques des données.

Validation des modèles : quelques règles formelles permettent de valider le modèle:

validation des attributs, validation des TA, etc.

1- Nous introduisons le concept de dépendance entre données ou entre types d'entité.

2- Nous présentons par la suite les règles de validation du modèle après avoir introduit la
notion de dépendance à partir de laquelle ces règles sont énoncées.
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Notion de dépendance
Définition: étant donné un attribut, ou un ensemble d'attributs, A, d'un TE (ou TA),
et B un attribut du même TE (ou TA), il y a :

- Dépendance A vers B, notée A → B , si dans la population du TE (ou TA) toutes

les occurrences qui ont même valeur pour A ont toujours même valeur pour B.
⇒ On dit que B dépend de A, ou que A détermine B.

Exemple:

Adresse → num, rue, ville

- Les attributs Nom, Prénom et Adresse du TE PERSONNE dépendent de NumP.

- La connaissance des dépendances permet de vérifier si le modèle élaboré
traduit correctement la réalité de l'application à décrire. Quelques règles
permettent de corriger ou de valider le modèle.
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Validation du modèle E-A

Règle 1: Validation des attributs d'un TE

Dans un TE (TA) valide, tous les attributs directs dépendent de chaque identifiant
entier du TE (TA). On dit aussi que l'identifiant d'un TE (ou TA) détermine tous les
autres attributs du TE (TA). Sinon le TE (TA) est incorrectement défini.

Exemple: tous les attributs dépendent de l'identifiant entier NumP. Le TE

PERSONNE est donc correctement défini.

Adresse → num, rue, ville

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Validation du modèle E-A

Règle 2: Validation des associations (1:n) et (n:1)

- Un attribut direct (du premier niveau) dépend de l'identifiant.

- Un attribut identifiant d’un TE - A en association de type (1:n) avec une TE –B
détermine l’attribut identifiant de TE- B et inversement.
Si idB → idA alors le cas d’une association n:1
Si idA → idB alors le cas d’une association 1: n

Exemple : Association (1:n)

Hypothèse : un fournisseur ne peut produire qu'un seul type
de produit, qui peut être fourni par plusieurs Fournisseurs.

Les attributs du TE Fournisseur respectent la R2:

- numFour → adresse
- nomP →description, prix
- numFour → nomP (l’identifiant de produit)
Problématique Démarche Vérification Validation Passage ML Normalisation Application

Validation du modèle E-A

Règle 3: Validation des attributs d'un TA de type (n:n)

La règle 1 est appliquée ici aux TA. Les attributs directs du TA dépendent de
l'identifiant entier, qui dans un TA est composé de tous les identifiants des TE liés
au TA.

Exemple :

Dans cet exemple, le modèle est valide puisque la règle 3 est respectée:
- l'attribut Date_achat du TA POSSEDE dépend à la fois de l'identifiant NumB du
TE BATIMENT et de l'identifiant NumP du TE PERSONNE.
- NumP, NumB → Date_achat
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Gestion de ventes/Achats
On considère une société qui vend des produits à des clients. Ces produits sont
achetés par la société chez des fournisseurs.
Un client possède un nom, et une adresse. Un client peut passer une ou plusieurs
commandes.

Une commande est identifiée par un numéro, elle concerne de manière générale
un ou plusieurs produits commandés en quantités différentes. Toute commande a
de plus une date de commande et de facturation bien déterminées. La date de
facturation est postérieure à la date de commande.

Un produit est identifié par une désignation ; il possède aussi une date de
fabrication et un prix unitaire. Chaque produit ne peut être fourni à la société que
par un et un seul fournisseur. Les fournisseurs sont identifiés par un numéro,
possèdent des noms et des numéros de téléphones.

Q- vérifier le modèle conceptuel correspondant a cet énoncé.

 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Gestion de ventes/Achats
Client Commande 1,n (n:n)
nomClient numeroCommande
adrClient 1,n (n:1) 1,1 dateCommande concerner
Travaille
passer dateFacturation
1,n pour Qté
(n:n)
1,n
commander
Fournisseur
Produit
numeroFournisseur
(n:1) desProduit
nomFournisseur
tel1Fournisseur fournir dateFabProd
1,1 0,n
tel2Fournisseur
1,n prixUnitaireProd

tel3Fournisseur

Vérification :
1- l’ entité client ne possède pas d’identifiant. 3- L’ association commander est redondante

2- Tous les attributs sont: 4- les attributs « tel fournisseurs » traduisent

- Élémentaires une nouvelle entité et association
- Mono-valués
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Gestion de ventes/Achats
Client Commande 1,n
numeroClient
(n:n)
numeroCommande
nomClient (n:1) 1,1 dateCommande concerner
adrClient 1,n Travaille dateFacturation
passer
pour Qté

(n:1)
Fournisseur fournir Produit
1,1
1,n desProduit
numeroFournisseur
dateFabProd
nomFournisseur 0,n
prixUnitaireProd
Téléphone
(n:1)
1,n
IdTel
NuméroTelephone
posséder
1,1
R2: numeroCommande → numeroClient
Validation: Les dépendances Fonctionnelles : desProduit → numeroFournisseur
R1: numeroClient → nomClient, adrClient IdTel → numeroFournisseur
numeroCommande → dateCommande, dateFacturation
numeroFournisseur → nomFournisseur, telFournisseur
desProduit → dateFabProduit, prixUnitaireProd
R3: numeroCommande, desProduit → Qté
3. Passage au Modèle Relationnel
Problématique Démarche Vérification Validation Passage ML Normalisation Application

Passage au modèle logique

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Définition du modèle logique

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Définition du modèle logique

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Formalisme

NomRelation (CléPrimaire, att1, att2, .. , #CléEtrangère)

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Formalisme

NomRelation (CléPrimaire, att1, att2, .. , #CléEtrangère)

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Règles de passage au ML
Règle 1: Transformation d’un TE

- Toute entité est transformée en une relation

- L’identifiant de l’entité devient la clé primaire de la relation
- Les autres attributs de l’entité représentent les champs de la relation

Personne (ID, Nom, Prenom)

 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Règles de passage au ML
Règle 2: Transformation d’une association de type 1:n ou n:1

- Toute entité est transformée en une relation

- L’identifiant de l’entité devient la clé primaire de la relation
- Les autres attributs de l’entité représentent les champs de la relation
- La clé primaire de la relation du coté n, devient une clé étrangère dans la relation du coté 1.

(1:n)

Personne (ID, Nom, Prenom, #IDAdr)

Adresse (ID, Voie, CP, Ville)
 Problématique Démarche Vérification Validation Passage ML Normalisation Application

Règles de passage au ML
Règle 3: Transformation d’une association de type n:n
- Toute entité est transformée en une relation
- L’identifiant de l’entité devient la clé primaire de la relation
- Les autres attributs de l’entité représentent les champs de la relation
- L’association est transformée en une nouvelle relation, avec comme clé primaire les clés
primaires des deux relations qu’elle lie.
- Les attributs de l’association, s’ils existent, représentent les champs de la nouvelle relation.

(n:n)

Personne (ID, Nom, Prenom)

Adresse (ID, Voie, CP, Ville)
Reside(#ID_Personne, #ID_Adresse, date_emmen)
Problématique Démarche Vérification Validation Passage ML Normalisation Application

Gestion de Facturation

Q- Traduire le modèle conceptuel en un modèle logique

Problématique Démarche Vérification Validation Passage ML Normalisation Application

Gestion de Facturation

Client (NClient, nomClient, prénom, adresse)

Reglement(NReglement, DateReglement, Montant, #NFacture)
Facture(NFacture, DateFacture, MontantTotal, #NClient)