chap.1 Modélisation des données dans le domaine des

chap.1 Modélisation des données dans le domaine des bases de
données
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
Inconvénients
A recommander si
Exemples
Une table pour la classe et une classe pour chaque sous classe
- plus proche de la
schématisation des
diagrammes de classes (plus
proche de la réalité)
- peu d’attributs par table
- nombreuses jointures
- peu de sous-classes
pour éviter les jointures
PERSONNE (idp, nomp,
prenomp)
ELEVE (#idp, classe)
PROFESSEUR (#idp, spécialité)
Une seule classe mère, plus aucunes classes filles
- une seule table
- pas de jointures
- l’information est à un seul
endroit
- table lourde : tous les attributs
sont copiés dans la classe mère.
- on s’éloigne de la
schématisation des diagrammes
de classes
- tous les attributs ne sont pas
utilisés : valeurs indéterminés
- peu de sous-classes
- peu d’attributs dans
les sous-classes pour
éviter de surcharger la
classe mère (attributs
spécifiques)
PERSONNE (idp, nomp,
prenomp, classe, spécialité)
Pas classes mère, que des classes filles
- pas de jointures
- pas de super classe inutile
- tous les attributs de la classe
mère sont présents dans les
sous classes : surcharge des sous
classes
- classe mère abstraite
- classe mère avec peu
d’attributs
- si les sous classes sont
suffisamment disjointes
ELEVE (idp, nomp, prenomp,
classe)
PROFESSEUR (idp, nomp,
prenomp, spécialité)
II. 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.