Le modèle relationnel ou logique¶

Le modèle relationnel ou logique se fonde sur le concept mathématique des ensembles (domaine, relation, attribut).

Une base de données relationnelle est une collection de données mises en relation dans des tables logiques; une table étant un ensemble de lignes et de colonnes.

Afin de déterminer quelles sont les tables à créer dans la base de données, on applique les étapes de passage du modèle entité-association vers le modèle relationnel, tout en s'assurant de respecter les règles du modèle relationnel.

passage

Termes du modèle relationnel¶

Cohérence : Toute valeur prise par un attribut doit appartenir au domaine sur lequel il est défini.

✔ En SQL , on donnera un type aux colonnes de données.
Unicité: Tous les éléments d'une relation doivent être distincts.

✔ En SQL, la table possède toujours une clé primaire unique pour chaque entité.

Cette clé primaire est généralement l'identifiant d'une classe d'entité.

Des index peuvent aussi être ajoutés.

Clé primaire : Identifiant minimum d'une table.

En SQL, à la création d’une table, nous pourrons utiliser la contrainte PRIMARY KEY pour désigner la clé primaire.
Intégrité référentielle: Cette règle impose qu'un attribut ou ensemble d'attributs d'une relation apparaisse comme clé primaire dans une autre relation.

✔ En SQL, lors de la création de clés étrangères, la clé primaire de la table reliée devra obligatoirement exister auparavant.

Clé étrangère: Attribut ou ensemble d'attributs vérifiant la règle d'intégrité référentielle.

En SQL, une clé étrangère sera créée avec la contrainte REFERENCES ou FOREIGN KEY, selon le besoin.
Valeur nulle: Dans le modèle relationnelle, la notion de nullité est admise. C'est une valeur représentant une information inconnue ou inapplicable dans une colonne.

✔ En SQL, si une colonne ne peut contenir de valeur nulle, nous devrons ajouter la contrainte NOT NULL.

Attention : une valeur nulle en base de données n’est pas du tout la même chose qu’une valeur égale à 0!
Contrainte d'entité: Toute valeur participant à une clé primaire doit être non NULL.

✔ En SQL, cette contrainte est implicite dès qu'on crée la clé primaire.

Étapes de passage du modèle entité-association vers le modèle relationnel¶

Chaque classe d'entité devient une table de données
- Le nom de l'entité devient le nom de la table
- Les attributs de l'entité devient des champs de la table (colonnes)
- L'identifiant de l'entité devient la clé primaire de la table
Prenons le schéma entité-association suivant :

Les classes d'entité deviennent des tables avec clé primaire :
Les attributs composés sont décomposés en plusieurs colonnes

Exemple : Adresse devient 4 colonnes : numéro civique, rue, ville, code postal

Donc, dans la table Etudiant, on doit exploser ce champ :
Les attributs multivalués deviennent une table de validation
- La clé primaire de cette table est généralement une valeur numérique séquentielle
- Chaque valeur possible devient une ligne (un enregistrement)
  
  Exemple :
  
  🎮 Dans une classe d'entités Jeux Vidéo, on retrouve l'attribut Plateformes.
  
  🕹 Dans plateformes, on retrouve toutes les plateformes sur lesquelles on peut jouer à un jeu (PC, Playstation, XBox, Switch...).
  
  On crée donc une table qui contiendra chaque valeur de plateforme possible.
  
  noPlateforme nomPlateforme
  
  1 PC
  
  2 Playstation
  
  3 XBOX
  
  4 Switch
Une relation 1:1 vers 1:N ajoute une clé étrangère dans la table 1:1

Exemple :

Un étudiant est inscrit dans un programme (1:1). Un programme peut être suivi par plusieurs étudiants (1:N).

❌Si on met un numéro d'étudiant dans la table Programmes, alors un programme n'aura qu'un seul étudiant associé.

✔ Si on met un numéro de programme dans la table Etudiants, alors les programmes sont indépendants, mais chaque étudiant se voit associer un numéro de programme.

Dans notre exemple:
1. on ajoute le numéro de programme dans Étudiant pour indiquer à quel programme chaque étudiant est inscrit
2. on ajoute le numéro de programme dans Cours pour indiquer à quel programme appartient chaque cours
Une relation 1:N vers 1:N crée une table de jointure
- La table porte le nom de la relation
- Elle contient :
  - Les clés des deux entité reliées
  - les attributs de la relation
  - La clé primaire est le tuple des deux clés étrangères et, au besoin, une autre colonne
    
    Exemple :
    
    Un prof enseigne plusieurs cours à chaque session. Un cours peut être dispensé par plus d'un prof à chaque session.
    
    Un prof enseigne un cours à une session donnée. (Mélissa, IntroBD, H26) est un tuple unique qui forme la clé primaire.
Dans notre exemple, on se retrouve avec deux tables de jointure :
On relie les tables entre elles avec le bon type de relation
- Créer un schéma ordonné sans croiser les lignes lorsque possible
- Utiliser le bon type de représentation (1:N, 0:N, 1:1, 0:1)
Exemple :
On applique les règles de nomenclature
- Nom de tables significatifs, sans espace, sans accent
- Si une table de jointure n'est pas claire, on ajoute le nom des tables liées
- Nom des champs : nom significatif + nom de la table
Pourquoi ?

Les règles de nomenclature sont différentes d'une entreprise à une autre, mais chose certaine : elles en ont toutes.

Pourquoi ajouter le nom de la table à chaque champ ?

Lorsqu'on extrait des données de deux tables ayant le même champ, ex. : Membre a un nom et Instructeur a aussi un nom... alors la base de données ne peut savoir magiquement quel nom on lui demande à moins de spécifier quelle table :
```
SELECT nom, nom 
FROM Membre, Instructeur; 
--Impossible de savoir quel nom extraire en premier ou en deuxième
```
De plus, si une telle requête fonctionnait, lors de l'extraction on aurait comme résultat :

nom nom

Julie Marco

Lequel est lequel ???

Une façon de l'écrire pour que ça fonctionne, serait d'utiliser le nom de la table avant chaque champ :
```
SELECT Membre.nom, Instructeur.nom 
FROM Membre, Instructeur; 
--Ainsi, la base de données sait quel nom aller chercher dans quel ordre
```
Pour éviter cette situation, dans le cours, nous allons ajouter le nom de la table à chaque champ.
```
SELECT nomMembre, nomInstructeur 
FROM Membre, Instructeur;
```
Cela évite de devoir mentionner la table à chaque fois lors de l'extraction de données.

Vérification finale¶

✔️ Toutes les classes d'entités sont devenues des tables

✔️ Toutes les relations sont représentées avec des clés étrangères et / ou des tables de jointure

✔️ Aucun attribut n’est dupliqué inutilement

✔️ Aucun attribut ne contient de donnée complexe ou multiple inutilement

✔️ Les noms de tables sont significatifs

✔️ Les noms de colonnes sont clairs et contiennent le nom de la table

Résumé¶

Etapes

noPlateforme	nomPlateforme
1	PC
2	Playstation
3	XBOX
4	Switch