Principales étapes de conception de la base de données

2.1. Design conceptuel

La conception de la base de données s'effectue en trois étapes :

1. design conceptuel;
2. conception logique ;
3. conception physique.

L'objectif de la phase de conception conceptuelle est de créer un modèle de données conceptuel basé sur les idées des utilisateurs sur le domaine. Pour y parvenir, une série de procédures séquentielles sont effectuées. Un exemple de schéma d'entité (conceptuel) :

1. Définition des entités et leur documentation. Pour identifier les entités, des objets sont définis qui existent indépendamment des autres. De tels objets sont des entités. Chaque entité reçoit un nom significatif que les utilisateurs peuvent comprendre. Les noms et les descriptions des entités sont entrés dans le dictionnaire de données. Si possible, le nombre attendu d'instances de chaque entité est défini.

2. Détermination des relations entre les entités et leur documentation. Seules les relations entre les entités sont définies qui sont nécessaires pour satisfaire aux exigences de conception de la base de données. Le type de chacun est défini. La classe d'appartenance des entités est révélée. Les liens reçoivent des noms significatifs exprimés par des verbes. Une description détaillée de chaque connexion, indiquant son type et la classe d'appartenance des entités participant à la connexion, est saisie dans le dictionnaire de données.

3. Création d'un modèle ER du domaine. Les diagrammes ER sont utilisés pour représenter les entités et les relations entre elles. Sur cette base, une seule image visuelle du domaine modélisé est créée - le modèle ER du domaine.

4. Définition des attributs et leur documentation. Tous les attributs qui décrivent les entités du modèle ER créé sont révélés. Chaque attribut reçoit un nom significatif que les utilisateurs peuvent comprendre. Les informations suivantes sont stockées dans le dictionnaire de données pour chaque attribut :

• nom et description de l'attribut ;
• type et dimension des valeurs;
• la valeur par défaut de l'attribut (le cas échéant) ;
• si l'attribut peut avoir des valeurs NULL ;
• si l'attribut est composite, et si oui, de quels attributs simples il se compose. Par exemple, l'attribut "Nom complet du client" peut être composé d'attributs simples "Nom", "Prénom", "Patronyme", ou il peut être simple, contenant des valeurs uniques, telles que "Sidorsky Evgeniy Mikhailovich". Si l'utilisateur n'a pas besoin d'accéder aux éléments individuels du "Nom", l'attribut est présenté comme simple ;
• si l'attribut est calculé, et si oui, comment ses valeurs sont calculées.

5. Définition des valeurs d'attributs et leur documentation. Pour chaque attribut d'une entité participant au modèle ER, un ensemble de valeurs valides est déterminé et un nom lui est attribué. Par exemple, l'attribut "Type de compte" ne peut avoir que les valeurs "dépôt", "actuel", "à la demande", "compte de carte". Les entrées du dictionnaire de données associées aux attributs sont mises à jour avec les noms des ensembles de valeurs d'attribut.

6. Définition des clés primaires des entités et leur documentation. Cette étape est guidée par la définition d'une clé primaire - en tant qu'attribut ou ensemble d'attributs d'une entité qui permet l'identification unique de ses instances. Les informations de clé primaire sont placées dans le dictionnaire de données.

7. Discussion du modèle de données conceptuel avec les utilisateurs finaux. Le modèle de données conceptuel est représenté par un modèle ER accompagné d'une documentation contenant une description du modèle de données développé. Si des incohérences de domaine sont trouvées, des modifications sont apportées au modèle jusqu'à ce que les utilisateurs confirment que le modèle qu'ils proposent reflète adéquatement leurs opinions personnelles.

2.2 Conception logique

L'étape de conception logique a pour objectif de transformer le modèle conceptuel basé sur le modèle de données sélectionné en un modèle logique indépendant des fonctionnalités du SGBD utilisé ultérieurement pour l'implémentation physique de la base de données. Pour y parvenir, les procédures suivantes sont effectuées.

Un exemple de schéma de base de données logique.

1. Choisir un modèle de données. Le plus souvent, un modèle de données relationnelles est choisi en raison de la clarté de la présentation tabulaire des données et de la commodité de travailler avec elles.

2. Définir un ensemble de tables basées sur le modèle ER et les documenter. Un tableau est créé pour chaque entité du modèle ER. Le nom de l'entité est le nom de la table. Les relations entre les tables sont établies par le mécanisme des clés primaires et étrangères. Les structures des tables et les relations établies entre elles sont documentées.

3. Normalisation des tables. Pour effectuer correctement la normalisation, le concepteur doit comprendre en profondeur la sémantique et les modèles d'utilisation des données. A cette étape, il vérifie l'exactitude de la structure des tables créées à l'étape précédente en leur appliquant la procédure de normalisation. Il consiste à amener chacun des tableaux au moins à la 3ème FN. Grâce à la normalisation, une conception de base de données très flexible est obtenue, ce qui permet d'y apporter facilement les extensions nécessaires.

4. Vérification du modèle de données logique pour la possibilité d'effectuer toutes les transactions fournies par les utilisateurs. Une transaction est un ensemble d'actions effectuées par un utilisateur individuel ou un programme d'application pour modifier le contenu d'une base de données. Ainsi, un exemple de transaction dans le projet BANK peut être le transfert du droit de gérer les comptes d'un certain client à un autre client. Dans ce cas, plusieurs modifications devront être apportées à la base de données à la fois. Si un ordinateur tombe en panne pendant une transaction, la base de données sera dans un état incohérent car certaines modifications ont déjà été apportées et d'autres non. Par conséquent, toutes les modifications partielles doivent être annulées pour ramener la base de données à son état cohérent précédent.

La liste des transactions est déterminée par les actions des utilisateurs dans le domaine. En utilisant le modèle ER, le dictionnaire de données et les relations établies entre les clés primaires et étrangères, une tentative est faite pour effectuer manuellement toutes les opérations d'accès aux données nécessaires. Si une opération manuelle échoue, le modèle de données logique compilé est inadéquat et contient des erreurs qui doivent être éliminées. Ils sont peut-être liés à une lacune dans le modèle d'une entité, d'une relation ou d'un attribut.

5. Détermination des exigences de prise en charge de l'intégrité des données et de leur documentation. Ces exigences sont des restrictions mises en place pour empêcher la saisie de données conflictuelles dans la base de données. À cette étape, les problèmes d'intégrité des données sont couverts sans tenir compte des aspects spécifiques de sa mise en œuvre. Les types de restrictions suivants doivent être pris en compte :

• données requises. Rechercher s'il existe des attributs qui ne peuvent pas avoir de valeurs NULL ;
• restrictions sur les valeurs d'attribut. Des valeurs valides pour les attributs sont définies ;
• l'intégrité de l'entité. Il est atteint si la clé primaire de l'entité ne contient pas de valeurs NULL ;
• intégrité référentielle. Il est entendu que la valeur de la clé étrangère doit être présente dans la clé primaire d'une des lignes du tableau pour l'entité mère ;
• restrictions imposées par les règles commerciales. Par exemple, dans le cas du projet BANK, une règle peut être adoptée qui interdit au client de gérer, disons, plus de trois comptes.

Les informations sur toutes les contraintes d'intégrité des données établies sont placées dans le dictionnaire de données.

6. Création de la version finale du modèle logique de données et discussion avec les utilisateurs. Cette étape prépare la version finale du modèle ER, qui représente le modèle de données logique. Le modèle lui-même et la documentation mise à jour, y compris le dictionnaire de données et le schéma de liens de table relationnelle, sont présentés pour examen et analyse par les utilisateurs, qui doivent s'assurer qu'ils représentent avec précision le domaine.

2.3. Conception physique

L'étape de conception physique a pour but de décrire une implémentation spécifique d'une base de données située dans la mémoire externe d'un ordinateur. Il s'agit d'une description de la structure de stockage des données et des méthodes efficaces d'accès aux données de la base de données. Dans la conception logique, ils répondent à la question - ce qui doit être fait, et dans la conception physique - un moyen est choisi pour le faire. Les procédures de conception physique sont les suivantes.

1. Conception de tables de base de données à l'aide du SGBD sélectionné. Un SGBD relationnel est sélectionné pour être utilisé pour créer une base de données hébergée sur un support machine. Sa fonctionnalité pour la conception de tables est profondément étudiée. Ensuite, la conception des tables et le schéma de leur connexion dans l'environnement SGBD sont effectués. Le projet de base de données préparé est décrit dans la documentation jointe.

2. Implémentation des règles métier dans l'environnement du SGBD sélectionné. La mise à jour des informations dans les tables peut être limitée par des règles métier. La manière dont ils sont implémentés dépend du SGBD choisi. Certains systèmes de mise en œuvre des exigences du domaine offrent plus de fonctionnalités, d'autres moins. Dans certains systèmes, il n'y a aucune prise en charge de la mise en œuvre des règles métier. Dans ce cas, des applications sont développées pour implémenter leurs limitations.

Toutes les décisions prises dans le cadre de la mise en œuvre des règles métier du domaine sont décrites en détail dans la documentation jointe.

3. Conception de l'organisation physique de la base de données. Cette étape sélectionne la meilleure organisation de fichiers pour les tables. Les transactions qui seront effectuées dans la base de données en cours de conception sont identifiées, et les plus importantes d'entre elles sont mises en évidence. Le débit des transactions est analysé - le nombre de transactions pouvant être traitées dans un intervalle de temps donné et le temps de réponse - la période de temps nécessaire pour terminer une transaction. Ils s'efforcent d'augmenter le débit des transactions et de réduire le temps de réponse.

Sur la base de ces indicateurs, des décisions sont prises pour optimiser les performances de la base de données en définissant des index dans les tables qui accélèrent la sélection des données de la base de données ou en réduisant les exigences relatives au niveau de normalisation des tables. L'espace disque requis pour accueillir la base de données créée est estimé. Efforcez-vous de le minimiser.

Les décisions prises sur les questions ci-dessus sont documentées.

4. Élaboration d'une stratégie de protection des bases de données. La base de données est une ressource d'entreprise précieuse et une grande attention est accordée à sa protection. Pour ce faire, les concepteurs doivent avoir une compréhension complète et claire de toutes les protections fournies par le SGBD sélectionné.

5. Organisation du suivi du fonctionnement de la base de données et de son ajustement. Après la création du projet physique de la base de données, un suivi continu de son fonctionnement est organisé. Les informations résultantes sur le niveau de performance de la base de données sont utilisées pour l'ajuster. Pour cela, les moyens du SGBD sélectionné sont également mis à contribution.

Les décisions d'apporter des modifications à une base de données fonctionnelle doivent être examinées et pesées avec soin.