La conception d’une base de données logique implique trois phases :
- Phase d’analyse des besoins
- Phase de modélisation des données
- Phase de normalisation
Phase d’analyse des besoins
La phase d’analyse des besoins consiste à examiner l’entreprise modélisée, à interroger les utilisateurs et la direction pour évaluer le système actuel et à analyser les besoins futurs, et à déterminer les informations requises pour l’entreprise dans son ensemble. Ce processus est relativement simple.
Phase de modélisation des données
La phase de modélisation des données consiste à modéliser la structure de la base de données elle-même. Cela implique l’utilisation d’une méthode de modélisation des données qui fournit un moyen de représenter visuellement divers aspects de la structure de la base de données, tels que les tables, les relations entre les tables et les caractéristiques des relations.
Certaines des méthodes de modélisation de données courantes sont :
- Modélisation des relations d’entité (modélisation ER)
- Modélisation objet sémantique
- Modélisation des rôles d’objet
La méthode que vous utilisez ici est une version de base de la modélisation ER.
Modélisation ER
Un diagramme ER simple se présente comme suit :
Cette figure représente plusieurs aspects de la base de données. Premièrement, il transmet le fait qu’il y a deux tables dans cette base de données, l’une appelée Agents et l’autre appelée Clients ; chacun des tableaux est représenté par un rectangle. Le losange représente le fait qu’il existe une relation entre ces deux tables, et le “1:N” dans le losange indique que la relation est une relation un-à-plusieurs. Enfin, le diagramme traduit le fait qu’un client doit être associé à un agent (indiqué par la ligne verticale à côté de la table AGENTS), mais un agent ne doit pas nécessairement être associé à un client (comme indiqué par le cercle à côté de le tableau CLIENTS).
Un diagramme entité-relation (ER) est un graphique spécialisé qui illustre les interrelations entre les entités dans une base de données d’une modélisation de données logiques.
Symboles utilisés dans le diagramme ER
- La boîte représente l’entité
- Le diamant représente la relation
- L’ovale représente l’attribut
Activités clés dans la modélisation ER
Voici les principales activités impliquées dans la conception d’une base de données logique à l’aide du mode Entity-Relationship :
- Définir les entités
- Définir la clé primaire
- Définir les relations entre les entités
- Définir des attributs supplémentaires pour les entités
Définir les entités
- Vous commencez le modèle ER, en définissant les entités, les objets d’intérêt significatifs
- Les entités sont les éléments sur lesquels vous souhaitez stocker des informations.
Définir la clé primaire
- Une clé primaire est un identifiant unique pour une entité.
- Si une clé primaire est composée de plusieurs attributs, elle est appelée “clé composite”.
Définir les relations entre les entités
Une connexion établie entre une paire de tables est appelée une relation. Une relation existe lorsqu’une paire de tables est connectée par une clé primaire et une clé étrangère ou est liée par une troisième table, appelée table de liaison.
Les relations sont très importantes car elles aident à réduire les données redondantes et les données en double. Ils permettent également de définir des vues.
Chaque relation peut être caractérisée par le type de relation qui existe entre les tables, le type de participation de chaque table au sein de la relation et le degré de participation de chaque table au sein de la relation.
Types de relations (cardinalité) :
Lorsque deux tables sont liées, il existe toujours un type de relation spécifique (traditionnellement connu sous le nom de cardinalité) qui existe entre elles. Il existe trois types de relations possibles :
- Un par un
- relations un-à-plusieurs et plusieurs-à-un
- plusieurs à plusieurs
Relations individuelles (un-à-un) :
Une relation un-à-un existe entre une paire de tables si un seul enregistrement de la première table est lié à un seul enregistrement de la deuxième table et qu’un seul enregistrement de la deuxième table est lié à un seul enregistrement de la première table.
La figure suivante montre un exemple de relation un-à-un impliquant une table EMPLOYEES et une table SALAIRES. Dans cet exemple, un seul enregistrement de la table EMPLOYEES est lié à un seul enregistrement de la table SALAIRES; de même, un seul enregistrement de la table SALAIRES est lié à un seul enregistrement de la table EMPLOYEES.
Relations un-à-plusieurs :
Une relation un-à-plusieurs existe entre une paire de tables si un seul enregistrement de la première table peut être lié à un ou plusieurs enregistrements de la deuxième table, mais qu’un seul enregistrement de la deuxième table ne peut être lié qu’à un seul enregistrement dans le premier tableau.
Une relation un-à-plusieurs impliquant une table ETUDIANTS et une table MATIERES est illustrée dans la figure suivante. Dans ce cas, un seul enregistrement de la table ETUDIANTS peut être lié à un ou plusieurs enregistrements de la table MATIERES, mais un seul enregistrement de la table MATIERES est lié à un seul enregistrement de la table ETUDIANTS.
Relations plusieurs-à-un :
Une relation plusieurs-à-un existe entre une paire de tables si un seul enregistrement de la première table ne peut être lié qu’à un seul enregistrement de la seconde table, mais qu’un seul enregistrement de la seconde table peut être lié à un ou plusieurs enregistrements de le premier tableau.
Une relation plusieurs-à-un impliquant une table FILIERES et une table MATIERES est illustrée dans la figure suivante. Dans cet exemple, un seul enregistrement de la table FILIERES peut être lié à un seul enregistrement de la table MATIERES et un seul enregistrement de la table MATIERES peut être lié à un ou plusieurs enregistrements de la table FILIERES.
La figure suivante représente la relation plusieurs-à-un.
Relations plusieurs-à-plusieurs :
Une relation plusieurs-à-plusieurs existe entre une paire de tables si un seul enregistrement de la première table peut être lié à un ou plusieurs enregistrements de la deuxième table, et un seul enregistrement de la deuxième table peut être lié à un ou plusieurs enregistrements dans le premier tableau.
La figure suivante montre une relation classique de plusieurs à plusieurs. Dans cet exemple, un seul enregistrement de la table EMPLOYES peut être lié à un ou plusieurs enregistrements de la table REUNION ; de même, un seul enregistrement de la table REUNION peut être lié à un ou plusieurs enregistrements de la table EMPLOYES.
La figure suivante représente la relation plusieurs à plusieurs. Ici, une relation est établie entre deux tables à l’aide d’une table de liaison PLANNING.
Types de participation (facultatif):
Il existe deux types de participation qu’une table peut avoir dans une relation :
- Obligatoire
- Optionnel
Supposons qu’il existe une relation entre deux tables appelées TABLE A et TABLE B.
Si des enregistrements dans la TABLE A doivent exister avant que de nouveaux enregistrements puissent être saisis dans la TABLE B, la participation de la TABLE A au sein de la relation est obligatoire.
Cependant, s’il n’est pas nécessaire que des enregistrements dans la TABLE A existent pour entrer de nouveaux enregistrements dans la TABLE B, la participation de la TABLE A dans la relation est facultative.
Chaque table d’une relation peut participer d’une manière ou d’une autre. Le type de participation de chaque table au sein d’une relation est généralement déterminé par la manière dont les données de chaque table sont liées et la manière dont les données sont utilisées.
Examinez la relation entre les tables CONSEILLERS et CLIENTS dans la figure suivante. La table CONSEILLERS a une participation obligatoire dans la relation si des agents doivent exister avant qu’un nouveau client puisse être saisi dans la table CLIENTS. Mais la participation de la table CONSEILLERS est facultative s’il n’est pas nécessaire d’avoir des agents dans la table CONSEILLERS avant qu’un nouveau client puisse être saisi dans la table CLIENTS.
Le type de participation établi pour la table CONSEILLERS est déterminé par la manière dont ses données sont utilisées par rapport aux données de la table CLIENTS. Par exemple, s’il est nécessaire de s’assurer que chaque client se voit attribuer un agent disponible, la participation de la table CONSEILLERS dans la relation doit être obligatoire.
Représentation de la cardinalité et de l’option :
En général, les conventions suivantes sont utilisées pour représenter la cardinalité et l’optionalité,
Cardinalité :
- La notion de cardinalité s’exprime soit par “un” soit par “plusieurs”
- Une cardinalité « un » s’exprime par une « ligne droite » et une cardinalité « plusieurs » s’exprime à l’aide de « pattes d’oie ».
Facultatif :
- La notion d’optionnalité est exprimée soit comme “obligatoire” soit comme “facultative”
- Une option “Facultatif” est exprimée sous la forme d’un “cercle” et une option “Obligatoire” est exprimée sous la forme d’une “barre verticale”.
Exemple de diagramme ER :
Prenons l’exemple d’une base de données contenant des informations sur les habitants des villes. Le diagramme ER contient deux entités – Personne et Ville.
Facultatif
Une personne devrait vivre dans une ville. (C’est pourquoi une barre apparaît à côté de Ville venant de Personne). Une ville peut exister sans personne. (C’est pourquoi un cercle apparaît à côté de Personne dans la « Relation Ville – Personne »).
Définissez des attributs supplémentaires pour les entités :
La définition des attributs d’une entité comprend les activités suivantes.
- Définition du nom d’attribut.
- Définition du type de données pour les attributs.
- Définir les valeurs appropriées pour les attributs – quelles valeurs sont acceptables pour les différents attributs d’une table.