Support du cours MCSI Rafik BOUAZIZ

CHAPITRE 2

ELABORATION DES MODELES

ORGANISATIONNEL ET LOGIQUE
DES DONNÉES

I. ELABORATION DU MODELE ORGANISATIONNEL

DES DONNÉES

Le modèle organisationnel des données (MOrD) a été introduit par MERISE/2.

1- Le MOrD permet de définir le système d'autorisation pour l’utilisation des données.

Mais tout d’abord, il faut définir une vue pour chaque type de site et pour chaque
type de poste de travail. Une vue constitue une partie du MCD qui correspond à une
limitation du champ de l’étude aux besoins d’un type de site ou d’un type de poste de
travail.

Trois types de restrictions sont possibles :

- Accès limité à un sous-ensemble des propriétés d'un objet ou d'une association.
- Accès limité à un sous-ensemble des occurrences d'un objet ou d'une association.
- Accès limité à certaines actions : création, interrogation, modification, suppression.

Quatre groupes de données peuvent être définis :

- Le groupe de données privées.
- Le groupe de données protégées.
- Le groupe de données partagées.
- Le groupe de données consultables.

Exemple :

2ème Semestre Chapitre 2 Page 1 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ
Groupe de données
consultables par Site 1

SITE N°1 Groupe de SITE N°2

données
consultables
par Site 2
Groupe de Groupe de Groupe de Groupe de
Données Données Données Données
Privées Protégées Groupe de Privées Protégées
Données
Partagées
Poste n° 11 Poste n° 12 Poste n° 21 Poste n° 22
G. G.
G.D.PRI D. G.D.PRI G.D.PRI D. G.D.PRI
P G.D.PRO P G.D.PRO
G.D.PRO G.D.PRO
A A
R R

G.D.C./P11 G.D.C./P22

G.D.C./P13 G.D.C./P23
G.D.C./P21
G.D.PRI
G.D.PRI
G.D.C./P12 G.D.PRO
G.D.PRO

Poste n° 23
Poste n° 13

2- Le MOrD permet de définir le mode de gestion des données : informatisé ou manuel.

Un sous-modèle du MOrD peut être alors défini pour chacun de ces modes.

3- Le MOrD permet de faire apparaître les données d'origine organisationnelle.

Exemples :
- modes de transmission des informations : sur support papier (par poste ou par
porteur), sur support magnétique, par message électronique à travers les réseaux,
par fax, téléx, ...

2ème Semestre Chapitre 2 Page 2 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

- couleurs des exemplaires des préimprimés : pour une facture, par exemple,
l’exemplaire blanc est destiné au client, l’exemplaire jaune à la comptabilité, ...

4- Le MOrD permet de mentionner les critères d'historisation des données : entités à

historiser, nombres d'occurrences à historiser, postes chargés de l'historisation, durées et
supports d'historisation.

II. VALIDATION DONNEES / TRAITEMENTS

Après avoir construit le MCD et le MOrD, d’une part, et le MCT et le MOrT, d’autre
part, le concepteur doit confronter les modèles des données et les modèles des traitements
pour vérifier leur conformité et leur apporter, le cas échéant, les correctifs nécessaires.

MCD MCT

Correctifs

MOrD MOrT

Validation

II.1. CONSTRUCTION DES VUES EXTERNES POUR LES

PROCEDURES

Au niveau organisationnel, le MOrT s’est intéressé à la description des traitements

(procédures et tâches), en spécifiant les actions élémentaires et les données élémentaires.

Il s’agit de recenser pour chaque procédure fonctionnelle les données manipulées au

niveau :
 des événements qui participent au déclenchement de la procédure : identifiants et données
descriptives des messages des différents événements,
 des règles de gestion : Il s’agit de toutes les données manipulées par ces règles. Ces
données appartiennent à la mémoire collective,
 des résultats : il s’agit de toute donnée appartenant aux résultats produits par la PF, y
compris les données calculables.

2ème Semestre Chapitre 2 Page 3 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

L’ensemble de ces données constitue donc la liste des données formant la vue externe
de la procédure, appelée aussi modèle externe. Si cette liste n’est pas complexe et ne nécessite
pas une structuration, elle peut être laissée en tant que telle. Autrement on doit élaborer pour
cette liste un modèle structuré selon les règles de construction d’un MCD.

Remarque :
Il est parfois intéressant de construire une vue externe par ensemble de procédures qui
concourent à un même objectif de gestion.

II.2. CONFRONTATION MOrT / MOrD

Modélisation

des données des traitements

MCD CONFRONTATION MCT

MOrD VUES MOrT

EXTERNES PF

MOrTtâches

B.I

Il faut vérifier que chaque propriété appartenant à toute vue externe, c’est-à-dire
manipulée par la (ou les) procédure(s) concernée(s), doit pouvoir être déduite du MCD et plus
précisément du sous-modèle correspondant du MOrD. Une propriété est déduite du MOrD
(ou du MCD) lorsqu’elle existe en tant que telle dans ce modèle ou lorsqu’elle peut être
calculée à partir d’autres propriétés ou des occurrences de certains objets ou des occurrences
de certaines associations. Dans le cas négatif, il faut corriger le MOrD et le MCD, en ajoutant
les propriétés manquantes, avec ou sans adjonction d’objets ou d’associations.
II.3. CONFRONTATION MOrD / MOrT

Cette confrontation a pour objectif de vérifier que toute propriété appartenant à tout
sous-modèle du modèle organisationnel des données (MOrD) est bien manipulée par au
moins une procédure ayant une nature conforme à la nature du support de mémorisation

2ème Semestre Chapitre 2 Page 4 Modèles Organisationnel et Logique des Données

 Support du cours MCSI Rafik BOUAZIZ

relatif à ce sous-modèle. Quatre types de manipulation sont proposés : C : Création, S:

Suppression,
M : Modification, E : Examen (Consultation). Cette confrontation peut se faire à l’aide du
tableau ci-dessous présenté.

Sous modèle : X

PF PF1 PF2 PF3 -------------- PFr

propriétés
1 Prop1 C I, M, S
2 Prop2 C, M, E, S
3 Prop3 C E E, S
.
.
.
.
.
.
.
.
.
n Propn C, M, E

Si une propriété n’est pas suffisamment manipulée par les traitements, il faut :
 soit supprimer cette propriété du modèle de données si elle s’avère inutile,
 Soit corriger le MOrT en ajoutant les actions appropriées à certaines PF ou en ajoutant
de nouvelles PF.

La correction peut toucher également le MCT en ajoutant de nouvelles actions à

certaines opérations ou même en ajoutant de nouvelles opérations.

II.4. RESULTATS DE LA VALIDATION

Après les deux confrontations ci-dessus présentées, on obtient un MCD, un MCT, un

MOrD et un MOrT validés.

2ème Semestre Chapitre 2 Page 5 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

III. ELABORATION DU MLD DANS LE CONTEXTE

RELATIONNEL

Le MOrD validé est à transformer en un ou des modèles logiques conformément aux

modes de gestion des données et aux types de SGBD à utiliser.

MCD

MOrD
Sous-modèle Sous-modèle
manuel automatisé

MLD_B MLD_B
manuel automatisé

Les modèles logiques des données obtenus sont bruts (MLD_B) et nécessiteront une
optimisation en fonction des traitements prévus. Le MLD manuel est défini sur des supports
manuels : imprimé, fiche, dossier, registre, etc. Le MLD automatisé est défini à travers les
concepts du type du SGBD à utiliser :
 navigationnel (en réseau) : enregistrement (record), lien de chaînage (set),
pointeur, ...
relationnel : relation, attribut, clé, ...

La transformation en un MLD automatisé est étudiée ci-après pour les SGBD

relationnels.

III.1. Règle de passage du MCD au MLD brut

On peut énoncer des règles de transformation du MCD au MLD brut qui garantissent
l’obtention d’un modèle relationnel en 3ème forme normale de BOYCE-CODD.

2ème Semestre Chapitre 2 Page 6 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Règle 1 : Cas d’un individu non vide

Tout individu non vide (comportant au moins une propriété, autre que son identifiant)
se transforme en une relation au sens relationnel du terme :
 L’identifiant de l’individu devient la clé de la relation.
 Les propriétés de l’individu deviennent les attributs de la relation.

Règle 2 : Cas d’un individu vide

Tout individu dont la liste des propriétés se limite à son identifiant n’aura pas de
correspondant dans le modèle logique, sauf exception.

Exemple : On ne définit pas une relation pour l’objet DATE.

DATE DATE (DAT)

DAT

Exception à la règle 2 :

La règle 2 n’est pas applicable lorsqu’il est nécessaire de constituer un répertoire des
données de l’objet vide et que la projection des autres relations sur l’attribut concerné ne
donne pas ce répertoire.

Exemple :

EST_DE_TYPE TYP_DOCUM
1,n TYP-DOC

DOCUMENT
1,1
COD-DOC
LIB_DOC
... 1,n
MOT_CLE
CARACTERISE
0,n MOT-C

DOCUMENT (CODE-DOC, LIB-DOC, ... )

MOT-CLE (MOT-C)

2ème Semestre Chapitre 2 Page 7 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

MOT-CLE #  CARACTERISE
MOT-C

TYPE-DOC =  DOCUMENT
TYP-DOC

Règle 3 : Cas d’une relation

Toute relation conceptuelle non définie comme DF se transforme en une relation au

sens relationnel du terme :
 L’identifiant de la relation conceptuelle devient la clé de la relation relationnelle.
 Les propriétés de la relation conceptuelle (si elle est porteuse de données) deviennent
les attributs de la relation relationnelle.

Exemple : CARACTERISE (CODE-DOC, MOT-C)

Règle 4 : Cas d’une DF (ou CIF) binaire forte

A (1, n) B
0,n
CIF 1,1

 Les deux individus A et B se transforment conformément à la règle 1 et à la règle 2.

 L’identifiant de A est ajouté à la relation B (au sens relationnel) ; cette propriété
s’appelle alors clé étrangère ( foreign key ) pour « B ».
 La DF (ou CIF) ne se transforme pas en relation, sauf exception.

Exemple :
DOCUMENT TYP_DOCUM
COD-DOC 1,1 EST_DE_TYPE
TYP-DOC
LIB_DOC 1,n
...

DOCUMENT ( CODE-DOC, LIB-ODC, #TYP-DOC )

Exception à la règle 4 :

2ème Semestre Chapitre 2 Page 8 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Pour une DF binaire dont l’objet source est un objet vide, il faut correspondre une
relation, au sens relationnel, soit à la DF, soit à l’objet vide.

Exemple :

CIF
A B
A1 0,n
AB 1,1 B1
A2

1ère solution : exception à la règle 4

A (a1, a2) AB (b1, a1)

2ème solution : exception à la règle 2

A (a1, a2) B (b1, #a1)

Règle 5 : Cas d’une DF (ou CIF) binaire faible

A (1, n)
B
0,n
CIF 0,1

Solution n°1 :
Elle consiste à appliquer les mêmes dispositions que celles de la règle 4. Toutefois, la
relation « B » (au sens relationnel du terme) ne sera pas normalisée. En effet, toutes les
occurrences de « B » ne vont pas avoir la même liste d’attributs : l’attribut correspondant à
l’identifiant de « A » et, éventuellement, ceux correspondant aux propriétés de la DF
n’existent dans la relation « B » que pour les occurrences qui participent à la DF.

Solution n°2 :
Les deux individus A et B se transforment conformément à la règle 1 et à la règle 2.
La DF se transforme conformément à la règle 3.

Généralisation de la règle 4 :

La règle 4 s’applique pour toute DF dont la source est constituée d’un seul objet.

2ème Semestre Chapitre 2 Page 9 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Exemple :
A B
A1 ABC B1
1,1
A2 0, n

1, n

C
C1

A ( A1, A2, #B1, #C1 )

Remarque :
Les DF (ou CIF) non binaires dont la source ne se limite pas à un seul objet se
transforment conformément à la règle 3.

Exemple :

INSCRIPTION (NUM_ET, AN, COD_CY, NUM_CL)

2ème Semestre Chapitre 2 Page 10 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Exemple Récapitulatif :

SOCIETE
1,n REGION
CODE_SOCIETE 1,1
CIF
ADRESSE CODE_REGION
PDG LIBELLE
CAPITAL
0,n
1,n

PATICIPATION_AU_CAPITAL PRODUCTION_ANNUELLE
QUANTITE_PRODUITE
PRIX_DE_VENTE

0,n
ACTIONNAIRE 0,n
1,n
NOM_ACTIONNAIRE PRODUIT
ADRESSE EXERCICE
CODE
N_TEL LIBELLE ANNEE

SOCIETE (CODE-SOCIETE, ADRESSE, PDG, CAPITAL, #CODE-REGION)

REGION (CODE-REGION, LIBELLE)
ACTIONNAIRE (NOM-ACTIONNAIRE, ADRESSE, N°TEL)
PARTICIPATION-CAPITAL (CODE-SOCIETE, NOM-ACTIONNAIRE)
PRODUIT (CODE-PRODUIT, LIBELLE-PRODUIT)
PRODUCTION-ANNUELLE (ANNEE, CODE-SOCIETE, CODE-PRODUIT,
QUANTITE-PRODUIT, PRIX-VENTE).

Règle 6 : Cas des généralisations / spécialisations

 Un objet générique se transforme en une relation dont la clé est le transformé de

l’identifiant et les attributs sont les transformés des propriétés.
 Un objet spécialisé se transforme en une relation dont la clé est la même que celle de
l’objet générique et les attributs sont les transformés des propriétés de l’objet spécialisé.

Exemple :

2ème Semestre Chapitre 2 Page 11 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

EMPLOYE
NUM_EMPL Objet générique
NOM
PRENOM

EST-UN liens sémantiques de EST-UN

généralisation-
spécialisation
EMP_MENS EMPL_VACAT
CATEG_EM DAT_DEB_VACA
DAT_ENTREE DURE_VACA
SALAIRE_MENS Objets spécialisés
REMUN_HOR
NBJ_CUM_VAC

EMPLOYE (NUM_EMPL, NOM, PRENOM)

EMPL_MENS (NUM_EMPL, CATEG_EM, DAT_ENTREE, SALAIRE_MENS)
EMPL_VACAT (NUM_EMPL, DAT_DEB_VACA, DURE_VACA, REMUN_HOR,
NBJ_CUM_VAC)

Cas d’une généralisation composée :

EMPLOYE SOUSCRIPTEUR
NUM_EMP NUM_SOUSCR
NOM_EMP NOM_SOUSCR
PRENOM_EMP CATEG_SOCIO_PROF

est_un est_un

SOUSCR_EMPL ENTREPRISE
TAUX_REMISE RAISON_SOCIALE
NOM_EMP_SOUSCR

EMPLOYE (NUM-EMP, NOM-EMP, PRENOM-EMP)

SOUSCRIPTEUR (NUM-SOUSCR, CATEG-SOUSCR, NOM-SOSCR)
ENTREPRISE (NUM-SOUSCR, RAISON-SOCIAL-ENT, ADR-ENT, SECTEUR-ENT)
SOUSCR-EMP (NUM-EMP, NUM-SOUSCR, TAUX-REMISE)

Remarque : La relation SOUSCR-EMP comporte deux clés candidates

2ème Semestre Chapitre 2 Page 12 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Exceptions :

 Dans le cas où tous les objets spécialisés de l’objet générique sont vides, les objets ne
se transforment pas en relations. En effet, il aurait suffit d’ajouter une propriété dans
l’objet générique spécifiant le type de chaque occurrence. La relation correspondante à
cet objet générique comporte alors un attribut indiquant le type de chaque tuple.

 Généralisation sélective
SOUSCRIPTEUR


SOUSCR_ASSUR_ETRANGER

ASSURE

* *
* * ** * * * * * *
* *
* * SOUSCR_ASSUR_ETRANGER * *
** * * *
SOUSCRIPTEUR * *
ASSURE

SOUSCRIP (NUM-SOUSCR, ...) ASSURE (NUM-ASSUR, ...)

SOUSCRIP-ETR (NUM-SOUSC, ...) ASSURE-ETR (NUM-ASSUR, ...)
SOUSCRIP-ASSUR-ETR (NUM-SOUSCR, NUM-ASSUR, ...)

III.2. L’OPTIMISATION DU MLD BRUT AU NIVEAU LOGIQUE

Il s’agit d’une première optimisation du MLD brut. Cette optimisation peut être
abordée à la fin de l’étude détaillée. Mais vue la réduction progressive entre modèle logique
des données (MLD) et entre modèle physique des données (MPD), elle est de plus en plus
laissée à l’étude technique. Elle doit permettre une transformation du MLD brut relationnel
dans l’objectif d’optimiser le temps de déroulement des procédures transactionnelles et en
différé. Il s’agit alors d’analyser essentiellement l’activité logique des traitements afin de
pouvoir recenser les fusions à réaliser et les redondances à introduire, indépendamment du

2ème Semestre Chapitre 2 Page 13 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

SGBD relationnel à utiliser. C’est la deuxième optimisation qui se réalise en fonction des
caractéristiques propres au SGBD à utiliser. L’étude de la première optimisation est illustrée
ici à travers l’exemple qui suit.

Exemple illustratif : Etude et suivi de la commercialisation des SGBD.

Enoncé : « Les développeurs des SGBD assurent leur commercialisation et offrent aux clients
la possibilité de les tester. Les clients convaincus passent des commandes
d’utilisations annuelles qui leur garantissent le droit d’utilisation des nouvelles
versions ». L’étude détaillée a débouché sur les modèles qui suivent.

MCD :
SGBD CLIENT
NUM_SGBD NUM_CL
NOM_SGBD NOM_CL
0,n ESSAI 0,n
AN_DEV ADR_CL
NOTE
NB_VERSION MATERIEL_CONST
TYP_MATERIEL MATERIEL_TYPE
0,n
1,1
DATE
0,n
0,n DATE

DEVELOPPE
0,n

0,n
CONSTRUCTEUR COMMANDE
NOM_CONST MONTANT
PAYS_CONST ANNEE

MLD Brut :
CONSTRUCTEUR (NOM-CONST, PAYS-CONST)
SGBD (NUM-SGBD, NOM-SGBD, AN-DEV, NB-VERSION, NB-MATERIEL,
TYP-MATERIEL, #NOM-CONST)
CLIENT (NUM-CL, NOM-CL, ADR-CL, MATERIEL-CONST, MATERIEL-TYPE)
ESSAI (NUM-CL, NUM-SGBD, DATE, NOTE)
COMMANDE (NUM-CL, NUM-SGBD, DATE, MONTANT, ANNEE)

2ème Semestre Chapitre 2 Page 14 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Le volume de la base de données logique s'élève alors à environ 60 millions d'octets. Ce

volume est calculé en fonction des tailles allouées aux attributs et présentées dans le tableau
suivant :

ATTRIBUT LONGUEUR EN OCTETS

NOM-CONST 30
PAYS-CONST 30
NUM-SGBD 2
NOM-SGBD 30
AN-DEV 2
NB-VERSION 2
NB-MATERIEL 2
TYP-MATERIEL 1
NUM-CL 9
NOM-CL 30
ADR-CL 30
MATERIEL-CONST 16
MATERIEL-TYPE 15
DATE 8
NOTE 4
MONTANT 4
ANNEE 2

Le formalisme proposé par l'ISO pour la quantification de l'activité logique dans le

cadre des SGBD relationnels est le suivant :

# T : accès à une table T par clé primaire

Exemple : SELECT AN-DEV FROM SGBD
WHERE NUM-SGBD = 150 ;

T+ : Ajout d'un tuple à une table T

Exemple : INSERT INTO ESSAI
VALUES (180, 240, 21/10/92, 16) ;

2ème Semestre Chapitre 2 Page 15 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

T- : Suppression d'un tuple d'une table T

Exemple : DELETE FROM SGBD
WHERE NUM-SGBD = 12 ;

Tm : Mise à jour d'un tuple dans T

Exemple : UPDATE CLIENT
SET ADR-CL = "CITE NOUVELLE 1020 TUNIS-TUNISIE"
WHERE NUM-CL = 1820 ;

?T : Recherche d'un tuple répondant à certains critères

Exemple : SELECT * FROM COMMANDE
WHERE MONTANT > 100.000 ;

TjT' : Jointure entre T et T' pour l'exploitation simultanée de deux tables

Exemple : SELECT MATERIEL-CONST FROM CLIENT, ESSAI
WHERE NUM-SGBD = 140 AND
CLIENT.NUM-CL = ESSAI.NUM-CL ;

L'optimisation peut être réalisée sur la base d'une analyse qualitative en se basant, tout
de même :
 d'une part, sur les fréquences des différentes procédures et le volume des données et,
 d'autre part, sur le fait que les opérations les plus coûteuses sont celles qui utilisent des
jointures et des recherches séquentielles.

Elle peut être également le résultat d'une analyse quantitative dont le paramètre-pivot
est le nombre d'accès nécessaires à l'exploitation de chaque procédure. Les calculs à réaliser
nécessitent des hypothèses sur le coût, en nombre d'accès, de chaque opération élémentaire ou
primitive. Ces hypothèses peuvent être comme suit :

#T : 2 accès (1 accès à l'index + 1 accès au tuple dans la page-données),

T+ et T- : 4 accès (1 accès à l'index, 1 accès à la page-données, mise à jour index et

mise à jour page),

Tm : 3 accès (1 accès à l'index, 1 accès au tuple dans la page-données, mise à jour de

ce tuple)

2ème Semestre Chapitre 2 Page 16 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

?T : Le balayage séquentiel définit un nombre d'accès égal au nombre de pages de

données de la table T, soit :

Cardinalité
(T)
E (P / l(T))
partie entière longueur d'un tuple de T
taille de la page logique
(4000 octets par exemple)

TjT' : Le nombre d'accès est égal au nombre d'accès à la table T (conformément au terme de
sélection) auquel on ajoute le nombre d'accès à T'. Ce dernier est égal au nombre
de tuples t de T satisfaisant le critère de sélection multiplié par le nombre d'accès
à T' consommés par chaque tuple t.

L'analyse quantitative passe par les étapes suivantes :

1°) Calcul du volume des données

Au niveau logique brut, le volume des données est composé :

 du volume des données mémorisées

No =  l(Ti)  n(Ti)

nombre de tuples de Ti

Longueur d'un tuple de Ti

 du volume nécessaire aux index construits sur les clés primaires de chaque tableau T
issu d'individu, en supposant que l'unité d'accès logique est la page et qu'une adresse
de page nécessite 4 octets.

Exemple : Cas de la base de données "Commercialisation des SGBD".

- Table SGBD
l(SGBD) = 69 octets
n(SGBD) = 250 occurrences

2ème Semestre Chapitre 2 Page 17 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Volume (SGBD) = 17250 octets

Taille de l'index construit sur NUM-SGBD (de longueur égale à 2 octets) :
. taille d'un élément de l'index : 2 + 4 = 6 octets
. taille de l'index : 6  250 = 1500 octets
Cet index peut être logé dans une page logique et peut être mis en mémoire centrale. Il
ne nécessite donc qu'un seul niveau.

- Table CONSTRUCTEUR
l(CONSTRUCTEUR) = 60 octets
n(CONSTRUCTEUR) = 125 occurrences
Volume (CONSTRUCTEUR) = 7500 octets
Taille de l'index construit sur NOM-CONST :
. taille d'un élément : 30 + 4 = 34 octets
. taille de l'index : 34  125 = 4250 octets

- Table ESSAI
l(ESSAI) = 23 octets
n(ESSAI) = 1.000.000 occurrences (un client teste en moyenne 10 SGBD)
VOLUME (ESSAI) = 23.000.000 octets

- Table CLIENT
l(CLIENT) = 100 octets
n(CLIENT) = 100.000 occurrences
VOLUME (CLIENT) = 10.000.000 octets
Taille de l'index construit sur NUM-CL :
. taille d'un élément de l'index : 9 + 4 = 13 octets
. taille de l'index : 13  100.000 = 1.300.000 octets.
Cet index nécessite 325 pages logiques de 4.000 octets chacune. Il requiert alors un
index maître de 325 éléments qui consomme 4225 octets et qui peut se loger sur 2 pages
logiques et se charger en mémoire centrale.

- Table COMMANDE
l(COMMANDE) = 25 octets
n(COMMANDE) = 1.000.000 (les commandes sont gardées pour une durée de 5 ans. Un
client dispose en moyenne de 2 SGBD)

2ème Semestre Chapitre 2 Page 18 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

VOLUME (COMMANDE) = 25.000.000 octets

2°) Évaluation de l'activité logique

L'activité logique est évaluée pour chaque procédure en terme de nombre d'opérations
élémentaires de manipulation de données (ou accès logiques). L'évaluation se base
généralement sur les valeurs moyennes, mais dans certains cas, on doit également considérer
les valeurs relatives aux périodes de pointe (horaire ou saisonnier).

Na =  a(Pi)  n(Pi)
i

avec :
a(Pi) = activité logique de la procédure-type Pi
n(Pi) = nombre d'occurrences de Pi dans l'unité de temps considérée

Exemple : Cas de la base de données "Commercialisation des SGBD"

Considérons la procédure P qui s'intéresse à la recherche des clients qui ont commandé
un SGBD donné au cours d'un mois donné. On suppose que P est appelée en moyenne 35 fois
par jour. Cette procédure se traduit en SQL par la requête suivante :

SELECT NUM-CL, MATERIEL-CONST, MATERIEL-TYPE

FROM COMMANDE, CLIENT
WHERE NUM-SGBD = 25
AND YEAR (DATE) = 97 AND MONTH (DATE) = 10
AND COMMANDE.NUM-CL = CLIENT.NUM-CL ;

Elle nécessite donc une lecture séquentielle de la relation commande, soit :

1.000.000
= 6250 accès
E(4000/25)

Par ailleurs, elle nécessite la recherche des données clients (avec accès direct, soit 2
accès élémentaires) pour chaque tuple de COMMANDE sélectionné. Si on suppose qu'en
moyenne un SGBD bénéficie de 70 commandes par mois, la requête consommera encore :
2  70 = 140 accès élémentaires, Soit au total :
(6250 + 140)  35 = 223650 accès élémentaires par jour.

2ème Semestre Chapitre 2 Page 19 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

La définition d'un index sur NUM-SGBD pour la relation COMMANDE permet de

réduire les accès élémentaires pour cette relation à environ 34 accès élémentaires : ayant 250
SGBD, on a en moyenne 6250/250 = 25 pages, soit 25 accès pour les données.

L'index nécessite 2 niveaux et chacun de ses éléments consomme 6 octets. L'index de

niveau 2 consomme donc 6.000.000 octets, soit 1500 pages. Il consomme en moyenne
1500/250, soit 6 pages pour chaque SGBD et nécessite donc 6 accès.

L'index maître consomme au total 1500  6 / 4000, soit 3 pages et nécessite donc 3
accès.

Il permet donc de réduire le nombre total d'accès élémentaires à :

(34 + 140)  35 = 6090 accès par jour.
Soit un gain de plus de 200.000 accès par jour, au prix d'une consommation d'environ 6
millions d'espace disque. Le gain escompté justifie donc pleinement la création de cet index.

3°) Les paramètres de l'optimisation

Pour un site centralisé, le coût d'utilisation d'une base de données dépend

essentiellement de deux facteurs :
- le coût de stockage des données
- le coût d'accès aux données

Le coût de stockage est fonction du volume de la base et du coût unitaire sur le support
de stockage utilisé (facturation du Service Informatique, prix de revient).

Le coût d'accès peut être déterminé par l'étude des procédures et de leurs fréquences. Il
s'agit donc d'optimiser une fonction de coût de la forme :

F = Coût d'Accès + Coût de Stockage

Avec :
Coût d'Accès = nombre d'accès logiques par période  coût d'un accès
Coût de Stockage = nombre de caractères à stocker  coût de stockage unitaire

Cette fonction définit une ligne directrice pour l'opération d'optimisation. Il s'agit alors
d'essayer de minimiser le coût des accès logiques et, en contre partie et inéluctablement,
d'augmenter le coût de stockage pour minimiser en fin de compte F.

2ème Semestre Chapitre 2 Page 20 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

Dans l'exemple "Commercialisation des SGBD", cette fonction peut s'optimiser par :

- la création d'un index sur NUM-SGBD pour la relation COMMANDE, tel que nous l'avons
ci-dessus discutée,

- la création d'un index sur ANNEE pour la relation COMMANDE dans le cas où les
procédures qui exploitent les commandes par année sont fréquentes.
Un autre index, basé sur NUM-CL pourrait être également intéressant.

- la création d'un index sur NUM-SGBD pour la relation ESSAI dans le cas où les procédures
qui exploitent les essais sur NUM-SGBD sont fréquentes.
D'autres index pourraient être intéressants : ceux basés sur NUM-CL et DATE.

- la création de données calculables (donc redondantes) qui éviteront à certaines procédures,

des accès nombreux aux relations ESSAI et COMMANDE qui ont des cardinalités élevées.
Il s'agit :
* pour la relation SGBD, de :
. NB-NOT, permettant de calculer la moyenne des notes de chaque SGBD pour l'année
courante.
. TOT-NOT
. MOY-NOT-1, MOY-NOT-2, MOY-NOT-3, MOY-NOT-4, donnant les moyennes des
notes pour les 4 dernières années.
. NB-CL, NB-CL-1, NB-CL-2, NB-CL-3, NB-CL-4 donnant le nombre de clients pour
les 5 dernières années (y compris l'année courante).
. MONT-COMM, MONT-COMM-1, MONT-COMM-2, MONT-COMM-3, MONT-
COMM-4, donnant les 5 derniers chiffres d'affaires (y compris l'année courante).
Ces données consommeraient :
(11  4 + 5  8)  250 = 21.000 octets supplémentaires.
* pour la relation CLIENT, de :
. NB-SGBD, NB-SGBD-1, NB-SGBD-2, donnant le nombre de SGBD installés par le
client pour les 3 dernières années
. MONTANT, MONTANT-1, MONTANT-2, donnant le montant des locations des
SGBD pour les 3 dernières années.
Ces données consommeraient : (3x2+3x4)x100.000 = 1.800.000 octets.
Il ne serait opportun de les introduire que si les fréquences des procédures qui les
utilisent sont élevées.

- Le regroupement des relations SGBD et CONSTRUCTEUR en une seule (qui ne serait plus
en "3FN"). La redondance ajoutée ne coûterait rien en espace supplémentaire, mais pourrait
nécessiter des accès supplémentaires (mise à jour des adresses redondantes). Elle se justifie
lorsque les jointures entre ces deux relations sont nombreuses.

2ème Semestre Chapitre 2 Page 21 Modèles Organisationnel et Logique des Données

Support du cours MCSI Rafik BOUAZIZ

IV. ELABORATION DU MLD REPARTI

Le MLDR correspond à la répartition du MLD sur les différents sites, conformément à

l’implantation des segments de données sur les différentes machines logiques du système. Le
MLDR est donc composé de 2 à N modèles logiques locaux. Le MLDR est un outil pour
l’administration des données.

Si les données sont gérées par différents SGBD locaux, les composants de
l’application doivent savoir où sont implantées réellement les données. le MLDR est dans ce
cas un outil pour le développement de l’applicatif également.

Si les données sont gérées par un seul SGBD Réparti, les composants de l’application
n’ont pas à savoir où sont implantées réellement les données.

Un segment de données, sur une machine donnée (serveur ou client), peut être de trois
types :

 référence, c’est-à-dire que ce segment n’est mis à jour que sur cette machine,

 cliché (photo, snapshot) ; ce segment n’est accessible sur cette machine qu’en
consultation ; il peut être actualisé :
 périodiquement sur toutes les machines qui l’utilisent,
 à la demande de l’une de ces machines.

 dossier, c’est-à-dire que ce segment n’est considéré par une machine donné comme de
type référence que durant la durée de mise à jour ; ailleurs, il y est considéré comme de
type cliché.

Parmi les critères de répartition des données d’une application, on cite :

 les types d’utilisation définis par le MOrD (données privées, protégées, partagées et
consultables),

 les fréquences d’utilisation,

 les volumes des données vis à vis des capacités de stockage des machines serveurs et
des machines clientes,

 l’existence de « dossiers », c’est-à-dire de données toujours consultées ou mises à

jour simultanément (dossiers prêt, dossier sinistre, ...),

 la possibilité d’assurer le blocage et le déblocage des données et le retour à une

situation cohérente en cas d’incident.

2ème Semestre Chapitre 2 Page 22 Modèles Organisationnel et Logique des Données