Notions : modèle relationnel : relation, attribut, domaine, clef primaire, clef étrangère, schéma relationnel.
Capacités attendues : identifier les concepts définissant le modèle relationnel.
Remarques : ces concepts permettent d’exprimer les contraintes d’intégrité (domaine, relation et référence)
Emprunt d’un livre dans une bibliothèque :
Illustration des caractéristiques d’un système d’information.
Contient :
Chaque description d’objet est un modèle de la réalité : le système ne retient que ce qui est nécessaire au bon fonctionnement des processus (la couleur des yeux d’Alice est inutile pour le fonctionnement d’une bibliothèque).
En plus du stockage es objets (livres, personnes, emprunts, …) le système doit garantir l’absence d’erreurs.
De manière générale, un modèle de données est une représentation de concepts que l’on souhaite étudier.
Un modèle permet d’énoncer des propriétés des données en termes logiques, et permet de programmer des processus réels complexes sous forme d’opérations élémentaires sur les données.
Défini en 1970 par Edgar F. Codd, employé à IBM.
Modèle de données <> structure de données. La structure de données est le choix d’une implémentation pour le modèle de données.
Un livre peut être représenté par un quintuplet : (“Titre du livre”, “Auteurs”, “Editeur”, année, “ISBN”)
L’ensemble des livres de la bibliothèque est alors représenté par un ensemble de n-uplets, appelé une relation.
livres = [
("Titre 1", "Auteur 1", "Editeur 1", 1988, "000-000000001"),
("Titre 2", "Auteur 3", "Editeur 2", 1987, "000-000000002"),
("Titre 3", "Auteur 1", "Editeur 2", 2015, "000-000000003"),
("Titre 4", "Auteur 2", "Editeur 1", 2001, "000-000000004"),
]Chaque relation se conforme à un schéma : description du nom et du domaine de chaque composant (attribut du schéma).
Exemple : les éléments de la relation Livre possèdent 5 attributs
On peut aussi noter le schéma de la manière suivante :
Livre(titre: str, auteur: str, editeur: str,
annee: int, isbn: str)La base de données est un ensemble de relations. Par extension, on appelle schéma d’une base de données l’ensemble des schémas des relations constituant la base.
Exemple : la bibliothèque pourrait avoir 3 relations :
Livres, Utilisateurs,
Emprunts
La modélisation se décompose en plusieurs étapes :
Une contrainte d’intégrité est une propriété logique, préservée à tout instant par la base de données, et qui garantit la cohérence des données. On distingue 4 grandes catégories de contraintes d’intégrité
Comment le choix de l’un domaine pour un attribut permet de garantir certaines propriétés ? Ou comment faire les bons choix de domaine(s) pour représenter une ou des propriétés pour garantir leurs propriétés ?
Exemples :
Le choix des domaines doit répondre à deux impératifs :
La contrainte d’entité (ou contrainte de relation) permet de s’assurer que chaque élément d’une relation est unique et identifie une entité de manière non ambigüe.
Exemple : relation Usager où on ne prendrait que “nom” et “prénom” comme attribut…
Chaque relation dont être identifiée par une clef primaire, unique et non nulle.
La clef primaire peut être un attribut ou une combinaison d’attributs. Le système garantit l’unicité de la clef primaire, donc en fonction des choix de clef primaire, certains choix seront impossibles (exemple: si clef primaire = email, deux personnes ne peuvent pas partager le même email)
Les clefs primaires permettent de servir de référence dans une autre relation.
Exemple : un n-uplet emprunt dans la bibliothèque contient deux “liaisons” entre entités (une personne et un livre)
On utilise pour cela une clef étrangère (ex: code-barre); la clef étrangère doit être une valeur pour cet attribut existant dans l’autre relation - on utilise pour cle la clef primaire).
La contrainte de référence empêche aussi la suppression d’éléments reliés : on ne pourrait pas supprimer un livre si il est emprunté, car alors la clef étrangère du n-uplet emprunt correspondant serait cassée (violation de la contrainte de référence).
Les clefs étrangères permettent de créer des relations de type un à plusieurs ou plusieurs à plusieurs
Exemple : ville de naissance d’une personne / auteur d’un livre / auteurS d’un livre / ingrédients d’une pizza.
Les contraintes utilisateur (ou contrainte métier) sont toutes les contraintes qui ne peuvent pas être exprimées par les précédentes.
Exemples :
Proposer une modélisation des départements et régions de France. Pour chaque département et région, on veut pouvoir stocker son nom, son code (27, 91, mais aussi 2A/2B et 971 à 976 pour les DOM), son chef-lieu, et la liste de tous ses voisins de même type, ainsi que la région d’appartenance pour les départements.
Proposer une modèlisation pour un catalogue en ligne basique, qui présente des vêtements par catégorie et sous-catégorie (hiérarchie à 2 niveaux). Chaque vêtement peut avoir plusieurs tailles et couleurs, et le prix dépend du vêtement, de la taille et de la couleur.
Proposer une modèlisation pour une bibliothèque de recettes : chaque recette comporte des ingrédients avec une certaine quantité, un texte, une catégorie (dessets, entrée, etc..) et zéro ou plusieurs “badges” (économique, végétarien, hiver, été, etc..)
Proposer une modélisation pour un réseau de bus. Cette dernière doit être suffisamment riche pour permettre de générer, pour chaque arrêt de bus du réseau, une fiche horaire avec tous les horaires de passage de toutes les lignes de bus qui desservent l’arrêt.
Donner la modélisation relationnelle d’un bulletin scolaire, cette dernière pouvant permettre de mentionner :
Préciser toutes les contraintes utilisateur