Cycle de conception des bases de données

Nous synthétisons les principales étapes ayant mené au consensus concernant le cycle de conception des BD en trois principales évolutions (figure 1.3) : une évolution verticale où les principales phases de modélisation (analyse des besoins, phase de modélisation conceptuelle, logique et physique) ont été ajoutées de manière évolutive au cycle de conception. Une deuxième évolution interne qui a permis de détailler les étapes à suivre pour chacune des phases du cycle. Une troisième évolution horizontale qui a permis d’enrichir chaque phase par l’apparition de nouveaux modèles de données. Nous présentons dans ce qui suit ces différentes évolutions.

1.2.1 Evolution verticale du cycle de conception

Les modèles de données ont été proposés afin de représenter la sémantique permettant ratta-cher à chaque information du monde perçu modélisé qui y est représentée, un sens. Les évolutions du cycle de conception des BD que nous présentons sont principalement liées aux différentes pro-positions des modèles de données.

1.2.1.1 Les modèles physiques

Après l’apparition de la technologie des BD dans les années 60 comme successeurs aux sys-tèmes de fichiers, certains modèles de données ont été proposés pour gérer les données au sein d’un système de gestion de base de données (SGBD). Le principal objectif des SGBD est d’assu-rer une indépendance (la plus grande possible) entre les données d’une part et les programmes qui exploitent la BD d’autre part afin de gagner en souplesse.

Deux principaux modèles ont connu un certain succès et ont été utilisés dans des systèmes industriels : le modèle hiérarchique utilisé dans le système IBM IMS développé en 1968, et le

1.2. Cycle de conception des bases de données

Figure1.2 – Cycle de conception d’une BD

modèle réseau proposé par le groupe de travail DBTG (Data Base Task Group) du CODASYL (COnference on DAta SYstems Languages) en 1969 dans sa première version [49]. Ces systèmes ont été développés à la fin des années 60, leurs deux modèles de données ont été définis par la suite, par abstraction des modèles implémentés dans ces systèmes [49]. Le concept de "modèle de donnée" a émergé avec l’apparition de ces modèles, même si le terme modèle de données a été introduit et défini plus tard par Edgar Codd pour son modèle de données relationnel.

Le premier modèle hiérarchique (figure 1.4) consiste à stocker les données dans des enregistre-ments comportant un ensemble de champs ayant chacun un type de données. Les enregistreenregistre-ments sont organisés sous forme d’un arbre tel que chaque nœud (enregistrement) possède un seul pa-rent. Chaque arbre comprend une racine et des branches qui permettent l’accès aux différents niveaux de données. Le niveau d’une donnée mesure sa distance à la racine. La racine est si-tuée au niveau supérieur. Les autres données se situent au niveau des nœuds de l’arbre (on parle de parents et d’enfants). Les relations entre les enregistrements d’un niveau et du niveau immédiatement inférieur sont de type un à plusieurs (1,n).

Les SGBD hiérarchiques les plus utilisés sur le marché étaient ceux des systèmes IMS et SYSTEM-2000. Leurs BD consistaient alors en un ensemble d’instances de ces enregistrements hiérarchiques. Ce modèle en arbre possède deux principaux inconvénients [85] : (1) la redon-dance de l’information pouvant engendrer des inconsistances entre les données. (2) l’existence des données d’un enregistrement repose sur celle de son enregistrement parent.

Le modèle de données réseau (ou codasyl) a été proposé en 1969, suivi d’une autre version en 1973 complétant le modèle par une spécification d’un langage de manipulation des données. Le modèle réseau a servi de base pour la plupart des systèmes commerciaux au cours des années 1970 [76]. Le modèle réseau (figure 1.5) stocke les données dans une collection d’enregistrements organisés, non pas dans un arbre, mais dans un réseau (ou graphe) dont les nœuds sont les enregistrements. Ce modèle permet ainsi à une instance d’un enregistrement d’avoir plusieurs parents et non plus un parent unique. Le langage de manipulation des données Codasyl est

Figure 1.3 – Types d’évolution du cycle de conception des BD : horizontale, verticale, interne

un langage procédural permettant de récupérer et de manipuler un seul enregistrement à la fois. L’utilisateur accède à une donnée par un point d’entrée et navigue à travers le réseau à l’enregistrement contenant la donnée. Le modèle réseau est une évolution logique du modèle hiérarchique. Il offre une meilleure représentation des données et davantage de flexibilité que le modèle hiérarchique. Par rapport à ce dernier, le modèle réseau a permis l’élimination des redondances de données et la création de chemins d’accès multiples à une même donnée. Il a d’ailleurs valu à son auteur Charles Bachman d’avoir le prix ACM Turing en 1973. Cependant, ce modèle ne permet pas la prise en compte réelle de phénomènes plus complexes et ne résout pas tous les problèmes d’indépendance des structures de données et des traitements.

Figure 1.4 – Exemple d’une représentation hiérarchique

Ses principaux inconvénients sont les suivants :

– La difficulté d’installation et de gestion du système à cause du temps nécessaire pour l’organisation des données dans les deux niveaux (physique et logique) avant l’activation de la base.

– La difficulté de maintenance et d’évolution de la BD et des programmes.

– La difficulté d’accès aux données où les programmeurs étaient obligés de naviguer le long de chemins d’accès pour atteindre une donnée cible.

– La redondance des données qui nécessitait une révision simultanée de tous les programmes utilisant une structure ayant subi une modification [50].

1.2. Cycle de conception des bases de données

Figure 1.5 – Exemple d’une représentation en réseau

Les deux modèles hiérarchique et réseau comportent un inconvénient commun et majeur qui est la faible indépendance physique et logique des données. Ceci nécessitait de prévoir toutes les données et opérations nécessaires avant la conception de la BD, afin d’éviter de recoder d’éven-tuels changements ou mises à jour. Les modèles proposés étaient certes efficaces pour les requêtes et les opérations initiales pour lesquelles la BD a été conçue. Ils ne fournissaient cependant pas suffisamment de souplesse pour accéder aux enregistrements efficacement lorsque de nouvelles requêtes et transactions étaient identifiées. Ces transactions étaient souvent coûteuses en temps et en argent, car les programmes devaient être réécrits, testés et débogués [55].

1.2.1.2 Le modèle relationnel

L’indépendance physique des données était une nécessité car une application de BD n’est jamais écrite dès le premier jet, mais nécessite plusieurs mises à jour. Le modèle qui suivit ces deux premiers modèles, a été proposé avec pour principal objectif d’offrir une séparation entre les deux niveaux d’abstraction des données : le niveau logique et le niveau physique [85]. C’est ainsi qu’Edgar Codd a proposé en 1970 le modèle relationnel [48], présentant une abstraction mathématique de ce qui est implémenté dans la base. Le modèle relationnel propose de stocker les données dans un modèle organisé en des structures simples et flexibles (des tables) pouvant représenter tout type d’information. La gestion des données dans le modèle relationnel se fait par leur valeur et non par leur position souvent difficile à maintenir (comme dans le modèle réseau). Le modèle relationnel offre un accès aux données par un langage de manipulation permettant aux utilisateurs d’exprimer des opérations sur des blocs ou ensembles d’information à la fois (ex-ploitant les concepts de la théorie des ensembles). Ce modèle présente de plus une représentation formelle et rigoureuse, basée sur l’algèbre relationnelle, pour l’organisation et la gestion de la BD. Edgar Codd définit ensuite son modèle de données par trois composantes [50]. Cette définition a été retenue pour les autres types de modèle de données :

– Partie structurelle : représente la collection de types de structures de données. La partie structurelle dans le modèle relationnel est représentée par les domaines, relations, attributs, tuples, clés candidates et primaires.

– Partie manipulation : collection d’opérateurs et de règles d’inférence qui peuvent être appliqués sur des instances valides de la BD pour leur restitution, leur modification ou leur gestion. La partie manipulation dans le modèle relationnel est représentée par les opérateurs algébriques (select, project, join, etc) qui transforment des relations en d’autres

reprochaient au modèle relationnel son aspect formel difficilement compréhensible par les utilisa-teurs et programmeurs. Les pro-relationnel reprochaient au modèle Codasyl sa complexité et son manque de flexibilité pour la représentation de scénarios du monde réel, la difficulté d’optimiser les programmes et la faible indépendance des données. Durant ces années 70, la communauté de recherche travailla activement sur la proposition de prototypes de SGBD relationnels. Des études ont montré la supériorité des performances des BD relationnelles comparées à celles des BD orientées enregistrements [76]. Ces études ont servi de base pour le développement de SGBD relationnels menés par d’importants projets industriels comme le projet SystemR (initié par le groupe de recherche d’IBM ), le projet Ingres (initié par l’université de Berkeley) et le projet Gamma [76]. Ces projets ont été les précurseurs de plusieurs champs de recherches du domaine de BD et de plusieurs contributions comme le développement des langages de requêtes, la propo-sition des propriétés ACID (acronyme pour Atomicité, Consistance, Isolation et Durabilité) pour les transactions de BD, l’optimisation des requêtes ou l’indépendance des données et les vues [76, 8]. Le débat entre les pro-Codasyl et les pro-relationnel prit fin en 1984 lorsqu’IBM, grand détenteur du marché des SGBD, annonça l’apparition de son prochain SGBD DB2 (successeur de l’IMS) développé selon le modèle relationnel. Le langage SQL (structured Query Language) a été adopté comme langage standard d’interrogation et de manipulation du modèle relationnel [85].

1.2.1.3 Méthodologie unifiée pour la conception BD

Malgré l’engouement suscité par le modèle relationnel, les éditeurs de logiciels et les utilisa-teurs en entreprises ont constaté que les modèles existants ne répondaient pas suffisamment à leurs attentes. Les éditeurs logiciels réclamaient urgemment des modèles de données incorporant davantage de sémantique et la possibilité d’intégrer des fichiers de formats variés dans leurs BD. Les utilisateurs en entreprise souhaitaient avoir des modèles de données pouvant exprimer toute la sémantique représentée par les règles de gestion de leur entreprise, et souhaitaient avant tout, avoir une méthodologie unifiée pour la conception de leurs BD [45]. C’est dans ce contexte que Peter Chen proposa en 1976 [46] son modèle entités/associations (E/A). Ce modèle a, comme le relationnel, un fondement mathématique car il est basé sur la théorie des ensembles et les relations mathématiques. Il a de plus l’avantage de présenter un modèle plus proche et plus compréhensible par l’utilisateur (figure 1.6). D’un point de vue formalisation mathématique, une principale différence est remarquée entre le modèle relationnel et le modèle E/A : le modèle

1.2. Cycle de conception des bases de données

Figure 1.6 – Un exemple de diagramme entités/associations

relationnel utilise le constructeur de relation mathématique (produit cartésien) pour décrire la structure de valeurs de données. Une table est ainsi définie comme un produit cartésien des do-maines de ses attributs. Le modèle E/A par contre, utilise le même constructeur pour décrire la structure des entités. Dans le modèle E/A, une relation est le produit cartésien des entités [45]. On remarque bien que le modèle E/A apporte un autre niveau d’abstraction car il traite les en-tités du mode réel et ne considère pas seulement les valeurs de données. Le modèle E/A apporte de plus, davantage de sémantique que le modèle relationnel comme par exemple la représenta-tion des cardinalités dans le modèle E/A, et aussi le lien entre les entités qui est explicitement représenté dans le modèle E/A mais qui est implicite dans le modèle relationnel [45].

Malgré ces avantages, le modèle E/A n’a pas été un modèle de données implémenté dans un SGBD probablement selon [85] parce qu’il n’a pas été accompagné d’un langage de requêtes ou parce qu’il a été dépassé par le succès du relationnel. Le modèle E/A a cependant rapidement trouvé échos dans la communauté de conception des BD marquant une nouvelle évolution par l’introduction d’un niveau d’abstraction plus élevé que le niveau physique et logique, qui est le niveau conceptuel. Peter chen proposa dans ces articles une méthodologie pour construire un schéma initial E/A. Le modèle E/A est devenu très populaire dans les outils de conception de BD dans lesquels la traduction du schéma E/A en une collection de tables en troisième forme normale a été automatisée. Divers exemples d’outils ont été proposés comme Silverrun, ERwin et ER/Studio. Plusieurs grandes conférences ont été organisées autour du thème de la modélisation conceptuelle comme la conférence ER dont la première édition a été organisée en 1979. Ce thème de la modélisation conceptuelle a été porté par l’apparition d’autres modèles dits "sémantiques" qui se voulaient plus expressifs et comportant davantage de sémantique que le modèle relationnel. Les modèles les plus marquants de cette famille sont les modèles proposés par Smith et al. [182] et aussi Hammer et McLeod [82]. Les modèles objets ont suivi, basés sur les concepts du modèle E/A [45] pour apporter des aspects dynamiques aux modèles statiques existants.

1.2.1.4 Bilan 1 : évolution verticale des modèles de données

Comme premier bilan, nous remarquons que les modèles de données peuvent être représentés en trois grandes familles de modèles. Leur développement a marqué d’importantes évolutions dans le domaine des BD. La première famille de modèles comporte les modèles orientés enregis-trement (hiérarchique et codasyl). Le modèle relationnel a apporté une indépendance physique des données ainsi qu’une puissance de calcul en introduisant des opérations pouvant s’effectuer sur des ensembles de données. Les modèles conceptuels et sémantiques, ensuite les modèles objets ont assuré une indépendance logique des données tout en apportant des modèles plus flexibles et plus expressifs. La flexibilité permet au modèle de faire face aux scénarios du monde réel. L’expressivité désigne la manière dont le modèle peut être en mesure de mettre en évidence les

Figure 1.7 – Evolution verticale du cycle de conception des BD

différentes abstractions et les relations d’un scénario donné [142].

L’évolution de ces modèles de données que nous appelons évolution "verticale" (figure 1.7), a été unifiée dans l’architecture ANSI/SPARC [195] qui est actuellement universellement admise dans la communauté des BD. Cette architecture distingue les trois niveaux d’abstraction : le niveau conceptuel, externe et interne (figure 1.8) :

– Le niveau conceptuel, où la connaissance du domaine est formalisée dans un formalisme de modélisation conceptuel (E/A, modèle sémantique ou autre).

– Au-dessus, les modèles externes ou les vues utilisateurs qui permettent d’adapter les don-nées fournies aux besoins des différentes catégories d’utilisateurs.

– En dessous, le modèle interne présente une spécification des données telle qu’elle sera implémentée dans le système de BD.

L’architecture ANSI/SPARC permet d’assurer l’indépendance logique et physique des don-nées, i.e la capacité de modifier le modèle à un niveau de la BD sans avoir à modifier le modèle au niveau supérieur [55]. L’indépendance logique des données signifie la capacité de modifier le schéma conceptuel de la BD sans avoir à modifier ses schémas externes ou ses programmes d’applications. L’indépendance physique des données garantit la capacité de modifier le schéma interne de la BD (exp. Création de nouvelles structures d’accès ou réorganisation des fichiers de la BD) sans avoir à modifier ni son schéma conceptuel, ni les schémas externes.

1.2.2 L’évolution interne du cycle de conception

Se basant sur les niveaux de l’architecture ANSI/SPARC, un cycle de conception des BD a été défini, comprenant cinq principales étapes [142] : la définition des besoins, la phase de modélisation conceptuelle, la phase de modélisation logique, la phase de modélisation physique et la phase d’implémentation et de tuning. Ces étapes correspondent aux niveaux de l’architecture ANSI/SPARC de la manière suivante : le niveau externe et le niveau conceptuel traduisent les

1.2. Cycle de conception des bases de données

Figure 1.8 – L’architecture ANSI/SPARC

phases de modélisation conceptuelle et logique et le niveau interne correspond à la phase de modélisation physique [142, 55]. Les phases de ce cycle de conception ont été détaillées par la spécification des étapes de chaque phase (figure 1.9).

Figure 1.9 – Evolution interne du cycle de conception des BD

1.2.2.1 La définition des besoins

Le domaine relatif à la définition des besoins des utilisateurs est le domaine de l’ingénierie des besoins (IB). Rolland [159] définit l’lB comme suit : "l’ingénierie de besoins est concernée

certaines tâches préliminaires comme : l’identification de la portée de l’application de BD ainsi que de l’ensemble des ses utilisateurs, l’étude de l’environnement du système incluant l’analyse des types de traitements et de leur fréquence, l’analyse des flux d’informations du système, des entrées et sorties des traitements, des caractéristiques géographiques des utilisateurs, l’étude et l’analyse de la documentation existante relative à l’application de la BD et l’établissement des questionnaires destinés aux utilisateurs. La phase de définition des besoins comprend les quatre étapes suivantes [183] :

– La collecte des besoins : les besoins sont collectés auprès des utilisateurs finaux ou des clients du système. Plusieurs techniques de collecte des besoins peuvent être utilisées comme les interviews, les réunions ou les workshops.

– La spécification des besoins : consiste à formaliser les besoins et à identifier leurs caractéris-tiques attendues. L’étape de collecte des besoins fournit généralement un premier ensemble de besoins informels, inconsistants ou incomplets. Trois principales techniques de spécifi-cation des besoins sont utilisées pour spécifier les besoins collectés d’une manière plus structurée [123] :

1. Les techniques informelles : sont construites en langue naturelle avec ou sans règles de structuration. Leur usage introduit des risques d’ambiguïtés car ni leur syntaxe ni leur sémantique ne sont parfaitement définies. Parmi ces techniques, nous citons : le questionnaire et le cahier des charges.

2. Les techniques semi-formelles : sont généralement basées sur des notations graphiques qui ont une syntaxe précise et permettent d’avoir une vision claire du système. Ces modèles sont de bons vecteurs de communication entre les concepteurs et les utilisa-teurs du système. Parmi ces techniques, nous citons les modèles de la méthodeMerise et les modèles UML (comme les cas d’utilisations ou les diagrammes de séquence pour spécifier les besoins relatifs aux traitements).

3. Les techniques formelles : sont basées sur des notations mathématiques qui fournissent un cadre précis et non ambigu pour la modélisation des besoins. Nous pouvons citer la spécification des méthodes B et EB3 (Entity-Based Black-Box).

– La validation des besoins : consiste à valider le modèle obtenu lors de l’étape de spécification des besoins par les experts du domaine et les utilisateurs. Cette phase permet d’éviter la propagation des erreurs ou inconsistances des besoins durant les étapes de conception et d’implémentation de la base, qui peuvent s’avérer très coûteuses à corriger par la suite. Des

1.2. Cycle de conception des bases de données

outils et langages peuvent être utilisés pour faciliter les tâches de validation des besoins. Des langages formels comme le langage OCL ou le langage Z sont utilisés pour compléter la spécification des besoins afin de vérifier leur consistance [55].

– La gestion des besoins : inclut toutes les activités permettant d’établir et de maintenir l’intégrité des besoins pendant que l’application de BD évolue. Quelques outils de traçabilité sont disponibles pour vérifier la traçabilité des besoins dans le cas où ces derniers évoluent très fréquemment.

1.2.2.2 La modélisation conceptuelle

Cette phase prend comme entrée la spécification des besoins collectés auprès des utilisateurs du système. Cette phase est assurée par les analystes et concepteurs du système. Elle comprend deux principales étapes menées en parallèle : la conception du modèle conceptuel et la conception de l’application et des transactions [55].

– La conception du modèle conceptuel : cette étape consiste à élaborer le modèle conceptuel