Modélisation des données dans le domaine des bases de données chap.1 En base de données, ne pas confondre schéma et modèle. Modèle : ensemble de concept et opération de base de données. Schéma : instanciation de modèles I. Qu'est ce qu'un modèle de données 1.1 Le but Le but du modèle est de représenter à l'aide de ces concepts une application du monde réel dans le but de fournir au système une vue de l'application. 1.2 Mécanisme d'abstraction et d'opérations Un formalisme pour décrire les données. Ex: notion de classes. Des opérations pour manipuler les données. Ex: Accéder à différentes sous classes d'une classe donnée. 1.3 Un modèle de données pour une famille d'application Le modèle relationnel permet de traiter des applications où on va gérer une activité. Quand on s'intéresse à la tectonique des plaques, les caractéristiques géographiques ont une grande importance pour notre application. Si l'on s'intéresse à l'évolution des objets, les aspects temporels doivent être pris en compte. On pourra donc décrire les caractéristiques géographiques de notre application. Le modèle devra offrir aussi des opérateurs pour exprimer les requêtes sur plus d'opérateurs spatiaux. 1.4 Impact du modèle sur l'application L'utilisation du modèle pour représenter une application à une incidence sur la perception de l'application et sur les opérations que l'on peut faire sur cette application. Avec un modèle pauvre (hiérarchique/relationnel), on ne dispose pas d’un large choix de concept pour modéliser finement une application du monde réel. La phase de modélisation consiste donc à traduire les données de l’application à l’aide des mécanismes existant. Les concepts comme association, spécialisation/généralisation, agrégation, peuvent disparaître ou être objet de traduction delicate. Exemple : Comment représenter en relationnel une relation de spécialisation / généralisation ? C SC1 SC2 Avantages - plus proche de la schématisation des diagrammes de classes (plus proche de la réalité) - peu d’attributs par table - une seule table - pas de jointures - l’information est à un seul endroit - pas de jointures - pas de super classe inutile II. Inconvénients A recommander si Exemples Une table pour la classe et une classe pour chaque sous classe - nombreuses jointures - peu de sous-classes PERSONNE (idp, nomp, pour éviter les jointures prenomp) ELEVE (#idp, classe) PROFESSEUR (#idp, spécialité) Une seule classe mère, plus aucunes classes filles - table lourde : tous les attributs - peu de sous-classes sont copiés dans la classe mère. - peu d’attributs dans - on s’éloigne de la les sous-classes pour schématisation des diagrammes éviter de surcharger la de classes classe mère (attributs - tous les attributs ne sont pas spécifiques) utilisés : valeurs indéterminés Pas classes mère, que des classes filles - tous les attributs de la classe - classe mère abstraite mère sont présents dans les - classe mère avec peu sous classes : surcharge des sous d’attributs classes - si les sous classes sont suffisamment disjointes PERSONNE (idp, nomp, prenomp, classe, spécialité) ELEVE (idp, nomp, prenomp, classe) PROFESSEUR (idp, nomp, prenomp, spécialité) Modèle utilisés dans les méthodologies de conception Résultat = un schéma conceptuel Modèles conceptuels : Merise : Modèle entité association UML : Modèle objet => diagramme des classes III. Modèle de données sous jacent aux SGBD Au début pour stocker des données on a utilisé des fichiers (pas de modèles uniformisés), on avait recours à une certaine organisation (séquentiel indexés) et les accès aux données se faisait via des programmes en COBOL. On est passé par la suite, à plusieurs modèle : Modèle hiérarchique Les SGBD s'appuyaient au début sur des modèles hiérarchiques. Les données sont rangées selon des arborescences. (IMS, DL1). Modèle réseau Pus amélioration => modèle réseau (IDS, comité CODASYL) Modèle relationnel Codd 1967 => première commercialisation en 1980 Outils disponibles : DB2, Oracle, Sybase, SQLserver, PostgreSQL, MySQL. Modèle objet Année 90, la pensée objet. Le groupement ODMG, le produit français o2, OQL (grand frère de SQL). Echec commercial. Modèle objet – relationnel Compromis : garder l'existant et y incorporer des notions objets. (voir la norme SQL3) Modèle multi – dimensionnel Seulement deux dimensions dans une base de données relationnelles. Dans le multi dimensionnel, on va intégrer différents axes pour de l'analyse de données. Exemple : La vente par modèle et par motorisation de différents véhicules par années et selon différentes régions. Technologie OLAP Produits : data warehouse Modèles géographiques Outils SIG, ex: ESRI IV. Passage du modèle conceptuel (II) au modèle logique (III) SC => SL Règles de passage : Il est nécessaire de traduire le schéma de données obtenu via la méthodologie de conception en terme compréhensible par le SGBD. Par exemple depuis un schéma EA vers un schéma relationnel on va parler de processus de décomposition et de normalisation. Cf. EXERCICE 1 Règle de transformation de la relation de spécialisation / généralisation dans un schéma relationnel.