Database Reference
In-Depth Information
Son formalisme a été élaboré par Peter Chen en 1976. Il compte des entités et des asso-
ciations. Ces objets peuvent être représentés par différentes notations comme la très
française MERISE, la plus moderne UML 2 ou encore IDF1X, ER, etc.
Le
modèle logique de données
est le deuxième des modèles et se trouve être la traduc-
tion mathématique du premier. Ce modèle, élaboré par Frank Edgar Codd dans les
années 1970, comporte des « relations » (c'est-à-dire des objets mathématiques porteurs
d'informations) constituées d'attributs dont certains, communs entre différentes rela-
tions, servent de liens. Il permet d'afiner le modèle conceptuel d'un point de vue logique,
mais pas physique.
Le
modèle physique de données
est le troisième des modèles et découle directement du
second dont il n'est que la traduction physique, c'est-à-dire sur une machine SQL. Ce
modèle a aussi été élaboré par Frank Edgar Codd, mais c'est Larry Ellison, alors tout
jeune entrepreneur, qui en fait la première implémentation sur un produit qu'il dénomme
Oracle V2 (version 2, la première n'ayant jamais existé). Selon que l'on utilise Oracle,
SQL Server, DB2 ou PostgreSQL, le modèle est légèrement différent, car il résulte de la
capacité à prendre en compte ou non tel ou tel type de données, telle ou telle contrainte…
Il est constitué de tables et de colonnes, mais aussi de contraintes et d'index.
Le
modèle externe de données
est le dernier des modèles relationnels. Souvent oublié, il
permet de présenter les informations d'une manière lisible, simpliiée et enrichie de façon
à faciliter le travail des développeurs et à rendre évidente la compréhension des données
par les utilisateurs. Il est constitué de vues et de routines SQL : procédures, déclencheurs,
fonctions. À nouveau, il a été élaboré par Franck Edgar Codd, dans les années 1980, au
tout début des premières expériences sur les SGBDR commerciaux que sont Sytème R
et Oracle. Son but est de rendre indépendante la structure physique de la base, de celle
perçue au niveau du développement, ain que des modiications apportées aux tables n'en-
traînent que peu d'effets sur le code applicatif.
Bien que les développeurs ne pensent jamais à utiliser proprement le modèle externe de
données, ils en utilisent généralement une partie, celle consacrée aux routines, à force
de constater que les performances du code de traitement d'un SGBDR sont sans com-
mune mesure avec celles qu'ils peuvent obtenir d'un traitement itératif dans un langage
hôte, dès que la montée en charge se fait sentir (accroissement du volume des données
ou de la concurrence…). Il est alors dommage de constater l'absence de vues, qui leur
auraient grandement facilité le travail, surtout en termes d'évolution de la structure de
la base…
De même, l'utilisation inconsidérée des ORM (Hibernate, Symfony, Doctrine…) n'est
qu'un pis-aller de substitution au MED et possède l'inconvénient majeur de dégrader
singulièrement les performances applicatives. En effet, il n'est pas rare qu'un ORM
multiplie par 10 ou 20 les temps de réponse par rapport à une approche procédurale
en SQL.
