Exemple de modèle de données orienté objet. Modèle de données orienté objet. Prise en charge limitée des contraintes d'intégrité

Introduction

L'émergence de la direction des bases de données orientées objet (OODB) a été déterminée avant tout par les besoins de la pratique : la nécessité de développer des systèmes d'application d'informations complexes pour lesquels la technologie des systèmes de bases de données précédents n'était pas entièrement satisfaisante. Bien entendu, ODB n’est pas né 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.

Quant au lien avec les travaux antérieurs dans le domaine des bases de données, l'influence la plus forte sur les travaux dans le domaine de l'OODB a été exercée par le développement du SGBD et de la famille de bases de données chronologiquement ultérieures, qui prenaient en charge la gestion d'objets complexes. Ces travaux ont constitué la base structurelle de l'organisation de l'OODB. Ce résumé abordera OOMD et OODBMS.

Modèle de données orienté objet

Considérons 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. OOMD est généralement utilisé dans des domaines complexes pour lesquels la fonctionnalité du modèle relationnel n'est pas suffisante 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 principalement par un aspect fondamental. Dans le modèle de données SQL et le véritable modèle de données relationnel, une base de données est une collection de conteneurs de données nommés du même type générique : tables ou relations, respectivement. Dans un modèle de données orienté objet, une base de données est un ensemble 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 :

intégrer des outils conçus pour travailler avec des bases de données dans un langage orienté objet ;

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 des bases 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 larges capacités de modélisation de domaine, un langage de requête expressif et des performances élevées. Chaque objet de l'OOMD possède un identifiant unique (OID - identifiant d'objet). L'accès par OID est beaucoup plus rapide que la recherche dans une table relationnelle.

Parmi les inconvénients de l'OODB, il convient de noter l'absence d'un modèle généralement accepté, le manque d'expérience dans la création et l'exploitation de l'OODB, la complexité d'utilisation et l'insuffisance des outils 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 un 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. Les relations sont établies entre les enregistrements de bases de données et leurs fonctions de traitement à l'aide de mécanismes similaires aux fonctionnalités correspondantes 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 - groupe de gestion de bases de données orientées objet). Il n'a pas encore été 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é de base de données orientée objet.

La structure d'une base de données orientée objet peut être représentée graphiquement sous la forme d'une arborescence dont les nœuds sont des objets. Les propriétés des objets sont décrites par un type standard (par exemple, une 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 classe est un objet qui est une instance de la classe correspondante. Chaque objet instance d'une classe est considéré comme un enfant de l'objet dans lequel il est défini comme 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 connectée d'objets.

Base de données orientée objet(OODB) - une base de données dans laquelle les données sont modélisées sous forme d'objets, de leurs attributs, méthodes et classes.

Les bases de données orientées objet sont généralement recommandées dans les cas où un traitement haute performance de données avec une structure complexe est requis.

Le manifeste OODB propose des caractéristiques obligatoires que tout OODB doit respecter. Leur choix repose sur 2 critères : le système doit être orienté objet et être une base de données.

Caractéristiques requises

1. Prise en charge des objets complexes. Le système doit offrir la possibilité de créer des objets composites grâce à l'utilisation de constructeurs d'objets composites. Il est nécessaire que les constructeurs d’objets soient orthogonaux, c’est-à-dire que n’importe quel constructeur puisse être appliqué à n’importe quel objet.

2. Prise en charge de l'individualité des objets. Tous les objets doivent avoir un identifiant unique indépendant des valeurs de leurs attributs.

3. Prise en charge de l'encapsulation. Une encapsulation correcte est obtenue grâce au fait que les programmeurs n'ont accès qu'à la spécification d'interface des méthodes, et que les données et l'implémentation des méthodes sont cachées à l'intérieur des objets.

4. Prise en charge des types et des classes. Un OODB doit prendre en charge au moins un concept de distinction entre types et classes. (Le terme « type » est plus cohérent avec le concept de type de données abstrait. Dans les langages de programmation, une variable est déclarée avec une indication de son type. Le compilateur peut utiliser cette information pour vérifier que les opérations effectuées sur la variable sont compatibles avec son type, ce qui permet de garantir l'exactitude du logiciel. D'autre part, une classe est un modèle pour créer des objets et fournit des méthodes qui peuvent être appliquées à ces objets. Ainsi, le concept de « classe » est plutôt une exécution. temps qu'un temps de compilation.)

5. Prise en charge de l'héritage des types et des classes de leurs ancêtres. Un sous-type ou une sous-classe doit hériter respectivement des attributs et des méthodes de son supertype ou de sa superclasse.

6. Surcharge combinée à un liage complet. Les méthodes doivent être appliquées à des objets de différents types. L'implémentation d'une méthode doit dépendre du type d'objets auxquels la méthode est appliquée. Pour fournir cette fonctionnalité, la liaison du nom de méthode dans le système ne doit pas se produire avant l'exécution du programme.

7. Complétude du calcul. Le langage de manipulation de données doit être un langage de programmation à usage général.

8. L'ensemble des types de données doit être extensible. L'utilisateur doit avoir les moyens de créer de nouveaux types de données basés sur un ensemble de types de système prédéfinis. De plus, il ne devrait y avoir aucune différence entre la manière dont les types de données système et utilisateur sont utilisés.

SGBD OO

Bases de données orientées objet– des bases de données dans lesquelles les informations sont présentées sous forme d'objets, comme dans les langages de programmation orientés objet.

Utiliser ou non des systèmes de gestion de bases de données orientés objet (OODBMS) dans des projets réels aujourd'hui ? Dans quels cas doivent-ils être utilisés et dans quels cas ne doivent-ils pas être utilisés ?

Ici avantages en utilisant un SGBOD :

· Il n'y a aucun problème de non-concordance d'impédance entre le modèle de données de l'application et la base de données. Toutes les données sont stockées dans la base de données sous la même forme que dans le modèle d'application.

· Il n'est pas nécessaire de prendre en charge séparément le modèle de données du côté du SGBD.

· Tous les objets au niveau de la source de données sont strictement typés. Fini les noms de colonnes de chaînes ! La refactorisation d'une base de données orientée objet et du code qui s'y exécute est désormais automatisée, plutôt qu'un processus monotone et ennuyeux.

Norme ODMG

Premier manifeste n'était formellement qu'un article présenté à Conférence sur les bases de données orientées objet et déductives un groupe d’individus. Comme vous pouvez le voir dans la sous-section précédente, les exigences du Manifeste étaient plus émotionnelles que celles explicitement spécifiées. En 1991, le consortium ODMG a été formé (puis cette abréviation a été élargie en Groupe de gestion de base de données d'objets, mais a acquis plus tard une interprétation plus large - Groupe de gestion des données d'objet). Le consortium ODMG est étroitement lié au consortium OMG, beaucoup plus vaste ( Groupe de gestion d'objets), créée deux ans plus tôt. Le principal objectif initial de l’ODMG était de développer une norme industrielle pour les bases de données orientées objet (un modèle commun). Le modèle objet de base OMG COM ( Modèle objet de base). Au cours de ses plus de dix ans d'existence, l'ODMG a publié trois versions de base de la norme, la plus récente étant appelée ODMG 3.0. 16

C'est drôle que même si ODMG (selon l'auteur) est issu d'OMG, ces dernières années, certaines normes OMG se sont appuyées sur le modèle objet ODMG. En particulier, la spécification du langage OCL ( Langage de contraintes d'objet), qui fait partie de la spécification globale du langage UML 1.4 (et UML 2.0). Dans cet article, nous n’avons pas pour objectif de faire une comparaison détaillée des approches OMG et ODMG et de renvoyer les lecteurs intéressés à Encyclopédie Kogalovsky et des documents provenant des sites Web de ces consortiums. Nous nous limiterons à un bref résumé des principales idées contenues dans la norme ODMG-3.

Architecture ODMG

L'architecture proposée par ODMG est illustrée à la Fig. 2.1. Cette architecture définit la manière dont les données sont stockées et les différents types d'accès des utilisateurs à ce « data store » 17 . Un magasin de données unique est accessible à partir d'un langage de définition de données, d'un langage de requête et d'un certain nombre de langages de manipulation de données. 18 Sur la fig. 2.1 ODL signifie Langage de définition d'objet, OQL – Langage de requête d'objet et OML- Langage de manipulation d'objets.

Riz. 2.1. Architecture ODMG

Au cœur de l’architecture se trouve modèle de données, représentant la structure organisationnelle dans laquelle toutes les données gérées par le SGBDOO sont stockées. Le langage de définition d'objet, le langage de requête et les langages de manipulation sont conçus de telle manière que toutes leurs capacités reposent sur le modèle de données. L'architecture permet une variété de structures de mise en œuvre pour stocker les données modélisées, mais une exigence importante est que toutes les bibliothèques de logiciels et tous les outils de support soient fournis dans un cadre orienté objet et doivent rester cohérents avec les données.

Les principaux composants de l'architecture sont les suivants.

Modèle de données objet. Toutes les données stockées par un SOODBMS sont structurées en termes de constructions de modèles de données. Le modèle de données définit la sémantique exacte de tous les concepts (voir ci-dessous pour plus de détails).

Langage de définition de données (ODL). Les schémas de base de données sont décrits en termes d'ODL, dans lequel les constructions de modèles de données sont instanciées sous la forme d'un langage de définition. ODL permet de décrire un schéma comme un ensemble d'interfaces de types d'objets, qui comprend une description des propriétés des types et des relations entre eux, ainsi que les noms des opérations et leurs paramètres. ODL n'est pas un langage de programmation complet ; l'implémentation du type doit être effectuée dans l'un des langages de la catégorie OML. De plus, ODL est virtuel langage dans le sens où la norme ODMG n'exige pas son implémentation dans les produits logiciels SOODBMS considérés comme conformes à la norme. Ces produits sont autorisés à prendre en charge des langages de définition équivalents qui incluent toutes les fonctionnalités d'ODL, mais sont adaptés aux caractéristiques d'un système particulier. Cependant, avoir une spécification de langage ODL dans la norme ODMG est important car le langage spécifie les propriétés du modèle de données.

Langage de requête d'objet (ODL). Le langage possède une syntaxe similaire à celle du langage SQL, mais s'appuie sur la sémantique du modèle objet ODMG. La norme permet l'utilisation directe d'OQL et son intégration dans l'un des langages de la catégorie OML.

Modèle de données relationnel

Presque tous les systèmes modernes sont basés sur relationnel modèles de gestion de bases de données (relationnelles). Nom relationnel Cela est dû au fait que chaque enregistrement d'une telle base de données contient des informations relatives à un seul objet spécifique.

DANS relationnel Dans le SGBD, toutes les données traitées sont présentées sous forme de tableaux plats. Les informations sur les objets d'un certain type sont présentées sous forme de tableau : les colonnes du tableau contiennent divers attributs d'objet et les lignes sont destinées à réduire les descriptions de tous les attributs à des instances individuelles d'objets.

Le modèle créé au stade de la modélisation de l'information satisfait le plus aux principes de relationnalité. Cependant, pour convertir ce modèle en modèle relationnel, il est nécessaire d'effectuer une procédure appelée normalisation.

La théorie de la normalisation fonctionne avec cinq formes normales. Ces formulaires sont conçus pour réduire la redondance des informations, de sorte que chaque formulaire normal ultérieur doit satisfaire aux exigences du précédent et à certaines conditions supplémentaires. Dans la conception pratique des bases de données, les quatrième et cinquième formes ne sont généralement pas utilisées. Nous nous sommes limités à considérer les quatre premières formes normales.

Introduisons les concepts nécessaires pour comprendre le processus de réduction d'un modèle à un schéma relationnel.

Attitude- abstraction de l'objet décrit comme un ensemble de ses propriétés. Lors de la phase de conception infologique, nous avons parlé de l'abstraction des objets et leur avons attribué certaines propriétés. Aujourd’hui, avec le design conceptuel, nous passons au niveau supérieur d’abstraction. A ce stade, les objets en tant que tels n'existent plus. Nous opérons avec un ensemble de propriétés qui définissent un objet.

Instance de relation- un ensemble de valeurs de propriétés d'un objet spécifique.

Clé primaire- un ensemble d'attributs identifiants, c'est-à-dire la signification de ces attributs est unique à un égard donné. Il n'existe pas deux instances d'une relation contenant les mêmes valeurs dans la clé primaire.

Attribut simple- un attribut dont les valeurs sont indivisibles.

Attribut complexe- un attribut dont la valeur est un ensemble de valeurs de plusieurs propriétés différentes d'un objet ou plusieurs valeurs d'une propriété.

Concepts d'essence..

Domaine

Le concept de domaine est plus spécifique aux bases de données, bien qu'il présente certaines analogies avec les sous-types de certains langages de programmation. Dans sa forme la plus générale, un domaine est défini en spécifiant un type de données de base auquel appartiennent les éléments du domaine et une expression logique arbitraire appliquée à l'élément du type de données. Si l'évaluation de cette expression booléenne renvoie vrai, alors l'élément de données est un élément de domaine.

L'interprétation intuitive la plus correcte du concept de domaine est de comprendre le domaine comme un ensemble potentiel admissible de valeurs d'un type donné. Par exemple, le domaine « Noms » dans notre exemple est défini sur un type chaîne de caractères de base, mais ses valeurs ne peuvent inclure que des chaînes pouvant représenter un nom (en particulier, de telles chaînes ne peuvent pas commencer par un caractère soft).

Il convient également de noter la charge sémantique de la notion de domaine : les données ne sont considérées comme comparables que si elles appartiennent au même domaine. Dans notre exemple, les valeurs de domaine « Gap Numbers » et « Group Numbers » sont de type entier, mais ne sont pas comparables. Notez que la plupart des SGBD relationnels n'utilisent pas le concept de domaine, bien qu'Oracle V.7 le prenne déjà en charge.

Le 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é sur la base de la théorie des ensembles, précisément en tant que modèle de données). L'Object DataBase Management Group a développé la norme ODMG-93 (Object DataBase Management Group). Cette norme n'a pas encore été pleinement mise en œuvre.

La structure d'une base de données orientée objet est représentée graphiquement sous la forme d'une arborescence 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 des objets, tandis que la structure et le comportement des objets de la même classe sont les mêmes. Chaque objet, à savoir une instance d'une classe, est considéré comme un descendant de l'objet dans lequel il est défini comme propriété. Propriétés de l'objet- soit un type standard, tel qu'une chaîne, soit un type de classe construit par l'utilisateur. Le comportement des objets est spécifié à l'aide de méthodes. Méthode est une certaine 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, des propriétés, leurs types et valeurs sont définis. Dans la base de données :

« BIBLIOTHÈQUE » – parent (ancêtre) pour « ABONNEMENT », « CATALOGUE », « NUMÉRO » ;

"CATALOG" est le parent de "BOOK".

« LIVRE » – différents objets peuvent avoir des parents identiques ou différents. S'il s'agit du même parent (même auteur), alors les numéros d'accession sont différents, mais l'isbn, l'UDC, le titre et l'auteur sont les mêmes.

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

Encapsulation limite la portée d'un nom de propriété aux limites de l'objet dans lequel il est défini. Ainsi, si le bien est ajouté au « CATALOGUE » Téléphone auteur du livre, ils sont ensuite obtenus de la même manière dans « ABONNEMENT » et « CATALOGUE ». La signification d’une propriété sera déterminée par l’objet dans lequel elle est encapsulée.

Héritageà l’inverse, cela étend la portée de la propriété à tous les enfants de l’objet. Ainsi, tous les objets de type « LIVRE » qui descendent de « RÉPERTOIRE » peuvent se voir attribuer les propriétés de l'isbn parent, de l'UDC, du titre et de l'auteur.

Polyformisme signifie la capacité du même code de programme à fonctionner avec différents types de données. En d’autres termes, cela signifie qu’il est permis que des objets de types différents aient des méthodes – procédures et fonctions – portant les mêmes noms. Lors de l'exécution d'un programme objet, les mêmes méthodes opèrent sur des objets différents selon le type de l'argument. Pour la base de données « LIBRARY », cela signifie que les objets de la classe « BOOK » qui ont des parents différents de la classe « DIRECTORY » 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 du code polymorphe. Dans une classe, une méthode n’a pas de corps, c’est-à-dire qu’il n’est pas défini quelles actions spécifiques elle doit effectuer. Chaque sous-classe effectue les opérations requises. L'encapsulation masque les détails d'implémentation de tous les objets en dehors d'une hiérarchie donnée.

Les avantages d'un modèle orienté objet par rapport à un modèle relationnel sont la capacité d'afficher des informations sur les relations complexes entre les objets et 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. Grâce à une approche orientée objet, des bases de données contenant de grands volumes d'informations sémantiques peuvent être créées, telles que multimédia et spécialisées dans des domaines spécifiques (géographique, design, etc.).

Les inconvénients de cette approche incluent une complexité conceptuelle élevée, des inconvénients de traitement des données et une faible vitesse d'exécution des requêtes.

Dans les années 90, des prototypes de bases de données opérationnelles orientées objet ont été créés. Il s'agit de POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Thème 5

Approche relationnelle pour construire un modèle informationnel-logique : concepts de base

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

Comme indiqué dans la section de la conférence 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 interconnectées (relations).

Les principales idées théoriques du modèle relationnel ont été exposées dans les travaux sur la théorie des relations du logicien américain Charles Souders Peirce (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 l'ensemble des relations est fermé par certaines opérations spéciales qui forment ensemble une algèbre abstraite. Cette propriété essentielle des relations a été utilisée dans le modèle relationnel pour développer un langage de manipulation de données.

En 1970, paraît l'article d'E. Codd sur la présentation de données organisées en tableaux bidimensionnels appelés relations. Codd a été le premier à introduire les concepts de base et les limites du modèle relationnel comme base du stockage des données, et a montré la possibilité de traiter les données en utilisant des opérations traditionnelles sur des ensembles et des opérations relationnelles spéciales introduites.

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 tableaux (relations). L'intégrité des données est assurée par des clés étrangères et primaires (voir paragraphe « Intégrité des données relationnelles »).

Les opérateurs du modèle relationnel sont un ensemble d'instructions qui permettent la sélection et la manipulation des données.

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

Terme du modèle relationnel	Description

Base de données (BD)	Un ensemble de tableaux et autres objets nécessaires à une représentation abstraite du domaine sélectionné
Schéma de base de données	Un ensemble d'en-têtes de tableau interdépendants les uns avec les autres
Attitude	Une table est une collection d'objets du monde réel caractérisés par des propriétés et des caractéristiques communes (champs de table)
En-tête de relation	Titre du tableau – noms des champs (colonnes) du tableau
Relation corporelle	Le corps du tableau est un ensemble de valeurs pour tous les objets du monde réel, qui peuvent être représentés sous forme d'enregistrements de tableau (lignes de tableau)
Diagramme de relation	Ligne d'en-tête de colonne du tableau (en-tête du tableau)
Attribut de relation	Nom de la colonne du tableau (champ du tableau)
Tuple relationnel	Ligne de tableau (enregistrement) – une représentation sans ambiguïté d'un objet du monde réel créé à l'aide des valeurs de champ de tableau
Domaine	Ensemble de valeurs d'attribut valides
Valeur d'attribut	Valeur du champ dans l'enregistrement (tuple)
Clé primaire	Un ou plusieurs attributs (dans le cas d'une clé composite) qui définissent de manière unique la valeur du tuple (valeur de la ligne du tableau)
Clé externe	Un attribut de table dont les valeurs correspondent aux valeurs de clé primaire dans une autre table associée (parente, primaire). Une clé étrangère peut être constituée d'un ou plusieurs attributs (clé étrangère composite). Si le nombre d'attributs d'une clé étrangère est inférieur au nombre d'attributs de la clé primaire correspondante, alors on parle de clé étrangère tronquée (partielle).
Degré (arité) de la relation	Nombre de colonnes du tableau
Rapport de puissance	Nombre de lignes (tuples) du tableau
Instance de relation	Un ensemble d'enregistrements (tuples) pour une table (relation) donnée. L'instance peut changer avec le temps. Puisqu'une base de données standard fonctionne actuellement avec une seule version d'une relation, une telle instance de la relation est appelée actuelle.
Type de données	Type de valeur d'élément de tableau
Attitude de base	Une relation contenant une ou plusieurs colonnes caractérisant les propriétés d'un objet, ainsi qu'une clé primaire
Relation dérivée	N'est-ce pas une relation fondamentale, c'est-à-dire ne caractérise pas les propriétés d'un objet et est utilisé pour fournir des relations entre d'autres tables ; il ne peut pas contenir de clé primaire. Si une clé primaire est spécifiée, elle est constituée des clés étrangères associées aux clés primaires de la relation sous-jacente
Connexion	Établit une relation entre les valeurs correspondantes dans les champs clés - la clé primaire d'une table et la clé étrangère d'une autre
Communication individuelle (1:1)	Lorsque vous utilisez ce type de relation, un enregistrement dans une table peut avoir au plus un enregistrement associé dans une autre table. Dans les deux tables, les champs clés doivent être primaires. Utilisé pour séparer les tables comportant de nombreux champs ou selon les exigences de la protection des données
Communication un-à-plusieurs (1:M)	Lorsqu'on utilise ce type de relation, chaque enregistrement d'une table peut correspondre à plusieurs enregistrements de la seconde, mais chaque enregistrement de la deuxième table ne correspond qu'à un seul enregistrement de la première table. La première table doit avoir une clé primaire, la seconde doit avoir une clé étrangère.
Relation plusieurs-à-plusieurs (N:M)	Avec ce type de relation, un enregistrement de la première table peut correspondre à plusieurs enregistrements de la deuxième table, mais un enregistrement de la deuxième table peut correspondre à plusieurs enregistrements de la première. L'unicité des clés pour de telles tables n'est pas requise. Lors du processus de conception d'un schéma de base de données, ces connexions sont transformées. Pour ce faire, il est nécessaire d'introduire une relation auxiliaire qui permet de remplacer la relation plusieurs-à-plusieurs par deux relations un-à-plusieurs.

La structure des données du modèle relationnel implique de représenter le domaine du problème considéré comme un ensemble de relations interconnectées.

Dans chaque connexion, une relation peut agir comme la relation principale (de base, parent) et l'autre peut agir comme une relation subordonnée (dérivée, enfant). 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 (identifie de manière unique le tuple de la relation principale) ; la relation subordonnée doit avoir 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é à un seul tuple de la relation principale.

De nombreuses tables interconnectées se forment schéma de base de données.

Donc l'attitude R. est un tableau bidimensionnel contenant des données.

Mathématiquement N relation -aire R. est l'ensemble des produits cartésiens D 1 ×D 2 ×…×D n ensembles (domaines) ré 1 , ré 2 ,…,ré n(n≥1), pas nécessairement différent :

R D 1 ×D 2 ×…×D n,

Où D 1 ×D 2 ×…×D n– produit cartésien complet, c'est-à-dire un ensemble de toutes les combinaisons possibles de n éléments chacune, où chaque élément est extrait de son propre domaine.

Domaine est un concept sémantique qui peut être considéré comme un sous-ensemble de valeurs d'un certain type de données ayant une signification spécifique.

Propriétés du domaine:

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

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

Peut avoir une condition logique qui vous permet de décrire un sous-ensemble de données valides pour ce domaine,

Porte une certaine charge sémantique.

La principale signification 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 la forme

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

Les noms d'attribut sont uniques au sein d'une relation. Souvent, les noms d'attributs sont les mêmes que les noms de domaine correspondants.

Une relation R définie sur un ensemble de domaines contient deux parties : un en-tête et un 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 spécifiée :

(<A1 : D1>, <A2 : D2 >, …, <Et n>).

L'en-tête est statique : il ne change pas lors du travail avec la base de données. Si des attributs sont modifiés, ajoutés ou supprimés dans la relation, alors une relation différente est obtenue. Même si le nom est enregistré.

Corps relation contient un ensemble de tuples de relation.

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

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

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

De telle sorte que la valeur Vali attribut Un je appartient au domaine D je.

Le corps d’une relation est un ensemble de tuples, c’est-à-dire un sous-ensemble du produit cartésien des domaines. Ainsi, le corps d’une relation est en réalité une relation au sens mathématique du terme. Le corps de la relation peut changer lors de l'utilisation de la base de données, car les tuples peuvent changer, être ajoutés et supprimés au fil du temps.

La relation s’écrit généralement sous la forme :

R.(<A1 : D1>, <A2 : D2 >, …, <Et n>),

ou en abrégé : R.(Un 1, Un 2, …, Un) ou R..

Diagramme de relation est un ensemble d'en-têtes de relation inclus dans la base de données, c'est-à-dire une liste de noms d'attributs d'une relation donnée indiquant le domaine auquel ils appartiennent :

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

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

Par exemple, si un domaine contient des données numériques, alors toutes les opérations de comparaison sont valables pour celui-ci : θ == (=,<>,>=,<=,<,>). Cependant, pour les domaines contenant des données de caractères, non seulement des opérations de comparaison d'égalité et d'inégalité de valeurs peuvent être spécifiées. Si un domaine donné a un ordre lexicographique, alors il dispose également d'un ensemble complet d'opérations de comparaison.

Les schémas de deux relations sont appelés équivalent, s'ils ont le même degré, et qu'il est possible d'ordonner les noms d'attributs dans les schémas de telle manière que les attributs comparables, c'est-à-dire les attributs qui prennent des valeurs du même domaine, seront aux mêmes endroits.

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

Avoir le même nombre d’attributs ;

La présence d'attributs portant les mêmes noms ;

La présence de lignes identiques dans les relations, en tenant compte du fait que l'ordre des attributs peut varier ;

Des relations de ce genre sont des images différentes d’une même relation.

Propriétés des relations découlent directement de la définition donnée précédemment de la relation. Ces propriétés constituent les principales différences entre les relations de modèles de données relationnelles et les tables simples :

Unicité du nom de la relation. Le nom d’une relation doit être différent des noms des autres relations.

Unicité des tuples. Il n'y a pas de tuples identiques dans une relation. En effet, le corps d’une relation est un ensemble de tuples et, comme tout ensemble, ne peut contenir d’éléments indiscernables. Les tableaux, contrairement aux relations, peuvent contenir des lignes identiques. Chaque cellule de relation contient uniquement une valeur atomique (indivisible).

Le désordre des tuples. Les tuples ne sont pas ordonnés (de haut en bas), car le corps de la relation est un ensemble, et l'ensemble n'est pas ordonné (à titre de comparaison, les lignes des tableaux sont ordonnées). La même relation peut être représentée par différents tableaux dans lesquels les lignes sont dans des ordres différents.

Trouble des attributs. Les attributs ne sont pas ordonnés (de gauche à droite).

L'unicité du nom de l'attribut au sein de la relation. Chaque attribut a un nom unique au sein de la relation, ce qui signifie que l'ordre des attributs n'a pas d'importance (en comparaison, les colonnes du tableau sont ordonnées). Cette propriété distingue quelque peu une relation de la définition mathématique d'une relation. La même relation peut être représentée par différents tableaux dans lesquels les colonnes sont dans des ordres différents.

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 que chaque attribut est associé à un domaine de valeurs (un type élémentaire distinct) et que les valeurs d'attribut sont extraites du même domaine. Le schéma et les tuples d'une relation sont des ensembles et non des listes, donc l'ordre dans lequel ils sont présentés n'a pas d'importance. À titre de comparaison, vous pouvez placer diverses informations dans les cellules d'un tableau : tableaux, structures, autres tableaux, etc.

Commentaire:

Des propriétés de la relation il résulte que pas tout le monde une table peut être une relation. Pour qu'un tableau définisse une relation, le tableau doit avoir une structure simple (contenir uniquement des lignes et des colonnes, et chaque ligne doit avoir le même nombre de champs), le tableau ne doit pas avoir de lignes identiques, aucune colonne du tableau doit ne contiennent qu’un seul type de données, tous les types de données utilisés doivent être simples.

Il convient de noter que le modèle relationnel représente une base de données sous la forme d'un ensemble de relations interconnectées, appelées schéma de base de données relationnelle.

Un exemple de la structure logique d’une base de données OO de bibliothéconomie est présenté dans la Fig. 3.14. Ici, un objet de type LIBRARY est le parent des objets instance des classes SUBSCRIBER, DIRECTORY et ISSUE. Différents objets de type BOOK qui ont le même parent doivent différer au moins par le numéro d'accession (unique pour chaque instance du livre), mais avoir les mêmes valeurs de propriété isbn, udk, titre Et auteur.

Figure 3.14. Structure logique d'une base de données de bibliothéconomie

La structure logique d'une base de données orientée objet est superficiellement similaire à la structure d'une base de données hiérarchique. La principale différence entre eux réside dans les méthodes de manipulation des données. Pour effectuer des actions sur les données d'une base de données MOO, 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 de la formation automatique et de l'ajustement ultérieur d'index (tables d'index) contenant des informations pour une récupération rapide des données.

Considérons brièvement les concepts d'encapsulation, d'héritage et de polymorphisme en relation avec les bases de données MOO.

Encapsulation limite la portée d'un nom de propriété aux limites de l'objet dans lequel il est défini. Ainsi, si vous ajoutez une propriété à un objet de type DIRECTORY qui précise le numéro de téléphone de l'auteur du livre et porte le nom Téléphone, nous obtiendrons ensuite les propriétés du même nom pour les objets SUBSCRIBER et DIRECTORY. La signification d’une telle propriété sera déterminée par l’objet dans lequel elle est encapsulée.

Héritage, au contraire, elle étend le champ de la propriété à tous les descendants de l'objet. Ainsi, tous les objets de type BOOK descendants d'un objet de type DIRECTORY peuvent se voir attribuer les propriétés de l'objet parent : isbn, udk, titre Et auteur. S'il est nécessaire d'étendre le mécanisme d'héritage à des objets qui ne sont pas des parents immédiats (par exemple, entre deux enfants d'un même parent), alors une propriété abstraite de type abs est définie dans leur ancêtre commun. Ainsi, la définition des propriétés abstraites billet Et nombre dans l'objet LIBRARY fait que ces propriétés sont héritées par tous les objets enfants SUBSCRIBER, BOOK et ISSUE. Ce n'est pas un hasard si la valeur des propriétés billet les classes SUBSCRIBER et ISSUING indiquées sur la figure seront les mêmes - 00015.

Polymorphisme dans les langages de programmation orientés objet, on entend la capacité d'un même code de programme à fonctionner avec différents types de données. En d’autres termes, cela signifie qu’il est permis que des objets de types différents aient des méthodes (procédures ou fonctions) portant les mêmes noms. Lors de l'exécution d'un programme objet, les mêmes méthodes opèrent sur des objets différents selon le type de l'argument. Par rapport à notre base de données orientée objet, le polymorphisme signifie que les objets de la classe BOOK qui ont des parents différents de la classe DIRECTORY peuvent avoir un ensemble de propriétés différent. Par conséquent, les programmes permettant de travailler avec des objets de la classe BOOK peuvent contenir du code polymorphe.

Rechercher dans une base de données orientée objet consiste à rechercher les similitudes entre un objet spécifié par l'utilisateur et des objets stockés dans la base de données. Un objet défini par l'utilisateur, appelé objet goal (la propriété de l'objet est de type goal), peut généralement être un sous-ensemble de la hiérarchie entière 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éros de carte de bibliothèque et de noms d'abonnés ayant reçu au moins un livre de la bibliothèque est illustré à la Fig. 3.15.

Principal dignité Le MOO de données par rapport au relationnel est la capacité d'afficher des informations sur les relations complexes entre les objets. Le MOO de données vous permet d'identifier un enregistrement de base de données individuel et de déterminer les fonctions pour les traiter.

Désavantage Les MOO se caractérisent par une complexité conceptuelle élevée, des inconvénients de traitement des données et une faible vitesse d'exécution des requêtes.

Figure 3.15. Fragment de base de données avec objet cible

Revenons à la tâche Commandes, présentée sous la forme d'un modèle de données relationnel dans la Fig. 3.8, et considérons-le en termes de base de données orientée objet. Il y a trois classes dans l'exemple : « Clientèle», « Ordres" Et " Marchandises" Objets de la classe " Clientèle» sont des clients spécifiques ; propriétés de classe - numéro de client, nom du client Ville, Statut, etc. Méthodes de classe - " Créer une commande», « Payer l'addition" et ainsi de suite. Une méthode est une opération qui peut être appliquée à un objet ; une méthode est ce qu'un objet doit faire. Classe correspondant au tableau " détails de la commande", non requis. Les données du tableau peuvent faire partie de la classe " Ordres" Disponibilité en classe " Clientèle" méthode " Créer une commande" conduit à une interaction avec des objets de classe " Ordres" Et " Marchandises" Dans ce cas, l’utilisateur n’a pas besoin de connaître cette interaction d’objets. L'utilisateur accède uniquement à l'objet " Ordres" et utilise la méthode " Créer une commande" Le fait de l'impact sur d'autres bases de données peut être caché à l'utilisateur. Si la méthode " Créer une commande", à son tour, appelle la méthode " Vérifier la solvabilité du client", alors ce fait peut également être caché à l'utilisateur. Les bases de données relationnelles nécessitent que les procédures soient écrites en Visual Basic pour Application (VBA) pour exécuter les mêmes fonctions.

Dans les années 90, il existait des prototypes expérimentaux de systèmes de gestion de bases de données OO. Actuellement, de tels systèmes sont répandus. Il s'agit notamment des SGBD suivants : POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center), ainsi que Iris, Orion et Postgres.

04/06/2004 Sikha 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 à des exigences d'application différentes de celles servies et desservies par les systèmes de bases de données relationnelles. Examinons 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 surmonter pour que la technologie des bases de données orientées objet devienne aussi répandue que la technologie des bases de données relationnelles.

Le développement de systèmes de bases de données orientés objet (appelés technologies de bases de données de cinquième génération) a commencé au milieu des années 1980 en raison de la nécessité de répondre aux exigences d'applications autres que celles des applications de traitement de données qui sont caractéristiques des systèmes de bases de données relationnelles (les technologie de base de données de quatrième génération). Tentatives d'utilisation des technologies de bases de données relationnelles dans des applications complexes telles 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 révélé 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 et ont été 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 celles qui combinent l'orientation objet avec les capacités de la base de données. Orientation de l'objet permet de représenter et de modéliser plus directement des problèmes du monde réel, et fonctionnalité de base de données requis pour garantir la stabilité des données et l’accès parallèle multi-utilisateurs aux informations de l’application.

Il existe actuellement plus de 25 systèmes OBD sur le marché. Parmi eux figurent le système 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 et Informix comprenaient des outils orientés objet. Beaucoup de ces produits sont apparus dans la seconde moitié des années 80 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 une des raisons pour lesquelles le marché mondial des applications réelles n'est toujours pas pressé d'accepter les systèmes OBD. Parmi les ODB modernes, il n'existe pratiquement aucun système à part entière comparable aux systèmes de bases de données relationnelles modernes. Discutons des principales réalisations et problèmes associés à l'état actuel de l'OBD.

Modèle OOBD

La raison de l'émergence des systèmes de bases de données orientés objet était la nécessité d'une représentation et d'une modélisation plus adéquates des entités du monde réel, puisque les ODB fournissent un modèle de données beaucoup plus développé 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 différée.

Dans un modèle de données orienté objet, toute entité du monde réel est représentée par un seul concept : objet. Un objet est associé à un état et à un comportement. 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, quant à lui, consiste en 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éterminé à l'aide de méthodes, qui opèrent sur l’état d’un objet.

Chaque objet a un défini par le système identifiant unique. Les objets ayant les mêmes propriétés et comportements 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 selon une hiérarchie de classes. La sous-classe hérite des propriétés et méthodes de la superclasse ; De plus, les sous-classes peuvent avoir des propriétés et des méthodes individuelles. Dans certains systèmes, comme ORION, une classe peut avoir plusieurs superclasses (héritage multiple), alors que dans d'autres systèmes, le nombre de superclasses est limité à une (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 de celle-ci.

Avantages du modèle OOBD

Les bases de données orientées objet permettent de représenter des objets complexes de manière plus directe que les systèmes relationnels. Examinons quelques-unes des réalisations existantes dans le domaine de l'OOBD. Les systèmes OODB permettent aux utilisateurs de définir des abstractions ; faciliter la conception de certaines connexions ; é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, le besoin de connexions est éliminé ; dans certaines situations, ils offrent des performances supérieures à celles des 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 des objets a été développée – mais 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 ces abstractions. Ces nouvelles abstractions peuvent correspondre aux structures de données requises dans des problèmes complexes, à de nouveaux types de données abstraits. En d'autres termes, les packages OODB modernes donnent à l'utilisateur la possibilité 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 la classe, chacune avec un identifiant d'objet unique, de récupérer ces instances une par une. un ou en groupes, et charger et exécuter des méthodes. De plus, les OODB permettent de définir des objets comme des collections d'autres objets, et les collections permettent plusieurs niveaux d'imbrication. Les propriétés peuvent également avoir une structure complexe et sont définies à l'aide du constructeur de collection. De plus, ils peuvent avoir des objets non primitifs comme valeurs, 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 réalisé grâce à des relations et des jointures supplémentaires.

ENCORE est un exemple de package OODB doté de toutes les fonctionnalités mentionnées. Le modèle de données d'ENCORE est principalement basé sur l'abstraction des données. ENCORE permet le sous-typage (héritage), l'encapsulation, les structures complexes, l'identification d'objets et la liaison de méthodes paresseuses. De plus, ENCORE offre la possibilité de lier des objets à l'aide de propriétés. Dans le système ENCORE, une propriété p relie un objet x à un ensemble d'objets S, sans aucune indication sur la manière dont la relation est calculée. Il peut être calculé en spécifiant directement l'identifiant de l'ensemble S (ou les identifiants de ses membres) ou en faisant correspondre les valeurs d'autres propriétés, comme dans une jointure.

Conception légère de certaines connexions

Les bases de données orientées objet prennent en charge une fonction de relation inverse pour exprimer des références mutuelles entre deux objets (relation binaire). Un tel système garantit l'intégrité référentielle en établissant un backlink approprié immédiatement après la création du lien aller. Il existe même une option pour 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'objet, générés automatiquement par le système et garantis uniques pour chaque objet. Ceci, associé au fait que le modèle OODB élimine le besoin de clés définies par l'utilisateur, confère aux bases de données orientées objet d'autres avantages. Premièrement, l'identifiant de l'objet ne peut pas être modifié par l'application. Deuxièmement, le concept d'identifiabilité d'un objet implique un concept d'identité distinct et cohérent, indépendant de la manière dont l'objet est accédé ou de la manière dont l'objet est modélisé par des 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 ont les mêmes valeurs. Dans le modèle RDB, où l'identification des objets est effectuée via des clés définies par l'utilisateur, ces objets seraient considérés comme le même objet.

Présence de prédicats de comparaison

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

É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 identifiant d'objet).
Égalité des objets basée sur des valeurs. Cela 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 qui lui est égale en valeur.
Égalité de propriété basée sur la valeur.
Égalité des propriétés en fonction de leur identité.

Moins besoin de connexions

La possibilité de naviguer à travers les structures d'objets et les expressions de chemin qui en résultent en termes d'attributs d'objet nous offre une nouvelle façon d'aborder le problème des connexions dans OODB. Une jointure relationnelle est un mécanisme qui fait correspondre deux relations en fonction des valeurs des paires d'attributs correspondantes dans ces relations. Étant donné que dans OODB, deux classes 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 Étudiant et École, et chacune de ces classes a des attributs Nom et Âge. Bien que les domaines des attributs Name et Age de la classe School puissent ne pas être les mêmes que les domaines des attributs Name et Age de la classe Student, nous pouvons souhaiter associer ces classes en fonction des valeurs de ces attributs (par exemple trouver tous les élèves dont l'âge est inférieur à l'âge de l'école qu'ils fréquentent).

Mais, comme nous l'avons déjà noté, la prise en charge des expressions de chemin peut réduire considérablement le besoin de connexion de classes par rapport à la situation dans un RDB. Il existe même des situations dans lesquelles le besoin d’une jointure relationnelle peut être entièrement éliminé. Par exemple, lorsque le domaine d'un attribut de classe A est la classe B, la récupération des identifiants d'objet d'une classe stockés en tant que valeurs d'attribut d'une autre classe élimine le besoin de jointures d'objets implicites.

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

Gain de performances

Les ODB modernes ne sont pas des systèmes de bases de données à part entière par rapport aux RDB modernes ; les ODB ont plusieurs fonctionnalités qui leur offrent des avantages en termes de performances.

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 une application a déjà récupéré l'objet X et souhaite maintenant récupérer l'objet Y, alors le SGBD peut récupérer l'objet Y en trouvant son identifiant. Si cet identifiant est l'adresse physique d'un objet, alors l'objet peut être récupéré directement ; si l'identifiant est une adresse logique, alors l'objet en trouvant l'élément de table de hachage correspondant (en supposant que le système maintient une table de hachage qui mappe l'identifiant d'objet à une adresse physique). Dans un RDB, cela pourrait ne pas être si simple, car le RDB ne prend pas en charge les identifiants d'objet.
La deuxième fonctionnalité d'OODB qui offre des avantages en termes de performances est que dans la plupart des ODB, lorsqu'un objet est chargé en mémoire, les identifiants d'objet stockés dans cet objet sont convertis en pointeurs de mémoire. Étant donné que les RDB ne stockent pas d'identifiants d'objet, ils ne peuvent pas stocker de pointeurs mémoire vers d'autres tuples. L'incapacité de naviguer dans les objets contenus en mémoire est une propriété fondamentale des RDB, et la diminution des performances qui en résulte ne peut être compensée par une simple augmentation de la quantité de mémoire tampon. Ainsi, lors de l'exécution d'applications qui impliquent une navigation répétée d'objets associés chargés en mémoire, les OODB peuvent surpasser considérablement les RDB en termes de performances.
De plus, même si les ODB ne sont pas indexés, il peut être pratique d'effectuer des requêtes arbitraires correspondant à la structure de l'objet par analyse séquentielle, 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 analyse séquentielle. Cependant, les requêtes formulées sur la base de relations d'objet qui ne sont pas directement modélisées par des références fonctionnent de manière inefficace.

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

Le RDB ne prend pas en charge la gestion des versions ou les transactions de longue durée. Une telle prise en charge est disponible dans certains ODB, bien qu'avec des capacités limitées.

Algèbre des objets

L'algèbre des objets n'est pas aussi détaillée ou mature que l'algèbre relationnelle. Quoi qu’il en soit, une telle algèbre existe et elle définit cinq opérations fondamentales qui préservent les objets : l’union, la différence, la sélection, la génération et la cartographie. A partir de ces opérations fondamentales, d'autres opérations peuvent être définies, comme l'intersection. Les règles de transformation pour l'optimisation logique des expressions d'algèbre d'objets tout en préservant l'équivalence sont dérivées dans et . Alors que les opérations d'union, de différence et de mappage produisent principalement un mappage un-à-un, les opérations de sélection et de génération produisent un mappage un-à-plusieurs. La persistance des 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 ensembles. L'opérateur de différence renvoie un ensemble d'objets qui appartiennent à l'ensemble P mais pas à l'ensemble Q. select renvoie un sous-ensemble de l'ensemble saisi. 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 OOBD

On s’attendait à ce que les méthodes orientées objet permettent à la technologie des bases de données de faire un bond en avant. Cependant, malgré les réalisations ci-dessus, l'OBD n'a pas pu avoir un impact significatif sur la situation dans ce domaine. Le modèle et la technologie OOBD présentent encore des faiblesses.

Les bases de données orientées objet ne disposent pas des fonctionnalités de base auxquelles les utilisateurs de systèmes de bases de données sont habitués et s'attendent donc à voir. Entre autres choses, on peut noter : le manque d’interopérabilité entre le RDB et l’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 opinions ; problèmes de sécurité; 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 des 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 l’OODB ait un impact significatif sur le marché des bases de données, un certain nombre de conditions doivent être remplies.

Transformez OODB en systèmes de bases de données à part entière suffisamment compatibles avec RDB. Un chemin de migration est nécessaire pour assurer la coexistence des produits existants et nouveaux, ainsi qu'une transition en douceur des premiers vers les seconds.
Proposer des outils de développement d'applications et des moyens d'accès à des bases de données orientées objet.
Unifiez les architectures RDB et ODB.
Unifiez les modèles de données RDB et ODB.

Des moyens insuffisants pour optimiser les requêtes

L'un des problèmes les plus importants d'OODB est l'optimisation des requêtes déclaratives. L'optimisation des requêtes ODB est rendue plus difficile 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.

La possibilité pour les utilisateurs de définir de nouveaux types et classes à l'aide de l'héritage rend l'optimisation des requêtes à la fois plus facile et plus difficile. Un exemple où cette fonctionnalité facilite l'optimisation est une requête impliquant l'intersection des ensembles Employés et Superviseurs. Si Employee est une superclasse de Supervisor, alors l'optimiseur peut supposer que Supervisors est son propre sous-ensemble d'Employees et simplifier la procédure d'intersection définie. Un exemple où des types de données supplémentaires limitent les options d'optimisation est l'union des ensembles Étudiants et Employés ; La superclasse des deux classes est la classe Person. Si nous voulions trouver tous les superviseurs d’étudiants et d’employés, nous ferions d’abord la jointure et utiliserions Supervisor() .
Les requêtes peuvent s'appuyer sur des opérations sur des collections, mais les types d'optimisation qui affectent les ensembles (ou multiensembles, 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 être capable d'appliquer des routines d'optimisation spécifiques à des types donnés, ainsi que des routines d'optimisation qui prennent en compte les relations entre les objets de différents types.
La complexité du traitement des requêtes dans OODB est aggravée par la présence d'objets, de méthodes et d'encapsulation complexes. Les objets complexes génèrent des expressions de chemin, ce qui rend le traitement des requêtes plus complexe. La création d'index sur des expressions de chemin, en particulier lorsque les expressions contiennent des méthodes arbitraires, 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 un ordre dans lequel les méthodes d'expression de chemin sont appelées, et cet ordre peut s'avérer assez inefficace. Par exemple, l'expression de chemin Orders.part.name est mieux évaluée de droite à gauche s'il y a beaucoup de commandes et peu de pièces, mais s'il y a beaucoup de pièces et peu de commandes, l'expression est mieux évaluée de gauche à droite. De plus, les expressions de chemin sont parfois traitées plus efficacement à l’aide de Join. Considérons, par exemple, une requête avec une expression de chemin s.comp.name, où s appartient à l'ensemble Students. Il pourrait être plus efficace (si le nombre de sociétés, composition, 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 de l'étudiant au nom de l'entreprise impliquerait de joindre l'ensemble Students à un ensemble de tuples en faisant correspondre la propriété comp de la classe d'étudiant avec la valeur de l'attribut Company d'un tuple.
Les langages de requête OODB prennent en charge l'utilisation de structures imbriquées, ce qui, encore une fois, peut compliquer considérablement le processus d'optimisation, car ils le transforment d'un problème local en un problème global, puisqu'une connaissance globale de l'ensemble de l'expression de requête est requise.
Lorsque les objets sont identifiables, la question se pose de savoir ce que l’on entend par l’égalité de deux objets. Ce problème se retrouve dans les langages où les opérateurs de comparaison d'égalité sont utilisés dans les prédicats et où des décisions doivent être prises concernant 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 traiter les problèmes associés à la création de nouveaux objets et aux définitions alternatives de l'égalité.

Ces problèmes indiquent que l'optimisation des requêtes orientées objet est extrêmement difficile et reste un domaine de recherche. Les systèmes de bases de données orientés objet d'aujourd'hui proposent des stratégies d'optimisation assez simples. Le problème de l’optimisation des connexions nécessite également plus d’attention.

Manque d'algèbre de requête standard

Un autre inconvénient majeur de l’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ête formels différents basés sur l'algèbre et le calcul ont été proposés pour OODB. Ces algèbres et calculs diffèrent à plusieurs égards, à la fois par leur expressivité et par leur support pour 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 des résultats intermédiaires. KOLA, l'un des packages OBD, est un produit purement fonctionnel ; il n'utilise pas de variables. L'auteur affirme que c'est précisément grâce à l'absence de variables que l'algèbre KOLA permet la construction de systèmes de règles plus puissants.

Dans RDB, il existe une correspondance étroite entre les opérations algébriques et les primitives du système physique de bas niveau. Cette correspondance stricte est obtenue grâce à des mappages entre relations et fichiers, et entre tuples et enregistrements. Cependant, dans OODB, il n’existe pas de correspondance intuitive similaire entre les opérations de l’algèbre des objets et les primitives des systèmes physiques. Chaque fois qu'on parle de génération de plan d'exécution, il est également nécessaire, tout d'abord, de définir des primitives de manipulation d'objets de bas niveau.

Manque de prise en charge des requêtes

La plupart des ODB ne prennent pas en charge les requêtes. Sur les quelques systèmes disposant de fonctionnalités suffisantes, le langage de requête n'est pas compatible avec ANSI SQL. Parmi ces outils de support de requêtes, il n'y a pas de sous-requêtes imbriquées, de requêtes avec des ensembles (union, intersection, différence), de fonctions d'agrégation et de GROUP BY, joignant plusieurs classes - fonctionnalités entièrement prises en charge dans le RDB.

De plus, il n’existe pas de standard pour les requêtes objet, même s’il faut dire que des tentatives ont été faites pour développer un langage objet, SQL. SQL3 sera probablement retardé de plusieurs années.

Manque de prise en charge des vues

OODB ne prend pas en charge les vues. Bien que plusieurs propositions aient été avancées à ce sujet, aucun consensus n'a été atteint sur la manière dont devrait fonctionner le mécanisme de visualisation dans OODB. Le développement d'un mécanisme de représentation orienté objet est compliqué par des propriétés de modèle telles que l'identifiabilité des objets. Quel est l'identifiant d'un objet dans une vue ? D'un autre côté, certains pensent que la capacité d'encapsuler les données et l'héritage permet d'éviter les définitions explicites de vues.

Problèmes de sécurité

Les RDB prennent en charge l'autorisation, contrairement à la plupart des OODB. Les RDB permettent aux utilisateurs d'accorder et de révoquer les droits de lecture ou de modification des définitions et des tuples dans les relations et les vues. Les ODB ne pourront se généraliser dans les entreprises que si cette fonctionnalité est améliorée.

Certains systèmes OODB exigent que les utilisateurs définissent et libèrent explicitement les verrous. Les systèmes RDB définissent et libèrent automatiquement des verrous lors du traitement des requêtes des utilisateurs et des instructions de mise à jour.

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

Outre le fait qu'un modèle de données standard unique n'a pas encore été développé pour l'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 la 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 contrôle automatique des extensions de classe. Si une extension de classe est requise, l'utilisateur doit définir une collection pour celle-ci et s'assurer que toutes les insertions et suppressions sont enregistrées dans la collection en temps opportun.

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

Il n'existe aucun mécanisme pour déclarer les propriétés clés des attributs (par exemple, un attribut de classe ne peut pas être déclaré comme la clé primaire d'une classe), ni les contraintes d'unicité, les contraintes d'intégrité explicites ou les pré- et postconditions de méthode. Bien que tout cela puisse être fait à l’aide de méthodes, les contraintes explicites seraient plus conviviales, produiraient moins d’erreurs et seraient plus testables et modifiables.

Options de réglage des performances limitées

La plupart des ODB ne fournissent que des moyens limités de réglage paramétré des performances. Dans RDB, les installateurs ont la possibilité de personnaliser les performances du système en spécifiant 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 une future insertion 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 parcourir les liens et coder des opérations à l’aide de ces liens, mais il n’existe aucune opération générique prédéfinie utilisant différents types de sémantique de lien. Toutes les références sont supposées pointer vers des objets indépendants, et la sémantique des relations spéciales au sein d'objets complexes est caché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 retravailler les hiérarchies de classes ; tendance de l'OODB à surcharger les opérations du système.

Gain de performances 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 identifiants d'objet et de manipuler rapidement les objets dans la mémoire principale à l'aide de pointeurs, les OODB surpasseraient en réalité les RDB de deux à trois ordres de grandeur. Cependant, la plupart des applications qui nécessitent l'accès aux objets via des identifiants nécessitent également les capacités d'accès à la base de données et de mise à jour fournies par le RDB. Ces fonctionnalités incluent le chargement groupé de bases de données ; créer, mettre à jour et supprimer des objets individuels (un à la fois) ; récupérer de la classe un ou plusieurs objets qui satisfont à certaines conditions de recherche ; connecter plusieurs classes; enregistrement des transactions, etc. Lors de l'exécution de telles applications, les OODB n'offrent aucun avantage en termes de performances par rapport aux RDB.

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

***

En raison de ces faiblesses, les ODB n'ont pas réussi à répondre à leurs attentes : fournir toutes les fonctionnalités importantes souhaitées par les applications cibles. Par rapport à la plupart des systèmes modernes, le terme « ODB » est utilisé de manière incorrecte. Presque tous les ODB 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, bien que le modèle de données orienté objet soit à bien des égards plus riche que le modèle relationnel, le modèle orienté objet n’a pas encore pleinement atteint sa maturité. Aujourd’hui, les systèmes OOBD présentent clairement plus d’inconvénients que d’avantages.

Littérature

S. Abiteboul, A. Bonner, « Objets et vues ». ACM SIGMOD Int. Conf. Sur la gestion des données, 1991.
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.
F. Bancilhon, « Systèmes de bases de données orientés objet ». 7e Conférence ACM SIGART/SIGMOD, 1988.
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.
J. Banerjee, W. Kim, K.C. Kim, « Requêtes dans les bases de données orientées objet ». Conférence IEEE sur l'ingénierie des données, février. 1988.
D. Beech, « Fondations pour l'évolution et les bases de données relationnelles aux objets. » Proc. Technologie de base de données étendue, mars. 1988.
E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, « Langages de requête orientés objet : notion et enjeux ». Transactions IEEE sur l'ingénierie des connaissances et des données, mars. 1992.
A.W. Brown, Bases de données orientées objet, applications en génie logiciel. New York : McGraw-Hill, 1991.
R.G.G. Cattell, gestion des données objet, systèmes de bases de données orientées objet et relationnelles étendues. Addison-Wesley, 1991.
M. Cherniack, « Formulaire(s) sur fonction(s) : algèbre de requête KOLA. » Rapport technique, Brown University, déc. 1995.
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.
SI. Cruz, DOODLE : Langage visuel pour bases de données orientées objet. ACM SIGMOD Int. Conf. Sur la gestion des données, 1992.
U. Dayal, « Requêtes et vues dans un modèle de données orienté objet. » 2e International. Travail. Sur les langages de programmation de bases de données, juin 1989.
K.A. Dittrich, K.R. Dittrich, « Là où les SGBD orientés objet devraient faire mieux : 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.
U. Erlingsson, "Object-Qriented Query Optimization", manuscrit non publié.
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.
L. Fegaras, D. Maier, T. Sheard, «Spécification des optimiseurs de requêtes basés sur des règles dans un cadre réfléchissant». 3e Int. Conf. sur les bases de données déductives et orientées objet, Phoenix, Arizona, décembre 2017. 1993.
S. Heiler, S. Zdonik, « Vues d'objet : étendre la vision. » 6e International. Conf. Sur l'ingénierie des données, 1990.
J.G. Hughes, Bases de données orientées objet. New York : Prentice-Hall, 1991.
S. Khoshafian, « Aperçu des bases de données orientées objet ». Technologie de l'information et des logiciels, avril. 1990.
S. Khoshafian, Bases de données orientées objet, New York : John Wiley & Sons, 1993.
S. Khoshafian, G. Copeland, « Identité d'objet ». 1er Int. Conf. Sur les systèmes, langages et applications de programmation orientée objet, oct. 1986.
W. Kim, « Fondation pour les bases de données orientées objet ». Technologie MCC. Rep., N. ACA-ST-248-88, août. 1988.
W. Kim, Introduction aux bases de données orientées objet. Presses du MIT, 1991.
W. Kim, « Systèmes de bases 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.
T.W. Leung et al., « Modèle de données Aqua et algèbre ». Rapport technique CS-93-09, Brown University, mars. 1993.
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.
E.A. Rudensteiner, « Multiview : Méthodologie pour prendre en charge plusieurs vues dans les bases de données orientées objet. » 18e International. Conf. Sur les très grandes bases de données, 1992.
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.
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.
M. Stefik, D.G. Bobrow, « Programmation orientée objet : thèmes et variations. » The AI Mag., janvier. 1986.
M. Stonebraker et al., « Manifeste du système de base de données de troisième génération ». Comité pour les fonctions avancées de SGBD, Université de Californie, Berkeley, 1990.
D.D. Straube, M.T. Ozsu, « Requêtes et traitement des requêtes dans les systèmes de bases de données orientés objet. » Transactions ACM sur les systèmes d'information, octobre. 1990.
D.D. Straube, M.T. Ozsu, « Génération de plan d'exécution pour un modèle de données orienté objet ». 2e International. Conf. sur les bases de données déductives et orientées objet, Munich, Allemagne, décembre 2017. 1991.
S.Y.W. Su, M. Guo, H. Lam, « Algèbre d'association : fondement mathématique pour les bases de données orientées objet ». Transactions IEEE sur l'ingénierie des connaissances et des données, octobre. 1993.
S.B. Zdonik, D. Maier, éd., Lectures dans les systèmes de bases de données orientés objet, Morgan Kauffman, 1989.
S.B. Zdonik, P. Wegner, « Langage et méthodologie pour les environnements de bases de données orientés objet. » Hawaï Int. Conf. sur les sciences des systèmes, janvier. 1986.

Sikha Bagui([email protégé]) est maître de conférences au Département d'informatique de l'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-Relation 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 avec l'autorisation spéciale de l'éditeur original. Copyright JOT, 2003. Article original sur http://www.jot.fm/issues/issue_2003_07/column2.

De l'éditeur de traduction

OOBD - maturité ou déclin ?

Sergueï Kouznetsov

Il y a eu une accalmie frappante dans le domaine des 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 à l'émergence d'idées fausses, voire de mythes, chez des personnes proches de l'informatique, mais qui ne sont pas des spécialistes des bases de données. L'une de ces idées fausses est qu'une personne prend l'ensemble des termes qu'elle a en tête (objet, attribut, méthode, classe, héritage, etc.) pour un modèle de données orienté objet généralement accepté.

C'est ce qui explique notre décision de publier une traduction d'un article assez banal de Sikha Bagui. Une telle publication se justifie au moins dans la mesure où elle interrompt cette accalmie et montre, tout d'abord, que le domaine de l'OOBD non seulement n'est pas entré dans une époque de maturité, mais continue de rester un conglomérat d'idées hétérogènes et confuses qui s'unissent à la fois. le niveau des slogans plutôt 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 entre 1986 et 1995. Par conséquent, la caractéristique souvent utilisée de l’OODB « moderne » n’est pas tout à fait juste. Les citations, parfois données au présent, semblent parfois assez suspectes.

Bien entendu, les nombreuses sources ont utilisé une terminologie différente et, à cet égard, leur analyse est extrêmement variée. De plus, de nombreux articles sont assez complexes sur le plan technique et les citer sans fournir de contexte ne fait que rendre la compréhension plus difficile. 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 intuitives (bien qu'en réalité les auteurs de l'article original autorisent une option d'échantillonnage pas très évidente sous la forme d'une semi-jointure), mais les deux dernières - génèrent et map - sont des opérations difficiles à définir et non évidentes.

Je voudrais noter une autre caractéristique étrange de l'article de Bagui. Jusqu'en 2001, il existait un consortium international, l'Object Data Management Group, qui publiait trois versions de propositions visant à standardiser le 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 propose une terminologie relativement cohérente et, dans une certaine mesure, un modèle de données orienté objet. C'est dommage que Bagui n'utilise pas ce matériel.

A noter que le magazine DBMS a publié un article consacré à la première version du standard, ODMG-93. Un résumé de la norme ODMG 3.0 est disponible dans . Nous pouvons également vous recommander la traduction du Manifeste des systèmes de bases de données orientés objet et un très bel aperçu de la technologie OODB.