Méthodes de conception 1. Objectifs et principes 2. Le modèle objet 3. Passage au relationnel 4. Raffinement du schéma 5. Optimisation physique 6. Conclusion

1. Objectifs de la Modélisation Permettre une meilleure compréhension Systèmes réels trop complexes Abstraction des aspects cruciaux du problème Omission des détails Permettre une conception progressive Abstractions et raffinements successifs Possibilité de prototypage rapide Découpage en modules ou vues Génération des structures de données et de traitements Faciliter la visualisaton du système Diagrammes avec notations simple et précise Compréhension visuelle et non seulement intellectuelle

Générations de méthodes Méthodes d'analyse et de décomposition hiérarchiques (1ère génération) Diviser pour régner (Problème --> Sous-problème) Warnier, SADT, Jackson, De Marco Méthodes d'analyse et de représentation systémiques    (2e génération) Séparation des données et traitements Merise, Axial, SSADM Méthodes d'analyse et de conception orientées objets (3ème génération) Réconciliation données et traitements Réutilisation de composants

Objectifs des méthodes objet Réduire la distance sémantique entre le langage des utilisateurs et le langage des concepteurs meilleure communication entre utilisateurs et concepteurs abstraction du réel perçu en termes compréhensible Regrouper l'analyse des données et des traitements meilleure compréhension des choses plus grande cohérence entre l'aspect statique et l'aspect dynamique Simplification des transformations entre niveau conceptuel et niveau interne implémentation directe éventuelle du schéma conceptuel établissement possible de règles de transformations automatisées

Principales méthodes objet OOD G. Booch 1991 HOOD HOOD Technical Group (B. Delatte, M. Heitz, J.F. Muller) 1993 OOA S. Shlaer & S. Mellor 1992 OOA/OOD T. Coad & E. Yourdon 1991 OMT J. Rumbaugh, M. Blaha, W. Premerlani, et. al. 1991 OOSE I. Jacobson, M. Christerson, P. Jonson, G.Vergaard 1992 OOM M. Bouzeghoub, A. Rochfeld 1994 FUSION D. Coleman, P. Arnold, S. Bodoff, C. Dollin et. al. 1994 La notation UML Rationale et OMG une notation universelle

Les principaux modèles Modèle des objets (Object model) définition des objets (données et opérations) définition des associations entre objets Modèle dynamique (Dynamic model) états successifs des objets (cycle de vie) interactions temporelles et réponses aux stimulis Modèle fonctionnel (Functional model) processus de transformation des objets flots de données entre acteurs

Les cycles Analyse (Analysis) Conception (Design) étude du problème utilisateur génération de modèles de problèmes Conception (Design) raffinement de modèles de problèmes génération de modèles d'implémentation (prototypes) Implémentation (Implementation) codage de modèles d'implémentation génération du code des programmes

2. Le modèle des objets Objet (Object) Classe (Class) concept, abstraction ou entité clairement distinguable Classe (Class) description d'un groupe d'objet aux propriétés similaires Attribut (Attribute) propriété nommée d'une classe représentée par une valeur dans chaque instance Opération (Operation) une fonction/transformation applicable aux objets d'une classe Méthode (Method) une implémentation d'une opération pour une classe

Représentation (UML) Classe Voitures Nveh: Int Nom Type: String Marque: Constructeur Vitesse: Int Km : Int Démarrer() Accélérer() Rouler(km:Int) Freiner() Nom attributs opérations

Association Association (Association) Lien (Link) Rôle (Role) Une relation entre des instances de deux (ou plus) classes Lien (Link) Une instance d'association Rôle (Role) Une extrémité d'une association Cardinalité (Multiplicity) Le nombre d'instance d'une classe pour chaque instance de l'autre Attribut de lien (Link attribute) Un attribut de l'association instancié pour chaque lien

Représentation Estbu Personne Voiture Possède Propriétaire Possédée Date Prix Buveurs Vins Boire Estbu Abus Date Quantité

Cardinalités 1 * 0..1 1..* 0..* {ord} 3..5 1 plusieurs (0 à N) optionnel (0 ou 1) 1..* obligatoire (1 ou plus) 0..* ordonné (0 à N) {ord} 3..5 limité (de 3 à 5)

Agrégation Agrégation (Aggregation) Forme spéciale d'association entre un tout et ses parties (part-of) Poste-Travail Type Barre-Menus Bureau Corbeille Taille Sélectionner Ranger Vider * * Dossiers Outils-Bureau * NbreEléments Nom Ouvrir

Généralisation Généralisation (Generalization) Relation particulière de factorisation permettant de regrouper les attributs et opérations communs de sous-classes dans une super-classe. Personnes Employés Etudiants Hommes Femmes

Module Module (Module) Sous-système (Sub-system) Groupe de classes apparentées conçues ensemble Sous-système (Sub-system) Groupe de modules Permet de définir des vues et groupes de vues d'une BD ou plus généralement d’une application

La pratique Bien comprendre le problème à résoudre Essayer de conserver le modèle simple Bien choisir les noms Ne pas cacher les pointeurs sous forme d'attributs utiliser les associations Faire revoir le modèle par d'autres définir en commun les objets de l’entreprise Documenter les significations et conventions élaborer le dictionnaire

3. Passage au relationnel Implémentations des attributs, généralisation, et associations sous de forme de tables mémorisent les états des objets pas nécessaire d ’avoir une BD objet Implémentation des méthodes sous forme de procédures stockées état de l ’objet passé en paramètre (clés) associées à une base de données très important pour l ’optimisation client-serveur

Réduction des généralisations Aplatissage des hiérarchies 1 table par classe avec jointures une seule table avec valeurs nulles une table par feuille Réalisation de l ’héritage statique : problème des valeurs nulles pour les objets sans descendants dynamique : jointures sur clés, bien prévoir les indexes ! C C1 C2 C K C1 K C1 C C C1 C2 C2 K C2 C (c) (a) (b) 14

Implémentation des associations Une association est représentée par une table dont le schéma est le nom de l'association et la liste des clés des classes participantes et des attributs de l'association Exemple : POSSEDE (N° SS, N° VEH, DATE , PRIX ) BOIRE(NV, NB, CRU, MILLESIME, DEGRE) Amélioration possible Regrouper les associations 1 --> n avec la classe cible VOITURE (N°VEH, MARQUE, TYPE, PUISSANCE, COULEUR) regroupés si toute voiture a un et un seul propriétaire

Tabulation des collections Nombre maximum de valeurs connu N attributs déclarés Manque de dynamicité Maximum souvent difficile à estimer Requêtes complexes Valable pour N < 5 Table des valeurs avec clé Passage en première forme normale Nécessité de jointure pour reconstituer la collection Performance nécessitant un index

Exemple Appartient Habite Voiture nveh couleur marque km rouler() Personne nss nom prenoms datenais vieillir() dormir() Appart. étage no rue code ville Loge Possède Boire Inférieur Employé fonction salaire primes travailler() Buveur type état boire() Vin cru millésime degré qualité Bu_par Supérieur EmployéBuveur

4. Raffinement du schéma Risques de mauvaise conception Exemples : classe trop importante classe trop petite Exemples : Propriétaire-de-véhicule (n° ss, nom, prénom, n° veh,  marque, type, puissance, couleur, date, prix) Propriétaire-de-véhicule = personne |x| possède |x| voiture Cru (cru, qualité, degré) et Vin (nv, cru, millésime) Cru = (vins) et Vin = (vins) Anomalies redondance de données, valeurs nulles perte de sémantique

Dépendances Fonctionnelles Définition : Soient R(A1, A2 … An) un schéma de relation, X et Y des sous-ensembles de A1, A2 …An; On dit que X --> Y (X détermine Y ou Y dépend fonctionnellement de X) ssi il existe une fonction qui a partir de toute valeur de X détermine une valeur unique de Y Formellement : ssi quel que soit l’instance r de R, pour tout tuple t1 et t2 de r on a X(t1) = X(t2) ==> Y(t1) = Y(t2)

Exemples PERSONNE VOITURE POSSEDE N° SS --> NOM ? NOM --> N° SS ? VOITURE (MARQUE, TYPE) --> PUISSANCE ? MARQUE --> PUISSANCE ? PUISSANCE --> TYPE ? POSSEDE N° VEHP --> N° PROP ? N° PROP --> N° VEHP ? (N° VEHP, N° PROP) --> DATE ACHAT ?

Graphe de Dépendances VOITURE (N°VEH, TYPE, COULEUR, MARQUE, PUISSANCE)

Autre Exemple TYPE CLIENT REMISE A B C1 C2 3% 5% 4% CRU CHENAS MEDOC JULIENAS CRU TYPE CLIENT CRU --> TYPE TYPE, CLIENT --> REMISE REMISE

Notion formelle de Clé Définition : Plus simplement : Non unicité : Un groupe d'attribut X est une clé de R (a1, a2 … an) ssi : 1) X --> A1 A2 … An 2) il n'existe pas de sous-ensemble Y de X tel que Y --> A1 A2 … An Plus simplement : Une clé est un ensemble minimum d'attribut qui détermine tous les autres. Exemple : (n° veh) voiture ? (n° veh, type) voiture ? Non unicité : Il peut y avoir plusieurs clés pour une relation (clés candidates) Une est choisie comme clé primaire

Formes normales Objectifs Éviter les anomalies de mises a jour Définir des règles pour décomposer les relations tout en préservant les DF et sans perdre d'informations, afin de représenter des objets et associations canoniques du monde réel (les molécules d'informations) Éviter les anomalies de mises a jour Éviter les réponses erronées

1e Forme Définition Exemple Une relation est en 1ère forme normale si tout attribut contient une valeur atomique (unique) Exemple PERSONNE NOM PROFESSION DUPONT Ingénieur, Professeur MARTIN Géomètre Une telle relation doit être décomposée en répétant les noms pour chaque profession (Opération UNNEST)

Une telle relation doit être décomposée en 2e Forme Définition une relation est en 2e forme normale ssi : 1) elle est en 1ère forme 2) tout attribut non clé ne dépend pas d'une partie de clé Schéma R K1   K2 X Y Une telle relation doit être décomposée en R1(K1,K2,X) et R2(K2,Y)

Exemple 2e Forme Exemple 1 : Exemple 2 : Fournisseur (nom,adresse, article, prix) La clé est (nom, article) Mais nom --> adresse : pas en 2e forme Exemple 2 : R (cru,type,client,remise) La clé est (cru, client) Mais cru --> type : pas en 2e forme

Une telle relation doit être décomposée en 3e Forme Définition une relation est en 3e forme normale ssi : 1) elle est en 2e forme 2) tout attribut n'appartenant pas a une clé ne dépend pas d'un autre attribut non clé Schéma R K X Y Z Une telle relation doit être décomposée en R1(K, X, Y) et R2(X,Z)

Exemple 3e Forme Exemple Pas en 3eme forme ! Voiture (n° veh, marque, type,puissance, couleur) Type --> marque Type --> puissance Pas en 3eme forme ! Il est bon que les relations logiques soient en 3e forme : Pas de redondance Pas de perte d ’information Pas de perte de dépendance Représentation canonique du monde réel !

Exemples de Décomposition Voiture (n° veh, marque, type, puissance, couleur) Se décompose en : véhicule (n° veh, type, couleur) Modèle (type, marque, puissance) Réduction (cru, type, client, remise) Remise (cru,client,remise) Type (cru,type)

Une forme plus simple : la BCNF Définition une relation est en BCNF (Boyce-Codd Normal Form) ssi : les seules dépendances fonctionnelles sont du type clé détermine attribut non clé Plus simple que 3NF, un peu plus fort Schéma R K1      K2 X Y Une telle relation peut être décomposée en R1(K1, K2, X) et R2(Y,K1)

5. Optimisation physique On implémente pas forcément le schéma logique regroupement de relations interrogées ensemble parfois avantageux la dénormalisation évite des jointures coûteuses nécessite de gérer la redondance en mise à jour Choix du placement indexe primaire plaçant = clé primaire hachage parfois avantageux (groupes de relations) Choix des indexes contraintes référentielles attributs de sélections fréquentes indexe B-tree ou bitmap

Réglage des schémas Partitionnement de relations horizontal supporter par certains SGBD gestion d ’indexe maître vertical découpage en plusieurs tables attributs de jointures redondants Utilisation de données redondantes agrégats pré-calculés jointures pré-calculées vues concrètes

Résumé du réglage 1. Régler les requêtes en premier : vérifier les plans d'exécution générés; reformuler les requêtes sans changer le schéma; pour éviter des sous requêtes inefficaces, régler l'usage des relations temporaires intermédiaires; ... 2. Régler les dimensions des tables par partitionnement 3. Régler les indexes et l’organisation des relations 4. Considérer l'usage de données redondantes 5. Revoir les décisions de normalisation L'usage de vues permet de masquer ces réorganisations

6. Conclusion Intérêt de l’utilisation d’une méthode objet proche du monde réel démarche sémantique claire diagramme UML standards Passage au relationnel automatique outils du commerce utilisables (Rationale Rose, etc.) supporteront les extensions objet-relationnel à venir Normalisation à l’exception utile quand sémantique confuse Optimisation et réglage une étape essentielle et permanente (suivi nécessaire)