TSQL - Cardinalités
Cette quête t'apprendra à représenter des cardinalités dans un schéma de base de donnée relationnelle
Objectifs
-
Comprendre le principe de cardinalité
-
Modéliser un schéma relationnel correspondant à une cardinalité
-
Savoir définir les cardinalités entre entités
Une cardinalité
Une cardinalité entre deux entités est sûrement une des propriétés les plus importantes à définir lorsque l'on conçoit un modèle de donnée relationnel.
La cardinalité est le type de relation que peut avoir une entité avec une autre. Ainsi, il existe trois types de cardinalité d'une entité à une autre.
Fil de discussions sur la définition de la cardinalité en base de donnée
One-To-Many
Le One-To-Many est la relation la plus courante que l'on rencontre dans un modèle relationnel.
Une relation One-To-Many existe dès lors qu'une seule et même entité a une relation avec plusieurs autres entités du même type.
Quelques exemples de One-To-Many:
-
Une entreprise a plusieurs salariés
-
Un plat a plusieurs ingrédients
-
Un parent a plusieurs descendants
Aucune fonctionnalité du SGBD ne permet de gérer automatiquement les cardinalités. A une cardinalité est associée une structure précise.
Lorsqu'une relation One-To-Many existe entre une entité et plusieurs autres entités du même type, on crée une table spéciale référençant les relations entre les entités.
Voici un schéma représentant la structure d'une relation One-To-Many:
Dans la relation ci-dessus, il y a un produit et ses ventes. Comme il y a plusieurs ventes pour un seul et même produit, la table contenant toutes les ventes référence chaque vente de chaque produit grâce à une clé étrangère dans la table ProductSale. Il peut y avoir une infinité de vente d'entités ProductSale pour un seul et même Product, et il y aura autant d'enregistrements dans la table ProductSale que d'achats d'un produit.
Article sur la structure d'une relation One-To-Many
Fil de discussions expliquant comment créer une relation One-To-Many en Transact-SQL
Many-To-One
Un Many-To-One existe sous la même forme qu'un One-To-Many, sauf que le sens de la **direction **n'est pas le même. C'est la même relation, mais prise de l'autre sens. En soi, il s'agit donc exactement de la même relation et donc de la même structure lui correspondant.
Fil de discussion sur la différence entre une relation One-To-Many et Many-To-One
Many-To-Many
Une relation Many-To-Many existe dès lors que plusieurs entités sont référencées par plusieurs autre entités.
Afin de réaliser une relation Many-To-Many, on crée une table de jointure. Un enregistrement d'une table de jointure joint l'index d'une entité et d'une autre.
Le schéma suivant représente un Many-To-Many:
Ce schéma permet à un produit (Product) d'appartenir à plusieurs catégories (Category). La table de jointure permettant de créer la relation Many-To-Many est ProductCategory. La table ProductCategory contient trois champs:
-
Une clé primaire
-
Une clé étrangère référençant un produit
-
Une clé étrangère référençant une catégorie
De cette manière, on a autant d'enregistrements que d'appartenance d'un produit à une catégorie.
Article sur la création d'une relation Many-To-Many
Fil de discussions autour de la création des tables de jonctions pour les relations Many-To-Many
Challenge
La gestion de stock
Le monde professionnel ayant eu vent de tes exploits, un magasin venant d'ouvrir décide de faire appel à tes services pour participer à la création d'un système informatique leur permettant de tenir compte du stock de leurs produits et des achats de ceux-ci.
Cela évitera aux employés du magasin de faire l'inventaire manuellement toutes les semaines puisque le schéma de base de données que tu vas créer permettra de tenir l'inventaire et de faire les comptes des produits vendus/stockés.
Critères de validation
-
Fournis un fichier TSQL créant le schéma adéquat pour la base de données
-
Un produit a un nom et un prix
-
Une catégorie a un nom
-
Chaque achat d'un produit est enregistré dans une table (OneToMany)
-
Un achat a lieu à une date précise et sur un produit précis
-
Le stock d'un produit est enregistré dans une table
-
Un produit peut exister sans être en stock
-
Le stock d'un produit inexistant ne peut pas exister
-
Ecris une seule requête de sélection renvoyant les stocks de tous les produits d'une seule et même catégorie
-
Créer un jeu de données de test dans le fichier TSQL qui respecte les points suivants:
-
au moins 3 catégories
-
9 produits
-
18 achats
-