From fe903401de0fc493120feb441c1fde1dcd668893 Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Tue, 18 Jan 2022 00:25:30 +0100 Subject: [PATCH] Add advanced database chapter 2 --- .../images/schema_bdd.svg | 658 ++++++++++++++++++ .../index.md | 108 +++ 2 files changed, 766 insertions(+) create mode 100644 content/bdd_avancees/2-introduction_modele_relationnel/images/schema_bdd.svg create mode 100644 content/bdd_avancees/2-introduction_modele_relationnel/index.md diff --git a/content/bdd_avancees/2-introduction_modele_relationnel/images/schema_bdd.svg b/content/bdd_avancees/2-introduction_modele_relationnel/images/schema_bdd.svg new file mode 100644 index 0000000..5021fdd --- /dev/null +++ b/content/bdd_avancees/2-introduction_modele_relationnel/images/schema_bdd.svg @@ -0,0 +1,658 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/bdd_avancees/2-introduction_modele_relationnel/index.md b/content/bdd_avancees/2-introduction_modele_relationnel/index.md new file mode 100644 index 0000000..575202f --- /dev/null +++ b/content/bdd_avancees/2-introduction_modele_relationnel/index.md @@ -0,0 +1,108 @@ +--- +title: "Base de données avancées : Introduction au modèle relationnel" +date: 2022-01-11 +tags: ["définitions", "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. + +![Schema de base de données compagnie aérienne](./images/schema_bdd.svg) + +Dans le schéma ci-dessus : + + * \\( planning.num_vol \subseteq vols.num_vols \\) + * \\( planning.matricule \subseteq pilotes.matricule \\) + * \\( planning.num_avion \subseteq 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**.