Cours bases de données : Architecture et Systèmes
...
Pour éviter le gaspillage d'espace on peut utiliser un fichier à structure variable :
Le gain de place n'est pas négligeable mais la gestion devient plus complexe.
Si l'on se penche maintenant sur la structure physique des fichiers (contenant), on se rend compte que des principes similaires à ceux énoncés précédemment sont mis en application, mais les mécanismes sont intimement liés aux possibilités de gestion des entrées-sorties du SE présent.
Structure physique : Ordre physique des enregistrements.
Bloc : est constitué de un à plusieurs enregistrements logiques traités comme un tout au niveau des entrées-sorties.
L'intérêt de ce principe réside, en tenant compte de la taille des buffers, dans la diminution du nombre d'entrées-sorties physiques.
De plus, les principes mis en place pour la gestion des mémoires secondaires autorisent le fractionnement d'un fichier physique en plusieurs endroits.
Enregistrement physique (ou bloc) : ensemble des caractères transférés par le système d'exploitation au cours d'une entrée-sortie.
Enregistrement logique : unité de base directement accessible par le programme utilisateur.
Les tailles de ces différents enregistrements ne sont pas obligatoirement compatibles : le SE doit permettre de faire la correspondance entre physique et logique.
Facteur de groupage (ou facteur de blocage) : Nombre d’enregistrements logiques contenus dans un enregistrement physique.
Schéma récapitulatif
Enregistrement physique 1
Enregistrement logique 1 Enregistrement logique 2 Enregistrement logique 3
Article ou enregistrement logique
N° Matricule Nom Prénom Adresse N° téléphone
Clé primaire Rubrique :
MICHEL
M I C H E L
2.1. Structure physique séquentielle
Ceci est le cas des bandes magnétiques : les enregistrements sont écrits les uns à la suite des autres.
Il est donc logique que la structure logique correspondante soit aussi séquentielle, ce qui rend les accès et les opérations de recherche très longs.
Ce type de structure est utilisé pour la sauvegarde et l'archivage des informations.
2.2. Structure physique adressée (ou adressable)
La tête de lecture peut se positionner directement à n'importe quel endroit du fichier.
Les fichiers peuvent être fragmentés (découpés en plusieurs parties logiquement chaînées mais physiquement situées à des endroit différents du support).
Cette structure est compatible avec toutes les structures logiques citées.
Organisation : Méthode permettant d'attribuer (écrire) un emplacement physique sur le support à tout enregistrement logique
On peut donc distinguer 4 grands types d'organisations :
1.1. Organisation séquentielle (heap)
Telle une série de fiches dans un bac, sans repères particuliers, une organisation séquentielle est basée sur un fichier séquentiel dont les enregistrements sont répartis sur plusieurs pages de données.
L’impression de désordre que laisse ce type d’organisation explique le nom qui lui est donné (heap veut dire tas).
Les accès sont relativement longs mais si les enregistrements sont triés selon un attribut couramment sollicité (organisation heap triée), cet inconvénient est moins sensible.
Cette organisation a pour avantage de considérer indifféremment chaque attribut de l'enregistrement ; on peut donc accéder aux informations en utilisant comme point d'entrée chaque attribut ou combinaison d'attributs de l'enregistrement, avec des performances équivalentes.
1.2. Organisation à accès direct
Dans ce type d’organisation, la valeur de la clé d’un enregistrement suffit à retrouver l’emplacement physique de celui-ci.
La zone de données (data file) est découpée en pages.
1.2.1. Adresse physique d’un enregistrement
Plusieurs cas de figure peuvent se présenter :
Exemple :
Page 0 Page 1 Page 2
0 512 1024
L’enregistrement grisé pourrait, selon les trois cas énoncés plus haut, se voir attribuer les adresses suivantes :
1.2.2. Mode d’adressage
Ceci étant défini, la valeur de la clé détermine l’adresse physique de l’enregistrement selon deux modes :
La valeur de la clé est la valeur de l’adresse physique de l’enregistrement.
Une fonction mathématique appliquée à la valeur de la clé permet de déterminer la valeur de l’adresse physique.
@ = f (clé)
Exemple : Soit la valeur de clé " DUPONT ", on aura : f (" DUPONT ") 576
1.3. Organisation séquentielle indexée (ISAM)
Il existe plusieurs versions d'organisation séquentielle indexée : IS3 (série 3 d'IBM), ISAM (Indexed Sequential Acces Method), VSAM (Virtual Sequential Acces Method).
Dans le fichier des données, les articles sont rangés séquentiellement à la création selon l’ordre croissant de la clé primaire, et en respectant un certain taux de remplissage par page de données. Dès que cette zone est pleine, les nouveaux articles sont rangés dans une zone de débordement (OVERFLOW) en attendant une restructuration du fichier par programme ou par utilitaire.
La zone de débordement contient les enregistrement ajoutés après la dernière indexation : il faut donc ré-indexer régulièrement le fichier.
En utilisant différents niveaux d'indexation et une indexation partielle des enregistrements, on se retrouve avec des index moins volumineux et tout aussi performants.
Cependant, il faut donc ré-indexer régulièrement le fichier et durant cette opération les informations ne sont pas disponibles.
1.4. Organisation indexée arbre B (B-TREE)
L'organisation B-Tree est aussi appelée arbre balancé (B pour balanced) ou arbre équilibré.
Le principal avantage de cette organisation par rapport à la précédente réside dans la mise à jour dynamique des pages de données et des index, rendant les informations disponibles à tout moment.
Un arbre-B peut être utilisé pour constituer l'index hiérarchisé d'un fichier :
- Il contient des clés triées par ordre croissant et des pointeurs de deux types :
les pointeurs internes qui désignent les branches de l'arbre ;
les pointeurs externes qui désignent des pages de données.
- Il possède au premier niveau une page unique d'index (le tronc), au deuxième niveau plusieurs pages d'index (les branches) et au troisième niveau plusieurs pages de données (les feuilles).
- Chaque entrée d'index donne le numéro de page d'une branche ou d'une feuille.
- Chaque entrée de feuille donne le numéro de page de données et le déplacement dans la page.
Les principes mis en œuvre lors d'un ajout sont les suivants :
Exemple : si la page de données est pleine : elle se coupe en deux ;
on ajoute une entrée dans la page d'index, qui se coupe en deux, si nécessaire ;
si cela n'est pas suffisant, on ajoute un niveau d'index (une branche supplémentaire).
Il n'y a pas de page de débordement, si l'index est unique.
Les mécanismes mis en œuvre font que l'arbre se démultiplie toujours harmonieusement évitant d'ajouter inutilement trop de niveaux d'index.
Accès : Façon de trouver (lire) un enregistrement sur le support ; moyen de sélectionner un enregistrement en tenant compte de l’organisation du fichier.
On distingue 4 grands types d’accès à un enregistrement :
2.1. Accès séquentiel
Accès séquentiel : accès au premier enregistrement, puis au second …
2.2. Accès direct
Accès direct : l'utilisateur ou le programme fournit une clé à partir de laquelle est calculée l'adresse ou le rang de l'enregistrement.
2.3. Accès semi-direct
Accès semi-direct : l'utilisateur ou le programme fournit la clé et la recherche se fait par l’intermédiaire de table(s) d'index (ou de branches).
Le fichier des index (index file) est divisé en zone des index de la clé primaire et en zone des index des clés secondaires. Chaque zone permet de localiser (par étapes) l’article recherché.
La table de correspondance (zone index) ne contient que les adresses d'un nombre restreint d'enregistrements en fonction de la rubrique d'index. Ces enregistrements servent de points d'entrée aux pages de données, telles des bornes de recherche.
Pour accéder à un enregistrement, on recherche dans la zone index l'adresse de l'enregistrement le plus proche de celui recherché et on se déplace ensuite séquentiellement dans la page de données.
2.4. Accès dynamique
Accès dynamique : on accède à un enregistrement en direct ou en semi-direct et on continue en séquentiel sur les suivants.
Accès Séquentiel Direct Semi-direct Dynamique
Organisation
Séquentiel (heap)
Direct
Indexé ISAM
Indexé BTree
Accès possible pour un type d'organisation
Sachant comment organiser les différents réceptacles de données que constituent les fichiers, il reste encore à organiser les liens entre ces fichiers, c'est à dire constituer un véritable Système de Gestion de Fichiers qui assure la cohérence et le fonctionnement de l'ensemble.
Là encore, de fortes similitudes existent entre les systèmes de gestion de fichiers utilisés par les différents systèmes d'exploitation et les systèmes de gestion de fichiers de données, objet de ce chapitre.
Les fichiers composant le SGF sont des fichiers de données et des fichiers de programmes.
Les fichiers de programmes permettent 2 types de traitements :
traitement interactif : une action extérieure implique un résultat immédiat de la part du système ;
ou
traitement par lots : le traitement comporte une série de commandes qui traitent plusieurs éléments et dont le résultat n'est pas immédiat
En conséquence de quoi, le traitement interactif est un traitement unitaire et le traitement par lots est un traitement différé.
Le Système de gestion de fichiers a pour but, en parfaite collaboration avec le système d'exploitation, d'assurer les tâches suivantes :
Au-delà de l'organisation interne de chaque fichier et des mécanismes permettant de manipuler les enregistrements de ces fichiers, la difficulté majeure demeure dans l'existence de différents fichiers au sein du système d'information d'une entreprise ou d'un organisme.
Si l'on prend le cas du système d'information de l'ESAT, et plus particulièrement l'activité de gestion des stagiaires : les stagiaires sont pris en compte par différents services de l'école, qui doivent, chacun manipuler des informations relatives à leur mission. En conséquence de quoi, chaque service dispose d'un fichier regroupant les informations qui les concernent, et sous une forme qui leur convient :
Service Général :
Grade Nom N° Véhicule
BureauPersonnel :
Grade Nom Prénom N° livret de solde
Chancellerie :
Grade Abréviation grade Libellé grade Nom Prénom
Division d'instruction:
Nom Prénom UV Matière Note
2.1. Redondance des informations
La même information est dupliquée dans plusieurs fichiers où elle peut, en plus, être structurée de manières différentes.
Exemple : Les rubriques grade, nom et prénom.
Cette redondance a pour effet direct une augmentation du volume de l'ensemble des fichiers.
2.2. Inconsistance des données
Les copies d'une même donnée ne concordent pas obligatoirement entre elles.
Exemple : Cas des codifications de grades, orthographes différentes pour le même nom …
2.3. Difficulté à rapprocher les informations
La tâche la plus couramment effectuée, en terme de traitement des données, consiste à associer des informations à d'autres informations, éparpillées un peu partout dans le système d'information de l'entreprise.
Exemple : Retrouver le numéro de livret de solde du stagiaire dont le véhicule porte telle immatriculation, retrouver les commandes d'un client, retrouver les fournisseurs d'un produit …
Ce sont ces associations entre informations qui sont traduites dans un MCD par la mise en place de relations.
Or les données sont de structures différentes et ne sont pas reliées physiquement entre elles, ce qui rend très difficile l'exécution de ces rapprochements : le développeur doit se charger d'effectuer ces rapprochements par comparaison des rubriques des fichiers concernés, en tenant compte de leur organisation, de leurs méthodes d'accès et en espérant qu'il n'y ait pas d'inconsistance !!
Les inconvénients suivants ne sont que la conséquence de ceux précédemment énoncés.
3.1. Difficultés d'accès
Les données étant dupliquées et éparpillées, il y a plusieurs moyens d'y accéder sans savoir à l'avance quel est le mieux adapté au traitement ou à la recherche souhaitée (par quel bout doit-on s'y prendre ?).
On a donc besoin d'un système global pouvant s'adapter aux demandes spécifiques et immédiates des utilisateurs.
De plus, il est difficile d'écrire des programmes qui permettent d'accéder aux informations de manière globale ; il devient nécessaire d'établir des relations entre les fichiers.
3.2. Multiplicité des mises à jour
Les données étant dupliquées, la modification d'une information entraîne autant de mises à jour qu'il y d'endroits où cette information est stockée.
Exemple : Un stagiaire féminin du nom de DUPONT se marie et décide de porter son nom d'épouse, DURAND. Il devient obligatoire de modifier la rubrique Nom dans chaque fichier.
Cette multiplicité des mises à jour est aggravée par les difficultés d'accès et par l'inconsistance des données ainsi que par le facteur temps qui rend le système incohérent tant que l'ensemble des mises à jour n'est pas fini.
3.3. Problèmes d'intégrité
Pour garantir un minimum de cohérence au système, on peut mettre en place un certain nombre de règles concernant les données : les contraintes d'intégrité (voir III.B.4 Intégrité et cohérence).
Parmi ces contraintes d'intégrité, on peut citer :
- l'unicité de valeur d'un attribut ;
- le contrôle des valeurs possibles d'un attribut ;
Exemple : solde >0 ; année naissance < année courante …
- la référence ou appartenance à un ensemble variable de valeurs …
Dans un SGF, la mise en place de ces contraintes est à la charge des programmeurs, qui doivent écrire les programmes correspondants, chose rendue complexe par le contexte d'instabilité et d'incohérence qu'impliquent les inconvénients déjà cités.
De plus, toutes ces difficultés rencontrées augmentent parfois considérablement le temps nécessaire à la mise à jour d'une information sur l'ensemble du système. Celui-ci se retrouve donc régulièrement dans un état incohérent qui peut impliquer des erreurs.
Exemple : En reprenant le cas de figure précédent, si un service ne prend pas rapidement connaissance de la modification de patronyme du stagiaire DUPONT ; ce service ne connaîtra que le stagiaire DUPONT alors que les autres services ne connaîtront que DURAND.
3.4. Problèmes de sécurité
De la même manière, il devient impossible de mettre en place les verrouillages nécessaires pour empêcher une personne d'accéder aux informations dont elle n'a pas le "besoin d'en connaître".
3.5. Indépendance données / traitements
Les langages de programmation utilisés pour manipuler les SGF comportent une très grosse partie dédiée à la déclaration et à la définition des informations traitées ainsi qu'à l'accès et à la manipulation de ces données. Cette lourdeur est démultipliée en cas de maintenance corrective ou évolutive de l'application.
De plus, il est dans l'intérêt d'un propriétaire de données de pouvoir faire évoluer indépendamment les traitements et éventuellement changer le langage de programmation sans remettre en cause toute l'organisation de ces données.
Organiser la gestion de données à partir d'un système de gestion de fichiers est une solution qui n'est pas satisfaisante : lourde à gérer, trop dépendante de l'organisation physique …
Même si l'emploi de méthodes d'analyse permet, dans une certaine mesure, de limiter la redondance et l'inconsistance des données, il reste clair que seules de nouvelles solutions techniques peuvent améliorer la possibilité de rapprocher ou de lier entre elles des informations de même sens.
C'est pourquoi d'autres systèmes de gestion de données se sont mis en place : les Systèmes de Gestion de Bases de Données (SGBD) ; leur objectif principal étant d'éliminer les inconvénients directs des SGF en espérant, par là même, éliminer les inconvénients indirects.
Chaque génération de SGBD constitue une avancée supplémentaire liée à des innovations technologiques ; chaque génération apporte des solutions nouvelles pour atteindre les objectifs énoncés et pour pallier les contraintes de la génération précédente.
III. Notions de SGBD
Définition normalisée (BOC/PP du 16/02/81 N7) : Une base de données est un ensemble de données organisé en vue de son utilisation par des programmes correspondant à des applications distinctes et de manière à faciliter l'évolution indépendante des données et des programmes.
Base de données : Ensemble structuré de données, enregistrées sur des supports, accessibles par l'ordinateur, représentant les informations du monde réel et pouvant être interrogées et mises à jour par une communauté d'utilisateurs.
D'autres définitions reprennent les même éléments tout en insistant sur certaines aspects :
On ne gère plus un ensemble de fichiers mais un ensemble de données structurées. En ce sens, le SGBD est donc :
Le système de gestion d'un ensemble cohérent de données non redondantes.
De plus, le SGBD doit répondre aux besoins de toute l'entreprise et non plus d'une application particulière, et ce, dans la limite des droits de chacun. On doit donc aussi considérer le SGBD comme :
Un ensemble de logiciels de gestion, de contrôle d'accès aux données et aux programmes les manipulant.
En visant cet objectif, on cherche naturellement à supprimer la redondance, à assurer l'unicité des saisies et mises à jour et à centraliser les contrôles.
C'est la modélisation conceptuelle qui va permettre, dans un premier temps, de répondre à ce souci.
Il s'agit ici de pouvoir faire évoluer indépendamment données et traitements.
Cette indépendance sera assurée grâce à une approche en plusieurs niveaux de la base de données.
On doit pouvoir ainsi établir des liaisons entre ensembles de données qui n'ont que peu de points communs (articles, fournisseurs, clients, comptabilité …).
Dans un premier temps, ces rapprochements seront matérialisés dans la base de données par des liens physiques visibles et manipulables par certains utilisateurs de la base de données. On pourrait alors qualifier cela de "ficelles" existant entre les données. Les versions suivantes de SGBD vont tendre à supprimer ces "ficelles" ; les liaisons entre les données seront assurées par des routines, invisibles mais utilisables à tout moment.
4.1. Intérêt des contraintes
L'information étant stockée de manière unique, il faut d'autant plus s'assurer de son intégrité, de sa fiabilité et de sa cohérence.
Pour cela, il faut pouvoir définir des contraintes d'intégrité ou des contraintes de cohérence entre données, contraintes qui doivent être prises en compte aussi bien pour la définition que pour le traitement des données et sans faire appel à la programmation (ou le moins possible, pour ne pas invalider les efforts fournis en terme d'indépendance données / traitements).
4.2. Définition
Contrainte d’intégrité : Règle spécifiant les valeurs permises pour certaines données, éventuellement en fonction d’autres données, et permettant d’assurer une certaine cohérence de la base de données.
Exemple : Certaines cardinalités impliquent une contrainte d'intégrité très forte. C'est la cas notamment des cardinalités 1,1.
4.3. Typologie
Ces contraintes peuvent prendre les formes suivantes :
- appartenance à une liste de valeurs ou à un intervalle (définition en extension ) ;
Exemple : Les couleurs recensées sont : Bleu, Jaune, Rouge; Les dates de naissance prises en compte sont comprises entre le 01/01/1938 et le 01/01/1972.
- format (nature, longueur ; définition en intention) ;
Exemple : Les couleurs recensées sont les couleurs primaires, codifiées sur 5 caractères alphabétiques ; Les dates de naissance prises en compte sont codifiées selon le format JJ/MM/SSAA.
- règle de vraisemblance ;
Exemple : Les dates de naissance prises en compte obligent que l'individu soit majeur mais n'ait pas atteint l'âge de la retraite.
- règle de cohérence avec d'autres informations…
Exemple : Saisie d'une note pour un élève qui est recensé dans la base de données.
4.4. Modes d'emploi
Il existe plusieurs manières de mettre en place les contraintes au sein d'une base de données :
Triggers : Traitements stockés au niveau du SGBD et déclenchés automatiquement lorsque survient un événement tel qu'une création, une modification ou une suppression.
Les applications doivent pouvoir partager les informations de manière transparente.
Les différentes actions de mise à jour des données doivent pouvoir être effectuées concurremment mais en respectant certaines règles de préséance entre applications et/ou utilisateurs :
Exemple : Si un opérateur sollicite une opération de lecture d'une donnée, cela autorise les autres opérateurs à procéder eux-mêmes à la lecture de cette même donnée, mais interdit toute opération de mise à jour (création, modification ou suppression) de la donnée.
De la même manière toute opération de mise à jour d'une donnée interdit toute autre opération (mise à jour et lecture).
Ces autorisations et interdictions sont gérées par un mécanisme de verrouillage. Cependant, il peut arriver que ces règles ne suffisent pas à réguler les opérations de consultation et de mises à jour des informations, ce qui provoque une situation dite d' interblocage :
Interblocage : blocage mutuel des deux opérations du fait des mécanismes de verrouillage mis en œuvre.
Il est indispensable d'envisager des procédures garantissant des récupérations contre tout type d'incident (matériel, logiciel), qu'il s'agisse de destructions logiques (anomalies de mise à jour) ou physiques, que ces destructions soient partielles ou totales.
Avant de présenter les mécanismes qui assurent cette sécurité, il est nécessaire de définir les notions de transaction et de requête.
Requête : Unité élémentaire de traitement permettant d'agir sur un SGBD.
Exemple : - Lecture des toutes les informations relatives aux clients ;
- Création d'un nouveau client ;
- Création d'un utilisateur du SGBD …
Transaction : Ensemble de 1 à n requêtes nécessaires à la réalisation d'une opération particulière.
Exemple : - Retrait d'argent d'un compte avec vérification préalable du solde ;
- Enregistrement de la livraison d'un produit avec mise à jour de la quantité en stock …
6.1. Atomicité des transactions
Pour que ces opérations soient réalisées de manière fiable en obtenant des résultats cohérents, il est indispensable que l'intégralité des requêtes constituant une transaction soit exécutée et que les résultats définitifs soient enregistrés dans la base de données.
En fait, un SGBD devra veiller à ce qu'une base de données reste dans un état cohérent. Pour cela les transactions ne doivent pas être exécutées partiellement : elles doivent être réalisées, soit entièrement, soit pas du tout. D'où le qualificatif d'atomique (qui constitue un tout indissociable).
Exemple : Si on considère une opération de transfert d'un montant M d'un compte bancaire C1 sur un compte bancaire C2, on peut concevoir que cette transaction nécessite les requêtes suivantes :
Requêtes Actions Résultats
R1 Lecture du montant du solde Solde C1 = Solde C1
R2 Débit sur C1 Solde C1 = Solde C1 - M
R3 Crédit sur C2 Solde C2 = Solde C2 + M
Si un incident survient entre les requêtes R2 et R3, la base de données est dans un état logiquement incohérent : le débit est effectué sur C1, le solde de C2 est erroné, le montant M a disparu !!
Une grande partie du fonctionnement d'un SGBD est guidée par le respect de cette contrainte d'atomicité des transactions.
6.2. Validation et annulation des résultats d'une transaction
6.2.1. La commande COMMIT
Lorsqu'une transaction s'est déroulée correctement et dans son intégralité, plus rien n'empêche que les résultats soient enregistrés définitivement. Cette validation des résultats est assurée par la commande :
Commit : Commande exécutée par le système, qui rend effectifs les résultats d'une transaction.
Cette commande est aussi mise à la disposition des utilisateurs qui ont la possibilité d'en demander l'exécution après chacune de leurs requêtes. De plus, l'exécution de cette commande libère les verrous posés par chacune des requêtes de la transaction.
6.2.2. La commande ROLLBACK
Si une transaction ne s'exécute pas complètement, le système dispose de la commande ROLLBACK lui permettant d'annuler les effets partiels de la transaction :
Rollback : commande exécutée par le système, qui annule les résultats d'une transaction.
Comme pour la commande COMMIT, l'utilisateur a la possibilité d'employer cette commande, pour éviter, par exemple, qu'une opération malheureuse ne vienne endommager la base de données (suppression intempestive, annulation de toutes les requêtes en cas de message d'erreur …). La commande ROLLBACK libère également les verrous posés par les différentes requêtes.
Exemple : Opération de crédit d'un montant de 100,00 FF sur un compte C1 :
Requêtes Actions Résultats
R0 Commit Solde C1 = 0
R1 Lecture du montant du solde Solde C1 = 0
R2 Crédit sur C1 Solde C1 = 100
R3 Lecture de C1 Solde C1 = 100
R4 Rollback Solde C1 = 0 , l'effet de la requête R2 est annulée !
6.3. Les mécanismes de sécurité
6.3.1. Les points de reprise
Lorsque le SGBD redémarre après un incident, il doit impérativement le faire à partir d'une situation de référence dans laquelle les données des bases de données sont dans un état stable. Pour garantir cela, le SGBD effectue à intervalles réguliers des points de reprise.
Point de reprise : Etat stable créé par le SGBD à intervalles réguliers. Le SGBD effectue un bilan des transactions en cours et valide les transactions terminées (les résultats de ces transactions sont écrits sur disque)
6.3.2. Le journal des transactions
A l'issue du point de reprise, toutes les transactions sont enregistrées dans un journal :
Journal des transactions : Fichier mémorisant l'état des bases de données à l'issue du dernier point de reprise ainsi que toutes les transactions effectuées par le SGBD depuis ce dernier point de reprise.
6.3.3. La procédure de reprise
Lors de la reprise après incident, le système redémarre depuis le point de reprise précédent en appliquant le journal des transactions, pour se retrouver dans la même situation qu'avant l'incident : il s'agit d'une procédure de reprise.
6.4. Duplication des données
Pour se protéger des destructions physiques massives d'informations, seules les duplications (sauvegardes) par des dispositifs réguliers (hebdomadaires, journaliers…) ou permanents (mirroring, réplication…) constituent une garantie suffisante.
Un SGBD doit offrir une protection des données afin d'éviter les accès illicites.
On peut notamment assurer la confidentialité en mettant en œuvre des procédures :
- d'identification ;
Exemple : nom d'utilisateur ou login
- d'authentification ;
Exemple : mot de passe
- d'autorisation d'accès.
Exemple : définition des possibilités de consultation de création, de modification, de suppression d'une ou plusieurs entités au profit des utilisateurs.
N.B. : Le souci d'identification et d'authentification pour accéder à un SGBD se superpose systématiquement au même besoin pour le système d'exploitation.
Pour éviter qu'un utilisateur ne soit obligé de s'identifier et de s'authentifier deux fois (une fois pour accéder à sa machine et une fois pour accéder au SGBD), il peut être possible de reprendre les éléments d'identification et d'authentification du SE (même nom d'utilisateur, même mot de passe). Ce dispositif s'appelle le "mapping".
Vers 1965 des sociétés comme Honeywell (IDS 1) et IBM (IMS 1) ont développé des produits permettant de constituer des chaînes d'articles entre les fichiers et de parcourir ces chaînes : la multi-indexation. On retrouve derrière cette innovation la volonté de faciliter le rapprochement d'informations.
A la fin des années 60, les premiers SGBD apparurent accompagnés des premiers langages navigationnels
L'innovation principale réside dans la séparation de la description et de la manipulation des données.
L'apparition de langages permettant de manipuler les données va résoudre en partie le problème de la redondance et de l'inconsistance des données. Ces langages utilisent les liens logiques et physiques mis en place lors de la construction de la base de données.
Ce type de SGBD utilise les possibilités suivantes :
1.1. La représentation graphique des données
La dépendance entre les données est formalisée selon des règles simples :
Modèle linéaire : chaque entité a une seule entité 'mère" et, au plus, une seule entité "fille".
Modèle arborescent : Chaque entité a une seule entité "mère" mais peut avoir plusieurs entités "fille".
Bien sûr ces règles ont un impact direct sur la représentation graphique des modèles de données :
Modèle hiérarchique linéaire Modèle hiérarchique arborescent
Dans les deux cas, l'organisation reste sous la forme d'arborescence, mais des liaisons entre les éléments d'un même niveau ne sont pas possibles, d'où le terme de hiérarchique (Il n'existe pas de lien logique direct entre les entités C et D).
