Dépendances et normalisation (1)

Présentation au sujet: "Dépendances et normalisation (1)"— Transcription de la présentation:

1 Dépendances et normalisation (1)

2 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.

3 Nécessité de la normalisation (1)
Soit la relation R (produit, client, adresse, date, quantité_commandée, montant) Cette relation pose des problèmes...

4 Nécessité de la normalisation (2)
L’adresse du client est répétée autant de fois qu’il y a de commandes  redondance des informations

5 Nécessité de la normalisation (3)
Si l’adresse change, il faut modifier la base à plusieurs endroits  anomalie de modification

6 Nécessité de la normalisation (4)
Si on insère la ligne (Disquettes, Dubois, Dijon, 10/03/01, 100, 200), Dubois aura deux adresses  anomalie d’insertion

7 Nécessité de la normalisation (5)
Si Martin annule sa commande, on perd son nom et son adresse…  anomalie de suppression

8 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.

9 Nécessité de la normalisation (7)

10 But de la normalisation
Fixer des règles permettant de passer de la première représentation (incohérente) à la deuxième (cohérente).

11 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.

12 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é).

13 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é.

14 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é.

15 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)  ARRIVEE (NUMVOL, JDEP)  NUMAV (NUMVOL, JDEP)  NUMPIL (NUMVOL, JDEP)  HDEP (NUMVOL, JDEP)  JARR (NUMVOL, JDEP)  HARR Le couple (NUMVOL, JDEP) est donc bien la clé de la relation VOL. Il y a donc deux attributs clé.

16 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 sous- ensemble 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.

17 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. Exemple de relation non normalisée - 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.

18 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.

19 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.

20 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.

21 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é.

22 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é.

23 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

24 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

25 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

26 SGBD : Evolution 1960 : SGBD hiérarchique 1970 : SGBD Relationnel
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

27 SGBD : Evolution 1980 Entité Association 1986 SGBDOO
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

28 SGBD : Evolution Applications plus complexes
Couts de développement important  En faire plus au SGBD APPLICATION SGBD BD BD

29 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.

30 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#

31 SGBD OO = SGBD + LPOO LP OO SGBD SGBD OO Développement
Structure complexe Identité Encapsulation Classe Héritage Redéfinition Bibliothèque de classe Représentation du réel Persistance Fiabilité Sécurité Langage de requête Indépendance logique/physique Partage des données Concurrence

32 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.

33 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

34 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

35 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 Identité d’objet Polymorphisme

36 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

37 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.

38 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.

39 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.

40 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)

41 Représentation Conceptuelle
Personne nom Prénoms liste 0,n liste 1,n liste 0,n Adresse N° téléphone Enfant Liste 1,n Ville N° type Date nais Rue N° CP Prénoms sexe

42 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)

43 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 ;} }

44 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.

45 Eléments de la structure
Structure complexe Structuré Collections Atomique User Defined Set Time Array Date List Bag Long String Float

46 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;

47 Structure complexe Collections Attributs multi-valués Exemples :
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 set string; attribute adresses : list T-adresse; }

48 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

49 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

50 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

51 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

52 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

53 Identité d’objet : test d’égalité

54 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

55 Lien de composition Objectif : Représenter d’une relation de composition du monde réel Composé composant Lien de composition Voiture Moteur matricule modèle type moteur N° type Nb Cylindre Moteur : attribut de référence = OID de l’objet Moteur

56 Lien de composition

57 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

58 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}

59 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

60 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

61 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

62 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]

63 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

64 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

65 Héritage (exemple)

66 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

67 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

68 Héritage (Exemple) Classe Employé Lien d'héritage Classe Ingénieur Nom
Saisie Code des opés - Saisie - Afficher - AugSal Adr Afficher Age AugSal(Pourcen) Sal Lien d'héritage Code des opés - Saisie - Afficher - AugSal Nom Saisie Adr Afficher Age AugSal(Pourcen) Sal Code des opés - MajEcole - NomEcole MajEcole (Eco) Ecole NomEcole : Chaine Classe Ingénieur

69 Redéfinition d’attribut
Exemple d’attribut complexe complété

70 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

71 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

72 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)

73 Méthodes Signature Implémentation 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

74 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

75 Encapsulation Exemple Nom Adr Age Sal Poitiers 30 15000 Freddy
Code des opérations - Saisie - Afficher - AugmenterSal Saisie Afficher AugmenterSal (Pourcen) Interdit Autorisé

76 Encapsulation Méthode Interface Données Objet Messages

77 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

78 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

79 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 Personne Nom Age (0 < Age < 120 Age Etudiant Enseignant Age 18 < Age < 60 22 < Age < 65

80 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

81 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);

82 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

83 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

84 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éé.

85 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

86 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

87 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