Cours 4

Description

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 ...

Informations

• Publié par: Fewyar
• Nombre de lectures: 36
• Langue: Français

Extrait

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 cihaut. 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é. Celuici 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 viceversa. Exemple : Dans un mariage chrétien, un époux est associé à une seule épouse et viceversa 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 viceversa. Exemple : Un étudiant peut être inscrit à plusieurs cours, et un cours peut être suivi par plusieurs étudiants. Exemple : Le relations hommesfemmes
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 interentité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 223420 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 1154M87 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