Add advanced database chapter 2

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**.