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 des objets 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.

Un exemple de la structure logique de la base de données OO de la bibliothéconomie est illustré à la Fig. 3.14. Ici, un objet de type LIBRARY est le parent par exemple des objets des classes SUBSCRIBER, DIRECTORY et OUTPUT. Différents objets de type LIVRE ayant le même parent doivent être différents, au moins dans le numéro d'inventaire (unique pour chaque exemplaire du livre), mais avoir les mêmes valeurs de propriété isbn, udk, nom et auteur.

Graphique 3.14. La structure logique de la base de données de la bibliothèque

La structure logique de la base de données OO est extérieurement similaire à la structure d'une base de données hiérarchique. La principale différence entre eux réside dans les méthodes de manipulation des données. Pour effectuer des actions sur les données d'une base de données MOO, des opérations logiques sont utilisées, renforcées par des mécanismes orientés objet d'encapsulation, d'héritage et de polymorphisme. Des opérations similaires aux commandes SQL peuvent être utilisées dans une mesure limitée (par exemple, pour créer une base de données).

La création et la modification de la base de données s'accompagnent de la formation automatique et de l'ajustement ultérieur d'index (tables d'index) contenant des informations pour une 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 OOM.

Encapsulation restreint la portée du 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 REPERTOIRE qui définit le numéro de téléphone de l'auteur du livre et porte le nom Téléphone, alors nous obtiendrons des 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 la portée de la propriété à tous les descendants de l'objet. Ainsi, tous les objets de type BOOK descendants d'un objet de type DIRECTORY peuvent se voir attribuer les propriétés de l'objet parent : isbn, udk, nom et auteur. S'il est nécessaire d'étendre l'effet du mécanisme d'héritage à des objets qui ne sont pas des parents immédiats (par exemple, entre deux descendants du même parent), alors une propriété abstraite de type abs est définie dans leur ancêtre commun. Ainsi, la définition des propriétés abstraites billet et pièce dans un objet LIBRARY, ces propriétés sont héritées par tous les objets enfants SUBSCRIBER, BOOK et REFERENCE. Ce n'est pas un hasard si les valeurs du bien billet des classes SUBSCRIBER et ISSUE montrées dans la figure seront les mêmes - 00015.

Polymorphisme dans les langages de programmation orientés objet, cela 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 possible d'avoir des méthodes (procédures ou fonctions) avec les mêmes noms dans des objets de types différents. Lors de l'exécution d'un programme objet, les mêmes méthodes opèrent sur des objets différents selon le type de l'argument. Appliqué à notre base de données OO, le polymorphisme signifie que les objets de la classe BOOK, ayant des parents différents de la classe DIRECTORY, peuvent avoir un ensemble de propriétés différent. Par conséquent, les programmes pour travailler avec des objets de la classe BOOK peuvent contenir du code polymorphe.

La recherche dans la base de données OO consiste à rechercher la similitude entre l'objet spécifié par l'utilisateur et les objets stockés dans la base de données. Un objet défini par l'utilisateur appelé objet objectif (la propriété de l'objet est de type objectif), dans le cas général, peut représenter 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 l'exécution de la requête, peuvent être stockés dans la base de données elle-même. La Fig. 3.15.

Le principal dignité Le MOO par rapport aux données relationnelles est la capacité d'afficher des informations sur les relations d'objets complexes. Les données du MOO permettent d'identifier un seul enregistrement de base de données et de définir les fonctions de leur traitement.

Désavantage Les MOO sont caractérisés par une complexité conceptuelle élevée, des inconvénients dans le traitement des données et une faible vitesse de requête.

Graphique 3.15. Fragment de la base de données avec l'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 la considérer en termes de base de données orientée objet. Il y a trois classes au total : " Clients», « Ordres" et " Des produits". Objets de la classe " Clients»Sont des clients spécifiques ; propriétés de classe - N° de client, Nom du client, Ville, Statut, etc. Méthodes de classe - " Créer une commande», « Payer sa commande" etc. Une méthode est une sorte d'opération qui peut être appliquée à un objet ; une méthode est ce qu'un objet doit faire. La classe correspondant au tableau " Détails de la commande", non requis. Les données de la table peuvent faire partie de la classe " Ordres". Présence dans la classe " Clients"Méthode" Créer une commande"Mène à l'interaction avec les objets des classes" Ordres" et " Des produits". Dans ce cas, l'utilisateur n'a pas besoin de connaître cette interaction d'objets. L'utilisateur se réfère uniquement à l'objet " Ordres"Et utilise la méthode" Créer une commande". L'impact sur les autres bases de données peut être masqué à l'utilisateur. Si la méthode " Créer une commande", À son tour, se réfère à la méthode" Vérifier la solvabilité du client”, Ce fait peut également être caché à l'utilisateur. Dans les bases de données relationnelles, l'exécution de la même fonctionnalité nécessite l'écriture de procédures en Visual Basic pour Application (VBA).

Dans les années 90, il y avait 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), et Iris, Orion et Postgres.

Base de données orientée objet(OODB) est 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 pour les cas où un traitement hautes performances de données avec une structure complexe est requis.

Le manifeste OODB propose les caractéristiques requises 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 obligatoires

1. Prise en charge d'objets complexes. Le système devrait prévoir la possibilité de créer des objets composés en utilisant les constructeurs d'objets composés. Les constructeurs d'objets doivent être orthogonaux, c'est-à-dire que n'importe quel constructeur peut être appliqué à n'importe quel objet.

2. Prise en charge de l'individualité des objets. Tous les objets doivent avoir un identifiant unique qui ne dépend pas des valeurs de leurs attributs.

3. Prise en charge de l'encapsulation. Une encapsulation correcte est obtenue du fait que les programmeurs ont le droit d'accéder uniquement à la spécification d'interface des méthodes, et 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. L'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 la compatibilité des opérations effectuées sur la variable avec son type, ce qui permet de garantir l'exactitude du logiciel. D'autre part, une classe est une sorte de 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 plus de un runtime plutôt 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 sous-classe, doit hériter des attributs et méthodes de son supertype, ou superclasse, respectivement.

6. Surcharge combinée à une reliure complète. Les méthodes doivent être appliquées à des objets de types différents. 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 des noms de méthode sur le système ne doit avoir lieu qu'au moment de 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èmes prédéfinis. De plus, il ne devrait y avoir aucune distinction entre la façon dont les types de données définis par le système et ceux définis par l'utilisateur sont utilisés.

SGBD OO

Bases de données orientées objet- les 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.

Appliquer ou ne pas appliquer les systèmes de gestion de base de données orientés objet (OODBMS) dans des projets réels aujourd'hui ? Dans quels cas faut-il les utiliser, et dans quels cas pas ?

Ici Avantages en utilisant OODBMS :

· Il n'y a pas de problème de discordance entre le modèle de données dans l'application et la base de données (impédance dismatch). 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 fortement typés. Plus de noms de colonnes de chaîne ! La refactorisation d'une base de données orientée objet et du code qui l'utilise est désormais automatisée, plutôt qu'un processus fastidieux et ennuyeux.

Norme ODMG

Premier manifeste formellement n'était qu'un article soumis à Conférence sur les bases de données orientées objet et déductives par un groupe d'individus. Comme vous pouvez le voir dans la sous-section précédente, les exigences du Manifeste étaient émotionnelles plutôt que explicitement spécifiées. En 1991, le consortium ODMG a été formé (puis cette abréviation a été divulguée comme Groupe de gestion de la 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 des objets), qui a été formé deux ans plus tôt. L'objectif initial principal d'ODMG était de développer la norme de l'industrie pour les bases de données orientées objet (modèle commun). Le modèle objet de base OMG COM ( Modèle d'objet de base). Au cours de plus d'une décennie, ODMG a publié trois versions de base de la norme, dont la dernière s'appelle ODMG 3.0. seize

Ironiquement, bien que l'ODMG soit (de l'avis de l'auteur) hors de l'OMG, ces dernières années, certaines normes de l'OMG se sont appuyées sur le modèle objet ODMG. En particulier, la spécification du langage OCL ( Langage de contrainte d'objet), qui fait partie de la spécification générale du langage UML 1.4 (et UML 2.0). Dans cet article, nous n'avons pas l'intention de procéder à une comparaison détaillée des approches OMG et ODMG et de renvoyer les lecteurs intéressés à Encyclopédies de Kogalovsky et des documents provenant des sites Web de ces consortiums. Nous nous limiterons à un bref résumé des idées principales contenues dans la norme ODMG-3.

Architecture ODMG

L'architecture ODMG proposée est illustrée à la Fig. 2.1. Cette architecture définit un mode de stockage des données et différents types d'accès des utilisateurs à ce « data store » 17. Un seul magasin de données 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 Dans 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 sont stockées toutes les données gérées par l'OODBMS. Le langage de définition d'objet, le langage de requête et les langages de manipulation sont conçus de manière à ce 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 le stockage des données modélisées, mais une exigence importante est que toutes les bibliothèques logicielles et tous les outils de support soient fournis dans un cadre orienté objet et doivent être stockés en cohérence 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 OODBMS 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 de langage ODL, dans lequel les constructions de modèles de données sont instanciées sous la forme d'un langage de définition. ODL vous permet de décrire un schéma comme un ensemble d'interfaces de type objet, qui inclut la description des propriétés de type et des relations entre elles, ainsi que les noms des opérations et leurs paramètres. ODL n'est pas un langage de programmation complet ; les types doivent être implémentés dans l'un des langages de la catégorie OML. De plus, l'ODL est virtuel langage dans le sens où la norme ODMG n'exige pas sa mise en œuvre dans les produits logiciels OODBMS qui sont considérés comme conformes à la norme. Il est permis à ces produits de prendre en charge des langages de définition équivalents qui incluent toutes les capacités d'ODL, mais adaptés aux spécificités d'un système spécifique. Cependant, la présence de la spécification du langage ODL dans la norme ODMG est importante car le langage spécifie les propriétés du modèle de données.

• Langage de requête d'objet (ODL). Le langage a une syntaxe similaire à celle de SQL, mais repose 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èle de gestion de base de données (relationnelle). Nom relationnel est lié au fait que chaque enregistrement dans une telle base de données contient des informations relatives à un seul objet spécifique.

V relationnel Toutes les données traitées dans le SGBD 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 : divers attributs d'objets sont concentrés dans les colonnes du tableau 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 infologique répond au maximum aux principes de la relativité. Cependant, pour convertir ce modèle en modèle relationnel, vous devez 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 suivant doit répondre aux exigences des conditions précédentes et de 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. Au cours de la phase de conception infologique, nous avons parlé de l'abstraction des objets et leur avons attribué certaines propriétés. Maintenant, avec la conception conceptuelle, nous passons au prochain niveau d'abstraction. A ce stade, les objets, en tant que tels, n'existent plus. Nous fonctionnons avec un ensemble de propriétés qui définissent l'objet.

Instance de relation- un ensemble de valeurs des propriétés d'un objet particulier.

Clé primaire- un ensemble d'attributs identifiant, c'est-à-dire la valeur de ces attributs est unique à cet égard. Il n'y a pas deux instances d'une relation contenant la même valeur 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'entité ..

Domaine

Le domaine est plus spécifique aux bases de données, bien qu'il présente des 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 cette expression booléenne est vraie, alors l'élément de données est un élément de domaine.

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

Il faut également noter la charge sémantique du concept 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 des domaines "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 supporte déjà.

Les technologies de base de données basées sur les DM ci-dessus sont basées sur un concept statique de stockage d'informations, axé sur la modélisation des données. Cependant, de nouveaux domaines d'application technologique avec des objets de base de données complexes et interconnectés, tels que :

Conception assistée par ordinateur;

Production automatisée ;

Développement de logiciels automatisés ;

Systèmes d'information de bureau ;

Systèmes multimédias;

Systèmes d'information géographique;

Les systèmes de publication et autres - ont démontré les capacités limitées du concept statique en termes de modélisation d'objets dans le monde réel.

Pour les nouveaux types d'applications complexes de bases de données spécialisées, un concept dynamique de stockage d'informations est efficace, ce qui permet de simuler des données et des processus agissant sur ces données en parallèle. Cela permet de prendre en compte la sémantique du domaine et donc de décrire au mieux ces applications. Ce concept est basé sur l'approche orientée objet largement utilisée dans le développement de logiciels. Le MD, qui met en œuvre ce concept et est basé sur le paradigme orienté objet (OOP), est appelé modèle de données orienté objet (OOMD).

La construction de l'OOMD part de l'hypothèse que le domaine peut être décrit par un ensemble d'objets. Chaque objet est une entité identifiable de manière unique qui contient des attributs qui décrivent l'état des objets du "monde réel" et leurs actions associées. L'état actuel d'un objet est décrit par un ou plusieurs attributs, qui peuvent être simples ou complexes. Un attribut simple peut être de type primitif (par exemple, entier, chaîne, etc.) et prendre une valeur littérale. Un attribut composite peut contenir des collections et/ou des liens. Un attribut de référence représente une relation entre des objets.

La propriété clé d'un objet est l'unicité de son identification. Par conséquent, chaque objet dans un système orienté objet doit avoir son propre identifiant.

Un identificateur d'objet (OID) est un moyen interne à la base de données de marquer des objets individuels. En règle générale, les utilisateurs qui travaillent avec le programme de dialogue pour définir des requêtes ou afficher des informations ne voient pas ces identificateurs. Ils sont attribués et utilisés par le SGBD lui-même. La sémantique de l'identifiant dans chaque SGBD est différente. Il peut s'agir d'une valeur aléatoire ou contenir des informations nécessaires pour trouver un objet dans le fichier de base de données, par exemple, le numéro de page dans le fichier et le décalage de l'objet depuis son début. C'est l'identifiant qui doit être utilisé pour organiser les références à l'objet.

Tous les objets sont encapsulés, c'est-à-dire que la représentation ou la structure interne de l'objet reste cachée à l'utilisateur. Au lieu de cela, l'utilisateur sait seulement que cet objet peut exécuter certaines fonctions. Par exemple, pour l'objet WAREHOUSE, on peut utiliser des méthodes telles que ACCEPT_PRODUCT, EXIT_TOBAP... L'avantage de l'encapsulation est qu'elle permet de changer la représentation interne des objets sans retravailler les applications qui utilisent ces objets. En d'autres termes, l'encapsulation implique l'indépendance des données.

Un objet encapsule des données et des fonctions (des méthodes, selon la POO). Les méthodes définissent le comportement d'un objet. Ils peuvent être utilisés pour changer l'état d'un objet en modifiant les valeurs de ses attributs, ou pour interroger les valeurs d'attributs sélectionnés. Par exemple, il peut exister des méthodes pour ajouter des informations sur une nouvelle propriété locative, mettre à jour les informations sur le salaire d'un employé ou imprimer des informations sur un élément spécifique.

Les objets qui ont le même ensemble d'attributs et répondent aux mêmes messages peuvent être regroupés en Classer(dans la littérature, les termes « classe » et « type » sont souvent utilisés de manière interchangeable). Chacune de ces classes a son propre représentant - un objet, qui est un élément de données. Les objets d'une certaine classe sont appelés copies.

Dans certains systèmes orientés objet, une classe est également un objet et possède ses propres attributs et méthodes appelés attributs de classe et méthodes de classe.

Les concepts importants de la POO sont hiérarchie de classes et hiérarchie de conteneurs.

Hiérarchie de classe implique la possibilité que chaque classe, appelée dans ce cas une superclasse, ait sa propre sous-classe. A titre d'exemple, la chaîne suivante peut être donnée : tous les programmeurs d'une entreprise sont ses employés, par conséquent, chaque programmeur qui est un objet de la classe PROGRAMMERS au sein de l'OOMD est également un employé qui, à son tour, est un objet des EMPLOYÉS. classer. Ainsi, les PROGRAMMEURS seront une sous-classe, les EMPLOYÉS seront une super-classe. Mais les programmeurs peuvent également être divisés en système et application. Par conséquent, PROGRAMMERS sera la super-classe des sous-classes SIS_PROGRAMMERS et APPLICATION_PROGRAMMERS. En poursuivant cette chaîne plus loin, nous obtenons une hiérarchie de classes dans laquelle chaque objet de la sous-classe hérite des instances de variables et de méthodes de la superclasse correspondante.

Il existe plusieurs types d'héritage - unique, multiple et sélectif. L'héritage simple est un cas où les sous-classes héritent d'au plus une superclasse. Héritage multiple - héritage de plusieurs superclasses. L'héritage sélectif permet à une sous-classe d'hériter d'un nombre limité de propriétés de sa superclasse.

L'héritage d'instance de variable est appelé héritage structurel, héritage de méthode - héritage comportemental, et la possibilité d'utiliser la même méthode pour différentes classes, ou plutôt d'appliquer différentes méthodes avec le même nom pour différentes classes est appelée polymorphisme.

L'architecture orientée objet a également un autre type de hiérarchie - hiérarchie des conteneurs... Elle consiste dans le fait que certains objets peuvent conceptuellement être contenus dans d'autres. Ainsi, un objet de la classe DEPARTMENT doit contenir la variable publique HEAD, qui est un lien vers l'objet de la classe EMPLOYEES correspondant au chef de service, et doit également contenir un lien vers un ensemble de références à des objets correspondant au employés travaillant dans ce service.

Dans certains systèmes orientés objet, une classe est également un objet et possède ses propres attributs et méthodes. Les caractéristiques générales d'une classe sont décrites par ses attributs. Les méthodes de classe d'objets sont en quelque sorte analogues aux propriétés des objets dans le monde réel. Chaque objet appartenant à une classe particulière possède ces propriétés. Par conséquent, lors de la création d'un objet, vous devez déclarer la classe à laquelle il appartient afin de définir ainsi ses propriétés inhérentes.

L'utilisateur et l'objet interagissent à travers des messages. En réponse à chaque message, le système exécute la méthode appropriée.

Tous les liens dans le modèle objet sont créés à l'aide d'attributs de référence, qui sont généralement implémentés sous forme d'OID.

Les relations dans une base de données relationnelle sont représentées par un mappage de clés primaires et étrangères. Dans la base elle-même, il n'y a pas de structures pour la formation d'associations entre les tables, des liens sont utilisés au besoin lors de la jointure des tables. En revanche, les relations forment l'épine dorsale d'une base de données orientée objet, puisque chaque objet comprend les identifiants des objets auxquels il est associé.

Dans OOMD, non seulement des liens traditionnels peuvent être implémentés, mais aussi des liens conditionnés par l'héritage.

Communication en tête-à-tête (1 : 1) entre les objets A et B est mis en œuvre en ajoutant un attribut de référence à l'objet B à l'objet A et (pour maintenir l'intégrité référentielle) un attribut de référence à l'objet A à l'objet B.

Relation un-à-plusieurs (1 : M) entre les objets A et B est implémenté en ajoutant à l'objet A un attribut de référence à l'objet B et un attribut contenant un ensemble de références à l'objet A à l'objet B (par exemple, un attribut de référence B (OID2, OID3 ...) est ajouté à l'objet A, et aux instances d'objet B avec OID2, OID3, ... un attribut de référence A : OID1 est ajouté.

Relation plusieurs-à-plusieurs (M:N) entre les objets A et B est implémentée en ajoutant à chaque objet un attribut contenant un ensemble de liens.

Dans OOMD, vous pouvez utiliser une relation tout-à-partie, qui décrit qu'un objet d'une classe contient des objets d'autres classes comme ses parties. Dans le cas d'une base de données de production, il y aurait une relation de tout à partie entre la classe PRODUCT et les classes PART et ASSEMBLY. Cette relation est une variante d'une relation plusieurs-à-plusieurs avec une sémantique spéciale. Une relation tout-à-partie est implémentée comme toute autre relation plusieurs-à-plusieurs, en utilisant un ensemble d'identificateurs d'objets liés. Cependant, contrairement à la relation plusieurs-à-plusieurs habituelle, elle a une signification sémantique différente.

Étant donné que le paradigme orienté objet prend en charge l'héritage, dans OOMD, il est possible d'utiliser la relation de type "est" et la relation de type "étend". La relation is, également appelée relation de généralisation-spécialisation, génère une hiérarchie d'héritage dans laquelle les sous-classes sont des cas particuliers de superclasses. Cela évite de décrire des caractéristiques réhéritées. Lors de l'utilisation de la relation "s'étend", la sous-classe développe la fonctionnalité de la superclasse plutôt que d'être limitée à son cas particulier.

Considérez comment les composants tels que les contraintes d'intégrité et les opérations sur les données sont implémentés dans OOMD.

Les caractéristiques de ces composants sont déterminées par les spécificités du modèle. Cette spécificité dans OOMD est dictée principalement par ses concepts internes tels que l'encapsulation d'objets, c'est-à-dire le secret de la structure interne, l'accès aux données uniquement via des méthodes prédéfinies, la hiérarchie des classes et la hiérarchie des conteneurs.

La spécificité de l'OOMD est également dictée par la spécificité de l'objet. Elle se manifeste par la nécessité de regrouper les objets en classes. Chaque objet est inclus dans l'une ou l'autre classe selon la tâche, et un objet peut appartenir à plusieurs classes à la fois (par exemple, les familles PROGRAMMEUR et HAUTEMENT PAYÉ). Une autre spécificité d'un objet est qu'il peut « déborder » d'une classe (sous-classe) à une autre. Ainsi, un PROGRAMMATEUR DE SYSTÈME peut s'APPLIQUER au fil du temps. Ainsi, la hiérarchie des classes n'est pas analogue au modèle hiérarchique, comme cela peut paraître plus tôt, mais nécessite que le système soit capable de changer l'emplacement de chaque objet dans la hiérarchie des classes, par exemple, se déplacer " vers le haut " ou " vers le bas " dans cette hiérarchie. Mais un processus plus complexe est également possible - le système doit garantir la capacité d'un objet à être attaché (détaché) à un sommet arbitraire de la hiérarchie à tout moment.

Les contraintes d'intégrité jouent un rôle important dans OOMD. Pour que les liens d'un MD orienté objet fonctionnent, les identificateurs d'objet des deux côtés du lien doivent correspondre. Par exemple, s'il existe une relation entre des EMPLOYÉS et leurs ENFANTS, alors il doit y avoir une certaine assurance que lorsqu'un objet décrivant un enfant est inséré dans un objet représentant un employé, l'identifiant de ce dernier est ajouté à l'objet correspondant. Ce type d'intégrité de lien, quelque peu analogue à l'intégrité référentielle dans un modèle de données relationnel, est établi à l'aide de rétroactions. Pour assurer l'intégrité des liens, le concepteur dispose d'une syntaxe spéciale requise pour spécifier l'emplacement de l'identificateur d'objet inverse. La responsabilité de fixer des contraintes sur l'intégrité des liens (ainsi que l'intégrité référentielle dans une base de données relationnelle) incombe au concepteur.

Dans OOMD, la description des données et leur manipulation se produisent à l'aide du même langage procédural orienté objet.

Le groupe ODMG (Object Database Management Groop) traite des problèmes de standardisation de la technologie des bases de données objet. Elle a développé un modèle objet (ODMG version 2.0 a été adopté en septembre 1997) qui définit un modèle standard pour la sémantique des objets de base de données. Ce modèle est important car il définit une sémantique intégrée qu'un SGBD orienté objet (OODBMS) comprend et peut implémenter. La structure des bibliothèques et des applications utilisant cette sémantique doit être portable parmi les différents OODBMS qui prennent en charge un objet donné MD. Les principaux composants de l'architecture ODMG sont le modèle d'objet (OM), le langage de définition d'objet (ODL), le langage de requête d'objet (OQL) et la possibilité de se lier à C ++, Java et Smalltalk.

Le modèle de données objet selon la norme ODMG 2.0 se caractérise par les propriétés suivantes :

Les blocs de construction de base sont les objets et les littéraux. Chaque objet a un identifiant unique. Un littéral n'a pas d'identifiant propre et ne peut pas exister séparément en tant qu'objet. Les littéraux sont toujours intégrés dans des objets et ne peuvent pas être référencés individuellement ;

Les objets et les littéraux diffèrent par leur type. Chaque type a son propre domaine, partagé par tous les objets et littéraux de ce type. Les types peuvent aussi avoir des comportements. Si un type a un certain comportement, alors tous les objets de ce type ont le même comportement. En pratique, un type peut être la classe à partir de laquelle l'objet est créé, une interface ou un simple type de données (comme un entier). Un objet peut être considéré comme une instance d'un type ;

L'état d'un objet est déterminé par un ensemble de valeurs courantes implémentées par un ensemble de propriétés. Ces propriétés peuvent être des attributs d'un objet ou une relation entre un objet et un ou plusieurs autres objets ;

Le comportement d'un objet est déterminé par un ensemble d'opérations qui peuvent être effectuées sur un objet ou sur l'objet lui-même. Les opérations peuvent avoir une liste de paramètres d'entrée et de sortie, dont chacun est d'un type strictement défini. Chaque opération peut également retourner un résultat typé ;

Une définition de base de données est stockée dans un schéma écrit en langage de définition d'objet (ODL). La base de données stocke les objets afin qu'ils puissent être partagés par différents utilisateurs et applications.

Les SGBD basés sur OOMD sont appelés SGBD orientés objet (OODBMS). Ces SGBD sont appelés SGBD de troisième génération * (* L'histoire du développement des modèles de stockage de données est souvent divisée en trois étapes (générations) : la première génération (fin des années 1960 - début des années 70) - les modèles hiérarchiques et en réseau ; la deuxième génération (environ 1970-1980) - les modèle relationnel ; la troisième génération (années 1980 - début des années 2000) - Modèles Orientés Objet.).

Aujourd'hui, les bases de données orientées objet sont utilisées dans diverses organisations pour résoudre un large éventail de tâches. L'analyse et la généralisation de l'expérience accumulée dans le domaine des données informatiques ont permis d'identifier des applications dans lesquelles l'utilisation de bases de données orientées objet est justifiée :

L'application se compose d'un grand nombre de parties en interaction. Chacun d'eux a son propre comportement, qui dépend du comportement des autres ;

Le système doit gérer de grandes quantités de données non structurées ou complexes ;

L'application fournira un accès prévisible aux données, de sorte que la nature de navigation des bases de données orientées objet ne sera pas un inconvénient majeur ;

Le besoin de demandes ad hoc est limité ;

La structure des données stockées est hiérarchique ou de nature similaire.

Actuellement, il existe de nombreux SGBD orientés objet sur le marché des logiciels. Tableau 10.6 présente quelques-uns des systèmes commerciaux de cette classe.

Tableau 10.6

OODBMS commercial moderne,

leurs entreprises de fabrication et leurs domaines d'application

L'une des différences fondamentales entre les bases de données objet et les bases de données relationnelles est la possibilité de créer et d'utiliser de nouveaux types de données. Une caractéristique importante d'OODBMS est que la création d'un nouveau type ne nécessite pas de modification du noyau de base et est basée sur les principes de la programmation orientée objet.

Le cœur de l'OODBMS est optimisé pour la manipulation d'objets. Les opérations naturelles pour cela sont la mise en cache des objets, la gestion des versions d'objets, la séparation des droits d'accès à des objets spécifiques. Les OODBMS se caractérisent par des performances plus élevées sur les opérations nécessitant l'accès et la récupération de données compressées dans des objets, par rapport aux SGBD relationnels, pour lesquels la nécessité de récupérer des données connectées entraîne des opérations internes supplémentaires.

La capacité de déplacer des objets d'une base de données à une autre est d'une grande importance pour OODBMS.

Lors de la création de diverses applications basées sur OODBMS, la structure intégrée des classes d'un SGBD particulier est importante. La bibliothèque de classes prend en charge, en règle générale, non seulement tous les types de données standard, mais également un ensemble étendu de types de données multimédias et d'autres types de données complexes, tels que la vidéo, le son, la séquence d'images d'animation. Certaines bibliothèques de classes OODBMS ont été créées pour permettre le stockage et la recherche en texte intégral d'informations documentaires (par exemple, Jasmine, ODB-Jupiter). Un exemple de structure de classe de base est illustré à la Fig. 10.17.

La position principale est occupée par la classe TOdbObject, qui contient toutes les propriétés et méthodes nécessaires pour contrôler l'accès à la base de données et effectuer l'indexation. Toutes les autres classes remplacent ses méthodes en ajoutant un contrôle de validation pour le type qu'elles implémentent et un indexeur spécifique.

Comme on le voit sur la Fig. 10.17, il existe différentes classes dans la structure axées sur le traitement de l'information documentaire - TOdbText, TOdbDocument, TODBTextDocument, etc. Chaque document est représenté par un objet distinct. Ainsi, le stockage naturel des documents est assuré. L'une des opérations les plus importantes est la recherche de documents sur demande. Pour la plupart des classes, la possibilité de rechercher des objets par la valeur d'une clé spécifique est implémentée. Pour la classe TOdbText, la possibilité de former une requête de recherche pour une phrase écrite en langage naturel est implémentée.

La classe TOdbDocument est spéciale, capable de contenir des objets de différents types. Il se compose de champs dont chacun a un nom et est associé à un objet d'un certain type. La présence de cette classe permet à l'utilisateur d'étendre l'ensemble des types. En modifiant l'objet conteneur (document), vous pouvez définir un certain ensemble de champs et ainsi obtenir un nouveau type de document.

Sur la base d'ODB-Jupiter, les développeurs OODBMS ont créé un système de recherche d'informations complet ODB-Text, qui possède une structure universelle de données stockées et un moteur de recherche puissant. Le système ODB-Text est un outil de traitement collectif de documents et de gestion d'archives d'entreprise. Parmi les applications possibles, on citera l'automatisation de la gestion documentaire dans un bureau moderne, la construction de systèmes d'information de référence (similaires aux bases de données juridiques bien connues), la maintenance de bases de données en réseau, les dossiers du personnel, la bibliographie, etc.

41. Caractéristiques de la conception du SI appliqué. Phases de développement de la propriété intellectuelle. (Sujet 11, pp. 100-103).

11.1.3. Caractéristiques de la conception de systèmes IC appliqués

Lors de la construction (choix, adaptation) d'un système d'information, vous pouvez utiliser deux concepts principaux, deux approches principales (le troisième concept en est une combinaison) :

1. orientation vers les problèmes qui doivent être résolus à l'aide de ce système d'information, c'est-à-dire approche orientée problème (ou approche inductive) ;

2. orientation vers une technologie disponible (mise à jour) dans un système, un environnement donné, c'est-à-dire approche technologique (ou approche déductive).

Le choix du concept dépend de critères stratégiques (tactiques) et (ou) de long terme (court terme), de problèmes, de ressources.

Si d'abord les possibilités de la technologie disponible sont étudiées, puis les problèmes réels qui peuvent être résolus avec leur aide sont déterminés, alors il est nécessaire de s'appuyer sur une approche orientée vers la technologie.

Si, d'abord, des problèmes réels sont identifiés, puis une technologie est introduite qui est suffisante pour résoudre ces problèmes, alors il est nécessaire de s'appuyer sur une approche axée sur les problèmes.

En même temps, les deux concepts de construction d'un système d'information dépendent l'un de l'autre : l'introduction de nouvelles technologies modifie les problèmes à résoudre, et l'évolution des problèmes à résoudre conduit à la nécessité d'introduire de nouvelles technologies ; les deux affectent les décisions prises.

La conception (développement) du système et l'utilisation de tout système d'information appliqué (d'entreprise) doivent passer par le cycle de vie suivant du système d'information :

- analyse de pré-conception (expérience dans la création d'autres systèmes similaires, prototypes, différences et caractéristiques du système en cours de développement, etc.), analyse des manifestations externes du système ;

- analyse intra-système, analyse interne (analyse des sous-systèmes du système) ;

- description systémique (morphologique) (présentation) du système (description de l'objectif systémique, des relations du système et des connexions avec l'environnement, les autres systèmes et les ressources du système - matérielles, énergétiques, informationnelles, organisationnelles, humaines, spatiales et temporelles);

- détermination des critères d'adéquation, d'efficacité et de stabilité (fiabilité) ;

- description fonctionnelle des sous-systèmes du système (description des modèles, algorithmes de fonctionnement des sous-systèmes) ;

- le prototypage (description de la configuration) du système, l'évaluation de l'interaction des sous-systèmes du système (développement d'une configuration - la mise en œuvre de sous-systèmes avec des descriptions fonctionnelles simplifiées, des procédures et l'approbation de l'interaction de ces configurations afin de satisfaire le système but), alors qu'il est possible d'utiliser des "dispositions" de critères d'adéquation, de stabilité, d'efficacité ;

- "assemblage" et test du système - la mise en œuvre de sous-systèmes et de critères fonctionnels à part entière, l'évaluation du modèle selon les critères formulés ;

- le fonctionnement du système ;

- détermination d'objectifs pour le développement ultérieur du système et de ses applications ;

- maintenance du système - clarification, modification, extension des capacités du système dans son mode de fonctionnement (en vue de son évolution).

Ces étapes sont fondamentales pour la réingénierie des systèmes d'information.

En règle générale, le développement d'un système d'information d'entreprise est réalisé pour une entreprise très spécifique. Les spécificités de l'activité objet de l'entreprise influenceront sans aucun doute la structure du système d'information. Mais en même temps, les structures des différentes entreprises sont généralement similaires les unes aux autres. Chaque organisation, quel que soit son type d'activité, se compose d'un certain nombre de divisions qui exercent directement l'un ou l'autre type d'activité de l'entreprise. Et cette situation est vraie pour presque toutes les organisations, quel que soit le type d'activité dans laquelle elles sont engagées.

Ainsi, toute organisation peut être considérée comme un ensemble d'éléments en interaction (divisions), dont chacun peut avoir sa propre structure assez complexe. Les relations entre les départements sont également assez complexes. En général, il existe trois types de liens entre les divisions de l'entreprise :

Connexions fonctionnelles - chaque service effectue certains types de travail au sein d'un seul processus métier ;

Communications d'information - les services échangent des informations (documents, télécopies, commandes écrites et orales, etc.);

Relations externes - certaines unités interagissent avec des systèmes externes, et leur interaction peut également être à la fois informationnelle et fonctionnelle.

La généralité de la structure des différentes entreprises nous permet de formuler quelques principes communs de construction des systèmes d'information d'entreprise.

De manière générale, le processus d'élaboration d'un système d'information peut être envisagé sous deux angles :

Par temps, ou par étapes du cycle de vie du système en cours de développement. Dans ce cas, l'organisation dynamique du processus de développement est considérée, décrite en termes de cycles, d'étapes, d'itérations et d'étapes.

Un système d'information d'entreprise est développé comme une sorte de projet. De nombreuses caractéristiques des phases de gestion de projet et de développement de projet (phases du cycle de vie) sont générales, non seulement en fonction du domaine, mais aussi de la nature du projet (peu importe qu'il s'agisse d'un projet d'ingénierie ou économique) . Par conséquent, il est logique de considérer d'abord un certain nombre de problèmes généraux de gestion de projet.

Un projet est un changement ciblé et limité dans le temps d'un système séparé avec des objectifs initialement clairement définis, dont la réalisation détermine l'achèvement du projet, ainsi que des exigences établies pour les délais, les résultats, les risques, la portée des dépenses de fonds et ressources et pour la structure organisationnelle.

Habituellement, pour un concept complexe (qui, en particulier, est le concept d'un projet), il est difficile de donner une formulation univoque qui couvre entièrement toutes les caractéristiques du concept introduit. Par conséquent, la définition donnée ne prétend pas être unique et complète.

Les principales caractéristiques distinctives suivantes du projet en tant qu'objet de gestion peuvent être distinguées :

La variabilité est un transfert délibéré d'un système d'un système existant à un certain

l'état souhaité, décrit en fonction des objectifs du projet ;

La limitation du but ultime;

Durée limitée ;

Budget limité;

Ressources limitées requises ;

Nouveauté pour l'entreprise pour laquelle le projet est mis en œuvre ;

Complexité - la présence d'un grand nombre de facteurs qui affectent directement ou indirectement l'avancement et les résultats du projet ;

Accompagnement juridique et organisationnel - création d'une structure organisationnelle spécifique pour la durée du projet.

L'efficacité du travail est obtenue en gérant le processus de mise en œuvre du projet, qui assure l'allocation des ressources, la coordination de la séquence de travail et la compensation des influences perturbatrices internes et externes.

Du point de vue de la théorie des systèmes de contrôle, le projet en tant qu'objet de contrôle doit être observable et contrôlable, c'est-à-dire qu'on distingue certaines caractéristiques par lesquelles il est possible de surveiller en permanence l'avancement du projet (la propriété d'observabilité) . De plus, des mécanismes d'influence opportune sur le déroulement de la mise en œuvre du projet sont nécessaires (propriété de contrôlabilité).

La propriété de contrôlabilité est particulièrement importante dans des conditions d'incertitude et de variabilité du domaine, qui accompagnent souvent les projets de développement de systèmes d'information.

Chaque projet, quelles que soient la complexité et la quantité de travail nécessaire à sa mise en œuvre, passe par certains états dans son développement : d'un état où « le projet n'est pas encore » à un état où « le projet n'est plus là ». L'ensemble des étapes de développement depuis l'émergence d'une idée jusqu'à l'achèvement complet du projet est généralement divisé en phases (étapes, étapes).

Il existe quelques différences dans la détermination du nombre de phases et de leur contenu, car ces caractéristiques dépendent largement des conditions de mise en œuvre d'un projet particulier et de l'expérience des principaux participants. Néanmoins, la logique et le contenu principal du processus de développement du système d'information sont dans presque tous les cas les mêmes.

On distingue les phases de développement du système d'information suivantes :

Élaboration de concepts ;

Élaboration des spécifications techniques ;

Conception;

Fabrication;

Mise en service du système.

Examinons chacun d'eux plus en détail. La deuxième et partiellement la troisième phases sont généralement appelées phases de conception des systèmes, et les deux dernières (parfois cela inclut la phase de conception) - les phases de mise en œuvre.

Phase conceptuelle

Formation d'idées, établissement d'objectifs ;

Formation d'une équipe de projet clé;

Étudier la motivation et les exigences du client et des autres participants ;

Collecte de données de base et analyse de l'état existant ;

Détermination des exigences et restrictions de base, des ressources matérielles, financières et de main-d'œuvre requises ;

Évaluation comparative des alternatives ;

Remise des propositions, leur examen et approbation.

Elaboration d'une proposition technique

Développement du contenu principal du projet, la structure de base du projet ;

Élaboration et approbation des spécifications techniques ;

Planification, décomposition du modèle structurel de base du projet ;

Estimer et budgétiser le projet, déterminer les besoins en ressources ;

Élaboration d'horaires et d'horaires de travail élargis;

Signature d'un contrat avec un client ;

Mise en service des moyens de communication des acteurs du projet et contrôle de l'avancement des travaux.

Conception

Dans cette phase, les sous-systèmes, leurs interrelations sont déterminés et les moyens les plus efficaces d'exécution de projet et d'utilisation des ressources sont sélectionnés. Travaux typiques de cette phase :

Travail de conception de base ;

Elaboration de spécifications techniques privées ;

Design conceptuel;

Rédaction des spécifications et instructions techniques ;

Soumission de conception, expertise et approbation.

Développement de

À cette phase, la coordination et le contrôle opérationnel des travaux du projet sont effectués, les sous-systèmes sont fabriqués, combinés et testés. Contenu principal:

Mise en œuvre des travaux de développement de logiciels ;

Préparer la mise en œuvre du système ;

Contrôle et régulation des principaux indicateurs du projet.

Mise en service du système

Au cours de cette phase, des tests sont effectués, un essai de fonctionnement du système en conditions réelles, des négociations sont en cours sur les résultats du projet et sur d'éventuels nouveaux contrats. Principaux types de travaux :

Tests complexes ;

42. Le concept du cycle de vie de la propriété intellectuelle. (Sujet 11, pp. 103-105).

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 de la famille de bases de données chronologiques 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. L'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 un ensemble d'objets (conteneurs de données) de type arbitraire.

Lors de la création de 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 dans l'OOMD a un identifiant unique (OID - object identifier). La récupération d'OID est nettement plus rapide 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 le fonctionnement 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 des objets 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 à l'aide de 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 ont estimé 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 de modèle de données au paradigme orienté 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 les 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 « est dans 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 combien 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 qui n'utilisent qu'un seul concept (soit un type, soit une classe), ce concept est inévitablement surchargé : un type pré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éterminer 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 joue pour les schémas de bases de données relationnelles.

Il existe de nombreuses autres publications liées au thème 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 le biais de 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 de constructeurs set, tuple et list. Les membres de valeur structurelle sont accessibles à l'aide d'opérations prédéfinies (primitives).

Les données peuvent être organisées de deux manières : 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 associé à 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 avec 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 des 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, de manière générale, différents objets peuvent se trouver à différents moments. 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.