1.1 Introduction
La conception d'une base de données est quelque peu similaire à la conception de l'architecture d'un projet Java. Vous pouvez placer toutes les données dans quelques tables ou créer une belle structure de données à partir de schémas et de dizaines de tables.
Voici les tâches auxquelles un développeur est généralement confronté lors de la conception d'une base de données :
- S'assurer que toutes les informations nécessaires sont stockées dans la base de données.
- Assurer la possibilité d'obtenir des données sur toutes les demandes nécessaires.
- Réduire la redondance et la duplication des données.
- Assurer l'intégrité de la base de données
- Optimisation de la vitesse d'accès aux données
La principale chose à retenir est que vous ne pouvez pas créer une structure de base de données idéale, car. il, comme votre code, changera également constamment. Il y a trois choses que vous devez garder à l'esprit lors de la conception de la structure de votre base de données :
- La structure doit être assez bonne.
- Il doit y avoir une logique dans tout ce que les autres peuvent comprendre.
- L'optimisation prématurée est la racine de tout Mal.
Vous n'êtes pas obligé de créer la meilleure structure de base de données au monde. Elle va encore changer. Votre tâche consiste à vous assurer qu'après 20 modifications de la structure de votre base de données, il est assez facile de le comprendre.
Très probablement dans les premières années de votre travail, personne ne vous fera confiance pour concevoir une base à partir de zéro. Vous apporterez des modifications à un schéma existant. Vous devez essayer de comprendre sur la base de quels principes il est organisé et y adhérer . Avec leur charte, ils ne montent pas dans le monastère de quelqu'un d'autre.
N'optimisez pas la base de données tant que cela n'est pas nécessaire. Si la table ne contient que quelques centaines de lignes, le SGBD la conservera probablement en mémoire et y mettra en cache les requêtes.
D'autre part, vous devriez pouvoir accélérer le traitement des demandes importantes de dizaines, voire de centaines de fois. Et ce serait bien si vous saviez comment faire. Comment dit-on au lycée en première année ? "Oublie tout ce qu'on t'a appris à l'école..."
Si vous savez ce qu'est la normalisation de base de données, alors je m'empresse de vous faire plaisir, dans votre travail, vous traiterez très probablement de la dénormalisation . Rien n'est plus important pour les sanctuaires du projet que la rapidité de la base de données. Et si, pour accélérer la sélection des données de la base de données, vous devez combiner 200 (!) Tables en une seule (avec une redondance monstrueuse), vous devrez le faire.
1.2 Conception de la bibliothèque
Plongeons un peu dans le sujet et réfléchissons à la conception de bases de données en utilisant quelque chose d'aussi simple qu'une bibliothèque de livres typique.
La tâche principale de toute bibliothèque est le traitement du fonds de livres. Il est facile de distinguer trois groupes principaux d'utilisateurs du système : lecteur, bibliothécaire, administrateur . L'activité de chacun est présentée dans un diagramme de cas d'utilisation.
Déjà maintenant, certaines entités et relations de la future base de données peuvent être distinguées :
Avec cette approche, on ne sait pas comment relier le lecteur au livre (le lecteur n'a pas d'arité dans la relation « émission/réception ». Si le livre a plusieurs exemplaires, alors il peut être délivré à plusieurs lecteurs. Même si un livre est compris comme un exemplaire, alors lorsqu'il est enregistré dans la table des livres du lecteur actuel, il sera impossible d'obtenir des informations sur qui (et combien de fois) a pris ce livre plus tôt.
La solution peut être l'introduction d'une entité supplémentaire - une carte pour la délivrance d'un livre. Lorsque le livre est remis au lecteur, une carte est créée et lorsque le livre est remis, une marque correspondante y est apposée. A l'aide de ces cartes, les dettes de chaque utilisateur sont déterminées et des statistiques sur l'utilisation des livres sont calculées. Lors de la réservation de littérature par le lecteur, une carte est également lancée ; si la littérature réservée n'est pas prise par le lecteur dans un certain délai, la carte est détruite. Il y a une limite au nombre de livres qu'un lecteur peut réserver.
Lors de la sélection de la littérature, l'utilisateur visualise le catalogue de la littérature avec la possibilité de filtrer les résultats de la recherche par auteur, titre, année de publication.
Il est possible de calculer des statistiques pour tous les livres de la bibliothèque, tandis que le nombre d'exemplaires publiés du livre pour une période de temps donnée. Vous pouvez également définir le nombre minimum d'instances de livre pour lesquelles le calcul est effectué. Sur la base de ces statistiques, les livres inutilisés sont radiés de la bibliothèque.
Les principales entités suivantes du domaine peuvent être distinguées :
- utilisateur (bibliothécaires et administrateurs) ;
- lecteur;
- salle de lecture;
- livre;
- carte d'émission de livres;
- carte de réservation de livre.
Le diagramme ER modifié de la base de données est illustré dans la figure.
Selon les cas d'utilisation illustrés à la figure 1, la base de données doit implémenter les requêtes suivantes (liste non exhaustive) :
- afficher les livres qui correspondent aux conditions spécifiées ;
- afficher les utilisateurs qui ont des cartes pour délivrer des livres qui n'ont pas été fermés à temps (le bibliothécaire recherche des débiteurs) ;
- afficher tous les livres correspondant aux cartes de prêt de livres de l'utilisateur donné qui n'ont pas été fermées à temps (l'utilisateur est venu à la bibliothèque pour de nouveaux livres - vous devez voir s'il est débiteur et l'en informer) ;
- supprimer toutes les fiches de réservation créées il y a plus de N secondes ;
- afficher tous les livres correspondant aux cartes de réservation de livres non fermées de l'utilisateur spécifié (le lecteur a commandé des livres et est venu à la bibliothèque pour eux - le bibliothécaire doit obtenir cette liste afin de la distribuer).
1.3 Formation du schéma
Pour former un schéma de données, vous devez d'abord compléter le diagramme ER avec les détails des entités (l'affiner). Parfois, en même temps, il est possible de trouver des erreurs dans la construction d'un diagramme ER - dans cette tâche, il a été constaté que le livre devait être "d'une manière ou d'une autre" connecté au hall de la bibliothèque.
Cela peut être fait en plaçant le "numéro de salle" requis dans le livre, cependant, avec cette approche, le même livre devra être décrit plusieurs fois dans la base de données (s'il se produit dans différentes salles). Une approche plus correcte consiste à introduire une entité supplémentaire "placement de livre". La figure montre un diagramme ER avec une entité ajoutée et des accessoires.
Le diagramme ER ci-dessus reflète les principales tables, relations et attributs ; sur sa base, vous pouvez créer un modèle de base de données. Il n'y a pas de norme pour le diagramme ER, mais il existe un certain nombre de notations (Chen, IDEFIX, Martin, etc.), mais ni la norme ni les notations n'ont pu être trouvées pour le modèle de domaine. Cependant, au cours de la construction d'un tel diagramme, des champs clés (externes et internes) sont nécessairement mis en évidence, parfois des index et des types de données.
Dans ce cas, dans le schéma suivant :
- pour les liens, la notation de Martin (« pattes d'oie » est utilisée) ;
- les tableaux sont présentés sous forme de rectangles divisés en 3 sections :
- nom de la table;
- clés internes (marquées d'un marqueur);
- les champs restants, tandis que les champs obligatoires sont marqués d'un marqueur.
Lors du développement de ce modèle, il y avait une volonté de joindre la table des administrateurs avec la table des bibliothécaires - ajoutez cependant la table des utilisateurs :
- l'administrateur n'est pas associé à une salle spécifique (il faudrait remplir le champ correspondant avec des valeurs nulles) ;
- cela compliquerait probablement la distribution des droits d'accès - maintenant seul l'administrateur de la base de données (qui travaille via un panneau SGBD spécial et n'a pas de compte dans le système en cours de développement) a accès à la table des administrateurs. Cependant, lors de la jointure de tables, les requêtes des utilisateurs nécessiteraient l'accès à la nouvelle table.
Lors de la construction de ce diagramme, une faille dans le diagramme ER a été trouvée et corrigée - un tableau a été ajouté librarians_roomsqui unit les bibliothécaires et les salles. Ceci est nécessaire car un bibliothécaire peut travailler dans plusieurs salles, mais plusieurs bibliothécaires peuvent travailler dans la même salle.
Lors de la conception de bases de données, vous devriez être capable de raisonner au moins comme dans l'exemple ci-dessus. Si vous pensez avoir réussi, allons plus loin : encore plus de théorie.