Discussion :

[itmak]

Bonjour,

1) Je cherche un cours détaillé sur les SGBD hiérarchiques.
2) Comment programmer un SGBD hiérarchique?

merci

[dgi77]

Je n'ai pas d'exemple à te fournir, mais c'est quand même un peu pourri le hiérarchique, du moins archi-dépassé : tables avec des multitudes de colonnes, grosse redondance des données, lourdeur d'accès aux données, ... c'était une autre époque.

Heureusement que depuis le relationnel est arrivé...

[gregory.broissard]

Le hiérarchique est encore très utilisé dans les grosses entreprises ayant besoin de traiter de gros volumes de données très rapidement car en terme de traitement de gros volumes, c'est super super efficace!

Ce n'est donc pas dépassé du tout, c'est ancien mais IBM continue de développer IMS et DL/1 et de le faire évoluer c'est donc qu'il y a bien une demande.

Regarde du côté de google en cherchant IMS et DL/1

[dgi77]

En y réfléchissant, c'est sûr que tu ne dois pas pourrir les plans d'exécution des requêtes à cause des jointures...
Un bon index, et roule ma poule !

[itmak]

merci pour les tuyaux mais je cherche plus de détails.
Je dois comprendre le fonctionnement le concevoir et le réaliser.

[gregory.broissard]

faut regarder sur google... peut etre que des universités ou écoles ont des cours mais à mon avis ca n'ira pas loin.

Apres il te reste la possibilité de demander à ton employeur une formation chez IBM sur IMS: http://www-05.ibm.com/services/learn...urseNr)/IM210F

[fsmrel]

Bonsoir,

Comment programmer un SGBD hiérarchique?

Souhaitez-vous modéliser et développer une application selon le paradigme hiérarchique ou bien concevoir et fabriquer un SGBD hiérarchique ?

Je dois comprendre le fonctionnement le concevoir et le réaliser.

Si vous avez à concevoir un SGBD hiérarchique (pardonnez-moi, mais en 2008, cela me paraît relever du bizutage), vous devez commencer par suivre un cours IMS/DL1 chez IBM (ou dans une SSII ou un organisme continuant à dispenser ce genre de formation).


Quelques pointeurs concernant IMS DL/1 :

Point d’entrée
http://www-306.ibm.com/software/data/ims/ims/index.html

Commandes DL/1
http://publibz.boulder.ibm.com/epubs/pdf/dfsp50d4.pdf

Application Programming Guide
http://publibfp.boulder.ibm.com/epubs/pdf/dfsapgh0.pdf

IMS/ESA V6
http://www-03.ibm.com/servers/eserve...pdf/ims61.html

IMS V10
http://www-1.ibm.com/support/docview...=utf-8&lang=en

Il y a aussi les cours que j’ai montés et dispensés, mais ils sont au fond de mon grenier, sous le foutoir de piles de souvenirs, perdus à jamais...

Suite à l'étude ce ces documents, mettez-vous à quatre ou cinq experts en SGBD et en programmation et enfermez-vous pendant un an à concevoir et développer votre SGBD (pour ma part, j’ai donné, je ne recommencerai pas...)

c'est quand même un peu pourri le hiérarchique, du moins archi-dépassé : tables avec des multitudes de colonnes, grosse redondance des données, lourdeur d'accès aux données

Allons, allons, dgi77, le concept de table n’est apparu qu’avec le 1er SGBD relationnel, System/R, au milieu des années soixante-dix. Même chose pour le concept de colonne. Avec les systèmes hiérarchiques (au moins le plus important d’entre eux, à savoir IMS DL/1), on raisonne en termes de champs dans des segments.

Où avez-vous été cherché que les données étaient particulièrement redondantes ? Pour avoir bien pratiqué IMS et DB2, je puis vous assurer qu’en fait il est incomparablement plus facile d’être redondant quand on manipule des tables (avec un système hiérarchique, on accède aux données en suivant les pointeurs (à l'attention de kamelini : physical child first, physical child last, physical twin, physical parent, logical child first, etc.))

Lourdeur d'accès aux données : qu’entendez-vous par ça ?

En tout cas, j’ai observé que les structures décrites en hiérarchique (ou réseau) par des concepteurs à la tête bien faite, étaient correctement migrées sous forme de tables relationnelles et que les concepteurs fouillis procédaient à des migrations toujours délirantes et finissant dans la poubelle.

Si vous voulez critiquer les SGBD hiérarchiques, parlez plutôt de la dissymétrie de la représentation des données, de la nécessité de produire un programme d’au moins cent cinquante lignes (conséquence de la chasse aux pointeurs, répercutée dans les Get Unique, Get next, Get Next Within Parent et inhérentes aux Segment Search Areas débiles mais incontournables), quand avec un Select SQL, on obtient le résultat de manière déclarative et non procédurale, en quelques lignes.

Le hiérarchique est encore très utilisé dans les grosses entreprises ayant besoin de traiter de gros volumes de données très rapidement car en terme de traitement de gros volumes, c'est super super efficace!

Je confirme. Simplement, on reste confronté à la nécessité de raisonner procédural et pointeurs (au moins avec IMS tel que je l’ai pratiqué jusqu’en 1986, après je ne sais pas). Et subsiste toujours ce fichu dilemme de la dissymétrie, inhérent au hiérarchique : Le contrat dépend-il du client, ou est-ce l’inverse ? (quoique avec les relations logiques, on arrive à symétriser les choses, mais au détriment de la performance). Je me souviens de débats houleux il y a trente ans : dans la journée, le contrat dépend du client (généralement point d’entrée dans les systèmes transactionnels), la nuit faisant permuter les rôles (batchs traitant des comptes, donc des sous). Question à 34 centimes d'euro la minute : comment résoudre cette variante de la quadrature du cercle ?

[dgi77]

Je vois que je suis tombé sur un dinosaure du hiérarchique qui a pratiqué ces systèmes pendant des décennies avant 1986, donc je m'incline humblement sur les arguments avancés.

Je n'avais étudié le hiérarchique que d'un point de vue théorique pendant mes études au début des années 1990, et déjà c'était la risée de tout le monde. Donc, en gros, je voulait dire que c'était plus qu'obsolète.
Il me semble qu'on avançait le problème de la redondance des données car en passant du modèle logique au modèle physique, toutes les données des entités mères devaient être redescendues, créant un vaste fichier plat...

[fsmrel]

Je n'avais étudié le hiérarchique que d'un point de vue théorique pendant mes études au début des années 1990, et déjà c'était la risée de tout le monde. Donc, en gros, je voulait dire que c'était plus qu'obsolète.

Je suppose que l’enseignement que vous avez reçu à l’époque était incomplet, sinon bien superficiel et déformé. Le modèle hiérarchique est orienté vers la représentation arborescente des données. Disons que la structure est celle d’un arbre non balancé (les feuilles ne sont pas toutes à la même distance de la racine). Pensez-vous que la représentation arborescente soit aujourd’hui obsolète ? Je viens d’ouvrir MS SQL Server : L’explorateur d’objets me présente un arbre non balancé : sous la racine, j’ai les nœuds Databases, Security, Server Objects, Replication, Management. Sous le nœud Databases, SQL Server me présente la liste des bases de données, la sienne et les miennes. Sous chaque nœud Database, j’ai la liste des tables, des vues, des synonymes, etc. Sous chaque table, j’ai la liste des colonnes, des clés, des triggers, etc. Qu’y a-t-il de risible ?

Maintenant, plutôt qu’au modèle théorique, peut-être faites-vous allusion aux SGBD qui s’y conforment, du genre de celui que voudrait peut-être réaliser kamelini. A l’époque des dinosaures, il y a certainement eu réalisation de pas mal de prototypes et de SGBD qui furent commercialisés pendant un laps de temps plus ou moins bref. Mais quand on en arrive à DL/1 (un gâteau sans doute de 500 à 700 millions de dollars aujourd’hui), on vient dans une autre cour et il faut bien connaître la bête pour en parler et discerner légende et réalité.

toutes les données des entités mères devaient être redescendues, créant un vaste fichier plat...

Venons-en au niveau physique : il est vrai qu’avec DL/1, une organisation purement séquentielle des données telle que HSAM peut inciter à vider une hiérarchie sur un fichier plat, par exemple pour effectuer certains traitements batch. Si l’on connaît le produit, on passe à HIDAM (pour ceux qui ne se mouillent pas) ou à HDAM (pour les plus pointus). Par le jeu des relations logiques, on peut construire une arborescence dont les nœuds reposent physiquement sur autant de fichiers. Je vous suggère donc de laisser tomber les légendes et une vision trop simpliste, caricaturale du modèle hiérarchique. Déjà que les SGBD relationnels sont la risée des tenants des SGBD objets (dont les promoteurs, rappelons-le, ont découvert à leur tour le mécanisme d’adressage par pointeurs...)