CH2 Partie1 Verification

Cours
Bases de Données Relationnelles
Dr. Safa Hachani

hachanisafaa@gmail.com
ENIB 2017/2018
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
Le but d’un modèle logique / relationnel : décrire une BD qui va être utilisée.
 chargée, accédée, mise a jour (maj)
Les maj (insertion, suppression, modification) doivent conserver la cohérence de

la base de données:
 les contraintes d’intégrité référentielle ou autres
 en particulier les dépendances fonctionnelles entre attributs
Selon le schéma c’est + ou – facile:

 Plus la BD contient de redondances, plus les maj avec maintien de la
cohérence est difficile.
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 …
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- E- A
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.
Vérification de la cohérence syntaxique

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.

⇒ 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.
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 est identifié par son numéro, et 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é.

Client Commande
numeroClient
1,n (n:n)
numeroCommande
nomClient (n:1) 1,1 dateCommande concerner
adrClient 1,n Travaille
passer dateFacturation
pour Qté
Fournisseur Produit
(n:1)
desProduit
numeroFournisseur fournir dateFabProd
nomFournisseur 1,1 0,n
1,n prixUnitaireProd
telFournisseur
CIF : Les dates de facturation doivent être postérieurs aux dates de commandes.
Q- vérifier le modèle conceptuel correspondant a cet énoncé.
Client Commande
numeroClient
1,n (n:n)
numeroCommande
pour Qté
Fournisseur
Produit
(n:1)
desProduit
numeroFournisseur
nomFournisseur fournir dateFabProd
1,1 0,n
telFournisseur
Vérification :
1- Chaque entité possède :
- Un identifiant
2- Tous les attributs sont: 3- Il n’existe pas :

- Élémentaires - d’attributs traduisant une association
- Mono-valués - d’associations redondantes
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.
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.
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


Règle 1: Validation des attributs d'un TE
A vous de jouer.
Q- Indiquez si le modèle ci-dessous est correctement défini et motiviez votre

affirmation. S’il ne l’est pas, proposez une solution adéquate.
NumE, Dept  nomE

nomD  Directeur

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)

Règle 2: Validation des associations
A vous de jouer.
Q- Indiquez si le TE Client respecte la R2 ou pas.

Hypothèse : un client peut passer plusieurs commandes, qui peuvent appartenir
qu’a un seul client.
Association (n:1)
Les attributs du TE Client respectent la R2:
- numCl  adresseCl
- numCm  dateCm, Produit
- numCm  numCl (l’identifiant de client)

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

Règle 3: Validation des attributs d'un TA
A vous de jouer.
Q- Dans le modèle ci-dessous on souhaite ajouter un numéro d’assuré qu’une

compagnie d’assurance assigne a chacun de ses clients. Indiquez si la solution choisie est
correcte, et motivez votre affirmation. Si elle ne l’est pas, proposez une solution.

Règle 3: Validation des attributs d'un TA
A vous de jouer.
NumP, Nom  Num_assuré

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 est identifié par son numéro, et 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- valider le modèle conceptuel correspondant a cet énoncé.

Client Commande
numeroClient
1,n (n:n)
numeroCommande
pour Qté
Fournisseur Produit
(n:1)
desProduit
numeroFournisseur fournir dateFabProd
nomFournisseur 1,1 0,n
telFournisseur
CIF : Les dates de facturation doivent être postérieurs aux dates de commandes.
Q- Donner les DF qui correspondent au modèle conceptuel vérifié auparavant.
Client Commande
numeroClient
1,n (n:n)
numeroCommande
pour Qté
Fournisseur
Produit
(n:1)
desProduit
numeroFournisseur
nomFournisseur fournir dateFabProd
1,1 0,n
telFournisseur
Validation: Les dépendances Fonctionnelles :

R1: numeroClient  nomClient, adrClient R2: numeroCommande  numeroClient
numeroCommande  dateCommande, dateFacturation
desProduit  numeroFournisseur
numeroFournisseur  nomFournisseur, telFournisseur
desProduit  dateFabProduit, prixUnitaireProd R3: numeroCommande, desProduit  Qté

CH2 Partie1 Verification

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CH2 Partie1 Verification

Transféré par

Droits d'auteur :

Formats disponibles

Cours

Bases de Données Relationnelles

Dr. Safa Hachani

Validation du modèle E-A et

Les maj (insertion, suppression, modification) doivent conserver la cohérence de

Selon le schéma c’est + ou – facile:

Une BD est incorrecte si :

Exemple d'anomalies de MAJ

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

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

Vérification de la cohérence syntaxique

Vérification de la cohérence syntaxique

Vérification de la cohérence syntaxique

Vérification de la cohérence syntaxique

Vérification de la cohérence syntaxique

Vérification de la cohérence syntaxique

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

2- Tous les attributs sont: 3- Il n’existe pas :

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

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

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

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

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

Adresse  num, rue, ville

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

Validation du modèle E-A

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

Adresse  num, rue, ville

Validation du modèle E-A

Q- Indiquez si le modèle ci-dessous est correctement défini et motiviez votre

NumE, Dept  nomE

Validation du modèle E-A

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

Exemple : Association (1:n)

Les attributs du TE Fournisseur respectent la R2:

Validation du modèle E-A

Q- Indiquez si le TE Client respecte la R2 ou pas.

Validation du modèle E-A

Validation du modèle E-A

Q- Dans le modèle ci-dessous on souhaite ajouter un numéro d’assuré qu’une

Validation du modèle E-A

NumP, Nom  Num_assuré

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

Validation: Les dépendances Fonctionnelles :

Vous aimerez peut-être aussi