1 D'après G.Gardarin Méthodes de conception l 1. Objectifs et principes l 2. Rappels sur le modèle objet l 3. Passage au modèle relationnel l 4. Raffinement du schéma l 5. Optimisation physique l 6. Conclusion

2 D'après G.Gardarin 1. Objectifs de la modélisation l Permettre Une bonne compréhension de systèmes réels très complexes. La formulation abstraite des aspects cruciaux du problème. l Permettre une conception progressive Abstractions et raffinements successifs. Définition de méthodes de prototypage rapides. Découpage en modules ou vues. Génération des structures de données et de traitements. l Faciliter la visualisation du système Diagrammes avec des notations simples et précises. Compréhension visuelle et non seulement intellectuelle.

3 D'après G.Gardarin Générations et méthodes l Méthodes d'analyse et de décomposition hiérarchiques l 1ère génération Diviser pour régner (le problème est décomposé en sous-problèmes) Warnier, SADT, Jackson, De Marco l Méthodes d'analyse et de représentation systémiques l 2ième génération Séparation des données et traitements Merise, Axial, SSADM l Méthodes d'analyse et de conception orientées objet l 3ième génération Réconciliation données et traitements. Réutilisation de composants logiciels.

4 D'après G.Gardarin Objectifs des méthodes objet l Réduction de la distance sémantique entre le langage des utilisateurs et celui des concepteurs Amélioration de la communication entre utilisateurs et concepteurs. Abstraction du monde réel perçu en termes compréhensibles. l Regroupement de l'analyse des données et des traitements Meilleure compréhension des phénomènes. Meilleure cohérence entre les aspects statique et dynamique. l Simplification des transformations entre les niveaux conceptuel et interne Implémentation directe éventuelle du schéma conceptuel. Établissement possible de règles de transformations automatisées.

5 D'après G.Gardarin Principales méthodes objet l OOD G. Booch1991 l HOOD HOOD Technical Group (B. Delatte, M. Heitz, J.F. Muller) 1993 l OOA S. Shlaer & S. Mellor1992 l OOA/OOD T. Coad & E. Yourdon1991 l OMT J. Rumbaugh, M. Blaha, W. Premerlani, et. al.1991 l OOSE I. Jacobson, M. Christerson, P. Jonson, G.Vergaard1992 l OOM M. Bouzeghoub, A. Rochfeld1994 l FUSION D. Coleman, P. Arnold, S. Bodoff, C. Dollin et. al.1994 l La notation UML Universel Modelisation Langage. Rationale et OMG. Une notation universelle.

6 D'après G.Gardarin Les principaux modèles l Le Modèle Objet (Object model) Utilise les définitions des objets (données et opérations). Utilise la définition des associations entre objets. l Le Modèle dynamique (Dynamic model) Considère les états successifs des objets (cycle de vie). Réagit aux interactions temporelles et peut répondre à certains stimulis. l Le Modèle fonctionnel (Functional model) Utilise les processus de transformation des objets. Gère des flots de données entre acteurs.

7 D'après G.Gardarin Les cycles de réalisation d'une base l Analyse (Analysis) Étude du problème utilisateur. Génération de modèles de problèmes. l Conception (Design) Raffinement des modèles de problèmes. Génération de modèles d'implémentation (prototypes). l Implémentation (Implementation) Codage de modèles d'implémentation. Génération du code des programmes.

8 D'après G.Gardarin 2. Rappels sur le modèle Objet l Objet (Object) Concept, abstraction ou entité clairement distinguable. l Classe (Class) Description d'un groupe d'objets dotés de propriétés similaires. l Attribut (Attribute) Propriété nommée d'une classe représentée par une valeur dans chaque instance. l Opération (Operation) Une fonction/transformation applicable aux objets d'une classe. l Méthode (Method) Une implémentation d'une opération dans une classe.

9 D'après G.Gardarin Nom_classe attributs opérations Voitures NV: Int Type: String Marque: Constructeur Vitesse: Int Km : Int Démarrer() Accélérer() Rouler(km:Int) Freiner() Représentation UML (Universal Modelling Language) l La classe est une extension du concept d'entité dotée d'opérations. Représentation d'entités

10 D'après G.Gardarin Association l Association (Association) Une relation entre des instances de deux classes ou plus. l Lien (Link) Une instance d'association. l Rôle (Role) Une extrémité d'une association. l Attribut de lien (Link attribute) Un attribut de l'association instancié pour chaque lien.

11 D'après G.Gardarin Représentation (UML) d'associations PersonneVoiture Possède PropriétairePossédée Date Prix Buveurs Vins Boire Date Quantité Abus Est_bu Entité 1 Entité 2 Association

12 D'après G.Gardarin Cardinalités d'association (1/2) l Cardinalité (Multiplicity) Le nombre d'instances d'une classe associées à chaque instance de l'autre. l Cardinalité d'association Cardinalités minimale et maximale associées à chacun des rôles de l'association, indiquant le nombre minimal et maximal d'instances d'association auxquelles participe une instance de l'entité du rôle.

13 D'après G.Gardarin Cardinalités d'association (2/2) 1 (minimum et maximum) plusieurs (0 à N) 0..1 * optionnel (0 ou 1) 1..* obligatoire (1 ou plus) ordonné (0 à N) {ord} 3..5 limité (de 3 à 5) 1 0..*

14 D'après G.Gardarin Représentation d'associations en UML PersonneVoiture Possède PropriétairePossédée Date Prix Buveurs Vins Boire Abus Date Quantité Abus Est_bu Entité 1 Entité 2 Association 1 * * 1..*

15 D'après G.Gardarin Poste-Travail Bureau Barre-Menus Corbeille Outils-Bureau Dossiers Sélectionner NbreEléments Ouvrir Taille Vider Nom Type Ranger * * * Agrégation : représentation UML de l'héritage l Agrégation (Aggregation) Forme spéciale d'association entre un tout et ses parties (part-of)

16 D'après G.Gardarin Personnes Employés Etudiants Personnes Employés Etudiants Personnes Employés Hommes Femmes Généralisation l Généralisation (Generalization) Relation de factorisation permettant de regrouper les attributs et opérations communs de classes dérivées dans une classe mère.

17 D'après G.Gardarin Module l Un module (Module) est un groupe de classes apparentées conçues ensemble. l Un sous-système (Sub-system) est un groupe de modules. l Ce concept permet de définir des vues et groupes de vues d'une BD ou plus généralement d'une application.

18 D'après G.Gardarin Conseils pratiques l Bonne compréhension du problème à résoudre. l Essayer de conserver un modèle simple. l Bien choisir les identificateurs. l Ne pas camoufler les pointeurs sous la forme d'attributs mais utiliser les associations. l Faire vérifier le modèle par d'autres pour un contrôle des définitions communes des objets de l'entreprise. l Documenter conventions et significations pour l'élaboration ultérieure du dictionnaire des données.

19 D'après G.Gardarin 3. Passage au modèle relationnel l Implémentations des attributs, généralisation, et associations sous de forme de tables qui mémorisent les états des objets. Il n'est pas nécessaire d'avoir une BD objet. l Implémentation des méthodes sous forme de procédures stockées L'état de l'objet est transmis en argument (clés), Les méthodes sont associées à une base de données. l C'est très important pour l'optimisation dans l'architecture client-serveur.

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

21 D'après G.Gardarin C C1C1 C2C2 C C1C1 C2C2 K K K (a) C1C1 C2C2 C C C C 1 C 2 (b) (c) Réduction des généralisations l p 674 l Aplatissage des hiérarchies 1 table par classe avec jointures une seule table avec valeurs nulles une table par feuille l Réalisation de l'héritage statique : l problème des valeurs nulles pour les objets sans descendants dynamique : l jointures sur clés, bien prévoir les indexes !

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

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

24 D'après G.Gardarin 4. Raffinement du schéma l Risques de mauvaise conception classe trop importante ou classe trop petite. l 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) l Anomalies redondance de données, valeurs nulles, perte de sémantique.

25 D'après G.Gardarin Dépendances fonctionnelles l Définition Soient R(A 1, A 2, …,A n ) un schéma de relation, X et Y des sous- ensembles de {A 1, A 2, …,A n }; On dit que X  Y (X détermine Y) ou encore que Y dépend fonctionnellement de X si et seulement si, pour toute extension r de R, il existe une fonction qui a partir de toute valeur de X détermine une valeur unique de Y. l Formellement  r extension de R,  tuples t 1, t 2 de r on a :  X (t 1 ) =  X (t 2 )   Y (t 1 ) =  Y (t 2 )

26 D'après G.Gardarin Exemples l PERSONNE N° SS  NOM ? NOM  N° SS ? l VOITURE (MARQUE, TYPE)  PUISSANCE ? MARQUE  PUISSANCE ? PUISSANCE  TYPE ? l POSSEDE N° VEHP  N° PROP ? N° PROP  N° VEHP ? (N° VEHP, N° PROP)  DATE ACHAT ?

27 D'après G.Gardarin Graphe des dépendances VOITURE (N°VEH, TYPE, COULEUR, MARQUE, PUISSANCE)

28 D'après G.Gardarin CRU  TYPE TYPE, CLIENT  REMISE TYPECLIENTREMISE A A B C1 C2 C1 3% 5% 4% TYPECLIENTREMISE A A B C1C1 C2C2 C1C1 3% 5% 4% CRU CHENAS MEDOC JULIENAS Autre exemple CRU TYPE CLIENT REMISE

29 D'après G.Gardarin Notion formelle de Clé l Définition : Un groupe d'attribut X est une clé du schéma de la relation R (A 1,A 2, …, A n ) si et seulement si : l 1) X  A 1 A 2 … A n l 2) Il n'existe pas de sous-ensemble Y de X tel que l Y  A 1 A 2 … A n l Plus simplement Une clé représente un ensemble minimum d'attributs qui détermine tous les autres. Exemple : (n° veh) voiture ? (n° veh, type) voiture ? l Non unicité Il peut exister plusieurs clés pour une relation (clés candidates). Une clé doit alors être choisie comme clé primaire.

30 D'après G.Gardarin Formes normales l Objectifs Définir des règles de décomposition des relations l tout en préservant les Dépendances Fonctionnelles, l sans perte d'informations, pour représenter des objets et associations canoniques du monde réel (les molécules d'informations). Éviter les anomalies de mises à jour. Éviter les réponses erronées.

31 D'après G.Gardarin Une telle relation doit être décomposée en répétant les noms pour chaque profession (Opération UNNEST) PERSONNENOMPROFESSION DUPONTIngénieur, Professeur MARTINGéomètre 1 ière forme normale l Définition Une relation est en 1 ière forme normale si tout attribut contient une valeur atomique (unique). l Exemple

32 D'après G.Gardarin R K1 K2XY Une telle relation doit être décomposée en R1(K1, K2, X) et R2(K2, Y) 2 ième forme normale l Définition une relation est en 2 ième forme normale si et seulement si : l 1) elle est en 1 ière forme normale. l 2) tout attribut non clé ne dépend pas d'une partie de clé. l Schéma

33 D'après G.Gardarin Exemple 2 ième forme normale l Exemple 1 Fournisseur (nom, adresse, article, prix) La clé est (nom, article) Mais nom  adresse : la relation n'est pas en 2 ième forme normale. l Exemple 2 R (cru, type, client, remise) La clé est (cru, client) Mais cru  type : la relation n'est pas en 2 ième forme normale.

34 D'après G.Gardarin R KXYZ Une telle relation doit être décomposée en R1(K, X, Y) et R2(X, Z) 3 ième forme normale l Définition une relation est en 3 ième forme normale si et seulement si : l 1) elle est en 2 ième forme normale. l 2) tout attribut n'appartenant pas a une clé ne dépend pas d'un autre attribut non clé. l Schéma

35 D'après G.Gardarin Exemple : 3 ième forme normale l Exemple Voiture (n° veh, marque, type, puissance, couleur) Type  marque Type  puissance Pas en 3 ième forme. l Il est judicieux que les relations logiques soient en 3 ième forme normale ce qui garanti : l'élimination des redondances, la non-perte d'information. la non-perte de dépendance. l La 3 ième forme normale est la représentation canonique du monde réel !

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

37 D'après G.Gardarin R K1 K2XY Une telle relation peut être décomposée en R1(K1, K2, X) et R2(Y, K1) Une forme plus simple : la BCNF l Définition Une relation est en BCNF (Boyce-Codd Normal Form) si et seulement si les seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une clé entière détermine un attribut. Plus simple que 3NF, un peu plus fort. l Schéma

38 D'après G.Gardarin 5. Optimisation physique l Le schéma logique n'est pas forcément implémenté. Le regroupement de relations interrogées simultanément peut être parfois avantageux. La dénormalisation évite des jointures coûteuses. Il est alors nécessaire de gérer la redondance lors de mises à jour. l Choix du placement indexe primaire plaçant = clé primaire hachage parfois avantageux (groupes de relations). l Choix des indexes contraintes référentielles, attributs de sélections fréquentes, indexes B-tree ou bitmap.

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

40 D'après G.Gardarin Résumé du réglage l 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;... l 2. Régler les dimensions des tables par partitionnement. l 3. Régler les indexes et l'organisation des relations. l 4. Considérer l'usage de données redondantes. l 5. Revoir les décisions de normalisation. l L'usage de vues permet de masquer ces réorganisations.

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