Modèle orienté objet

Dans un modèle orienté objet, lors de la présentation des données, il est possible d'identifier des enregistrements individuels de base de données. Des relations sont établies entre les enregistrements de base de données et leurs fonctions de traitement à l'aide de mécanismes similaires aux outils correspondants des langages de programmation orientés objet.

Le modèle orienté objet normalisé est décrit dans les recommandations du standard ODMG-93 (groupe de gestion de base de données d'objet). Il n'est pas encore possible de mettre pleinement en œuvre les recommandations de l'ODMG-93. Pour illustrer les idées clés, considérons un modèle légèrement simplifié d’une base de données orientée objet.

La structure d'une base de données orientée objet (par exemple, la base de données d'objets Versant, le magasin d'objets, etc.) est représentée graphiquement sous la forme d'un arbre dont les nœuds sont des objets. Les propriétés des objets sont décrites par un type standard (par exemple, chaîne) ou un type construit par l'utilisateur (défini en tant que classe).

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

La structure logique d'une base de données orientée objet ressemble à celle d'une base de données hiérarchique. La principale différence entre les deux réside dans les méthodes de manipulation des données.

Pour effectuer des actions sur les données du 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 en langage 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 sont accompagnées d'une formation automatique et d'un ajustement ultérieur d'index (tables d'index) contenant des informations pour une extraction rapide des données.

Examinons brièvement les concepts d'encapsulation, d'héritage et de polymorphisme appliqués à un modèle de base de données orienté objet.

Encapsulation limite la portée d'un nom de propriété aux limites de l'objet dans lequel il est défini.

L'héritage, en revanche, étend la portée d'une propriété à tous les descendants d'un objet.

Le polymorphisme dans les langages de programmation orientés objet signifie que le même code de programme peut fonctionner avec des données hétérogènes. En d'autres termes, cela signifie qu'il est permis à des objets de types différents d'avoir des méthodes (procédures ou fonctions) portant le même nom. Lors de l'exécution d'un programme objet, les mêmes méthodes s'appliquent à différents objets en fonction du type d'argument. Une recherche dans une base de données orientée objet consiste à rechercher les similitudes entre l'objet défini par l'utilisateur et les objets stockés dans la base de données. Un objet défini par l'utilisateur appelé objet cible (une propriété d'objet est du type objectif), dans le cas général, peut être un sous-ensemble de la hiérarchie complète des objets stockés dans la base de données. L'objet cible, ainsi que le résultat de la requête, peuvent être stockés dans la base de données elle-même.

Le principal avantage d'un modèle de données orienté objet par rapport à un modèle relationnel est la possibilité d'afficher des informations sur les relations complexes des objets. Un modèle de données orienté objet vous permet d'identifier un enregistrement de base de données unique et de déterminer les fonctions de traitement.

Les inconvénients du modèle orienté objet sont la complexité conceptuelle élevée, les inconvénients du traitement des données et la faible vitesse d'exécution des requêtes.

Types de données

Initialement, les SGBD étaient principalement utilisés pour résoudre des problèmes financiers et économiques. Dans ce cas, quel que soit le modèle de présentation utilisé dans les bases de données, les principaux types de données suivants ont été utilisés:

•   numérique. Exemples de valeurs de données: 0.43; 328; 2E + 5;
•   caractère (alphanumérique). Exemples de valeurs de données: "vendredi", "chaîne", "programmeur";
•   Dates spécifiées à l'aide du type de date spécial ou en tant que données de caractères ordinaires. Exemples de valeurs de données: 12/12/97, 23/2/1999.

Dans différents SGBD, ces types peuvent légèrement différer par leur nom, leur plage de valeurs et leur type de présentation. Par la suite, des systèmes de traitement de données spécialisés ont commencé à apparaître dans de nouvelles applications, par exemple, les systèmes de géoinformation, le traitement vidéo, etc. À cet égard, les développeurs ont commencé à introduire de nouveaux types de données dans les SGBD traditionnels. Les types de données relativement nouveaux sont les suivants:

• heure et date-heure, conçu pour stocker des informations sur l'heure et (ou) la date. Exemples de valeurs de données: 01/31/85 (date), 9:10:03 (heure), 03/06/1960 12:00 (date et heure);
•   longueurs variables de caractères conçues pour stocker des informations textuelles de texte long, telles qu'un document;
•   binaire, destiné au stockage d’objets graphiques, d’informations audio et vidéo, d’informations spatiales, chronologiques et autres. Par exemple, dans MS Access, ce type est le type de données OLE Object Field, qui vous permet de stocker des données graphiques au format BMP (Bitmap) dans la base de données et de les afficher automatiquement lorsque vous utilisez la base de données.
•   hyperliens (hyperlink), conçus pour stocker des liens vers diverses ressources (noeuds, fichiers, documents, etc.) situées en dehors de la base de données, par exemple sur Internet, sur l'intranet de l'entreprise ou sur le disque dur de l'ordinateur.

Dans les SGBD modernes dotés de divers modèles de données, tous les types de données répertoriés peuvent être utilisés.

Modèle de données orienté objet

Modèle de données relationnel objet

Autres modèles de données

La complexité croissante des applications de base de données et les limites du modèle relationnel ont conduit au développement du modèle Codd, s'appelait tout d'abord modèle relationnel étendu, et plus tard développé dans le modèle de données objet-relationnel. Les bases de données basées sur ces modèles sont communément appelées la 3ème génération.

Le modèle de données relationnel-objet (ORMD) est mis en œuvre à l'aide de tables relationnelles, mais inclut des objets similaires au concept d'objet dans la programmation orientée objet. L'ORMD utilise des composants orientés objet tels que types de données utilisateur, encapsulation, polymorphisme, héritage, redéfinition de méthode, etc.

Malheureusement, à ce jour, les développeurs ne sont pas parvenus à un consensus sur ce que devrait fournir le MMP. En 1999. La norme SQL-99 a été adoptée et en 2003. la deuxième version de cette norme a été publiée, appelée SQL-3, qui définit les principales caractéristiques de l'ORMD. Mais jusqu'à présent, les modèles objet-relationnels pris en charge par différents fabricants de SGBD sont très différents les uns des autres. Les perspectives de ce secteur sont illustrées par le fait que les principaux fabricants de SGBD, notamment Oracle, Informix, INGRES et autres, ont étendu les fonctionnalités de leurs produits au SGBD relationnel-objet (ORBMS).

Dans la plupart des implémentations de ORMD, les objets sont un agrégat et une table (relation), qui peuvent faire partie d'une autre table. Les méthodes de traitement des données sont présentées sous la forme de procédures stockées et de déclencheurs, objets de procédure de la base de données, associés à des tables. Au niveau conceptuel, toutes les données d'une base de données relationnelle-objet sont représentées sous la forme de relations et ORBMS prend en charge SQL.

Une autre approche pour créer une base de données consiste à utiliser un modèle de données orienté objet (OOMD). La modélisation des données dans OOMD est basée sur le concept d'objet. OOMD est généralement utilisé dans des domaines complexes pour la modélisation pour laquelle la fonctionnalité du modèle relationnel fait défaut (par exemple, pour les systèmes de conception automatisés (CAD), les systèmes de publication, etc.).

Lors de la création d'un SGBD orienté objet (OODBMS), différentes méthodes sont utilisées, à savoir:

• intégration dans les outils de langage orientés objet conçus pour fonctionner avec la base de données;
• extension du langage existant pour travailler avec des bases de données avec des fonctions orientées objet;
• création de bibliothèques de fonctions orientées objet pour travailler avec la base de données;
• création d'un nouveau langage et d'un nouveau modèle de données orienté objet

Les avantages de OOMD incluent les vastes possibilités de modélisation de domaine, de langage de requête expressif et de performances élevées. Chaque objet dans OOMD a un identifiant unique (OID - identifiant d'objet). Les recherches d'OID sont nettement plus rapides que la recherche d'une table relationnelle.

Parmi les faiblesses de l'OOMD, il convient de noter l'absence de modèle généralement accepté, le manque d'expérience dans la création et le fonctionnement de l'OOBD, la complexité de l'utilisation et le manque d'outils de protection des données.

En 2000. le groupe de travail ODMG (groupe de gestion de base de données d’objets), formé par les fabricants d’OSOSMD, a publié le prochain standard (ODMG 3.0) pour OSOSDB, qui décrit le modèle objet, le langage de définition de requête, le langage de requête d’objet et les langages de connexion C ++, Smalltalk et Java Les normes ODMG ne sont pas officielles. L'approche d'ODMG en matière de normalisation consiste dans le fait qu'après l'adoption de la prochaine version de la norme par les organisations membres d'ODMG, un livre contenant le texte de la norme est publié.

Nous allons maintenant examiner comment le support des données de modèle est implémenté dans de vrais systèmes de gestion de base de données.

Un modèle de données orienté objet - concept et types. Classification et caractéristiques de la catégorie "Modèle de données orienté objet" 2017, 2018.

Lors de la soumission de données à OOMD, il est possible d'identifier des enregistrements individuels de base de données. Les relations entre les enregistrements de base de données et leurs fonctions de traitement sont établies à l'aide de mécanismes similaires aux outils correspondants des langages de programmation orientés objet.

Le modèle normalisé orienté objet est décrit dans les recommandations du standard ODMG-93 (groupe de gestion de base de données objet - groupe de gestion de base de données orientée objet). Il n'est pas encore possible de mettre pleinement en œuvre les recommandations de l'ODMG-93. Pour illustrer les idées clés, considérons un modèle quelque peu simplifié d’une base de données orientée objet.

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

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

Un exemple de la structure logique du système de bibliothèque est illustré à la Fig. 2.8.

Ici, un objet du type LIBRARY est le parent des objets d'instance des classes SUBSCRIBER, CATALOG et ISSUE. Différents objets comme BOOK peuvent avoir un ou plusieurs parents. Les objets de type BOOK qui ont le même parent doivent différer d'au moins le numéro d'inventaire (unique pour chaque copie du livre), mais avoir les mêmes valeurs de propriété. isbnudk, nomet l'auteur.

Fig. 2.8. La structure logique de la base de données de la bibliothèque

La structure logique de l'OOBD est similaire en apparence à celle de la base de données IDB. La principale différence entre les deux réside dans les méthodes de manipulation des données.

Pour effectuer des actions sur les données du 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 d'une base de données s'accompagnent d'une génération automatique et d'un ajustement ultérieur d'index (tables d'index) contenant des informations pour une extraction rapide des données.

Examinons brièvement les concepts d'encapsulation, d'héritage et de polymorphisme appliqués à un modèle de base de données orienté objet.

Encapsulationlimite la portée d'un nom de propriété à la portée de l'objet dans lequel elle est définie. Ainsi, si nous ajoutons à l'objet du type CATALOG une propriété qui définit le numéro de téléphone de l'auteur du livre et porte le nom phone, nous obtiendrons les mêmes propriétés pour les objets SUBSCRIBER et CATALOG. La signification de cette propriété sera déterminée par l'objet dans lequel elle est encapsulée.

L'héritageau contraire, étend la portée de la propriété à tous les descendants de l'objet. Ainsi, tous les objets du type BOOK qui sont les descendants d’un objet du type CATALOG peuvent être attribués aux propriétés de l’objet parent: isbn, udk, title et author. S'il est nécessaire d'étendre l'effet du mécanisme d'héritage sur des objets qui ne sont pas des parents immédiats (par exemple, entre deux descendants du même parent), une propriété abstraite de type abs est définie dans leur ancêtre commun. Ainsi, la définition des propriétés abstraites du ticket et du numéro dans l'objet LIBRARY entraîne l'héritage de ces propriétés par tous les objets enfants de SUBSCRIBER, BOOK et ISSUE. Ce n'est donc pas un hasard si les valeurs de propriété billetles classes SUBSCRIBER et ISSUE indiquées dans la figure seront les mêmes - 00015.

Polymorphisme danslangages de programmation orientés objet signifie que le même code de programme peut fonctionner avec des données hétérogènes. En d'autres termes, cela signifie qu'il est permis à des objets de types différents d'avoir des méthodes (procédures ou fonctions) portant le même nom. Lors de l'exécution d'un programme objet, les mêmes méthodes s'appliquent à différents objets en fonction du type d'argument. 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 CATALOG peuvent avoir un ensemble de propriétés différent. Par conséquent, les programmes d'utilisation des objets de la classe BOOK peuvent contenir un code polymorphe.

La recherche dans l'OBDB consiste à rechercher les similitudes entre l'objet spécifié par l'utilisateur et les objets stockés dans la base de données. Un objet défini par l'utilisateur appelé objet cible (la propriété de l'objet a typebut), dans le cas général, il peut s'agir d'un sous-ensemble de la totalité de la hiérarchie des objets stockés dans la base de données. L'objet cible, ainsi que le résultat de la requête, peuvent être stockés dans la base de données elle-même. Un exemple de demande de numéro de carte de bibliothèque et du nom des abonnés ayant reçu au moins un livre dans la bibliothèque est présenté à la Fig. 2.9

Fig. 2.9 Fragment de base de données avec objet cible

Le principal vaut la peineOOMD, en comparaison avec relationnel, est la capacité d'afficher des informations sur les relations complexes d'objets. OOMD vous permet d'identifier un seul enregistrement de base de données et de déterminer leurs fonctions de traitement.

Le principal   inconvénientsLes OOMD se caractérisent par une complexité conceptuelle élevée, des inconvénients du traitement des données et une faible vitesse d'exécution des requêtes.

Dans les années 90, il y avait des prototypes expérimentaux de l'OSBMS. Il existe actuellement plus de 300 SGBD de ce type. Certains systèmes sont relativement répandus, par exemple les SGBD suivants: Cache (InterSystems), POET (logiciel POET), Jasmine (Computer Associates), Versant (VersantTechnologies), O2 (ArdentSoftware), ODB-Jupiter (Centre de recherche et de production Inteltek Plus). ), ainsi que Iris, Orion et Postgres.

À l'avenir, les avantages du système OBD devraient aboutir à une très large distribution. Pour ce faire, il est d'abord nécessaire de résoudre les problèmes d'élimination des défauts inhérents à l'ODBD: augmenter la flexibilité de la structure de la base de données, créer un langage de programmation clair, élaborer la syntaxe d'analyse des requêtes, définir plusieurs méthodes d'accès aux données, résoudre les problèmes d'accès simultané, déterminer les énumérations complexes de données, définir la protection et la récupération des données. La liste des problèmes nécessitant une solution peut être poursuivie.

Cependant, même après la résolution des problèmes susmentionnés, la transition vers la base de données OBDB sera progressive et peu rapide, car il sera difficile de rompre avec le grand nombre de SGBD relationnels existants pour des raisons objectives et subjectives. Rendre une telle transition moins pénible permettra l'inclusion non seulement de l'objet, mais également de la composante relationnelle dans la structure de l'OSBMS. De plus, MMD devrait être introduit dans l'OSBMS pour la formation des systèmes OLAP HD, de plus en plus demandés dans la pratique.

En présence d'un grand nombre de projets expérimentaux (et même de systèmes commerciaux), il n'existe pas de modèle de données orienté objet généralement accepté, et non pas parce qu'il n'y a pas un seul modèle complet développé, mais parce qu'il n'y a pas d'accord général sur l'adoption d'un modèle. En fait, des problèmes plus spécifiques sont associés au développement de langages de requête déclaratifs, à l'exécution et à l'optimisation de requêtes, à la formulation et au maintien de contraintes d'intégrité, à la synchronisation des accès et à la gestion des transactions, etc.

Un modèle orienté objet (Fig. 3) vous permet de créer, stocker et utiliser des informations sous la forme d'objets. Lors de la création d'un objet, tout objet reçoit un identifiant unique généré par le système, qui est associé à l'objet tout au long de son existence et ne change pas lorsque l'état de l'objet change.

Fig. 3 Modèle de données orienté objet

Chaque objet a un état et un comportement. Un état d'objet est un ensemble de valeurs de ses attributs. Comportement d'objet - ensemble de méthodes (code de programme) qui agissent sur l'état d'un objet. Une valeur d'attribut d'un objet est également un objet ou un ensemble d'objets. L'état et le comportement de l'objet sont encapsulés dans l'objet; l'interaction des objets repose sur la transmission de messages et la mise en œuvre de méthodes appropriées.

De nombreux objets avec le même ensemble d'attributs et de méthodes forment une classe d'objets. Un objet doit appartenir à une seule classe (si vous ne tenez pas compte de la possibilité d'héritage). Il est permis d'avoir des classes prédéfinies primitives dont les objets d'instance ne possèdent pas d'attributs: entiers, chaînes, etc. Une classe dont les objets peuvent servir de valeur d'attribut aux objets d'une autre classe est appelée le domaine de cet attribut.

Il est permis de générer une nouvelle classe basée sur une classe existante - l'héritage. Dans ce cas, la nouvelle classe, appelée sous-classe de la classe existante (super-classe), hérite de tous les attributs et méthodes de la super-classe. Dans la sous-classe, en outre, des attributs et méthodes supplémentaires peuvent être définis. Il existe des cas d'héritage simple et multiple. Dans le premier cas, une sous-classe ne peut être déterminée que sur la base d'une super-classe, dans le second cas, il peut y avoir plusieurs super-classes. Si un héritage de classe unique est pris en charge dans un langage ou un système, l'ensemble de classes forme une hiérarchie. Tout en conservant plusieurs héritages, les classes sont connectées dans un graphe dirigé à une racine, appelée réseau de classes. Un objet de sous-classe est considéré appartenir à une superclasse de cette classe.

Les bases de données orientées objet sont les plus largement utilisées dans des domaines tels que les systèmes de conception / production assistée par ordinateur (CAO / FAO), les systèmes de développement de logiciels assisté par ordinateur (CASE), les systèmes de gestion de documents composés, par exemple dans les zones non traditionnelles pour les bases de données. POET, Jasmine, Versant, Iris, Orion sont des exemples de SGBD orientés objet.

2.2.4 Modèle de données relationnel

En 1970, le mathématicien américain Codd E.F. a publié un article révolutionnaire dans son contenu, proposant d'utiliser la théorie des ensembles pour le traitement des données. Il a fait valoir que les données devaient être liées en fonction de leurs relations logiques (par exemple, l'union, l'intersection) et non des pointeurs physiques. Il a proposé un modèle de données simple dans lequel toutes les données sont résumées dans des tableaux composés de lignes et de colonnes portant des noms uniques. Ces tables s'appellent relations (relation), et le modèle s'appelle le modèle de données relationnel, construit sur le concept de relations mathématiques et s'appelle parfois le modèle de Codd. Les propositions de Codd étaient si efficaces pour les systèmes de base de données que ce modèle lui valut le prestigieux prix Turing dans le domaine des fondements théoriques de la technologie informatique.

Dans les bases de données relationnelles, toutes les données sont stockées dans des tables simples, divisées en lignes (appelées enregistrements) et en colonnes (elles sont appelées champs), à l'intersection desquelles se trouvent des informations sur les données. En termes généraux, cela peut être représenté comme sur la Fig. 4

Fig. 4 Table de base de données relationnelle.

Chaque colonne a son propre nom. Par exemple, dans le tableau «Biens en stock» (Fig. 5.), les noms de champ sont les suivants: ID, Produit, Nom du groupe, Le groupe, Unité, Prix \u200b\u200bd'achat, Prix \u200b\u200bde vente, Stock Disponibilité.

Fig. 5. Tableau “Marchandises dans l'entrepôt »

Toutes les valeurs d'une colonne sont du même type. Ainsi, les champs sont diverses caractéristiques (parfois, ils disent - attributs) d’un objet. Les valeurs de champ sur la même ligne font référence au même objet et les différents champs ont des noms différents.

Chaque enregistrement est distingué par une clé d'enregistrement unique, de deux types: primaire et secondaire.

Clé primaire  - Il s'agit d'un ou de plusieurs champs identifiant l'enregistrement de manière unique. Si la clé primaire comprend un seul champ, on l'appelle simple, s'il provient de plusieurs champs: une clé composite.

Clé secondaire  - il s'agit d'un champ dont la valeur peut être répétée dans plusieurs enregistrements d'un fichier, c'est-à-dire qu'il n'est pas unique.

Clé étrangère  une table subordonnée est la clé secondaire d'une relation donnée, qui sert en même temps de clé primaire dans la table principale. Si par la valeur de la clé primaire une seule instance d'enregistrement peut être trouvée, alors par la valeur de la clé étrangère plusieurs (Fig. 6).

Fig. 6 Exemple d'utilisation d'une clé étrangère

En règle générale, une base de données relationnelle se compose de plusieurs tables, comme Combiner dans une même table toutes les informations nécessaires aux employés (utilisateurs de bases de données) de toute organisation pour résoudre les problèmes est impossible.

L’indexation est un moyen efficace d’accès par clé à une entrée de fichier. Lors de l'indexation, un fichier supplémentaire est créé qui contient sous une forme ordonnée toutes les valeurs de la clé de fichier de données. Pour chaque clé, le fichier d'index contient un pointeur sur l'entrée de fichier de données correspondante. En utilisant le pointeur sur un enregistrement du fichier de données, un accès direct à cet enregistrement est fourni.

Pour travailler avec des bases de données relationnelles, le langage SQL (Structured Query Language) est couramment utilisé. C'est le langage utilisé pour créer, modifier et gérer les données. SQL n'est pas un langage de programmation algorithmique. Ceci est un langage logique d'informations, basé sur l'algèbre relationnelle et divisé en trois parties:

· Opérateurs de définition de données;

· Opérateurs de manipulation de données (Insérer, Sélectionner, Mettre à jour, Supprimer);

· Opérateurs pour déterminer l'accès aux données.

En 1986, le langage SQL a été adopté comme norme ANSI (American National Standards Institute) pour les langages de bases de données relationnelles. Aujourd'hui, cette base de données est considérée comme une norme pour les systèmes d'information modernes.

Ainsi, une table est le type principal de structure de données d'un modèle relationnel. La structure de la table est déterminée par l'ensemble des colonnes. Chaque ligne de la table contient une valeur dans la colonne correspondante. Une table ne peut pas avoir deux lignes identiques, le nombre total de lignes est illimité. Une colonne est un élément de données, chaque colonne a un nom. Un ou plusieurs attributs dont les valeurs identifient de manière unique une ligne de la table sont la clé de la table.

Les avantages du modèle relationnel sont les suivants:

Simplicité et accessibilité de la compréhension par l'utilisateur final - la seule conception informationnelle est un tableau;

Lors de la conception d'une base de données relationnelle, des règles strictes sont appliquées en fonction de l'appareil mathématique;

Indépendance totale des données. Lorsque la structure est modifiée, les modifications à effectuer dans les programmes d'application sont minimes.

Pour créer des requêtes et écrire des programmes d'application, il n'est pas nécessaire de connaître l'organisation spécifique de la base de données dans la mémoire externe.

Les inconvénients du modèle relationnel sont les suivants:

Vitesse d'accès relativement faible et grande quantité de mémoire externe;

Difficulté à comprendre la structure des données en raison de l’apparition d’un grand nombre de tables résultant de la conception logique;

Loin d'être toujours le sujet peut être représenté comme un ensemble de tables.

Les bases de données relationnelles sont actuellement les plus utilisées. Les modèles réseau et hiérarchiques sont considérés comme obsolètes, les modèles orientés objet n’ayant pas encore été normalisés et peu utilisés.

Modèle de données orienté objet

Un modèle de données orienté objet est une extension des dispositions de la programmation orientée objet (alors que le modèle relationnel est né de la théorie des ensembles, à savoir d'un modèle de données). Le groupe de gestion de base de données orienté objet a développé la norme ODMG-93 (groupe de gestion de base de données d'objets). Cette norme n'a pas encore été pleinement mise en œuvre.

La structure d'une base de données orientée objet peut être représentée graphiquement sous la forme d'un arbre dont les nœuds sont des objets. La structure visible d'un objet est déterminée par les propriétés de sa classe. Classe  inclut les objets, tandis que la structure et le comportement des objets de la même classe sont identiques. Chaque objet, à savoir une instance d'une classe, est considéré comme un descendant de l'objet dans lequel il est défini en tant que propriété. Propriétés de l'objet  - soit un type standard, par exemple, chaîne, ou un type de classe construit par l'utilisateur. Le comportement des objets est défini à l'aide de méthodes. Méthode  Est une opération qui peut être appliquée à un objet.

A titre d'exemple, considérons la base de données LIBRARY (Fig. 4.4). Pour chaque objet, les propriétés, leurs types et leurs valeurs sont définis. Dans le DB:

“LIBRARY” - parent (ancêtre) pour “ABONNEMENT”, “CATALOGUE”, “ISSUE”;

"CATALOGUE" - le parent du "LIVRE".

“LIVRE” - divers objets peuvent avoir un ou plusieurs parents. Si le même parent (un auteur), les numéros d'inventaire sont différents, mais isbn, UDC, title et author sont identiques.

La structure logique d'une base de données orientée objet est similaire à celle hiérarchique, la principale différence réside dans les méthodes de manipulation des données. Vous pouvez effectuer des actions telles que des opérations logiques sur la base de données, améliorées par des méthodes d'encapsulation, d'héritage et de polymorphisme orientées objet.

Encapsulation  limite la portée du nom de la propriété à l'objet dans lequel elle est définie. Donc, si une propriété est ajoutée au "CATALOGUE" le téléphone  l'auteur du livre, il est obtenu de la même manière dans "SUBSCRIBE" et "CATALOG". La signification de la propriété sera déterminée par l'objet dans lequel elle est encapsulée.

L'héritageau contraire, étend la portée de la propriété à tous les descendants de l'objet. Ainsi, tous les objets de type "BOOK", descendants du "CATALOGUE", peuvent être attribués aux propriétés du parent isbn, UDC, nom et auteur.

Polyformisme  signifie que le même code de programme peut fonctionner avec des données hétérogènes. En d'autres termes, cela signifie qu'il est permis à des objets de types différents d'avoir des méthodes - procédures et fonctions - avec le même nom. Lors de l'exécution d'un programme objet, les mêmes méthodes s'appliquent à différents objets en fonction du type d'argument. Pour la base de données LIBRARY, cela signifie que les objets de la classe BOOK ayant des parents différents de ceux de la classe CATALOG peuvent avoir un ensemble de propriétés différent, c'est-à-dire Les programmes permettant de travailler avec un objet de la classe «BOOK» peuvent contenir un code polymorphe. Dans une classe, une méthode n’a pas de corps, c’est-à-dire qu’elle ne détermine pas les actions spécifiques qu’elle doit effectuer. Chaque sous-classe effectue les opérations nécessaires. Encapsulation masque les détails d'implémentation de tous les objets en dehors de la hiérarchie donnée.

Les avantages d'un modèle orienté objet par rapport au modèle relationnel sont la possibilité d'afficher des informations sur les relations complexes des objets, l'absence de limitations dans les structures de stockage de données. Une base de données orientée objet peut stocker non seulement la structure, mais également les aspects comportementaux des données. En utilisant une approche orientée objet, il est possible de créer des bases de données contenant de grandes quantités d’informations sémantiques, telles que le multimédia et spécialisées dans des domaines spécifiques (géographique, conception, etc.).

Les inconvénients de cette approche sont la complexité conceptuelle élevée, les inconvénients du traitement des données et la rapidité d'exécution des requêtes.

Dans les années 90, des prototypes de bases de données existantes orientées objet ont été créés. Ce sont POET (logiciel de POET), JASMINE (ASSOCIÉS INFORMATIQUES), IRIS, ORION, POSTGRES.

Thème 5

L'approche relationnelle dans la construction d'un modèle logique de l'information: concepts de base

Modèle de données relationnel. Concepts de base

Comme indiqué dans la section précédente, le modèle relationnel est actuellement l'un des modèles les plus courants sur le marché des bases de données. La base de ce modèle est un ensemble de tables (relations) interconnectées.

Les principales idées théoriques du modèle relationnel ont été présentées dans les travaux sur la théorie des relations du logicien américain Charles Soders Pierce (1839-1914) et du logicien allemand Ernst Schroeder (1841-1902), ainsi que du mathématicien américain Edgar Codd.

Dans les travaux de Pierce et Schroeder, il a été prouvé que de nombreuses relations sont fermées en ce qui concerne certaines opérations spéciales qui forment ensemble une algèbre abstraite. Cette propriété des relations la plus importante a été utilisée dans le modèle relationnel pour développer un langage de manipulation de données.

En 1970, un article de E. Codd est paru sur la présentation de données organisées sous forme de tableaux bidimensionnels appelés relations. Pour la première fois, Codd a introduit les concepts de base et les limites du modèle relationnel en tant que base pour le stockage de données et a montré la possibilité de traiter des données à l'aide d'opérations traditionnelles sur des ensembles et d'opérations relationnelles introduites spéciales.

Les concepts de base du modèle relationnel sont donnés dans le tableau. 3.1.

Les objets du modèle relationnel sont principalement des tables (relations). L'intégrité des données est assurée par des clés étrangères et primaires (voir p. "Intégrité des données relationnelles").

Les opérateurs d'un modèle relationnel sont un ensemble d'instructions permettant l'échantillonnage et la manipulation de données.

Tableau 5.1. Éléments du modèle relationnel

La structure de données du modèle relationnel implique de représenter le domaine du problème en question sous la forme d'un ensemble de relations interdépendantes.

Dans chaque relation, une relation peut agir en tant que principale (base, parent) et l'autre en tant que subordonné (dérivé, fille). Pour maintenir ces relations, les deux relations doivent contenir un ensemble d'attributs par lesquels elles sont liées: dans la relation principale, il s'agit de la clé primaire de la relation (détermine uniquement le tuple de la relation principale); dans une relation subordonnée, il doit exister un ensemble d'attributs correspondant à la clé primaire de la relation principale. Ici, cet ensemble d'attributs est déjà une clé secondaire ou une clé étrangère, c'est-à-dire définit un ensemble de tuples d'une relation dérivée, associée à un seul tuple de la relation principale.

Beaucoup de tables interconnectées forment schéma de base de données.

Donc l'attitude R  est un tableau à deux dimensions contenant des données.

Mathématiquement Nrelation -ary R  Est-ce une multitude de produits cartésiens D 1 × D 2 ×… × D n  ensembles (domaines) D 1, D 2, ..., D n(n≥1), éventuellement différent:

R D 1 × D 2 × ... × D n,

où D 1 × D 2 ×… × D n  Est le produit cartésien complet, c'est-à-dire un ensemble de différentes combinaisons de n éléments, chaque élément étant extrait de son domaine.

Domainereprésente un concept sémantique, qui peut être considéré comme un sous-ensemble des valeurs d'un certain type de données ayant une certaine signification.

Propriétés du domaine:

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

Défini sur un type de données simple ou sur un autre domaine,

Il peut avoir certaines conditions logiques nous permettant de décrire un sous-ensemble des données valides pour ce domaine,

Il porte une certaine charge sémantique.

La signification première des domaines est qu'ils limitent les comparaisons: vous ne pouvez pas comparer les valeurs de différents domaines, même s'ils ont le même type de données.

Attribut  la relation est une paire de genre

<Имя_атрибута: Имя_домена>  (ou<A: D>).

Les noms d'attributs dans une relation sont uniques. Les noms d'attributs correspondent souvent aux noms des domaines correspondants.

La relation R définie sur de nombreux domaines contient deux parties: l'en-tête et le corps.

En-tête de relation  - un nombre fixe d'attributs de relation décrivant le produit cartésien des domaines sur lesquels la relation est donnée:

(<A 1: D 1>, <A 2: D 2 >, …, <A n: D n>).

Le titre est statique: il ne change pas lorsque vous travaillez avec la base de données.Si les relations sont modifiées, des attributs ajoutés, supprimés, nous obtenons une relation différente. Même avec le nom enregistré.

Du corps relations contient de nombreux nuplets de relations.

Chaque cortège  représente beaucoup de paires de la forme:

<Имя_атрибута: Значение атрибута>:

R(<A 1: Val 1>, <A 2: Val 2 >, …, <A n: Val n>).

Tel que le sens Val i  attribuer Un je  appartient au domaine D i.

Un corps de relation est une collection de n-uplets, c’est-à-dire un sous-ensemble du produit cartésien de domaines. Ainsi, le corps d'une relation est en réalité une relation au sens mathématique du mot. Le corps de la relation peut changer tout en travaillant avec la base de données, car K. tuples peut changer, ajouter et supprimer au fil du temps.

Le rapport est généralement écrit comme:

R(<A 1: D 1>, <A 2: D 2 >, …, <A n: D n>),

soit abrégé: R(Un 1, Un 2, …, A n) ou R.

Modèle de relation  Il s’agit d’un ensemble d’en-têtes de relation inclus dans la base de données, c’est-à-dire une liste de noms d’attributs pour cette relation avec le domaine auquel ils appartiennent:

S R \u003d(Un 1, Un 2, …, A n), A i D i, je = 1, ..., n.

Si les attributs prennent des valeurs du même domaine, ils sont alors appelés θ-comparables, où θ est l'ensemble des opérations de comparaison valides spécifiées pour ce domaine.

Par exemple, si un domaine contient des données numériques, toutes les opérations de comparaison lui sont valides: θ \u003d\u003d (\u003d,<>,>=,<=,<,>) Toutefois, pour les domaines contenant des données symboliques, les opérations de comparaison ne peuvent pas uniquement être spécifiées pour l'égalité et l'inégalité des valeurs. Si un ordre lexicographique est spécifié pour un domaine donné, il comporte également un ensemble complet d'opérations de comparaison.

Les schémas de deux relations s'appellent équivalents’ils ont le même degré et qu’il est possible d’organiser des noms d’attributs dans des schémas tels que des attributs comparables se trouvent au même endroit, c’est-à-dire des attributs prenant des valeurs du même domaine.

Ainsi, pour des relations équivalentes, les conditions suivantes sont remplies:

La présence du même nombre d'attributs;

La présence d'attributs portant le même nom;

La présence dans les relations des mêmes lignes, étant donné que l'ordre des attributs peut varier;

Les relations de ce type sont des images différentes de la même relation.

Propriétés de la relation  découlent directement de la définition d'une relation donnée précédemment. Ces propriétés comprennent essentiellement les différences entre les relations du modèle de données relationnel et des tables simples:

L'unicité du nom de la relation. Le nom d'une relation doit être différent de celui des autres relations.

L'unicité des tuples. En relation, il n'y a pas de nuplets identiques. En effet, le corps d’une relation est constitué d’une multitude de n-uplets et, comme toute multitude, ne peut contenir d’éléments indiscernables. Les tables, contrairement aux relations, peuvent contenir les mêmes lignes. Chaque cellule d'une relation ne contient qu'une valeur atomique (indivisible).

Le désordre des tuples. Les n-uplets ne sont pas ordonnés (de haut en bas), car le corps de la relation est un ensemble et cet ensemble n'est pas ordonné (pour la comparaison, les lignes des tables sont ordonnées). La même relation peut être représentée par différentes tables, dans lesquelles les lignes vont dans un ordre différent.

Attributs désordonnés. Les attributs ne sont pas ordonnés (de gauche à droite).

L'unicité d'un nom d'attribut dans une relation. Chaque attribut a un nom unique dans la relation, ce qui signifie que l'ordre des attributs n'a pas d'importance (pour la comparaison, les colonnes de la table sont ordonnées). Cette propriété distingue quelque peu la relation de la définition mathématique de la relation. La même relation peut être représentée par différentes tables, dans lesquelles les colonnes sont placées dans un ordre différent.

Atomicité des valeurs d'attribut. Toutes les valeurs d'attribut sont atomiques. Cela découle du fait que les attributs sous-jacents ont des valeurs atomiques, c’est-à-dire qu’un certain intervalle de valeurs (un type élémentaire distinct) est associé à chaque démarrage, les valeurs d’attribut sont tirées du même domaine. Le schéma de relation et les n-uplets sont des ensembles et non des listes. Par conséquent, l'ordre dans lequel ils sont présentés n'a pas d'importance. À des fins de comparaison, diverses informations peuvent être placées dans les cellules du tableau: tableaux, structures, autres tableaux, etc.

Note:

Il découle des propriétés de la relation que pas tous  la table peut être un ratio. Pour qu'une table définisse une relation, il est nécessaire que la table ait une structure simple (elle ne contient que des lignes et des colonnes, et chaque ligne doit avoir le même nombre de champs), la table ne doit pas avoir les mêmes lignes, aucune colonne de la table ne doit contenir de données d'un seul type. , tous les types de données utilisés doivent être simples.

Il convient de noter que le modèle relationnel est une base de données sous la forme de nombreuses relations interdépendantes, appelées schéma de base de données relationnelle.