Transcript for:
Normalisation et Conception de Base de Données

dans le précédent chapitre on a vu qu'on pouvait lier les tables et comme vous pouvez l'imaginer ça rentrait rapidement les choses un petit peu plus complexe donc c'est important avant de se lancer dans la conception d'une base de données de réfléchir à notre système d'une certaine manière et on va pouvoir se reposer sur des schémas qui sont normalisés et qui vont nous permettre de représenter la structure de nos données et qui grâce à certaines règles vont nous aider à conceptualiser notre base de données alors techniquement vous pourrez utiliser n'importe quelle pratique pour faire un schéma mais en se basant sur des normes l' avantage c'est que vous allez pouvoir vous comprendre en équipe et on va commencer par un type de schéma particulier qui est le mcd pour modèle conceptuel de données alors le mcd on peut le créer sur une feuille de papier mais non on va utiliser un logiciel vous pouvez utiliser des lots chez le dessin ou des logiciels adaptés on va plutôt partir sur un logiciel de dessin ici on va utiliser drop.io donc vous pouvez adapter je vais vous donner les normes et quel que soit le boucher que vous utilisez vous pourrez faire la même chose donc sur un nouvel onglet je vais ouvrir drop.io automatiquement je vais et créer ici un nouveau diagramme donc je vais choisir un diagramme vide et je vais cliquez sur créer donc il me propose de le sauvegarder quelque part sur mon système et je vais mettre oui j'arrive sur cette interface donc c'est une interface de dessins où on a la possibilité de mettre quelques formes prédéfinies donc dans mcd la première chose que l'on va faire c'est définir des entités donc les entités vont représenter un type de données particulier et s'écrivent de cette manière là c'est un rectangle avec un titre donc dans notre cas par exemple on a un système de recettes de cuisine là on va mettre notre mcd en français pour représenter notre logique dans notre application ensuite on va avoir des catégories pour ses recettes donc là je crée et hop un nouveau truc que je vais appeler catégorie ensuite on va pouvoir lier nos différentes entités ensemble grâce à des liaisons donc les liaisons vont être représentés un petit peu de la même manière sauf qu'elles vont avoir en général des bords arrondis et la liaison sap sera la maison appartient donc une recette appartient à une catégorie et on peut tracer des traits pour faire la liaison je vais juste redimensionner ça parce que c'est plus petit du coup et on peut faire les traits avec les petites flèches ici donc c'est l'avantagé de ce logiciel là il permet d'aller un tout petit peu plus vite ses relations là on ne va pas forcément les flécher donc à ce niveau là on va supprimer ap la flèche pour lui dire qu' il n'y a pas vraiment de sens et vous pouvez comme ça représentait votre système on peut s'imaginer que nos recettes vont avoir des ingrédients donc je crée une nouvelle entité donc je fais un contrôle c'est quand relevé on l'appelait ingrédients et à ce niveau là je vais créer une liaison hop je vais l'appeler composé par exemple une recette est composé de bouquets composés 2 et là je vais faire la liaison hop comme ceux ci on peut s'imaginer aussi qu'on a des utilisateurs qui vont créer des recettes donc là hop je vais avoir une nouvelle entité utilisateurs et je vais lier les utilisateurs grâce à une liaison qui va être créée par ou créer un utilisateur il crée une recette donc au fur à mesure comme ça je vais représenter l'entièreté de mon système et ça va me permettre de m'organiser de réfléchir donc là on n'est pas encore sur la conception de la base de données mais on réfléchit à la logique métier de notre application donc une fois qu'on a défini les grandes lignes en fait de notre système on va pouvoir remplir nos entités avec les informations qui vont être nécessaires donc je vais double cliquer dans une des entités et appuyez sur texte voilà je trouve pas ça très pratique mais on va s'imaginer qu'un utilisateur il va avoir un pseudo ensuite on peut imaginer d'autres champs comme ça que l'on va pouvoir renseigner qu'est-ce qu'on pourrait avoir on pourrait avoir un email email je veux laver ni à gauche voilà et vous créez les propriétés dont vous avez besoin pareil pour les recettes on va ici mettre le titre de la recette ensuite on va mettre qu'est ce qu'on avait en avait la durée la date de création date et il vous remplissez comme ça vos différentes entités pour la recette je pense peut-être rajouter un slug donc on va mettre slug voilà îlot sera bon alors maintenant pour les ingrédients baisse à être un peu pareil pour les ingrédients on va avoir besoin du titre en fait du nom de l'ingrédient donc là on va mettre nom de quoi on peut avoir besoin d'autres c'est pas forcément on va par contre dans la partie composition dire que on a besoin de la quantité de l'ingrédient donc là on va créer un nouveau champ quantité est comme ça mais vous représenter les différentes choses dont vous avez besoin peut-être on aura besoin typiquement de l'unité up unités est ce qu'on peut se dire que on a besoin de 3 mais on sait pas si ces trois kilos 3 grammes ce genre de choses et vous réfléchissez au fur et à mesure à votre structure alors ça appartient à une catégorie où plusieurs d'ailleurs donc dans ce cas là on va mettre ici dans la partie catégorie justin chante eater voilà est pour l'instant se contenter de ça la partie appartient on n'a pas forcément besoin de données supplémentaires pareil pour la partie crée donc on peut laisser ses relations vide une fois que l'on a fait ça on va devoir définir les cardinali t c'est à dire combien de fois cette liaison peut être fait dans un sens ou dans l'autre donc au niveau de notre liaison on double clic on va rajouter un petit peu texte et on va mettre la valeur minimale et maximum possible donc une recette lappartient a commis deux catégories au minimum elles appartiennent à 0 catégorie et combien de catégorie elle peut avoir donc si on est dans le même cas que tout à l'heure on n'avait qu'une seule catégorie part recette mais on pourrait s'imaginer un cas un peu plus complexe où on aurait une infinité de catégorie vous pourrez en avoir plusieurs dans ce cas-là remettra haine et on va définir comme ça les cardinali tewf au niveau de chacune de nos relations donc maintenant à ce niveau là une catégorie appartient à comme une recette au minimum on peut s'imaginer qu'on aurait des catégories qui seraient vides donc dans ce cas là on mettrait 0 et ensuite on peut avoir plusieurs recettes qui vont être associés à une catégorie donc on mettra n je vais sur la partie utilisateurs un utilisateur combien de recettes il a créé au minimum un utilisateur peut être créé sans forcément avoir participé au site donc là je vais lui dire que par défaut il a créé aucune recette et il peut ancrer plusieurs les recettes se sont créés par combien d'utilisateurs au minimum une recette est forcément créé par un utilisateur est aussi au maximum une recette peuvent être créés par chrome et d'utilisateurs un seul on continue une recette est composé d'ingrédients de combien d'ingrédients elle peut être composé au minimum on va s'imaginer qu'ici bas une recette sans ingrédient ça n'a pas de sens et ensuite on peut avoir plusieurs ingrédients maintenant un ingrédient dans combien de recettes il doit être utilisée au minimum on peut dire zéro on peut se retrouver des ingrédients qui ne seraient plus associé à des recettes est par contre ensuite on peut avoir un ingrédient qui appartient à une infinité de recettes donc là on mettra n est là on a défini les cardinali t les nombres qui sont associés à nos relations donc ce schéma peut ensuite être simplifiées grâce à des règles de normalisation alors là je vais vous renvoyer sur un document qui a été publiée par une université qui est beaucoup plus clair que toutes les explications que je pourrais faire parce qu'il vous donne des cas concrets qui ne s'applique pas forcément dans notre système de recettes donc on va descendre un petit peu dans la partie normalisation je vous mettrai le document en lien ne vous inquiétez pas il a il vous montre un petit peu des cas par exemple si ici on a une entité étudiants est une entité enseignants qui ont finalement les mêmes informations ce n'est pas la peine d'avoir deux entités séparées ce que l'on va faire c'est qu'on va fusionner les deux et on va mettre une entité personnes plus générique ensuite on a un autre point c'est la normalisation des noms là l'idée c'est de dire que deux ans ou deux associations ou deux attributs ne peuvent pas avoir le même nom donc là on a un problème typiquement on a deux fois adresse de livraison ça veut dire qu'on pourrait faire quelque chose de différent typiquement s'imaginer qu'on aurait une entité adresse et on lirait avec cette entité n'a pour éviter d'avoir justement deux fois adresse de livraison c'est ce qui est montré ici dans la phase de normalisation il décide de séparer la drees dans une table et de faire une liaison de cette manière là et pareil pour la partie numéro de téléphone il le sait par aussi certains attribuent peuvent être remplacés par des calculs et dans ce cas là ça ne sera pas nécessaire de multiplier les champs alors ensuite on a la partie normalisation des attributs des associations qui dit que les attributs des associations doivent dépendre des identifiants de toutes les entités en association ça veut dire que globalement quand on définit une association et qu'on met des champs à l'intérieur chacun de ces chambres dépendra à la fois de la recette et de l'ingrédient effectivement notre quantité ici elle dépend de la recette et de l'ingrédient par contre on peut se demander si l'unité de mesure est finalement elle ne dépend pas que de l'ingrédient est-ce que d'une recette à l'autre la quantité de mesure peut être différente si on estime que c'est pas vraiment le cas dans ce cas là on va déplacer ce champ là typiquement nous on pourrait se dire que si on a un ingrédient qui est par exemple une quantité d'eau qui est de l'eau l'eau sera toujours exprimé en centilitres auquel cas on va déplacer ce champ là à ce niveau là las dans notre cas c'est un peu particulier parce qu'on pourrait se dire que pour une recette la quantité d'eau va être exprimée en centilitres et pour une autre recette en millilitres suivant le type de recettes que l'on va faire donc ça peut être pertinent de le laisser là mais dans certaines situations c'est beaucoup plus clair c'est ce qui donne un exemple ici il met le nom du livreur dans cette partie là or le nom du livreur ne dépend pas du fournisseur il ne dépend que de la livraison donc on déplacera la tribu à ce niveau là ensuite on a une règle de normalisation qui est la normalisation des associations donc si on se retrouve avec une association de type 1 dans les deux sens autant fusionner les choses typiquement un fournisseur qui travaille chez un contact est dans ce cas là on a vraiment une association fantômes et autres regrouper les informations à un seul endroit comme ça et enfin vous avez la normalisation des cardinali tu es une cardinali t minimale et toujours 0 ou 1 et une carte deal était maximale est toujours un ou n est pas 2,3 donc ensuite vous avez autre règle vous avez celle ci qui dit que là on a un champ hauteur donc typiquement ça veut dire qu'on peut sauvegarder plusieurs valeurs à l'intérieur donc dans ce cas là mieux vaudra séparés et avoir une relation avec une entité dédiée à la partie auteurs enfin une dernière règle c'est que si jamais quelque chose ne dépend pas de la clé primaire dans ce cas là ils devraient être séparées dans une entité donc typiquement ici on a des choses qui dépendent du modèle de l'avion dont vu que ça ne dépend pas de lady de l'avion du numéro d'avion est plutôt du modèle on va séparer dans une partie différente donc ça c'est des règles que vous pouvez aussi appliqué naturellement lorsque vous travaillez à peut-être moi le détail que j'ai oublié c'est un peu un peu pénible là à bouger mais c'est que j'ai oublié de rajouter les primaires donc pour la recette là que les primaires mais on n'a pas forcément quelque chose donc on va mettre un à dix on va faire la même chose pour les utilisateurs donc pour les utilisateurs on pourrait utiliser autre chose comme une clé primaire on pourrait se dire que par exemple l'email constitue un identifiant mois dans ce cas là je vais mettre un avis parce que je sais que mes utilisateurs peuvent changer un peu à la volée de 10000 donc ça peut être pénible pareil pour les catégories mais dans certains cas si on prend un système étudiants on pourrait avoir des numéros qui seraient associés par un autre système et dans ce cas là on n'aurait pas forcément un heidi may dans notre exemple ici on a toujours un à dix donc cette manière de représenter les choses c'est ce que l'on appelle mcd et ça permet de facilement réfléchir à notre système se mcd il n'a pas du tout de rapports avec sql et la structure des données pour l'instant mais l'avantagé c'est qu'ensuite ce système là on va pouvoir le traduire mlr des mots pour modèle relationnel logique de données qui va représenter véritablement nos données dans notre base de données nous ce que l'on va faire c'est qu'on va se mettre un petit peu sur le côté et on va faire justement cette traduction la première règle de la traduction est très simple elle stipule que toutes les entités vont devenir d'état donc on va avoir une table utilisateurs une table recettes une table catégorie voilà et enfin une table ingrédients donc les noms des chambres pour être amené à changer entre les deux mais ça c'est la première règle elle est facile à appliquer la seconde règle stipule que les associations de type 1 n donc si une association que l'on a par exemple ici une recette en a 1 ici n à ce niveau là les relations de ce type là sont traduites par des clés étrangères donc c'est ce que l'on avait vu avec le système de catégories tout à l'heure la khl étrangères va se situer du côté de la relation qui a le 1 1 ou le 01 donc c'est à ce niveau là et ensuite va faire une référence à la clé primaire de l'entité lié donc typiquement ici ça veut dire que sur recettes on va rajouter un nouveau champ que l'on va appeler user heidi donc la forêt renommer les champs en rapport avec notre base de données je vais en profiter pour le faire de suite voilà donc on aime tout en anglais là on va appeler ça rit 6 et du coup user à eddy permettra de faire le lien avec les 10 de la table utilisateurs alors hop je vais essayer de forcer un petit peu la flèche à être un peu plus joli voilà et là je vais m users on mettra à 10 ans mettra username au lieu de pseudo on va aligner sa gauche et on mettra email la seconde règle c'est que les relations de type nmnm ca veut dire qu on n des deux côtés dans ce cas là ça va se traduire par la création d'une table intermédiaires qui va permettre de faire la liaison donc nous maintenant on veut que les recettes puisse appartenir à plusieurs catégories par exemple on peut avoir une catégorie des serres et gâteaux et dans ce cas là une recette pour être à la fois un gâteau et un dessert du coup donc dans notre situation on est dans une relation de type n m on a deux cardinal it et potentiellement infini à ce niveau là du coup on doit créer une nouvelle table de liaison donc là on va créer une nouvelle table et cette table là elle va contenir une clé étrangères pour chacune des tables donc on va avoir une clé ici qui va s'appeler recipe un bon score heidi et une autre clé qui va s'appeler catégorie 1 au score elle dit je supprime ap les autres champs parce que on en avait pas à ce niveau là principale 10 points travers l'asie de la recette et catégorie à 10 points travers l'idée de la catégorie je vais rentrer sur ce tableau là parce qu'il ya pas besoin qu'il soit aussi grand maintenant on passe sur les ingrédients donc les ingrédients ils ont un type ici qui est de type n aime comme la honda n des deux côtés donc ça veut dire que dans ce cas là on doit aussi avoir une table de liaison les tables de liaison en général comment les appels on utilise le mode le nom des tableaux plurielle et on met les tables dans l'ordre alphabétique mais à vous de voir comment voulez faire les choses donc là ce serait catégorise voilà la remettrai tilleuls et pour la partie ingrédients on va séparer donc on va avoir une table de liaison donc y arrive à venger alors on va imaginer que ces ingrédients à nos scores et ips et là on va mettre un gradient ce pareil c'est une convention et si vous choisissez de mettre quelque chose de différent vous pouvez faire autre chose donc là on va avoir une clé qui va pointer vers les recettes donc ça sera réussie par idi est une clé qui va pointer vers les ingrédients qui sera ingrédients kaédi et on n'oublie pas les champs que l'on avait mis originellement à savoir la quantité et l'unité donc la coin titi titi et unit et on fera la liaison donc ici receipts paris 10 points travers la recette et ingrédients tidy pointera vers l'idée de l'ingrédient n'hésitez pas à réorganiser impôts vos flèches pour ce soit un tout petit peu plus clair il ya des outils qui sont un peu plus adapté je voulais vous montrer d'euros.au parce que il est gratuit et il vous impose pas grand chose enfin la dernière règle concerne les associations de type 1 1 donc nous c'est pas quelque chose que l'on a ici mais c'est un exemple qu'il donne à ce niveau là un employé dirige zéro ou un service et un service est dirigée nécessairement par un employé dans ce cas-là ça reprend un petit peu le même principe que la première règle on crée une clé étrangères sauf que la particularité c'est qu'on va mettre des contraintes comme quoi le numéro de l'employé que l'on a au niveau de notre service va être unique et non vide de la même manière à ce niveau là dans notre système de relation on va préciser que dans cette partie là on aura une contrainte d'unicité sur la combinaison recettes ingrédients on ne pourra pas avoir deux fois l'association qui va être faite de cette manière là ça ne peut pas être multiples reprises la même catégorie donc on en rajoutera des contraintes d'unicité mais sur la combinaison des deux choses et la grâce à cette logique là de séparation on a conçu la structure de notre base de données et c'est ça que l'on va pouvoir appliquer dans notre système donc c'est quelque chose qui peut être fait de manière à 10 peu automatique quand vous avez l'habitude de faire les choses mais je vous conseille de commencer par faire cette schématisation ça vous permet de prendre les choses progressivement et de savoir un petit peu ce que vous allez devoir faire au niveau de votre structure de base de données avant de commencer une des erreurs que l'on commet malheureusement un petit peu trop souvent contre avec les bases de données c'est de se lancer directement dans la création des tables sans forcément réfléchir à la structure de notre application parce que si on réfléchit à la structure de notre application ça peut avoir un impact assez important sur la manière de structurer les données si on décide par exemple qu'une recette appartient qu à une seule catégorie ça change complètement la structure que l'on va adopter dans notre base de données typiquement on aurait simplement une clé étrangères et ça aurait suffi donc c'est pour ça que c'est important lorsque vous êtes sur un projet de réfléchir avec le reste de l'équipe et de voir un petit peu comment vous les structures et les choses pour ceux que ça intéresse je rajouterais des chapitres dans cette formation avec quelques petites tpe où on fera justement le mcd suivi du mld pour pouvoir pratiquer certains systèmes d'organisation dans le prochain chapitre ce que je vous propose c'est de mettre en pratique le mld que l'on a créé ici de créer les tables qui vont correspondre et ensuite on fera quelques exercices pour recruter les données qui nous intéresse enfin si vous êtes intéressé n'hésitez pas à regarder le court et je vous en mets très d'autres aussi en descriptions qui vous ré explique tout ce que j'ai dit dans cette vidéo mais de manière écrite donc ça peut être intéressant pour pouvoir avoir un support technique pour vous y référer mais voilà ce qu'il faut retenir au niveau de la manière de conceptualiser une base de données quand on débute donc je vous donne rendez-vous dans le prochain chapitre