Dépendances et normalisation (1)

Dépendances et normalisation (1)
Qu’est-ce que la normalisation ?
• Normaliser une relation consiste à la représenter sous
une forme qui respecte certains critères assurant
l’intégrité des données (correspondance au réel) et
évitant au concepteur de la base des erreurs graves
• La théorie de la normalisation propose des méthodes
systématiques visant à assurer la cohérence de cette
représentation.
Nécessité de la normalisation (1)
• Soit la relation R (produit, client, adresse, date,
quantité_commandée, montant)
produit
Cassettes audio
CD-ROM
Disquettes
CD-ROM
CD-ROM
Disquettes
client
Dupuis
Dupuis
Dupuis
Martin
Dubois
Dupont
adresse
Lille
Lille
Lille
Marseille
Paris
Lyon
date
10/02/01
15/02/01
30/02/01
01/03/01
02/03/01
05/03/01
Cette relation pose des problèmes...
quantité_commandée
100
150
200
15
50
300
montant
1000
1500
400
150
500
600
Nécessité de la normalisation (2)
produit
Cassettes audio
CD-ROM
Disquettes
CD-ROM
CD-ROM
Disquettes
client
Dupuis
Dupuis
Dupuis
Martin
Dubois
Dupont
adresse
Lille
Lille
Lille
Marseille
Paris
Lyon
date
10/02/01
15/02/01
30/02/01
01/03/01
02/03/01
05/03/01
quantité_commandée
100
150
200
15
50
300
montant
1000
1500
400
150
500
600
• L’adresse du client est répétée autant de fois qu’il y a de
commandes
 redondance des informations
Nécessité de la normalisation (3)
produit
Cassettes audio
CD-ROM
Disquettes
CD-ROM
CD-ROM
Disquettes
client
Dupuis
Dupuis
Dupuis
Martin
Dubois
Dupont
adresse
Lille
Lille
Lille
Marseille
Paris
Lyon
date
10/02/01
15/02/01
30/02/01
01/03/01
02/03/01
05/03/01
quantité_commandée
100
150
200
15
50
300
montant
1000
1500
400
150
500
600
• Si l’adresse change, il faut modifier la base à plusieurs
endroits
 anomalie de modification
Nécessité de la normalisation (4)
produit
Cassettes audio
CD-ROM
Disquettes
CD-ROM
CD-ROM
Disquettes
client
Dupuis
Dupuis
Dupuis
Martin
Dubois
Dupont
adresse
Lille
Lille
Lille
Marseille
Paris
Lyon
date
10/02/01
15/02/01
30/02/01
01/03/01
02/03/01
05/03/01
quantité_commandée
100
150
200
15
50
300
• Si on insère la ligne (Disquettes, Dubois, Dijon,
10/03/01, 100, 200), Dubois aura deux adresses
 anomalie d’insertion
montant
1000
1500
400
150
500
600
Nécessité de la normalisation (5)
produit
Cassettes audio
CD-ROM
Disquettes
CD-ROM
CD-ROM
Disquettes
client
Dupuis
Dupuis
Dupuis
Martin
Dubois
Dupont
adresse
Lille
Lille
Lille
Marseille
Paris
Lyon
date
10/02/01
15/02/01
30/02/01
01/03/01
02/03/01
05/03/01
quantité_commandée
100
150
200
15
50
300
montant
1000
1500
400
150
500
600
• Si Martin annule sa commande, on perd son nom et son
adresse…
 anomalie de suppression
Nécessité de la normalisation (6)
• Cette relation n’est donc pas cohérente, alors que la
base formée des trois relations :
R1 (code_client, nom_client, adresse)
R2 (code_produit, nom_produit, prix_unitaire)
R3(code_commande, code_client, date,
code_produit, quantité)
n’aura aucun problème de cohérence.
Nécessité de la normalisation (7)
code_
client
CL001
CL002
CL003
CL004
client
Dupuis
Martin
Dubois
Dupont
code_
commande
C0001
C0002
C0003
C0004
C0005
C0006
adresse
code_
produit
P0001
P0002
P0003
Lille
Marseille
Paris
Lyon
code_
client
CL001
CL001
CL001
CL002
CL003
CL004
date
10/02/01
15/02/01
30/02/01
01/03/01
02/03/01
05/03/01
code_
produit
P0001
P0002
P0003
P0001
P0003
P0001
produit
prix_
unitaire
Cassettes audio
10
CD-ROM
10
Disquettes
2
quantité
100
150
200
15
50
300
But de la normalisation
Fixer des règles
permettant de passer
de la première représentation (incohérente)
à la deuxième (cohérente).
Dépendances fonctionnelles (1)
• Une dépendance fonctionnelle (DF) traduit le fait
qu’à une valeur d’une donnée, on associe dans une
relation, à un instant donné, une valeur au plus
d’une autre donnée.
Exemple
Dans la relation VOL, à une certaine date, un vol ne
peut être associé qu’à un seul pilote. Il y a une DF
entre (NUMVOL, JDEP) et NUMPIL. On écrit
(NUMVOL, JDEP)  NUMPIL
(NUMVOL, JDEP) est la source de la DF, NUMPIL
en est le but.
Dépendances fonctionnelles (2)
• Remarque
Il s’agit bien d’une dépendance,
car s’il existe une occurrence où
NUMVOL = V0010, JDEP=15/5/2004 et NUMPIL =
P0005,
alors
on ne peut pas introduire une nouvelle occurrence où
NUMVOL = V0010, JDEP=15/5/2004 et NUMPIL =
P0001
sans supprimer la première (problème de l’unicité de la
clé).
Clé d’une relation : définition
• Lorsque, dans une relation, un attribut ou un groupe
d’attributs est source de plusieurs DF ayant
respectivement pour buts chacun des autres attributs
de la relation, cet attribut ou ce groupe d’attributs est
appelé clé de la relation.
• Un attribut est appelé attribut clé s’il fait partie d’au
moins une clé.
• Un attribut est dit attribut non clé s’il ne participe à
aucune clé.
Clé d’une relation : exemples
• Dans la relation PILOTE (numpilote, nom, prenom),
on a deux DF de source NUMPILOTE :
NUMPILOTE  NOM
NUMPILOTE  PRENOM
NUMPILOTE est donc bien la clé de la relation PILOTE
et le seul attribut clé.
Clé d’une relation : exemples
• Dans la relation VOL (numvol, depart, arrivee, numav,
numpil, jdep, hdep, jarr, harr), on a sept DF de source
(NUMVOL, JDEP) :
(NUMVOL, JDEP)  DEPART
(NUMVOL, JDEP)  NUMAV
(NUMVOL, JDEP)  HDEP
(NUMVOL, JDEP)  HARR
(NUMVOL, JDEP)  ARRIVEE
(NUMVOL, JDEP)  NUMPIL
(NUMVOL, JDEP)  JARR
• Le couple (NUMVOL, JDEP) est donc bien la clé de la
relation VOL. Il y a donc deux attributs clé.
Dépendance fonctionnelle élémentaire et directe
• Soit X un groupe d’attributs et Y un attribut unique
n’appartenant pas à X.
• La DF X  Y est dite élémentaire si aucun sousensemble de X ne suffit pour être source de la DF (X est
donc la plus petite quantité d’information permettant
de déduire Y).
• Une DF de source A et de but B est dite directe s’il
n’existe pas d’attribut C tel que A  C et C  B.
Première forme normale : définition
• Une relation est dite normalisée ou en première
forme normale (1 FN) si un même attribut n’est pas
représenté plusieurs fois et si un attribut n’est pas
décomposable en d’autres attributs.
nom
Exemple de relation
non normalisée
Dupuis
Dupont
diplôme
bac
licence
bac
ingénieur
prénom
Luc
André
Jeanne
Lucie
enfants
date naissance
1986
1989
1991
1995
- l’attribut enfants est décomposable en deux
attributs,
- Les attributs diplôme et enfant sont représentés
plusieurs fois pour une même personne.
Première forme normale : exemple
• La relation
VENTE(num_client, num_article, nom_client,
nom_article)
où (num_client, num_article) est la clé,
est en première forme normale.
Les dépendances fonctionnelles sont :
(num_client, num_article)  nom_client
(num_client, num_article)  nom_article.
Deuxième forme normale : définition
• Une relation est en deuxième forme normale (2 FN)
si elle est en 1 FN et si toutes les DF issues de la
clé sont élémentaires.
Exemple de relation qui n’est pas en 2 FN
VENTE(num_client, num_article, nom_client,
nom_article) est en 1 FN, mais pas en 2 FN car des
deux DF : (num_client, num_article)  nom_client
(num_client, num_article)  nom_article
on peut extraire les DF élémentaires :
num_client  nom_client
num_article  nom_article.
Deuxième forme normale : exemple
• La relation
REPRESENTANT(num_client, nom_client,
num_représentant, nom_représentant)
où num_client est la clé, est en 2 FN car les trois DF qui
en découlent :
num_client  nom_client
num_client  num_représentant
num_client  nom_représentant
sont toutes les trois élémentaires.
Troisième forme normale : définition
• Une relation est en troisième forme normale (3 FN)
si elle est en deuxième forme normale (2 FN)
et si toutes les DF issues de la clé sont directes.
• Alors
- aucune DF n’est issue d’un sous-ensemble de la clé.
- aucune DF n’est issue d’un attribut non clé vers un
autre attribut non clé.
Troisième forme normale : exemples
• Les relations
CLIENT(num_client, nom_client, adresse)
et VENTE(num_commande, num_article, quantité)
sont en 3 FN.
On a les DF élémentaires et directes :
num_client  nom_client
num_client  adresse
num_commande, num_article  quantité.
SGBDR : Points Forts
– Simplicité des concepts et du schéma
- Bon support théorique, la théorie de la normalisation,
algèbre relationnelle
- Haut degré d’indépendance
- Langages de manipulation de haut niveau, SQL2 (langage
déclaratif)
- Amélioration de l’intégrité et de la confidentialité
- Optimisation des requêtes d’accès à la BD.
- Technologie très répandue (3/4 applications)
– Adapté aux applications traditionnelles
Pourquoi étendre le
relationnel ?
• Nouvelles applications
–
–
–
–
–
Système d’information géographique (SIG)
MultiMedia
Bioinformatique
Web
Workflow
• Nouveaux besoins
– Objets complexes et structurés
– Nouveaux types de données (Vidéo, XML, etc.)
– Volume de données important
SGBDR : points faibles
• Structure de données trop simple
– Pas d’attribut complexe ni multivalué
» Entités réelles éclatées, jointures
– Un seul type de lien (clé étrangère)
• Peu compatible avec les langages de programmation
• Données alphanumériques uniquement
– Images, sons, vidéos, …
• Performances problématiques en cas de jointure
SGBD : Evolution
• 1960 : SGBD hiérarchique
– Modèle réseau (CODASYL)
– Langage navigationnel
• 1970 : SGBD Relationnel
– Structure physique cachée à l’utilisateur
– Modèle simple
– Théorie des ensembles
– Langage déclaratif
SGBD : Evolution
• 1980 Entité Association
– Représentation sémantique riche d’un domaine
– Outils de modélisation
• 1986 SGBDOO
– Représentation riche du monde réel (Données + Traitement)
– Réutilisation, évolution et gestion faciles
• 1993 Standard ODMG pour les SGBD OO
• 1999 Standard SQL3 pour les SGBD Relationnel-Objet
SGBD : Evolution
• Applications plus complexes
• Couts de développement important
 En faire plus au SGBD
APPLICATION
APPLICATION
SGBD
SGBD
BD
BD
ODMG
• Groupe de normalisation des SGBD OO
• Norme publié en 2001
• A regroupé de nombreux vendeurs de
SGBD OO
– Poet, Ardent, Objectivity, Versant, GemStone,
O2, etc.
– Constructeurs, utilisateurs, chercheurs etc.
• www.odmg.org
Approche Orientée Objet
• Ensemble de méthodologies et d’outils pour concevoir et
réaliser des logiciels structurés et réutilisables, par composition
d’éléments indépendants
• Objectif : permettre aux programmeurs d’application une
meilleure productivité
• Maintenance facile
• Réutilisation
• Extensibilité
• Concepts essentiels
– Objets encapsulés
• Interface visible : opérations (méthodes)
• Implémentation cachée : structure et code
– Héritage
• Langages de programmation OO
– Eiffel , Smalltalk, C++, java, C#
SGBD OO = SGBD + LPOO
LP OO
SGBD
SGBD OO
• Représentation du réel
•Persistance
• Fiabilité
• Sécurité
• Langage de requête
• Indépendance logique/physique
• Partage des données
• Concurrence
•Développement
•Structure complexe
• Identité
• Encapsulation
• Classe
• Héritage
• Redéfinition
• Bibliothèque de classe
Intérêt d’un SGBD OO / LP OO
Un SGBD est meilleur qu’un langage de programmation
car :
–
–
–
–
–
Les données sont persistantes
Les données sont intègres
Le modèle logique et indépendant du modèle physique
Langage de manipulation de données déclaratif et optimisé
Confidentialité, fiabilité, concurrence, gestion de
transactions, etc.
Intérêt d’un SGBD OO / SGBDR
Un SGBD OO est meilleur qu’un SGBD Relationnel :
• Manipulation d’objets à structure complexe
• Compatibilité avec les langages de programmation et la
modélisation OO
• Nouveaux types de données (image, son, XML, etc.)
• Performances
• Gestion des versions, des historiques, transactions longues
Différences entre SGBDO
• Modèles de données différents
• Langage sous-jacent différent (C++, Lisp,
etc.)
• Interprété ou compilé (Perl, C++)
• Couplage fort ou faible avec les langages
de programmation
• Bibliothèques de classes + ou – complète
• Performances
SGBD OO : caractéristiques
Des SGBD :
– Persistance
– Concurrence
– Système de requête
Des langages OO :
– Structure d’objet complexe
– Gestion des types ou classes
– Encapsulation
Le modèle Objet
• Les modèles à objets permettent de modéliser
directement les entités du monde réel avec un état et un
comportement.
• Objet : abstraction informatique d’une entité du monde
réel caractérisée par une identité, un état et un
comportement.
• Attribut : caractéristique d’un objet désignée par un nom
permettant de mémoriser une ou plusieurs valeurs, un
ou plusieurs identifiants d’objets.
• Identifiant d’objet (Oid) : référence unique et invariante
attribuée à un objet lors de sa création
Le Modèle Objet
• Encapsulation des objets : Les modèles à objets
permettent d’encapsuler les structures des objets par
des opérations, appelées méthodes ou fonctions
membres.
• Une opération est la modélisation d’une action
applicable sur un objet, caractérisée par un en-tête
appelé signature, définissant son nom, ses paramètres
d’appel et ses paramètres de retour.
• Classe : type associé à un ensemble d’objets, permet de
spécifier un ensemble de propriétés d’objets (attributs et
opérations) et de créer des objets possédant ces
propriétés.
Le Modèle Objet
• Généralisation-Spécialisation : lien hiérarchique entre
deux classes, spécifiant que les objets de la classe
supérieure (inférieure) sont plus généraux (spécifiques)
que ceux de la classe inférieure (supérieure).
• Héritage : transmission automatique des propriétés d’une
classe de base vers une sous-classe.
• Redéfinition : spécification d’une méthode existante dans
une super-classe au niveau d’une sous-classe, avec une
implémentation différente.
Le Modèle Objet
• Surcharge : possibilité de définir plusieurs codes pour
une même opération d’une classe, le code approprié
étant sélectionné selon le type des paramètres fournis
lors d’un appel.
• Polymorphisme : possibilité pour une opération d’avoir
différentes signatures avec un code spécifique attaché
à chaque signature.
• Agrégation : association entre deux classes exprimant
que les objets de la classe cible sont des composants
de ceux de la classe source.
Objets à structure Complexe
• Objectif : représentation directe des entités du monde
réel
• Monde réel : Personne
– Nom
– Prénoms
– Adresses (Rue, N°, Code postal, Ville)
– Numéros de téléphone (N°, type)
– Enfants (prénoms, sexe, date de naissance)
Représentation Conceptuelle
nom
Personne
Prénoms
liste 1,n
liste 0,n
Adresse
Rue
N°
CP
liste 0,n
N° téléphone
Ville
N°
type
Enfant
Date
nais
sexe
Liste 1,n
Prénoms
En relationnel
5 relations :
•
•
•
•
•
Personne (NP, nom,adr_ville, adr_N°, adr_ville, adr_CP)
Personne_prénom(n°P, n°prenom, prénom)
Personne_enfant (n°P,n°enfant,datenais, sexe)
Personne_Enfant_Prenom (n°P,n°Enf,n°prénom, prénom)
Telephone (n°p, n°tel, type)
En objet
Une seule classe
Class Personne
{attribute Nom : string
attribute Prénoms : LIST string
attribute adresse : struct adr
{
rue : string ;
N° : string ,
Ville : string ;
CP : int ;},
Attribute Enfants : list struct Enfant
{prénoms : list string ; date_naissance : date ; sexe : ENUM {‘M’,’F’};}
Attribute téléphones list struct téléphone
{ N° long ;
type string ;}
}
Structure complexe
• SGBD OO permettent de définir des structures complexes
qui peuvent être utilisés pour :
– Définir la structure des objets du monde réel
– Définir de nouveaux types
• Les structures sont définies en utilisant les constructeurs
– Struct (attributs complexes)
– Collection (attributs multi-valués)
• SET, ARRAY, LIST, etc.
Eléments de la structure
Structure complexe
Collections
Set
List
Date
Array
Bag
Structuré
Atomique
Long
Float
String
Time
User
Defined
Structure complexe
• STRUCT
• Définie une structure de donné complexe
• Exemples :
– Struct Adresse {string rue; long N°; long CP}
– Struct N°telephone {
Code_pays : Unsigned short ;
Code_région : Unsigned short ;
Code_Personnel : Unsigned short ;}
– Attribute Telephone_domicile : N°telephone;
– Attribute Telephone_bureau : N°telephone;
Structure complexe
• Collections
• Attributs multi-valués
–
–
–
–
SET : ensemble d’éléments non ordonnés
LIST : ensemble d’éléments ordonnés
BAG : ensemble d’éléments non ordonnés et dupliqués
ARRAY : ensemble d’éléments ordonnés avec position
• Exemples :
Class Personne
{ attribute nom : string ;
attribute email : set string;
attribute adresses : list T-adresse;
}
Types définis par l’utilisateur
• Constructeurs de structures complexes :
– Définir la structure des objets
– Définir les type de données utilisateurs (Typedef) :
type T-Adresse , Image, son, polygone, ligne
• Comme les classes, les types de données utilisateur ont:
– Une structure complexe
– Un ensemble d’opérations (méthodes)
• Exemples
Struct T-adresse
{rue : String ;
N° : String ;
Ville : String ;
CP : String }
Typedef list T-adresses
Structure complexe
– Impact sur le SGBD ?
– Comment accéder aux valeurs des données ?
Références
Navigation
Initialisation, mise à jour
Opérations algébriques
– Taille des variables, stockage des objets complexes
Identité d’objet (OID)
• Identifie l’objet indépendamment de ces valeurs
• Produit par le système lors de sa création
• Ne change pas durant son cycle de vie
– Indépendamment de son changement de valeur
– Indépendamment de son adresse physique
• Permet une duplication des valeurs des attributs
• Intérêts :
– Représentation directe du monde réel
– Représenter les doubles
– Moyen efficace pour référencer un objet
Identité, clés, noms, …
•
SGBD relationnels : Clés
–
–
•
Danger lors des :
•
Mises à jour de la clé
•
Changements d’attributs clé
Identité dépendante de la valeur
Langages de programmation : Noms de variables
–
–
Attention
•
•
pas de test d’identité X ==Y?
Temporaire
identité dépendante des accès
Identité d’objet : test d’égalité
• Trois tests d’égalité
– Test d’identité ==
• Même oid
– Test d’égalité en surface =
•
Même valeur
– Test d’égalité en profondeur =*
• Feuilles composantes de de même valeur
Identité d’objet : test d’égalité
Identité : Impact sur le SGBD
• Implémentation
– Adresse disque ou MC
– Un numéro logique
• Exemple N° de classe + N° de séquence
• LMD
– Différents tests
– Opérations ensemblistes selon :
• Les Valeurs
• Les Oids
Lien de composition
• Objectif : Représenter d’une relation de
composition du monde réel
Composé
composant
Lien de composition
Voiture
matricule modèle type moteur
Moteur : attribut de référence = OID de l’objet Moteur
Moteur
N°
type
Nb Cylindre
Lien de composition
Contraintes de composition
• Objet composant : partagé / non partagé
• Objet composant : dépendant / non dépendant
– Destruction composite Destruction composant
• Cardinalités
– Minimale, maximale
– Inverses ( partagé /dépendant)
– Lien inverse
Liens inverses gérés par le SGBD OO
• Certains SGBD OO gèrent les liens de composition inverses
– Maj. Du lien inverse par le SGBD OO
• Class Voiture
{Modèle : string,
…
Moteur : Moteur INVERSE Moteur.ModèlesV}
• Class Moteur
{N° : string,
…
ModèlesV: Set Voiture INVERSE Voiture.Moteur}
Intégrité référentielle
• Les SGBD OO vérifient les affectations
– Attribut-référence = x
– UPDATE Voiture
WHERE modèle = ‘207’
SET moteur = X
– X doit être un (des) oid de la classe référencé
• Suppression d’un objet composant
– Les SGBD OO devrait mettre NULL dans les attributs
référence des objets composites
Impact des liens de composition
sur les SGBD
• Assurer l’intégrité référentielle
• Stockage des objets composants par rapport à leurs
objets composés
• Unité de verrouillage
• Transactions emboités
Lien composition / Association
BDOO
Entité Association
Composition
Voiture  Moteur
Association générique
Etudiant - Inscription - Cours
Orienté
Non orienté
Binaire
N-aire
Sans attributs
Avec attributs
Cardinalités quelconques
Cardinalités quelconques
Lien composition / Association
• Certains SGBD permettent les attributs référence en
attributs composants
• C’est un lien attribut – classe d’objet
• RELATIONSHIP non-attr-ref : [SET | LIST] nom-classe
[INVERSE non-classe.nom-att-ref2]
Représentation des associations
• Associations binaires sans attributs :
Lien(s) de composition dans le sens des reqûetes
• Association n-aire et/ou avec attributs :
Une classe d’objets avec un lien de composition par rôle (dans le
sens des reqûetes)
• Exemple : inscription (avec une date) d’un étudiant à un cours
Hiérarchie d’héritage
• Objectif des LP OO : réutilisation (réduire le coût de développement)
Héritage des propriétés
Redéfinition des propriétés pour les adapter
• Objectif des BD OO : représentations multiples du monde objet
– Annie est :
•
•
•
•
Membre du personnel de l’hôpital
Médecin
Chirurgien
Patient
• Lien « is-a » ou lien de généralisation/Spécialisation
Héritage (exemple)
Propriétés des liens is-a
• Inclusion des populations
– Tout objet d’une sous-classe est aussi objet de sa
surclasse
– Exemple : un objet de la classe Médecin peut aussi
être un objet de la classe Personnel
• Héritage des propriétés
– La sous-classe hérite des :
• Attributs valeur
• Attributs référence
• Et des méthodes
– Exemple : infirmier a pour attributs AVS, nom,
adresse, salaire mensuel, service et horaire
Propriétés des liens is-a
• Substituabilité
– On peut toujours employer un objet spécifique à la place de
l’objet générique
– Exemple : Ajouter au service de réanimation un médecin.
• Sous-typage : Une sous-classe peut avoir des :
– Propriétés supplémentaires
• Infirmier à l’attribut horaire
– Propriétés redéfinies
• Domaine d’un attribut hérité plus spécifique dans la sous-classe
• Code d’une méthode hérité adaptée à la sous classe
Héritage (Exemple)
Classe Employé
Nom
Adr
Age
Sal
Saisie
Afficher
AugSal(Pourcen)
Code des opés
- Saisie
- Afficher
- AugSal
Lien d'héritage
Saisie
Afficher
AugSal(Pourcen)
MajEcole (Eco)
NomEcole : Chaine
Nom
Adr
Age
Sal
Code des opés
- Saisie
- Afficher
- AugSal
Ecole
Code des opés
- MajEcole
- NomEcole
Classe Ingénieur
Redéfinition d’attribut
• Exemple d’attribut complexe complété
Restrictions à la hiérarchie
• Dynamique?
– Un objet peut-il changer de classe?
• Un infirmier devient médecin
– Implémentation plus complexe (instances de formats
différents)
Les SGBD OO offrent en général des hiérarchies
statiques
• Instanciations multiples ?
• Un objet du monde réel peut-il être décrit par
plusieurs instances de classes différentes
• Exemple : Annie est rhumatologue et Chirurgien
• Implémentation plus complexe
 Non : Sous-classe commune
Héritage multiple
Employé
Ingénieur
Commercial
Ingénieur Commercial
La classe Ingénieur Commercial hérite des propriétés de même nom de ses
deux superclasses
Comportement
• Le comportement des objets est définis
par des méthodes ou opérations
• Méthodes sont spécifiées dans les classes
• Stockées dans les SGBDOO
• Elles possèdent une signature et une
implémentation
• Elles permettent d’accéder aux propriétés
de l’objet (principe d’encapsulation)
Méthodes
• Signature
– Nom
– Type de résultat (void si pas de résultat)
– Paramètres (s’ils existent) : nom et type
• Implémentation
– Instructions LPOO (maj. Objets)
– Instructions SGBDOO (reqûetes SQL)
– Appels à d’autres objets
Encapsulation
• Les attributs d’un objet sont privés et seules les
méthodes peuvent mettre à jour leurs valeurs.
• Indépendance des données
– La structure des données est cachée aux utilisateurs
• Avantages
– Implémentation de la méthode peut changer sans
affecter les utilisateurs
– La structure des données peut changer sans affecter
les utilisateurs
– Peu de code à réécrire
Encapsulation
• Exemple
Autorisé
Saisie
Afficher
AugmenterSal
(Pourcen)
Nom
Freddy
Adr
Poitiers
Age
30
Sal
15000
Code des opérations
- Saisie
- Afficher
- AugmenterSal
Interdit
Encapsulation
Objet
Méthode
Méthode
Interface
Messages
Méthode
Données
Méthode
Méthode
Exemple d’encapsulation
CLASS Personnel
• Interface visible
INT salaire() signatures
VOID newService (servoid : Service)
VOID afficher()
• Implémentation invisible
ATTRIBUTE NSS : STRING ;
ATTRIBUTE nom : STRING ;
ATTRIBUTE adresse : STRING ;
ATTRIBUTE sal_mensuel : INT ;
RELATIONSHIP service : Service
INVERSE Service.Personnes
Exemple d’encapsulation (2)
Implémentaton invisible (suite) : code des méthodes
salaire ()
{ return sal_ mensuel }
newService (servoid: Service)
{ self.service := servoid }
afficher ()
{ PRINT(‘NSS:', self.AVS) ; PRINT('nom:', self.nom) ; PRINT('adresse:',
self.adresse) ; PRINT('salaire mensuel:', self.sal_mensuel) ;
}
Encapsulation : seul l'objet lui-même (ie. les instructions de ses méthodes)
peut accéder à ses attributs
Redéfinition de méthodes
spécification d’une méthode existante dans une superclasse au niveau d’une
sous-classe, avec une implémentation différente
Nom
Personne
Age (0 < Age < 120
Age
Age
Etudiant
Enseignant
18 < Age < 60
22 < Age < 65
Salaire mensuel de tout le
personnel
•
Sans redéfinition
SELECT p.salaire()
FROM p IN lespersonnes
WHERE NOT (p IN lesmédecins)
SELECT p.medSalaire()
FROM p IN lesmédecins
WHERE NOT (p IN leschirurgiens)
SELECT p.chirurSalaire()
FROM p IN leschirurgiens
•
Avec redéfinition : même nom de méthode, codes
différents
SELECT p.salaire()
FROM p IN lespersonnes
Polymorphisme
• Variable polymorphe : Variable contenant des valeurs
de types différents
• Opération polymorphe : Opération dont les arguments
peuvent avoir plus d'un type
i := 3 + 2; -- i de type entier
c := "Bon" + "jour"; -- c de type chaîne
écrire (i);
écrire (c);
Polymorphisme par surcharge
•
Contexte : Deux classes indépendantes, au sens où elles n'ont pas
de lien d'héritage
• Définition : Le même nom est utilisé pour dénoter des opérations
ayant des significations différentes
• Exemple :
Classe Employé avec opération Afficher
Classe Société avec opération Afficher
e et s deux instances respectives de Employé et Société
 L'opération Afficher est polymorphe car le comportement du
message Afficher envoyé à l'objet e est différent du comportement
du message Afficher envoyé à l'objet s
Polymorphisme d’héritage
• Contexte : Deux classes associées par un lien d'héritage
• Définition : Tout objet d'une classe C est utilisable dans
le contexte d'une superclasse de C
• Exemple :
- classe Employé avec opération Afficher
- classe Ingénieur inherit Employé
- l'opération Afficher de Employé est applicable à tout
objet de Ingénieur
Persistance
• La persistance des objets : tout objet doit pouvoir
persister sur disque au-delà du programme qui le créé.
 Un objet peut être persistant ou transient.
 Objet persistant : objet stocké dans la base de données et dont
la durée de vie est supérieure au programme qui le créé.
 Objet transient : objet restant en mémoire, dont la durée de vie
ne dépasse pas celle du programme qui le créé.
Persistance et populations
• Objectifs :
– BD : gérer des ensembles d’objets permanents :
populations
– LP OO : permettre aux utilisateurs de manipuler de la
même manière des objets permanents et temporaires
• SGBD classique
– Relation : record type, type d’entité
• Définition de la structure des occurrences
potentielles permanentes par définition
• SGBDO fournit des outils aux utilisateurs pour gérer :
– Les populations des classes
– La persistance des objets
Exemple de gestion de population
• Via les collections (SET, LIST, …)
• L’utilisateur crée une collection et y insère
les objets
• Exemple : les médecins de l’hôpital
M : Médecin ;
Lesmédecins : SET Médecin ;
déclaration
m:=Médecin(…,nom : 4meziane’,...)
lesmédecins.insert_élément(m) ;
insertion
SELECT x.nom FROM x IN les medecins
WHERE x.nom = ‘MEZIANE’
Utilisation
CONCLUSION
• Meilleure représentation du monde réel
• Réutilisation
• Efficacité pour les nouvelles applications
Mais
• Méthodologie de conception incomplètes
• Compétition entre standards
• Absence de théorie
• Migration difficiles des SGBDR vers les
SGBDOO
• Solutions propriétaires