Base de données (suite)
II) Modélisation
1) Généralités
Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Une ou plusieurs modélisations intermédiaires sont donc utiles, le modèle entités-associations constitue l'une des premières et des plus courantes. Ce modèle permet une description naturelle du monde réel à partir des concepts d'entité et d'association1. Basé sur la théorie des ensembles et des relations, ce modèle se veut universel et répond à l'objectif d'indépendance données-programmes. On s'en sert pour la phase de conception.
Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Une ou plusieurs modélisations intermédiaires sont donc utiles, le modèle entités-associations constitue l'une des premières et des plus courantes. Ce modèle permet une description naturelle du monde réel à partir des concepts d'entité et d'association1. Basé sur la théorie des ensembles et des relations, ce modèle se veut universel et répond à l'objectif d'indépendance données-programmes. On s'en sert pour la phase de conception.
Les données représentent la statique du système d'information et les traitements sa dynamique. L'expression conceptuelle des données conduit à une modélisation des données en entités et en associations. Dans ce cours, nous écartons volontairement la modélisation des traitements puisque nous ne nous intéressons à la méthode Merise que dans la perspective de la modélisation de bases de données.
1.1 Description
Avant de procéder à la création de la base de données, le professionnel responsable doit la concevoir, c'est-à-dire en établir la définition en fonction des besoins auxquels la base doit répondre. Cette étape comporte, entre autres, la modélisation des données qui seront gérées. La modélisation consiste à représenter le mieux possible des objets (concrets ou abstraits) du monde réel par des objets numériques stockés dans une base de données.
Avant de procéder à la création de la base de données, le professionnel responsable doit la concevoir, c'est-à-dire en établir la définition en fonction des besoins auxquels la base doit répondre. Cette étape comporte, entre autres, la modélisation des données qui seront gérées. La modélisation consiste à représenter le mieux possible des objets (concrets ou abstraits) du monde réel par des objets numériques stockés dans une base de données.
1.2 Architecture
Le travail du professionnel responsable de la base inclut donc, avant même la modélisation, le choix du modèle de données le mieux adapté à la situation. Pour faire un choix éclairé, le professionnel doit connaître très bien les différents modèles de données disponibles sur le marché, en particulier les modèles textuel et relationnel (un autre modèle important étant celui des documents structurés).
Le travail du professionnel responsable de la base inclut donc, avant même la modélisation, le choix du modèle de données le mieux adapté à la situation. Pour faire un choix éclairé, le professionnel doit connaître très bien les différents modèles de données disponibles sur le marché, en particulier les modèles textuel et relationnel (un autre modèle important étant celui des documents structurés).
2) Modèle Entité-Relation (modèle E-R)
2.1 Entité et Attribut
Le modèle E/A est un modèle conceptuel de haut niveau. Il est souvent utilisé comme modèle de données pivot de méthodes de conception . Il a été élaboré par Chen [Chen 1976]. Il s'agit d'une des premières tentatives pour intégrer au modèle de données plus de sémantique, afin de se rapprocher de la réalité considérée. De nombreuses variations et extensions ont été faites sur ce modèle. Aucun SGBD commercialisé ne l'implante (il s'agit d'un modèle dit de conception). Un handicap fort est qu'il n'y a pas de langage de manipulation associé (ou plutôt il y en a plusieurs, mais aucun ne s'étant imposé).
Le modèle E/A est un modèle conceptuel de haut niveau. Il est souvent utilisé comme modèle de données pivot de méthodes de conception . Il a été élaboré par Chen [Chen 1976]. Il s'agit d'une des premières tentatives pour intégrer au modèle de données plus de sémantique, afin de se rapprocher de la réalité considérée. De nombreuses variations et extensions ont été faites sur ce modèle. Aucun SGBD commercialisé ne l'implante (il s'agit d'un modèle dit de conception). Un handicap fort est qu'il n'y a pas de langage de manipulation associé (ou plutôt il y en a plusieurs, mais aucun ne s'étant imposé).
2.2 Entité
C'est un objet du monde réel avec une existence indépendante; chaque entité a des propriétés particulières ("attributs") qui la décrivent, et elle a des valeurs pour chacun de ses attributs.
C'est un objet du monde réel avec une existence indépendante; chaque entité a des propriétés particulières ("attributs") qui la décrivent, et elle a des valeurs pour chacun de ses attributs.
2.3 Attribut
un attribut peut être composé hiérarchiquement de plusieurs autres attributs (attribut composite par opposition à attribut simple ou atomique) . un attribut peut être monovalué ou multivalué et la valeur peut être dérivée d'une ou plusieurs autres valeurs d'attributs.
un attribut peut être composé hiérarchiquement de plusieurs autres attributs (attribut composite par opposition à attribut simple ou atomique) . un attribut peut être monovalué ou multivalué et la valeur peut être dérivée d'une ou plusieurs autres valeurs d'attributs.
2.4 Relation
Le modèle relationnel de données a été défini en 1970 par Codd et les premiers systèmes commerciaux sont apparus au début des années 80. Le modèle relationnel représente l'information dans une collection de relations. Intuitivement, on peut voir une relation comme une table à double entrée, voire même comme un fichier. Chaque ligne de la table (appelée nuplet ou tuple) peut être vue comme un fait décrivant une entité du monde. Une colonne de la table est appelée un attribut.
Le modèle relationnel de données a été défini en 1970 par Codd et les premiers systèmes commerciaux sont apparus au début des années 80. Le modèle relationnel représente l'information dans une collection de relations. Intuitivement, on peut voir une relation comme une table à double entrée, voire même comme un fichier. Chaque ligne de la table (appelée nuplet ou tuple) peut être vue comme un fait décrivant une entité du monde. Une colonne de la table est appelée un attribut.
3) Forme normale
3.1 Dépendances fonctionnelles
On dit qu'un attribut B dépend fonctionnellement d'un attribut A si, étant donné une valeur de A, il lui correspond une unique valeur de B (quel que soit l'instant t considéré).
On dit qu'un attribut B dépend fonctionnellement d'un attribut A si, étant donné une valeur de A, il lui correspond une unique valeur de B (quel que soit l'instant t considéré).
On peut juger de la justesse des shémas relationnels en regardant les deux niveaux suivants :
le niveau logique (ou conceptuel) à savoir la manière dont les utilisateurs interprètent les shémas relationnels et la signification des attributs.
Le niveau d'implémentation( ou de stockage) i.e comment les tuples d'une relation de base sont conservés et mis à jour.
Avant d'en arriver là, précisons que pour concevoir une base de données, on a le choix entre deux approches du mini-monde qu'on a décrire; soit on appréhende le problème par une conception ascendante (appelée également conception par synthèse)
le niveau logique (ou conceptuel) à savoir la manière dont les utilisateurs interprètent les shémas relationnels et la signification des attributs.
Le niveau d'implémentation( ou de stockage) i.e comment les tuples d'une relation de base sont conservés et mis à jour.
Avant d'en arriver là, précisons que pour concevoir une base de données, on a le choix entre deux approches du mini-monde qu'on a décrire; soit on appréhende le problème par une conception ascendante (appelée également conception par synthèse)
3.2 Normalisation des relations
(à venir)
(à venir)
3.3 les différentes formes normales
Les formes normales définissent un ordre partiel sur les schémas de relation. On peut donc voir une forme normale comme une classe d'équivalence (on peut comparer deux schémas dans deux classes d'équivalence différentes mais pas dans la même). Il faut aussi noter que le seul élément qui est pris en compte par les formes normales est la non redondance d'informations d'un schéma. Selon les formes normales un "bon" schéma est un schéma sans redondance (ce qui ne veut pas forcément dire qu'il est efficace par exemple). Un schéma relationnel sans qualité particulière est appelé schéma en 1ère forme normale (on note 1FN) et si on rajoute certaines qualités on obtient les deuxième et troisième formes normales (on note 2FN et 3FN).
Les formes normales définissent un ordre partiel sur les schémas de relation. On peut donc voir une forme normale comme une classe d'équivalence (on peut comparer deux schémas dans deux classes d'équivalence différentes mais pas dans la même). Il faut aussi noter que le seul élément qui est pris en compte par les formes normales est la non redondance d'informations d'un schéma. Selon les formes normales un "bon" schéma est un schéma sans redondance (ce qui ne veut pas forcément dire qu'il est efficace par exemple). Un schéma relationnel sans qualité particulière est appelé schéma en 1ère forme normale (on note 1FN) et si on rajoute certaines qualités on obtient les deuxième et troisième formes normales (on note 2FN et 3FN).
1FN : une relation est en première forme normale ssi tout attribut a une valeur atomique (vrai par définition du modèle relationnel)
2FN : une relation est en deuxième forme normale ssi elle est en 1FN et si tous les attributs non clés sont pleinement dépendants des clés (toutes les dépendance entre une clé et un attribut non clé sont élémentaires)
3FN : une relation est en troisième forme normale ssi elle est en 2FN et si tous les attributs non clés sont directement et pleinement dépendants des clés (si tout attribut non clé ne dépend pas d'un autre attribut non clé)
3FNBCK (Boyce-Codd-Kent) : une relation est en 3FNBCK ssi elle est en 3FN et si les seules DFE sont celles de la forme C -> X avec C clé (seules les clés sont en partie gauche de DF).
3.4 Exemples pratiques
(à venir)
(à venir)
4) Méthodologie de conception
4.1 Généralités
(à venir)
(à venir)
4.2 Processus de conception
4.3 UML dans la concetion des BD
(à venir)
(à venir)
