!!!Base de données relationnelle

[{TableOfContents}]

!!Origine

Les bases de données relationnelles sont les traductions d'idées formulées en 1970 par E. F. Codd qui travaillait alors pour IBM[1]. Il s'agit à l'origine d'une solution pour permettre la réorganisation des données selon les besoins. Le langage de communication avec les bases de données relationnelles est {{SQL}} (''Structured Query Language''). S'il s'agit aujourd'hui d'un standard ANSI/ISO, il résulte d'un travail initié en 1974, toujours pour le compte d'IBM, sous le nom {{SEQUEL}} (''Structured English Query Language'')[2].

!!En quelques mots

Le principe de ces bases de données repose sur le terme ''relation'' qui, formulé de manière informelle, désigne la proposition liant certains éléments d'un ensemble.

Le modèle relationnel ne s'intéresse pas à la nature des relations mais uniquement à leurs cardinalités, nous distinguerons donc deux types de relations :
*Les relations {{1-1}} liant un élément à un autre élément
*Les relations {{n-1}} liant plusieurs éléments à un élément
[{Image src = 'relation_1-1.gif'  caption = 'Relation 1-1'}]
[{Image src = 'relation_n-1.gif'  caption = 'Relation n-1'}]

En informatique il est naturellement question d'informations plutôt que d'éléments.

!1) Relations {{1-1}} : regrouper les informations dans des tables

Pour présenter simplement les tables, il s'agit de regrouper les informations autour d'un thème en respectant les relations {{1-1}}. Prenons un exemple : ce qui concerne un spécimen sera enregistré dans une table, ce qui concerne une détermination sera enregistré dans une autre, nous ne mélangerons pas ces informations puisqu'il peut y avoir plusieurs déterminations pour un spécimen. 

Chaque regroupement d'informations dans une table peut être perçu comme une ''ligne d'un tableau'' (pour reprendre notre table de spécimens, nous aurions une ''ligne'' pour chaque spécimen). Afin d'accéder facilement à chacune de ces ''lignes'', il convient de déterminer une information constante appelée __identifiant__ ou __clé__ __primaire__ qui permettra de repérer de manière sure chacune d'entre elles.

Si nous avons 
*le spécimen de numéro d'inventaire 152 qui mesure {{23}} cm de longueur, {{12}} cm de largeur et {{4}} cm de hauteur
*le spécimen de numéro d'inventaire 153 qui mesure {{15}} cm de longueur, {{8}} cm de largeur et {{3}} cm de hauteur
[{Image src = 'ensemble_1-1.gif'  caption = ''}]
Alors nous aurons dans notre table de spécimens deux ''lignes'' valant {{(152, 23, 12, 4)}} et {{(153, 15, 8, 3)}}.

Nous pouvons dégager pour nos spécimens un modèle général d'information de la forme

[{Image src = 'modele_1-1.gif'  caption = ''}]


Notons qu'en pratique nous n'utilisons pas le numéro d'inventaire comme identifiant puisqu'il faut être en mesure de modifier un numéro d'inventaire erroné (erreur de saisie) et qu'un identifiant ne peut pas être modifié. Nous utilisons ainsi comme identifiants dans nos bases des compteurs numériques incrémentés automatiquement ne présentant pas de valeurs significatives.

Pour détailler la démarche ensembliste de constitution d'une table, les relations {{1-1}} sont transitives (s'il y a un {{A}} pour un {{B}} et un {{B}} pour un {{C}}, alors il y a un {{A}} pour un {{C}}).

Dans une base de données relationnelle, toutes les informations liées transitivement par des relations {{1-1}} sont regroupées dans une table autour de l'__identifiant__ ou __clé primaire__. L'ensemble des informations regroupées autour d'un identifiant est un [n-uplet|http://fr.wikipedia.org/wiki/N-uplet].

Les règles que doit respecter un identifiant sont :
*être unique
*ne pas varier dans le temps
Ces règles constituent les __''contraintes d'intégrité d'une entité''__.

En reprenant l'illustration du spécimen et de ses dimensions, nous constatons que toutes les informations ne sont a priori pas liées par des relations {{1-1}} : plusieurs numéros d'inventaire peuvent en effet correspondre à une même longueur.
Pour des raisons pratiques, nous sommes amenés à regrouper dans une même table des informations qui devraient théoriquement se trouver dans des tables différentes : nous aurions dans le cas contraire une table pour la longueur, une autre pour la largeur et ainsi de suite, ce qui serait difficile à manipuler. Une démarche de modélisation nous permet cependant de résoudre cette question : en considérant que chaque spécimen a des dimensions qui lui sont propres (et qui ne sont pas reflétées par les mesures), nous obtenons une relation {{1-1}} judicieuse entre un spécimen et sa longueur.

!2) Relations {{n-1}} : relier les tables entre elles

Toutes les relations {{1-1}} sont regroupées dans des tables. Il faut ensuite être en mesure de restituer les relations {{n-1}}. En d'autres termes, si nous avons plusieurs déterminations pour un spécimen, il faut pouvoir indiquer quelles déterminations correspondent à quel spécimen.

La solution à ce problème est simple : il suffit de reporter la valeur de l'identifiant (ou clé primaire) de la table de cardinalité {{1}} dans la table de cardinalité {{n}}, cette valeur d'identifiant reportée est appelée __référence__ ou __clé__ __étrangère__. 

Pour poursuivre avec notre exemple détermination/spécimen, si mon identifiant de spécimen est le numéro d'inventaire, alors je reporterai le numéro d'inventaire sur les différentes déterminations du spécimen.

Si nous considérons que le spécimen de numéro d'inventaire {{152}} (''ligne'' {{(152, 23, 12, 4)}} de la table spécimen) a été
*Déterminé initialement par Sérafin Lampion
*Déterminé ensuite par le Professeur Tournesol

[{Image src = 'ensemble_n-1.gif'  caption = ''}]

Nous aurons dans la table détermination deux ''lignes'' (ou {{n-uplet}}) valant {{(1, 152, Sérafin Lampion)}} et {{(2, 152, Professeur Tournesol)}} avec {{1}} et {{2}} valeurs numériques uniques non significatives utilisées comme identifiants.

Pour notre détermination de spécimen, nous pouvons dégager le modèle suivant :

[{Image src = 'modele_n-1.gif'  caption = ''}]

Notons que cette table détermination est une version simplifiée, il manque notamment l'information concernant le taxon.

La seule règle que doit respecter une référence est de présenter une valeur qui existe comme identifiant dans la table référencée. Cette règle constitue la __''contrainte d'intégrité de référence''__.

!!Liens externes :

*Codd, E. F. 1970. A relational model of data for large shared data banks. ''Commun. ACM'' 13, 6 (Jun. 1970), 377-387. [10.1145/362384.362685|http://dx.doi.org/10.1145/362384.362685] [#1]
*Chamberlin, D. D. and Boyce, R. F. 1974. [SEQUEL: A structured English query language|http://www.almaden.ibm.com/cs/people/chamberlin/sequel-1974.pdf]. ''Proceedings of the 1974 ACM SIGFIDET (now SIGMOD) workshop on Data description, access and control'' [10.1145/800296.811515|http://dx.doi.org/10.1145/800296.811515] [#2]