Bravo, c'est le seul cours qui m'a permis de comprendre la modélisation MCD et son passage au MPD. Tu prends bien le temps d'expliquer avec des exemples concrets. Good work.
merci pour votre explication , jai une question slvp, pourquoi on a pas considerer le paiement comme une association entre le client et la reservation avec ces attributs?
j'ai une question a vous poser dans l'énoncé "Un client peut effectuer une ou plusieurs réservations " et dans la cardinalités de l'association effectuer entre les 2 entités client et réservation vous avez mis 1...N et 1...1 est ce que l'orsque je mets 1..N et 1...N ça veut dire un client peut effectuer une ou plusieurs réservation et dans le sens contraires une ou plusieurs réservation vont etre effectuées par un ou plusieurs client est ce que c'est vrai ou faux ??
Bonjour, Il n'y a aucun problème si on ajoute une clé primaire même si on a un numéro d'identité. L'usage du numéro d'identité, certes reste correct, mais l'usage de notre propre clé primaire est plus optimal en termes de performances (Stockage, Liaison avec autres tables, temps de Réponse des requêtes, ...)
Oui c'est possible, mais les données ne seront pas homogènes pour la clé primaire. Il y aura des clients qui auront le N° de passeport (Clients provenant d'autres pays) et d'autres auront le N° d'identité (Ceux du pays local). Donc on va utiliser 2 types de données différentes dans une même clé. Ce qui n'est pas vraiment optimal (Bien que c'est correct). Pour éviter tout cela, on crée un ID pour éviter tout problème pouvant surgir.
salut !! bon je vois dans l'exercice et précisément dans l'énoncé il y a un client procède à un paiement donc dans la cardinalité client doit etre (1,n) au lieu de (0,n). parceque au début vous avez dit qu'il y en a deux méthodes, soit en se basant sur l'énoncé ou bien on fait recours à la logique, chose qui n'a pas été respecter je crois. plus d'éclaircissement stp et merci pour ton contenu.
Bonjour Anass, Dans la phrase: "Le client procède à un paiement", il n'y a aucune expression qui exprime l'OBLIGATION du paiement. On n'a pas écrit le client DOIT procéder à un paiement, mais juste le client procède à un paiement. Et donc là, en nous référant à la logique, le client n'est pas forcé d'effectuer un paiement et donc la cardinalité minimale peut être 0. C'est complètement logique: Quand Vous accédez à un site de réservation d'hôtels en ligne, Vous n'êtes pas forcé de payer après Votre réservation: Vous pouvez réserver et renoncer après, Vous pouvez annuler votre réservation, etc. Beaucoup de scénarios peuvent avoir lieu et le processus peut s'arrêter sans qu'il n'aboutit à un paiement. J'espère que c'est plus clair pour Vous maintenant.
@@KLNTechnology Bonjour, si c'est cela la logique alors on peut dire que la cardinalité pour les réservations faites par un client peut être de (1.n), car sur les sites en ligne plusieurs clients peuvent réserver une chambre , mais la chambre ne sera attribuée au final qu'au client qui aura payé. Donc au final on devrait avoir la possibilité de mettre plusieurs options Ce serait bien d'avoir plus d'éclaircissement, merci !
Avec plaisir Meftah, Oui il y aura une série de vidéos dédiée au SQL mais malheureusement elle pourra prendre du temps pour la préparer. J'espère pouvoir la préparer le plus tôt possible.
Bravo, c'est le seul cours qui m'a permis de comprendre la modélisation MCD et son passage au MPD.
Tu prends bien le temps d'expliquer avec des exemples concrets.
Good work.
qu'Allah te bénisse toi et toute ta famille
BONJOUR
UN GRAND MERCI POUR VOS EFFORTS C EST SUPER ET BIEN BIEN Expliqué.
Merci beaucoup ça m'a beaucoup aidé à bien comprendre le cours!
Très bon explications , vraiment intéressant tes explications. Merci bro
merci pour votre explication , jai une question slvp, pourquoi on a pas considerer le paiement comme une association entre le client et la reservation avec ces attributs?
Chaîne géniale et utile
Merci 😘😘
Monsieur est ce qu'on ne peut pas considérer la date de paiement comme une attribut d'association..
j'ai une question a vous poser dans l'énoncé "Un client peut effectuer une ou plusieurs réservations " et dans la cardinalités de l'association effectuer entre les 2 entités client et réservation vous avez mis 1...N et 1...1 est ce que l'orsque je mets 1..N et 1...N ça veut dire un client peut effectuer une ou plusieurs réservation et dans le sens contraires une ou plusieurs réservation vont etre effectuées par un ou plusieurs client est ce que c'est vrai ou faux ??
dans la table client pourquoi vous avez ajouter une clé primaire alors quon peut considerer num identité comme clé primaire ??
Bonjour,
Il n'y a aucun problème si on ajoute une clé primaire même si on a un numéro d'identité. L'usage du numéro d'identité, certes reste correct, mais l'usage de notre propre clé primaire est plus optimal en termes de performances (Stockage, Liaison avec autres tables, temps de Réponse des requêtes, ...)
On peut ajouter une association(choisir) entre les entités client et chambre ?
merci beaucoup
Dans l’entité client , le N d’identité ou N passeport peut être la clé primaire parce que c un identifiant unique !!
Oui c'est possible, mais les données ne seront pas homogènes pour la clé primaire. Il y aura des clients qui auront le N° de passeport (Clients provenant d'autres pays) et d'autres auront le N° d'identité (Ceux du pays local). Donc on va utiliser 2 types de données différentes dans une même clé. Ce qui n'est pas vraiment optimal (Bien que c'est correct).
Pour éviter tout cela, on crée un ID pour éviter tout problème pouvant surgir.
@@KLNTechnology merciiii , excellent travail que faites
Salut tu expliques bien !!! Vous avez les vidéos sur le sgbdo
thank u
salut !! bon je vois dans l'exercice et précisément dans l'énoncé il y a un client procède à un paiement donc dans la cardinalité client doit etre (1,n) au lieu de (0,n). parceque au début vous avez dit qu'il y en a deux méthodes, soit en se basant sur l'énoncé ou bien on fait recours à la logique, chose qui n'a pas été respecter je crois. plus d'éclaircissement stp et merci pour ton contenu.
Bonjour Anass,
Dans la phrase: "Le client procède à un paiement", il n'y a aucune expression qui exprime l'OBLIGATION du paiement. On n'a pas écrit le client DOIT procéder à un paiement, mais juste le client procède à un paiement. Et donc là, en nous référant à la logique, le client n'est pas forcé d'effectuer un paiement et donc la cardinalité minimale peut être 0. C'est complètement logique: Quand Vous accédez à un site de réservation d'hôtels en ligne, Vous n'êtes pas forcé de payer après Votre réservation: Vous pouvez réserver et renoncer après, Vous pouvez annuler votre réservation, etc. Beaucoup de scénarios peuvent avoir lieu et le processus peut s'arrêter sans qu'il n'aboutit à un paiement. J'espère que c'est plus clair pour Vous maintenant.
@@KLNTechnology oui merci infiniment
@@KLNTechnology Bonjour, si c'est cela la logique alors on peut dire que la cardinalité pour les réservations faites par un client peut être de (1.n), car sur les sites en ligne plusieurs clients peuvent réserver une chambre , mais la chambre ne sera attribuée au final qu'au client qui aura payé. Donc au final on devrait avoir la possibilité de mettre plusieurs options
Ce serait bien d'avoir plus d'éclaircissement, merci !
Partie 2?
Bonjour Meftah,
Je te remercie pour ton intérêt.
La deuxième partie sera publiée demain.
@@KLNTechnology Merci pour votre clarification et pour vos efforts💙
Ferez-vous une vidéo sur algebre relationnel et SQL?
Avec plaisir Meftah,
Oui il y aura une série de vidéos dédiée au SQL mais malheureusement elle pourra prendre du temps pour la préparer. J'espère pouvoir la préparer le plus tôt possible.
@@KLNTechnology merci pour votre reponse 💙