SYSTEMES DE BASES DE DONNEES
©2002 Jean Bellec
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. 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.
|