108 lines
4.4 KiB
Markdown
108 lines
4.4 KiB
Markdown
---
|
|
title: "Base de données avancées : Introduction au modèle relationnel"
|
|
date: 2022-01-12
|
|
tags: ["schema", "modèle relationnel", "relation"]
|
|
categories: ["Base de données avancées", "Cours"]
|
|
mathjax: true
|
|
---
|
|
|
|
Le point de départ de notre introduction est une unique relation universelle
|
|
contenant tous les attributs comme dans l'exemple ci-dessous:
|
|
|
|
| Vol | Avion | Capacité |
|
|
| :---: | :---: | :---: |
|
|
| IT6543 | Airbus A320 | 310 |
|
|
| AF4576 | Airbus A320 | 310 |
|
|
| EF3490 | Boeing 777 Max | 210 |
|
|
| RA7889 | Airbus A330 | 335 |
|
|
| RU7854 | Tupolev Tu-204 | 210 |
|
|
|
|
Cette modélisation n'est pas sans poser plusieurs problèmes:
|
|
|
|
* **L'espace de stockage** : sur cette petite relation, certaines données sont
|
|
enregistrées plusieurs fois.
|
|
* **Mise à jour** : si ont doit changer la capacité des *Airbus A320* suite un
|
|
réaménagement par exemple. Il faudra passer en revue l'ensemble des
|
|
enregistrements de la table.
|
|
* **Insertion incohérente** : et si on insère un avion sans vol.
|
|
* **Lors de la suppression** d'un enregistrement avec un seul type d'avion,
|
|
comme l'exemple du *Tupolev Tu-204*, on supprime aussi l'avion.
|
|
|
|
## Le modèle relationnel
|
|
|
|
Définis par E.F. Codd, le modèle relationnel se veut **indépendant** de la
|
|
représentation physique des données avec une assise mathématique forte : le
|
|
concept mathématique de relation en théorie des ensembles.
|
|
|
|
Il se base donc sur **l'algèbre relationnel** et le produit cartésien. Ce modèle
|
|
défini une façon de représenter les données, les opérations possibles et les
|
|
outils pour assurer la consistance des données.
|
|
|
|
Les objectifs sont multiples:
|
|
|
|
* éliminer les comportements anormaux
|
|
* éliminer les données redondantes
|
|
* avoir une meilleurs compréhension des relations sémantiques entre les données
|
|
|
|
## Conception d'un schéma relationnel
|
|
|
|
Lors de la conception, il nous faut éliminer toutes les anomalies de la relation
|
|
universelle afin de faciliter la manipulation des relations qui en découlent. On
|
|
parles alors de **normaliser les relations**.
|
|
|
|
Lors de la décomposition il faut veiller à obtenir un schéma qui :
|
|
|
|
* conserve l'ensemble des données
|
|
* conserve un minimum les contraintes d'intégrité tout en respectant le réel
|
|
perçu (à l'aide des formes normales?)
|
|
* éliminer les anomalies
|
|
|
|
## Schéma de base de données
|
|
|
|
Un schéma de base de données est un ensemble de schémas liés par des dépendances
|
|
référentielles : des attributs communs et des dépendances d'inclusions.
|
|
|
|
Une base de données est alors un ensemble de relations associé au schéma de base
|
|
de données et vérifiant toutes ses relations.
|
|
|
|
|
|
|
|
Dans le schéma ci-dessus :
|
|
|
|
* \\( \text{planning.num_vol} \subseteq \text{vols.num_vols} \\)
|
|
* \\( planning.matricule \subseteq pilotes.matricule \\)
|
|
* \\( \text{planning.num_avion} \subseteq \text{avions.num_serie} \\)
|
|
|
|
## contraintes d'intégrité
|
|
|
|
Tout schéma de base de données doit être conçu pour imposer le respect d'un
|
|
maximum de **contraintes d'intégrité** du réel perçu. Les contraintes
|
|
d'intégrités sont des expressions logiques devant être satisfaites à tout
|
|
instant par une instance de la base de données. Ces contraintes sont de plusieurs
|
|
types:
|
|
|
|
* sur les attributs : domaines vides
|
|
* sur les *n_uplets* : la valeur d'un attribut peut dépendre des valeurs d'autres
|
|
attributs dans le cas d'un vol, il ne peux pas atterrir avant d'avoir
|
|
décoller (en UTC bien entendu!)
|
|
* sur les relations : les clefs, les cardinalités
|
|
* sur la base de données : clef étrangères
|
|
* temporelles : évolution chronologique ( diplômes, état civil)
|
|
|
|
On va alors chercher à minimiser le nombre des contraintes tout en restant
|
|
équivalents aux contraintes d'origines.
|
|
|
|
## la notion de clé
|
|
|
|
Une relation étant un ensemble de *n_uplets*, et comme un ensemble n'a pas
|
|
d'éléments en double, on peut alors dire que chaque *n_uplet* est unique. Pour en
|
|
identifier un *n_uplet* sans fournir toutes ses valeurs tout en respectant leur
|
|
unicité, **une clé est nécessaire**.
|
|
|
|
Par définition, **une clé** est donc un groupe minimum d'attributs qui
|
|
déterminent de façon unique un *n_uplet*. Tout relation possède au moins une clé
|
|
: l'ensemble de ses attributs.
|
|
|
|
Si une relation possède plusieurs **clefs candidates**, on en choisi une qui
|
|
sera privilégiée : **la clé primaire**. Bien entendu aucun des attributs d'une
|
|
clé primaire ne peux avoir **de valeur nulle**.
|