Cours les bases de données relationnelles, tutoriel & guide de travaux pratiques en pdf.

Les 12 Règles d’intégrité de Codd

Cette introduction sur les SGBD-R ne serait pas complète sans l’énoncé des principes fondateurs de la théorie sous-jacente, celle du modèle relationnel.
Lorsque le Dr Codd définit le modèle relationnel en 1970, construction qui sera reprise en suite par de nombreux auteurs, il énonça un ensemble de 12 règles pour la représentation des relations en table.
Cet ensemble de règles permet de mieux comprendre le cadre dans lequel a été conçu le modèle
relationnel ainsi que la majorité des particularité du SQL. Et comprendre sur quoi on travaille est toujours un avantage à un moment ou à un autre…
Règle 0
Pour qu’un système de gestion de données soit considéré comme une base de donnée relationnelle, il doit utiliser exclusivement les relations pour gérer la base de données.
Règle 1 – Règle d’information
Toutes les informations de la base de données doivent être représentées d’une seule et même manière, notamment par des valeurs dans les colonnes à l’intérieur de lignes.
Le modèle physique est la concrétisation du modèle logique une fois la base cible choisie. Les entités deviennent des tables, les propriétés deviennent des champs dans les tables, et on voit apparaître les clés étrangères ainsi que les tables donnant corps à certaines relations multiples.
Un tel bouclage d’une table sur elle-même s’appelle aussi une auto-jointure
 Règle 2 – Règle de garantie d’accès
Chaque information stockée dans une base de données relationnelle doit pouvoir être accessible en précisant uniquement le nom de la table, le nom de la colonne et la valeur de la clé primaire.
Règle 3 – Règle des informations manquantes
Il doit y avoir un moyen d’exprimer des valeurs manquantes dans la base de données d’une façon
homogène non dépendante du type de donnée, expression qui doit être supportée dans les opérations logiques. La règle originale précise qu’il faut différencier valeur manquante et valeur inapplicable, à l’heure actuelle les SGBD-R ne proposent majoritairement que le NULL.
Règle 4 – Catalogue système
La description de la base au niveau logique doit être représentée dynamiquement par un ensemble de données normalisé de telle sorte que ce catalogue soit accessible aux utilisateurs autorisés depuis leur langage de requête.
On voit ici que les formats dBase et Paradox ne satisfont pas à cette exigence alors que Interbase ou tout autre serveur SQL ne saurait fonctionner sans tables système. Ces pour cela qu’on choisira les seconds si on doit gérer beaucoup d’intégrité référentielle ou de contraintes.
Règle 5 – Règle de sous-langage
Le système doit mettre à la disposition au moins un langage relationnel qui : (1) a une syntaxe linéaire, (2) peut être utilisé à la fois de manière interactive et dans des programmes d’application, et (3) supporte les opérations de définition de données (dont les vues), celles de manipulation de données (mise à jour et accès), les contraintes de sécurité et d’intégrité, ainsi que les opérations de pilotage de transactions (début, validation, annulation). Le langage SQL propose tout cela.
Règle 6 – Règle de mise à jour des vues
Le système doit supporter la définition des vues et les informations des tables sous-jacentes doivent pouvoir être mises à jour directement depuis la vue. Les vues modifiables ne sont pas gérées de la même façon par tous les serveurs, et les vues, même non modifiables n’existent pas en dBase et Paradox.
 Règle 7 – Insertion, mise à jour et suppression
Le système doit permettre aux opérateurs INSERT, UPDATE et DELETE d’être actifs en même temps. Le SQL standard supporte cette contrainte.
 Règle 8 – Indépendance des données physiques
Les programmes d’application et les opérations interactives ne doivent pas avoir à être modifiés si la structure physique de la base est modifiée. En ce sens SQL est un langage beaucoup plus portable que la majorité des langages classiques. Delphi et le BDE autorise d’ailleurs une très bonne isolation entre représentation physique de la base et application. On peut à ce sujet étudier l’exemple fourni avec Delphi (MASTAPP) qui fonctionne aussi bien avec des données Paradox que sous Interbase.
 Règle 9 – Indépendance des données logiques
Les programmes d’application et les opérations interactives n’ont pas être modifiés si la base de
données est restructurée, du moins tant qu’il n’y a pas de perte d’information.
Règle 10 – Indépendance par rapport aux contraintes d’intégrité
Les contraintes d’intégrité doivent être spécifiées séparément des programmes d’application et rangées dans le catalogue. On doit pouvoir les modifier comme on le souhaite, sans avoir à toucher aux applications existantes.
Règle 11 – Indépendance par rapport à la distribution des données
Les applications existantes se dérouleront normalement (1) quand une version distribuée du SGBD est introduite pour la première fois et (2) quand les données distribuées sont redistribuées dans le système.
Les versions distribuées de SQL commencent tout juste à apparaître et il est difficile aujourd’hui de donner des exemples précis de respect de cette règle.
 Règle 12 – Règle de non-subversion
Si le système dispose d’une interface de bas niveau (traitement d’un enregistrement à la fois), celle-ci n’a pas la possibilité de pervertir le système, c’est à dire de passer outre une directive de sécurité relationnelle ou une contrainte d’intégrité. SQL-92 répond à ces conditions.

La normalisation

But et Principe
Il y a plusieurs bonnes raisons de normaliser une base de données, la première relève uniquement du bon sens : Le BDE, et tous les serveurs SQL, ont été conçus sur la base de l’hypothèse que les bases qu’ils auraient a traiter seraient normalisées. De ce fait, ces SGBD-R sont plus efficaces lorsque la base utilisée est normalisée. Cela peut paraître une évidence, mais tout va mieux lorsqu’on le dit… Parmi les raisons plus spécifiquement liées au relationnel, la normalisation apporte : des requêtes plus simples à écrire11, des données plus facilement accessibles ; une meilleure intégrité des données ; la diminution des erreurs lors de l’insertion ou de la suppression de nouvelles données et une utilisation optimale des ressources.
Il faut tout de même préciser que la normalisation des bases de données n’est pas une fin en soi,
seulement un outil pratique et performant et que chaque concepteur de base de données doit décider si, dans un cas précis, la normalisation est la solution la plus efficace.
La dénormalisation est une opération parfois nécessaire, toutefois il faut bien l’entendre dans le sens que son nom indique : la suppression d’une normalisation existante… Il est donc toujours préférable, au niveau conceptuel, de commencer par concevoir une base de données normalisée. Ensuite, et seulement ensuite, on peut dénormaliser en justifiant et en assumant chaque opération ponctuelle de ce type.
Dépendances fonctionnelles et dépendances de plusieurs valeurs
Une forme normale (que nous aborderons à la section suivante) est une méthode de classification de table qui repose sur les dépendances fonctionnelles (DF) qu’elle comprend. Une dépendance
fonctionnelle signifie que si l’on connaît la valeur d’un attribut on peut toujours déterminer la valeur d’un autre attribut. La notation utilisée dans la théorie relationnelle est une flèche entre les deux attributs, par exemple A ® B s’énonce « A détermine B ». Si on connaît votre numéro de salarié dans l’entreprise on peut trouver votre nom.
La dépendance de plusieurs valeurs (DPV) signifie que si l’on connaît la valeur d’un attribut on peut
toujours déterminer les valeurs d’un ensemble d’autres attributs. La notation retenue dans la théorie relationnelle est une flèche à double pointe entre les deux attributs, par exemple A « B s’énonce «A détermine plusieurs B ». Si on connaît le nom d’un professeur on peut déterminer la liste de ses étudiants.
La compréhension des DF et les DPV joue un rôle essentiel dans celle des formes normales.
Les Formes Normales
Normaliser une base consiste à appliquer des règles regroupées sous la dénomination de « Formes normales12 ». Ces règles sont aussi utilisées, dans l’autre sens, pour valider l’état de normalisation d’une base Les formes normales sous entendent que chaque table possède une clé primaire. Chaque forme porte un numéro d’ordre (ou un acronyme). Les voici :
Première forme normale (1NF)
Il s’agit de la première règle qu’on pourrait dire fondatrice. Elle fait partie de la définition formelle des bases de données relationnelles.
Cette règle stipule que les champs de chaque table doivent être atomiques et qu’il ne peut exister de champs répétitifs. De plus, chaque champ doit avoir une signification précise constante dans le temps.