introduction

L'émergence de la direction des bases de données orientées objet (OODB) a été déterminée, tout d'abord, par les besoins de la pratique : la nécessité de développer des systèmes applicatifs d'information complexes pour lesquels la technologie des systèmes de bases de données antérieurs n'était pas entièrement satisfaisante. Bien sûr, OODB n'est pas sorti de nulle part. La base correspondante a été fournie à la fois par des travaux antérieurs dans le domaine des bases de données et par les domaines en développement de longue date des langages de programmation avec des types de données abstraits et des langages de programmation orientés objet.

En ce qui concerne la relation avec les travaux antérieurs dans le domaine des bases de données, l'influence la plus puissante sur les travaux dans le domaine de l'OODB a été le développement du SGBD et la prochaine famille de bases de données chronologiquement suivante, dans laquelle la gestion d'objets complexes était prise en charge. Ces activités ont fourni la base structurelle de l'organisation OOBD. Dans ce résumé, OOMD et OODBMS seront considérés.

Modèle de données orienté objet

Considérez l'une des approches pour créer une base de données - en utilisant 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. ODM est généralement utilisé dans des domaines complexes qui n'ont pas la fonctionnalité du modèle relationnel pour la modélisation (par exemple, pour les systèmes d'automatisation de la conception (CAO), les systèmes de publication, etc.).

Le modèle de données orienté objet ODMG diffère des autres modèles, tout d'abord, par un aspect fondamental. Dans le modèle de données SQL et le vrai modèle de données relationnelles, une base de données est un ensemble de conteneurs de données nommés du même type générique : des tables ou des relations, respectivement. Dans le modèle de données orienté objet, une base de données est une collection d'objets (conteneurs de données) d'un type arbitraire.

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

encastrement dans le langage orienté objet de moyens destinés à travailler avec une 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 une base de données;

création d'un nouveau langage et d'un nouveau modèle de données orienté objet.

Les avantages d'OOMD incluent de nombreuses possibilités de modélisation du domaine, un langage de requête expressif et des performances élevées. Chaque objet de l'OOMD a un identifiant unique (OID - object identifier). Les recherches d'OID sont nettement plus rapides que les recherches de table relationnelle.

Parmi les inconvénients de l'OOMD, il faut noter l'absence d'un modèle généralement admis, le manque d'expérience dans la création et l'exploitation de l'OODB, la complexité d'utilisation et l'insuffisance des moyens de protection des données.

Voyons maintenant comment la prise en charge des modèles de données est implémentée dans les systèmes de gestion de bases de données réels.

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

Le MOO standard est décrit dans les recommandations de la norme ODMG-93 (Object Database Management Group). Les recommandations de l'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.

La structure de la base de données OO est représentée graphiquement sous la forme d'un arbre dont les nœuds sont des objets. Les propriétés d'objet sont décrites par un type standard (par exemple, un type chaîne) ou un type construit par l'utilisateur (défini comme une 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 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 en tant que propriété. Un objet 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 liés.

Le premier modèle de données formalisé et généralement accepté était le modèle relationnel de Codd. Dans ce modèle, comme dans tous les suivants, trois aspects ont été distingués - structurel, holistique et manipulateur. Les structures de données dans le modèle relationnel sont basées sur des relations normalisées plates, les contraintes d'intégrité sont exprimées en utilisant la logique du premier ordre et, enfin, la manipulation des données est basée sur l'algèbre relationnelle ou son calcul relationnel équivalent. Comme le notent de nombreux chercheurs, le modèle de données relationnelles doit une grande partie de son succès au fait qu'il reposait sur l'appareil mathématique rigoureux de la théorie des ensembles, des relations et de la logique du premier ordre. Les concepteurs de tout système relationnel particulier considéraient qu'il était de leur devoir de montrer que leur modèle de données particulier correspondait au modèle relationnel général, qui agissait comme une mesure de la « relationnalité » du système.

Les principales difficultés de la modélisation de données orientée objet proviennent du fait qu'il n'existe pas d'appareil mathématique développé sur lequel un modèle de données général orienté objet pourrait s'appuyer. Dans une large mesure, il n'existe donc toujours pas de modèle de base orienté objet. D'autre part, certains auteurs soutiennent que le modèle de données général orienté objet au sens classique ne peut pas être défini en raison de l'inadéquation du concept classique du modèle de données au paradigme de l'orientation objet.

L'un des plus célèbres théoriciens des modèles de données, Beeri, propose un aperçu d'un cadre formel pour OODB, qui est loin d'être complet et n'est pas un modèle de données au sens traditionnel du terme, mais permet aux chercheurs et développeurs de systèmes OODB de parler au moins un langue (à moins, bien sûr, que des phrases Beeri ne soient développées et prises en charge). Quel que soit le sort futur de ces propositions, nous jugeons utile de les résumer brièvement.

Tout d'abord, suivant la pratique de nombreux OODB, il est proposé de distinguer deux niveaux de modélisation objet : inférieur (structural) et supérieur (comportemental). Au niveau structurel, les objets complexes, leur identification et les types de communication "isa" sont pris en charge. Une base de données est un ensemble d'éléments de données liés par la relation « appartient à une classe » ou « est un attribut ». Ainsi, la DB peut être considérée comme un graphe orienté. Un point important est de maintenir, avec le concept d'objet, le concept de sens (nous verrons plus tard tout ce qui est construit là-dessus dans l'un des SGBD orienté objet à succès O2).

Un aspect important est une séparation claire du schéma de la base de données et de la base de données elle-même. Les principaux concepts du niveau de schéma OODB sont les types et les classes. On constate que dans tous les systèmes n'utilisant qu'un seul concept (soit un type, soit une classe), ce concept est inévitablement surchargé : un type suppose la présence d'un certain ensemble de valeurs déterminé par la structure de données de ce type ; une classe suppose également un ensemble d'objets, mais cet ensemble est défini par l'utilisateur. Ainsi, les types et les classes jouent des rôles différents, et pour la rigueur et l'absence d'ambiguïté, il est nécessaire de prendre en charge les deux concepts en même temps.

Beeri ne présente pas un modèle formel complet du niveau structurel OODB, mais exprime sa confiance que le niveau actuel de compréhension est suffisant pour formaliser un tel modèle. Quant au niveau comportemental, seule une approche générale de l'appareil logique requis pour cela est proposée (la logique du premier niveau ne suffit pas).

Une hypothèse importante, quoique insuffisamment étayée, de Beeri est que les deux couches traditionnelles - schéma et données - ne suffisent pas pour OODB. Pour définir avec précision un OODB, un niveau de méta-schéma est requis, dont le contenu doit définir les types d'objets et de relations qui sont autorisés au niveau du schéma de la base de données. Le méta-schéma devrait jouer le même rôle pour les OODB que la partie structurelle du modèle de données relationnelles le fait pour les schémas de bases de données relationnelles.

Il existe de nombreuses autres publications liées au sujet des modèles de données orientés objet, mais elles touchent soit à des problèmes assez spécifiques, soit utilisent un appareil mathématique trop sérieux pour cette revue (par exemple, certains auteurs définissent un modèle de données orienté objet basé sur la théorie des catégories).

Pour illustrer l'état actuel des choses, nous examinerons brièvement les caractéristiques d'un modèle de données spécifique utilisé dans le SGBD orienté objet O2 (ceci, bien sûr, n'est pas non plus un modèle de données au sens classique).

O2 prend en charge les objets et les valeurs. Un objet est un couple (identifiant, valeur), et les objets sont encapsulés, c'est-à-dire leurs valeurs ne sont accessibles que par des méthodes - procédures liées à des objets. Les valeurs peuvent être atomiques ou structurelles. Les valeurs structurelles sont construites à partir de valeurs ou d'objets représentés par leurs identifiants à l'aide des constructeurs set, tuple et list. Les membres de valeur structurelle sont accessibles à l'aide d'opérations prédéfinies (primitives).

Il existe deux types d'organisation des données : les classes, qui sont instanciées par des objets qui encapsulent les données et le comportement, et les types, dont les instances sont des valeurs. Chaque classe est associée à un type qui décrit la structure des instances de la classe. Les types sont définis de manière récursive à partir de types atomiques et de types et classes précédemment définis à l'aide de constructeurs. Le côté comportemental d'une classe est déterminé par un ensemble de méthodes.

Les objets et les valeurs peuvent être nommés. Le nommage d'un objet ou d'une valeur est associé à sa persistance : tous les objets ou valeurs nommés sont persistants ; tout objet ou valeur faisant partie d'un autre objet ou valeur nommé est durable.

À l'aide d'une instruction spéciale donnée lors de la définition d'une classe, vous pouvez réaliser un stockage à long terme de tout objet de cette classe. Dans ce cas, le système génère automatiquement une valeur de consigne dont le nom est le même que le nom de la classe. Cet ensemble est garanti pour contenir tous les objets de cette classe.

Méthode - code de programme lié à une classe spécifique et applicable aux objets de cette classe. La détermination de la méthode en O2 s'effectue en deux étapes. Tout d'abord, la signature de la méthode est déclarée, c'est-à-dire son nom, sa classe, ses types d'arguments ou ses classes et son type ou sa classe de résultat. Les méthodes peuvent être publiques (accessibles à partir d'objets d'autres classes) ou privées (accessibles uniquement dans cette classe). À la deuxième étape, la mise en œuvre de la classe dans l'un des langages de programmation O2 est déterminée (les langages sont discutés plus en détail dans la section suivante de notre revue).

Le modèle O2 prend en charge l'héritage de classes multiples basé sur la relation supertype/sous-type. La sous-classe est autorisée à ajouter et/ou remplacer des attributs et des méthodes. Les ambiguïtés possibles dans l'héritage multiple (dans le nommage des attributs et des méthodes) sont résolues soit en renommant, soit en spécifiant explicitement la source de l'héritage. Un objet de sous-classe est un objet de chaque superclasse dont la sous-classe est dérivée.

La classe prédéfinie « Objet » est prise en charge, qui est la racine du réseau de classes ; toute autre classe est un héritier implicite de la classe "Object" et hérite des méthodes prédéfinies ("is_same", "is_value_equal", etc.).

Une caractéristique spécifique du modèle O2 est la possibilité de déclarer des attributs et des méthodes "exclusifs" supplémentaires pour les objets nommés. Cela signifie qu'un objet représentatif nommé particulier d'une classe peut avoir un type qui est un sous-type du type de la classe. Bien sûr, les méthodes de classe standard ne fonctionnent pas avec de tels attributs, mais des méthodes supplémentaires (ou standard) peuvent être définies spécifiquement pour un objet nommé, pour lequel des attributs supplémentaires sont déjà disponibles. Il est souligné que des attributs et des méthodes supplémentaires ne sont pas attachés à un objet spécifique, mais à un nom, derrière lequel à différents moments, en général, différents objets peuvent se tenir. Le développement de techniques de liaison tardive est nécessaire pour implémenter des attributs et des méthodes exclusifs.

Dans la section suivante, nous examinerons, entre autres, les caractéristiques des langages de programmation et des requêtes du système O2, qui, bien sûr, sont étroitement liées aux spécificités du modèle de données.

Concepts de base

Définition 1

Modèle Orienté Objet la présentation des données permet d'identifier les enregistrements individuels de la base de données.

Les enregistrements de la base de données et leurs fonctions de traitement sont liés par des mécanismes similaires aux outils correspondants qui sont implémentés dans les langages de programmation orientés objet.

Définition 2

Représentation graphique une structure de base de données orientée objet est un arbre dont les nœuds représentent des objets.

Type standard (par exemple, chaîne - chaîne de caractères) ou un type créé par l'utilisateur ( classer), décrit propriétés de l'objet.

Dans la figure 1, l'objet LIBRARY est le parent des objets d'instance DIRECT, SUBSCRIBER et REFERENCE. Différents objets de type LIVRE peuvent avoir un ou plusieurs parents. Les objets de type LIVRE qui ont le même parent doivent avoir au moins des numéros d'inventaire différents (uniques pour chaque exemplaire du livre), mais les mêmes valeurs de propriété auteur, Titre, udk et isbn.

Les structures logiques d'une base de données orientée objet et d'une base de données hiérarchique sont superficiellement similaires. Ils diffèrent principalement par les méthodes de manipulation des données.

Lors de l'exécution d'actions sur des données dans le modèle orienté objet, des opérations logiques sont utilisées, qui sont renforcées par l'encapsulation, l'héritage et le polymorphisme. Avec certaines limitations, vous pouvez utiliser des opérations similaires aux commandes SQL (par exemple, lors de la création d'une base de données).

Lors de la création et de la modification de la base de données, la formation automatique et l'ajustement ultérieur des index (tables d'index), qui contiennent des informations pour une récupération rapide des données, sont effectués.

Définition 3

Cibler encapsulations- limiter la portée du nom de propriété aux limites de l'objet dans lequel il est défini.

Par exemple, si une propriété est ajoutée à l'objet DIRECTORY qui définit le numéro de téléphone de l'auteur et porte le nom Téléphone, alors les propriétés du même nom seront obtenues pour les objets DIRECTORY et SUBSCRIBER. La signification d'une propriété est déterminée par l'objet dans lequel elle est encapsulée.

Définition 4

Héritage, inversement encapsulant, est chargé d'étendre la portée de la propriété relative à tous les descendants de l'objet.

Par exemple, tous les objets BOOK descendants de l'objet DIRECTORY peuvent se voir attribuer les propriétés de l'objet parent : auteur, Titre, udk et isbn.

S'il est nécessaire d'étendre l'action du mécanisme d'héritage à des objets qui ne sont pas des parents immédiats (par exemple, deux descendants du même parent), une propriété de type abstrait est définie dans leur ancêtre commun abdos.

Donc les propriétés pièce et billet dans l'objet LIBRARY sont hérités par tous les objets enfants REFERENCE, BOOK et SUBSCRIBER. C'est pourquoi les valeurs de cette propriété des classes SUBSCRIBER et OUTPUT sont les mêmes - 00015 (Figure 1).

Définition 5

Polymorphisme permet au même code de programme de fonctionner avec différents types de données.

En d'autres termes, il permet à des objets de types différents d'avoir des méthodes (fonctions ou procédures) avec les mêmes noms.

Chercher dans une base de données orientée objet, il s'agit de déterminer la similitude entre l'objet que l'utilisateur spécifie et les objets qui sont stockés dans la base de données.

Avantages et inconvénients du modèle orienté objet

Le principal avantage Le modèle de données orienté objet, contrairement au modèle relationnel, consiste en la capacité d'afficher des informations sur les relations complexes entre les objets. Le modèle de données considéré permet de définir un enregistrement de base de données séparé et les fonctions de son traitement.

À désavantages Le modèle orienté objet se caractérise par une complexité conceptuelle élevée, un traitement des données peu pratique et une vitesse de requête faible.

Aujourd'hui, de tels systèmes sont assez répandus. Ceux-ci incluent les SGBD :

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Objectivité / DB,
• Magasin d'objets,
• Statique,
• Gemme
• Base G.

04/06/2004 Siha Bagui

Le développement de systèmes de bases de données orientés objet a commencé au milieu des années 1980 en réponse au besoin de répondre aux exigences d'applications autres que celles maintenues et maintenues par les systèmes de bases de données relationnelles. Considérez les progrès de la technologie des bases de données orientées objet, ainsi que les défis que la communauté du développement doit encore résoudre pour que la technologie des bases de données orientées objet soit aussi répandue que la technologie des bases de données relationnelles.

Le développement des systèmes de bases de données orientés objet (les technologies de bases de données dites de cinquième génération) a commencé au milieu des années 80 en relation avec la nécessité de satisfaire les exigences d'applications autres que les applications informatiques caractéristiques des systèmes de bases de données relationnelles (quatrième technologie de base de données de génération). génération). Tente d'utiliser des technologies de bases de données relationnelles dans des applications aussi complexes que la conception assistée par ordinateur (CAO) ; fabrication assistée par ordinateur (FAO); technologie de programmation; les systèmes basés sur la connaissance et les systèmes multimédias ont exposé les limites des systèmes bases de données relationnelles (RDB)... Avec l'émergence d'une nouvelle génération d'applications de bases de données, des besoins sont apparus qui sont mieux satisfaits en utilisant bases de données orientées objet (OODB).

De nombreuses définitions de l'orientation objet et des bases de données orientées objet ont été proposées, mais nous définirons les bases de données orientées objet comme des bases de données qui combinent l'orientation objet avec les capacités des bases de données. Orientation de l'objet permet de représenter et de modéliser plus directement des problèmes dans le monde réel, et fonctionnalité de base de données requis pour assurer la stabilité des données et l'accès simultané multi-utilisateurs aux informations de l'application.

Actuellement, il existe plus de 25 systèmes OODB sur le marché. Ceux-ci incluent GemStone de Servio, ONTOS d'Ontos, ObjectStore d'Object Design et bien d'autres. De plus, les systèmes de gestion de bases de données relationnelles développés par Oracle, Microsoft, Borland, Informix incluaient des outils orientés objet. Beaucoup de ces produits sont apparus dans la seconde moitié des années 1980, et aujourd'hui, après près d'une décennie et demie de développement, ils n'ont pas encore atteint leur maturité ; c'est l'une des raisons pour lesquelles le marché mondial des applications du monde réel a été lent à adopter les systèmes OODB à ce jour. Parmi les OODB modernes, il n'y a presque pas de systèmes à part entière comparables aux systèmes de bases de données relationnelles modernes. Discutons des principales réalisations et problèmes liés à l'état actuel de l'OODB.

modèle OODB

La raison de l'émergence des systèmes de bases de données orientées objet était le besoin d'une représentation et d'une modélisation plus adéquates des entités du monde réel, car les OODB fournissent un modèle de données beaucoup plus avancé que les bases de données relationnelles traditionnelles. Le paradigme OODB est basé sur un certain nombre de concepts de base tels que l'objet, l'identifiabilité, la classe, l'héritage, la surcharge et la liaison paresseuse.

Dans le modèle de données orienté objet, toute entité du monde réel est représentée par un seul concept - objet... L'état et le comportement sont associés à un objet. L'état d'un objet est déterminé par les valeurs de ses propriétés - les attributs... Les valeurs de propriété peuvent être des valeurs primitives (telles que des chaînes ou des entiers) et des objets non primitifs. Un objet non primitif, à son tour, se compose d'un ensemble de propriétés. Par conséquent, les objets peuvent être définis de manière récursive en termes d'autres objets. Le comportement d'un objet est défini à l'aide de méthodes, qui agissent sur l'état de l'objet.

Chaque objet a un système défini identifiant unique... Les objets ayant les mêmes propriétés et le même comportement sont regroupés en Des classes... Un objet peut être une instance d'une seule classe ou de plusieurs classes.

Les classes sont organisées dans une hiérarchie de classes. La sous-classe hérite des propriétés et des méthodes de la superclasse ; en outre, les sous-classes peuvent avoir des propriétés et des méthodes individuelles. Dans certains systèmes, par exemple ORION, une classe peut avoir plusieurs superclasses (héritage multiple), tandis que dans d'autres systèmes le nombre de superclasses est limité à un (héritage unique).

La plupart des modèles permettent surcharge propriétés et méthodes héritées. La surcharge consiste à remplacer un domaine de propriété par un nouveau domaine, ou à remplacer une implémentation d'une méthode par une autre implémentation.

Avantages du modèle OODB

Les bases de données orientées objet vous permettent de représenter des objets complexes de manière plus directe que les systèmes relationnels. Arrêtons-nous sur quelques réalisations existantes dans le domaine de l'OODB. Les systèmes OODB permettent aux utilisateurs de définir des abstractions ; faciliter la conception de certains liens ; Élimine le besoin de clés définies par l'utilisateur prendre en charge un nouvel ensemble de prédicats de comparaison ; dans certains cas, éliminer le besoin de connexions ; dans certaines situations, offrir de meilleures performances que les systèmes basés sur le modèle relationnel ; fournir un support pour les versions et les transactions de longue durée. Enfin, l'algèbre d'objets a été développée - bien que peut-être pas encore avec autant de détails que l'algèbre relationnelle.

Définir des abstractions personnalisées

Les bases de données orientées objet offrent la possibilité de définir de nouvelles abstractions et de contrôler la mise en œuvre de telles abstractions. Ces nouvelles abstractions peuvent correspondre à des structures de données requises pour des tâches complexes, de nouveaux types de données abstraits. En d'autres termes, les packages OODB modernes permettent à l'utilisateur de créer une nouvelle classe avec des attributs et des méthodes, d'avoir des classes qui héritent des attributs et des méthodes des superclasses, de créer des instances de classe, chacune ayant un identifiant d'objet unique, de récupérer ces instances une à la fois ou en groupes, et charger et exécuter des méthodes. De plus, les OODB permettent de définir des objets en tant que collections d'autres objets, et plusieurs niveaux d'imbrication sont autorisés pour les collections. Les propriétés peuvent également être complexes et peuvent être définies à l'aide du constructeur de collection. De plus, ils peuvent avoir comme valeurs des objets non primitifs, ce qui permet de former des structures d'objets profondément imbriquées.

Les propriétés à valeurs multiples sont utilisées dans les modèles de données orientés objet pour exprimer des structures de données complexes. Dans le modèle relationnel, cela est accompli avec des relations et des jointures supplémentaires.

Un exemple de package OODB qui possède toutes les capacités ci-dessus est ENCORE. Le modèle de données dans ENCORE est basé principalement sur l'abstraction de données. ENCORE permet le sous-typage (héritage), l'encapsulation, les structures complexes, l'identification d'objets et la liaison de méthode paresseuse. De plus, ENCORE offre la possibilité de lier des objets à l'aide de propriétés. Dans le système ENCORE, la propriété p lie un objet x à un ensemble d'objets S sans aucune indication sur la façon dont le lien est calculé. Il peut être calculé en spécifiant directement l'identifiant de l'ensemble S (ou les identifiants de ses membres), ou en mappant les valeurs d'autres propriétés, comme dans une jointure.

Conception légère de certains liens

Les bases de données orientées objet prennent en charge une fonction de liaison inverse pour exprimer des liens réciproques entre deux objets (lien binaire). Un tel système assure l'intégrité référentielle en établissant une liaison retour appropriée immédiatement après la création de la liaison aller. Il existe même la possibilité de propager automatiquement les suppressions via ces liens. ObjectStore est un exemple de package OODB qui assure la maintenance automatique des relations inverses.

Pas besoin de clés définies par l'utilisateur

Le modèle OODB a le concept d'identifiants d'objets qui sont générés automatiquement par le système et sont garantis uniques pour chaque objet. Ceci, combiné au fait que le modèle OODB élimine le besoin de clés définies par l'utilisateur, fournit des bases de données orientées objet avec d'autres avantages. Premièrement, l'identifiant de l'objet ne peut pas être modifié par l'application. Deuxièmement, la notion d'identifiabilité de l'objet implique une notion d'identité distincte et cohérente, indépendante de la façon dont l'objet est accessible ou de la façon dont l'objet est modélisé à l'aide de données descriptives. Par conséquent, deux objets ne sont pas identiques s'ils ont des identifiants d'objet différents ; dans ce cas, les objets peuvent avoir les mêmes structures et toutes leurs propriétés - les mêmes valeurs. Dans le modèle RDB, où les objets sont identifiés par des clés définies par l'utilisateur, ces objets seraient considérés comme le même objet.

Prédicats de comparaison

Dans RDB, la comparaison est toujours basée sur des valeurs uniquement. Dans ce modèle, deux tuples sont une entité si tous leurs attributs clés ont la même valeur. Cependant, d'autres types de comparaison ont été développés et définis dans le modèle OODB.

1. L'égalité des objets en fonction de leur identité. Deux objets, S1 et S2 sont égaux s'ils sont le même objet (c'est-à-dire qu'ils ont le même ID d'objet).
2. L'égalité des objets basée sur les valeurs. Ceci peut être déterminé en deux étapes - (a) deux objets primitifs sont égaux s'ils ont la même valeur ; (b) deux objets non primitifs sont égaux s'ils ont le même nombre de propriétés, et pour chaque propriété pi de l'objet S1 il existe une propriété pj de l'objet S2 de valeur égale.
3. Égalité de propriété basée sur des valeurs.
4. L'égalité des biens en fonction de leur identité.

Moins besoin de connexions

La capacité de naviguer dans les structures d'objets et les expressions de chemin résultantes en termes d'attributs d'objets nous donnent une nouvelle perspective sur le problème des jointures dans les OODB. Une jointure relationnelle est un mécanisme qui mappe deux relations en fonction des valeurs des paires d'attributs correspondantes dans cette relation. Étant donné que deux classes d'un OODB peuvent avoir des paires d'attributs correspondantes, une jointure relationnelle (ou une jointure explicite) peut toujours être nécessaire dans ce modèle. Par exemple, disons que nous avons des classes Student et School, et chacune de ces classes a des attributs Name et Age. Bien que les domaines des attributs Name et Age de la classe School puissent ne pas correspondre aux domaines des attributs Name et Age de la classe Student, nous pouvons souhaiter associer ces classes en fonction des valeurs de ces attributs (disons trouver tous les élèves plus jeunes que l'âge de l'école que cet élève fréquente).

Mais, comme déjà noté, la prise en charge des expressions de chemin peut réduire considérablement le besoin de joindre des classes par rapport à la situation dans le RDB. Il existe même des situations dans lesquelles le besoin d'une jointure relationnelle peut être complètement éliminé. Par exemple, lorsque le domaine d'un attribut de la classe A est la classe B, la récupération des identificateurs d'objet d'une classe qui sont stockés en tant que valeurs d'attribut d'une autre classe élimine le besoin d'une jointure d'objet implicite.

Ainsi, dans les bases de données orientées objet, les jointures implicites générées par l'imbrication hiérarchique d'objets sont différentes des jointures explicites. Ces dernières ressemblent à des jointures relationnelles : deux objets sont explicitement comparés en fonction des valeurs d'attributs ou d'identifiants d'objet. De plus, toutes les jointures explicites (basées sur la comparaison de valeurs ou d'identifiants) ne peuvent pas être exprimées dans le langage de requête relationnel, puisque tout prédicat dans un RDB ne peut contenir que des attributs atomiques.

Gain de performances

Les OODB modernes ne sont pas des systèmes de base de données à part entière par rapport aux OODB modernes ; les OODB ont plusieurs fonctionnalités qui offrent leurs gains de performances.

1. Dans un OODB, la valeur d'un attribut d'un objet X dont le domaine est un autre objet Y est l'identifiant de l'objet Y. Par conséquent, si l'application a déjà récupéré l'objet X et veut maintenant récupérer l'objet Y, le SGBD peut récupérer l'objet Y en trouvant son identifiant. Si cet identifiant est l'adresse physique d'un objet, alors cet objet peut être récupéré directement ; si l'identifiant est une adresse logique, alors l'objet en trouvant l'élément correspondant de la table de hachage (en supposant que le système maintient une table de hachage qui mappe l'identifiant de l'objet à une adresse physique). Ce n'est peut-être pas si facile dans la RDB, car les identificateurs d'objet ne sont pas pris en charge dans la RDB.
2. La deuxième caractéristique des OODB, qui apporte un gain de performances, est que dans la plupart des OODB, lorsqu'un objet est chargé en mémoire, les identifiants d'objet stockés dans cet objet sont convertis en pointeurs depuis la mémoire. Étant donné que les identifiants d'objet ne sont pas stockés dans le RDB, il est impossible de stocker des pointeurs en mémoire vers d'autres tuples qu'ils contiennent. L'impossibilité de naviguer dans les objets contenus dans la mémoire est une propriété fondamentale de la RDB, et la diminution des performances qui en résulte ne peut pas être compensée par une simple augmentation de la quantité de mémoire tampon. Ainsi, lors de l'exécution d'applications impliquant une navigation multiple dans les objets associés chargés en mémoire, les OODB peuvent considérablement surpasser les RDB en termes de performances.
3. De plus, même si les OODB ne sont pas indexés, il peut être pratique d'exécuter des requêtes arbitraires qui correspondent à la structure de l'objet par des balayages séquentiels, c'est-à-dire utiliser des chemins de référence entre les objets. Lorsqu'une demande est formulée dans une direction non prise en charge par les liens, cette demande sera traitée par un balayage séquentiel. Cependant, les requêtes formulées sur la base de telles relations d'objets qui ne sont pas modélisées directement à l'aide de liens sont inefficaces.

Prise en charge de la gestion des versions et des transactions de longue durée

Le RDB ne prend en charge ni la gestion des versions ni les transactions longues. Cette prise en charge est disponible dans certains OODB, mais avec des capacités limitées.

Algèbre d'objets

L'algèbre d'objet n'est pas aussi détaillée et mature que l'algèbre relationnelle. Mais quoi qu'il en soit, une telle algèbre existe, et elle définit cinq opérations fondamentales qui préservent les objets : union, différence, sélection, génération et application. D'autres opérations peuvent être définies sur la base de ces opérations fondamentales, telles que l'intersection. Des règles de conversion pour l'optimisation logique des expressions de l'algèbre d'objets tout en préservant l'équivalence sont déduites dans et. Alors que les opérations union, difference et map effectuent principalement un mappage un-à-un, les opérations de sélection et de génération produisent un mappage un-à-plusieurs. L'enregistrement d'objets signifie que les opérations algébriques renvoient des objets appartenant à des classes de base de données précédemment définies et ne créent pas de nouveaux objets. L'opérateur union renvoie les objets contenus dans l'ensemble P ou l'ensemble Q, ou les deux. L'opérateur de différence renvoie un ensemble d'objets appartenant à l'ensemble P mais pas à l'ensemble Q. select renvoie un sous-ensemble de l'ensemble que vous avez entré. generate génère des objets à partir de ceux qui appartiennent à l'ensemble d'entrée. map renvoie l'ensemble des objets résultant de chaque application d'une séquence de méthodes.

Inconvénients du modèle OODB

Les méthodes orientées objet devaient permettre à la technologie des bases de données d'effectuer une sorte de transition quantique. Cependant, malgré les réalisations ci-dessus, l'OODB n'a pas été en mesure d'avoir un impact significatif sur la situation dans ce domaine. Le modèle et la technologie OODB présentent encore des faiblesses.

Les bases de données orientées objet ne disposent pas des outils de base auxquels les utilisateurs de bases de données sont habitués et s'attendent donc à les voir. On peut noter entre autres : le manque d'interopérabilité entre RDB et OODB ; optimisation minimale des requêtes ; manque d'algèbre de requête standard; manque de moyens pour répondre aux demandes ; manque de soutien pour les soumissions; problèmes de sécurité; le manque de prise en charge des changements dynamiques dans les définitions de classe ; prise en charge limitée des contraintes d'intégrité ; options de réglage des performances limitées ; prise en charge insuffisante d'objets complexes ; intégration limitée avec les systèmes de programmation orientés objet existants ; gain de performances limité.

Manque d'interopérabilité entre RDB et OODB

Pour que les OODB aient un impact significatif sur le marché des bases de données, un certain nombre de conditions doivent être remplies.

1. Transformez les OODB en systèmes de base de données à part entière qui sont raisonnablement compatibles avec les RDB. Un chemin de migration est nécessaire pour assurer la coexistence des produits existants et nouveaux, ainsi qu'une transition en douceur du premier au second.
2. Offrir des outils de développement d'applications et des moyens d'accès aux bases de données orientées objet.
3. Unifiez l'architecture de RDB et OODB.
4. Unifiez les modèles de données RDB et OODB.

Fonds insuffisants pour optimiser les requêtes

L'un des problèmes les plus importants dans OODB est l'optimisation des requêtes déclaratives. L'optimisation des requêtes contre les OODB est entravée par la complexité supplémentaire du modèle de données orienté objet lui-même. Cette complexité supplémentaire est due à un certain nombre de facteurs.

1. La possibilité pour les utilisateurs de définir de nouveaux types et classes à l'aide de l'héritage facilite et complique l'optimisation des requêtes. Un exemple où cette fonctionnalité peut aider à l'optimisation est une requête impliquant l'intersection des ensembles Employés et Superviseurs. Si Employé est une superclasse de Superviseur, alors l'optimiseur peut supposer que les Superviseurs sont son propre sous-ensemble d'Employés et simplifier l'intersection des ensembles. Un exemple dans lequel des types de données supplémentaires limitent les options d'optimisation est l'union des ensembles Étudiants et Employés ; la superclasse pour les deux classes est Person. Si nous voulions trouver tous les superviseurs des étudiants et des employés, nous ferions d'abord la fusion, puis utiliserions superviseur ().
2. Les requêtes peuvent être basées sur des opérations sur des collections, mais les types d'optimisation affectant des ensembles (ou multi-ensembles, ou listes, etc.) doivent être combinés avec une optimisation sur les types d'objets contenus dans ces ensembles. Un optimiseur de requêtes orienté objet doit pouvoir appliquer des procédures d'optimisation spécifiques à ces types, ainsi que des procédures d'optimisation qui prennent en compte les relations entre objets de types différents.
3. La complexité du traitement des requêtes dans les OODB est aggravée par la présence d'objets, de méthodes et d'encapsulations complexes. Les objets complexes génèrent des expressions de chemin qui compliquent le traitement des requêtes. La création d'index pour les expressions de chemin, en particulier lorsqu'il existe des méthodes arbitraires dans les expressions, complique le traitement des requêtes. Le problème est encore plus compliqué si les méthodes ont des effets secondaires. Un autre problème avec les expressions de chemin est qu'elles imposent l'ordre des appels aux méthodes d'expression de chemin, et cet ordre peut être assez inefficace. Par exemple, l'expression de chemin Orders.part.name est mieux calculée de droite à gauche, s'il y a beaucoup de commandes (Orders) et peu de pièces (Parts), mais s'il y a beaucoup de pièces, et il y a peu de commandes, c'est mieux pour évaluer l'expression de gauche à droite. De plus, les expressions de chemin sont parfois traitées plus efficacement à l'aide de Join. Par exemple, considérons une requête avec l'expression de chemin s.comp.name, où s appartient à l'ensemble Students. Il peut être plus efficace (si le nombre de sociétés, comp, est petit) de calculer d'abord le nom de chaque société et de stocker le résultat dans un tuple. Ensuite, évaluer l'expression du nom de l'étudiant au nom de l'entreprise impliquerait de joindre l'ensemble des étudiants à l'ensemble des tuples en mappant la propriété comp de la classe d'étudiants à la valeur de l'attribut Company d'un tuple.
4. Dans les langages de requête OODB, l'utilisation de structures imbriquées est prise en charge, ce qui, encore une fois, peut compliquer considérablement le processus d'optimisation, car elles le transforment d'un problème local en un problème global, car une connaissance globale de l'ensemble de l'expression de la requête est requise.
5. Lorsque les objets sont identifiables, la question se pose de savoir ce que l'on entend par l'égalité de deux objets. Cette question se retrouve dans un langage où les comparaisons d'égalité sont utilisées dans les prédicats et où il est nécessaire de prendre une décision sur la création de nouveaux objets lors de l'exécution d'une requête. Un optimiseur de modèle orienté objet doit être capable de résoudre les problèmes associés à la création de nouveaux objets et à des définitions alternatives de l'égalité.

Ces problèmes indiquent que l'optimisation des requêtes orientées objet est une tâche extrêmement difficile, et ce domaine est encore au stade de la recherche. Les systèmes de base de données orientés objet d'aujourd'hui offrent des stratégies d'optimisation assez simples. Le problème de l'optimisation des connexions requiert également plus d'attention.

Absence d'algèbre de requête standard

Un autre inconvénient majeur des OODB est le manque de normes d'algèbre de requête. Cette circonstance rend également difficile l'optimisation des requêtes. Plusieurs langages de requêtes formels différents basés sur des algèbres et des calculs ont été proposés pour OODB. Ces algèbres et calculs diffèrent à plusieurs égards, à la fois en termes d'expressivité et de prise en charge de l'optimisation des règles de réécriture. Presque toutes ces algèbres sont basées sur des variables, c'est-à-dire utiliser des variables pour stocker les résultats intermédiaires. KOLA, l'un des packages OODB, est un produit purement fonctionnel ; les variables n'y sont pas utilisées. L'auteur prétend que c'est précisément en raison de l'absence de variables que l'algèbre de KOLA permet de construire des systèmes de règles plus puissants.

Dans RDB, il existe une correspondance étroite entre les opérations algébriques et les primitives de bas niveau d'un système physique. Cette correspondance stricte est obtenue grâce à des mappages entre les relations et les fichiers, et entre les tuples et les enregistrements. Cependant, dans OODB, il n'y a pas de correspondance intuitive analogue entre les opérations de l'algèbre des objets et les primitives des systèmes physiques. Dans toute discussion sur la génération d'un plan d'exécution, il est également nécessaire, tout d'abord, de définir les primitives de bas niveau pour manipuler les objets.

Manque de moyens pour répondre aux demandes

La plupart des OODB manquent d'installations de support de requête. Dans les quelques systèmes qui disposent d'installations adéquates, le langage de requête n'est pas conforme à ANSI SQL. Parmi ces moyens de fournir des requêtes, il n'y a pas de sous-requêtes imbriquées, de requêtes avec ensembles (union, intersection, différence), de fonctions d'agrégat et de GROUP BY, joignant plusieurs classes - fonctionnalités entièrement prises en charge dans la RDB.

De plus, il n'y a pas de standard pour les requêtes objet, même s'il faut dire qu'il y a eu des tentatives pour développer un langage objet SQL. SQL3 est susceptible d'être retardé de plusieurs années.

Manque de prise en charge de la vue

Les vues ne sont pas prises en charge dans les OODB. Bien que plusieurs suggestions aient été faites à ce sujet, aucun consensus n'a été atteint sur la façon dont le moteur de présentation devrait fonctionner dans l'OODB. Le développement d'un moteur de visualisation orienté objet est compliqué par des propriétés de modèle telles que l'identifiabilité des objets. Quel est l'ID d'un objet dans une vue ? D'autre part, le point de vue est exprimé que la capacité d'encapsuler des données et l'héritage permet de se passer de définitions explicites de vues.

Problèmes de sécurité

L'autorisation est prise en charge dans les RDB, alors que dans la plupart des OODB, elle est absente. Les RDB permettent aux utilisateurs de transférer et de révoquer les autorisations de lecture ou de modification des définitions et des tuples dans les relations et les vues. Les OODB ne pourront être mieux acceptés dans le domaine commercial que si cette fonction y est améliorée.

Dans certains systèmes OODB, les utilisateurs doivent explicitement définir et libérer les verrous. Les systèmes RDB définissent et libèrent automatiquement les verrous lors du traitement des demandes des utilisateurs et des opérateurs de mise à jour.

Manque de prise en charge des modifications dynamiques des définitions de classe

Outre le fait qu'un seul modèle de données standard n'a pas encore été développé pour les OODB, la plupart des OODB n'autorisent pas les modifications dynamiques du schéma de la base de données, telles que l'ajout d'un nouvel attribut ou d'une nouvelle méthode à une classe, l'ajout d'une nouvelle superclasse à une classe , suppression d'une superclasse d'une classe, ajout d'une nouvelle classe et suppression de classe. Les RDB permettent à l'utilisateur de modifier dynamiquement le schéma de la base de données à l'aide de la commande ALTER ; une nouvelle colonne peut être ajoutée à une relation, une relation peut être supprimée et, dans certains cas, il est possible de supprimer une colonne d'une relation.

La plupart des OODB manquent également de gestion automatique des extensions de classe. Si l'extension de la classe est nécessaire, l'utilisateur doit définir une collection pour celle-ci et s'assurer que toutes les insertions et suppressions y sont enregistrées en temps opportun.

Prise en charge limitée des contraintes d'intégrité

Il n'y a pas de mécanismes pour déclarer les propriétés de clé des attributs (par exemple, un attribut de classe ne peut pas être déclaré la clé primaire d'une classe), ni de contraintes d'unicité, de contraintes d'intégrité explicites et de pré- et post-conditions de méthode. Bien que tout cela puisse être fait à l'aide de méthodes, les contraintes explicites seraient plus conviviales, généreraient moins d'erreurs et seraient plus vérifiables et modifiables.

Options de réglage des performances limitées

La plupart des OODB n'ont que des moyens limités de réglage des performances paramétré. Dans RDB, les installateurs ont la possibilité de régler les performances du système en définissant un grand nombre de paramètres définis par l'administrateur système. Ces paramètres incluent le nombre de tampons mémoire, la quantité d'espace libre réservé dans la page de données pour les futures insertions de données, etc. ...

Prise en charge insuffisante des objets complexes

La fonctionnalité complète des objets complexes n'est toujours pas prise en charge. Vous pouvez naviguer dans les liens et les opérations de code à l'aide de ces liens, mais il n'y a pas d'opérations génériques prédéfinies qui utilisent différents types de sémantique de lien. Toutes les références sont considérées comme pointant vers des objets indépendants, et la sémantique des relations spéciales au sein d'objets complexes est masquée dans les opérations fournies par l'utilisateur.

Intégration limitée avec les systèmes de programmation orientés objet

Il est difficile de réécrire des programmes orientés objet pour gérer des données stables. Un certain nombre de problèmes se posent ici : conflits de noms ; la nécessité de refaire les hiérarchies de classes ; Tendance de l'OODB à surcharger les opérations du système.

Gain de performance limité

Si toutes les applications de base de données n'avaient besoin que de rechercher des objets de base de données via des identificateurs d'objet et de travailler rapidement avec des objets dans la mémoire principale à l'aide de pointeurs, alors les OODB surpasseraient réellement les RDB en termes de performances de deux à trois ordres de grandeur. Cependant, la plupart des applications qui nécessitent un accès aux objets via des identificateurs ont également besoin des capacités d'accès à la base de données et de mise à jour fournies dans le RDB. Ces capacités incluent le chargement de base de données en masse ; créer, mettre à jour et supprimer des objets individuels (un à la fois) ; récupérer dans la classe un ou plusieurs objets répondant à certaines conditions de recherche ; connexion de plusieurs classes; commettre des transactions, etc. Lors de l'exécution de telles applications, les OODB n'ont aucun avantage en termes de performances par rapport aux RDB.

Les fonctionnalités non encore prises en charge dans les OODB incluent les déclencheurs, les contrôles de métadonnées et les contraintes d'intégrité telles que UNIQUE et NULL.

***

En raison de ces faiblesses, les OODB n'ont pas été en mesure de répondre à leurs attentes en fournissant tous les outils importants qui sont souhaitables pour leurs applications prévues. Le terme « OODB » est utilisé à tort pour la plupart des systèmes modernes. Presque tous les OODB modernes ne sont pas tant des systèmes de bases de données que des systèmes de stockage de données stables pour certains langages de programmation orientés objet. Ainsi, alors que le modèle de données orienté objet est à bien des égards plus riche que le modèle relationnel, le modèle orienté objet n'est pas encore pleinement mature. Aujourd'hui, il y a clairement plus d'inconvénients dans les systèmes OODB que d'avantages.

Littérature

1. S. Abiteboul, A. Bonner, "Objets et vues". ACM SIGMOD Int. Conf. Sur la gestion des données, 1991.
2. M. Atkinson, et al., "Manifeste du système de base de données orienté objet." Construire un système de base de données orienté objet : l'histoire d'O2. Morgan Kaufman, 1992.
3. F. Bancilhon, "Systèmes de bases de données orientés objet". 7e Conférence ACM SIGART / SIGMOD, 1988.
4. J. Banerjee, et al., "Problèmes de modèle de données pour les applications orientées objet." ACM Trans. Sur les systèmes d'information de bureau, janvier 1987.
5. J. Banerjee, W. Kim, K.C. Kim, "Requêtes dans les bases de données orientées objet." IEEE Data Engineering Conf., fév. 1988.
6. D. Beech, "Fondation pour l'évolution et les bases de données relationnelles à objets." Proc. Technologie de base de données étendue, mars. 1988.
7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, « Langages de requêtes orientés objet : notion et problèmes ». Transactions IEEE sur la connaissance et l'ingénierie des données, mars. 1992.
8. A.W. Brown, Bases de données orientées objet, Applications en génie logiciel. New York : McGraw-Hill, 1991.
9. R.G.G. Cattell, gestion des données d'objets, systèmes de bases de données relationnelles étendues et orientées objet. Addison-Wesley, 1991.
10. M. Cherniack, "Former (ers) sur fonction (s): KOLA Query Algebra." Rapport technique, Brown University, déc. 1995.
11. S. Cluet, et al., "Reloop, langage de requête basé sur l'algèbre pour un système de base de données orienté objet." 1er Int. Conf. Sur les bases de données déductives et orientées objet, déc. 1989.
12. SI. Cruz, DOODLE : Langage visuel pour bases de données orientées objet. ACM SIGMOD Int. Conf. Sur la gestion des données, 1992.
13. U. Dayal, "Requêtes et vues dans un modèle de données orienté objet." 2e Int. Travailler. Sur les langages de programmation de bases de données, juin 1989.
14. K.A. Dittrich, K.R. Dittrich, "Là où les SGBD orientés objet devraient mieux faire : une critique basée sur les premières expériences." Systèmes de bases de données modernes : modèle objet, interopérabilité et au-delà, ACM Press, Addison Wesley, 1995.
15. U. Erlingsson, "Object-Qriented Query Optimization", manuscrit non publié.
16. L. Fegaras, D. Maier, "Vers un calcul efficace pour les langages de requête d'objets." ACM SIGMOD Int. Conf. sur la gestion des données, San Jose, Californie, mai 1995.
17. L. Fegaras, D. Maier, T. Sheard, "Spécification des optimiseurs de requêtes basés sur des règles dans un cadre réflexif." 3e Int. Conf. sur les bases de données déductives et orientées objet, Phoenix, Arizona, déc. 1993.
18. S. Heiler, S. Zdonik, "Object Views: Extending the vision." 6e Int. Conf. Sur l'ingénierie des données, 1990.
19. J.G. Hughes, Bases de données orientées objet. New York : Prentice-Hall, 1991.
20. S. Khoshafian, « Aperçu des bases de données orientées objet. » Technologies de l'information et des logiciels, avr. 1990.
21. S. Khoshafian, Bases de données orientées objet, New York : John Wiley & Sons, 1993.
22. S. Khoshafian, G. Copeland, "Identité d'objet". 1er Int. Conf. Sur les systèmes de programmation orientés objet, les langages et les applications, oct. 1986.
23. W. Kim, "Fondation pour les bases de données orientées objet." MCC Tech. Rep., N. ACA-ST-248-88, août. 1988.
24. W. Kim, Introduction aux bases de données orientées objet. MIT Press, 1991.
25. W. Kim, « Systèmes de base de données orientés objet : promesses, réalité et avenir ». Systèmes de bases de données modernes : modèle objet, interopérabilité et au-delà, ACM Press, Addison Wesley, 1995.
26. T.W. Leung, et al, "Aqua Data Model and Algebra". Rapport technique CS-93-09, Université Brown, mars. 1993.
27. G. Mitchell, S.B. Zdonik, U. Dayal, « Optimisation des requêtes orientées objet - Quel est le problème ? » Rapport technique CS-91-41, Brown University, juin 1991.
28. E.A. Rudensteiner, "Multiview: Méthodologie de prise en charge de plusieurs vues dans des bases de données orientées objet." 18e Int. Conf. Sur les très grandes bases de données, 1992.
29. M. Scholl, H. Schek, "Modèle objet relationnel". 3e Int. Conf. Sur la théorie des bases de données, LNCS, vol. 470, Springer Verlag, 1990.
30. P.G. Selinger, et al, "Sélection du chemin d'accès dans un système de gestion de base de données relationnelle." ACM SIGMOD Int. Conf. Sur la gestion des données, 1979.
31. M. Stefik, D.G. Bobrow, "Programmation orientée objet : thèmes et variations". The AI ​​Mag., janv. 1986.
32. M. Stonebraker, et al, "Manifeste du système de base de données de troisième génération". Committee for Advanced DBMS Function, Université de Californie, Berkeley, 1990.
33. D.D. Straube, M.T. Ozsu, "Requêtes et traitement des requêtes dans les systèmes de base de données orientés objet." Transactions ACM sur les systèmes d'information, oct. 1990.
34. D.D. Straube, M.T. Ozsu, "Génération de plan d'exécution pour un modèle de données orienté objet." 2e Int. Conf. sur les bases de données déductives et orientées objet, Munich, Allemagne, déc. 1991.
35. S.Y.W. Su, M. Guo, H. Lam, Association Algebra: Mathematical Foundation for Object-Oriented Databases. Transactions IEEE sur la connaissance et l'ingénierie des données, oct. 1993.
36. S.B. Zdonik, D. Maier, éd., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
37. S.B. Zdonik, P. Wegner, "Langage et méthodologie pour les environnements de base de données orientés objet." International d'Hawaï Conf. sur les sciences du système, janv. 1986.

Siha Bagui([email protégé]) - Maître de conférences au Département d'informatique, Université de Floride occidentale. Co-auteur de trois livres sur les bases de données : Learning SQL : A Step-by-Step Guide Using Oracle, Learning SQL : A Step-by-Step Guide Using Access (Addison Wesley) et Database Design Using Entity Relationship Diagrams (CRC Press).

Traduit de "Réalisations et faiblesses des bases de données orientées objet" par Sikha Bagui dans Journal of Object Technology (JOT), vol. 2, non. 4, juillet-août 2003, pages 29-41. Traduit en russe pour Otkrytye Systemy sous autorisation spéciale de l'éditeur d'origine. Copyright JOT, 2003. Article original sur http://www.jot.fm/issues/issue_2003_07/column2.

De l'éditeur de traduction

OODB - maturité ou déclin ?

Sergueï Kouznetsov

Il y a eu une accalmie frappante dans les bases de données orientées objet au cours des dernières années, que certains ont tendance à percevoir comme un déclin de la technologie, et d'autres comme une transition de la technologie vers un état mature et stable. D'après mes observations, une telle accalmie conduit parfois à des idées fausses et même à des mythes chez des personnes proches de l'informatique, mais non spécialisées dans le domaine des bases de données. L'une de ces idées fausses est qu'une personne prend un ensemble de termes qui s'est développé dans sa tête (objet, attribut, méthode, classe, héritage, etc.) pour un modèle de données orienté objet généralement accepté.

Ceci explique notre décision de publier une traduction d'un article assez ordinaire de Siha Bagui. Une telle publication se justifie au moins par le fait qu'elle interrompt cette accalmie et montre, tout d'abord, que le domaine de l'OODB non seulement n'est pas entré dans la période de maturité, mais continue de rester un conglomérat d'idées hétérogènes et confuses qui se unis plutôt au niveau des slogans que de la technologie.

L'article est basé sur une analyse de 36 publications consacrées aux bases de données orientées objet et publiées sur la période 1986-1995. Par conséquent, la caractéristique fréquemment utilisée des OODB "modernes" n'est pas tout à fait juste. Les citations, parfois données au présent, semblent parfois plutôt suspectes.

Bien entendu, de nombreuses sources ont utilisé une terminologie différente, et à cet égard, leur examen est extrêmement varié. De plus, de nombreux articles sont techniquement suffisamment complexes pour que les citer sans fournir de contexte ne fasse que rendre difficile la compréhension. L'exemple le plus frappant est la sous-section sur le développement de l'algèbre des objets. Les trois premières opérations "fondamentales" - union, différence, sélection - sont intuitivement claires (bien qu'en réalité les auteurs de l'article original permettent une sélection peu évidente sous forme de semi-jointure), mais les deux dernières - générer et map - sont des opérations difficiles à définir et pas évidentes.

Je veux souligner une autre caractéristique étrange de l'article de Baguya. Jusqu'en 2001, il existait un consortium international Object Data Management Group, qui publiait trois versions de propositions pour la standardisation du modèle de données orienté objet ; la dernière version - ODMG 3.0 a été publiée en 2000. C'est le seul document qui offre une terminologie relativement cohérente et, dans une certaine mesure, un modèle de données orienté objet. Il est dommage que Bagui n'utilise pas ce matériel.

A noter que la revue "DBMS" a publié un article sur la première version de la norme, ODMG-93. Un aperçu de la norme ODMG 3.0 peut être trouvé dans. Je recommanderais également une traduction de l'Object Oriented Database Systems Manifesto et un très bon aperçu de la technologie OODB.

Littérature

1. La norme de données d'objet : ODMG 3.0. R.G.G. Cattel, D.K. Barry, éd., Morgan Kauffmann, 2000.
2. LA. Kalinichenko,. // SGBD, n° 1, 1996.
3. DAKOTA DU SUD. Kouznetsov. Trois manifestes de bases de données : rétrospective et perspective. Rapport à la conférence "Bases de données et technologies de l'information du XXIe siècle", Moscou, septembre 2003, http://www.citforum.ru/database/articles/manifests.
4. M. Atkinson et al., // SGBD, n° 4, 1995.
5. Ark Andreev, Dmitri Berezkin, Roman Samarev,. // Systèmes ouverts, n° 3, 2001.

Bases de données orientées objet : réalisations et défis

Avec un grand nombre de projets expérimentaux (et même de systèmes commerciaux), il n'y a pas de modèle de données orienté objet généralement accepté, non pas parce qu'il n'y a pas de 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 effet, il existe des problèmes plus spécifiques liés au développement de langages de requêtes déclaratives, à l'exécution et à l'optimisation des requêtes, à la formulation et au maintien des contraintes d'intégrité, à la synchronisation des accès et à la gestion des transactions, etc.

Le modèle orienté objet (Figure 3) vous permet de créer, stocker et utiliser des informations sous forme d'objets. Tout objet lors de sa création 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.

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

Chaque objet a un état et un comportement. L'état d'un objet est un ensemble de valeurs pour ses attributs. Le comportement de l'objet est un ensemble de méthodes (code de programme) qui agissent sur l'état de l'objet. La valeur d'un attribut d'un objet est aussi un objet ou un ensemble d'objets. L'état et le comportement d'un objet sont encapsulés dans l'objet ; l'interaction des objets est basée sur la transmission de messages et l'exécution des méthodes correspondantes.

De nombreux objets avec le même ensemble d'attributs et de méthodes forment une classe d'objets. Un objet ne doit appartenir qu'à une seule classe (si vous ne considérez pas la possibilité d'héritage). La présence de classes prédéfinies primitives est autorisée, dont les objets-instances n'ont pas d'attributs : entiers, chaînes, etc. Une classe dont les objets peuvent servir de valeurs à un attribut d'objets d'une autre classe est appelée le domaine de cet attribut.

Il est permis de créer une nouvelle classe basée sur une classe existante - héritage. Dans ce cas, la nouvelle classe, appelée sous-classe de la classe existante (superclasse), hérite de tous les attributs et méthodes de la superclasse. De plus, des attributs et des méthodes supplémentaires peuvent être définis dans la sous-classe. On distingue les cas d'héritage simple et multiple. Dans le premier cas, une sous-classe ne peut être définie qu'à partir d'une seule superclasse, dans le second cas il peut y avoir plusieurs superclasses. Si un langage ou un système prend en charge l'héritage unique de classes, l'ensemble de classes forme une arborescence. Tout en maintenant l'héritage multiple, les classes sont liées dans un graphe orienté avec une racine appelée treillis de classes. Un objet de sous-classe est considéré comme appartenant à n'importe quelle 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 / fabrication assistée par ordinateur (CAO / FAO), les systèmes de développement de logiciels assistés par ordinateur (CASE) et les systèmes de gestion de documents multiples. dans des domaines non traditionnels pour les bases de données. Des exemples de SGBD orientés objet sont POET, Jasmine, Versant, Iris, Orion.

2.2.4 modèle de données relationnel

En 1970, le mathématicien américain 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 devraient être liées en fonction de leur relation logique (par exemple, union, intersection), et non des pointeurs physiques. Il a proposé un modèle de données simple dans lequel toutes les données sont tabulées avec des lignes et des colonnes portant un nom unique. Ces tables sont appelées relations (relatio - relation), et le modèle est un modèle de données relationnel construit sur le concept de relations mathématiques et il est parfois aussi appelé modèle de Codd. Les propositions de Codd étaient si efficaces pour les systèmes de bases de données que pour ce modèle, il a reçu le prestigieux prix Turing pour les fondements théoriques de l'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 (appelées champs), à l'intersection desquelles se trouvent les informations sur les données. En général, cela peut être représenté comme dans la Fig. 4.

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

Chaque colonne a son propre nom. Par exemple, dans le tableau « Marchandises en stock » (Fig. 5.), les noms des champs sont les suivants : Identifiant, Produit, Nom de groupe, Grouper, unité de mesure, Prix ​​d'achat, Prix ​​de vente, Disponibilité des stocks.

Riz. 5. Tableau « Marchandises en stock »

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 une ligne font référence au même objet et différents champs diffèrent par leur nom.

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

Clé primaire Est un ou plusieurs champs qui identifient de manière unique un enregistrement. Si la clé primaire est constituée d'un seul champ, elle est appelée clé simple, si elle est constituée de plusieurs champs, elle est appelée clé composite.

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

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

Figure 6. Exemple utilisant une clé étrangère

En règle générale, une base de données relationnelle se compose de plusieurs tables, car Il n'est pas possible de combiner dans un seul tableau toutes les informations requises par les employés (utilisateurs de la base de données) d'une organisation pour résoudre des problèmes.

L'indexation est un moyen efficace d'accéder par clé à un enregistrement de fichier. L'indexation crée un fichier supplémentaire qui contient toutes les valeurs clés du fichier de données de manière ordonnée. Pour chaque clé, le fichier d'index contient un pointeur vers l'entrée de fichier de données correspondante. Un pointeur vers un enregistrement dans le fichier de données accède directement à cet enregistrement.

Pour travailler avec des bases de données relationnelles, le langage de requête structuré (Structured Query Language - SQL) est actuellement couramment utilisé. C'est un langage utilisé pour créer, modifier et manipuler des données. SQL n'est pas un langage de programmation algorithmique. C'est un langage logique de l'information, il est basé sur l'algèbre relationnelle et est 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 de définition d'accès aux données.

En 1986, 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 un standard pour les systèmes d'information modernes.

Ainsi, le tableau est le type principal de la structure de données du modèle relationnel. La structure d'une table est déterminée par un ensemble de colonnes. Chaque ligne du tableau contient une valeur dans la colonne correspondante. Il ne peut pas y avoir deux lignes identiques dans le tableau, le nombre total de lignes n'est pas limité. 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 table sont la clé de table.

Les avantages du modèle relationnel sont :

Simplicité et facilité de compréhension par l'utilisateur final - la seule structure informationnelle est le tableau ;

Lors de la conception d'une base de données relationnelle, des règles strictes basées sur des appareils mathématiques sont appliquées ;

Indépendance totale des données. Lorsque la structure change, les modifications qui doivent être apportées aux programmes d'application sont minimes ;

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

Les inconvénients du modèle relationnel sont :

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 tableaux résultant d'une conception logique ;

Il n'est pas toujours possible de représenter le domaine sous la forme d'un ensemble de tableaux.

Les bases de données relationnelles sont actuellement les plus répandues. Les modèles réseau et hiérarchiques sont considérés comme obsolètes, les modèles orientés objet ne sont pas encore standardisés et largement acceptés.