La structure de données dans le modèle relationnel est. Modèle de données relationnel

MODÈLES DE DONNÉES

Les données stockées dans la base de données ont une certaine structure logique et sont décrites par un certain modèle de représentation de données (modèle de données) pris en charge par le SGBD. Les modèles de données suivants sont des classiques:

· Hiérarchique;

· Réseau;

· Relationnel.

De plus, ces dernières années, les modèles de données suivants sont apparus et sont devenus plus activement mis en œuvre dans la pratique:

Post-relationnel,

Multidimensionnel,

· Orienté objet.

Divers systèmes sont également en cours de développement sur la base d'autres modèles de données qui étendent les modèles connus. Ceux-ci incluent des modèles relationnels, déductifs, orientés objet, sémantiques, conceptuels et orientés. Certains de ces modèles servent à intégrer des bases de données, des bases de connaissances et des langages de programmation. Certains SGBD prennent en charge plusieurs modèles de données en même temps.

2.1. Modèle de données hiérarchique

Dans un modèle hiérarchique, les données peuvent être décrites à l'aide d'un graphe ordonné (ou d'un arbre). Une représentation simplifiée des relations entre les données dans un modèle hiérarchique est illustrée à la Fig. 2.1.

Figure: 2.1. Représentation des relations dans un modèle hiérarchique

Le type de données d'arborescence est utilisé pour décrire la structure (schéma) d'une base de données hiérarchique dans un certain langage de programmation.

Le type d'arborescence est similaire au type de données d'enregistrement Pascal. L'imbrication de types est autorisée, chacun étant à un certain niveau.

Le type d'arbre est composite. Il comprend des sous-types («sous-arbres»), dont chacun, à son tour, est un type d '«arbre». Chacun des types d'arbres se compose d'un seul type racine et d'un ensemble ordonné de types subordonnés (éventuellement vides). Chacun des types primitifs inclus dans le type d'arborescence est un type d'enregistrement simple ou composite. Un "enregistrement" simple se compose d'un type, tel que numérique. Un "enregistrement" composite combine un ensemble de types, par exemple un entier, une chaîne de caractères et un pointeur (lien). Un exemple du type "arbre" en tant que collection de types est illustré à la Fig. 2.2.

Kornevappelé un type qui a des sous-types et n'est pas lui-même un sous-type. Type d'esclave (sous-type) est un descendant d'un type qui agit comme un ancêtre (parent) pour lui. Les descendants du même type sont des jumeaux les uns par rapport aux autres.

En général, le type d'arborescence est un ensemble hiérarchisé de types d'enregistrement.

Figure: 2.2. Exemple de type "arbre"

Une base de données hiérarchique est une collection ordonnée d'instances de données de type arborescence (arborescences) contenant des instances de type enregistrement (enregistrements). Souvent, la relation entre les types est transférée à la relation entre les enregistrements eux-mêmes. Les champs d'enregistrement stockent les valeurs numériques ou symboliques réelles qui constituent le contenu principal de la base de données. La traversée de tous les éléments d'une base de données hiérarchique se fait généralement de haut en bas et de gauche à droite.

Dans un SGBD hiérarchique, une terminologie peut être utilisée qui diffère de celle donnée. Par exemple, un enregistrement peut être appelé un segment, et un enregistrement de base de données peut être compris comme l'ensemble complet d'enregistrements liés à une instance du type «arborescence».

Les données de la base de données avec le schéma donné (Fig.2.2.) Peuvent ressembler, par exemple, à la figure 2.3.

Figure: 2.3. Données dans une base de données hiérarchique

Les groupes de méthodes suivants peuvent être utilisés pour organiser le placement physique des données hiérarchiques dans la mémoire de l'ordinateur:

· Représentation par une liste linéaire avec allocation séquentielle de mémoire (arithmétique d'adresse, structures de liste de gauche);

· Représentation par listes linéaires liées (méthodes utilisant des pointeurs et des références).

Les principales opérations de manipulation de données organisées hiérarchiquement sont les suivantes:

· Rechercher l'instance de base de données spécifiée (par exemple, une arborescence avec la valeur 912 dans le champ Group_Code);

· Transition d'un arbre à un autre;

· Transition d'un enregistrement à un autre dans l'arborescence (par exemple, à l'enregistrement suivant du type Etudiants);

· Insertion d'un nouvel enregistrement à la position spécifiée;

· Suppression de l'enregistrement actuel, etc.

Conformément à la définition du type "arbre", on peut conclure que le contrôle de l'intégrité des liens est automatiquement maintenu entre ancêtres et descendants. La règle principale du contrôle d'intégrité est formulée comme suit: un enfant ne peut pas exister sans un parent et certains parents peuvent ne pas avoir d'enfants. Il n'existe aucun mécanisme pour maintenir l'intégrité des liens entre les enregistrements de différents arbres.

Les avantages du modèle de données hiérarchique comprennent une utilisation efficace de la mémoire informatique et de bons indicateurs de performance pour les opérations de base sur les données. Le modèle de données hiérarchique est pratique pour travailler avec des informations hiérarchisées.

L'inconvénient du modèle hiérarchique est sa lourdeur à traiter des informations avec des connexions logiques assez complexes, ainsi que la complexité de la compréhension pour un utilisateur ordinaire.

Un nombre relativement limité de SGBD est basé sur un modèle de données hiérarchique, comprenant les systèmes étrangers IMS, PS / Focus, Team-Up, Data Edge, ainsi que les systèmes nationaux Oka, INES, MIRIS.

2.2. Modèle de réseau

Le modèle de données réseau vous permet d'afficher diverses relations d'éléments de données sous la forme d'un graphique arbitraire, généralisant ainsi le modèle de données hiérarchique (Fig. 2.4). Le concept le plus complet de bases de données en réseau a été présenté pour la première fois dans les propositions du groupe KODASYL.

Pour décrire le schéma de la base de données réseau, des groupes de types sont utilisés: "record" et "link". Le type de lien est défini pour deux types d'enregistrement: ancêtre et descendant. Variables de type "Lien" sont des instances de liens.

Se compose d'étudiants

Dirigé par le chef

Figure: 2.5. Exemple de schéma de base de données réseau

Dans divers SGBD type de réseau des termes différents peuvent être utilisés pour désigner des concepts essentiellement identiques. Par exemple, comme des éléments de données et des agrégats, des enregistrements, des ensembles, des zones, etc.

Le placement physique des données dans des bases de données de type réseau peut être organisé en utilisant presque les mêmes méthodes que dans les bases de données hiérarchiques.

Les opérations les plus importantes pour manipuler les données des bases de données de type réseau sont les suivantes:

Rechercher un enregistrement dans la base de données,

Transition d'ancêtre en premier descendant,

Transition de descendant à ancêtre,

Créer un nouveau record,

Suppression de l'enregistrement actuel,

Mise à jour de l'enregistrement actuel,

Inclusion de l'enregistrement dans la communication,

Exclusion d'un enregistrement de la communication,

· Changement de connexions, etc.

Dignité modèle de réseau les données sont la possibilité d'une mise en œuvre efficace en termes de temps et d'efficacité. En comparaison avec le modèle hiérarchique, le modèle de réseau offre de grandes opportunités dans le sens de l'admissibilité de la formation de connexions arbitraires.

Désavantagele modèle de données de réseau est la complexité et la rigidité élevées du schéma de base de données, construit sur sa base, ainsi que la complexité de la compréhension et de l'exécution des opérations de traitement des données dans la base de données pour les utilisateurs ordinaires. De plus, dans le modèle de données réseau, le contrôle de l'intégrité des liens est affaibli du fait de l'admissibilité de l'établissement de liens arbitraires entre les enregistrements.

Les systèmes basés sur le modèle de réseau ne sont pas largement utilisés dans la pratique. Les SGBD réseau les plus connus sont les suivants: IDMS, db_VistaIII, NETWORK, CETOR et KOMPAS.

2.3. Modèle relationnel

Le modèle de données relationnelles a été suggéré par un employé iBM Edgar Codd et est basé sur le concept de relation (relation).

Attitude est un ensemble d'éléments appelés tuples. Base théorique détaillée modèle relationnel discuté dans la section suivante. Une forme visuelle de représentation d'une relation est un tableau bidimensionnel familier à la perception humaine.

Le tableau comporte des lignes (enregistrements) et des colonnes (colonnes). Chaque ligne du tableau a la même structure et se compose de champs. Les lignes du tableau correspondent aux tuples et les colonnes aux attributs de la relation.

En utilisant un seul tableau, il est pratique de décrire des informations sur des groupes d'objets homogènes (ayant les mêmes propriétés), des phénomènes ou des processus dans le monde réel. Chaque ligne du tableau contient des informations sur un objet, un phénomène ou un processus spécifique. Une chaîne (enregistrement) a la même structure et décrit les propriétés des objets à l'aide de champs. Par exemple, un tableau peut contenir des informations sur un groupe de stagiaires, sur chacun desquels sont connues les caractéristiques suivantes: nom, prénom et patronyme, sexe, date de naissance, adresse de résidence. Puisqu'il n'est pas possible de décrire toutes les données du domaine dans un même tableau, plusieurs tableaux sont créés, entre lesquels des liens sont établis.

Placement physique des données dans des bases de données relationnelles sur média externe facilement fait avec des fichiers normaux.

Avantages le modèle de données relationnelles réside dans la simplicité, la clarté et la commodité de la mise en œuvre physique sur un ordinateur. C'est la simplicité et la clarté pour l'utilisateur qui sont la raison principale de leur utilisation généralisée.

Le principal désavantages les modèles relationnels sont les suivants: outils standards l'identification des enregistrements individuels et la complexité de la description des relations hiérarchiques et de réseau.

Exemples de SGBD relationnels: dBaseIIIPlus dBaseIV (Ashton-Tate), DB2 (IBM), R: BASE (Microrim), FoxPro premières versions et FoxBase (Fox Software), Paradox et dBASE pour les fenêtres (Borland), plus tard FoxPro, Visual FoxPro et Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer System) et Oracle (Oracle).

Les versions récentes des SGBD relationnels ont certaines des propriétés des systèmes orientés objet. Un tel SGBD est souvent appelé objet-relationnel. Oracle 8.x est un exemple d'un tel système.

2.4. Modèle post-relationnel

Le modèle relationnel classique suppose l'indivisibilité des données stockées dans les champs des enregistrements de table. Cela signifie que les informations du tableau sont présentées sous la première forme normale. Il existe un certain nombre de cas où cette limitation empêche une mise en œuvre efficace de l'application.

Le modèle de données post-relationnel est un modèle relationnel étendu qui supprime la contrainte d'indivisibilité des données stockées dans les enregistrements de table. Le modèle de données post-relationnel autorise des champs à valeurs multiples - des champs dont les valeurs sont constituées de sous-valeurs. L'ensemble de valeurs des champs à valeurs multiples est considéré comme une table indépendante, intégrée dans la table principale.

En figue. 2.6 en utilisant l'exemple des informations sur les factures et les marchandises à des fins de comparaison, la présentation des mêmes données à l'aide de modèles relationnels (a) et post-relationnels (b) est présentée. Le tableau Factures contient des informations sur les numéros de facture et les numéros de client. La table Invoice_Goods contient des informations sur chacune des factures: numéro de facture, nom de l'article et quantité de l'article. La table Factures est liée à la table Invoices_Products par le champ Numéro de facture.

Comme on peut le voir sur la figure, en comparaison avec le modèle relationnel, le modèle post-relationnel stocke les données plus efficacement et, pendant le traitement, il n'est pas nécessaire d'effectuer l'opération de jonction des données de deux tables.

En plus de l'imbrication des champs, le modèle post-relationnel prend en charge les champs à plusieurs valeurs associés (plusieurs groupes). L'ensemble des champs associés est appelé une association. Dans ce cas, dans une ligne, la première valeur d'une colonne de l'association correspond aux premières valeurs de toutes les autres colonnes de l'association. Toutes les valeurs de la deuxième colonne sont liées de la même manière, et ainsi de suite.

L'exigence de constance n'est pas imposée sur la longueur des champs et le nombre de champs dans les enregistrements de table. Cela signifie que la structure des données et des tableaux est très flexible.

Aérien

Overhead_Products

Aérien

Figure: 2.6. Structures de données de modèles relationnels et post-relationnels

Étant donné que le modèle post-relationnel permet de stocker des données non normalisées dans des tables, il existe un problème pour garantir l'intégrité et la cohérence des données. Ce problème est résolu en incluant des mécanismes dans le SGBD qui sont similaires aux procédures stockées dans les systèmes client-serveur.

Pour décrire les fonctions de contrôle des valeurs dans les champs, il est possible de créer des procédures (codes de conversion et codes de corrélation) qui sont automatiquement appelées avant et après l'accès aux données. Les codes de corrélation sont exécutés immédiatement après la lecture des données, avant de les traiter. Inversement, les codes de conversion sont exécutés après le traitement des données.

L'avantage du modèle post-relationnel est la possibilité de représenter un ensemble de tables relationnelles liées par une table post-relationnelle. Cela permet une grande visibilité de la présentation de l'information et une augmentation de l'efficacité de son traitement.

L'inconvénient du modèle post-relationnel est la complexité de résoudre le problème d'assurer l'intégrité et la cohérence des données stockées.

Le modèle de données post-relationnel considéré est pris en charge par les SGBD uniVers, Bubba, Dasdb.

2.5. Modèle multidimensionnel

Une approche multidimensionnelle de la représentation des données dans une base de données est apparue presque simultanément avec une approche relationnelle, mais jusqu'à présent, il y avait très peu de SGBD multidimensionnels fonctionnels (MSUBMS). Depuis le milieu des années 90, l'intérêt pour eux a commencé à acquérir un caractère massif.

L'impulsion en 1993 fut un article programmatique de l'un des fondateurs de l'approche relationnelle, E. Codd. Il formule 12 exigences de base pour les systèmes de la classe OLAP (OnLine Analytical Processing), dont les plus importantes sont associées aux possibilités de représentation conceptuelle et de traitement de données multidimensionnelles. Les systèmes multidimensionnels vous permettent de traiter rapidement les informations pour l'analyse et la prise de décision.

Lors de l'élaboration du concept de propriété intellectuelle, les deux directions suivantes peuvent être distinguées:

· Systèmes de traitement opérationnel (transactionnel);

· Systèmes de traitement analytique (systèmes de prise de décision).

Les SGBD relationnels étaient destinés aux systèmes d'information pour le traitement de l'information en ligne et étaient très efficaces dans ce domaine. Dans les systèmes de traitement analytique, ils se sont révélés quelque peu maladroits et pas assez flexibles. Les SGBD multidimensionnels sont ici plus efficaces.

SGBD multidimensionnelsont des SGBD hautement spécialisés conçus pour le traitement analytique interactif de l'information. Révélons les concepts de base utilisés dans ces SGBD: agrégabilité, historicité, prévisibilité des données.

Agrégabilité données signifie considérer l'information à différents niveaux de sa généralisation. DANS systèmes d'information le degré de détail dans la présentation des informations pour l'utilisateur dépend de son niveau: analyste, utilisateur-opérateur, manager, manager.

Historicité données implique d'assurer un niveau élevé de statique (immuabilité) des données elles-mêmes et de leurs interrelations, ainsi que l'obligation de relier les données au temps.

La nature statique des données permet d'utiliser des méthodes spécialisées de chargement, de stockage, d'indexation et de récupération pendant leur traitement.

La liaison de données temporelle est nécessaire pour l'exécution fréquente de requêtes qui ont des valeurs d'heure et de date dans l'exemple. La nécessité d'organiser les données dans le temps dans le processus de traitement et de présentation des données à l'utilisateur impose des exigences sur les mécanismes de stockage et d'accès aux informations. Ainsi, pour réduire le temps de traitement des demandes, il est souhaitable que les données soient toujours triées dans l'ordre dans lequel elles sont le plus fréquemment demandées.

Prévisibilité les données impliquent de définir des fonctions de prévision et de les appliquer à différents intervalles de temps.

La multidimensionnalité du modèle de données ne signifie pas la multidimensionnalité de la visualisation des données numériques, mais la représentation logique multidimensionnelle de la structure de l'information dans la description et dans les opérations de manipulation de données.

Par rapport au modèle relationnel, l'organisation multidimensionnelle des données a une visibilité et un contenu informationnel plus élevés.

Si un ça arrive sur un modèle multidimensionnel avec une dimension supérieure à deux, alors pas nécessairement visuellement l'information est présentée sous la forme d'objets multidimensionnels (hypercubes à trois, quatre et plus). Même dans ces cas, il est plus pratique pour l'utilisateur de traiter des tableaux ou des graphiques à deux dimensions. Dans le même temps, les données sont des «tranches» (plus précisément, des «tranches») d'un entrepôt de données multidimensionnel, réalisées avec des degrés de détail variables.

Examinons les concepts de base des modèles de données multidimensionnels, qui incluent la dimension et la cellule.

Dimension (Dimensiom) est un ensemble de données du même type qui forme l'une des faces d'un hypercube. Des exemples des dimensions de temps les plus couramment utilisées sont les jours, les mois, les trimestres et les années. Les villes, régions, régions et pays sont largement utilisés comme dimensions géographiques. Dans un modèle de données multidimensionnel, les dimensions agissent comme des indices pour identifier des valeurs spécifiques dans les cellules d'un hypercube.

Une cellule ou une mesure est un champ dont la valeur est déterminée de manière unique par un ensemble fixe de dimensions. Le type de champ est le plus souvent défini comme numérique. Selon la façon dont les valeurs d'une certaine cellule sont formées, il peut généralement s'agir d'une variable (les valeurs changent et peuvent être chargées à partir d'une source de données externe ou générées par programme) ou d'une formule (les valeurs, comme les cellules de formule dans une feuille de calcul, sont calculées à l'aide de formules prédéfinies).

Dans l'exemple de la Fig. 2,8 chaque valeur de cellule Volume de ventesest uniquement déterminé par la combinaison de la dimension temporelle (mois de vente) et du modèle de véhicule. Un exemple de modèle de données 3D est illustré à la Fig. 2.9.

1999

Petrov 9999999varoyoro

Volume de ventes

«Zhiguli» «Moskvich»

Des mesures:

Temps (année) - 1994, 1995, 1996

Directeur - Petrov, Smirnov, Yakovlev

Modèle - "Volga", "Zhiguli", "Moskvich"

Indicateur: volume des ventes

Figure: 2.9. Exemple de modèle 3D

Il existe deux principales options (schémas) pour organiser les données dans l'ISDBMS existant: hypercubique et polycubique.

Dans le schéma semi-cube, on suppose que plusieurs hypercubes de dimensions différentes et de différentes dimensions comme des visages. Oracle Express Server est un exemple de système prenant en charge une version polycubique d'une base de données.

Dans le cas d'une conception hypercube, toutes les mesures sont supposées être définies par le même ensemble de dimensions. Cela signifie que s'il existe plusieurs hypercubes DB, ils ont tous la même dimension et coïncident. Évidemment, dans certains cas, les informations de la base de données peuvent être redondantes (si le remplissage obligatoire des cellules est requis).

Dans le cas d'un modèle de données multidimensionnel, un certain nombre d'opérations spéciales sont appliquées, qui comprennent: "tranche", "rotation", agrégation et détails.

Une tranche est un sous-ensemble d'un hypercube résultant d'une ou plusieurs mesures. Le découpage est effectué pour limiter les valeurs utilisées par l'utilisateur, puisque toutes les valeurs de l'hypercube ne sont presque jamais utilisées simultanément. Par exemple, si vous limitez les valeurs de mesure Modèle de voiture dans un hypercube (Fig. 2.9) à la marque «Zhiguli», vous obtenez un tableau en deux dimensions des ventes de cette marque de voiture par différents gestionnaires par année.

L'opération Rotation est utilisée pour la représentation de données 2D. Son essence est de changer l'ordre des mesures dans la présentation visuelle des données. Ainsi, la "rotation" de la table bidimensionnelle représentée sur la figure 2.8b entraînera un changement dans son apparence de telle sorte que la marque de voiture sera sur l'axe X et le temps sur l'axe Y.

L'opération de "rotation" peut être généralisée au cas multidimensionnel, si elle est comprise comme une procédure de changement d'ordre des mesures. Dans le cas le plus simple, il peut s'agir d'une permutation mutuelle de deux dimensions arbitraires.

Les opérations «agrégation» (Drill Up) et «détaillant» (Drill Down) signifient respectivement une transition vers une présentation plus générale ou plus détaillée des informations à l'utilisateur à partir de l'hypercube.

Pour illustrer le sens de l'opération «agrégation», supposons que nous ayons un hypercube, dans lequel, en plus des dimensions de l'hypercube illustrées à la Fig. 2.9, il y a aussi des dimensions: Département, Région, Entreprise, Pays. Notez que dans ce cas, dans l'hypercube, il existe une hiérarchie (de bas en haut) des relations entre les dimensions: Responsable, Département, Région, Entreprise, Pays.

Laissons l'hypercube décrit définir avec quel succès en 2000 le directeur Petrov a vendu les voitures Zhiguli et Volga. Ensuite, en remontant d'un niveau dans la hiérarchie, à l'aide de l'opération «agrégation», vous pouvez découvrir à quoi ressemble le ratio de ventes des mêmes modèles au niveau du département où Petrov travaille.

Le principal avantage d'un modèle de données multidimensionnel est la commodité et l'efficacité du traitement analytique de grandes quantités de données temporelles. Lors de l'organisation du traitement de données similaires sur la base du modèle relationnel, il y a une augmentation non linéaire de l'intensité de travail des opérations en fonction de la dimension de la base de données et une augmentation significative des coûts mémoire vive pour l'indexation.

L'inconvénient du modèle de données multidimensionnel est sa lourdeur à résoudre les problèmes les plus simples du traitement opérationnel de l'information.

Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle), Cache (InterSystem) sont des exemples de systèmes prenant en charge des modèles de données multidimensionnels. Certains logiciels, par exemple Media / MR (Speedware), vous permettent de travailler simultanément avec des bases de données multidimensionnelles et relationnelles. Dans le SGBD Oracle, dans lequel le modèle de données interne est un modèle multidimensionnel, trois méthodes d'accès aux données sont implémentées: directe (au niveau des nœuds de matrice multidimensionnelle), objet et relationnelle.

2.6. Modèle orienté objet

Dans le modèle orienté objet, lors de la présentation des données, il est possible d'identifier des enregistrements de base de données individuels. Les relations sont établies entre les enregistrements de base de données et leurs fonctions de traitement en utilisant des mécanismes similaires à ceux des langages de programmation orientés objet.

Le modèle standardisé orienté objet est décrit dans les recommandations de la norme ODMG-93 (Object Database Management Group - Object-Oriented Database Management Group). Les recommandations ODMG-93 n'ont pas encore été pleinement mises en œuvre. Pour illustrer les idées clés, considérons un modèle quelque peu simplifié d'une base de données orientée objet.

Structure de base de données orientée objet peut être représenté graphiquement sous la forme d'un arbre dont les nœuds sont des objets. Les propriétés des objets sont décrites par certains type standard (par exemple, chaîne) ou un type construit par l'utilisateur (défini comme une classe).

La valeur d'une propriété de type string est une chaîne de caractères. La valeur d'une propriété de type class est un objet qui est une instance de la classe correspondante. Chaque instance d'une classe est considérée comme un descendant de l'objet dans lequel elle est définie comme propriété. Un objet d'instance d'une classe appartient à sa classe et a un seul parent. Les relations génériques dans la base de données forment une hiérarchie d'objets.

Un exemple de la structure logique d'une base de données de bibliothéconomie orientée objet est illustré à la Fig. 2.10.

Ici, un objet de type LIBRARY est le parent par exemple les objets des classes SUBSCRIBER, DIRECTORY et OUTPUT. Différents objets de type LIVRE peuvent avoir des parents identiques ou différents. Les objets de type LIVRE qui ont le même parent doivent différer au moins par le numéro d'inventaire (unique pour chaque exemplaire du livre), mais ont les mêmes valeurs pour les propriétés de chiffrement du livre, UDC, titre et auteur.

La structure logique d'une base de données orientée objet est extérieurement similaire à la structure d'une base de données hiérarchique. La principale différence entre eux réside dans les méthodes de manipulation des données.

Pour effectuer des actions sur les données dans le modèle de base de données considéré, des opérations logiques sont utilisées, renforcées par des mécanismes d'encapsulation, d'héritage et de polymorphisme orientés objet. Des opérations similaires aux commandes SQL peuvent être utilisées dans une mesure limitée (par exemple, pour créer une base de données).

La création et la modification de la base de données s'accompagnent de la formation automatique et de l'ajustement ultérieur d'index (tables d'index) contenant des informations pour une recherche rapide des données. Examinons brièvement les concepts d'encapsulation, d'héritage et de polymorphisme en relation avec le modèle de base de données orienté objet.

Encapsulation limite la portée du nom de propriété aux limites de l'objet dans lequel il est défini. Ainsi, si nous ajoutons une propriété qui définit le numéro de téléphone de l'auteur du livre et a le nom numéro de téléphone d'un objet de type DIRECTORY, alors nous obtenons les propriétés du même nom pour les objets SUBSCRIBER et DIRECTORY. La signification d'une telle propriété sera déterminée par l'objet dans lequel elle est encapsulée.

Héritageà l'inverse, étend la portée de la propriété à tous les descendants de l'objet. Ainsi, tous les objets de type BOOK descendants d'un objet de type DIRECTORY peuvent se voir attribuer les propriétés de l'objet parent: code livre, UDC, titre, auteur. S'il est nécessaire d'étendre l'effet du mécanisme d'héritage à des objets qui ne sont pas directement liés (par exemple, entre deux descendants du même parent), alors une propriété abstraite de type abs est définie dans leur ancêtre commun. Ainsi, la définition des propriétés abstraites ticket et number dans l'objet LIBRARY conduit à l'héritage de ces propriétés par tous les objets enfants SUBSCRIBER, BOOK et REFERENCE. Ce n'est pas un hasard si les valeurs du ticket de propriété des classes SUBSCRIBER et ISSUE montrées dans la figure seront les mêmes - 00015.

Le polymorphisme dans les langages de programmation orientés objet signifie la capacité du même code de programme à travailler avec différents types de données. En d'autres termes, cela signifie qu'il est permis d'avoir des méthodes (procédures ou fonctions) avec les mêmes noms dans des objets de types différents. Lors de l'exécution d'un programme objet, les mêmes méthodes opèrent sur des objets différents selon le type d'argument. Lorsqu'il est appliqué à notre base de données orientée objet, le polymorphisme signifie que les objets de la classe BOOK, ayant des parents différents de la classe DIRECTORY, peuvent avoir un ensemble de propriétés différent. Par conséquent, les programmes de travail avec des objets de la classe BOOK peuvent contenir du code polymorphe.La recherche dans une base de données orientée objet consiste à découvrir la similitude entre un objet spécifié par l'utilisateur et des objets stockés dans la base de données. Un objet défini par l'utilisateur, appelé objet objectif (la propriété d'objet est de type objectif), dans le cas général, peut être un sous-ensemble de toute la hiérarchie des objets stockés dans la base de données. L'objet cible, ainsi que le résultat de l'exécution de la requête, peuvent être stockés dans la base de données elle-même. Un exemple de demande pour les lecteurs qui ont reçu au moins un livre de la bibliothèque est illustré à la Fig. 2.11.

Figure: 2.11. Fragment d'une base de données avec un objet cible

L'avantage principal Le modèle de données orienté objet en comparaison avec le modèle relationnel est la capacité d'afficher des informations sur les relations complexes des objets. Le modèle de données orienté objet vous permet d'identifier entrée séparée bases de données et définir les fonctions de leur traitement.

Les inconvénients du modèle orienté objet sont une complexité conceptuelle élevée, des inconvénients dans le traitement des données et une faible vitesse de requête.

Dans les années 90, il y avait des prototypes expérimentaux de systèmes de gestion de base de données orientés objet. Actuellement, de tels systèmes sont répandus, en particulier, les SGBD suivants comprennent: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), Q2 (Ardent Software), ODB-Jupiter (centre de recherche et de production Inteltek Plus), ainsi que Iris, Orion, Postgres.

MODÈLE DE DONNÉES RELATIONNELLES

3.1. Définitions basiques

Le modèle de données relationnelles a été proposé par E. Codd en 1970. Le modèle de données relationnelles est basé sur le concept de relation.

Mathématiquement, le rapport est défini comme suit. Soit n ensembles D1, D2,…, Dn. Alors R est une relation sur ces ensembles si R est l'ensemble des tuples ordonnés de longueur n de la forme (d1, d2,…, dn), où d1 est un élément de D1, d2 est un élément de D2, dn est un élément de Dn. D1, D2,…, Dn sont appelés domaines de la relation R. Notez que cette définition équivaut à la définition du produit cartésien des ensembles D1, D2,…, Dn.

Définissons la relation du point de vue de la théorie de l'informatique. Attitude - un sous-ensemble du produit cartésien d'un ou plusieurs domaines. Domaine - l'ensemble des valeurs possibles pour un attribut particulier. Attribut - propriété d'un objet, d'un phénomène ou d'un processus. Exemples d'attributs: nom, prénom, patronyme, date de naissance. Tuple- un élément de relation est un mappage de noms d'attributs avec des valeurs issues des domaines respectifs. Un ensemble fini de tuples forme une relation. Si une relation est créée à partir de n domaines, alors chaque tuple a n composants.

Expliquons ces définitions avec des exemples.

Exemple 1. Ayons deux domaines:

D1 \u003d (0,1); D2 \u003d (a, b, c).

Construisons le produit cartésien des domaines D1, D2:

D1 x D2 \u003d ((0, a), (0, b), (0, c), (1, a), (1, b), (1, c)).

En tant que relation construite sur les domaines D1, D2, vous pouvez choisir, par exemple, les éléments suivants:

R \u003d ((0, a), (0, c), (1, b), (1, c)).

La relation R est constituée de quatre tuples, chaque tuple a deux éléments, le premier est choisi dans le domaine D1, le second dans le domaine D2.

Exemple 2. Ayons quatre domaines:

D1 est un ensemble d'entiers, par exemple un ensemble de numéros de pièces (101, 34, 23, 109, 147).

D2 - plusieurs chaînes de caractères, par exemple, de nombreux noms de pièces (bague, support, support, accouplement, boulon).

D3 - de nombreuses chaînes de caractères, par exemple, de nombreux noms de traitement (estampage à froid, moulage de métal, moulage de plastique, usinage).

D4 est un ensemble de nombres réels, par exemple, un ensemble de poids de parties (45,8, 6,9, 123, 69,3, 5,2, 2,34).

En tant que relation construite sur les domaines D1, D2, D3, D4, vous pouvez choisir, par exemple, les éléments suivants:

R \u003d ((34, douille, plastique moulé, 69,3), (23, support, formé à froid, 45,8), (101, boulon, usiné, 5,2)).

La relation R se compose de trois tuples, chaque tuple contient quatre éléments.

Il est pratique de représenter la relation sous forme de tableau, où chaque ligne est un tuple contenant des données sur un objet, un phénomène ou un processus spécifique. Chaque colonne du tableau est un domaine contenant les valeurs possibles de l'une des propriétés d'un objet, processus ou phénomène.

Par exemple: Détails

Les ensembles de termes suivants sont équivalents:

relation, table, fichier;

tuple, chaîne, enregistrement:

attribut, élément de colonne, champ.

La liste nommée des noms d'attributs de relation est appelée schéma relationnel... Exemple de schéma:

Détails ( Numéro de détail, Nom de la pièce, type de traitement, poids).

Un attribut clé du schéma de relation est mis en évidence.

L'ensemble des schémas de relations utilisés pour représenter les informations est appelé schéma de base de données relationnelle.

Le nombre de colonnes de la relation est appelé degré... Le nombre actuel de tuples dans une relation est appelé puissance... Le degré de la relation ne change généralement pas après la création de la relation, mais la cardinalité fluctuera à mesure que de nouveaux tuples sont ajoutés et d'anciens tuples supprimés.

Base de données relationnelleEst un ensemble de relations contenant toutes les informations qui doivent être stockées dans la base de données.

Exemple d'extrait de base de données:

Attitude 1. Radioéléments (transistors)

Attitude 2. Entrepôt

Chaque relation a une clé. Clé (clé primaire, clé de relation, attribut clé) Est un attribut ou un groupe d'attributs qui identifie de manière unique un tuple dans une relation. Si un clé composite (se compose de deux attributs ou plus), alors il doit être minimal... Cela signifie que si un attribut arbitraire est exclu de la clé composite, les attributs restants ne seront pas suffisants pour identifier de manière unique les tuples individuels. Les valeurs de clé dans une relation (table) doivent être uniques, c'est-à-dire qu'il ne doit pas y avoir deux ou plusieurs tuples (enregistrements) avec la même valeur de clé. S'il n'y a aucun champ dans la relation dont les valeurs sont uniques, un champ numérique supplémentaire est généralement entré pour créer une clé, contenant les nombres ordinaux des enregistrements.

En ce qui concerne "Radioéléments (transistors)", la clé est le type de périphérique, par rapport à "Entrepôt" - Numéro de rack, type de périphérique.

Il peut y avoir des cas où une relation a plusieurs combinaisons d'attributs, chacune identifiant de manière unique tous les tuples de la relation. Toutes ces combinaisons d'attributs sont clés possibles rapports. N'importe laquelle des clés possibles peut être sélectionnée comme principale.

Les clés sont couramment utilisées aux fins suivantes:

élimination des valeurs en double dans les attributs clés;

commande de tuples;

accélérer le travail avec les tuples de relation;

organisation des tableaux de liaison.

Supposons qu'il y ait un attribut non clé A dans la relation R1, dont les valeurs sont les valeurs de l'attribut clé B d'une autre relation R2. On dit alors que l'attribut A de la relation R1 (attribut B de la relation R2) est clé externe... Les liens entre les relations sont établis à l'aide de clés étrangères.

Classes de relations... Les relations de base de données relationnelles sont classées en deux classes basées sur le contenu: les relations d'objet et les relations connectées.

Relations d'objets stocker des données sur des groupes d'objets homogènes, des phénomènes ou des processus ayant les mêmes caractéristiques. Dans une relation d'objet, la clé est appelée la clé principale ou simplement la clé de la relation.

Attitude connectée stocke des données sur les relations entre les relations d'objets. Une relation connectée contient les clés des relations d'objet liées et des données qui caractérisent quantitativement ou qualitativement la relation. Les clés d'une relation connectée sont appelées clés étrangères car elles sont les clés primaires d'autres relations. Le modèle relationnel impose une contrainte sur les clés étrangères appelée intégrité référentielle. Cela signifie que chaque valeur de clé étrangère doit avoir un tuple de relation d'objet correspondant. Sans cela, il est possible que la clé étrangère se réfère à un objet dont on ne sait rien.

Regardons un exemple d'objet et de relations connectées.

Relation d'objet de détails

Relation d'objet de matériaux

Relation connectée "Processus technologique"

Pour «Détails», la clé primaire est le numéro de pièce. Dans la relation matière, la clé primaire est le code matière. En ce qui concerne "Processus technologique", la clé étrangère est le numéro de pièce, code matière. L'attribut «Taux de consommation de matière pour une pièce» est une caractéristique quantitative de la relation entre une pièce et un article.

Comme toutes les tables ne peuvent pas être associées à une relation, nous présentons les conditions dont le respect nous permet de considérer une table comme une relation.

1. Toutes les lignes du tableau doivent être uniques, c'est-à-dire. il ne peut pas y avoir de lignes avec les mêmes clés primaires.

2. Les noms des colonnes du tableau doivent être différents et leurs valeurs simples, c'est-à-dire. un groupe de valeurs dans une colonne d'une ligne n'est pas valide.

3. Toutes les lignes d'une table doivent avoir la même structure, avec les noms et types de colonnes correspondants.

4. L'ordre des lignes du tableau peut être arbitraire.

Indexage... Définir une clé pour une table signifie trier automatiquement les enregistrements, s'assurer qu'il n'y a pas de valeurs en double dans les champs clés des enregistrements et augmenter la vitesse des recherches dans les tables. Pour implémenter ces fonctions, le SGBD utilise l'indexation. Indice Est un moyen d'accélérer l'opération de recherche d'enregistrements dans une table, et, par conséquent, d'autres opérations utilisant la recherche: extraction, modification, tri, etc. La table pour laquelle l'index est utilisé est appelée indexée. Les champs clés d'une table dans de nombreux SGBD sont généralement indexés automatiquement. Les index créés pour les clés sont appelés indices primaires.

Les index créés par l'utilisateur pour les champs non clés sont parfois appelés index secondaires (personnalisés)... L'introduction de tels index ne modifie pas la disposition physique des enregistrements de la table, mais affecte l'ordre dans lequel les enregistrements sont analysés.

La principale raison de l'accélération des diverses opérations sur les tables indexées est que la plupart du travail est effectué sur de petits fichiers d'index, et non sur les tables elles-mêmes. Le meilleur effet de l'amélioration des performances de l'utilisation des tables indexées est obtenu pour les tables de grande taille. L'indexation nécessite peu d'espace disque supplémentaire et peu de surcharge du processeur pour modifier les index à la volée.

Liens entre relations (tableaux).En règle générale, une base de données est une collection de tables liées. Les tables de liaison offrent les avantages suivants:

de nombreux SGBD, lors de la liaison de tables, contrôlent automatiquement l'intégrité des données saisies dans la base de données conformément aux liens établis, ce qui augmente la fiabilité des informations stockées dans la base de données;

un accès plus facile aux données. La liaison de tables pour effectuer des opérations telles que la recherche, l'affichage, l'édition, la récupération et la préparation de rapports à l'aide d'informations provenant de différentes tables réduit le nombre d'appels explicites aux tables de données et le nombre de manipulations dans chacune d'elles.

Il existe plusieurs types de connexions entre les relations. Les relations liées interagissent souvent comme une table principale et une sous-table. La table principale peut également être appelée parent et le subordonné - enfant. La même table peut être primaire pour une table de base de données et enfant pour une autre.

Relation un-à-plusieurssignifie qu'un enregistrement dans la table parent peut correspondre à plusieurs enregistrements (dont un) dans la table enfant. La table parent peut contenir des enregistrements pour lesquels ce moment il n'y a pas d'entrées correspondantes dans la table enfant. Il existe également une relation un-à-plusieurs rigide, lorsque chaque enregistrement de la table parent doit correspondre à un enregistrement de la table enfant.

La relation un-à-plusieurs est la relation la plus courante pour les bases de données relationnelles. Exemple de lien: les tables "Etudiants" et "Examens" peuvent être liées par une relation "un-à-plusieurs" par le champ "Numéro de notes". Cette connexion signifierait qu'un enregistrement sur un étudiant de la table "Etudiants" peut être lié à plusieurs enregistrements sur la réussite des examens par un étudiant donné dans le tableau "Examens".

Communication individuelle se produit lorsqu'un seul enregistrement de la table enfant correspond à un enregistrement de la table parent. Cette relation est rare et signifie que les informations de deux tables peuvent être combinées en une seule. La présence de deux tableaux indique une volonté de diviser les informations principales et secondaires en deux relations. Par exemple, les informations sur les élèves peuvent être divisées en deux tableaux "Etudiants" et " Information additionnelle", Qui sera lié par une relation un-à-un selon le champ" Numéro d'étudiant ". Une relation un à un entraîne plusieurs lectures pour lire les informations associées sur plusieurs tables, ce qui ralentit la récupération des informations souhaitées. Une relation un à un peut être rigide ou non rigide.

Le troisième type de connexion est relation plusieurs à plusieurs... Ce type de relation signifie que plusieurs enregistrements d'une table sont liés à plusieurs enregistrements d'une autre table et vice versa. Par exemple: il peut y avoir une relation plusieurs-à-plusieurs entre les groupes d'apprentissage et les tables Cours et enseignants. Cela signifie que chaque enseignant peut enseigner plusieurs matières et, en même temps, plusieurs enseignants peuvent enseigner la même matière.

Certains SGBD ne prennent pas en charge les relations plusieurs-à-plusieurs au niveau de l'intégrité référentielle, bien qu'ils permettent leur implémentation implicite dans les tables. On pense que la base de données peut toujours être reconstruite afin que toute relation plusieurs-à-plusieurs soit remplacée par une ou plusieurs relations un-à-plusieurs.

Assurer l'intégrité des données... L'un des concepts fondamentaux de la technologie des bases de données est le concept d'intégrité. En général, ce concept est principalement lié au fait que la base de données reflète forme informative un objet du monde réel ou un ensemble d'objets interconnectés du monde réel. Dans le modèle relationnel, les objets du monde réel sont représentés comme un ensemble de relations interdépendantes. Par intégrité, nous entendons la correspondance modèle d'information sujet stocké dans la base de données, les objets du monde réel et leurs relations à chaque instant. Tout changement dans le domaine qui est significatif pour le modèle construit doit être reflété dans la base de données, tout en conservant une interprétation sans ambiguïté du modèle d'information en termes de domaine.

Le soutien de l'intégrité dans le modèle de données relationnelles dans sa compréhension classique comprend 3 aspects.

Le premier est le soutien intégrité structurelle, ce qui est interprété comme le fait qu'un SGBD relationnel ne devrait permettre de travailler qu'avec des structures de données homogènes de type «relation relationnelle». Dans ce cas, le concept de «relation relationnelle» doit satisfaire à toutes les restrictions qui lui sont imposées dans la théorie classique d'une base de données relationnelle (pas de doublons, la présence obligatoire d'une clé primaire, l'absence de la notion de tri des tuples).

En plus de l'intégrité structurelle, le problème des valeurs nulles non définies doit être pris en compte. Une valeur non définie est interprétée dans le modèle relationnel comme une valeur actuellement inconnue. Cette valeur quand information additionnelle à tout moment peut être remplacé par une valeur spécifique. Lors de la comparaison de valeurs nulles, les règles de comparaison standard ne s'appliquent pas: une valeur nulle n'est jamais considérée comme égale à une autre valeur nulle. Pour détecter l'égalité de la valeur d'un attribut à une valeur non définie, des prédicats standard spéciaux sont utilisés:

<имя атрибута> IS NULL et<имя атрибута> EST NON NULLE.

Si dans un tuple donné (dans une ligne donnée) l'attribut spécifié a une valeur non définie, alors le prédicat IS NULL est TRUE et le prédicat IS NOT NULL est FALSE, sinon le prédicat IS NULL est FALSE, et le IS NOT NULL est TRUE.

L'introduction de valeurs nulles a rendu nécessaire de modifier la logique classique à deux valeurs et de la transformer en trois valeurs.

Le deuxième est le soutien intégrité linguistique, qui consiste dans le fait qu'un SGBD relationnel doit fournir des langages de description et de manipulation des données non inférieurs au standard SQL. D'autres outils de manipulation de données de bas niveau qui ne sont pas conformes à la norme ne devraient pas être disponibles.

Troisièmement, c'est le soutien intégrité référentielle (Intégrité référentielle déclarative, DRI).

Intégrité référentielleEst un ensemble de relations entre des tables individuelles dans toute la base de données. La violation d'au moins une de ces connexions rend les informations de la base de données peu fiables. Le SGBD bloque généralement les actions qui violent l'intégrité des relations entre les tables, c'est-à-dire violer l'intégrité référentielle. La garantie de l'intégrité référentielle signifie que le SGBD, lors de la mise à jour de la base de données, garantit le respect des règles suivantes pour les tables associées:

une entrée avec une valeur de clé de lien qui n'existe pas dans la table principale ne peut pas être ajoutée à la table subordonnée;

un enregistrement ne peut pas être supprimé dans la table principale à moins que les enregistrements associés dans la table subordonnée ne soient supprimés;

la modification des valeurs de la clé de lien dans un enregistrement de la table maître n'est pas possible si des enregistrements lui sont associés dans la table subordonnée.

Lorsqu'un utilisateur tente de violer ces conditions lors d'opérations d'ajout et de suppression d'enregistrements ou de mise à jour de données clés dans des tables associées, le SGBD doit afficher des messages d'erreur et ne pas autoriser l'exécution de ces opérations.

Pour éviter la perte d'intégrité référentielle, un mécanisme en cascade est utilisé. Il consiste à assurer les actions suivantes:

lors de la modification d'un champ de lien dans un enregistrement de la table parent, vous devez modifier de manière synchrone les valeurs des champs de lien dans les enregistrements correspondants de la table enfant;

lors de la suppression d'un enregistrement dans la table parent, vous devez supprimer les enregistrements correspondants dans la table enfant.

L'intégrité structurelle, linguistique et référentielle ne détermine pas la sémantique de la base de données, ne se rapporte pas au contenu de la base de données, donc le concept est introduit prise en charge de l'intégrité sémantique.

Le support sémantique peut être fourni de deux manières: déclarative et procédurale.... La voie déclarative est associée à la présence de mécanismes au sein du SGBD qui assurent la validation et l'implémentation d'un certain nombre de règles-contraintes spécifiées de manière déclarative, le plus souvent appelées «Business Rules» ou contraintes d'intégrité déclarative.

Les types suivants de contraintes d'intégrité déclarative sont distingués:

· Contraintes d'intégrité des attributs: valeur par défaut, définition des valeurs obligatoires ou facultatives (Null), définition des conditions sur les valeurs d'attribut.

Le réglage par défaut signifie que chaque fois que vous entrez nouvelle ligne en relation, s'il n'y a pas de données dans la colonne spécifiée, cet attribut reçoit la valeur par défaut. Par exemple, lorsque vous saisissez de nouvelles entrées dans le champ Année de publication, vous devez saisir la valeur de l'année en cours. Pour MS Access, cette expression ressemblera à:

Ici NOW () est une fonction qui renvoie une valeur date actuelle, YEAR (données) - une fonction qui renvoie la valeur de l'année pour la date spécifiée en tant que paramètre.

Un autre exemple, comme condition sur la valeur de l'année de publication, vous devez spécifier une expression qui vérifiera si l'année de publication se situe dans l'intervalle de 1960 à l'année en cours. Pour MS Access, cette expression ressemblera à ceci:

Entre 1960 ET L'ANNÉE (MAINTENANT ())

Dans MS SGBD serveur SQL la valeur par défaut est enregistrée comme "règle métier". Dans ce cas, une expression sera utilisée dans laquelle le nom de la colonne correspondante doit être explicitement spécifié, par exemple:

YEAR_PUBL\u003e \u003d 1960 ET YEAR_PUB<= YEAR(GETDATE())

Ici GETDATE () est une fonction MS SQL Server qui renvoie la date actuelle, YEAR_PUB est le nom de la colonne correspondant à l'année de publication.

· Contraintes d'intégrité spécifiées par le domaine... Ces restrictions sont utiles si la base de données contient plusieurs colonnes de relations différentes qui prennent des valeurs du même ensemble de valeurs valides. Certains SGBD vous permettent de définir des domaines distincts, de définir le type de données pour chaque domaine et de définir en conséquence des restrictions sous la forme de règles métier pour les domaines. Dans ce cas, les attributs sont attribués à un domaine particulier. Parfois, la structure du domaine est implicite. Ainsi, par exemple, dans MS SQL Server, au lieu du concept de domaine, le concept de type de données défini par l'utilisateur est introduit, mais la signification de ce type de données est en fait équivalente à la signification d'un domaine. Il est pratique de définir une restriction sur la valeur au niveau du domaine, puis elle sera automatiquement exécutée pour tous les attributs qui prennent des valeurs de ce domaine. Si la restriction est modifiée, son remplacement est effectué une fois au niveau du domaine, et tous les attributs qui prennent des valeurs de ce domaine fonctionneront automatiquement selon la nouvelle règle.

· Contraintes d'intégrité définies au niveau de la relation. Certaines règles sémantiques ne peuvent pas être traduites en expressions qui ne s'appliquent qu'à une seule colonne. Par exemple, lors de la création d'une relation, les lecteurs ont besoin d'au moins un numéro de téléphone (domicile ou travail) pour joindre rapidement le lecteur. Pour MS Access ou MS SQL Server, l'expression correspondante sera la suivante:

HOME_PHON N'EST PAS NULL OU WORK_PHON N'EST PAS NULL

· Contraintes d'intégrité spécifiées au niveau du lien entre les relations: définition de l'obligation de communication, des principes de suppression en cascade et de mise à jour des données en cascade, définition de la prise en charge des contraintes de puissance de communication. Ces types de contraintes peuvent être exprimés en spécifiant si des valeurs de clé étrangère sont requises ou non dans des relations interdépendantes.

Les contraintes d'intégrité déclarative font référence aux contraintes qui sont immédiatement vérifiables. Il existe des contraintes d'intégrité qui sont différées. Ces contraintes d'intégrité sont prises en charge par le mécanisme de transaction et de déclenchement.

Il serait erroné de supposer que seules des bases de données relationnelles sont utilisées dans les systèmes d'information. Vous pouvez souvent trouver des implémentations de base de données basées sur des modèles hiérarchiques, de réseau, relationnels et autres. Néanmoins, la plupart des systèmes d'information reposent sur des bases de données relationnelles, dont les fondations ont été posées par E. Codd à la fin des années 1960, définissant les règles et opérations de base à appliquer dans la mise en œuvre de ces bases de données. De nombreux modèles de bases de données que l'on peut trouver dans les systèmes d'information sont, d'une manière ou d'une autre, basés sur les principes des bases de données relationnelles et utilisent divers outils supplémentaires pour améliorer le travail avec certains types de données, par exemple avec des données géographiques, des données en temps réel (données en streaming), données multidimensionnelles, etc.

Les bases de données relationnelles sont basées sur un modèle de données relationnelles construit sur la base de l'algèbre relationnelle, qui forme les règles de base pour travailler avec les données dans les bases de données correspondantes.

Modèle de données relationnel

La construction d'un modèle de données relationnelles repose sur la compréhension que tout ensemble de données peut être représenté sous la forme d'une relation, formatée, mais sous la forme d'un tableau (Fig.1.12), où les données sont présentées

attributs et valeurs à l'intersection de l'attribut correspondant avec l'enregistrement (tuple).

Le terme «Relation» fait référence à un ensemble de données combinées en un ensemble d'enregistrements (tuples) et décrit par un en-tête contenant un ensemble d'attributs.

Dans l'exemple ci-dessus, l'ensemble complet des valeurs de travail et l'en-tête avec les attributs nommés sur lesquels les valeurs sont placées est appelé une relation. En termes de logique formelle, la relation en termes généraux peut être représentée comme suit:

R (A, T), i \u003d (1..n) (11)

Dans cette représentation, A est compris comme un attribut décrivant une caractéristique des données, et par T- le type de données auquel les données à représenter dans la relation doivent correspondre. L'exemple ci-dessus est une déclaration informelle de la relation. Son en-tête ne spécifie pas les types de données qui décrivent les informations présentées dans le corps de la relation.

Habituellement, le titre d'une relation, où les noms des attributs et leurs types sont indiqués, est appelé un schéma de relation, et un ensemble de schémas de relations interconnectés est appelé un schéma de données. Un en-tête de relation contient des types de données normalisés ou des types dérivés de types normalisés, et l'ensemble de valeurs associé à un attribut particulier d'un type de données standard ou dérivé est appelé un domaine.

Waters, le terme «domaine» dans la théorie des bases de données signifie un ensemble admissible de valeurs nommées d'un type qui ont une certaine signification

De cette définition, il s'ensuit que le domaine est caractérisé par les propriétés suivantes:

le domaine porte une certaine charge sémantique, qui s'exprime dans la compréhension de la signification des données décrites, qui coïncide généralement avec la compréhension des données dans le domaine concerné;
le domaine est défini par un simple ou dérivé d'un type de données simple, ce qui permet d'utiliser des opérations logiques simples sur les données;
un domaine peut contenir une condition booléenne qui identifie un sous-ensemble spécifique de données qui est valide pour ce domaine.

Le corps d'une relation est construit à partir d'un ensemble d'enregistrements, qui en termes d'algèbre relationnelle sont appelés tuples et représentent des informations qui existent dans le domaine au sein de l'objet considéré ou du groupe d'objets interdépendants.

Ainsi, selon la définition d'un tuple, il contient toutes les données possibles qui obéissent aux règles définies par les domaines individuels. De plus, chaque élément des données du tuple correspond à un seul domaine et obéit à toutes les propriétés définies par ce domaine.

La description du tuple utilise un certain nombre de propriétés importantes, dont certaines sont présentées ci-dessous:

chaque tuple contient une seule valeur pour chacun des attributs qui caractérisent la relation;

aucun ordre n'est supposé pour les composants d'un tuple, comme les éléments d'un domaine;

chaque sous-ensemble de tuples est représenté par un tuple similaire.

En combinant des domaines et des tuples, vous pouvez former une relation qui est généralement définie comme suit;

R [<Заголовок>]{<Список кортежей >}. (1.2)

L'en-tête de relation est représenté par une liste d'attributs séparés par des virgules. Il est également important de noter que le deuxième paramètre de la relation, lorsqu'il est correctement représenté, est désigné par le terme "Body", qui contient de nombreux tuples. Mais pour simplifier la communication informelle et simplifier la présentation, le terme «Corps» est remplacé par le terme «Tuple», ce qui implique que tous les tuples forment le corps de la relation. En plus de comprendre les termes «Tuple», «Domaine» et «Corps» dans la théorie des bases de données relationnelles, il existe une contrainte selon laquelle tous les tuples de la même relation appartiennent au même type de tuple, et ce type de tuple doit être exactement le même tel que défini dans le titre de la relation. Ainsi, toutes les règles de présentation des données définies dans l'en-tête s'appliquent à tous les tuples de la relation.

Étant donné les définitions de relation, tuple et domaine décrites ci-dessus, les propriétés de base d'une relation peuvent être formulées. Pour un exemple de propriétés de relation, considérez la relation d'informations sur les employés de l'organisation, qui inclut les attributs des tuples, mais le nom de l'employé, son poste et son salaire officiel. Ces attributs constitueront le titre de la relation, formant les domaines de la relation. Chaque attribut d'en-tête contient non seulement le nom de l'attribut, mais également son type (Fig. 1.13), qui détermine les types possibles de données stockées en termes de présentation, de traitement et de restrictions.

Figure: 1.13. Exemple de relation d'employé

Toute relation dans une base de données relationnelle possède les propriétés suivantes.

1. Chaque tuple contient une seule valeur du type correspondant pour chaque attribut (la relation est normalisée).

Chaque attribut de l'exemple présenté, dans chaque tuple, se voit attribuer une seule valeur, qui peut être vue à l'intersection du domaine sélectionné "nom complet de l'employé" et du tuple avec le nom complet "Petrov Petr Petrovich". Le rapport qui correspond à cette propriété est normalisé, c'est-à-dire est dans ce cas sous la première forme normale, 1NF.

2. Les attributs ne sont classés selon aucune règle.

Il a été précédemment défini que les composants d'un tuple ne sont pas ordonnés, et comme un tuple doit correspondre aux attributs d'en-tête de manière unique, ces attributs ne sont pas non plus ordonnés. Vous devez comprendre qu'une personne, lorsqu'elle représente des structures de données, applique toujours certaines règles pour ordonner les attributs et les tuples, mais il est important de se rappeler qu'un tel ordre n'est pas important et n'est pas pris en compte lors de l'utilisation de bases de données relationnelles. Par conséquent, les concepts "Premier attribut" ou "Second attribut" ne s'appliquent pas aux objets du modèle relationnel, et le terme "Attribut suivant" ou "Attribut précédent" ne peut pas non plus être discuté.

Cette situation donne une certaine rigidité dans le travail avec des bases de données, améliorant la qualité du code du programme informatique, ce qui n'est souvent pas toujours évident lors de la programmation avec moins de rigidité.

3. Les tuples ne sont classés selon aucune règle.

Cette propriété découle du fait que le corps de la relation est représenté

un ensemble qui n'est pas ordonné par des règles mathématiques. Puisque les relations relationnelles obéissent aux règles de travail avec des ensembles mathématiques, l'appareil mathématique pour travailler avec des ensembles est utilisé.

Bien sûr, en présentant une relation sur papier, une personne essaiera de la rationaliser d'une certaine manière afin qu'elle soit plus facile à traiter. Cependant, ce reflet de la relation n'est pas une règle et n'est qu'une représentation de la relation. La relation elle-même reste non ordonnée, et en la présentant dans un ordre différent de tuples, la relation elle-même ne peut pas être modifiée et les mêmes opérateurs de traitement peuvent lui être appliqués que pour une relation avec une autre représentation ordonnée. Cela signifie que pour l'implémentation dans des bases de données, une représentation ordonnée d'une relation n'a aucun sens, ce qui signifie que toute relation dans une base de données n'est pas ordonnée.

4. Il n'y a pas de tuples en double dans la relation.

Cette propriété d'une relation découle de la compréhension que le corps d'une relation est représenté par un ensemble, et tout ensemble, compte tenu de sa représentation mathématique, ne contient pas de doublons. Il s'ensuit que, en prenant n'importe quel tuple représenté par tous les attributs utilisés dans la relation, il sera impossible de trouver un tuple avec exactement les mêmes valeurs d'attribut.

En même temps, cette propriété illustre les différences entre une relation et une table. Comprenant que la table de données est l'implémentation physique des relations dans la base de données, des enregistrements avec les mêmes valeurs peuvent y être placés, à moins, bien sûr, qu'une telle possibilité ne soit fournie au niveau de la logique du programme pour la construction de la base de données, et la relation, par définition, ne contient jamais de tuples en double.

Souvent, lorsqu'il n'est pas nécessaire de refléter les valeurs décrites dans une relation (corps de relation), le modèle relationnel se limite à ne spécifier que le titre de la relation avec la prescription du nom de la relation elle-même ou seulement le nom de la relation. Ces vues de modèle de données relationnelles sont des vues filtrées utilisées dans des outils de conception de base de données spécialisés tels qu'IBM InfoSphere Data Architect (figure 1.14).

Les principales informations contenues dans le modèle de données relationnelles sont les noms des relations (entités), des attributs et des types d'attributs qui décrivent la relation. De plus, le modèle relationnel reflète les relations entre les relations (entités), ce qui permet d'afficher l'interaction d'éléments de corps de relations liées. Chacun de ces composants du modèle relationnel a un certain nombre de caractéristiques auxiliaires qui s'affinent.

pour la représentation et le traitement des éléments du corps de la relation. Bien que ces caractéristiques ne soient pas explicitement visualisées dans le modèle de données, elles sont prises en compte lors de la présentation complète de la relation, en tenant compte de l'affichage du corps de la relation.

Le modèle de données présenté dans l'exemple utilise un filtre d'affichage qui prend en compte la nécessité d'afficher le nom de la relation (entité), la composition attributive de chaque relation et la relation entre les relations. L'absence de types d'attributs et d'autres caractéristiques dans la visualisation du modèle ne signifie pas qu'ils ne sont pas définis ou non. Cela signifie simplement que le modèle de données est présenté pour la nécessité de ne considérer que les paramètres spécifiés et que toutes les autres caractéristiques sont fixées dans les composants cachés du modèle. Par exemple, une autre présentation peut être le cas illustré à la Fig. 1.15.

Dans cette vue, en plus des noms des relations (entités) et des attributs, les types de données qui caractérisent le corps de la relation sont affichés, bien que le corps lui-même ne soit pas représenté dans ces modèles. Il convient de garder à l'esprit que le modèle de données (modèle de base de données) dans les outils de modélisation spécialisés est axé sur une représentation supplémentaire sous la forme d'une structure de base de données et que l'indication des corps de relation n'est pas pratique. Pour cette raison, les corps de relation ne sont généralement pas affichés dans les modèles de base de données. Si le modèle est construit précisément pour refléter des opérations avec des relations, au sens complet de ce terme, alors toutes les relations doivent être représentées avec des corps illustrant les valeurs possibles qui seront ensuite stockées dans des tables de base de données.

Cette division introduit souvent une certaine confusion quant à l'exactitude de l'utilisation d'un modèle de données particulier (modèle de base de données), ce qui nécessite une description plus précise de leur utilisation. Ainsi, le modèle de données sous forme de relations est utilisé lorsqu'il est nécessaire d'illustrer des opérations possibles sur les données de relations et de comprendre l'interprétation correcte dans le modèle de domaine, représenté par des objets avec leurs instances possibles. Le modèle de données sous la forme d'entités et de relations (modèle EL) est utilisé pour former un modèle de base de données logique (infologique) sans spécifier de valeurs de données spécifiques et vise à une présentation ultérieure sous la forme d'une structure de base de données. Le modèle sous forme de tableaux et de liens est construit au niveau physique, reflétant les particularités de la présentation et du traitement des données au niveau du SGBD. Le résultat est une représentation du modèle de données relationnelles en trois versions principales (tableau 1.3).

Tableau 13

Options de représentation pour les modèles de données relationnelles

Type de présentation	Utilisé terminologie	Rendez-vous
Modèle avec le reflet du nom de la relation, composition attributive, connexions	L'essence Type de données	Utilisé pour modéliser une structure de données logique pour une transition ultérieure vers la couche physique
Modèle avec en-tête et réflexion du corps avec données possibles	Attitude Titre Attribut / domaine Type de données	Il est utilisé pour la présentation avec indication des valeurs de données possibles et l'application, si nécessaire, l'analyse des opérations possibles sur les relations et les données dans les relations
Modèle affichant les structures de la représentation physique des données dans le SGBD	Attribut / 11ole / colonne Type de données	Permet d'afficher une variante de la représentation de la structure, qui sera implémentée au niveau physique dans le SGBD

Remarque. Cette section traite des formes de présentation du modèle de base de données, qui se reflètent dans trois options. Il convient de garder à l'esprit que la modélisation de base de données est basée sur la mise en œuvre de niveaux de modélisation et, par conséquent, il existe une interprétation des modèles de données en fonction de ces niveaux, qui sont représentés par d'autres types de modèles relationnels, qui seront abordés plus loin. A cet égard, il ne faut pas prendre la liste des représentations de modèles décrite ci-dessus comme exhaustive, sachant qu'il peut y avoir d'autres représentations et d'autres types de modèles.

Boyko V.V. Savinkov V.M. Conception de bases de données de systèmes d'information.
Les types de données seront abordés dans les chapitres suivants.
Le terme «normalisation» et les formes normales seront discutés dans le chap. 2.

Modèle de données relationnel

Le modèle relationnel est basé sur le concept théorique d'ensemble d'une relation. Dans les disciplines mathématiques, il y a un concept ʼʼ attitude ʼʼ (relation), dont la représentation physique est table ... D'où le nom du modèle - relationnel .

Par rapport à une base de données, les concepts «base de données relationnelle» et «base de données tabulaire» sont des synonymes. Les bases de données relationnelles sont les plus répandues au monde. Presque tous les produits de base de données créés depuis la fin des années 1970 sont relationnels.

En 1970, des articles ont paru sur l'utilisation de divers modèles de données tabulaires. Le plus significatif d'entre eux était un article du chercheur IBM Dr. E. Codd (Codd EF, A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, juin 1970), où a été appliqué pour la première fois terme "modèle de données relationnel" ... Le projet System R a été développé dans un laboratoire de recherche d'IBM Corporation. Ce projet a été conçu avec objectif prouver le caractère pratique du modèle relationnel. Le SGBD relationnel fait référence au SGBD deuxième génération.

Objectifs création d'un modèle de données relationnel:

1. Fournir un degré plus élevé d'indépendance par rapport aux données.

2. Construisez une base solide pour résoudre les problèmes de cohérence et de redondance des données.

3. Expansion des langages de gestion des données en incluant des opérations sur les ensembles.

Les systèmes commerciaux basés sur le modèle de données relationnelles ont commencé à apparaître à la fin des années 70 et au début des années 80. Il existe aujourd'hui plusieurs centaines de types différents de SGBD relationnels.

Le modèle relationnel est une forme pratique et la plus courante de représentation des données sous la forme les tables (rapports ). Chaque relation a nom et se compose de nommés les attributs (colonnes) données. L'un des avantages fondamentaux du modèle relationnel est sa uniformité... Toutes les données sont stockées dans des tables dans lesquelles chaque ligne a le même format. Chaque ligne du tableau représente un objet du monde réel ou une relation entre des objets.

Les concepts de base par lesquels le modèle relationnel est défini sont les suivants:

1. base de données relationnelle - un ensemble de relations normalisées;

2. attitude - fichier, une table plate composée de colonnes et de lignes; une table dans laquelle chaque champ est atomique;

3. domaine - un ensemble de valeurs admissibles à partir desquelles la valeur de l'attribut correspondant d'une certaine relation est prise. D'un point de vue programmation, domaine - ϶ᴛᴏ type de données;

4. univers - un ensemble de valeurs pour tous les champs ou un ensemble de domaines;

5. cortège - enregistrement, ligne de tableau;

6. cardinalité - le nombre de lignes dans le tableau;

7. les attributs – champs nommés, colonnes de table;

8. degré d'attitude - nombre de champs (colonnes);

9. diagramme de relation - une liste ordonnée de noms d'attributs;

10. schéma de base de données relationnelle - un ensemble de schémas relationnels;

11. clé primaire - un identifiant unique avec des enregistrements non répétitifs - une colonne ou un sous-ensemble de colonnes qui identifient de manière unique les lignes.

Une clé primaire qui comprend plusieurs colonnes est généralement appelée pluriel , ou combiné , ou composite , ou super clé .

Règle d'intégrité des objets indique que la clé primaire ne doit pas être complètement ou partiellement vide.

La relation entre ces concepts est illustrée à la Fig. 4.5.

№	Nom complet	Année de naissance	Position	département
1.	Ivanov I. I.		Tête département	22
2.	S. S. Sidorov		Prof.	22
3.	Andreeva G.G.		Prof.	22
4.	Tsvetkova S. S.		Docent
5.	Kozlov K.K.		Docent	22
6.	Petrov P. P.		Art. Tour.	22

Les attributs

figure. 4.5. Concepts de base du modèle de données relationnel.

Parfois, différentes colonnes sont sélectionnées comme clé primaire dans une table. Une clé dédiée est une clé explicitement répertoriée avec le schéma relationnel. Sinon, on parle d'une clé implicite, ou d'une clé possible, ou d'une clé candidate.

12. clé externe - ϶ᴛᴏ une colonne ou un sous-ensemble de colonnes d'une table pouvant servir de clé primaire pour une autre table. La clé étrangère d'une table est une référence à la clé primaire d'une autre table. Puisque le but de la construction d'une base de données est de stocker toutes les données, si possible, dans un seul cas, alors si un certain attribut est présent dans plusieurs relations, sa présence reflète généralement une certaine relation entre les lignes de ces relations.

Les clés étrangères implémentent des relations entre les tables de base de données.

Une clé étrangère, comme une clé primaire, peut être une combinaison de colonnes. En pratique, une clé étrangère sera toujours composite si elle fait référence à une clé primaire composite d'une autre table. Le nombre de colonnes et leurs types de données dans les clés primaire et étrangère doivent correspondre.

Dans le cas où une table est liée à plusieurs autres tables, elle peut avoir plusieurs clés étrangères.

Chaque table relationnelle a ce qui suit propriétés:

A un nom ĸᴏᴛᴏᴩᴏᴇ diffère des noms de toutes les autres tables;

Les données des cellules du tableau doivent être structurellement indivisibles. Il est inacceptable qu'une cellule de tableau contienne plus d'un élément d'information. Par exemple, le numéro et la série du passeport doivent figurer dans différentes colonnes du tableau;

Toutes les colonnes du tableau sont homogènes, ᴛ.ᴇ. 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 doit être arbitraire, indépendamment de leur réorganisation, la relation restera la même, et aura donc la même signification.

Les concepts de base du modèle de données relationnel sont des concepts et des types. Classification et caractéristiques de la catégorie «Concepts de base du modèle de données relationnel» 2017, 2018.

Les bases du modèle de données relationnelles ont été esquissées pour la première fois dans un article d'E. Codd en 1970. Ces travaux ont incité un grand nombre d'articles et de livres dans lesquels le modèle relationnel a été développé. L'interprétation la plus courante du modèle de données relationnelles appartient à K. Date. Selon Date, le modèle relationnel comprend trois parties:

La partie structurelle.

Partie intégrale.

La partie manipulation.

Partie structurelle décrit les objets considérés par le modèle relationnel. Il est postulé que la seule structure de données utilisée dans le modèle relationnel est des relations n-aires normalisées.

Partie intégrale décrit les contraintes d'un type particulier qui doivent être satisfaites pour toute relation dans une base de données relationnelle. il intégrité de l'entité et intégrité de la clé étrangère .

Partie de manipulation décrit deux manières équivalentes de manipuler des données relationnelles - algèbre relationnelle et calcul relationnel .

Ce chapitre traite de la partie structurelle du modèle relationnel.

Types de données

Toutes les données utilisées dans la programmation ont leurs propres types de données.

Important! Le modèle relationnel nécessite les types de données utilisés pour être facile.

Pour clarifier cette affirmation, considérez quels types de données sont généralement considérés dans la programmation. En règle générale, les types de données sont divisés en trois groupes:

Types de données simples.

Types de données structurées.

Types de données de référence.

Types de données simples

Types de données simples ou atomiques n'ont pas de structure interne. Ce type de données s'appelle scalaires ... Les types de données simples incluent les types suivants:

Logique.

Chaîne.

Numérique.

Divers langages de programmation peuvent étendre et affiner cette liste en ajoutant des types tels que:

Réel.
Monétaire.
Énumérable.
Intervalle.

Bien entendu, le concept d'atomicité est assez relatif. Ainsi, un type de données chaîne peut être considéré comme un tableau unidimensionnel de caractères, et un type de données entier comme un ensemble de bits. La seule chose importante est que lorsque vous passez à un niveau aussi bas, vous perdez sémantique (signification) des données ... Si une chaîne exprimant, par exemple, le nom de famille d'un employé, est décomposée en un tableau de caractères, alors la signification d'une telle chaîne dans son ensemble est perdue.

Types de données structurées

Types de données structurées sont conçus pour définir des structures de données complexes. Les types de données structurées sont construits à partir d'éléments constitutifs appelés composants, qui à leur tour peuvent être structurés. Les types de données suivants peuvent être cités comme types de données structurées:

Enregistrements (structures)

Mathématiquement, un tableau est une fonction à portée finie. Par exemple, considérons un ensemble fini de nombres naturels

appelé l'ensemble d'index. Afficher

d'un ensemble à un ensemble de nombres réels définit un tableau réel à une dimension. La valeur de cette fonction pour une valeur d'index est appelée l'élément de tableau correspondant à. Les tableaux multidimensionnels peuvent être définis de la même manière.

Un enregistrement (ou une structure) est un tuple d'un produit cartésien d'ensembles. En effet, un enregistrement est une collection ordonnée nommée d'éléments, dont chacun appartient à un type. Ainsi, l'entrée est un élément de l'ensemble ... En déclarant de nouveaux types d'enregistrement basés sur des types existants, l'utilisateur peut construire des types de données arbitrairement complexes.

Ce que les types de données structurées ont en commun, c'est qu'ils avoir une structure interneutilisé par au même niveau d'abstractioncomme les types de données eux-mêmes.

Expliquons cela comme suit. Lorsque vous travaillez avec des tableaux ou des enregistrements, vous pouvez manipuler le tableau ou enregistrer les deux avec un seul tout (créer, supprimer, copier des tableaux ou des enregistrements entiers) et élément par élément. Pour les types de données structurées, il existe des fonctions spéciales - les constructeurs de types, qui vous permettent de créer des tableaux ou des enregistrements à partir d'éléments de types plus simples.

Lorsque vous travaillez avec des types de données simples, tels que des types numériques, nous les manipulons comme des objets entiers indivisibles. Pour "voir" qu'un type de données numérique est en fait complexe (c'est une collection de bits), vous devez passer à un niveau d'abstraction inférieur. Au niveau du code du programme, cela ressemblera à des insertions d'assembleur dans du code de langage de haut niveau ou à l'utilisation d'opérations spéciales au niveau du bit.

Types de données de référence

Type de données de référence (pointeurs ) est destiné à fournir la possibilité de pointer vers d'autres données. Les pointeurs sont typiques des langages procéduraux, qui ont le concept d'une zone de mémoire pour stocker les données. Le type de données de référence est conçu pour gérer des structures évolutives complexes, telles que des arbres, des graphiques, des structures récursives.

Types de données utilisés dans le modèle relationnel

En fait, pour un modèle de données relationnel, le type de données utilisé n'est pas important. Exiger que le type de données soit facile, vous devez comprendre que les opérations relationnelles ne doivent pas prendre en compte la structure interne des données... Bien entendu, les actions qui peuvent être effectuées avec les données dans leur ensemble doivent être décrites, par exemple, des données de type numérique peuvent être ajoutées, pour les chaînes, une opération de concaténation est possible, etc.

De ce point de vue, si nous considérons un tableau, par exemple, dans son ensemble et n'utilisons pas d'opérations élément par élément, alors un tableau peut être considéré comme un type de données simple. De plus, vous pouvez créer votre propre type de données arbitrairement complexe, décrire des actions possibles avec ce type de données, et si les opérations ne nécessitent pas de connaissance de la structure de données interne, ce type de données sera également simple du point de vue de la théorie relationnelle. Par exemple, vous pouvez créer un nouveau type - les nombres complexes en tant qu'enregistrement du formulaire, où. Vous pouvez décrire les fonctions d'addition, de multiplication, de soustraction et de division, et toutes les actions avec des composants et ne jouer que à l'intérieurces opérations. Ensuite, si dans les actions avec ce type vous utilisez seulementopérations décrites, la structure interne n'a pas d'importance, et le type de données de l'extérieur ressemble à atomique.

C'est ainsi que certains implémentations de SGBD post-relationnels fonctionnent avec des types de données arbitrairement complexes créés par les utilisateurs.

Domaines

Dans le modèle de données relationnel, le concept de type de données est étroitement lié au concept de domaine, qui peut être considéré comme une spécification d'un type de données.

Domaine est un concept sémantique. Un domaine peut être considéré comme un sous-ensemble des valeurs de certains types de données qui ont une signification spécifique. Le domaine est caractérisé par les propriétés suivantes:

Le domaine a nom unique(dans la base de données).

Le domaine est défini sur certains faciletype de données ou sur un domaine différent.

Le domaine peut avoir condition logiquequi vous permet de décrire un sous-ensemble de données valides pour un domaine donné.

Le domaine porte un certain charge sémantique.

Par exemple, un domaine signifiant «âge de l'employé» peut être décrit comme le sous-ensemble suivant de l'ensemble des nombres naturels:

La différence entre un domaine et le concept de sous-ensemble réside précisément dans le fait que le domaine reflète la sémantiquedéfini par le domaine. Il peut y avoir plusieurs domaines qui coïncident en tant que sous-ensembles, mais qui ont des significations différentes. Par exemple, les domaines «Part Weight» et «Quantity Available» peuvent être décrits de la même manière comme un ensemble d'entiers non négatifs, mais la signification de ces domaines sera différente et sera diversdomaines.

La signification principale des domaines est que les domaines restreignent les comparaisons... Il est incorrect, d'un point de vue logique, de comparer des valeurs de différents domaines, même si elles sont du même type. C'est une manifestation de la limitation sémantique des domaines. La requête syntaxiquement correcte "donner une liste de toutes les pièces avec un poids de pièce supérieur à la quantité disponible" ne correspond pas à la signification des concepts "quantité" et "poids".

Commentaire... Le concept de domaine aide correctement simulerdomaine. Lorsque vous travaillez avec un système réel, en principe, une situation est possible lorsque vous devez répondre à la demande ci-dessus. Le système donnera une réponse, mais elle n'aura probablement aucun sens.

Commentaire... Tous les domaines n'ont pas une condition booléenne qui limite les valeurs de domaine possibles. Dans ce cas, l'ensemble des valeurs de domaine possibles correspond à l'ensemble des valeurs de type de données possibles.

Commentaire... Il n'est pas toujours évident de définir une condition booléenne qui limite les valeurs de domaine possibles. Je serai reconnaissant à quelqu'un qui me donnera une condition pour un type de données chaîne qui définit le domaine "Nom de famille de l'employé". Il est clair que les lignes qui sont des noms de famille ne doivent pas commencer par des chiffres, des caractères de service, par un signe souple, etc. Mais le nom de famille "Ггггыыыыый" (s) est-il acceptable? Pourquoi pas? Évidemment pas! Ou peut-être que quelqu'un par dépit s'appellera comme ça. Des difficultés de ce genre surviennent parce que la signification des phénomènes réels ne peut pas toujours être formellement décrite. C'est juste que nous, comme tout le monde, comprenons intuitivement ce qu'est un nom de famille, mais personne ne peut donner une définition aussi formelle qui distinguerait les noms de famille des chaînes qui ne sont pas des noms de famille. Le moyen de sortir de cette situation est simple - se fier à l'intelligence de l'employé qui saisit les noms dans l'ordinateur.

Relations, attributs, tuples de relation

Définitions et exemples

Le concept fondamental du modèle de données relationnelles est le concept rapports ... Dans la définition du concept de relation, nous suivrons le livre de K. Date.

Définition 1. Attribut de relation il existe plusieurs types<Имя_атрибута: Имя_домена>.

Les noms d'attribut doivent être uniques dans la relation. Souvent, les noms d'attribut d'une relation sont les mêmes que les noms de domaine correspondants.

Définition 2. Attitude défini sur plusieurs domaines (pas nécessairement différents) contient deux parties: un en-tête et un corps.

En-tête de relation contient un nombre fixe d'attributs de relation:

Relation corporelle contient de nombreux tuples de relations. Chaque tuple de relation est un ensemble de paires de la forme<Имя_атрибута: Значение_атрибута>:

de telle sorte que la valeur d'attribut appartient au domaine

La relation est généralement écrite comme suit:

ou plus court

ou simplement

Le nombre d'attributs dans une relation est appelé degré (ou -areté ) relations.

La cardinalité de l'ensemble des tuples d'une relation est appelée puissance rapports.

En revenant au concept mathématique de relation introduit dans le chapitre précédent, les conclusions suivantes peuvent être tirées:

Conclusion 1... L'en-tête de relation décrit le produit cartésien des domaines sur lesquels la relation est définie. L'en-tête est statique, il ne change pas lors de l'utilisation de la base de données. Si la relation a changé, ajouté ou supprimé des attributs, le résultat est déjà autreattitude (même avec le même nom).

Conclusion 2... Le corps d'une relation est une collection de tuples, i.e. un sous-ensemble du produit cartésien des domaines. Ainsi, le corps d'une relation est lui-même une relation au sens mathématique du mot. Le corps de la relation peut changer lors de l'utilisation de la base de données - les tuples peuvent être modifiés, ajoutés et supprimés.

Exemple 1 ... Considérez la relation «Employés» définie sur les domaines «Employee_Number», «Lastname», «Salary», «Department_Number». Car Étant donné que tous les domaines sont différents, il est pratique de nommer les attributs de la relation de la même manière que les domaines correspondants. L'en-tête de relation ressemble à.

Un modèle de données est un ensemble de structures de données et d'opérations pour leur traitement. À l'aide du 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 tout ensemble de données et des règles de liaison définissent 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. Les modèles de données hiérarchiques, de réseau et relationnels sont distingués. 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 de manière hiérarchique sont très courantes dans la vie quotidienne. 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 (arborescente) se compose d'un ensemble ordonné d'éléments. Dans ce modèle, les éléments d'origine génèrent d'autres éléments, et ces éléments génèrent à leur tour les éléments suivants. Chaque enfant n'a qu'un seul parent.

Les organigrammes, les listes de matériaux, la table des matières des 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. En règle générale, 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.

À propos du modèle de données 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 du modèle hiérachique 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 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, examiné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 diagramme de cette base à 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 ce modèle de base de données.

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

Modèle de données relationnel

Ainsi, le but du système d'information est de traiter les donnéesà propos objetsle monde réel, étant donné connexionsentre les objets. Dans la théorie DB, les données sont souvent appelées attributs, etobjets - entités.L'objet, l'attribut et la connexion sont des concepts fondamentaux de 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 une manière 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 comme produits imprimés, mais comme œuvres), représentations théâtrales, films; normes juridiques, théories philosophiques, etc.

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

Le développement de bases de données relationnelles a commencé à la fin des années 1960, lorsque sont apparus les premiers articles qui en discutaient; la possibilité d'utiliser des méthodes familières et naturelles de présentation des données dans la conception de bases de données - les modèles datalogiques dits 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é le 6 (article de juin 1970 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 relationnel». 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, a une base mathématique puissante qui décrit les règles d'organisation efficace des 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 tout ensemble de données peut être représenté sous la forme de tableaux à deux dimensions d'un type spécial, connus en mathématiques sous le nom de «relations».

Relationnelon considère une telle base de données 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. Tablereflète type d'objetle vrai monde (essence),et chacune d'elle string est un objet spécifique.Chaque colonne d'une table 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, qui est 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 date de naissance a un type de données qui peut stocker des informations sur des points dans le temps, et le domaine de nom d'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 dans un SGBD spécifique, il est possible de sélectionner pour chaque champ son un type,c'est-à-dire pour définir un ensemble de règles pour l'afficher, ainsi que pour déterminer 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 classé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 le nombre n'est pas logiquement limité.

Comme 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, les valeurs dans lesquelles identifient de manière unique chacune de ses lignes. Une telle colonne (ou une combinaison de colonnes) est appelée clé primaire... Un champ artificiel est souvent introduit pour numéroter des 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é.A tout moment dans le temps, deux tuples différents de la relation n'ont pas la même valeur pour la combinaison des attributs inclus dans la clé. Autrement dit, le tableau ne peut pas contenir deux lignes avec le même numéro d'identification ou 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 de numéro d'identification et de nom d'employé comme clé. En excluant le nom de l'employé de la clé, vous pouvez toujours identifier chaque ligne de manière unique.

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.D'autres clés possibles, le cas échéant, sont considérées 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 relationnel. 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, en fonction du niveau de description (théorie ou pratique) et du système (Access, SQL Server, dBase). Table 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

Ligne d'enregistrement tuple

Attribut Champ _______________ Colonne

Bases de données relationnelles

Base de données relationnelleest un ensemble de relations contenant toutes les informations qui doivent être stockées dans la base de données. Autrement dit, la base de données représente l'ensemble des tables nécessaires pour stocker toutes les données. Les tables de bases de données relationnelles sont logiquement liées les unes aux autres. Les exigences pour la conception d'une base de données relationnelle en général peuvent être réduites à plusieurs 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. Plus d'une valeur ne peut pas être stockée 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 ou plusieurs auteurs, vous devrez utiliser des tableaux supplémentaires.

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

О Chaque colonne se voit attribuer un nom unique dans le tableau; 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 vous référer librement à n'importe quelle ligne ou colonne du tableau. Les valeurs stockées dans la table n'imposent aucune restriction sur l'ordre dans lequel les données sont accédées. Description de la colonne,

La structure de données dans le modèle relationnel est. Modèle de données relationnel

Modèle de données relationnel

Types de données structurées

Lire aussi

Tarif MTS "Tablet Mini": description

Pneus et jantes pour Nissan X-Trail, dimensions de jantes pour Nissan X-Trail

Internet mobile et communication cellulaire en Crimée - Itinérance Beeline, MTS, Megafon, Tele2

LA CLOCHE