Chapitre 3

Chapitre 2 : MODELES de BASES DE DONNEES et GENERATIONS de SGBD


Dans le premier chapitre, nous avons précisé les caractéristiques que devait présenter un modèle de données afin de décrire - "modéliser" - correctement le monde réel : permettre la représentation et la description des entités et de leurs données constitutives, des liens qui les relient et de certaines assertions appelées contraintes d'intégrité. Ces composants d'un modèle conceptuel de données doivent autoriser une description de la réalité qui soit le plus indépendante possible des capacités de définition logique et de stockage physique des données par le système logiciel appelé SGBD .

Il faut donc distinguer entre modèles conceptuels, a priori indépendants des SGBD, et modèles logiques, caractéristiques d'une génération de SGBD. Ces modèles logiques sont eux-mêmes dépendants d'organisations physiques (placement et méthodes d'accès) comme, par exemple, les graphes en arbres ou en réseaux, seules structures offertes par la première génération de SGBD, celle des modèles navigationnels, hiérarchique et réseau.

Ces SGBD obligeaient à "voir" - c'est à dire à traduire - une base de données comme un ensemble d'enregistrements, reliés les uns aux autres par des ensembles de pointeurs. Cette organisation fige les relations existant entre les différents enregistrements de la base et impose un type de manipulation, la navigation, qui consiste à suivre, d'enregistrement en enregistrement, les chaînes de pointeurs. En fait, il serait préférable de parler de modèles d'accès (physiques) plutôt que de modèles de données (logiques) pour ces anciens SGBD. En effet leur organisation physique des données imposait la méthode d'accès et, au delà, la nature des langages de manipulation.

II.1. Les modèles de conception indépendants des SGBD

Le modèle "Entité-Association" ("Entity-Relationship" ou ER), présenté au Chapitre 1, est contemporain de ces premiers SGBD, qui seront décrits à la fin de ce chapitre. C'est un modèle de conception, généralement utilisé en mode graphique, indépendant des possibilités (logiques et physiques) des SGBD. Pour cette raison il reste très populaire, d'autant que les schémas de données qu'il permet de construire peuvent être traduits presque automatiquement dans les modèles logiques des SGBD des différentes générations : hiérarchique, réseau, relationnel et même orienté objet.

Il a été au fil du temps "enrichi" (Enhanced => EER) ou "complété" (ERC). Les nouveaux modèles de conception orientés objet (OO) ont toutefois vocation à le remplacer, surtout depuis leur récente unification avec l' "Unified Modeling Language" (UML).

Le foisonnement des variantes de l'ER et des modèles OO (OMT, Booch, OOSE...) ont entrainé une certaine confusion chez ceux-là mêmes qui appréciaient la clarté des schémas graphiques produits par l'ER ou ses successeurs. Aussi tenterons-nous, en quelques courts paragraphes, de montrer que pour l'essentiel (les concepts) ils présentent, au delà des différences de notation, une progression continue et sans perte des acquis principaux.

II.1.1. Entités et individus ou classes d'objets

L'entité , comme ensemble d'individus de même type, est un concept auquel on peut facilement substituer celui de classe d'objets ayant les mêmes types (ou "structures") de données (et les mêmes "méthodes" pour les manipuler). Les individus "instancient" les entités comme les objets instancient les classes. Les individus comme les objets doivent avoir un nom commun (celui de l'entité ou classe) et un identifiant unique et invariant de leur naissance à leur mort, que le concept physique de clef sur un article ne suggère qu'imparfaitement (on peut changer une clef pas un identifiant). Ayant le même type ils sont de surcroît décrits par les mêmes variables nommées : caractéristiques ou attributs (synonymes). Ces variables peuvent être de structures simples ou complexes : n-uplets (variables composites par ex. une Adresse) ou ensembles (variables multivaluées par ex. un Prénom). Les formes graphiques représentant entités ou classes sont différentes mais traduisibles l'une dans l'autre comme illustré ci-dessous par l'exemple de l'entité PLAGE :

N.B. l'attribut souligné est un identifiant externe, il appartient au SGBD de créer le véritable identifiant invariant (appelé pour cette raison identifiant interne ou "surrogate")

II.1.2. Liens, rôles et cardinalités

Entre les objets (ou les entités) peuvent exister des liens nommés porteurs d'une sémantique commune : le rôle. Ils peuvent lier des objets de classes différentes (comme BAIGNEUR et PLAGE, pour exprimer le rôle AIMER ou le rôle SE_BAIGNER ou un autre rôle) ou de même classe (comme BAIGNEUR, pour exprimer un rôle comme PARENT_DE ou comme ENSEIGNE_A). Dans le modèle ER ces liens sont représentés par des associations (il est interdit de relier directement des entités entre elles), même si elles n'ont pas d'attributs propres. Dans le modèle UML, si aucun attribut n'est associable au lien, celui-ci se représente par une simple arc entre les classes qu'il lie, sinon une classe association est ajoutée. Exemple :

Les cardinalités de ces liens ou associations spécifient, pour chaque extrémité d'un lien, c.à.d. pour chaque classe liée, le nombre d'objets pouvant être reliés à un même objet de la classe à l'autre extrémité. Les différentes notations ci-dessous sont équivalentes :

On peut être plus précis en spécifiant des cardinalités minimum et maximum, c.à.d.

au lieu de 1 l'une des paires (0,1) ou (1,1), au lieu de n l'une des paires (0,n) ou (1,n), on peut aussi afficher cette valeur n maximale, par exemple (0,3) ou (1,10)... Les dernières notations de la figure précédente pour l'association - de plusieurs à plusieurs, "n à n" - NAGEUR-aime-PLAGE pourraient être utilisées comme ci-dessous :

(dans la 2e notation le rond est un zéro et la barre verticale un 1)


Attention: dans le modèle ER classique, quand les cardinalités (min,max) sont indiquées, elles le sont généralement à l'inverse de toutes les notations précédentes. En effet les liens directs entre entités étant impossibles et l'association étant toujours considérée comme une classe intermédiaire instanciable, cette inversion s'explique pourvu que l'on passe bien par toutes les étapes de la traduction, ce que nous illustrons ci-dessous pour l'association - de 1 à n - REGIONaffichePLAGE :

(la raison pour laquelle la "classe association" est notée par un double rectangle sera expliquée plus loin)

II.1.3. Associations identifiantes et/ou entités faibles

 Les entités ou les classes s'opposent aux associations ou aux liens en ce qu'elles sont définissables en elles-mêmes. De même les identifiants de leurs individus ou instances sont autonomes. Or il existe de nombreux cas dans les univers à modéliser où certaines entités ne sont définies que relativement à d'autres, et les identifiants de leurs individus composés d'un identifiant d' "individu parent" suivi d'un identifiant propre en tant qu' "individu enfant". Dans ce cas on dit que l'entité correspondante est "faible" et que l'association parent-enfant est "identifiante". Pensez par exemple aux différents comptes bancaires d'une même client d'une banque, aux différentes personnes à la charge d'un même assuré social, aux différents joueurs d'une même équipe de foot, aux différents bureaux dans un même couloir, etc... La suppression de l'individu parent entraine celle de tous les individus enfants liés (suppression en "cascade"). Les différentes notations en usage sont illustrées par l'exemple classique ci-dessous :


Dans cet exemple les COMMANDE et PRODUIT sont des entités "fortes" par opposition à LIGNE_CDE (rectangle doublé) qui est une entité "faible, dont le lien (trait continu) ou l'association (lozange doublé) identifiant à gauche se distingue du lien (trait discontinu) ou de l'association (lozange simple) non identifiant à droite.

II.1.4. Agrégations

 Les agrégations sont des associations ou liens particuliers ayant la sémantique "composé-composant".

La suppression d'un "composé" peut ou non entrainer celle des "composants" ("pièces détachées" irrécupérables ou récupérables!). Réciproquement la suppression d'un "composant" peut ou non entrainer la suppression du "composé" (une voiture sans roue ne change pas d'identité, une voiture avec un nouveau chassis est une autre voiture...). La notation ER classique était insuffisante pour rendre compte de ces surcharges sémantiques. La notation UML en rend compte assez précisement comme illustré ci-dessous


 

II.1.5. Généralisation et spécialisation

C'est le couple de concepts le plus important pour enrichir le modèle ER. C'est un des concepts fondamentaux de l'approche orientée objet. Entre une classe, par exemple d'Employés, et une classe plus générale, par exemple de Personnes, le lien ou l'association est du type "EST-UN" (IS-A in english) : un Employé est une Personne. Même si les individus de la classe spécialisée (Employés) peuvent avoir une identification locale à cette sous-classe, il est entendu qu'ils peuvent d'abord être identifié en tant qu'individus de la super-classe (Personnes). Plus généralement un individu d'une sous-classe "hérite" de tous les attributs de la super-classe. Le lien réciproque de la généralisation est la spécialisation. Selon que les sous-classes d'une même classe forment ou non une partition de cette classe, on dit que la spécialisation est complète ou non. Différentes classes se généralisant dans une classe par l'opération d'union sont appelées des "catégories" pour cette classe. Les notations varient un peu entre les modèles ERC, .., OMT, UML. Le principal changement est apparu entre l'ER classique qui dessinait autant d'associations que de liens "Est-un" et les modèles suivants qui ont cré un nouveau symbole pour un noeud arborescent liant une super-classe à plusieurs sous-classes.

II.1.6. Autres concepts

 Il est très vite apparu nécessaire d'ajouter des contraintes à une association, comme, par exemple pour une association parent-enfant, d'ordonner les individus liés, ou des contraintes entre associations, comme, par exemple une contrainte d'exclusion pour le couple d'associations "défendu_par" et "accusé_par", ou, pour les associations de type "Est-un", une contrainte de partitionnement éventuel. Le fait que toute association peut ou non créer une association inverse (affirmer qu'un père "connait" ses enfants, ce n'est pas automatiquement affirmer que chaque enfant "connait" son père...) est aussi une surcharge que les modèles ajoutent souvent. D'autres concepts, comme celui de "qualificatif" (dans le modèle UML) ou celui d' "assertion" (dans l'ERC) ont aussi été ajoutés pour représenter d'autres contraintes que celles évoquées ci-dessus. Tous les modèles actuellement utilisés buttent sur l'infinie richesse du langage naturel pour l'expression des contraintes...


(NDLR. la fin de ce chapitre n'a qu'un intérêt historique et pédagogique. On peut aller directement à la conclusion)

II.2. Le modèle hiérarchique

Longtemps considéré comme le seul modèle permettant aux SGBD d'atteindre les performances exigées en production, le modèle hiérarchique possède effectivement la capacité de traiter rapidement des informations organisées sous la forme d'une hiérarchie stricte mais, par contre, interdit tout autre type de représentation, limitant ainsi considérablement la puissance d'expression du modèle. Le SGBD le plus connu dans cette catégorie est IMS, produit ancien de IBM, très répandu dans les applications de production.

II.2.1. Les objets du modèle

 Les concepts de base du modèle sont le champ, plus petite unité de données possédant un nom, et l'article Définition : article suite de champs, portant un nom et constituant l'unité d'échange entre la base de données et les applications. Les articles sont reliés entre eux par des liens hiérarchiques : à un article père correspondent N articles fils. La notion de type d'article qui désigne le schéma d'un article (description du contenant) se distingue ici de celle d'occurrences d'article qui représentent les différentes valeurs stockées de la base. Définition : arbre d'articles collection d'articles reliés par des associations père-enfants organisées sous forme d'une hiérarchie. Une base de données hiérarchique est une base constituée d'une forêt d'articles.

On peut formuler quelques remarques sur la structure hiérarchique :

- il y a un seul type article racine ;
- la racine peut avoir un nombre quelconque de types d'article enfant ;
- chaque type d'article enfant de la racine peut avoir un nombre quelconque de types d'article enfant, et ainsi de suite ;
- à une occurrence d'un type d'article donné, peuvent correspondre 0, 1 ou N occurrences de chaque type d'article enfant ;
- une occurrence d'article enfant ne peut exister sans l'occurrence d'un article père. Détruire une occurrence d'article père, détruit par conséquent également toutes les occurrences de ses enfants. Exemple : représentation hiérarchique d'une base de baigneurs
 



Dans cet exemple, POLLUTION représente différentes mesures de pollution. Pour exprimer qu'une baignade a eu lieu sur une plage et a été le fait d'un nageur, il a fallu dupliquer l'attribut "nom de plage" (NOMP). En fait, dans certains systèmes hiérarchiques, cette duplication est simplement logique (pas de duplication physique) : la valeur de NOMP n'est présente que dans une des deux hiérarchies, l'autre comportant un simple pointeur sur la valeur.

II.2.2. Langage de manipulation de données

Le principe de la manipulation d'une base hiérarchique (nous prenons ici l'exemple de DL1 de IBM) consiste à parcourir en profondeur d'une structure arborescente : on part de la racine et on visite successivement tous les fils depuis le fils gauche jusqu'au droit.

Dans notre exemple, les Ri sont des occurrences de régions, les Paii des occurrences de plage, les Piii des occurrences de mesures de pollution.
 


DL1 utilise des curseurs permettant de mémoriser différentes positions sur la base de données. A un accès en recherche, est associée une qualification de chemin constituée de différentes qualifications d'articles, connectées par des ET ou des OU logiques, et formant des critères élémentaires <nom_de_champ comparateur valeur>. Ces qualifications sont déclarées préalablement et invoquées ensuite par les programmes qui utilisent des opérations GET UNIQUE (GU, permet de rechercher la première occurrence satisfaisant la qualification), des opérations GET NEXT (GN, recherche l'occurrence suivante), des GET NEXT WITHIN PARENT (GNP, idem GN, mais uniquement parmi des descendants du parent courant), etc.

II.2.3. Actualité du modèle hierarchique

 Si l'on considère la représentation traditionnelle des occurences d'articles sous forme de "fiches", on s'aperçoit que toute solution au problème du placement physique d'un ensemble de fiches de différents types est un partitionnement de cet ensemble suivant une hiérarchie choisie sur ces types. Un exemple intéressant est celui des fiches de type "Management Information Base" (MIB) associées à chaque noeud d'un réseau gérable par le "Simple Network Management Protocol" (SNMP). Le langage associé a de nombreux points de ressemblance avec les langages de parcours des bases de données hierarchiques tels que DL1.

II.3. Le modèle réseau

Ce modèle a été introduit en 1961 par BACHMAN. Il propose une utilisation de structures de listes afin de relier sémantiquement des entités. Il permet ainsi une meilleure représentation de la réalité que le modèle hierarchique. Un des intérêts du modèle fut l'existence d'une proposition de normalisation émise par le groupe DBTG (Data Base Task Group) du Comité CODASYL (COnference on DAta SYstem Language). On parle ainsi souvent de modèle CODASYL pour les systèmes réseaux qui suivent ces recommandations. Deux niveaux de recommandations ont été émis : l'un, en 1971, conseillait la séparation d'un niveau de schéma externe et d'un niveau de schéma interne/conceptuel ; le second, en 1978, préconisait les trois niveaux de schéma -interne, conceptuel, externe-. Seul le premier niveau de recommandations a été réellement suivi par les produits. En 1978, il était déjà tard pour voir les produits prendre en compte ces recommandations : l'heure du relationnel avait déjà sonné pour les investissements à long terme ; quasiment aucun SGBD réseau réellement nouveau n'a été conçu depuis cette date. Mais à l'heure où les SGBD relationnels sont à leur tour défiés par les nouveaux SGBD orientés objets, il est encore intéressant de comprendre ce que les SGBD réseau avaient apporté de plus novateur : l'expression des requêtes sur les données dans une logique de chemin (c.à.d. de navigation ). Parmi les SGBD construits selon ce modèle, encore largement utilisés, on peut citer IDS2 chez BULL, IDMS de CULLINET, TOTAL de CINCOM, SOCRATE .

II.3.1. Description des objets et des associations

 Les objets modélisés dans la base de données sont déclarés comme des articles. Définition  : article un champ est la plus petite unité de données possédant un nom;

un agrégat est une collection de champs rangés consécutivement et possédant un nom;

un article est une collection d'agrégats et de champs rangés côte à côte dans la base; il constitue l'unité d'échange entre la base et les applications.
 

Définition : ensemble l'association entre un article appelé propriétaire et N articles membres de même type constitue un ensemble (SET). Le type ensemble ainsi constitué porte un nom ; un type ensemble permet d'associer un type d'article propriétaire à un type d'article membre.

Il ne reste plus qu'à définir une base de données réseau :

Définition : base de données réseau Une base de données réseau est composée d'articles reliés entre eux par des ensembles. La description de la structure des données d'une base réseau utilise un langage de description du schéma des données. Cette déclaration constitue la création de la structure vide de la base, en décrivant les articles et les associations entre articles formant des ensembles.

Le schéma d'une base de données réseau se représente par un graphe des types, parfois appelé diagramme de BACHMAN.

Définition : graphe des types une base de données réseau se représente à l'aide d'un graphe des types où :

- les sommets représentent les types d'articles ;
- les arcs représentent les types d'ensembles.

Chaque sommet est valué par le nom du type d'article associé ; chaque arc est valué par le nom du type d'ensemble qu'il représente ; chaque arc est orienté du type propriétaire vers le type membre.

Exemple :

déclaration d'un schéma réseau d'une base de baigneurs, dans le langage de définition de données CODASYL
  RECORD NAME IS NAGEUR 02 NN TYPE IS FIXED BIN 3
02 NOM TYPE IS CHAR 15
02 PRENOM TYPE IS CHAR 15
02 QUALITE TYPE IS CHAR 10 RECORD NAME IS PLAGE 02 NP TYPE IS FIXED BIN 3
02 NOMP TYPE IS CHAR 20
02 TYPE TYPE IS CHAR 10
02 REGION TYPE IS CHAR 20
02 POLLUTION TYPE IS CHAR 10


RECORD NAME IS BAIGNADE

02 DATE TYPE IS CHAR 6
02 DURÉE TYPE IS DEC 3


SET NAME IS BAIN

OWNER IS NAGEUR
MEMBER IS BAIGNADE


SET NAME IS LIEU

OWNER IS PLAGE MEMBER IS BAIGNADE Le graphe des types correspondant à cette déclaration est le suivant :
Pour bien voir la notion d'ensemble, on peut montrer une représentation du graphe au niveau des occurrences : ici, nous avons représenté deux occurrences d'ensemble de type BAIN (Dupond qui prend deux bains de 20 et 15 minutes, et Durand qui prend un bain de 5 minutes), deux occurrences d'ensemble de type LIEU (à Trégastel sont pris les bains de 20 minutes et de 5 minutes, à Nice est pris le bain de 15 minutes). Un ensemble de pointeurs existe pour chaque occurrence d'ensemble et lie les membres à leur propriétaire.
Cette approche impose deux limitations : (i) un type d'article ne peut être à la fois propriétaire et membre dans un même ensemble ; (ii) une occurrence d'article ne peut appartenir à plusieurs occurrences du même ensemble (pour des raisons physiques). Remarque 1: Une association ne peut relier que deux types d'articles différents. La configuration suivante est, par exemple, impossible :
La solution est de créer deux types d'article : un type "pièce composante", un type "pièce composée"
Cependant, dans certains cas, une pièce est à la fois pièce composée et pièce composante ; par exemple :
Faire figurer le moteur en pièce composée et en pièce composante constitue une assez mauvaise solution : cela créer une redondance. Remarque 2 : Le modèle impose d'autre part qu'une occurrence d'article n'appartienne qu'à une seule occurrence d'un même type d'ensemble. Ainsi la configuration suivante est impossible :
En effet chaque article est déclaré appartenir à un type d'ensemble (comme propriétaire ou comme membre) ; pour ce type d'ensemble, l'article se voit adjoindre un ensemble de pointeurs lui permettant de se positionner dans ce type d'ensemble. Il ne peut donc appartenir qu'à une seule occurrence de ce type d'ensemble car un seul jeu de pointeurs est prévu par type d'ensemble d'appartenance.

II.3.2. Types d'informations d'un schéma CODASYL

 Comme nous l'avons dit en introduction, le modèle réseau ne sépare pas clairement la description conceptuelle et la description interne du schéma. En fait, en plus de la structure déjà décrite par les clauses RECORD NAME, SET NAME, OWNER, MEMBER, le schéma CODASYL contraint l'administrateur à préciser l'organisation physique - fichiers AREAS - et la description des chemins d'accès - clés, références - qui seront utilisés.

Les modes de placement d'une base CODASYL sont assez particuliers et ne seront pas précisés ici Le chapitre 7 du polycopié présente des méthodes de placement générales et des développements sur le hachage.

II.3.3. Schéma et sous-schéma CODASYL

 La déclaration d'un schéma, qui crée la structure vide, est donc préalable à toute action et manipulation d'articles de la base de données. Très statique, cette caractéristique du modèle impose que toute modification du schéma ne s'effectue que sur une base vide : ainsi une évolution du schéma entraîne un déchargement , puis un rechargement complet de la base.

On s'affranchit cependant en partie de cette dépendance en déclarant un sous-schéma qui, en CODASYL, correspond à la notion de schéma externe. Un sous-schéma est le sous-ensemble du schéma vu par un programme d'application. Le sous-schéma permet de redéfinir l'ordre, les noms, les caractéristiques des articles. Recomposer une vision différente de la structure de la base n'est cependant pas possible (comme ce sera possible en relationnel, voir le chapitre 6).

Ordonnancement des articles dans un ensemble

La déclaration de chaque ensemble, précise l'ordre dans lequel les articles membres insérés dans une occurrence d'ensemble. Ainsi la clause

ORDER IS PERMANENT
INSERTION IS {FIRST | LAST | PRIOR | SORTED BY DEFINED KEY}
[KEY IS nom-de-donnée] accompagne la déclaration d'un type d'ensemble, pour préciser la position d'insertion des occurrences d'articles membres dans une occurrence d'ensemble de ce type. L'insertion s'effectue en première position (FIRST), en dernière position (LAST) ou par rapport au pointeur courant (PRIOR ou NEXT). Dans le cas où l'on désire qu'un ordre soit maintenu sur l'ensemble (SORTED BY DEFINED KEY), on ajoute la clause KEY IS nom-de-donnée.

Point d'entrée dans une occurrence d'ensemble

Pour chaque type d'ensemble, on précise dans le schéma comment seront accédés les articles de l'ensemble. Il existe deux possibilités :

- en fournissant la DBK du propriétaire de l'occurrence d'ensemble ; la clé sera alors un paramètre des programmes qui effectueront les accès. La clause du schéma est :

SET SELECTION IS THRU nom-d'ensemble OWNER IDENTIFIED BY CALC KEY

- par application, ce qui signifie que le propriétaire pur un ensemble aura été repéré préalablement à une intervention sur un des membres. Dans ce cas, les accès aux membres seront toujours effectués par la navigation (voir § II.2.4) exprimée dans le programme d'application. La clause est dans ce cas :

SET SELECTION IS TRHU nom-d'ensemble OWNER IDENTIFIED BY APPLICATION

Exemple de schéma de placement

On donne ici un exemple de déclaration du schéma de placement d'une base de baigneurs à quatre types d'articles (REGION, PLAGE, BAIGNADE, NAGEUR) et trois types d'ensembles (LOCALISATION, BAIN, LIEU).

Plutôt que de donner une écriture déclarative du schéma, nous illustrons l'organisation dans trois fichiers différents : F_PLA, F_NAGEUR et F_BAIGNADE. Les articles de type RÉGION sont placés par hachage sur un numéro de région (NR) dans un fichier F_PLA (la clause LOCATION MODE IS CALC USING NR WITHIN F_PLA est explicitée lors de la déclaration du type RÉGION). Les articles de type PLAGE sont placés par proximité dans ce même fichier (LOCATION MODE IS VIA LOCALISATION WITHIN AREA OF OWNER). Les articles de type NAGEUR sont stockés dans un fichier NAGEUR par un hachage sur le nom de nageur NOM (clause LOCATION MODE IS CALC USING NOM WITHIN NAGEUR associée à la déclaration du type NAGEUR). Enfin, les articles de type BAIGNADE sont placés dans un fichier F_BAIGNADE qui leur est propre, mais avec une organisation par homothétie qui les range en fonction des valeurs des nageurs ayant effectué ces baignades (clause LOCATION MODE IS VIA BAIN WITHIN F_BAIGNADE). Cette organisation favorise évidemment les questions qui évoquent, par exemple, les baignades de "Dupond", au détriment des questions recherchant les baignades ayant eu lieu sur la plage de "Quiberon".
 


II.3.4. La navigation CODASYL

 La nature du langage de manipulation de données dans un système réseau est largement déterminée par la structure physique des informations. Pour accéder à une information, il faut préciser le chemin utilisé pour atteindre cette information. Le langage indique un chemin de pointeurs à suivre. On parle ainsi de langage navigationnel, l'idée étant de naviguer dans la base de données par une succession de déplacements. A un instant donné, on occupe une position précise dans la base.

Ce type de manipulation impose un accès par programmes. Une utilisation interactive n'est guère envisageable avec un SGBD réseau : elle s'avérerait en effet beaucoup trop lourde. Ce n'est qu'avec l'apparition de modèle relationnel que les langages de manipulation de données deviendront réellement interactifs.

Une fois un schéma et un sous-schéma définis, les programmes d'application peuvent invoquer le SGBD à l'aide de verbes-clés du langage de manipulation. Ces verbes sont en général inclus dans un programme COBOL (ou PL1, Pascal, C…). Il sont de quatre types :

- la recherche d'articles : FIND ;
- les échanges d'articles entre programmes d'application et SGBD : GET et STORE ;
- les mises à jour : ERASE, MODIFY, CONNECT, DISCONNECT ;
- le contrôle : READY, FINISH. La recherche d'article (FIND) qui consiste à positionner le curseur courant sur un article particulier, se distingue des échanges (GET et STORE) qui utilisent un tampon pour charger ou récupérer un article. La notion de curseur est donc très importante dans ce modèle. Définition : curseur pointeur courant contenant la clé-base-de-données (DBK) du dernier article manipulé dans une collection d'articles, qui permet à un programme de se déplacer dans la base. Afin de faciliter les déplacements, un programme qui s'exécute dispose de plusieurs curseurs (en fait de plusieurs positions courantes) dans des ensembles différents: - un curseur dans chaque type de fichier référencé ;
- un curseur dans chaque type d'ensemble référencé ;
- un curseur dans chaque type d'article référencé ;
- un curseur courant sur le dernier article lu. Un FIND particulier précise la position des curseurs. Cependant les échanges d'articles s'effectuent uniquement sur l'article pointé par le curseur courant.

L'accès à un fichier (positionnement du curseur de fichier) s'obtient par la clause :

FIND { FIRST | LAST | NEXT | PRIOR | Ième } nom-d'article WITHIN nom-de-fichier De la même façon, l'accès par un ensemble sera demandé par : FIND { FIRST | LAST | NEXT | PRIOR | Ième } nom--d'article WITHIN nom-d'ensemble Se positionner sur le propriétaire de l'occurrence d'ensemble courante est également possible : FIND OWNER WITHIN nom-d'ensemble Enfin, une recherche sur clé est possible en connaissant la Clé-Base-de-Données : FIND nom-d'article DB-KEY IS paramètre Exemple

Quelles sont les plages où se sont baignés d'excellents nageurs pendant le mois d'août 89 ?

READY F_baignade, F_nageur
FIND FIRST nageur WITHIN F_nageur
PERFORM UNTIL fin-de-fichier GET nageur
IF qualité IN nageur = 'excellent' FIND FIRST baignade WITHIN bain
PERFORM UNTIL fin-de l'ensemble GET baignade
IF date BETWEEN 01/01/89 AND 31/08/89 FIND OWNER WITHIN lieu
GET plage
PRINT NOMP END_IF
FIND NEXT baignade END_PERFORM END_IF
FIND NEXT nageur WITHIN F_nageur END_PERFORM
FINISH F_plage, F_baignade, F_nageur. Remarquez que différentes méthodes permettent de répondre à la question posée ; on aurait très bien pu rentrer dans le fichier F_plage par les plages, et aller voir, pour chacune des baignades de chacune de ces plages, s'il ne s'agissait pas d'un excellent nageur.

La formulation de la question n'est pas plus compliquée ; le lecteur réfléchira cependant au coût potentiel de cette seconde exécution…  Il s'agit là d'un problème inhérent aux langages navigationnels, où toute la responsabilité des performances pèse sur le programmeur. Dans les systèmes relationnels, cette responsabilité sera, nous le verrons, confiée au système.

II.4. Conclusions

La modèles pour produire des schémas de bases de données ont suivi deux histoires parallèles: les modèles de définition conceptuelle , qui cherchent la plus grande richesse sémantique plus que la facilité d'implémentation sur un SGBD, ont suivi une voie propre depuis l'ER de Chen; les modèles d'implémentation logique, liés aux structures de stockage et aux langages de manipulation des SGBD, ont connu une histoire faite de continuités et de ruptures (environ tous les 10 ans) du modèle hierarchique au modèle objet, fortement contrainte par les phénomènes de diffusion et de parc installé. A l'heure de la "convergence relationnel-objet" (et du SQL3) on se plait à espérer une "convergence logique-conceptuel".

II.5. Références

[Bachman 73] C. W. BACHMAN : "The Programmer as Navigator", Communications of the ACM, Vol 16, N°11, Novembre. 1973.

[Chen 76] P. P. CHEN : "The Entity-Relationship Model - Towards a Unified View of Data", ACM, Vol 1, N°1, Mars. 1976.

[CODASYL 71] CODASYL DATA BASE TASK GROUP : "Report", Avril 1971, ACM, New-York.

[CODASYL 78] CODASYL Programming Language Committee "COBOL Journal of Development", 1978.

[Parent et S. 85] C. PARENT, S. SPACCAPIETRA : "An algebra for a general Entity-Relationship model", IEEE, Transactions on Software Engineering, July 1985.

[RFC 1066 et 1213] "Management Information Base for Network Management of TCP/IP-based internets".

[Rumbaugh et al. 91] J. RUMBAUGH, M. BLAHA, W. PREMERLANI, F. EDDY et W. LORENSON : "Object-Oriented Modeling and Design", Prentice Hall, Englewood Cliffs, NJ, 1991.

[UML 97] http://www.omg.org/docs/doclist-97.html, "UML1.1 (OMG)", 1997.

Chapitre 3