Discussion :

[tournad]

Bonjour;
J'ai une recherche sur les Bases de données navigationnelles.J'ai cherché des cours ou des tutoriels sur ce sujet mais j'ai rien trouvé.Est ce que quelqun peut m'aider.
Merci d'avance.

[fsmrel]

Qu'entendez-vous par base de données navigationnelle ?

Supposons qu'il s'agisse de systèmes pré-relationnels.

Pour les bases de données hiérarchiques, vous avez par exemple IMS/DL1 (IBM).

Pour les bases de données Codasyl (réseau) vous avez IDMS/R (Computer Associates).

Vous avez encore Datacom DB (Computer Associates), Total (Cincom), Adabas (Software AG), etc.

Bonne chasse sur le Nète.

[Luc Orient]

... Pour les bases de données Codasyl (réseau) vous avez IDMS/R (Computer Associates).

N'oublions pas les produits issus de la société Bull qui a été longtemps un éditeur majeur des SGBD Codasyl avec IDS II sur les systèmes d'exploitation GCOS7 et GCOS8.

Par exemple :
Cours IDS II sur GCOS8

De la même manière que Edgar F Codd est considéré comme le "père" du modéle relationnel, Charles Bachman l'est également pour les SGBD Codasyl ou BD navigationnelles.
Charles Bachman

C'est d'ailleurs lui qui a introduit le terme "navigationnel" en parlant du programmeur comme un navigateur.
Navigational database

[fsmrel]

N'oublions pas les produits issus de la société Bull qui a été longtemps un éditeur majeur des SGBD Codasyl avec IDS II sur les systèmes d'exploitation GCOS7 et GCOS8

Tout à fait exact. J’ai aussi oublié de citer Socrate (CII, ECA, IMAG), FORTE (Burroughs) et bien d’autres.

De la même manière que Edgar F Codd est considéré comme le "père" du modéle relationnel, Charles Bachman l'est également pour les SGBD Codasyl ou BD navigationnelles.

Absolument. Juste une petite précision : Ted Codd n’est pas à "considérer" comme le père du Modèle relationnel, puisqu’en réalité il en est l’inventeur, le seul, l’unique.

Chris Date a publié un article à lire à tout prix, relatif au grand débat entre nos deux géants, qui s’est tenu du 1 au 3 mai à Ann Arbor (Michigan). L’objet était de confronter le Modèle relationnel et le modèle réseau. Un exercice intellectuel magnifique de la part de Ted.

http://www.intelligententerprise.com.../online2.jhtml

Je mets les images manquantes en pièces jointes.

[GyLes]

Hello,

Les SGBDOs intègrent aussi la partie navigationnel grâce à l'utilisation des OIDs permettant une navigation d'objets en objets.

[fsmrel]

Bonjour,

"Les SGBDOs intègrent aussi la partie navigationnel grâce à l'utilisation des OIDs permettant une navigation d'objets en objets"

Effectivement, les OID permettent d'effectuer un parcours navigationnel selon un style de programmation "pointer-chasing" (suivi des pointeurs ou course aux pointeurs), ce qui nous ramène sur ce point à l'époque héroïque des SGBD pré-relationnels. Pour avoir utilisé ceux-ci pendant près de 20 ans, j’en connais bien les limites, et leur caractéristique navigationnelle ne milite pas en leur faveur, bien au contraire. La navigation relève du COMMENT (et nous contraint par les fonctionnalités physiques que cela implique) alors que le modèle relationnel (orienté accès par valeurs, indépendamment de toute contrainte physique) nous en affranchit et nous élève au niveau du QUOI.


Pour illustrer l’emploi du QUOI, supposons que nous ayons les tables suivantes (clés primaires soulignées) :

Produit (Produit#, Produit_Nom, Site#, ...) ;

Site (Site#, Site_Nom, ...) ;

Utilisateur (Utilisateur#, Utilisateur_Nom, Site#, ...) ;

En relationnel, pour connaître les produits accessibles à l'utilisateur Louis en fonction du site dont il relève, vous pouvez écrire :

Produit JOIN Site JOIN Utilisateur WHERE Utilisateur_Nom = "Louis" {Produit_Nom}

Soit une double jointure naturelle (JOIN), une restriction concernant Louis (WHERE) et une projection {Produit_Nom}. A noter que la jointure naturelle est associative et que cette opération se fait sur la base des attributs ayant même nom, en l'occurrence Site# (à l’instar de l’opérateur NATURAL JOIN du Standard SQL).

Contrairement à l’approche COMMENT, l’approche QUOI permet de ne pas brider les moteurs relationnels. Ces moteurs disposent d'un optimiseur sémantique à même de transformer la requête ci-dessus de la façon suivante :

Produit JOIN Utilisateur WHERE Utilisateur_Nom = "Louis" {Produit_Nom}

Par contraste, en respectant le paradigme navigationnel du pointer-chasing, vous m'expliquerez comment ce genre d'optimisation est possible.

Pour mémoire, sans être conforme au Modèle relationnel, un SGBDR comme DB2 sait procéder à l'optimisation précédente, en évacuant la table Site de la requête. D'accord, DB2 utilise SQL, mais au moins il sait optimiser.

Question : Comment les SGBDOO optimisent-ils ? (sous-entendu trivial : peuvent-ils concurrencer les SGBDR en terme de performances, avec bien entendu des volumétries respectables (tables de l’ordre de cent millions de lignes et plus).

[GyLes]

Bonjour fsmrel,

En premier lieu l'objectif des SGBDOs n'est pas de concurrencer les SGBD traditionnels, notamment les SGBDR.

Une application ayant besoin de transactions courtes, rapides s'orientera naturellement vers un SGBDR.

Le SGBDO est optimisé dans ses mécanismes pour des transactions longues.
Les domaines ciblés ne sont donc pas les mêmes et les mécanismes de concurrence, de transactions sont donc différents. Un SGBDO apporte cependant quelques nouveautés dans cette gestion, comme la gestion des versions, des configurations.

Le SGBDO via son langage de requête peut être en mesure d'optimiser des requêtes, ce dernier étant basé sur quelques uns des principes des SGBDRs (indépendance physique et logique, index, clés, ...). Un SGBDO ne se limite d'ailleurs pas aux jointures par OIDS, il peut en effectuer par valeur.

Pour ce qui du principe navigationnel, les SGBDOs sont très performants. L'une des optimisations du SGBDO est de transformer les pointeurs logiques ou OIDs en pointeurs physiques (opération de swizzling) permettant d'avoir des relations entre objets basés sur des pointeurs mémoires. Nous retrouvons ici les performances de structures de données comparables au C.

Pour un parcours navigationnel, ils peuvent être une solution, pas forcément la solution.

Oracle, à partir de la version 8i ou 9i, à commencer à incorporer beaucoup de notions des SGBDOS (OID, hiérarchie, classe, ...). Oracle utilise dans ce cas les OIDs pour la navigation. Il est peu facile, et j'espère que vous m'en excuserez, de relancer une question à une question, mais quelles peuvent-être les intérêts de cette intégration dans un SGBD relationnel ?

[Luc Orient]

...
En premier lieu l'objectif des SGBDOs n'est pas de concurrencer les SGBD traditionnels, notamment les SGBDR.

C'est sûr qu'il auraient du mal, parce que en ce moment le chiffre d'affaires généré par les SGBDO c'est proche de zéro ...

On peut trouver ça dommage, mais l'informatique, en plus d'être ouverte à tous les concepts plus ou moins fumeux, c'est aussi une économie de marché ...

[fsmrel]

Oracle utilise dans ce cas les OIDs pour la navigation. Il est peu facile, et j'espère que vous m'en excuserez, de relancer une question à une question, mais quelles peuvent-être les intérêts de cette intégration dans un SGBD relationnel ?

Offrir des fonctionnalités OO pour se démarquer des autrres SGBDR ?

Quoi qu'il en soit, je lis dans "Oracle® Database Concepts 10g Release 2 (10.2)" page 27-5 :

"The object identifier column of an object table is a hidden column... The system-generated unique identifier has many advantages, among which are the unambiguous identification of objects in a distributed and replicated environment".

Mais :

Il y a violation du principe fondamental énoncé par Ted Codd, père du Modèle relationnel selon lequel "The entire information content of a relational database is represented in one and only one way, namely as attribute values within tuples within relations".

En outre, un projet dans un environnement distribué ça se modélise en conséquence et on ne peut pas faire l'économie des clés candidates traditionnelles (et des identifiants du niveau conceptuel), ce qu'Oracle du reste reconnaît :

"system-generated object identifiers need to be remapped using some user-specified keys, especially when references to them are also stored persistently."

SQL (Sorry Query Language) est laid et plein de verrues, mais là il lui en pousse des plus bizarres. Sont-elles franchement essentielles, comme aurait dit Guillaume d'Ockham ? Les arguments d’Oracle peuvent faire de l’effet sur l’amateur, servir à alimenter les conversations lors des coquetèles qui suivent les présentations, mais en tant que vieux bourlingueur, ça ne m'amuse plus.

[GyLes]

oui mais combien de schémas physiques respectent ce principe. Le principe de modélisation d'un schéma relationnel est de respecter ces principes dans le modèle conceptuel. Mais l'optimisation de l'application passe souvent ensuite par une phase de dénormalisation et donc de duplication de l'information dans les tables.

L'intégration de l'objet dans le relationnel répond à une demande et donc à un besoin. Je ne discuterai pas de l'intérêt d'intégrer l'objet dans le relationnel, je préfère conserver des produits qui soient spécialisé chacun dans son domaine, du relationnel pour le relationnel et de l'objet pour l'objet. Le relationnel étendu se veut être un pont vers les technologies objets.

Luc Orient: quels sont vos sources pour affirmer pareille affirmation ? Db4o a un succès grandissant, lisez les success stories de Objectivity, de Versant, de Ontos, Matisse, ... Les SGBDOs ont leur marché de niche, marché que les SGBDRs ne peuvent concurrencer de par leur architecture.


http://www.objectivity.com/pages/dow...essstories.asp
http://www.db4o.com/about/customers/

Quid des SGBDOs dits post-relationnel comme Caché ou Matisse :

http://www.matisse.com/customers/international/
http://www.intersystems.com/casestudies/by-company.html

[fsmrel]

Avant d’aller plus loin, je voudrais attirer votre attention sur le fait que :

SQL n’est pas le Modèle relationnel

Que cela soit bien clair. SQL (ou Askew wall) est un mur biscornu, qui masque le pays des relations et malheureusement la plupart font la confusion. SQL, les systèmes appelés post-relationnels, relationnels étendus et consorts ne seront jamais le Relationnel, même s’ils peuvent le tuer.

combien de schémas physiques respectent ce principe

Si vous parlez du principe fondamental énoncé par Ted Codd, The Information Principle, il y a erreur d’aiguillage, car Codd, qui n’était absolument pas informaticien mais mathématicien et logicien, ne s’intéressait en aucune façon au niveau physique : sous le capot, libre aux SGBD d’utiliser des pointeurs, des index, des techniques de hachage où tous autres artifices et c’est heureux ! Codd se situe uniquement au niveau de l’utilisateur qui ne voit que des valeurs au sein de relations (au sens relationnel) qu’il peut manipuler à l’aide de l’algèbre ou du calcul relationnels. (Au contraire, l’utilisateur d’un SGBD non relationnel comme IDMS/R voit des pointeurs, en infraction totale avec le principe fondamental.)

Le principe de modélisation d'un schéma relationnel est de respecter ces principes dans le modèle conceptuel

Je suppose que par "schéma relationnel" il faut entendre ce que l’on appelle l’en-tête d’une variable relationnelle (relvar), plus informellement schéma de table, à moins que vous ne vouliez parler de l’ensemble de ces schémas. Quoi qu’il en soit, quand on modélise des variables relationnelles, on n’a à se conformer qu’aux règles énoncées par la théorie relationnelle. Je ne vois pas très bien le rapprochement avec le terme "modèle conceptuel" qui ne fait pas partie de cette théorie mais plutôt de l’approche entité/relation.

Je ne discuterai pas de l'intérêt d'intégrer l'objet dans le relationnel

D’autant plus que le Modèle relationnel n’a pas à intégrer l’OO ! Il se suffit à lui-même, cf. (Date2006).

Par exemple, la définition de types scalaires arbitrairement complexes est y minutieusement décrite. Exemples (en Tutorial D) de types, suffisamment explicites :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Type Longueur Ordinal Possrep (M Rational Constraint M >= 0.0) ;

Type Point  /* points géométriques dans un espace à deux dimensions */
    Possrep Cartésien (X Rational, Y Rational)
    Possrep Polaire (R Rational, Thêta Rational) ;

Type Ellipse Possrep (A Longueur, B Longueur, Ctr Point Constraint A >= B) ;

Type Polygone Possrep (Sommets Relation (SommetId Integer, Sommet Point) ;

Etc. 

Avec évidemment les opérateurs associés :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Operator Cartésien (X Rational, Y Rational) Returns Point ;
   Begin ;
      VAR P Point ;
      ...
   End ;
End Operator ;

Operator Polar (R Rational, Thêta Rational) Returns Point ;
   Return (Cartésien (R * cos (Thêta), R*sin (Thêta)))
End Operator ;

Etc.

Le Modèle Relationnel de Données n’est pas figé, depuis 1970 il a connu des évolutions (mais pas de révolutions !). Date et Darwen classifient les fonctionnalités en "prescriptions, proscriptions, very strong suggestions" : si une évolution est jugée possible et désirable, elle sera la bienvenue ; ainsi en va-t-il de l’héritage de type (scalaire ou relation). En revanche il n’y a aucune chance que soit acceptée la possibilité de considérer une table comme étant un type et que soit a fortiori accepté l’héritage de table. Le type Relation est consubstantiel au Modèle relationnel, mais il est hors de question de pouvoir écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Create Table Localisation       /* Localisation est une table */
      (Ville Char(48) Not null,
       Département Char(48) Not null) ;  

Create Table Entreprise
      (Nom  Char(48) Not null,
       Adresse Localisation Not null) ; /* Localisation n’est pas un type ! */

Mais l'optimisation de l'application passe souvent ensuite par une phase de dénormalisation et donc de duplication de l'information dans les tables

C’est ce que décrètent ceux qui planent et n’ont jamais pris la peine de descendre dans la soute (je ne vous classe pas parmi ces gens, mais méfiez-vous d’eux). L’expérience montre que si l’on sait modéliser et normaliser, la dénormalisation (qui n’induit pas que des problèmes de redondance) n’a pas lieu d’être et on s’en assure par des opérations serrées de prototypage, avant de s’engager auprès d’une DSI sur la performance des applications de la base de données. Ça coûte de la sueur, ça demande de l’expérience, de l’organisation, etc., mais c’est incontournable : on ne peut être ni des perdreaux de l’année, ni des autruches fourrant leur tête dans le sable. Vous pouvez prendre connaissance de quelques observations que j’ai faites à ce sujet sur ce forum, notamment :
http://www.developpez.net/forums/sho...?t=6231&page=3


Référence :

(Date2006) C.J. Date, Hugh Darwen. Databases, Types, and the Relational Model The Third Manifesto, Third Edition (Pearson Addison-Wesley Longman, 2006).
http://www.amazon.com/Databases-Type...m/0321399420/1

[GyLes]

et c'est ce à quoi je reviens et persiste, les SGBDR ont leurs domaines d'applications et les SGBDOs leurs domaines d'applications bien spécifiques !

Un SGBDO ne viendra pas concurrencer un SGBDR sur le domaine de la gestion, de transactions rapides sur faible volume.

Mais je vois mal un SGBDR venir concurrencer un SGBDO sur ses domaines particuliers !

Sur le sujet de la normalisation, je vous crois mais je reste tout de même prudent. Combien de personnes expérimentées m'ont avancé ces propos de dénormalisation ...

Que l'on se comprenne bien, je ne pars pas en croisade contre les SGBDR, et j'espère que vous n'êtes pas en croisade contre les SGBDOs. Je suis convaincu que chaque SGBD a son domaine d'application.

Je suis convaincu aussi que les SGBDOs ont leur domaine d'application et qu'au lieu de rester dans des considérations un peu vieillotte de performances complètement dégradées ou de technologies loufoques, il serait intéressant de ne pas rester uniquement dans une vision de suprématie du SGBDR tout domaine confondu !

Les retours d'expérience m'intéressent fortement sur les SGBDOs.

Vous me demandez quelles sont les techniques d'optimisation des SGBDOs. Je vous en donne. Discutons la-dessus si vous le voulez bien pour comparer ces techniques, mais pas "sur le SGBDR est meilleur que le SGBDO". Chaque technologie a son domaine d'application, ne pensez-vous pas ?

Autre question, les types scalaires peuvent-ils s'apparenter aux TADs d'Oracle ?

[fsmrel]

Bonsoir,

et c'est ce à quoi je reviens et persiste, les SGBDR ont leurs domaines d'applications et les SGBDOs leurs domaines d'applications bien spécifiques !

Vous êtes tenace. J’ai dit qu’on était d’accord là-dessus. Je répète une fois de plus, à propos de cette personne qui s’occupait d’accidentologie — et ne jurait que par son SGBDO — que je pensais ne pas être capable de faire aussi bien avec mon SGBDR "généraliste" (mon message du 27/04/2007) et qu’il eut été stupide de ma part de chercher à la convaincre de changer.
Souvenez-vous encore que j’ai écrit : "quand il y a 20 ans, le professeur Gardarin et ses collègues ont créé Sabrina, ils ne pouvaient se contenter de types simples, alors que leur système était un système de gestion de bases de données relationnelles. S’ils avaient entrepris leurs travaux dix ans plus tard le qualificatif orienté objet eût à coup sûr remplacé celui de relationnel." ("Grosse base de données et performances", message du 27/04/2007).
Dans la série, les SGBDR sont certainement moins appropriés que les SGBDO pour la CAO, la GPAO, le développement des AGL, la gestion documentaire, les applications scientifiques, médicales, bref tous les domaines où l’on manipule des choses "complexes". Fermez le ban.

Un SGBDO ne viendra pas concurrencer un SGBDR sur le domaine de la gestion, de transactions rapides sur faible volume.

Qu’entendez-vous par faible volume ? Certains de mes clients envisageant de conserver en ligne des données sur 3 à 5 ans, cela conduisait à des tables allant de cinq à quinze milliards de lignes, d’environ une centaine d’octets chacune en moyenne. Il fallait les convaincre de ne conserver qu’un volume beaucoup plus réduit, disons un demi-milliard de lignes, pour qu’au final ces gens finissent par dire qu’avec deux-cent millions de lignes c’était déjà bien (ils savaient convertir en euros...) Relativisons et reconnaissons qu’il s’agit là de faibles volumes.
Qu’entendez-vous par transaction rapide en relation avec un SGBDR ? Au fond, peu importe. J’apporte quand même un complément d’information : les transactions lourdes et les batchs sont traités de façon plus que satisfaisante par un tel SGBD (conséquence des traitements ensemblistes). Pour les SGBDO, je n’ai pas d’opinion, puisque je ne les ai pas secoués et donc je ne cherche pas à comparer et polémiquer à ce sujet. Je ne parle que de ce que je connais.

Sur le sujet de la normalisation, je vous crois mais je reste tout de même prudent. Combien de personnes expérimentées m'ont avancé ces propos de dénormalisation

Beaucoup de personnes expérimentées m’ont aussi soutenu qu’il fallait dénormaliser. Le problème est (1) qu’ils modélisaient de façon approximative, (2) qu’ils ne savaient pas ce qu’était une réorganisation (3) qu’ils ne savaient pas prototyper, (4) que sur des batchs de mise à jour il faut savoir virer judicieusement les index, ... (n)... Les fondus de la dénormalisation, je connais.

les types scalaires peuvent-ils s'apparenter aux TADs d'Oracle ?

Je me place du point de vue de la théorie relationnelle : les seuls types non scalaires sont les types Tuple et Relation puisque les attributs sont exposés. Tout le reste est par définition scalaire (donc encapsulé).
Puisqu’Oracle propose une instruction "Create Type x As Object" telle que x peut être le type d’un attribut d’une table, je dirais que ça démarre correctement, x est scalaire. Maintenant, on peut écrire "Create Table R Of x", donc manipuler directement les composants d’un type qui finalement n’est plus scalaire, en notant que pour être en accord avec le Modèle relationnel, on ne pourrait écrire que "Create Table R (liste des <attribut, type>)". Qui plus est l’OID fait son apparition avec ce type, en contradiction avec le principe fondamental de Codd (The Information Principle) : on change de paradigme (ce qui est nettement suggéré par l'expression "As Object"). Accessoirement je ne me souviens pas que SQL3 mentionne cette variante de l’instruction "Create Type". Quoi qu’il en soit, du point de vue du Modèle relationnel, un TAD Oracle n’est pas un type scalaire, du point de vue OO, à vous de juger.