Un modèle de données est un ensemble de structures de données et d'opérations pour leur traitement. En utilisant le modèle de données, vous pouvez visualiser la structure des objets et les relations établies entre eux. La terminologie des modèles de données est caractérisée par les concepts d'« élément de données » et de « règles contraignantes ». Un élément de données décrit n'importe quel ensemble de données, et les règles de liaison déterminent les algorithmes pour la relation des éléments de données. À ce jour, de nombreux modèles de données différents ont été développés, mais en pratique, trois principaux sont utilisés. Allouer des modèles de données hiérarchiques, réseau et relationnels. En conséquence, ils parlent de SGBD hiérarchique, réseau et relationnel.

О Modèle de données hiérarchique. Les données organisées hiérarchiquement sont très courantes dans la vie de tous les jours. Par exemple, la structure d'un établissement d'enseignement supérieur est une structure hiérarchique à plusieurs niveaux. Une base de données hiérarchique (en arborescence) se compose d'un ensemble ordonné d'éléments. Dans ce modèle, les éléments originaux donnent naissance à d'autres éléments, et ces éléments à leur tour donnent naissance aux éléments suivants. Chaque enfant n'a qu'un seul parent.

Les organigrammes, les listes de matériaux, la table des matières dans les livres, les plans de projet et de nombreuses autres collections de données peuvent être présentés de manière hiérarchique. L'intégrité des liens entre ancêtres et descendants est automatiquement maintenue. Règle de base : aucun descendant ne peut exister sans son parent.

Le principal inconvénient de ce modèle est la nécessité d'utiliser la hiérarchie qui a été établie dans la base de la base de données lors de la conception. La nécessité d'une réorganisation constante des données (et souvent l'impossibilité de cette réorganisation) a conduit à la création d'un modèle plus général - le réseau.

О Modèle de données de réseau. L'approche en réseau de l'organisation des données est une extension de l'approche hiérarchique. Ce modèle diffère de la hiérarchie en ce que chaque élément généré peut avoir plus d'un élément parent. ■

Étant donné que la base de données du réseau peut représenter directement tous les types de relations inhérentes aux données de l'organisation correspondante, ces données peuvent être parcourues, explorées et interrogées de toutes sortes de manières, c'est-à-dire que le modèle de réseau n'est pas connecté par une seule hiérarchie. Cependant, pour composer une requête vers une base de données réseau, il est nécessaire d'approfondir sa structure (pour avoir un schéma de cette base de données à portée de main) et de développer un mécanisme de navigation dans la base de données, ce qui est un inconvénient important de cette modèle de base de données.

À propos du modèle de données relationnel. L'idée de base derrière un modèle de données relationnel est de représenter n'importe quel ensemble de données sous la forme d'un tableau à deux dimensions. Dans son cas le plus simple, un modèle relationnel décrit une seule table à deux dimensions, mais le plus souvent ce modèle décrit la structure et les relations entre plusieurs tables différentes.

Modèle de données relationnelles

Ainsi, le système d'information a pour objectif de traiter Les donnéesà propos de objets le monde réel, en tenant compte Connexions entre les objets. Dans la théorie des bases de données, les données sont souvent appelées attributs, et objets - entités. Objet, attribut et connexion sont des concepts fondamentaux du S.I.

Un objet(ou entité) est quelque chose qui existe et perceptible, c'est-à-dire qu'un objet peut être appelé ce « quelque chose » pour lequel il existe un nom et un moyen de distinguer un objet similaire d'un autre. Par exemple, chaque école est un objet. Les objets sont aussi une personne, une classe dans une école, une entreprise, un alliage, un composé chimique, etc. Les objets peuvent être non seulement des objets matériels, mais aussi des concepts plus abstraits qui reflètent le monde réel. Par exemple, des événements, des régions, des œuvres d'art ; livres (non pas en tant que produits imprimés, mais en tant qu'œuvres), représentations théâtrales, films ; normes juridiques, théories philosophiques, etc.

Attribut(ou alors donné)- c'est un indicateur qui caractérise un certain objet et prend une certaine valeur numérique, textuelle ou autre pour une instance spécifique de l'objet. Système d'Information fonctionne avec des ensembles d'objets conçus en relation avec un domaine donné, en utilisant des valeurs d'attribut(données) de certains objets. Par exemple, prenons des cours dans une école comme une collection d'objets. Le nombre d'élèves dans une classe est une donnée, qui prend une valeur numérique (une classe en compte 28, une autre en compte 32). Le nom de la classe est une donnée qui prend valeur de texte(l'un a 10A, l'autre a 9B, etc.).

Le développement des bases de données relationnelles a commencé à la fin des années 1960, lorsque les premiers articles sont apparus discutant ; la possibilité d'utiliser dans la conception des bases de données les modes habituels et naturels de présentation des données - les modèles dits datalogiques tabulaires.

Le fondateur de la théorie des bases de données relationnelles est considéré comme un employé d'IBM, le Dr E. Codd, qui a publié l'article Un modèle relationnel de données pour les grandes banques de données partagées(Un modèle de données relationnelles pour les grandes banques de données collectives). Cet article a d'abord utilisé le terme « modèle de données relationnelles ». La théorie des bases de données relationnelles, développée dans les années 70 aux États-Unis par le Dr E. Codd, possède un puissant fondement mathématique qui décrit les règles pour organiser efficacement les données. La base théorique développée par E. Codd est devenue la base du développement de la théorie de la conception de bases de données.

E. Codd, mathématicien de formation, a suggéré d'utiliser l'appareil de la théorie des ensembles (union, intersection, différence, produit cartésien) pour le traitement des données. Il a prouvé que n'importe quel ensemble de données peut être représenté sous la forme de tableaux à deux dimensions d'un type particulier, connus en mathématiques sous le nom de « relations ».

Relationnel une telle base de données est considérée, dans laquelle toutes les données sont présentées à l'utilisateur sous la forme de tables rectangulaires de valeurs de données, et toutes les opérations sur la base de données sont réduites à des tables de manipulation.

Le tableau se compose de colonnes (champs) et lignes (enregistrements); a un nom unique dans la base de données. tableau reflète Type d'objet le vrai monde (essence), et chacune d'elle string est un objet spécifique. Chaque colonne d'un tableau est une collection de valeurs pour un attribut spécifique d'un objet. Les valeurs sont sélectionnées dans l'ensemble de toutes les valeurs possibles de l'attribut d'objet, appelé domaine.

Dans sa forme la plus générale, un domaine est défini en spécifiant un type de données de base auquel appartiennent les éléments du domaine, et une expression logique arbitraire appliquée aux éléments de données. Si, lors de l'évaluation d'une condition logique sur un élément de données, le résultat est « vrai », alors cet élément appartient au domaine. Dans le cas le plus simple, un domaine est défini comme un ensemble potentiel valide de valeurs du même type. Par exemple, l'ensemble des dates de naissance de tous les employés constitue le « domaine de la date de naissance », et les noms de tous les employés constituent le « domaine du nom des employés ». Le domaine de la date de naissance a un type de données pour stocker des informations sur les points dans le temps, et le domaine du nom de l'employé doit être un type de données caractère.

Si deux valeurs proviennent du même domaine, vous pouvez comparer les deux valeurs. Par exemple, si deux valeurs proviennent du domaine des dates de naissance, vous pouvez les comparer pour déterminer quel employé est le plus âgé. Si les valeurs proviennent de domaines différents, leur comparaison n'est pas autorisée car, selon toute vraisemblance, cela n'a pas de sens. Par exemple, rien de précis ne sortira de la comparaison du nom et de la date de naissance d'un employé.

Chaque colonne (champ) a un nom, qui est généralement écrit en haut du tableau. Lors de la conception de tables au sein d'un SGBD spécifique, il est possible de sélectionner pour chaque champ son un type, c'est-à-dire définir un ensemble de règles pour l'afficher, ainsi que définir les opérations qui peuvent être effectuées sur les données stockées dans ce champ. Les ensembles de types peuvent différer pour différents SGBD.

Le nom du champ doit être unique dans la table, cependant différentes tables peuvent avoir des champs avec le même nom. Toute table doit avoir au moins un champ ; les champs sont disposés dans le tableau selon l'ordre de leurs noms lors de sa création. Contrairement aux champs, les chaînes n'ont pas de nom ; leur ordre dans le tableau n'est pas défini, et leur nombre n'est pas logiquement limité.

Étant donné que les lignes du tableau ne sont pas ordonnées, il est impossible de sélectionner une ligne par sa position - il n'y a pas de "premier", "deuxième", "dernier" parmi eux. Toute table a une ou plusieurs colonnes, dont les valeurs identifient de manière unique chacune de ses lignes. Une telle colonne (ou combinaison de colonnes) est appelée clé primaire... Un champ artificiel est souvent introduit pour numéroter les enregistrements dans une table. Un tel champ, par exemple, peut être son ordinal, ce qui peut garantir l'unicité de chaque enregistrement de la table. La clé doit avoir les propriétés suivantes.

Unicité.À tout moment, deux tuples différents de la relation n'ont pas la même valeur pour la combinaison des attributs inclus dans la clé. C'est-à-dire qu'il ne peut pas y avoir deux lignes dans le tableau qui ont le même numéro d'identification ou le même numéro de passeport.

Minimalité. Aucun des attributs inclus dans la clé ne peut être exclu de la clé sans violer l'unicité. Cela signifie qu'il n'est pas nécessaire de créer une clé qui comprend à la fois le numéro de passeport et le numéro d'identification. Il suffit d'utiliser l'un de ces attributs pour identifier de manière unique le tuple. Vous ne devez pas non plus inclure d'attribut non unique dans la clé, c'est-à-dire qu'il est interdit d'utiliser une combinaison d'un numéro d'identification et du nom d'un employé comme clé. En excluant le nom de l'employé de la clé, vous pouvez toujours identifier de manière unique chaque ligne.

Chaque relation a au moins une clé possible, puisque la totalité de tous ses attributs satisfait à la condition d'unicité - cela découle de la définition même de la relation.

L'une des clés possibles est sélectionnée au hasard dans comme clé primaire. Les clés possibles restantes, le cas échéant, sont prises comme clés alternatives. Par exemple, si vous sélectionnez un numéro d'identification comme clé primaire, le numéro de passeport sera une clé alternative.

La relation des tables est un élément essentiel du modèle de données relationnelles. elle est soutenue clés étrangères.

Lors de la description d'un modèle de base de données relationnelle, différents termes sont souvent utilisés pour le même concept, selon le niveau de description (théorie ou pratique) et le système (Access, SQL Server, dBase). Tableau 2.3 résume les termes utilisés.

Tableau 2.3. Terminologie de la base de données

Théorie des bases de données ____________ Bases de données relationnelles _________ SQL Server __________

Tableau des relations Tableau

Ligne d'enregistrement de tuple

Champ d'attribut _______________ Colonne

Bases de données relationnelles

Base de données relationnelle est un ensemble de relations contenant toutes les informations qui doivent être stockées dans la base de données. C'est-à-dire que la base de données représente l'ensemble des tables requises pour stocker toutes les données. Les tables de bases de données relationnelles sont logiquement liées les unes aux autres. Les exigences de conception d'une base de données relationnelle peuvent être résumées en quelques règles.

О Chaque table a un nom unique dans la base de données et se compose de lignes du même type.

Chaque tableau se compose d'un nombre fixe de colonnes et de valeurs. Plusieurs valeurs ne peuvent pas être stockées dans une colonne d'une ligne. Par exemple, s'il existe un tableau contenant des informations sur l'auteur, la date de publication, la diffusion, etc., la colonne avec le nom de l'auteur ne peut pas contenir plus d'un nom de famille. Si le livre est écrit par deux auteurs ou plus, vous devrez utiliser des tableaux supplémentaires.

О À aucun moment, il n'y aura deux lignes dans le tableau qui se dupliquent l'une l'autre. Les lignes doivent différer d'au moins une valeur afin de pouvoir identifier de manière unique n'importe quelle ligne de la table.

О Chaque colonne se voit attribuer un nom unique dans la table ; un type de données spécifique lui est défini afin que des valeurs homogènes (dates, noms, numéros de téléphone, sommes d'argent, etc.) soient placées dans cette colonne.

О Le contenu informationnel complet de la base de données est représenté sous la forme de valeurs explicites des données elles-mêmes, et cette méthode de présentation est la seule. Par exemple, la relation entre les tables est basée sur les données stockées dans les colonnes correspondantes, et non sur la base de pointeurs définissant artificiellement des relations.

О Lors du traitement des données, vous pouvez librement vous référer à n'importe quelle ligne ou colonne du tableau. Les valeurs stockées dans le tableau n'imposent aucune restriction sur l'ordre d'accès aux données. Description de la colonne,

2. Principes du modèle relationnel

Principes du modèle de base de données relationnelle, relation, table, jeu de résultats, tuple, cardinalité, attribut, dimension, titre, corps, domaine

Le modèle relationnel a été développé à la fin des années 1960 par E. F. Codd (employé d'IBM) et publié en 1970. Il définit la manière dont les données sont représentées (structure des données), les méthodes de protection des données (intégrité des données) et les opérations pouvant être effectuées avec les données ( manipulation de données).

Le modèle relationnel n'est pas le seul à pouvoir être utilisé lorsque l'on travaille avec des données. Il existe également un modèle hiérarchique, un modèle en réseau, un modèle en étoile, etc. Cependant, le modèle relationnel s'est avéré le plus pratique et est donc aujourd'hui le plus largement utilisé.

Les principes de base des bases de données relationnelles peuvent être résumés comme suit :

· Toutes les données au niveau conceptuel sont représentées sous la forme d'une organisation ordonnée, définie sous forme de lignes et de colonnes et appelée relation. Le synonyme le plus courant de relation est une table (ou un jeu d'enregistrements, ou un jeu de résultats. C'est de là que vient le terme bases de données relationnelles, pas les relations entre les tables ;

· Toutes les valeurs sont des scalaires. Cela signifie que pour n'importe quelle ligne et colonne dans n'importe quelle relation, il y a une et une seule valeur ;

· Toutes les opérations sont effectuées sur l'ensemble de la relation et le résultat de ces opérations est également l'ensemble de la relation. Ce principe s'appelle l'accrochage. Par conséquent, les résultats d'une opération (par exemple, une requête) peuvent être utilisés comme entrée pour effectuer une autre opération (sous-requête).

Maintenant, à propos de la terminologie formelle :

· attitude(relation) est la structure entière dans son ensemble, un ensemble d'enregistrements (au sens habituel, une table).

· cortège est chaque ligne contenant des données. Un terme plus courant mais moins formel est record.

· Puissance- le nombre de tuples dans la relation (en d'autres termes, le nombre d'enregistrements) ;

· attribut est une colonne en relation ;

· dimension est le nombre d'attributs dans la relation (dans ce cas, 3);

Chaque relation peut être divisée en deux parties - titre et corps... En langage simple, le titre d'une relation est une liste de colonnes, et le corps est les enregistrements eux-mêmes (tuples).

· Dans notre exemple, le nom de chaque colonne (attribut) se compose de deux mots séparés par deux points. Selon les définitions formelles, la première partie est Nom d'attribut(nom de la colonne) et la deuxième partie est domaine(le type de données que la colonne de données représente). Le domaine et le type de données ne sont pas équivalents. En pratique, le domaine est généralement omis.

· Le corps d'une relation consiste en un ensemble non ordonné de tuples (son nombre peut être quelconque - de 0 à infiniment grand).

Le concept de relationnel (anglais relation - relation) est associé aux développements du célèbre spécialiste américain dans le domaine des systèmes de bases de données, employé d'IBM, le Dr E. Codd (Codd EF, A Relational Model of Data for Large Shared Data Banks, CACM 13 : 6, juin 1970), qui a été le pionnier du terme « modèle de données relationnelles ».

Pendant longtemps, l'approche relationnelle a été considérée comme un outil formel commode pour l'analyse de bases de données qui n'a pas perspectives pratiques, car sa mise en œuvre nécessitait des ressources machine trop importantes. Ce n'est qu'avec l'avènement des ordinateurs personnels que les systèmes relationnels et connexes ont commencé à se répandre, laissant peu de place à d'autres modèles.

Ces modèles se caractérisent par la simplicité de la structure des données, une présentation tabulaire conviviale et la capacité d'utiliser l'appareil formel de l'algèbre des relations et du calcul relationnel pour le traitement des données.

Le modèle relationnel se concentre sur l'organisation des données sous forme de tableaux à deux dimensions. Chaque table relationnelle est un tableau à deux dimensions et possède les propriétés suivantes :

- chaque élément du tableau est un élément de données ; il n'y a pas de groupes répétitifs ;
- toutes les colonnes du tableau sont homogènes, c'est-à-dire tous les éléments d'une colonne ont le même type (numérique, caractère, etc.) et la même longueur ;
- chaque colonne a un nom unique ;
- il n'y a pas de lignes identiques dans le tableau ;
- l'ordre des lignes et des colonnes peut être arbitraire. Ce type de table s'appelle une relation.

Une base de données construite à l'aide de relations est appelée base de données relationnelle.

Les relations sont présentées sous forme de tableaux, dont les lignes correspondent à des tuples ou des enregistrements, et les colonnes correspondent à des attributs de relation, des domaines et des champs.

Un champ, dont chaque valeur identifie de manière unique un enregistrement correspondant, est appelé clé simple (champ clé). Si les enregistrements sont identifiés de manière unique par les valeurs de plusieurs champs, une telle table de base de données possède une clé composite.

Pour lier deux tables relationnelles, la clé de la première table doit être incluse dans la clé de la deuxième table (les clés peuvent coïncider) ; sinon, vous devez entrer dans la structure de la première table la clé étrangère - la clé de la deuxième table.

Ayant proposé un modèle de données relationnelles, E.F. Codd a également créé un outil pour travailler facilement avec les relations - l'algèbre relationnelle. Chaque opération de cette algèbre utilise une ou plusieurs tables (relations) comme opérandes et produit comme résultat nouveau tableau, c'est à dire. vous permet de "couper" ou de "coller" des tables.

Ce qui diffère fondamentalement des modèles relationnels des modèles réseau et hiérarchiques peut être dit comme suit : modèles de réseau données - ont une relation par structure, et relationnel - ont une relation par valeur.

La conception de bases de données a toujours été considérée comme une tâche très difficile. La technologie relationnelle simplifie grandement cette tâche.

En séparant les couches logiques et physiques du système, cela simplifie le processus de mappage de la « couche du monde réel » dans une structure que le système peut directement prendre en charge. Parce que le cadre relationnel lui-même est conceptuellement simple, il permet la mise en œuvre de bases de données petites et/ou simples (et donc faciles à créer), telles que des bases de données personnelles, qui n'auraient jamais été considérées comme possibles dans des systèmes plus anciens et plus complexes.

La théorie et la discipline de la normalisation peuvent aider en montrant ce qui se passe lorsque les relations ne sont pas naturellement structurées.

Le modèle de données relationnelles est particulièrement pratique pour une utilisation dans les bases de données d'une architecture distribuée - il vous permet d'accéder à tous les éléments d'information stockés dans les nœuds d'un réseau informatique. Il est nécessaire de porter une attention particulière à l'aspect de haut niveau de l'approche relationnelle, qui consiste en un traitement multiple des enregistrements. De ce fait, le potentiel de l'approche relationnelle augmente considérablement, ce qui ne peut être atteint lors du traitement d'un enregistrement à la fois et, surtout, il s'agit d'optimisation.

Ce modèle permet de déterminer :

· Opérations de stockage et de récupération de données ;
· Restrictions liées à la garantie de l'intégrité des données.

Pour augmenter l'efficacité du travail dans de nombreux SGBD relationnels, des restrictions sont adoptées qui correspondent au modèle relationnel strict.

De nombreux SGBD relationnels présentent les fichiers de base de données à l'utilisateur sous forme de tableau - avec les enregistrements sous forme de lignes et leurs champs sous forme de colonnes. Sous forme de tableau, l'information est perçue beaucoup plus facilement. Cependant, dans la base de données au niveau physique, les données sont généralement stockées dans des fichiers contenant des séquences d'enregistrements.

Le principal avantage des SGBD relationnels est la possibilité de lier en fonction de ratios spécifiques de fichiers de base de données.

D'un point de vue structurel, les modèles relationnels sont plus simples et plus homogènes que les modèles hiérarchiques et en réseau. Dans le modèle relationnel, chaque objet du domaine correspond à une ou plusieurs relations. S'il est nécessaire de définir explicitement une relation entre objets, elle s'exprime sous la forme d'une relation dans laquelle des identifiants d'objets liés sont présents en tant qu'attributs. Dans le modèle relationnel, les objets du domaine et les connexions entre eux sont représentés par les mêmes constructions d'information, simplifiant grandement le modèle lui-même.

Un SGBD est considéré comme relationnel si les deux conditions suivantes sont réunies, proposées par E. Codd :

· Prend en charge une structure de données relationnelle;
· Met en œuvre, au minimum, des opérations de sélection, de projection et de connexion de relations.

Par la suite, un certain nombre de SGBD relationnels ont été créés qui, à un degré ou à un autre, répondent à cette définition. De nombreux SGBD sont des extensions significatives du modèle relationnel, d'autres sont mixtes, supportant plusieurs modèles datalogiques.

Aujourd'hui, les bases de données relationnelles restent les plus courantes, en raison de leur simplicité et de leur visibilité, tant dans le processus de création qu'au niveau de l'utilisateur.

Le principal avantage des bases de données relationnelles est la compatibilité avec les plus langue populaire Requêtes SQL.

Avec une seule requête dans ce langage, vous pouvez joindre plusieurs tables dans une table temporaire et en découper les lignes et les colonnes requises (sélection et projection). Parce que la structure tabulaire d'une base de données relationnelle est intuitive pour les utilisateurs, SQL est simple et facile à apprendre. Le modèle relationnel a une base théorique solide sur laquelle l'évolution et la mise en œuvre des bases de données relationnelles ont été basées. Dans le sillage de la popularité provoquée par le succès du modèle relationnel, SQL est devenu le langage principal des bases de données relationnelles.

Mais les inconvénients du modèle de base de données considéré ont également été identifiés :

- étant donné que tous les champs d'une table doivent contenir un nombre constant de champs de types prédéterminés, il est nécessaire de créer des tables supplémentaires, en tenant compte des caractéristiques individuelles des éléments, à l'aide de clés étrangères. Cette approche rend très difficile la création de relations complexes dans la base de données ;
- grande complexité de la manipulation des informations et des changements de connexions.

Traduction

Note du traducteur : bien que l'article soit assez ancien (publié il y a 2 ans) et porte un titre fort, il donne quand même une bonne idée des différences entre les bases de données relationnelles et les bases de données NoSQL, leurs avantages et inconvénients, et fournit également bref avis stockage non relationnel.

DANS Ces derniers temps il existe de nombreuses bases de données non relationnelles. Cela suggère que si vous voulez une évolutivité à la demande pratiquement illimitée, vous avez besoin d'une base de données non relationnelle.

Si cela est vrai, cela signifie-t-il que les puissantes bases de données relationnelles sont vulnérables ? Est-ce à dire que le temps des bases de données relationnelles est révolu et le sera bientôt ? Dans cet article, nous examinerons la dérive populaire des bases de données non relationnelles pour diverses situations et verrons si cela a un impact sur l'avenir des bases de données relationnelles.

Les bases de données relationnelles existent depuis environ 30 ans. Pendant ce temps, plusieurs révolutions ont éclaté qui devaient mettre fin au stockage relationnel. Bien entendu, aucune de ces révolutions n'a eu lieu, et l'une d'entre elles n'a pas ébranlé d'un iota la position des bases de données relationnelles.

Commençons par les bases

Une base de données relationnelle est un ensemble de tables (entités). Les tableaux sont constitués de colonnes et de lignes (tuples). Des contraintes peuvent être définies au sein des tables, des relations existent entre les tables. À l'aide de SQL, vous pouvez exécuter des requêtes qui renvoient des ensembles de données à partir d'une ou plusieurs tables. Au sein d'une même requête, les données sont obtenues à partir de plusieurs tables en les joignant (JOIN), le plus souvent les mêmes colonnes sont utilisées pour la jointure, ce qui détermine la relation entre les tables. La normalisation est le processus de structuration d'un modèle de données pour assurer la cohérence et la non-redondance des données.

Les bases de données relationnelles sont accessibles via des systèmes de gestion de bases de données relationnelles (SGBDR). Presque tous les systèmes de bases de données que nous utilisons sont relationnels tels que Oracle, SQL Server, MySQL, Sybase, DB2, TeraData, etc.

Les raisons de cette domination ne sont pas évidentes. Tout au long de l'histoire des bases de données relationnelles, elles ont toujours offert le meilleur mélange de simplicité, de robustesse, de flexibilité, de performances, d'évolutivité et d'interopérabilité dans la gestion des données.

Cependant, pour fournir toutes ces fonctionnalités, le stockage relationnel est incroyablement complexe en interne. Par exemple simple requête SELECT peut avoir des centaines de chemins d'exécution potentiels que l'optimiseur évaluera directement lors de l'exécution de la requête. Tout cela est caché aux utilisateurs, mais à l'intérieur du SGBDR, il crée un plan d'exécution basé sur des éléments tels que des algorithmes d'estimation des coûts et la meilleure façon répondre à la demande.

Problèmes de base de données relationnelle

Bien que le stockage relationnel offre le meilleur mélange de simplicité, de robustesse, de flexibilité, de performances, d'évolutivité et de compatibilité, il n'obtient pas nécessairement de meilleurs résultats sur chacun d'entre eux que des systèmes similaires qui se concentrent sur une fonctionnalité particulière. Ce n'était pas gros problème parce que la domination écrasante des SGBD relationnels l'emportait sur toutes les lacunes. Cependant, si les RDB classiques ne répondaient pas aux besoins, il y avait toujours des alternatives.

Aujourd'hui, la situation est un peu différente. La variété des applications augmente, et avec elle l'importance des fonctionnalités répertoriées. Et à mesure que le nombre de bases de données augmente, une fonctionnalité commence à éclipser toutes les autres. C'est l'évolutivité. Comme de plus en plus d'applications s'exécutent dans des conditions de charge élevée telles que les services Web, leurs exigences en matière d'évolutivité peuvent changer très rapidement et croître considérablement. Le premier problème peut être très difficile à résoudre si vous disposez d'une base de données relationnelle située à propre serveur... Supposons que la charge du serveur ait triplé du jour au lendemain. À quelle vitesse pouvez-vous mettre à niveau le matériel ? La solution du deuxième problème pose également des difficultés dans le cas de l'utilisation de bases de données relationnelles.

Les bases de données relationnelles ne s'adaptent correctement que si elles sont situées sur un seul serveur. Lorsque ce serveur manque de ressources, vous devrez ajouter d'autres machines et répartir la charge entre elles. C'est là que la complexité des bases de données relationnelles commence à jouer contre l'évolutivité. Si vous essayez d'augmenter le nombre de serveurs non pas à quelques-uns, mais à une centaine ou à un millier, la complexité augmente d'un ordre de grandeur, et les caractéristiques qui rendent les bases de données relationnelles si attractives réduisent rapidement à zéro les chances de les utiliser comme une plate-forme pour les grands systèmes distribués.

Pour rester compétitifs, les fournisseurs services cloud vous devez en quelque sorte faire face à cette limitation, car de quel type de plate-forme cloud s'agit-il sans stockage de données évolutif. Par conséquent, les fournisseurs n'ont qu'une seule option s'ils souhaitent fournir aux utilisateurs un espace de stockage évolutif. Vous devez utiliser d'autres types de bases de données plus évolutives, bien qu'au prix d'autres fonctionnalités disponibles dans les bases de données relationnelles.

Ces avantages, ainsi que la demande existante pour eux, ont conduit à une vague de nouveaux systèmes de gestion de bases de données.

Nouvelle vague

Ce type de base de données est communément appelé magasin clé-valeur. En fait, il n'y a pas de nom officiel, vous pouvez donc le trouver dans le contexte des bases de données distribuées orientées document, orientées attributs (bien qu'elles puissent également être relationnelles), des tableaux triés fragmentés, des tables de hachage distribuées et du stockage. taper. Bien que chacun de ces noms indique des caractéristiques spécifiques du système, ils sont tous des variantes de ce que nous appellerons le stockage clé-valeur.

Cependant, peu importe comment vous l'appelez, ce "nouveau" type de base de données n'est pas si nouveau et a toujours été utilisé principalement pour des applications pour lesquelles les bases de données relationnelles seraient inappropriées. Cependant, sans le besoin d'évolutivité du Web et du cloud, ces systèmes n'étaient pas très demandés. Maintenant, le défi consiste à déterminer quel type de stockage est le plus adapté à un système particulier.
Les bases de données relationnelles et les stockages de valeurs-clés diffèrent fondamentalement et sont conçus pour résoudre différents problèmes. Comparer les caractéristiques vous permettra seulement de comprendre la différence entre elles, mais commençons par ceci :

Caractéristiques de stockage

Base de données relationnelle	Stockage des valeurs-clés
Une base de données est constituée de tables, les tables sont constituées de colonnes et de lignes et les lignes sont constituées de valeurs de colonnes. Toutes les lignes d'une table ont la même structure.	Pour les domaines, vous pouvez faire une analogie avec les tables, mais contrairement aux tables pour les domaines, la structure des données n'est pas définie. Un domaine est une boîte dans laquelle vous pouvez mettre tout ce que vous voulez. Les enregistrements d'un même domaine peuvent avoir des structures différentes.
Le modèle de données 1 est prédéfini. Il est fortement typé et contient des contraintes et des relations pour assurer l'intégrité des données.	Les enregistrements sont identifiés par clé, chaque enregistrement étant associé à un ensemble dynamique d'attributs.
Le modèle de données est basé sur la représentation naturelle des données contenues, et non sur la fonctionnalité de l'application.	Dans certaines implémentations, les attributs ne peuvent être que des chaînes. Dans d'autres implémentations, les attributs ont des types de données simples qui reflètent les types utilisés dans la programmation : entiers, tableaux de chaînes et listes.
Le modèle de données est normalisé pour éviter la duplication des données. La normalisation crée des relations entre les tables. Les relations relient les données de différentes tables.	Les relations ne sont pas explicitement définies entre les domaines, ainsi qu'au sein d'un même domaine.

Aucune jointure

Les magasins de valeurs-clés sont orientés enregistrement. Cela signifie que toutes les informations relatives à un enregistrement donné sont stockées avec celui-ci. Un domaine (que vous pouvez considérer comme une table) peut contenir d'innombrables enregistrements différents. Par exemple, un domaine peut contenir des informations sur les clients et les commandes. Cela signifie que les données sont généralement dupliquées entre différents domaines... C'est une approche acceptable car espace disque peu coûteux. L'essentiel est que toutes les données associées soient stockées au même endroit, ce qui améliore l'évolutivité, car il n'est pas nécessaire de joindre les données de différentes tables. Lorsque vous utilisez une base de données relationnelle, vous devez utiliser des jointures pour regrouper les informations nécessaires en un seul endroit.

Bien que le besoin d'une relation diminue considérablement pour stocker des paires clé-valeur, des relations sont toujours nécessaires. De telles relations existent généralement entre les entités principales. Par exemple, un système de commande aurait des enregistrements contenant des données sur les clients, les produits et les commandes. Peu importe que ces données appartiennent à un domaine ou à plusieurs. L'essentiel est que lorsqu'un client passe une commande, vous ne voulez probablement pas conserver les informations sur le client et la commande dans un seul enregistrement.
Au lieu de cela, l'enregistrement de la commande doit contenir des clés qui pointent vers les enregistrements client et produit correspondants. Étant donné que les enregistrements peuvent stocker n'importe quelle information et que les relations ne sont pas définies dans le modèle de données lui-même, le système de gestion de base de données ne sera pas en mesure de contrôler l'intégrité des relations. Cela signifie que vous pouvez supprimer les clients et les produits qu'ils ont commandés. La garantie de l'intégrité des données relève de l'entière responsabilité de l'application.

Accès aux données

Base de données relationnelle	Stockage des valeurs-clés
Les données sont créées, mises à jour, supprimées et interrogées à l'aide du langage de requête structuré (SQL).	Les données sont créées, mises à jour, supprimées et interrogées à l'aide d'appels de méthode API.
Les requêtes SQL peuvent extraire des données à la fois d'une seule table et de plusieurs tables à l'aide de jointures.	Certaines implémentations fournissent une syntaxe de type SQL pour spécifier les conditions de filtrage.
Les requêtes SQL peuvent inclure des agrégations et des filtres complexes.	Souvent, vous ne pouvez utiliser que des opérateurs de comparaison de base (=,! =,<, >, <= и =>).
Une base de données relationnelle contient généralement une logique intégrée telle que des déclencheurs, des procédures stockées et des fonctions.	Toute la logique commerciale et d'intégrité des données est contenue dans le code de l'application.

Interaction avec les applications

Magasins clé-valeur : avantages

Ces systèmes présentent deux avantages distincts par rapport au stockage relationnel.

Convient aux services cloud

Le premier avantage des magasins clé-valeur est qu'ils sont plus simples et donc plus évolutifs que les bases de données relationnelles. Si vous hébergez votre propre système ensemble et prévoyez d'héberger une douzaine ou une centaine de serveurs qui doivent gérer la charge croissante derrière votre magasin de données, alors les magasins de valeurs-clés sont votre choix.

Parce qu'ils sont facilement et dynamiquement extensibles, ils sont également utiles pour les fournisseurs qui proposent une plate-forme de stockage Web multi-locataires. Une telle base de données représente un support de stockage relativement peu coûteux avec un grand potentiel d'évolutivité. Les utilisateurs ne paient généralement que pour ce qu'ils utilisent, mais leurs besoins peuvent augmenter. Le vendeur pourra augmenter dynamiquement et pratiquement sans restrictions la taille de la plate-forme, en fonction de la charge.

Intégration de code plus naturelle

Le modèle de données relationnel et le modèle d'objet de code sont généralement construits différemment, ce qui entraîne une certaine incompatibilité. Les développeurs résolvent ce problème en écrivant du code qui mappe le modèle relationnel sur modèle d'objet... Ce processus n'a pas une valeur claire et rapidement réalisable et peut prendre beaucoup de temps, qui pourrait être consacré au développement de l'application elle-même. En attendant, de nombreux magasins de valeurs-clés stockent les données dans une structure qui correspond plus naturellement aux objets. Cela peut réduire considérablement le temps de développement.

D'autres arguments en faveur de l'utilisation de magasins de valeurs-clés, tels que "les bases de données relationnelles peuvent devenir maladroites" (en passant, je n'ai aucune idée de ce que cela signifie), sont moins convaincants. Mais avant de devenir un partisan de tels référentiels, consultez la section suivante.

Magasins clé-valeur : inconvénients

Les contraintes dans les bases de données relationnelles garantissent l'intégrité des données au niveau le plus bas. Les données qui ne répondent pas physiquement aux contraintes ne peuvent pas entrer dans la base de données. Il n'y a pas de telles restrictions dans les stockages de valeurs-clés, de sorte que le contrôle de l'intégrité des données repose entièrement sur les applications. Cependant, il y a des bogues dans n'importe quel code. Alors que les erreurs dans une base de données relationnelle bien conçue n'entraînent généralement pas de problèmes d'intégrité des données, les erreurs dans les magasins de valeurs-clés entraînent généralement de tels problèmes.

Un autre avantage des bases de données relationnelles est qu'elles vous obligent à développer un modèle de données. Si vous disposez d'un modèle bien conçu, la base de données contiendra une structure logique qui reflète pleinement la structure des données stockées, mais qui est en contradiction avec la structure de l'application. Ainsi, les données deviennent indépendantes de l'application. Cela signifie qu'une autre application peut utiliser les mêmes données et que la logique de l'application peut être modifiée sans aucune modification du modèle de base. Pour faire de même avec le stockage clé-valeur, essayez de remplacer le processus de conception de modèle relationnel par une conception de classe, qui crée des classes génériques basées sur la structure de données naturelle.

Et n'oubliez pas la compatibilité. Contrairement aux bases de données relationnelles, le stockage basé sur le cloud a beaucoup moins normes communes... Bien que conceptuellement, ils ne soient pas différents, ils ont tous des API, des interfaces de requête et leurs propres spécificités différentes. Par conséquent, vous feriez mieux de faire confiance à votre fournisseur, car si quelque chose se produit, vous ne pouvez pas facilement passer à un autre fournisseur de services. Et étant donné que presque tous les magasins clé-valeur modernes sont en version bêta 2, la confiance devient encore plus risquée que les bases de données relationnelles.

Analyse de données limitée

Généralement tous stockage en ligne sont construits sur le type de baux multiples, ce qui signifie qu'un même système est utilisé par un grand nombre d'utilisateurs et d'applications. Pour empêcher le « détournement » de l'ensemble du système, les fournisseurs restreignent généralement l'exécution des requêtes d'une manière ou d'une autre. Par exemple, dans SimpleDB, une requête ne peut pas prendre plus de 5 secondes. Google AppEngine Datastore ne peut pas récupérer plus de 1000 enregistrements par requête 3.

Ces restrictions ne sont pas effrayantes pour une logique simple (créer, mettre à jour, supprimer et récupérer un petit nombre d'enregistrements). Mais que se passe-t-il si votre application devient populaire ? Vous avez beaucoup de nouveaux utilisateurs et beaucoup de nouvelles données, et maintenant vous voulez créer de nouvelles expériences pour les utilisateurs ou profiter d'une manière ou d'une autre des données. C'est là que vous pouvez vous détraquer avec des requêtes même simples pour analyser des données. Des fonctionnalités telles que le suivi des modèles d'utilisation des applications ou un système de recommandation basé sur l'historique des utilisateurs peuvent être au mieux difficiles. Et au pire, ils sont tout simplement impossibles.

Dans ce cas, pour l'analyse, il est préférable de créer une base de données distincte qui sera remplie des données de votre stockage clé-valeur. Pensez à l'avance comment cela peut être fait. Allez-vous héberger le serveur dans le cloud ou seul ? Y aura-t-il des problèmes dus à des retards de signal entre vous et votre fournisseur ? Votre stockage prend-il en charge ce transfert de données ? Si vous avez 100 millions d'enregistrements et que vous pouvez prendre 1 000 enregistrements à la fois, combien faudra-t-il pour transférer toutes les données ?

Cependant, ne donnez pas la priorité à l'évolutivité. Il sera inutile si vos utilisateurs décident d'utiliser les services d'un autre service, car cela offre plus d'options et de paramètres.

Stockage en ligne

De nombreux fournisseurs de services Web proposent des magasins clé-valeur multi-locataires. La plupart d'entre eux répondent aux critères énumérés ci-dessus, mais chacun a ses propres caractéristiques et diffère des normes décrites ci-dessus. Jetons un coup d'oeil à exemple précis référentiels tels que SimpleDB, Google AppEngine Datastore et SQL Data Services.

Amazon : SimpleDB

SimpleDB est un magasin orienté attribut clé-valeur qui est inclus avec Amazon WebServices. SimpleDB est en version bêta ; les utilisateurs peuvent l'utiliser gratuitement - tant que leurs besoins ne dépassent pas une certaine limite.

SimpleDB a plusieurs limitations. Premièrement, le temps d'exécution de la requête est limité à 5 secondes. Deuxièmement, il n'y a pas de types de données autres que des chaînes. Tout est stocké, récupéré et comparé sous forme de chaîne, donc pour comparer les dates, vous devrez les convertir au format ISO8601. Troisièmement, la taille maximale de toute chaîne est de 1024 octets, ce qui limite la taille du texte (par exemple, la description du produit) que vous pouvez stocker en tant qu'attribut. Cependant, étant donné que la structure des données est flexible, vous pouvez contourner cette limitation en ajoutant les attributs "Description du produit1", "Description du produit2", etc. Mais le nombre d'attributs est également limité - un maximum de 256 attributs. Alors que SimpleDB est en version bêta, la taille du domaine est limitée à 10 gigaoctets et la base de données entière ne peut pas dépasser 1 téraoctet.

L'une des principales caractéristiques de SimpleDB est son utilisation du modèle de cohérence éventuel. Ce modèle convient au travail multithread, mais gardez à l'esprit qu'après avoir modifié la valeur d'un attribut dans un enregistrement, les opérations de lecture suivantes peuvent ne pas voir ces changements. La probabilité d'un tel développement d'événements est assez faible, néanmoins, il faut s'en souvenir. Vous ne voulez pas vendre le dernier billet à cinq clients simplement parce que vos données étaient incohérentes au moment de la vente.

Magasin de données Google AppEngine

Le magasin de données AppEngine de Google repose sur BigTable, le système de stockage de données structuré interne de Google. Le magasin de données AppEngine ne fournit pas d'accès direct à BigTable, mais peut être considéré comme une interface simplifiée pour interagir avec BigTable.

AppEngine Datastore prend en charge plus de types de données dans un seul enregistrement que SimpleDB. Par exemple, les listes, qui peuvent contenir des collections dans un enregistrement.

Vous utiliserez très probablement ce magasin de données particulier lors du développement avec en utilisant google AppEngine. Cependant, contrairement à SimpleDB, vous ne pouvez pas utiliser AppEngine Datastore (ou BigTable) en dehors des services Web de Google.

Microsoft : Services de données SQL

SQL Data Services fait partie de Plateformes Microsoft Bleu azur. SQL Data Services est gratuit, en version bêta, et a des limites de taille de base de données. SQL Data Services est une application autonome - un module complémentaire sur l'ensemble Serveurs SQL qui stockent les données. Ces magasins peuvent être relationnels, mais pour vous, SDS est un magasin clé-valeur, tout comme les produits décrits ci-dessus.

Stockage hors cloud

Il existe également un certain nombre de référentiels que vous pouvez utiliser en dehors du cloud en les installant vous-même. Presque tous ces projets sont jeunes, en alpha ou bêta, et open source. Avec l'open source, vous êtes peut-être plus conscient des problèmes potentiels et des limitations qu'avec les produits propriétaires.

CouchDB

CouchDB est une base de données orientée document gratuite et open source. JSON est utilisé comme format de stockage de données. CouchDB vise à combler le fossé entre les bases de données documentaires et relationnelles en utilisant des "vues". Ces vues contiennent des données de documents sous une forme similaire à un tableau et vous permettent de créer des index et d'exécuter des requêtes.

CouchDB n'est pas une base de données vraiment distribuée pour le moment. Il dispose de fonctionnalités de réplication pour maintenir la synchronisation des données entre les serveurs, mais ce n'est pas le type de distribution nécessaire pour créer un environnement hautement évolutif. Cependant, les développeurs de CouchDB y travaillent.

Projet Voldemort

Le projet Voldemort est base distribuée type de données clé-valeur, conçu pour évoluer sur un grand nombre de serveurs. Il est né lors du développement de LinkedIn et a été utilisé pour plusieurs systèmes avec des exigences d'évolutivité élevées. Le projet Voldemort utilise également un modèle de cohérence final.

Mongo

Mongo est une base de données développée à 10gen par Geir Magnusson et Dwight Merriman (que vous connaissez peut-être de DoubleClick). Comme CouchDB, Mongo est une base de données orientée document qui stocke les données au format JSON. Cependant, Mongo est plus une base d'objets qu'un simple magasin de valeurs-clés.

Bruine

Drizzle présente une approche très différente pour résoudre les problèmes que les magasins de valeurs-clés sont conçus pour traiter. Drizzle a commencé comme une branche de MySQL 6.0. Plus tard, les développeurs ont supprimé un certain nombre de fonctions (y compris les vues, les déclencheurs, les expressions compilées, les procédures stockées, le cache de requêtes, les listes de contrôle d'accès et certains types de données) afin de créer un SGBD plus simple et plus rapide. Cependant, Drizzle peut toujours être utilisé pour stocker des données relationnelles. L'objectif des développeurs est de créer une plate-forme semi-relationnelle conçue pour les applications Web et cloud s'exécutant sur des systèmes dotés de 16 cœurs ou plus.

Solution

En fin de compte, il y a quatre raisons pour lesquelles vous pouvez choisir un stockage clé-valeur non relationnel pour votre application :

Vos données sont fortement orientées document et sont plus adaptées à un modèle de données clé-valeur qu'à un modèle de données relationnel.
Votre modèle de domaine est fortement orienté objet, donc l'utilisation du stockage clé-valeur réduira la quantité de code supplémentaire dont vous avez besoin pour transformer les données.
L'entrepôt de données est bon marché et facile à intégrer aux services Web de votre fournisseur.
Votre principale préoccupation est l'évolutivité élevée à la demande.

Cependant, au moment de prendre votre décision, gardez à l'esprit les limites de bases de données spécifiques et les risques que vous rencontrerez si vous choisissez d'utiliser des bases de données non relationnelles.

Pour toutes les autres exigences, il vaut mieux choisir le bon vieux SGBD relationnel. Alors sont-ils condamnés ? Bien sûr que non. Au moins pour l'instant.

1 - à mon avis, le terme "structure de données" est plus approprié ici, mais a laissé le modèle de données d'origine.
2 - très probablement, l'auteur voulait dire qu'en termes de capacités, les bases de données non relationnelles sont inférieures aux bases de données relationnelles.
3 - les données sont peut-être déjà obsolètes, l'article est daté de février 2009.

Ajouter des balises

Modèle relationnel

Le modèle de base de données relationnelle a été proposé en 1969 par E.F. Codd (E.F. Codd). Pour quelques informations d'introduction sur les bases de données relationnelles, voir l'article de présentation " BD et SGBD"2. Puisqu'à l'heure actuelle ce sont les bases de données relationnelles qui sont dominantes, dans cet article (ainsi que dans les articles" Description des données”, “Traitement de l'information" et " Conception de base de données« 2) les concepts les plus essentiels du modèle relationnel sont examinés en détail.

Immédiatement, nous notons que la théorie des bases de données relationnelles a été formulée à l'origine dans un langage mathématique rigoureux, et ce sont des concepts mathématiques rigoureux et formellement définis qui décrivent le mieux l'essence des choses. En même temps, dans la plupart des cas, il est possible, sans trop de dégâts, de sacrifier la rigueur terminologique au profit de la transparence de la présentation, ce que nous essaierons de faire.

L'idée de base derrière le modèle relationnel est la suivante. La base de données se compose d'un certain nombre de les tables(dans le cas le plus simple - à partir d'une table). Les tableaux peuvent être manipulés par des opérations non procédurales (déclaratives) - demandes, dont les résultats sont également des tableaux.

Souvent le mot « relationnel » ( relationnel) dans le terme « modèle relationnel » est interprété en fonction du fait que des liens sont établis dans une base de données relationnelle ( relater) entre les tables. Cette explication est commode, mais pas précise. DANS système d'origine Termes Codd termes de communication ( rapports), les attributs ( les attributs) et des tuples ( tuples) ont été utilisés là où la plupart d'entre nous utilisent les termes plus familiers tableaux, colonnes (champs) et lignes (enregistrements).

Lors de la construction d'un modèle infologique du domaine (voir " BD et SGBD”, “Conception de base de données”2) se démarquer entités(objets), ils sont décrits Propriétés a (caractéristiques, attributs) qui sont significatifs à des fins de modélisation, et les relations entre les entités sont établies. Au stade de la transition d'un modèle relationnel infologique à un modèle relationnel datalogique, les tableaux apparaissent exactement. En règle générale, chaque entité est représentée par une table. Chaque ligne de la table (un enregistrement) correspond à une instance de l'entité, et chaque champ décrit une propriété (attribut).

Par exemple, si nous devons stocker des informations sur des personnes, y compris le nom de famille de chacun, le prénom, le patronyme, le TIN, le pays de résidence et la date de naissance, alors l'entité est exactement la personne et les données spécifiées sont des attributs. L'entité elle-même devient naturellement le nom de la table.

Tableau "Personne"

Le modèle relationnel exige que chaque ligne du tableau soit unique, c'est-à-dire de sorte que deux lignes diffèrent par la valeur d'au moins un attribut.

La forme tabulaire traditionnelle est utile lorsque vous devez présenter les données elles-mêmes. Si, comme dans l'exemple ci-dessus, vous êtes seulement intéressé par structure- les noms de champs, puis du point de vue de la clarté, de la facilité d'utilisation dans les diagrammes et du gain de place, il est plus commode de le représenter comme suit :

Clés

Clé les tablesest un champ ou un groupe de champs contenant des valeurs uniques au sein de cette table... La clé identifie de manière unique la ligne correspondante dans la table. Si la clé est constituée d'un champ, elle est souvent appelée Facile si sur plusieurs - composite... Dans l'exemple ci-dessus, la clé est le champ TIN (nous considérons qu'il est connu que les TIN sont uniques dans le pays).

Regardons un exemple de table avec une clé composite. Il n'est pas rare que les sites de prévisions météorologiques présentent les informations de la manière suivante : pour chaque date, la température prévue est indiquée la nuit, le matin, l'après-midi et le soir. Pour le stockage les informations spécifiées vous pouvez utiliser un tableau comme celui-ci :

Dans ce tableau, ni le champ Date, ni l'Heure du jour, ni la Température ne sont des clés - les valeurs peuvent être répétées dans chacun de ces champs. Mais la combinaison des champs Date + Heure du jour est unique et définit de manière unique une ligne de table. C'est la clé composée.

Souvent, il y a une situation dans laquelle le choix d'une clé n'est pas sans ambiguïté. Revenons au premier exemple. Supposons qu'en plus du nom, prénom, patronyme, NIF, date de naissance, il soit nécessaire de mémoriser la série et le numéro du passeport civil et la série et le numéro du passeport étranger. Le tableau ressemblera à ceci.

Il y a jusqu'à trois touches parmi lesquelles choisir dans ce tableau. L'un d'eux est simple (TIN), les deux autres sont composites (Série + Numéro de passeport civil et Série + Numéro de passeport étranger). Dans une telle situation, le développeur choisit la clé la plus commode du point de vue de l'organisation de la base de données (dans le cas général, la clé dont la recherche de la valeur prend le moins de temps). La clé choisie dans ce cas est souvent appelée le maître, ou primaire, une clé et d'autres combinaisons de colonnes à partir desquelles une clé peut être créée sont possible, ou des touches alternatives. Notez qu'il y a toujours au moins une clé possible dans la table, car les lignes ne peuvent pas être répétées et, par conséquent, la combinaison de toutes les colonnes est garantie d'être une clé possible.

Lors de l'affichage des tableaux clés primaires les tables sont généralement allouées. Par exemple, les champs pertinents sont souvent soulignés. MAIS Microsoft Access met en évidence les champs clés en gras.

Plus souvent encore qu'en cas d'ambiguïté dans le choix d'une clé, les développeurs sont confrontés à l'absence de clé parmi les données à stocker. Un fait similaire peut être établi dans le processus d'analyse du domaine. Par exemple, si vous devez stocker une simple liste de personnes - prénoms, noms, patronymes et dates de naissance, alors il n'y a aucune clé dans cet ensemble d'attributs - une situation est envisageable lorsque deux personnes différentes ont les mêmes données complètement. Dans ce cas, vous devez saisir artificiellement un champ supplémentaire, par exemple un numéro de personne unique. Une telle clé est parfois appelée dans la littérature substitut... Assez souvent, une clé de substitution est également introduite pour des raisons d'efficacité. Si, par exemple, une table a une longue clé composite, les développeurs introduisent souvent une courte clé de substitution numérique supplémentaire et en font la clé principale. Souvent, ils le font même s'il y a clé simple qui a un type de données « incommode » (inefficace pour la recherche), par exemple, une chaîne. De telles opérations ne sont plus liées à la théorie, mais elles sont assez courantes dans la pratique.

Le lecteur attentif remarquera probablement que la clé peut presque toujours être étendue (à moins qu'elle n'inclue tous les champs de la table) en incluant des champs redondants. Formellement, une telle clé restera une clé, mais d'un point de vue pratique, ce n'est qu'un jeu de concepts. De telles clés ne sont même pas considérées comme possibles, car il faut toujours s'efforcer de minimiser la longueur (complexité) de la clé.

Formes normales, normalisation

Toutes les tables que nous pouvons dessiner sur papier ou dans Word ne peuvent pas être une table de base de données relationnelle. Et toutes les tables pouvant être utilisées dans une base de données relationnelle ne sont pas correctes en termes d'exigence de modèle relationnel.

tout d'abord, exige que toutes les données d'une colonne soient du même type(pour les types, voir“Description des données”2). De ce point de vue, l'exemple ci-dessous n'a même pas de sens à discuter :

En deuxième, nécessite que la table se voit attribuer une clé primaire.

Ces exigences sont nécessaires, mais pas suffisantes. La théorie des bases de données relationnelles introduit le concept de "formes normales" - des exigences pour organiser les données dans des tableaux. Les formulaires normaux sont numérotés de manière séquentielle à mesure que les exigences deviennent plus strictes. Dans une base de données correctement conçue, les tables sont au moins sous la troisième forme normale. En conséquence, nous considérerons les trois premières formes normales. Rappelons que nous avons affaire à des tables qui satisfont aux deux exigences de base formulées ci-dessus.

Première forme normale (1NF)

La première forme normale dicte que toutes les données contenues dans la table doivent être atomiques(indivisible). La liste des types de données atomiques correspondants est déterminée par le SGBD. L'exigence 1NF est tout à fait naturelle. Cela signifie que chaque champ de chaque enregistrement ne doit contenir qu'une seule valeur, pas un tableau ou toute autre structure de données. Donnons un exemple significatif d'une table qui n'est pas en 1NF. Supposons que nous ayons des listes de notes d'étudiants dans une certaine matière.

La valeur du champ Evaluation n'étant pas atomique, la table ne répond pas aux exigences de 1NF.

O voie possible la présentation de la liste des notes est écrite dans les directives de l'article "Conception de la base de données" 2.

Deuxième forme normale (2NF)

Une table est dite en seconde forme normale si elle est en 1NF et que chaque colonne non-clé dépend complètement de la clé primaire. En d'autres termes, la valeur de chaque champ doit être complètement déterminée par la valeur de la clé primaire. Il est important de noter que la dépendance vis-à-vis de la clé primaire s'entend précisément comme la dépendance vis-à-vis de la clé dans son ensemble, et non de son composant séparé (dans le cas d'une clé composite). Voici un exemple de table qui n'est pas en 2NF. Pour ce faire, reprenons l'exemple de la météo et ajoutons une autre colonne au tableau - l'heure du lever du soleil (c'est un exemple tout à fait plausible, ce genre d'information est souvent donnée sur les sites de météo).

Comme on s'en souvient, cette table a une clé composite Date + Heure. Le champ Température dépend entièrement de la clé primaire - il n'y a aucun problème avec cela. Mais le champ Lever du soleil ne dépend que du champ Date.L'heure de la journée n'affecte pas naturellement l'heure du lever du soleil.

Ici, il convient de se poser la question : quel est le sens pratique de 2NF ? A quoi servent ces restrictions ? Il s'avère - grand. Disons que dans l'exemple ci-dessus, le développeur ignore les exigences 2NF. Premièrement, la soi-disant redondance- stockage de données inutiles. Après tout, si l'heure du lever du soleil est déjà stockée pour un enregistrement avec une date donnée, alors pour tous les autres enregistrements avec une date donnée, elle devrait être la même et, en règle générale, il n'est pas nécessaire de la stocker.

Faisons attention aux mots « devrait être ». Et sinon? En effet, au niveau de la base de données, cela n'est en aucun cas contrôlé - la clé dans la table est composite, les dates peuvent être les mêmes (et seront très probablement dans le sens). Et aucune restriction formelle (et notre compréhension que « cela ne peut pas être » ne s'applique pas à cela) n'interdit pas de spécifier des heures de lever de soleil différentes pour la même date.

Troisième forme normale (3NF)

Une table est dite en 3NF si elle correspond à 2NF et que toutes les colonnes non clés sont mutuellement indépendantes.

Il est commode de comprendre l'interdépendance des colonnes comme suit : les colonnes sont interdépendantes si vous ne pouvez pas changer l'une d'elles sans changer l'autre.

Donnons un exemple de table qui n'est pas en 3NF. Prenons un exemple simple carnet pour stocker les téléphones résidentiels de personnes vivant, éventuellement, dans différentes régions du pays.

Dans ce tableau, il existe une relation entre les colonnes non-clés City et City Code, par conséquent, le tableau n'est pas en 3NF.

Notez que le développeur détermine la présence de la dépendance ci-dessus en analysant le domaine - une telle collision ne peut être vue par aucune méthode formelle. Lorsque vous modifiez les propriétés du domaine, la dépendance entre les colonnes peut disparaître. Par exemple, si des codes différents sont saisis au sein d'une même ville (comme 495 et 499 à Moscou), les colonnes correspondantes ne sont plus associées en termes de violation des exigences de la 3NF.

Dans la théorie des bases de données relationnelles, des formes d'ordres supérieurs sont également considérées - la forme normale de Boyes - Codd, 4NF, 5NF et même supérieur. Ces formulaires n'ont pas une grande importance pratique et les développeurs, en règle générale, s'arrêtent toujours à 3NF.

Normalisation de la base de données

La normalisation est le processus de conversion des tables de la base de données en une forme normale choisie. La normalisation à 2NF, en règle générale, se résume à la décomposition - à la division d'une table en plusieurs. La normalisation à 3NF peut généralement être effectuée en supprimant les colonnes dépendantes (calculées). Dans certains cas, lors de la normalisation en 3NF, vous devez également effectuer une décomposition.

Bases de données multi-tables, relations entre tables, clés étrangères

En pratique, les bases de données à table unique sont assez rares, car du point de vue de la modélisation d'une base de données de domaine, la présence d'une table signifie la présence d'une entité. À son tour, la présence de plusieurs entités signifie généralement la présence de relations entre elles.

Sans avoir l'intention de concevoir une base de données complète, considérons un exemple qui vous permet de démontrer les relations dans des bases de données multi-tables.

Supposons que nous ayons affaire à une école qui a des élèves regroupés par niveau et des enseignants qui enseignent certaines matières. On distingue d'emblée quatre entités : les élèves, les enseignants, les classes et les matières. Ces entités nous donnent déjà quatre tableaux.

Ensuite, nous devons résoudre le problème des attributs d'entité - quel type d'informations nous allons stocker. Étant donné que notre exemple est uniquement à des fins de démonstration, nous essaierons de minimiser la quantité d'informations stockées. Nous nous engageons à conserver le nom et le prénom pour chaque élève, pour la classe - le numéro du parallèle et la lettre qui identifie la classe à l'intérieur du parallèle, pour l'enseignant - le nom, prénom et patronyme, pour la matière - uniquement son Nom.

Maintenant, nous devons traiter le problème de la clé primaire. Les tables des étudiants et des enseignants, en principe, n'ont pas de clé, nous y entrerons donc une clé numérique de substitution - un nombre. Les tables de classes et d'éléments ont généralement des clés. Dans la table des classes, la clé est composite, elle est formée par les attributs Parallel Number + Letter, et dans la table des objets, une clé simple consiste en un seul champ - le nom de l'objet. Rappelez-vous que lorsque nous avons parlé des clés, nous avons mentionné que clés de substitution sont souvent ajoutés pour des raisons d'efficacité, en essayant de se débarrasser des clés composites ou des champs clés de types gênants, tels que des chaînes. C'est ce que nous allons faire. Ajoutons une clé numérique de substitution à chacune des tables.

En conséquence, nous obtiendrons l'ensemble de tables suivant correspondant aux entités décrites.

En comprenant de quel domaine nous traitons, nous savons que nos entités n'existent pas par elles-mêmes - elles sont reliées par certaines des relations que nous avons décrites ci-dessus. Mais comment les connecter techniquement ? Vous ne pouvez pas vous passer d'introduire des champs supplémentaires et même des tables supplémentaires. Traitons les relations entre les entités dans l'ordre.

Pour affecter un étudiant à une certaine classe, nous ajouterons un champ supplémentaire Numéro de classe dans le tableau « Etudiant ». (Il est clair que son type doit complètement coïncider avec le type du champ Numéro de classe dans la table "Classe".) Nous pouvons maintenant lier les tables "Elève" et "Classe" en faisant correspondre les valeurs des champs Numéro de classe ( nous n'avons pas accidentellement nommé ces champs de la même manière, en pratique, cela est souvent fait pour naviguer facilement dans les champs de liaison). Notez qu'un enregistrement dans la table "Classe" peut correspondre à plusieurs enregistrements dans la table "Elève" (et en pratique cela correspond très probablement - il est difficile d'imaginer une classe avec un seul élève). De telles tables sont dites liées par la relation " un à plusieurs”. Et le champ Numéro de classe dans la table "Étudiant" s'appelle clé étrangère... Comme vous pouvez le voir, le but des clés étrangères est de lier des tables. Notez que la clé étrangère fait toujours référence à la clé primaire de la table associée (c'est-à-dire que la clé étrangère est du côté « plusieurs »). La clé primaire associée est appelée parent bien que ce terme soit moins utilisé.

Illustrons ce qui a été dit avec un schéma à la manière de Microsoft Access (pour plus d'informations sur l'Access Data Scheme, voir l'article "Description des données" 2).

Pensons maintenant aux enseignants et aux matières. En analysant le domaine (c'est le seul moyen - après tout, le véritable état des choses ne peut pas être extrait du modèle formel lui-même), nous remarquons que le type de connexion entre les entités "enseignant" et "sujet" est différent de celui discuté ci-dessus. Après tout, non seulement une matière peut être enseignée par plusieurs enseignants, mais un seul enseignant peut enseigner plusieurs matières. Ainsi, il existe un lien entre ces entités » plusieurs à plusieurs”. L'introduction de champs supplémentaires ne suffit plus (essayez-le !). Les relations plusieurs-à-plusieurs sont toujours résolues en introduisant une table supplémentaire. A savoir, nous organiserons la table « Enseignant-Sujet », qui a la structure suivante :

Tableau "Professeur-Sujet"

Cette table a une clé composite formée de deux de ses champs. La table « Enseignant » et la table « Sujet » sont liées à cette table dans une relation un-à-plusieurs (bien sûr, dans les deux cas, « plusieurs » sont du côté « Enseignant-Sujet »). Ainsi, il existe deux clés étrangères dans la table « Enseignant-Sujet » (toutes deux faisant partie d'une clé primaire composite, ce qui n'est pas interdit) qui servent à faire le lien avec les tables correspondantes.

En pratique, en plus des relations considérées "un-à-plusieurs" et "plusieurs-à-plusieurs", il y a aussi la relation " Un par un”. Du point de vue théorique, une telle relation n'a pas d'intérêt, puisque deux tables reliées par une relation un à un peuvent toujours être simplement combinées en une seule. Cependant, dans les bases de données réelles, une relation un-à-un est utilisée pour optimiser le traitement des données. Illustrons ce qui a été dit avec un exemple.

Disons que nous stockons beaucoup d'informations diverses sur les personnes - les données de leurs divers documents, numéros de téléphone, adresses, etc. Très probablement, la plupart de ces données seront très rarement utilisées. Et souvent, nous n'avons besoin que d'un nom de famille, d'un nom, d'un patronyme et d'un numéro de téléphone. Ensuite, il est logique d'organiser les deux tables et de les lier dans une relation un-à-un. Stockez les informations fréquemment utilisées dans un (petit) tableau et le reste dans un autre. Naturellement, les tables dans une relation un-à-un ont la même clé primaire.

Règles d'intégrité

Le modèle relationnel définit deux règles générales Intégrité de la base de données : intégrité des objets et intégrité référentielle.

Règle d'intégrité objets très simple. Il nécessite que les clés primaires des tables ne contiennent pas de valeurs nulles.

Règle d'intégrité référentielle exige que les clés étrangères ne contiennent pas de valeurs incohérentes avec les clés parentes... En revenant à l'exemple ci-dessus, nous devons exiger, par exemple, que les élèves appartiennent uniquement à la classe dont le nombre est répertorié dans le tableau « Classes ».

La plupart des SGBD savent surveiller l'intégrité des données (bien sûr, cela nécessite des efforts appropriés de la part du développeur au stade de la description des structures de données). En particulier, des mécanismes sont utilisés pour maintenir l'intégrité référentielle en cascade opérations. La cascade signifie notamment que lorsqu'un enregistrement est supprimé d'une table « parent », liée à une autre table dans une relation un-à-plusieurs, tous les enregistrements liés sont automatiquement supprimés de la table « plusieurs » (par le SGBD lui-même, sans intervention de l'utilisateur). Et c'est naturel, car de tels enregistrements "suspendent en l'air", ils ne sont plus liés à rien.

Indexage

L'indexation est extrêmement importante du point de vue application pratique, mais une chose facultative du point de vue de la théorie pure. L'objectif principal de l'indexation est d'optimiser (accélérer) la recherche (et, par conséquent, certaines autres opérations avec la base de données). L'indexation nécessite dans tous les cas des ressources supplémentaires (au niveau physique, des fichiers d'index spéciaux sont le plus souvent créés). Les opérations liées à la modification des données, l'indexation peuvent même ralentir, par conséquent, les index sont généralement des tables rarement modifiées, qui sont souvent recherchées.

Le fichier d'index est très similaire à l'index d'un livre ordinaire. Pour chaque valeur d'index, une liste de lignes de table contenant la valeur donnée est stockée. Par conséquent, vous n'avez pas besoin de parcourir toute la table pour effectuer une recherche - vous avez juste besoin de consulter l'index. Cependant, la modification des enregistrements peut nécessiter la reconstruction de l'index. Et cela prend du temps supplémentaire.

Bien entendu, il n'est pas question de présenter la théorie des bases de données relationnelles dans le cadre de cours de base informatique ! Néanmoins, cet article est très important pour notre encyclopédie, car dans ce cas, nous avons affaire à du matériel qui ne peut pas être entièrement présenté dans les leçons, mais l'enseignant doit le posséder. Pourquoi?

D'abord parce qu'un certain nombre de notions sont étudiées uniquement dans le cadre du cours de base. Il s'agit à la fois d'une vue tabulaire des données et des clés de table. Et nous savons tous qu'il est très difficile d'énoncer correctement et précisément certains concepts sans présenter l'image générale.

Deuxièmement, en jouant avec des enfants requêtes simples aux bases de données (le matériel pertinent est présenté dans l'article "Traitement de l'information" 2), il faut traiter des tableaux qui sont corrects du point de vue de la théorie relationnelle. Il n'est pas nécessaire d'expliquer aux élèves que ces tableaux sont corrects, mais « si…, le tableau serait faux », mais il est inacceptable d'utiliser de mauvais exemples.

Dans un cours spécialisé en informatique, la situation peut être fondamentalement différente. La forme de travail la plus importante et la plus productive dans les classes spécialisées est le design. Dans le cadre de projets pédagogiques, il est possible et nécessaire de développer des bases de données simples, et ici on ne peut se passer des fondements de la théorie énoncée. Cependant, les éléments suivants doivent être pris en compte :

Les domaines à modéliser ne doivent pas être trop grands ;

Les élèves doivent les connaître très bien (en ce sens, le projet « École », qui est assez ennuyeux pour tout le monde, n'est pas le pire choix !) ;

Il est naïf de s'attendre à ce qu'après avoir écouté les principes fondamentaux de la théorie, les étudiants soient capables de concevoir eux-mêmes quelque chose. Chaque étape doit être franchie avec eux, en donnant les raisons détaillées de leurs actions.