Cours 4
11
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
11
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
Cours 4 La modélisation des données • Étape indépendante du SGBD qui servira à l’implantation • Consiste à modéliser graphiquement sur papier les données qui serviront à construire la B.D. • Le modèle de données permettra de visualiser l’organisation logique des données Étapes de modélisation : 1. Identification des entités 2. Collecte des attributs et allocation aux entités 3. Identification des clés primaires des entités 4. Identification des dépendances fonctionnelles entre les attributs à l’intérieur des entités 5. Identification des dépendances fonctionnetre entités et ajustements au modèle 6. Construction du dictionnaire de données 7. Transposition en modèle relationnel La notion d’entité • L’entité est l’objet de base de la modélisation et représente un élément que l’on retrouve dans la situation à modéliser, par exemple un être humain, une activité, on objet physique, etc.… • Chaque élément d’une entité est une occurrence, l’ensemble formant l’entité. Par exemple, une entité "étudiant" pourrait définir un étudiant générique, et toutes les occurrences spécifiques d’étudiants seraient regroupés dans cette entité. La première étape du processus de modélisation consiste à identifier toutes les entités nécessaires à la construction d’une base de données reflétant le plus fidèlement possible la situation réelle. Peut se faire principalement : o En observant les lieux physiques o En discutant avec les personnes ...
Voir
Publié par
Langue
Français
Cours 4 La modélisation des données Étape indépendante du SGBD qui servira à l’implantation Consiste à modéliser graphiquement sur papier les données qui serviront à construire la B.D. Le modèle de données permettra de visualiser l’organisation logique des données Étapes de modélisation : 1. Identification des entités 2. Collecte des attributs et allocation aux entités 3. Identification des clés primaires des entités 4. Identification des dépendances fonctionnelles entre les attributs à l’intérieur des entités 5. Identification des dépendances fonctionnelles entre entités et ajustements au modèle 6. Construction du dictionnaire de données 7. Transposition en modèle relationnel La notion d’entité L’entité est l’objet de base de la modélisation et représente un élément que l’on retrouve dans la situation à modéliser, par exemple un être humain, une activité, on objet physique, etc.… Chaque élément d’une entité est une occurrence, l’ensemble formant l’entité. Par exemple, une entité "étudiant" pourrait définir un étudiant générique, et toutes les occurrences spécifiques d’étudiants seraient regroupés dans cette entité. La première étape du processus de modélisation consiste à identifier toutes les entités nécessaires à la construction d’une base de données reflétant le plus fidèlement possible la situation réelle. Peut se faire principalement : En observant les lieux physiques o En discutant avec les personnes impliquées o En observant les documents utilisés dans le fonctionnement actuel des opérations. o Par exemple, si l’on voulait construire une B.D. pour la gestion d’une boutique de vêtements, on pourrait retrouver les entités suivantes : Article (ou produit ou vêtement, selon le cas) Vendeur Fournisseur Client Commande Facture Succursale (dans le cas où on voudrait gérer une chaîne plutôt qu’une seule boutique)
La modélisation des données se faisant graphiquement sous forme de schéma, une entité sera identifiée par un rectangle : VÊTEMENT La notion de partie Il peut souvent être nécessaire de diviser une entité en parties, ces dernières étant des composantes physiques ou logiques d’une entité. L’entité devient donc la somme de ses parties et de l’entité principale L’entité principale et ses parties sont reliées par des relations, illustrées sous forme de trait. Par exemple, si la boutique de vente de vêtements faisait également de la fabrication de vêtements, l’entité "vêtement" pourrait être décomposée de la façon suivante : VÊTEMENT BOUTON TISSU Chaque partie de l’entité principale représente une entité à part entière, et l’entité "vêtement" est alors représentée par l’ensemble des entités cihaut. Il est important d’identifier les parties pour éviter de la redondance (répétition inutile d’information) dans la base de donnée. Par exemple, si plusieurs vêtements utilisent le même type de bouton et que l’entité vêtement n’est pas divisée, alors chaque occurrence de "vêtement" contiendrait des données identiques sur le même bouton. Ce genre de situation est à éviter dans une B.D. En divisant l’entité "vêtement" en parties, on peut accéder aux caractéristiques des boutons du vêtement en passant par la relation ainsi créée entre "vêtement" et "bouton". La notion d’attribut Les attributs sont des qualités ou caractéristiques décrivant un objet. Dans le modèle entitérelations, les attributs seront reliés aux entités. Dans notre modèle, un vêtement pourrait être caractérisé par la marque, la taille, le type (chandail, pantalon, etc.) et le prix unitaire. Un bouton pourrait avoir comme attribut la couleur et le type de bouton et le tissu pourrait avoir la couleur et le type de matériel dont il est constitué. Nous aurions donc le modèle suivant, auquel sont ajoutés les attributs :
VÊTEMENT Marque Taille Type Prix BOUTON TISSU Couleur Couleur Type Matériel Note sur la redondance des données: Dans ce cas, l’attribut couleur est présent dans plusieurs entités, ce qui constitue une certaine redondance des données. Cependant, l’attribut est de type élémentaire (texte) alors il serait inutile d’ajouter une entité couleur qui complexifierait le modèle et ne serait pas plus efficace. Si, par exemple, les couleurs étaient fabriquées sur place et nécessiteraient divers produits pour leur fabrication, alors il pourrait être justifié d’ajouter une entité "couleur". Une analyse adéquate de la situation et des besoins en information permet de régler ce genre de question. Note sur les attributs calculés: De façon générale, il faut éviter d’inclure dans la B.D. les attributs qui peuvent être calculés à partir d’autres attributs. Par exemple, dans l’entité "vêtement", il ne serait pas adéquat d’inclure un attribut "PrixSolde", représentant un prix auquel on a soustrait un certain pourcentage, étant donné que cette donnée peut être calculée à partir du prix unitaire. Le calcul du prix en solde sera pris en charge soit par le SGBD lors d’une requête, soit par le programme d’application qui accèdera à la B.D. La notion de clé Une clé est un attribut ou un groupe d’attribut qui détermine de façon unique tous les autres attributs de l’entité Il ne peut y avoir, dans un schéma donné, deux entités possédant la même clé. Attribut et clé Une clé peut être constituée d’un seul attribut (par exemple un numéro de série ou numéro d’assurance sociale, etc.), ou de plusieurs attributs dans le cas où un attribut seul ne peut déterminer un élément de façon unique. TÉLÉVISEUR Marque Modèle Résolution Supposons que cette entité regroupe les différentes sortes de téléviseurs en vente dans un magasin. Comme une compagnie peut fabriquer différents types de téléviseurs, la marque ne pourrait alors à elle seule identifier un type de téléviseur. De plus, plusieurs compagnies pourraient fabriquer le même modèle de téléviseur, alors le modèle ne peut lui non plus être un identificateur unique. Cependant, avec une marque et un modèle, on peut identifier uniquement une catégorie de téléviseur, alors ces deux attributs pourraient former la clé.
Quand plusieurs attributs sont nécessaires, il faut en prendre le plus petit nombre possible. Il peut parfois être nécessaire de prendre comme clé tous les attributs de l’entité. Si le nombre d’attributs formant la clé est trop grand (généralement plus grand que 4), il peut être préférable de créer un attribut qui servira de clé (par exemple le no. de catalogue du téléviseur) Type d’attribut formant la clé La clé doit toujours être constituée d’attributs dont les valeurs sont fixes et fiables, et non de valeurs transitoires. Par exemple, pour l’entité "vêtement", le prix pourrait changer pour un élément donné, alors il ne devrait pas faire partie de la clé. La marque, n’étant pas unique pour chaque élément, ne pourrait être la clé à elle seule, mais elle pourrait faire partie d’une clé composée de plusieurs attributs. Identification des clés dans l’exemple des vêtements VÊTEMENT Marque Taille Type Prix
Plusieurs vêtements de même marque peuvent exister Plusieurs vêtements de même taille peuvent exister Plusieurs vêtements de même type peuvent exister Prix est une valeur transitoire alors ne peut être dans la clé Aucune combinaison ne peut identifier un vêtement de façon unique, deux mêmes vêtements pouvant avoir la même marque, la même taille et le même type en même temps Il faut donc ajouter un attribut servant à identifier un vêtement de façon unique. Cet attribut sera le numéro de vêtement. La même chose se produit pour les entités "tissu" et "bouton". Aucune combinaison d’attributs ne pouvant les identifier uniquement, il faudra créer un nouvel attribut pour chaque entité. Celuici pourra être le numéro de série s’il en existe un, ou bien un numéro ou identificateur unique qui sera créé pour chacun des éléments de chaque entité. L’ajout des clés donnera donc le modèle suivant : VÊTEMENT oVêtement* Marque Taille Type Prix BOUTON TISSU oBouton* oTissu* Couleur Couleur Type Matériel
Les clés sont identifiées par un astérisque. Par un numéro de vêtement donné, on retrouve une seule marque, une seule taille, un seul type et un seul prix. Même chose pour les entités "bouton" et "tissu". Clés candidates et clés primaires Il arrive que plusieurs attributs d’une même entité peuvent servir à identifier de façon unique un enregistrement. Ils sont alors appelés "clés candidates". Il faut alors choisir la clé candidate qui correspond le mieux au contexte, qui deviendra alors la "clé primaire". Par exemple, dans le dossier d’une personne, le numéro d’assurance sociale et le numéro d’assurance maladie constitueraient des clés candidates. Pour une B.D. d’hôpital on choisirait le numéro d’assurance maladie, alors que pour une B.D. gouvernementale ou une B.D. d’employés d’une entreprise on choisirait le numéro d’assurance sociale. Les types de relation logique entre deux entités Relation : lien logique existant entre deux ou plusieurs entités On retrouve 3 types de relations entre les entités : 1. Relation 1:1 Pour une occurrence de l’entité x on ne retrouve qu’une et une seule occurrence associée de l’entité y et viceversa. Exemple : Dans un mariage chrétien, un époux est associé à une seule épouse et viceversa 2. Relation 1:n Pour une occurrence de l’entité x on retrouve plusieurs occurrences associées de l’entité y, mais pour une occurrence de l’entité y on ne retrouve qu’une seule occurrence associée de l’entité x. Exemple : À un père peut être associé plusieurs enfants, mais un enfant ne peut être associé qu’à un seul père. 3. Relation n:n Pour une occurrence de l’entité x on retrouve plusieurs occurrences de l’entité y et viceversa. Exemple : Un étudiant peut être inscrit à plusieurs cours, et un cours peut être suivi par plusieurs étudiants. Exemple : Le relations hommesfemmes Type conventionnel HOMME FEMME Type amazone HOMME FEMME Type arabe HOMME FEMME Type commun HOMME FEMME
Les dépendances fonctionnelles Une dépendance fonctionnelle (DF) est une relation entre deux attributs ou entre deux entités s’exprimant par la phrase "un et un seul"(Relation 1:1). Par exemple, avec un numéro d’assurance sociale, on trouve un et un seul nom. Il y a donc une dépendance fonctionnelle entre le numéro d’assurance sociale et le nom d’une personne. Il peut également exister une dépendance fonctionnelle entre deux entités. Par exemple, supposons que dans la fabrication de vêtements il est prévu qu’une seule étiquette soit posée sur chaque vêtement produit. VÊTEMENT ÉTIQUETTE oVêtement* oÉtiquette* Marque CodeLavage Taille CodeSéchage Type CodeRepassage Prix Il y aurait une dépendance fonctionnelle entre « Vêtement » et « Étiquette ». Un vêtement contient une et une seule étiquette. On exprime une dépendance fonctionnelle par une flèche : VêtementÉtiquette Les DF (Dépendances Fonctionnelles) entre deux attributs d’une même entité sont desdépendances fonctionnelles interneset les DF entre deux entités sont desdépendances fonctionnelles externes. La nature de la relation entre deux entités dépend entre autres du caractère générique ou spécifique des entités impliquées Entité générique et entité spécifique Une entité générique contient des catégories ou des modèles o Une entité spécifique contient des objets réels o Par exemple, l’entité "Bouton" pourrait représenter une sorte de bouton (entité générique). Chaque bouton sortant de la même boîte serait donc représentés par la même occurrence de l’entité et identifié par le même numéro de bouton. Dans un autre cas, le bouton pourrait représenter un bouton réel précis (entité spécifique). Dans ce cas, chaque bouton (sortant de la même boîte ou non), serait représenté par une occurrence différente de l’entité "bouton" et portant un numéro différent. Si l’entité "bouton" était spécifique, il y aurait une DF entre les entités "bouton" et "vêtement" (un bouton n’est posé que sur un seul vêtement). Par contre, si elle était générique, la relation serait un lien multiple (1:n) et non une dépendance fonctionnelle (une sorte de bouton peut être posée sur plusieurs vêtements différents). Dans un modèle entitérelations, on distinguera les entités spécifiques en écrivant leur nom en o caractères droits, et les entités génériques en caractère italiques. Des DF existent dans les relations de type "1:1", "1:n" et "n:1"(relation équivalente à "1:n" mais vue dans le sens inverse). Dans le premier cas, il y a deux DF, une dans chaque sens. Dans les deux autres cas, on retrouve une DF dans un sens et un lien multiple dans l’autre sens. Dans une relation "n:n", il n’y a aucune DF mais deux relations multiples(1:n), une dans chaque sens. Il ne faut donc pas oublier que dans l’analyse des relations entre attributs et entre entités, le sens dans lequel on évalue la relation est important. La relation dans un sens peut être la même que dans l’autre, mais elle peut tout aussi bien être différente.
Dans l’exemple de la boutique de vêtements, pour chaque entité, toutes les relations entre la clé et un attribut sont des DF internes. Dans la prochaine section nous analyserons les relations entre les entités pour ce même exemple. Ajustements au modèle Après une première ébauche du modèle, une analyse des DF permettra d’apporter les ajustements nécessaires à l’obtention d’un modèle adéquat et transposable en modèle relationnel Cette étape permettra de transformer les relations entre les entités en dépendances fonctionnelles simples (illustrées sous forme de flèches unidirectionnelle). En d’autre mots, on cherchera ici à transformer toutes les relations interentités en relations "1:n". Deux cas peuvent se présenter dans le modèle 1. Certains attributs appelés orphelins ne sont pas déterminés par une dépendance fonctionnelle et ne sont pas des clés. Supposons que nous voudrions conserver le nombre de boutons posés sur un vêtement. BOUTON oBouton* Couleur Type QtéPosée L’attribut QtéPosée n’a pas vraiment sa place dans l’entité "Bouton" ni dans l’entité "Vêtement". Une sorte de boutons pourra être présente en nombre différent sur différents types de vêtements et un même vêtement peut contenir différents types de boutons. Il n’y a donc pas de dépendance fonctionnelle entre NoBouton et QtéPosée, ni entre NoVêtement et QtéPosée. Cet attribut est donc orphelin. Nous verrons un peu plus loin comment cette situation sera réglée. 2. Des relations autres que des DF existent entre deux entités Entre deux entités, trois situations peuvent se produire 1. Dépendance fonctionnelle simple (relation 1:n), notée "Entité1!Entité2" Il faut dupliquer la clé de l’entité 2 dans l’entité 1. La clé ainsi ajoutée devient une clé étrangère pour l’entité 1 (symbolisée par #) VÊTEMENT ÉTIQUETTE oVêtement* oÉtiquette* oÉtiquette# CodeLavage Marque CodeSéchage Taille CodeRepassage Type Prix
2.
Deux dépendances fonctionnelles entre les deux entités (relation 1:1) Il faut fusionner les deux entités en une seule
Supposons que l’entité étiquette représentait une étiquette spécifique et non une catégorie d’étiquette, nous aurions la dépendance fonctionnelle double suivante :
VÊTEMENT oVêtement* Marque Taille Type Prix
ÉTIQUETTE oÉtiquette* CodeLavage CodeSéchage CodeRepassage
Nous fusionnerions donc les deux entités en une seule, l’entité principale absorbant la partie :
3.
VÊTEMENT oVêtement* Marque Taille Type Prix oÉtiquette CodeLavage CodeSéchage CodeRepassage
Aucune dépendance fonctionnelle entre les deux entités (relation n:n) Il faut créer une entité intermédiaire entre les deux entités de sorte que les relations reliant cette nouvelle entité avec les deux entités originales soient des DF. L’entité crée contiendra les clés des deux entités d’origine. On peut inclure certains attributs dans la nouvelle entité créée.
Entre les entités "Bouton"(générique) et "Vêtement"(spécifique), il n’y a aucune dépendance fonctionnelle. Un vêtement peut contenir plusieurs sortes de boutons et une même sorte de bouton peut être présente sur plusieurs vêtements différents. Nous avons donc une relation (n:n).
BOUTON oBouton* Couleur Type QtéPosée
VÊTEMENT oVêtement* Marque Taille Type Prix
Il faudra donc créer une entité intermédiaire afin de décomposer cette relation "n:n" en deux relations "1:n" et donner à cette entité un nom pertinent, qui sera ici "BoutonPosé". La clé de cette nouvelle entité créée sera l’union entre les clés des deux entités d’origine. L’attribut orphelin "QtéPosée" aura d’ailleurs maintenant sa place dans cette nouvelle entité.
BOUTON oBouton* Couleur Type
BOUTONPOSÉ oBouton* oVêtement* QtéPosée
VÊTEMENT oVêtement* Marque Taille Type Prix
Les deux relations nouvellement créées seront des DF reliant ces trois entités. En effet, il pourra y avoir plusieurs poses de boutons pour un même vêtement et une sorte de bouton pourra faire partie de plusieurs poses sur différents vêtements, mais il ne pourra y avoir qu’une seule pose d’une même sorte de bouton sur un vêtement spécifique. Notons aussi que pour chaque pose de boutons sur un vêtement, il ne pourra y avoir qu’une seule quantité de boutons posés alors il y a une DF interne entre la clé de la nouvelle entité et l’attribut "QtéPosée".
La même situation sera rencontrée entre les entités "Vêtement" et "Tissu". Il n’y a aucune dépendance fonctionnelle entre ces deux entités. Il faudra donc créer une entité intermédiaire. On pourrait également y ajouter un attribut afin de connaître la quantité de chaque sorte de tissu nécessaire à la fabrication d’un vêtement.
VÊTEMENT oVê ement* Marque Taille Type Prix
TISSUPOSÉ oTissu* oVêtement* TailleUtilisée
TISSU oTissu* Couleur Matériel
Finalement, après tous les ajustements qui ont été effectués au modèle initial, nous obtenons comme résultat le modèle suivant : VÊTEMENT BOUTONPOSÉ TISSUPOSÉ oVêtement* oBouton* oTissu* oÉtiquette# oVêtement* oVêtement* Marque QtéPosée TailleUtilisée Taille Type Prix
BOUTON oBouton* Couleur Type
ÉTIQUETTE oÉ iquette* CodeLavage CodeSéchage CodeRepassage
TISSU oTissu* Couleur Matériel
Le dictionnaire de données Après avoir terminé le schéma du modèle de données, il faut construire le dictionnaire de données La dictionnaire de données est la liste de chacun des attributs présents dans le schéma et des caractéristiques de ces attributs. Le dictionnaire de données comprend les informations suivantes 1. Le nom des attributs 2. Le type des attributs "Texte "Numérique "Date "Monnaie 3. Une description sommaire des attributs 4. Un exemple de valeur que peut prendre l’attribut Utile dans la phase d’implémentation Documentation utile pour les personnes qui seront impliquées dans la conception et la construction de la base et pour ceux qui effectueront les applications accédant à la B.D. 2 points à noter 1. Le type numérique, qui représente des nombres, ne devrait idéalement être utilisé que dans le cas où des calculs pourraient être effectuées sur les données de cet attribut. Pour les nombres sur lesquels aucun calcul ne sera effectué, il est préférable d’utiliser le type texte. 2. Les clés devraient préférablement être de type texte Pour notre exemple de vêtements, nous aurions le dictionnaire de données suivant : Attribut Type Description Exemple NoVêtement Texte Identificateur de vêtement 12R35 Marque Texte Marque du vêtement Lois Taille Texte Taille du vêtement 33 Type Texte Catégorie du vêtement Chandail Prix Monnaie Prix de l’article 59.99 NoBouton Texte No. de stock du modèle 223420 QtéPosée Numérique Nombre de boutons posés 5 Couleur Texte Couleur du bouton Bleu Type Texte Décoratif, Utilitaire Utilitaire NoÉtiquette Texte Identificateur de type d’étiquette 11254 CodeLavage Texte Machine, Main, Sec Machine CodeSéchage Texte Machine, Suspension, plat Suspension CodeRepassage Texte Oui, Non Non NoTissu Texte Identificateur de stock du tissu 1154M87 TailleUtilisée Numérique Surface de tissu utilisée en cm carrés 55.7 Couleur Texte Couleur du tissu Rouge Matériel Texte Type de matériel constituant le tissu Coton
Transposition au modèle relationnel Les entités deviennent des tables Les attributs deviennent des champs Les clés sont soulignées VÊTEMENT(NoVêtement, NoÉtiquette, Marque, Taille, Type, Prix)BOUTONPOSÉ (NoBouton, NoVêtement, QtéPosée) BOUTON (NoBouton, Couleur, Type) TISSUPOSÉ (NoTissu, NoVêtement, TailleUtilisée) TISSU (NoTissu, Couleur, Matériel) ÉTIQUETTE (NoÉtiquette, CodeLavage, CodeSéchage, CodeRepassage) Le modèle relationnel résultant de cette transposition ne sera pas nécessairement optimal Pour éviter les anomalies dans une B.D. relationnelle, il faudra la normaliser, ce qui sera vu au prochain chapitre
