Le monde du SQL

Chapitre 3 : Modèle conceptuel

Learning by Doing.

Service de location de voitures
ER digram location de voiture

Le diagramme suivant peut représenter le service de location de voitures. L'entité "client" permet de stocker tous les clients du service et l'entité "voiture" permettra de sauvegarder les informations sur le parque de voitures disponibles. Un client est décrit pas ces attributs, tels que nom, prénom, date de naissance et e-mail qui est un attribut unique (on ne veut pas avoir deux clients ayant le même e-mail). Il est possible d'imaginer d'autres attributs à propos du client que le gérant peut vouloir stocker, comme, par exemple, le numéro de sa pièce d'identité, l'adresse, le numéro de téléphone, etc. La voiture est décrite pas ces attributs, tels que la marque, la couleur, le modèle et la plaque d'immatriculation qui est unique. Le fait qu’un client a loué une voiture est modélisé par l'association "loue" entre le client et la voiture. Les dates de location et la date de réservation sont attachées à cette association "loue" car ces attributs décrivent la location et non un client ou une voiture: on voudrait savoir non seulement qu'un client ait loué une voiture, mais quand et sur quelle période pour pouvoir proposer cette voiture en location aux autres clients quand elle est disponible. 

Le client peut louer plusieurs voitures, mais doit effectuer au moins une location pour apparaitre dans notre base de données. Une même voiture peut être louée par plusieurs clients (probablement pas en même temps, mais en générale, par principe même de la location). Il est néanmoins possible d'avoir une voiture dans la base de données qui n'a jamais été louée. L'association entre "client" et "voiture" est donc Many-to-many.

 

Il est préférable de modéliser l'agence comme une entité au lieu de l'ajouter comme un attribut, car on peut imaginer une agence décrite par plusieurs attributs, comme son nom, son adresse, probablement son gérant. Chaque agence gère seulement une partie des voitures. On peut associer l'agence et voiture avec une association "propose" pour savoir quelle voiture est proposée en location pas quelle agence. Chaque voiture est proposée par une et seulement une agence, mais l'agence peut proposer plusieurs voitures pour la location.

 

Dans le cas plus complexe (et plus rare) ou les agences peuvent louer toutes les voitures aux clients, les trois entités client, voiture et agence sont impliquées dans la location. Pourtant, une association peut relier seulement deux entités. Pour modéliser un tel cas, il est nécessaire de créer une nouvelle entité "Location" pour associer la voiture, le client et l'agence à la location.

ER diagram location voiture 2
Podcast
ER diagram Podcast 1

"Les émissions aussi appelées les podcasts sont des canaux de diffusion qui proposent régulièrement des épisodes audios sur une thématique définie." Nous comprenons donc qu'il faudra enregistrer les informations sur les émissions et aussi sur leurs épisodes. Nous devons ajouter une entité supplémentaire pour les épisodes. On peut supposer que chaque émission est composée de plusieurs épisodes et que chaque épisode est lié à une émission en particulier. Cela donne les cardinalités suivantes: une émission doit contenir au moins un épisode mais peut en contenir plusiers, chaque épisode est proposée dans le carde d'une émission bien specifique et seulement une.

 

"Chaque utilisateur doit pouvoir créer plusieurs podcasts sur son compte." Ceci nous donne l'information sur les cardinalités. On suppose aussi que chaque podcast est créé par un utilisateur qui est son propriétaire. Les utilisateurs ne sont pas obligés de proposer des émissions pour s"inscrire sur la plateforme pour écouter. Cela donne les cardinalités suivantes: une émission doit contenir au moins un épisode, mais peut en contenir plusieurs; chaque épisode est proposé dans le cadre d'une émission bien spécifique et seulement une.

ER diagram Podcast 2

"Chaque podcast doit avoir un nom, une image de couverture, une catégorie, une description, un lien vers son flux RSS et au moins un épisode. Chaque épisode doit également avoir un nom, une image de couverture, une description ainsi que le lien vers l’enregistrement. Les dates de création de podcasts et des épisodes doivent également être sauvegardées." Ceci sont des attributs qui doivent être stocké dans notre base de donnée.

ER diagram Podcast 3

"Les utilisateurs qui souhaitent écouter les podcasts doivent pouvoir s’y abonner. Aussi, les utilisateurs doivent pouvoir commenter chaque épisode disponible sur la plateforme." On suppose que l'utilisateur peut s'abonner à plusieurs podcasts sans y être obligé. Aussi, on suppose que chaque utilisateur peut laisser plusieurs commentaires et chaque épisode peut avoir plusieurs commentaires.

ER diagram Pogcast 4

"Intégrez les modifications pour assurer les fonctionnalités suivantes :

 

1.     "Les utilisateurs doivent pouvoir répondre aux commentaires d’autres utilisateurs."

Pour modéliser cette situation, il parait logique de faire une association semblable à "utilisateur comment le commentaire". Par contre, une association peut exister uniquement entres deux entités. Vous ne pouvez pas faire associer une entité "utilisateur" avec une association "commente". I faut donc transformer cette association "commente" en entité "commentaire". Notez que l'association "comment" est du type "Many-to-many" ce qui implique que cette association doit devenir, dans tous les cas, une entité dans le modèle logique pour que l'on puisse la stockez dans la base de données. L'association "many-to-many" est transformé en entité intermédiaire associée aux deux autres entités avec "one-to-many". Cette nouvelle entité va stocké chaque commentaire laissé par un utilisateur pour un épisode. Un utilisateur peut laisser plusieurs commentaire et un épisode peut recevoir plusieurs commentaire. Par conte, un commentaire stocké par l'entité "commentaire" est forcement lié à un utilisateur et un épisode en particulier.

Par contre, notons que le commentaire de commentaire est lui-même un commentaire à un épisode. Tous les commentaire peuvent déjà être mémorisé avec une entités "commentaire" ou une association "commente" comme sur les modèles ci-dessus. La seule information qui peut être nécessaire à ajouter et le fait qu'un commentaire n'est pas indépendant, car il est rédigé en réponse à un autre commentaire. Cela est un exemple type d'une relation à soi-même. Nous allons donc transformer l'association "comment" en entité "Commentaire" associée à l'utilisateur, à l'épisode ainsi qu'à soi-même. Un utilisateur peut laisser plusieurs commentaires et un épisode peut avoir plusieurs commentaires, pas contre, un commentaire en particulier est lié à un utilisateur et à un épisode.

ER diagram podcast 6

2.     Le client souhaite pouvoir récupérer des statistiques d’utilisation de son service : la géolocalisation des abonnées, le sexe et l’âge des auditeurs, le nombre de vues pour chaque épisode, le temps d’écoute pour chaque épisode, l’appareil utilisé pour écouter un épisode.

Pour obtenir ces statistiques, il fait décider quelle information doit être récupérée, à quel moment et à quelle entité cette information est associée. Par exemple, le sexe et l'âge des auditeurs sont, à priori, des informations sur les utilisateurs. La géolocalisation ainsi que l'appareil utilisé peuvent être récupérés au moment que l'utilisateur accède au service ou au moment où l'utilisateur accède à un épisode. On peut créer une entité "Accès" pour y stocker des informations liées à chaque accès d'un utilisateur au service. On peut aussi créer une association "écoute" entre l'utilisateur et l'épisode pour y stocker les statistiques liées à l'écoute. L'association "écoute" est aussi utile pour compter le nombre de fois un utilisateur lance un épisode et aussi le temps d'écoute.

3.     Le client souhaite donner la possibilité aux podcasters de découper un épisode en plusieurs sous-épisodes."

Cette demande est très similaire à la première et c'est aussi un exemple de la relation à soi-même, car un sous-épisode est lui-même un épisode.

ER diagram Posdcast 5
Covoiturage

"Votre client souhaite créer un nouveau service de covoiturage. On vous a chargé de mettre en place la base de données relationnelle associée au service. Les particuliers peuvent proposer les courses pour une date donnée et une destination. Les voyageurs peuvent réserver leurs places dans la limite du disponible. Tous les clients doivent avoir un compte et renseigner un certain nombre d’informations. On demande aussi des détails sur le permis de conduire et la voiture du conducteur. Les voyageurs peuvent noter les conducteurs suite aux voyages ainsi que leur laisser un commentaire. À la demande du client, le commentaire peut apparaitre anonymement sur la plateforme."

Vous avez la possibilité de modéliser les voyageurs et le conducteur comme deux entités séparées ou comme une entité "utilisateur". Dans le premier cas, on suppose que les voyageurs et les conducteurs vont avoir des comptes séparés, comme, par exemple, les photographes et les acheteurs sur shutterstock. Dans le deuxième cas, on suppose que tous les utilisateurs ont la possibilité d'être voyageurs ou conducteurs via le même compte, comme cela est le cas, par exemple, sur blablacar. Le permis de conduire ainsi que la voiture sont des entités, car plusieurs informations (attributs) peuvent les décrire.

Un utilisateur peut proposer ou réserver une course. Il existe donc deux associations entre l'utilisateur et course. Une réservation est faite pour une date et pour un nombre de places. Un utilisateur peut aussi laisser une évaluation suite à ces courses: noter le conducteur, laisser un commentaire et indiquer s'il doit apparaitre de manière anonyme. Ci-dessous est l'exemple du modèle. 

ER diagram Covoiturage

"Votre client souhaite lancer un nouveau service de podcast : un service permettant à ses utilisateurs d’écouter les émissions enregistrées par d’autres utilisateurs." Commençons par un diagramme simple représentant ce service.