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) Cette relation pose des problèmes...

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

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

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

Nécessité de la normalisation (5) 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)

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

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.

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.

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

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

SGBD : Evolution Applications plus complexes Couts de développement important  En faire plus au SGBD APPLICATION 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 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

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

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

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 Structuré Collections Atomique User Defined Set Time Array Date List Bag Long String Float

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 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 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 Moteur matricule modèle type moteur N° type Nb Cylindre Moteur : attribut de référence = OID de l’objet Moteur

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

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

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

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 Nom Adr Age Sal Poitiers 30 15000 Freddy Code des opérations - Saisie - Afficher - AugmenterSal Saisie Afficher AugmenterSal (Pourcen) Interdit Autorisé

Encapsulation Méthode Interface Données Objet Messages

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 Personne Nom Age (0 < Age < 120 Age Etudiant Enseignant Age 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