SYSTEMES DE BASES DE DONNEES

©2002 Jean Bellec

Retour Histoire informatique

en construction

Les applications de gestion opèrent sur des entités appelées fichiers. Ces fichiers sont dérivés des supports existant depuis l'antiquité et utilisés par les marchands, comptables, intermédiaires financiers... Le fichier est un "container" d'informations plus ou moins bien classées qui représentent une image de données réelles (stocks, transactions, description d'ensembles divers). L'enregistrement de données dans des fichiers est devenue progressivement le seul élément des transactions financières (dématérialisation des titres et des mouvements de capitaux). 

L'informatique de gestion depuis la mécanographie des années 1930 a eu comme objet les opérations sur des fichiers. Avant de décrire le format de ces fichiers mécanographiques, il n'est pas inutile d'observer le traitement de fichiers "manuels". Les petits fichiers (tarifs, tables de conversion...) tiennent sur une feuille de papier et l'oeil peut accéder directement à l'élément recherché. Lorsque l'accès direct est un peu plus difficile, les éléments sont triés par ordre alphabétique ou des critères similaires (agenda)... Les fichiers sont souvent composés de fiches comportant des éléments de type identique, mais avec des valeurs différentes et ces fiches seront conservées triées selon certains critères et recherchés séquentiellement (par exemple selon la date de création de la fiche ou dans l'ordre alphabétique d'un  certain champ de la fiche. Après des modifications dans les fiches, le fichier peut être laissé en l'état mais devient plus difficile à utiliser (cf. agenda raturé) ou bien retrié, ce qui signifie parfois pour les documents papier réécrit.

Le traitement par ordinateur des fichiers n'est pas fondamentalement différent des accès manuels. Pendant longtemps, l'être humain avait des facultés de traitement global supérieur à celui des ordinateurs, et ne bénéficiait de la mécanographie que pour le décharger de tâches répétitives (nombre important de fiches ) ou pour éliminer les aspects subjectifs de la comparaison des données, susceptibles d'entraîner erreurs ou fraudes. Lorsque la capacité d'accès direct de l'ordinateur a dépassé celle utilisée par l'être humain pour ce type d'opération, l'ordinateur a permis d'une part d'effectuer par lui-même des traitements plus complexes que ceux faisables par un être humain, d'autre part de mettre en commun les capacités de plusieurs êtres humains au profit de tous. C'est ainsi que progressivement l'ordinateur est devenu le dépositaire des données d'une entreprise ou d'une fonction.

 

La nature des supports des fichiers a évolué en fonction de la technologie, mais inversement les recherches technologiques ont été orientées par es besoins des applications esquissés ci-dessus. Le besoin des applications pour le traitement automatique de gros volumes de fiches a entraîné le développement de supports de fichiers séquentiels sur cartes perforées, bande perforée puis bandes magnétiques. Ces technologies souvent venu d'autres industries (télécommunication, radiophonie) ont été perfectionnés par les industriels informatiques. Par ailleurs, leur disponibilité a orienté des particularités des ordinateurs de gestion .

Les besoins en fichiers à accès direct ont bénéficié de l'accroissement des mémoires centrales (tores, tambours) et ont suscité des études pour développer des mémoires plus volumineuses (la recherche infructueuse de solutions à base de cartes magnétiques et bien entendu le succès des mémoires à disques).

Un débat qui a agité le monde des supports (médias) des bases de données dès l'origine a été l'attachement temporaire ou définitif de ces médias à l'ordinateur. Les informaticiens ont été tentés par la solution d'un attachement permanent du système de fichiers à l'ordinateur tant pour des raisons d'une architecture plus simple que pour conforter le monopole des constructeurs. Les utilisateurs préféraient le plus souvent des systèmes plus souples à partir du moment où le médias amovibles n'alourdissaient pas outre mesure les coûts d'exploitation.

Les premiers systèmes de fichiers à accès direct (disques et tambours) ont associés des disques fixes aux ordinateurs (IBM RAMAC, 1301, tambour Univac Fastrand...). IBM soucieux de donner aux fichiers disques la souplesse des exploitations sur bandes et peut-être avec l'espoir de faire disparaître celle-ci lança les disc packs interchangeables au début des années 1960 sur la série 1400, puis la série 360. La vogue du "temps partagé" provoqua une érosion des avantages des disques interchangeables et des problèmes technologiques de compatibilité média-têtes de lecture semblaient privilégier les disque fixes associés à l'ordinateur. L'utilisation d'un catalogue centralisé multi-utilisateurs semblait condamner le disque interchangeable. IBM riposta en fabriquant un ensemble amovible comportant le disque et ses têtes de lecture -avec la technologie Winchester- et le débat continua sans que la victoire des disques fixes soit définitive. Certes des raisons de coût eurent tendance à marginaliser l'approche des disques amovibles surtout sur les micro-ordinateurs, bien que la solution Winchester se retrouve chez Iomega avec le Zip. Une alternative naquit vers le milieu des années 1990: elle consista à proposer des systèmes indépendants de stockage de données fournissant des serveurs de fichiers alimentant à la demande les serveurs d'application et possédant un système indépendant de sauvegarde des données tant sur le plan physique (RAID) que logique (journaux).

L'organisation des fichiers décompose le fichier en enregistrements ou  "articles". Beaucoup de fichiers (notamment tous les fichiers séquentiels et les tables des bases de données relationnelles" ne contiennent que des enregistrements de nature identique. D'autres organisations dites intégrées peuvent contenir plusieurs types d'articles. Les articles sont ensuite divisés en plusieurs champs de données. Ce repérage des champs par le système de base de données permet facilement d'effectuer des opérations de tri, de calcul et de repérage à l'intérieur des fichiers.

Au début de l'informatique, les architectes et les programmeurs avaient un souci permanent de ne pas gaspiller l'espace de stockage des données, non seulement en mémoire centrale, mais en mémoire secondaire. Les fichiers d'articles composés exclusivement de champs fixes étaient plus l 'exception que la règle. Deux procédés différents ont été utilisés pour connaître les champs variables: le premier consistait à faire les données du champ d'un caractère spécial "délimiteur de champ"  ainsi qu' un délimiteur d'article à la fin de l'article; la second faisait précéder chaque objet de longueur variable d'un descripteur abrégé comportant la longueur du champ ou de l'article. Les code ASCII et EBCDIC conservent la trace de ces délimiteurs. L'inconvénient majeur de ces deux procédés est de nécessiter un traitement préalable des données dans le système de fichiers qui doit comparer chaque caractère avec les délimiteurs (appelés aussi flags ou drapeaux en français). Certains ont cherché à transférer ces opérations au niveau du processeur de canaux, au prix d'un dialogue complexe entre celui-ci et la gestion des fichiers. L'approche moderne, bénéficiant de la réduction de coût des mémoires, consiste plutôt à attribuer à chaque champ une longueur maximum et à conserver à chaque article en cours de traitement une longueur fixe, quitte à comprimer les données brutes en un archivage compressé en utilisant des algorithmes de compression sans perte. Cette stratégie ne s'applique pas au traitements de texte qui continuent d'associer une reconnaissance de mots par contexte avec des délimiteurs de champs partageant des attributs communs.

Il faut cependant distinguer les  fichiers pour lesquels existe une description des données indépendante de tout programme d'application et ceux où les bornes de champs, voire d'articles sont définis à l'intérieur d'un programme d'application, comme ce fut le cas dans trop de sites dans les années 1950 à 1970. Cette interaction forte entre programmes et données avait comme prétexte la réduction de l'encombrement des fichiers, le by-pass de la gestion des données du système d'exploitation, voire la possibilité de back-doors dans un but de fraude par certains programmeurs.

On distingue en général parmi les fichiers homogènes ceux à organisation purement séquentielle optimisés par un traitement en batch processing et les fichiers indexés où un fichier (ou plusieurs fichiers) auxiliaire(s) de "clés" permet d'accéder directement à l'article dont le champ désigné par la clé est comparé à une certaine valeur.

De nombreuses variantes de ces fichiers indexés ont vu le jour depuis 1955. Ils ne diffèrent généralement que par deux critères: la rapidité de l'accès et la gestion des optimisations des temps d'accès sur les médias physique. Très rapidement ce dernier problème s'est complexifié par l'utilisation d'un cache en mémoire principale (à l'origine réduit à quelques articles situés dans un même container), par un système de percolation entre des unités de mémoire à temps d'accès où à débit différent et par la complexité du système de journalisation propre à cette variété de média et aux besoins de l'informatique transactionnelle.
Les fichiers séquentiels-indexés furent les plus répandus dans les années 1965-1985 y compris sur micro-ordianteurs avec la famille Ashton Tate DB2.

Au milieu des années 1960, un modèle plus complexe attira l'attention, le modèle hiérarchique, comprennat plusieurs types d'articles organisés en arbres. C'est ainsi que IMS/DB de IBM et son sous-ensemble DL/1 s'introduisirent dans le marché des main frames IBM respectivement sous OS et DOS.

Les fichiers intégrés dont l'archétype est l'IDS inventé par Charlie Bachmann à General Electric, plus tard adopté par ICL et Cullinet (IDMS) était lui aussi un système où la description du fichier était bien formalisée dans un schéma séparé des programmes d'applications, mais où des articles de types différents se partageaient le même container.
Aux clés étaient substitués des chaînages entre occurrences d'articles de même type ou de types différents, permettant de stocker dans la base de données des relations complexes entre articles. Les avantages de l'organisation CODASYL (ainsi nommée car elle atteignit presque le statut de la standardisation COBOL au début des années 1970) étaient surtout dans le domaine des performances, à un moment où la taille des mémoires centrales était peu favorable à la réalisation d'un cache de taille substantielle. Elle exigeait au moment de la conception du schéma une analyse profonde des relations entre la spécification de l'entreprise et tous les programmes à développer. IDS ne s'avèrera pas propre à développer l'informatique de gestion dans un environnement évolutif malgré l'introduction du concept de vues (sous-schémas) en 1969.
 Après des discussions homériques entre Bachmann et Codd de IBM (tous deux agissant en franc-tireurs dans leur compagnie) la conception des bases de données relationnelles préconisée par Codd triompha essentiellement par ses capacités plus grandes d'adaptation aux évolutions de la gestion dans les entreprises et sa compatibilité avec les traitements séquentiels classiques. IBM avec DB2, Oracle et les développements universitaires de Berkeley autour de Ingres et Postgres imposèrent le relationnel. De nombreux développements, dérivant plus ou moins soit des systèmes universitaires soit d'accords d'entreprises conduisirent à rendre le modèle relationnel disponible sur tous les systèmes d'exploitation, notamment Unix et Windows (Microsoft SQL server, Oracle, DB2 et MySQL pour ne citer que les plus répandus. Les améliorations du matériel en particulier la puissance processeur et la taille des caches effacèrent les inconvénients du relationnel à partir de 1990.