partie 2 modèle et application - insa lyon
TRANSCRIPT
Partie 2 / Modèle et Application
Partie 2
Modèle et Application
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 79 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Chapitre 4
Modélisation des données
« Un problème sans solution est un problème mal posé »
Albert Einstein
Résumé du chapitre : Ce chapitre présente la définition d’un modèle basé sur une
double modélisation qui va nous permettre de représenter les documents, leurs liens
et les versions avec une granularité fine (c'est-à-dire une représentation au niveau
élément du document). Autour d’une étude de cas, nous aborderons la gestion de la
cohérence des documents tout au long de leur cycle de vie.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 80 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Table des matières
1 INTRODUCTION _______________________________________________ 81
1.1 DEFINITION DE L'INTEGRITE DOCUMENTAIRE _______________________________82
2 CONTEXTE ET PROBLEMATIQUE__________________________________ 83
2.1 PRESENTATION DU CHAPITRE (SCENARIO) __________________________________85
2.2 IMPLICATION de la documentation technique dans le processus de production _____86
2.3 PROPOSITION _______________________________________________________89
2.4 CLASIFICATION DE LIENS ______________________________________________90
2.4.1 Lien de référence (nommé aussi simple) ______________________________91
2.4.2 Lien de partage d'information (ou de connaissances)____________________92
2.4.3 Lien de composition _______________________________________________97
3 MODELE DE DONNEES POUR LA GESTION DE LIENS _______________ 98
3.1 DIMENSION STRUCTURE _______________________________________________98
3.2 GESTION DES VERSIONS ______________________________________________100
3.2.1 Versions des fragments ___________________________________________102
3.2.2 Incidences des mises à jour ________________________________________103
3.2.3 Instanciation du modèle de données _________________________________104
3.3 ACTEURS __________________________________________________________106
3.4 FORMALISATION DU MODELE __________________________________________107
3.4.1 Formalisation des documents ______________________________________107
3.4.2 Formalisation des liens____________________________________________109
3.4.3 Versions des liens ________________________________________________109
3.5 DESCRIPTION DES CLASSES DU MODELE ________________________________111
4 CONCLUSION ______________________________________________ 114
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 81 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
1 Introduction
Comme dit auparavant, dans le monde de l’entreprise, chaque processus majeur de
l’entreprise est un processus conduit ou supporté par des documents techniques;
comme le processus de production d’un produit industriel. En rationalisant les pro-
cessus de création, validation, gestion et distribution de documents, les entreprises
peuvent réduire d’une manière importante les procédures commerciales, raccourcir
les délais de mise sur le marché, améliorer la qualité des produits.
Il est incontestable, que la documentation technique joue un rôle clé dans les
étapes du cycle de vie d'un produit en tant qu’entrée, et support dans ce processus de
production, depuis l'étape de conception jusqu’au moment où le produit est terminé.
Elle est donc le reflet des connaissances du domaine, connaissances permettant
l’exécution des tâches courantes de l’activité concernée. La documentation technique
est rencontrée sous une grande diversité de formes :
les guides donnant des consignes pour l’exécution de telle ou telle tâche
les manuels décrivant un système
les manuels techniques et les manuels d'opération pour les utilisateurs
les manuels de spécifications, de fabrication et de la maintenance pour
les ingénieurs
des informations de gestion de production
des procédures, le cahier de charges, etc.
Cet ensemble de documents est relatif à un domaine donné et sert comme
instrument de travail pour une activité bien déterminée. Dans notre travail de recher-
che, cette activité est considérée comme un métier d’ingénierie où il s’agit, par exem-
ple, de supporter toutes les étapes du cycle de vie d’élaboration d’un produit. Cette
activité doit être supportée par un Système de Gestion Électroniques de Documents
(Systèmes de GED), dont l’objectif est d’assurer toutes les fonctionnalités dans la
chaîne documentaire : depuis leur création jusqu’à leur archivage, en passant par les
étapes de révision, d'approbation et diffusion [Amghar97]. La gestion des documents
est une des préoccupations majeures de toute entreprise.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 82 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Les nouvelles générations d’applications basées sur des environnements X-
Net (Intranet et Extranet), telles que les applications Workflow, Groupware et plus
précisément les Systèmes de GED occupent de plus en plus de places stratégiques, ils
nécessitent :
des plates-formes plus complexes (haute performance et haute qualité)
qui fournissent des outils qui soient capables de gérer les insuffisances
des Systèmes de GED.
des modèles de données qui permettent extension et généralisation.
la prise en compte de la gestion globale de la cohérence qui, à notre
point de vue, constitue une caractéristique fondamentale de ces systèmes
et n'est traitée que partiellement dans la plupart des systèmes existants.
1.1 Définition de l'intégrité documentaire
Nous pouvons formuler une définition de l'intégrité d'un document comme suit :
I ) « L'intégrité d'un document est assurée lorsqu'il y a la possibilité de véri-
fier que l'information n'en est pas altérée et qu'elle est maintenue dans
son intégralité. De plus, il faut que le support portant l'information pro-
cure à celle-ci la stabilité et la pérennité voulue. Il ne faut pas que l'in-
formation soit susceptible de disparaître ou d'être modifiée sans que l'on
puisse s'en apercevoir ».
II ) « L'intégrité d'un document vis-à-vis des liens est assurée lorsque tous les
liens sont cohérents ».
Ces définitions vont nous permettre de poser la problématique de notre re-
cherche. En effet, nous cherchons à élaborer une solution de gestion de la cohérence
des liens Inter & Intra documents en vue d'améliorer les processus de workflow dans
le contexte de suivi du cycle de vie d'un produit manufacturé.
Dans la section suivante intitulée contexte et problématique, nous aborderons
deux approches qui interviennent dans le processus de production de documents élec-
troniques : l'approche Workflow et l'approche Cycle de vie du produit. Nonobstant
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 83 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
ces deux approches accentuent la complexité pour contrôler et gérer la gestion de
liens Inter & Intradocuments.
2 Contexte et Problématique
La nécessité pour les entreprises de dépasser le cadre local ou national entraîne de
nouvelles organisations de travail où l'aspect géographique n’est plus un paramètre
déterminant pour faire fonctionner des équipes autour d’un projet. Les outils de
Workflow et de Groupware deviennent dans ce contexte incontournables pour
l’aboutissement des projets. A côté de ces outils, la GED joue un rôle prépondérant
proportionnel à la complexité et au volume important de la documentation technique
avec :
Des manuels d'opération, de spécifications, de fabrication, de la mainte-
nance.
Des manuels techniques pour les utilisateurs, des documents
d’ingénierie, des informations de gestion de production et enfin des bre-
vets, des procédures, le cahier de charges, etc.
Le processus de production de documents est ainsi supporté par le Système
de Gestion Électronique Documentaire (Systèmes de GED) le plus souvent dans des
environnements Inter & IntraNet. L’objectif d’une GED est d’assurer toutes les fonc-
tionnalités dans la chaîne documentaire : depuis la création jusqu'à l'archivage, en
passant par la révision, l'approbation et la diffusion.
La figure 4-1 schématise l'interaction et/ou l'interrelation de l'ensemble du
processus entre les différents Serveurs de GED et les processus Workflow de l'entre-
prise pour la conception d'un produit manufacturé.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 84 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Serveur de documents A
Système de GED
Client Browser
Base de documents, audio, vidéo
Internet
Client BrowserBase de
documents
Clients Browser
I n t r a n e t
Serveur de documents B
Système de GED
Base de documents, audio, vidéo
Serveur de documents C
Système de GED
Base de documents, audio, vidéo
PC PC
Liens Inter et Intra documentsLiens Inter et Intra documentsLiens Inter et Intra documents
Serveur Web de documents
Processus de Workflow
Ingén
ierie
Docu
men
taire
Création Révision Approbation ArchivageDiffusion
Cycle de vie du documentconception fabrication
contrôle de qualité
maintenance
PC
Serveur de documents A
Système de GED
Client Browser
Base de documents, audio, vidéo
Internet
Client BrowserBase de
documents
Clients Browser
I n t r a n e t
Serveur de documents B
Système de GED
Base de documents, audio, vidéo
Serveur de documents C
Système de GED
Base de documents, audio, vidéo
PC PC
Liens Inter et Intra documentsLiens Inter et Intra documentsLiens Inter et Intra documents
Serveur Web de documents
Processus de Workflow
Ingén
ierie
Docu
men
taire
Création Révision Approbation ArchivageDiffusion
Cycle de vie du documentconception fabrication
contrôle de qualité
maintenance
PC
Figure 4-1 Ensemble de processus liés à la gestion de la cohérence des liens Inter
& Intra documents.
Mettons en évidence la complexité que représente l’action de gérer de façon
efficace l'ensemble des documents et des liens repartis sur de Serveurs de GED. Cette
complexité est due à :
la diversité des médias contenus dans les documents (tels que l'audio, la
vidéo, l'hypertexte, les hyperliens, etc.)
les différents types d'hyperliens et/ou liens hypertextuels (par exemple :
liens de référence, de partage d'information et de composition)
au volume des données.
Par ailleurs, l'ensemble des documents structurés est lié par des liens hyper-
textuels. Il est cependant inévitable que ces documents ainsi que leur contenu (texte,
liens, images, etc.) soient exposés aux modifications effectuées par un auteur ou un
groupe d’auteurs. Lorsque ces manipulations sont achevées, il existe un risque poten-
tiel d’altérer ou détruire l’intégrité de la base documentaire et du document même.
Cette répercussion peut avoir un impact en chaîne sur les autres activités ou tâches,
par exemple : dans un processus workflow (le cycle de vie d'un produit manufacturé)
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 85 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
ou dans le processus de l'ingénierie documentaire comme par exemple le cas du cycle
de vie d’un document.
2.1 Présentation du chapitre (scénario)
Imaginons un fabricant de produits électroniques grand public dans le domaine de la
téléphonie mobile (téléphones mobiles, chargeurs, etc.) La compagnie a décidé de
s’étendre en créant un nouveau secteur commercial et un nouveau produit pour le
marché canadien. Concernant les données du produit, deux grandes catégories
d’informations peuvent être distinguées :
1. Les informations qui décrivent les produits de l’entreprise aux différentes
phases de leur cycle de vie. Un manuel d'inspection qui décrit les caracté-
ristiques techniques (volume, mesure, aspect physique, etc.) dans certains
phases du cycle de vie du produit.
2. Les informations qui se réfèrent aux composants préexistants, qui sont uti-
lisés pour concevoir, fabriquer ou maintenir les produits de l’entreprise,
c'est-à-dire les guides d'opération et/ou maintenance qui décrivent les ca-
ractéristique physiques et techniques de la matière première.
Ces types de données possèdent des points en commun (par exemple : le fait
qu’ils décrivent), du point de vue de la modélisation, ils se caractérisent par deux as-
pects :
L’origine de l’information : l’information sur les produits de l’entreprise
est créée dans l’entreprise elle-même. La description et la connaissance
sur les composants proviennent de leurs fournisseurs. Un échange entre
fournisseurs et utilisateurs de composants augmenterait la disponibilité
et la précision de l’information.
La structure de l’information : chaque produit réalisé par l’entreprise est
individuellement, explicitement et exhaustivement représenté pour per-
mettre sa fabrication.
Cependant, ces types de données nécessitent à leur tour, la définition d’un
modèle pour les représenter, gérer et exploiter. (C.f. Section 3).
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 86 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
La production actuelle des téléphones mobiles et de leur documentation est
basée sur les normes de réseau GSM900 et GSM1800 bien spécifiques pour la com-
munauté européenne (CE). En revanche, il faut savoir que pour pénétrer le marché
canadien on doit respecter deux normes : la norme IDEN et la norme PCS 1900. Pour
l'orient on peut citer la norme CDMA.
2.2 Implication de la documentation technique dans le processus de production
La compagnie se voit obligée de créer des annexes techniques et de remettre en
production des éléments de sa documentation technique afin de les adapter aux
normes utilisées pour le marché canadien : la norme IDEN et la norme PCS1900.
Dans cette perspective, distinguons la création de deux documents, un pour chaque
norme respectivement.
Nous considérons dans ce scénario d’utilisation, le domaine de la
documentation technique pour illustrer notre proposition. La documentation
technique traverse différents processus impliqués dans la production d’un produit.
Elle peut être définie de la façon suivante :
« Un document technique qui explique comment utiliser, maintenir et
manipuler un produit depuis sa mise à création jusqu’à sa livraison, et
qui fournit en outre une information technique dont l’utilisateur a be-
soin pendant le cycle de vie du produit ». (C.f. figure 4.2). [AA03],
[AACH02b].
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 87 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Fabrication Contrôle de qualité
Acquisition(achat)
Maintenance(service
après vente)
début processus Livraison
client
Conception (CAO)
(1, 2) ( 2 ) (3, 4)
(5)(6)(1,7)
(1) manuel des spécifications techniques
(2) manuel de fabrication(3) manuel d’inspection(4) ISO 9000(5) procédure ventes, facture(6) garantie, manuel d’opération(7) manuel de maintenance
fin du processus
Documentation technique
Étapes de processus de production d’un produit
Fabrication Contrôle de qualité
Acquisition(achat)
Maintenance(service
après vente)
début processus Livraison
client
Conception (CAO)
(1, 2) ( 2 ) (3, 4)
(5)(6)(1,7)
(1) manuel des spécifications techniques
(2) manuel de fabrication(3) manuel d’inspection(4) ISO 9000(5) procédure ventes, facture(6) garantie, manuel d’opération(7) manuel de maintenance
fin du processus
Documentation technique
Étapes de processus de production d’un produit
Figure 4-2 La documentation technique dans le processus de production d'un produit.
Voyons maintenant l’association (document – étape) du processus. Nous as-
socions à chaque type de document créé la phase qui lui est associée. Notons qu’un
document peut intervenir ou être impliqué à la fois sur une ou plusieurs phases. Par
exemple le manuel de spécification technique est utilisé dans la phase de conception,
la phase de fabrication et également dans la phase de maintenance.
Le tableau ci-dessous résume l’association «document – étape du processus»
de la documentation technique dans le processus de production d'un produit.
Document Processus de
l'entreprise Autre information attachée
Manuel des spécifications tech-niques
Conception, fabrication, maintenance
Dessins, diagrammes, images, maquettes, graphes, modèle CAO
Manuel de fabrication Fabrication Procédures, cahier des charges, schémas, organigrammes
Manuel d'inspection Manuel ISO9000,
Contrôle de qua-lité
Spécifications, plannings, procédures de stockage, de manipulation, procédures de mise en œuvre.
Manuel de maintenance Maintenance Gamme d'opération. Manuel de procédures d'acquisi-tion,
Acquisition (achat)
Procédures de ventes, facture, garantie.
Tableau 4-1 Implication de la documentation technique vers le processus de production
d'un produit.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 88 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
La documentation technique regroupe plusieurs familles de manuels que l'on
peut classer en trois grandes catégories :
1. Ceux qui décrivent la machine ou le matériel : notices techniques, ma-
nuels de référence, nomenclatures, etc.
2. Ceux qui servent à la formation des utilisateurs : manuels de formation et
d'utilisation, aide-mémoire des fonctions d'un logiciel, etc.
3. Ceux qui servent à la maintenance du matériel : manuels de maintenance,
catalogues de pièces, guide des procédures, cahiers d'incidents, rapports
d’anomalies, etc.
Retenons bien ici, que c’est grâce au mécanisme des liens hypertextuels, que
ces documents sont liés entre eux. Cela signifie qu'ils sont capables de véhiculer
toute ou une partie de l’information nécessaire aux différentes intervenants dans la
chaîne du processus d'élaboration d’un produit industriel. (C.f. figure 4-3). En
d’autres termes, un document et ses liens sont comme un chaînon dans le processus
d'élaboration du produit.
Lien 1 Lien 2
Lien 3Lien 4Lien 5Lien 6
Bureau d’études
Processus de production
Départementde fabrication
Départementcontrôle de qualité
Départementd’assemblage
Manipulations
Création Révision Approbation
Archivage Diffusion
Consultation
Système de GED
Manuel de fabrication
Manuel de fabrication
Manuel de maintenanceManuel de
maintenance
Manuel de maintenanceManuel de
maintenanceManuel
d’installationManuel
d’installationProcéduresProcédures
Manuel techniqueManuel
techniqueManuels ISO-
9000Manuels ISO-
9000Manuel de
spécificationsManuel de
spécifications
Lien 1 Lien 2
Lien 3Lien 4Lien 5Lien 6
Bureau d’études
Processus de production
Départementde fabrication
Départementcontrôle de qualité
Départementd’assemblage
Manipulations
Création Révision Approbation
Archivage Diffusion
Consultation
Système de GED
Manuel de fabrication
Manuel de fabrication
Manuel de maintenanceManuel de
maintenance
Manuel de maintenanceManuel de
maintenanceManuel
d’installationManuel
d’installationProcéduresProcédures
Manuel techniqueManuel
techniqueManuels ISO-
9000Manuels ISO-
9000Manuel de
spécificationsManuel de
spécifications
Figure 4-3 Mécanisme de liens dans le processus de production.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 89 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Il est cependant inévitable que ces documents ainsi que leur contenu (texte,
liens, images, etc.) soient exposés aux modifications par un auteur ou un groupe
d’auteurs. Lorsque ces manipulations sont achevées, il existe un risque potentiel
d’altérer ou de détruire l’intégrité de la base documentaire et du document même.
2.3 Proposition
La gestion de la cohérence d'une base documentaire dans des environnements Intra-
Net et ExtraNet, constitue une de nos préoccupations majeures, car c'est un problème
important dans le cas des Systèmes de Gestion Électronique Documentaires (Systè-
mes de GED).
Ces objectifs nous posent de nouvelles interrogations :
« Comment peut-on gérer conjointement la cohérence globale du do-
cument et la cohérence des différents composants du document tout au
long de leur cycle de vie ? »
Pour répondre à cette question, nous constatons que la cohérence globale
d'un document et de ses différents composants, résultent de la gestion intelligente de
deux niveaux de gestion : un premier niveau concerne l'ensemble entier du document
et un deuxième les éléments du document. Cela implique la définition d’un méca-
nisme actif, lequel va interagir entre ces deux niveaux de manipulation et les données
de la base. Bien entendu, un tel mécanisme suppose l'élaboration de règles permettant
de garantir automatiquement la cohérence de ces manipulations, donc la cohérence
des documents et de la base.
La gestion de la cohérence des documents et la définition du mécanisme actif
mettent en jeu deux aspects indispensables dans nos travaux de recherche :
L’aspect modélisation des données. La définition d’un modèle de données
pour la représentation des documents et la gestion de leurs versions.
L’aspect des règles actives. La définition d’un modèle de règles actives
pour assurer la gestion automatique de la cohérence des documents.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 90 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
2.4 Classification de liens
Comme nous l'avons signalé précédemment dans la introduction générale, la gestion
de la cohérence de la base documentaire, y compris les liens, est une de nos préoccu-
pations majeures et définit l'objet de l'un de nos objectifs. Avant citer les caractéristi-
ques de liens, nous considérons pertinent de donner une définition de lien hyper-
texte :
« Un lien hypertexte est une relation (interconnexion) entre différen-
tes parties d’un hypertexte et est souvent représenté par un bouton (un
graphique, une image, ou le classique mot souligné) qui lors de son
activation va afficher un nouveau fragment hypertexte. »
Remarquons que les liens constituent le principal moyen d’organiser un système hy-
pertexte. Ils permettent à l’utilisateur de se déplacer d’un endroit à un autre d’une
manière non séquentielle. Il existe différents types de liens :
Des liens simples ou de référence
Des liens étendus (bidirectionnels)
Des liens internes. Lorsque la cible est interne au document qui
contient le lien.
Des liens externes. Lorsque la cible est à l'extérieur du document qui
contient le lien.
La codification d'un lien (son point d'ancrage) s'effectue au niveau de l'ancre
source, en introduisant dans le contenu du document source du lien, la balise <A> ca-
ractérisée par l'attribut href selon la syntaxe suivante :
<A href= identifiant système de l'ancre cible> identifiant de l'ancre cible</A>
L'identifiant système de l'ancre cible correspond à l'URL (Uniform Resource
Locator) de la page cible, suivi éventuellement du caractère "#" et d'une séquence de
caractères correspondant à un identifiant local à cette page utilisé pour repérer une
partie du contenu. L'identifiant utilisateur de l'ancre est généralement une chaîne de
caractères à laquelle est associée une mise en forme particulière (exemple). Ceci per-
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 91 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
met au lecteur d'identifier la présence d'un lien activable pour l'atteindre et ainsi de
visualiser le contenu de l'ancre source.
Il est évident que de nombreux autres types de liens sont possibles (C.f. Sec-
tion 4, chapitre 1), Randall [Trigg83] dans la collaboration du projet Texnet. Néan-
moins, les types que nous abordons sont ceux les plus couramment rencontrés dans
les documents que nous étudions. Voyons, en détail ces liens :
2.4.1 Lien de référence (nommé aussi simple)
Un lien simple est défini par deux ancres : une ancre source et une ancre ci-
ble. Ce type de lien est un lien unidirectionnel qui associe exactement deux res-
sources. Cela signifie que les ancres peuvent être nommées ancre départ (pour la
source) et ancre d'arrivée (pour la cible). En d’autres termes, c’est une relation entre
deux points d'un lien : le point source (initial) et le point cible (final). Une ancre est
définie comme une extrémité d'un lien.
La figure 4-4, illustre ce type de lien et ses deux ancres respectivement.
Ancre départ(source)
Ancre d’arrivé(cible)
Fichier A Fichier A ou B
Ancre départ(source)
Ancre d’arrivé(cible)
Fichier A Fichier A ou B
Figure 4-4. Représentation d'un lien de référence
L'origine du lien est locale car elle est définie à l'intérieur même du lien (en-
tre ses balises). La cible du lien est distante car elle est située en dehors de celui-ci,
que ce soit dans le même document ou non. Ce type de lien est dit "en ligne" car il
possède une ressource locale, son origine.
Ce type de lien est en général introduit pour référencer d'autres informations
qui peuvent être des explications (définitions, illustrations, etc.) ou des expressions
réservées, comme par exemple "voir figure 2.3", "C.f. la section 2.1", "comme exposé
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 92 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
dans …". Le nombre d'expressions est hélas trop important pour permettre une détec-
tion automatique des liens de référence. Il semble donc plus prudent de demander
l'intervention de l'utilisateur afin de mettre ces liens en évidence.
La figure 4-5 illustre un exemple de lien simple qui pointe vers le fichier
alvarez.xml du site « LIRIS ».
URL du fichier index
http://liris.insa-lyon.fr/auteurs/alvarez.xml
Sens de la Navigation
Fichiers associés par le lien XML
<AUTEUR xmlns:xlink="http://www.w3.org/1999/xlink/namespace/" xlink:type="simple"xlink:href="http://liris.insa-lyon.fr/auteurs/alvarez.xml" xlink:title="l'auteur de cette page"> Abraham Alvarez
</AUTEUR>
Auteur: Abraham Alvarez
http://liris.insa-lyon.fr/auteurs/index.xml
Lien XML
Fichier AFichier B
URL du fichier BURL du fichier index
http://liris.insa-lyon.fr/auteurs/alvarez.xml
Sens de la Navigation
Fichiers associés par le lien XML
<AUTEUR xmlns:xlink="http://www.w3.org/1999/xlink/namespace/" xlink:type="simple"xlink:href="http://liris.insa-lyon.fr/auteurs/alvarez.xml" xlink:title="l'auteur de cette page"> Abraham Alvarez
</AUTEUR>
Auteur: Abraham Alvarez
http://liris.insa-lyon.fr/auteurs/index.xml
Lien XML
Fichier AFichier B
URL du fichier B
Figure 4-5. Représentation d'un lien simple
Les liens de XML ne se limitent pas aux liens simples comme le HTML. Ils
offrent la possibilité de liens étendus beaucoup plus puissants.
2.4.2 Lien de partage d'information (ou de connaissances)
Ce type de lien est représenté grâce à XML en lien étendu. Ce dernier est caractérisé
par sa double direction, c'est-à-dire type « bidirectionnel », étant donné que chaque
ancre est à la fois source et cible du lien.
Un lien de partage d'information permet de mettre en évidence que deux por-
tions de textes contiennent la même information, que ce soit partiellement ou totale-
ment. Un exemple est quand un document fait référence à des exemples d'un autre
document (par exemple, l'instruction "démonter la façade", renvoie à un autre docu-
ment qui détaille le démontage).
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 93 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
La figure 4-6 illustre le lien de référence et le lien de partage d'information
(partiel). On considère dans cette figure un manuel d'utilisation numéro 760112-A,
C'est celui qui correspond aux normes GSM900 et GSM1800, il comporte un premier
lien du type lien de référence, examinons que son ancre d’arrivée se dirige vers le do-
cument B. Un deuxième lien de partage partiel d'information associe un nombre res-
sources, ce lien peut donc être bi-directionnel du document A vers le document C et
vice-versa : dans cet exemple ces documents partageant le paragraphe 2 pour le do-
cument A et le paragraphe 1 pour le document C.
Manuel d'utilisation 760112-A
Le téléphone sans fil décrit dans ce manuel 760112-A, est agréé pour les réseaux GSM 900 et GSM 1800. C.f. la norme GSM 900. Le type de bande de votre téléphone mobile, est une fonctionnalité dépendant du réseau. Votre Nokia 2010 est de type "double bande". Vérifiez auprès de votre opérateur local s'il est possible de vous abonner à cette fonction et de l'utiliser.Voir aussi la norme DCS1800 de type tri-bandes avec une carte à puce intégrée ( SIM ). Classe de puissance - "Les classes de puissance qui existent actuellement sont les suivantes: classe 4 (2 Watt de puissance maximale) utilisée dans les terminaux GSM900 portables; classe 2 (8 Watt de puissance maximale) utilisée dans les terminaux GSM900 …
Norme GSM 900Plusieurs normes coexistent actuellement : GSM900, la plus connue et la plus ancienne, est utilisée par presque tous les opérateurs de portables en Europe. La norme DCS1800 est une évolution du GSM900 avec une meilleure qualitésonore et de nouveaux services. Le système PCS1900 est utilisé aux États-Unis et n'est pas compatible avec les systèmes européens. Il y a des téléphones dual-band et tri-band qui accumulent plusieurs systèmes. En France, la norme GSM900 est utilisée par SFR et France Telecom Mobiles.
Document A
Document C
Document BLien de référence (unidirectionnel)(de document A vers document B)
Carte SIM
Elle est insérée à l'intérieur du téléphone et existe sous deux formats: ISO/Standard (format CB) et PLUG IN (avec les dimensions d'un petit timbre). Il est possible d'utiliser un adaptateur qui permet d'insérer les cartes PLUG-IN dans les appareils qui acceptent les cartes au format ISO.
Carte SIM - La carte SIM contient les informations relatives à l'abonnement au réseau GSM.Lien de partage d’information
partiel (bidirectionnel)Le document A et le document C partagent un paragraphe
Lien de référence
Manuel d'utilisation 760112-A
Le téléphone sans fil décrit dans ce manuel 760112-A, est agréé pour les réseaux GSM 900 et GSM 1800. C.f. la norme GSM 900. Le type de bande de votre téléphone mobile, est une fonctionnalité dépendant du réseau. Votre Nokia 2010 est de type "double bande". Vérifiez auprès de votre opérateur local s'il est possible de vous abonner à cette fonction et de l'utiliser.Voir aussi la norme DCS1800 de type tri-bandes avec une carte à puce intégrée ( SIM ). Classe de puissance - "Les classes de puissance qui existent actuellement sont les suivantes: classe 4 (2 Watt de puissance maximale) utilisée dans les terminaux GSM900 portables; classe 2 (8 Watt de puissance maximale) utilisée dans les terminaux GSM900 …
Norme GSM 900Plusieurs normes coexistent actuellement : GSM900, la plus connue et la plus ancienne, est utilisée par presque tous les opérateurs de portables en Europe. La norme DCS1800 est une évolution du GSM900 avec une meilleure qualitésonore et de nouveaux services. Le système PCS1900 est utilisé aux États-Unis et n'est pas compatible avec les systèmes européens. Il y a des téléphones dual-band et tri-band qui accumulent plusieurs systèmes. En France, la norme GSM900 est utilisée par SFR et France Telecom Mobiles.
Document A
Document C
Document BLien de référence (unidirectionnel)(de document A vers document B)
Carte SIM
Elle est insérée à l'intérieur du téléphone et existe sous deux formats: ISO/Standard (format CB) et PLUG IN (avec les dimensions d'un petit timbre). Il est possible d'utiliser un adaptateur qui permet d'insérer les cartes PLUG-IN dans les appareils qui acceptent les cartes au format ISO.
Carte SIM - La carte SIM contient les informations relatives à l'abonnement au réseau GSM.Lien de partage d’information
partiel (bidirectionnel)Le document A et le document C partagent un paragraphe
Lien de référence
Figure 4-6. Illustration d'un document contenant des liens
Parmi les liens de partage, on peut différencier deux types distincts d’après
[Chabbat97] : le partage intégral et partiel. Le premier type de lien relie deux élé-
ments possédant exactement le même texte tandis que le second relie deux éléments
avec un texte différent mais exprimant une information similaire. Ce type de lien re-
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 94 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
quiert l'intervention de l'utilisateur afin d'identifier les portions de texte partageant
une même information.
Une des caractéristiques du lien étendu est qu'il associe un nombre arbi-
traire de ressources qui peuvent être locales ou distantes au lien. Il contient un mé-
lange des éléments suivants, chacun ayant une fonctionnalité précise :
▪ Des éléments de type "resource" qui fournissent les ressources locales au
lien.
▪ Des éléments de type "locator" qui fournissent les ressources distantes au
lien.
▪ Des éléments de type "arc" qui définissent un sens de liaison entre deux res-
sources du lien.
Ce type de lien peut donc être bi-directionnel, multi-directionnel, mais aussi en li-
gne ou hors ligne.
▪ Liens en ligne : Un lien étendu est dit en ligne s'il possède au moins une res-
source locale au lien. L'exemple de la figure 4-7 représente un lien étendu en
ligne. Considérons que ce lien se situe sur la page principale de l'INSA de
Lyon portant sur les liens XML d'adresse "http://www.insa-lyon.fr/etablisse
ments/index.xml". Il permet de lier cette page au réseau national des l'INSA.
http://www.insa-lyon.fr/etablissements/index.xml
http://www. insa-rouen.fr
http://www.insa-rennes.fr
http://www-insa.u-strasbg.fr
Etablissements de l’INSA:établissements
Fichier B
Lien XML
URL du fichierindex
Fichiers associés par le lien XML
URL du fichier C URL du fichier B
URL du fichier A
Fichier INDEX.XMLFichier A
Fichier C
http://www.insa-lyon.fr/etablissements/index.xml
http://www. insa-rouen.fr
http://www.insa-rennes.fr
http://www-insa.u-strasbg.fr
Etablissements de l’INSA:établissementsEtablissements de l’INSA:établissements
Fichier B
Lien XML
URL du fichierindex
Fichiers associés par le lien XML
URL du fichier C URL du fichier B
URL du fichier A
Fichier INDEX.XMLFichier A
Fichier C
Figure 4-7. Représentation des liens étendus en ligne
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 95 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Les liens étendus en ligne ne sont pas les plus intéressants, ceux hors ligne offrent
une souplesse de liaison supplémentaire.
▪ Liens hors ligne : Un lien étendu est dit hors ligne s'il ne possède aucune
ressource locale au lien. L'intérêt des liens étendus est qu'ils peuvent lier
plusieurs ressources sans qu'elles le sachent. Les liens sont en fait stockés
dans un autre fichier. Les liens hors ligne sont donc très utiles dans les cas
suivants :
1. quand le nombre de ressources est élevé, ils permettent une mise à jour
souple et simple des liens entre les ressources, sans avoir à modifier ces
ressources. Ainsi, si des ressources changent de position, seul le fichier
contenant les liens hors ligne a besoin d'être modifié.
2. quand les ressources à lier sont en lecture seule ou inaccessibles, les
liens hors ligne permettent malgré tout de les lier.
3. quand il est coûteux de modifier les ressources pour y ajouter des liens.
Voyons un exemple de lien étendu hors ligne figure 4-8 : Supposons que le lien
étendu en ligne de la figure 4-7 n'existe pas sur la page XML de l'INSA de Lyon
comportant sur les liens XML. Une personne pourrait vouloir lier cette page à d'au-
tres établissements pour la rendre plus complète. Par la même occasion, elle pourrait
aussi lier un des établissements de l'INSA à la page de référence ou page principale,
normalement celle-ci est le fichier index.
http://www. insa-rouen.fr
http://www.insa-rennes.fr
http://www-insa.u-strasbg.fr
BaseDeLiens.XML
Etablissements de l’INSA
Lien XML
Navigation URL du fichier B
URL du fichier A
http://www-insa-lyon.fr
Fichier A
Fichier index
Fichier B
URL du fichier C
Fichier CLiaison bidirectionnelle
http://www. insa-rouen.fr
http://www.insa-rennes.fr
http://www-insa.u-strasbg.fr
BaseDeLiens.XML
Etablissements de l’INSA
Lien XML
Navigation URL du fichier B
URL du fichier A
http://www-insa-lyon.fr
Fichier A
Fichier index
Fichier B
URL du fichier C
Fichier CLiaison bidirectionnelle
Figure 4-8. Représentation des liens étendus hors ligne
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 96 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Ce lien possède deux types de liaison : une liaison multi-directionnelle de la
page de référence aux pages des établissements, et une liaison bi-directionnelle entre
la page de référence et l'INSA Rouen. Les liens hors ligne sont stockés dans un do-
cument XML particulier séparé des ressources qu'ils lient. Ce document XML est ap-
pelé une base de liens.
Dans le cas de ressources distantes servant d'origine à des liens figurant dans
une base de liens, l'application traitant une de ces ressources devrait pouvoir localiser
la base de liens pour créer le lien. L'idéal serait un mécanisme externe aux ressources
informant l'application sur cette base de liens. Mais cela dépendrait des applications
et reste pour l'instant hypothétique. Néanmoins, une solution interne aux ressources
reste possible par l'utilisation de groupes de liens externes. Un tel groupe de liens
est en fait un lien étendu hors ligne particulier qui pointe vers la base de liens, dont
l'attribut role prend la valeur xlink:external-linkset.
Voici un exemple de groupe de liens externes pointant vers la base de liens
BaseDeLiens.xml, cette technique correspond à l'approche "Hyperbases" (C.f. Sec-
tion 2, chapitre 2).
<GROUP xmlns:xlink="http://www.w3.org/1999/xlink/namespace/"
xlink:type="extended"
xlink:role="xlink:external-linkset">
<BASE xlink:type="locator"
xlink:href=" BaseDeLiens.xml"/>
</GROUP>
Dans le cas de groupes de liens externes chaînés (un groupe de liens faisant
référence à une base de liens contenant elle-même un groupe de liens ...), l'applica-
tion devra choisir le nombre de groupes maximum qu'elle traitera dans la chaîne. En
plus d'un mécanisme de liaison puissant, les liens XML peuvent aussi utiliser le lan-
gage XPointer pour localiser des parties précises de documents XML.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 97 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
2.4.3 Lien de composition
Le lien de composition, représente la structure hiérarchique de composition d'un do-
cument par des éléments nommés nœuds. Ce type de lien permet d'organiser de façon
hiérarchique des fragments afin de reconstituer, par la suite, un document suivant le
schéma xml ou la DTD à laquelle il est conforme. Ces liens sont unidirectionnels et
sont établis par le système. Ce type de lien est représenté dans la figure 4-9.
TitleManualTitleManual
Section ISection I
ReferenceReferenceBodyBody
RootRootComposition link
ManualManual
URL or file URL or file locationlocation
Voir aussi la norme DCS1800
de type....
Manuel d'utilisation 760112-A
Le téléphone sans fil décrit dans ce
manuel …Element
Text
Section IISection II
Le type de bande de votre
téléphone mobile ...
TitleManualTitleManual
Section ISection I
ReferenceReferenceBodyBody
RootRootComposition link
ManualManual
URL or file URL or file locationlocation
Voir aussi la norme DCS1800
de type....
Manuel d'utilisation 760112-A
Le téléphone sans fil décrit dans ce
manuel …Element
Text
Section IISection II
Le type de bande de votre
téléphone mobile ...
Figure 4-9 Illustration d'un document contenant des liens
Ces liens constituent le principal moyen d’organiser un système hypertexte.
Ils permettent à l’utilisateur de se déplacer d’un endroit à un autre d’une manière non
séquentielle. Par ailleurs, la gestion de ces liens suppose une gestion de la structure
logique spécifique de la documentation technique. Cette structure devra également
être utilisée pour gérer les différentes versions de ces documents.
Dans la section suivante nous proposons un modèle pour la représentation
des documents XML, leurs liens intra et inter documents et la gestion de leurs ver-
sions.
Dans notre modèle, les documents sont modélisés au travers de trois dimen-
sions : une dimension structure, une deuxième dimension version et une dernière ac-
teurs. La figure 4-10 schématise notre modèle de données.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 98 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Enfin, notre modèle prévoit également le stockage des données de chaque
nœud dans le SGBD. Ceci est lié au choix de faire de notre système un système Hy-
perbase où la totalité des informations est gérée par l’application afin de prévenir les
risques d’incohérence liés à des interventions de la part d’auteurs pressés. En effet, se
contenter d’indexer les fichiers pour représenter leurs structures dans la base de don-
nées présente le risque de voir des manipulations effectuées sur les documents qui ne
seraient pas prises en compte et donc compensées par le système à travers la mise en
œuvre de ses règles actives.
3 Modèle de données pour la gestion de liens
Dans cette section, nous nous intéressons uniquement aux propriétés statiques. Ulté-
rieurement, pour les besoins de l'implémentation, nous introduirons les propriétés dy-
namiques dans la section suivante consacrée au modèle de règles. (C.f. Chapitre 5).
3.1 Dimension Structure
Nous avons comme première structure, la structure interne selon
l’organisation classique interne des documents, c’est-à-dire les sections, sous-
sections et autres paragraphes. Lorsque nous parlons d'organisation interne, nous
pouvons citer le concept de structure logique d'un document comme : l’organisation
hiérarchique des données du document, c’est-à-dire une organisation de l’information
qui sous-tend le discours de l’auteur du document. Cette organisation s’établit autour
d’abstractions représentant des parties du document dans le cas classique, un docu-
ment étant composé d’un titre, d’une ou plusieurs sections, elles mêmes composées
d’un titre, d’une ou plusieurs sous-sections. C’est une organisation qui est utilisée
dans la quasi-totalité des documents, et qui est facilement représentée ou réalisée
avec des outils comme Word ou de méta-langages comme XML. Si l’on considère
l’arbre représentant cette thèse, les modifications peuvent se traduire par des créa-
tions, des suppressions et des déplacements de nœuds, ainsi que par des mises à jour
du contenu textuel des feuilles.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 99 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Nous avons également une organisation non linéaire à travers un réseau de
liens, que nous appelons par analogie à hyperliens, hyperstructure. Cette dernière est
représentée dans notre modèle par les entités element, lien et URL qui constituent
l'hyperstructure, c’est-à-dire que nous serons capables de représenter la structure d'un
document dit Hypertexte. Dans l'entité element deux types d'éléments sont considé-
rés; l'élément composé et l'élément composite. Plusieurs éléments peuvent en compo-
ser un autre, l'élément composé est de type composite, sinon il est considéré comme
élémentaire. Les éléments de type multimédia (images, vidéo, etc.) sont représentés
dans la classe qui est séparée pour des raisons de stockage. Pour les liens, nous
considérons un lien comme un élément de type lien avec les attributs type de lien.
Les valeurs possibles pour cet attribut sont : simple, étendu, bidirectionnel, statut du
lien. Le contenu du lien est stocké dans la classe nommée URL. Cette classe a été dé-
composée selon la syntaxe d’une URL.
La syntaxe générale d'une URL est très spécifique, cela est défini par le
Network Working Group [RFC1738]. L'entité URL désormais peut être instanciée
avec les éléments que constituent la syntaxe de l'URL. L'exemple suivant l'illustre :
protocol ://hostname/chemin/nom fichier#pathsection
http:// lisi.insa-lyon.fr/~aalvarez/index.xml#section1
Nous avons choisi de formaliser notre modèle de données en utilisant la
notation UML. La figure 4-10 schématise cette première dimension.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 100 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
1..*
URL
id_urlprotocolhostNamepathNamefile_Name
Multimedia
id_mdesc_mcontenu_m
Lien
id_lientype_de_lienstatut_du_lien
1..* 1..1
un lien se dirige vers
Element
id_eletype_elenom_tag
plusieurs éléments peuvent en composer
un autre
un type d'élément peut être du type multimédia
0..*
0..*
un type d'élément contient
1..1
1..*
Cache_URLs
id_aliasdate_aliasURL
1 .. *
1..1
a document est formé de
1..1
un document peut référencer vers un
Documentid_doc
titre_doc
type_doc
auteur_docmots_clesdep_emebalise_xml
creer_doc()modifier_doc()supprimer_doc()deplacer_doc()rename_doc()notifier_doc()
etat_doc
transmettre_doc()
Auteurs
id_auteurnom_auteurauteur_type
demander.creation()demander.modification()demander.suppression()demander.lecture()demander.transmission()valider.etape()demander.changement etat()
un document peut être créepar plusieurs auteurs
1..1 1..*
1..*
URL
id_urlprotocolhostNamepathNamefile_Name
Multimedia
id_mdesc_mcontenu_m
Lien
id_lientype_de_lienstatut_du_lien
1..* 1..1
un lien se dirige vers
Element
id_eletype_elenom_tag
plusieurs éléments peuvent en composer
un autre
un type d'élément peut être du type multimédia
0..*
0..*
un type d'élément contient
1..1
1..*
Cache_URLs
id_aliasdate_aliasURL
1 .. *
1..1
a document est formé de
1..1
un document peut référencer vers un
Documentid_doc
titre_doc
type_doc
auteur_docmots_clesdep_emebalise_xml
creer_doc()modifier_doc()supprimer_doc()deplacer_doc()rename_doc()notifier_doc()
etat_doc
transmettre_doc()
Auteurs
id_auteurnom_auteurauteur_type
demander.creation()demander.modification()demander.suppression()demander.lecture()demander.transmission()valider.etape()demander.changement etat()
un document peut être créepar plusieurs auteurs
1..1 1..*
Figure 4-10 Représentation de la dimension structure
3.2 Gestion des Versions
Pour les systèmes de GED l'approche de versions est un atout indéniable, car la ges-
tion de versions permet de proposer une alternative au problème de la cohérence des
documents. Cette approche permet à l'utilisateur d'avoir une traçabilité et/ou un histo-
rique de tous les mouvements effectués sur un document, c'est-à-dire les différentes
versions du document.
Les documents que nous considérons sont donc évolutifs, liés les uns aux au-
tres, et leur évolution dépend du temps. Afin de restituer un ensemble de documents
cohérents à un utilisateur, il est donc nécessaire de conserver l'historique des docu-
ments (par le biais des versions) ainsi que celui des liens (en les versionnalisant).
La figure 4-11 illustre en détail l'approche gestion des versions de documents
et des fragments.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 101 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
1..*
URL
id_urlprotocolhostNamepathName
fileName
Version_d_element
id_vers_elenumero_vers_eledate_vers_ele
contenu_elemodificateur_ele
Multimedia
id_m
desc_mcontenu_m
Lien
id_lientype_de_lienstatut_du_lien
0..1
1..1un lien point vers un version
1..* 1..1
un lien se dirige vers
Element
id_eletype_elenom_tag
plusieurs éléments peuvent en composer un autre
1..1
1..*
1..1un élément point vers
0..*
un type d'element peut être du type multimédia0..*
1.. *
un type d'elementcontient
Version_du_document
id_vers_doc
numero_vers_doctype_vers_doc
date_vers_docstatut_vers_docmodificateur_doc
1 .. 1
1..*
une version est formée de
Cache_URLs
id_aliasdate_aliasURL
1..1
a document peut contenir
1 .. *
1..1un document peut référencer vers un cache
Documentid_doc
titre_doc
type_doc
auteur_docmots_clesdep_emebalise_xml
creer_doc()modifier_doc()supprimer_doc()deplacer_doc()rename_doc()notifier_doc()
etat_doc
transmettre_doc()
Auteurs
id_auteurnom_auteurauteur_type
demander.creation()demander.modification()demander.suppression()demander.lecture()demander.transmission()valider.etape()demander.changement etat()
un document peut être créepar plusieurs auteurs
1..1 1..*
1..*
URL
id_urlprotocolhostNamepathName
fileName
Version_d_element
id_vers_elenumero_vers_eledate_vers_ele
contenu_elemodificateur_ele
Multimedia
id_m
desc_mcontenu_m
Lien
id_lientype_de_lienstatut_du_lien
0..1
1..1un lien point vers un version
1..* 1..1
un lien se dirige vers
Element
id_eletype_elenom_tag
plusieurs éléments peuvent en composer un autre
1..1
1..*
1..1un élément point vers
0..*
un type d'element peut être du type multimédia0..*
1.. *
un type d'elementcontient
Version_du_document
id_vers_doc
numero_vers_doctype_vers_doc
date_vers_docstatut_vers_docmodificateur_doc
1 .. 1
1..*
une version est formée de
Cache_URLs
id_aliasdate_aliasURL
1..1
a document peut contenir
1 .. *
1..1un document peut référencer vers un cache
Documentid_doc
titre_doc
type_doc
auteur_docmots_clesdep_emebalise_xml
creer_doc()modifier_doc()supprimer_doc()deplacer_doc()rename_doc()notifier_doc()
etat_doc
transmettre_doc()
Auteurs
id_auteurnom_auteurauteur_type
demander.creation()demander.modification()demander.suppression()demander.lecture()demander.transmission()valider.etape()demander.changement etat()
un document peut être créepar plusieurs auteurs
1..1 1..*
Figure 4-11 Représentation du modèle pour la représentation de documents et leurs
versions
Dans notre modèle, deux niveaux des versions sont distingués :
Version du document : une version qui porte sur la structure et le
contenu du document. Si l'on considère l'arbre représentant ce docu-
ment, ces modifications peuvent se traduire par des créations, des sup-
pressions et des déplacements de nœuds, ainsi que par des mises à jour
du contenu textuel des feuilles.
Version d'élément et/ou fragment : Une deuxième gestion des ver-
sions, plus fine, se situe au niveau de ses éléments (nœuds). Chaque
nœud possède sa propre version et appartient à une version du docu-
ment. Chaque nœud est ainsi caractérisé par un ensemble de versions
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 102 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
indiquant sa position dans l’arbre et son contenu à une date donnée.
Ces nœuds sont dits multi-versions. Un nœud multi-version contient
donc l’ensemble de ses versions successives ordonnées dans le temps.
Enfin, en ce qui concerne la gestion des versions de documents, nous consi-
dérons dans notre modèle que pour chaque document il existe une ou plusieurs ver-
sions du document. Ensuite, chaque version du document est composée d’éléments, et
des versions des éléments, c'est-à-dire que chaque élément possède sa propre version
et appartient à une version du document. En revanche, nous ne pouvons pas autoriser
des modifications uniquement sur la dernière version d’un document.
3.2.1 Versions des fragments
La gestion simultanée des versions et des liens pour les documents structurés
implique introduire la notion de contexte estampillé. Un contexte estampillé est un
ensemble de documents valides et/ou cohérents techniquement parlant, à une date
donnée. La validité des documents s'entend selon leur validité donnée par le rédac-
teur, c'est-à-dire que leur contenu est applicable à la date considérée.
La figure ci-après illustre un exemple de contexte estampillé, selon le temps.
L'exemple ne prend en compte qu'un seul document, mais en réalité, un contexte es-
tampillé peut contenir plusieurs documents, chacun dans une version donnée.
f1V0 f2V0 f3V0 f4V0
f5V0
f3V1 f4V1f2V1f1V0
f5V0
Nouvelle version de fragment
f1V0 f2V1 f3V1
f4V1 f5V0
f1V0 f2V1 f3V2
f4V2 f5V0
f1V0 f2V0 f3V0
f4V0 f5V0
f3V2 f4V2f2V1f1V0
f5V0
Version 1 du document
Version 0 du
document
Version 2 dudocument
f1V0 f2V0 f3V0 f4V0
f5V0
f3V1 f4V1f2V1f1V0
f5V0
Nouvelle version de fragment
f1V0 f2V1 f3V1
f4V1 f5V0
f1V0 f2V1 f3V2
f4V2 f5V0
f1V0 f2V0 f3V0
f4V0 f5V0
f3V2 f4V2f2V1f1V0
f5V0
Version 1 du document
Version 0 du
document
Version 2 dudocument
Figure 4-12 Exemple de contexte estampillé.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 103 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Dans l'exemple de la figure 4-12, nous considérons un document D en version 0
comme le point de départ. Notre document est constitué de cinq fragments, tous en
version 0. Ensuite, le document va évoluer, c'est-à-dire avoir des modifications :
Le fragment 2 va passer en version 1 ;
Le fragment 4 va passer en version 1 lui aussi. Étant donné que le
fragment 4 a pour parent le fragment 3, l'évolution de version de f4 en-
traîne l'évolution de version de son parent f3. De même pour la suite, le
passage en version 2 de f4 entraîne à nouveau la création d'une nouvelle
version pour f3. On obtient alors trois contextes différents, à l'intérieur
desquels le document est constitué d'un ensemble cohérent de versions
de fragments.
Un contexte estampillé est un ensemble de documents à une date donnée,
donc il est un ensemble de versions de documents, donc un ensemble de versions de
fragments, à une date précise. Un contexte estampillé va donc permettre à un utilisa-
teur de consulter un ensemble de documents à une date demandée.
3.2.2 Incidences des mises à jour
La modification d'un document entraîne, généralement, la création d'une nouvelle
version. Comme nous l'avons vu précédemment, cela implique la vérification voire la
modification des liens associés aux fragments mis en cause dans la modification.
Ajout d'un fragment. Lors de l'ajout d'un fragment, les premiers liens
à mettre en place sont les liens de composition. En effet, avant toute
autre liaison, le fragment doit être rattaché à un fragment (excepté s'il
s'agit de la racine), devenant ainsi partie de document. L'ajout d'un
fragment dans un document entraîne évidemment la création d'une nou-
velle version pour ce document, ainsi que pour les fragments parents de
celui ajouté. Les autres types de liens peuvent ensuite être ajoutés.
Modification du contenu d'un fragment feuille. Lorsque le contenu
textuel d'un document est à modifier, c'est un des fragments feuilles
dudit document qui est à modifier. Une nouvelle version de ce fragment
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 104 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
est alors créée. Cette création est propagée jusqu'à la racine du docu-
ment, entraînant une nouvelle version du document lui-même. Les dif-
férents liens qui ont pour ancre le fragment modifié doivent être contrô-
lés et éventuellement invalidés.
Suppression d'un fragment. Il est possible qu'un fragment soit à sup-
primer d'un document. Cette suppression ne peut être que logique, et
non pas physique, étant donné la gestion de versions.
3.2.3 Instanciation du modèle de données
Exemple d'un extrait du fichier XML
À titre d'illustration, voyons comme un fichier du type xml est instancié dans notre
modèle de données. Tout d'abord commençons à instancier la table nommée « Do-
cument », cette table est instanciée de façon indépendante des autres tables. Instanciation de la table « Document » <?xml version="1.0" encoding="ISO8859-1"?>
<Titre>Specifications techniques de la carte Etherlink XL</Titre>
Id_doc titre_doc type_doc etat_doc auteurs_doc mots_cles dep_eme balise_xml 0010 Specifications
techniques de la carte Etherlink XL
man en cours de rédaction
10, 15, 8 Etherlink, 802.3, 802.3u
fabrication ?xml version="1.0" en-coding="ISO8859-1"?
<?xml version="1.0" encoding="ISO8859-1"?> <Specifications> <Titre>Specifications techniques de la carte Etherlink XL</Titre> <Section> <Titre_section>1. Normes</Titre_section> Media: 10BASE-T/100BASE-TX, Connectors: RJ-45,Bus: 32-bit PCI, Operating distance (10BASE-T):
Category 3/4/5 UTP to 100m (328ft).IEEE compliance: 802.3, 802.3u, 802.2, 802.1p, 802.1Q, 802.1... </Section> <Section> <Titre_section>2. Systeme requis</Titre_section> PCI 2.1 or 2.2 compliant PC NIC, Remote wake up cable, either CDROM with Dynamic Acces … <Image xlink:href="images\lan_card.jpg"/> <Lien xlink:href="demarrage_rapide_etherlink.xml">Guide de demarrage rapide</Lien> </Section> </Specifications>
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 105 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Instanciation de la classe « Version_du_document »
Id_vers_doc Numero_vers_doc Type_vers_doc date_vers_doc Statut_vers_doc Modificator_doc 0010 1 Nouveau document 01.10.2003 En cours de redaction nulle
Instanciation des classes « element, et Version_d_element »
<Section> élément 1 <Titre_section>1. Normes</Titre_section> élément 2 Media: 10BASE-T/100BASE-TX, Connectors: RJ-45, Bus: 32-bit PCI, Operating distance (10BASE-T):
Category 3/4/5 UTP to 100m (328 ft).IEEE compliance: 802.3, 802.3u, 802.2, 802.1p, 802.1Q, 802.1... </Section> <Section> élément 3 <Titre_section>2. Systeme requis</Titre_section> élément 4 PCI 2.1 or 2.2 compliant PC-NIC, Remote wake up cable, either CDROM with Dynamic Acces … <Image xlink:href="http:\liris.insa-lyon.fr\images\lan_card.jpg"/>carte reseau élément 5 <Lien xlink:href="="http:\liris.insa-lyon.fr\lan\d_rap.xml"> élément 6 Guide de demarrage rapide</Lien> </Section>
Instanciation de la classe « Element » Instanciation de la classe «Version_d_element »
Id_ele Type_ele
Nom_tag Id_vers_ele
Nu-mero_vers_ele
Date_vers_ele
contenu_ele
001 c Section 001 01 01.10.2003 Media: 10BASE-T/100BASE-TX, Connectors: RJ,Bus: 32-bit PCI, Operating distance (10BASE …
002 s Titre_section 002 01 01.10.2003 1. Normes
003 c Section 003 01 01.10.2003 PCI 2.1 or 2.2 compliant PC-NIC, Remote wake up cable …
004 s Titre_section 004 01 01.10.2003 2. Systeme requis
005 s Image xlink:href 005 01 01.10.2003 nulle
006 s Lien xlink:href 006 01 01.10.2003 Guide de demarrage rapide
Instanciation de la classe « multimedia » Instanciation de la classe «Lien »
Id_m desc_m contenu_m Id_lien type_de_lien
statut_du_lien
001 carte reseau ordimge 001 TS Valide
002 TS Valide
Instanciation de la table « URL »
id_url protocol hostname pathName fileName 001 http liris.insa-lyon.fr images lan_card.jpg
002 http liris.insa-lyon.fr lan d_rap.xml
Notons dans cet exemple l'existence de deux éléments de type <<section>>, ils sont composés de six fragments, le fragment 2 et correspondent aux titres des éléments. Le contenu de chaque élément est stockée dans la table de version_d_element, donc la table Element et version_d_element sont associées par l'dentifiant id_ele et id_vers_ele. Également les liens sont instanciées dans deux tables: dans la table liens on stocke le type de lien et son statut, et dans la table <<URL>> les éléments composants d'un lien sur la forme : protocol ://hostname/chemin/nom_fichier.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 106 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
3.3 Acteurs
Définir des acteurs permet surtout de trouver le cas d'utilisation (par exemple
un rédacteur, un lecteur, un utilisateur, etc.) Mais elle peut aussi être utilisée pour :
définir différents points de vues sur le système,
déterminer des droits d'accès par type d'acteur, etc.
Un acteur est un élément externe qui interagit avec le système. L'acteur
prend des décisions, des initiatives, bref il est actif. L'ensemble des acteurs partici-
pants dans notre modèle sont représentés dans la figure 4-13.
ré da c teu r e n ch ef
( f rom Ac t ors )
c ré e r u n n o u ve a u d o cu m e n t a p p ro u ve r d ocu m e n t
ré v ise r d o cu m e n t
va l i d e r é ta p e
ch a n g e m e n t d 'é ta p e
ré d a cte u r d u typ e e xp e rt
ré d a cte u r d u typ e co rre c te u r
a rch i ve r d o cu m e n t
A d m i n i stra te u r d u sy stèm e d e G E D
C yc l e to ta l d e v i e d 'u n d o cu m e n t
é q u i p e d e systè m e d e p rod u cti o n
d i ffu se r d o cu m e n t
Figure 4-13 Représentation des acteurs
Il existe trois types d'acteurs : les experts qui rédigent les documents, les cor-
recteurs qui corrigent les épreuves du document, et les lecteurs qui consultent des
documents. L'administrateur du système crée et met à jour la structure de la base do-
cumentaire, gère les évolutions fonctionnelles et techniques, définit les accès et veille
au respect des règles de sécurité et de protection des données, est garant de la cohé-
rence et du bon fonctionnement global.
Nous constatons que tous ces éléments sont organisés selon un modèle objet
de document (DOM), cela va nous permettre de décomposer et représenter le docu-
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 107 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
ment sous une forme arborescente et par la suite de reconstituer correctement le do-
cument.
3.4 Formalisation du modèle
3.4.1 Formalisation des documents
Il est possible de formaliser la représentation d'un document. En terme de modélisa-
tion, nous considérons qu'un document est constitué d'un ensemble des fragments
et/ou éléments non décomposables.
Une représentation formelle pour un document D est :
D = ({fD = ({f1, f, f2, f, f3 … f… fn}V}Vd)) D : Document représente le document auquel un fragment ou fragment(s)
sont rattachés.
f : Fragment = <t,type, м,Vf,Vd,D, {ffils}|cont> représente un fragment de document.
t : nom du tag représente un type caractéristique du fragment. Par exemple : titre, section, lien, image, etc.
type : C, E détermine si le composant est encore décomposable ou non. C pour composite et/ou E pour élémentaire.
м : média les types sont (texte, vidéo, image.)
ffils : Fragment ensemble des fragments fils du fragment
Vf : Version = <num, cdate > indique la version de fragment
num : N numéro de la version
cdate : date date de création de la version
cont contenu du fragment
Vd : version = <num, cdate > indique la version de document
num : N numéro de la version
cdate : date date de création de la version
Un Fragment possède :
un tag ou type de balise qui vient du mot tag au sens XML du terme;
(par exemple un nom d'étiquette peut être : <titre>, <section>, <lien>,
<image>, <sous-section>, etc.) ce qui permet de réaliser des recherches
sur la structure du document.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 108 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
un type, qui permet de déterminer, pour chaque fragment de D, si le
composant est encore décomposable ou non. C'est-à-dire si le type du
fragment est : composite ou élémentaire.
une version, contenant à la fois un numéro de version et la date à la-
quelle cette version a été créée.
une version de document, afin de savoir à partir de quelle version du
document cette version de fragment doit être considérée. Il est possible
de ne prendre en compte que les dates de version, les numéros de ver-
sion pouvant se déduire facilement des dates de création.
une liste de fragments fils ou bien d'un contenu textuel. La liste de
fragments fils permet de connaître les fragments dont celui considéré
est le père hiérarchiquement parlant, et le contenu textuel marque un
élément feuille de l'arbre Document qui, comme son nom l'indique,
présente une partie du contenu textuel du Document.
un type de média (texte, vidéo, image, etc.)
la version du document auquel le fragment est rattaché.
Nous ferons une distinction particulière entre :
les fragments ayant uniquement du contenu textuel ou multimédia, qui
sont les feuilles de l’arbre du document, et
ceux qui constituent des nœuds (il faudra pour cela, lors de toute mani-
pulation, s’intéresser à leur descendance). Néanmoins, un document
peut être vu comme un fragment particulier, étant donné qu'il corres-
pond à l'élément racine d'un texte.
Une création de version commence toujours, dans notre étude, par la création
d'une nouvelle version d'une feuille de l'arbre. Cette création est ensuite propagée
jusqu'à la racine de l'arbre, entraînant ainsi la création d'une nouvelle version pour le
document lui-même.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 109 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
3.4.2 Formalisation des liens
Lors de la formalisation des documents, un autre aspect a dû être étudié à savoir la
formalisation des liens [Karl97, Davis95, Nadalin94, ACH93, HHD93]. Pourtant, il
est nécessaire de formaliser aussi bien les liens que les documents.
Un lien a, par définition les caractéristiques suivantes :
un identifiant,
un type (dans notre cas, le type sera "référence", "partage d'information",
"composition")
une référence à son ancre "source",
une référence à son ancre "cible",
un paramètre de similarité en cas de lien de partage d'information,
une date de création.
Ces informations permettent d'utiliser par la suite un lien, à partir d'une date
donnée (celle de sa création), entre deux fragments de documents. Ces fragments
peuvent appartenir à un même document (lien intra-document) ou bien à deux docu-
ments distincts (lien inter-documents).
3.4.3 Versions des liens
Ne pas tenir compte de l'évolution des liens équivaudrait à perdre les traces (histori-
que) des liaisons entre les éléments. Si un élément "A" est relié à un élément "B" et si
la destination de l’élément "A" est changée en faveur de l’élément "C" alors l'an-
cienne destination de "A" est irrémédiablement perdue. Inversement, une gestion des
versions uniquement orientée liens introduira des problèmes d'ambiguïté : si, dans
l'exemple précédent, on garde la liaison A-B, il y a situation de concurrence entre le
lien menant vers "B" et le lien menant vers "C". Une solution est la gestion des ver-
sions des liens. Le nouveau lien de "A" vers "C" entraînera la création d'une nouvelle
version, ce lien passe de la version 1 à la version 2. La dernière version est la version
active. Nous pouvons faire référence à la section précédente pour illustrer la gestion
de versions de liens étant donné que dans notre modèle un lien est considéré comme
un élément du type lien ou bien un fragment.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 110 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Lorsque l'on introduit la notion de version avec les liens, il nous faut prendre
en compte le fait qu'à une date donnée, un lien va relier deux versions : celle de sa
source et celle de sa cible. A une autre date, les numéros de versions des fragments
ancres peuvent être différents. Néanmoins, une même version du lien peut être utili-
sée à plusieurs dates différentes, avec des fragments associés de versions différentes,
suivant l'évolution de ce dernier fragment.
De plus, un lien peut être momentanément invalidé. Il faut par conséquent
être capable d'indiquer au système (ainsi qu'à l'utilisateur) qu'il est impossible d'utili-
ser le lien à telle date. C'est pourquoi nous ajoutons la propriété suivante à la descrip-
tion d'un lien :
Une liste de triplets : (date, vnum_source, vnum_cible) date correspond à la date à partir de laquelle le couple qui suit doit être
utilisé
vnum_source correspond au numéro de la version de l'ancre source à consi-
dérer lors de l'utilisation du lien
vnum_cible correspond au numéro de la version de l'ancre cible à considé-
rer lors de l'utilisation du lien
Si l'on considère la formalisation précédemment émise, nous pouvons la
compléter par celle des liens versionnalisés. l : Liens = <t,dc,s,c,vv> représente le lien
t : {référence, partage d'in-
formation, composition} représente le type du lien
dc : Date date de création du lien
s : Fragment "source" du lien
c : Fragment "cible" du lien
vv = {(datevv, nums, numc)} ensemble des versions valides des ancres
datevv : Date date de début de prise en compte du couple de versions des ancres associé
nums : N numéro de la version de l'ancre "source" à prendre en compte
numc : N numéro de la version de l'ancre "cible" à prendre en compte
Si nums et numc sont à 0, cela signifie que le lien est invalide à partir de la
date associée à ce couple de versions d'ancres.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 111 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
3.5 Description des classes du modèle
« Classe Document » Il s’agit d’un document au sens large. Toutes les versions, dans chaque partie d’un même document, géné-rées au fil du temps seront rattachées à cette entité. C’est aussi à cette entité que sont rattachés les rensei-gnements complémentaires utiles et généralement disponibles sur tout système : type de document, auteurs, mots-clefs, etc.
« Attributs » Les attributs titre_doc, type_doc, auteurs_doc, mots_cles, dep_eme sont des renseignement complémentai-res, qui sont mis ici à titre informatif. Ils n’ont pas d’utilité pour la gestion de la cohérence des liens mais ont vocation à être pris en charge par notre système.
Nom Attribut Type de donnée
longueur Libellé
id_doc numérique 10 C’est l’identifiant du document
titre_doc, alphanumérique 25 Décrit le nom du document et est de type alphanumé-rique.
type_doc,
alphanumérique 4 Ce champ de type alphanumérique sert à identifier un type de document. Quelques exemples de types de documents sont : le type manuel : MAN, le type catalogue : CATA, le type brevet : BRE, le type procédures : PROCE, etc.
etat_doc alphanumérique 30 Détermine l'état actuel qui porte un document. Quel-ques exemples d'états de documents sont : en cours de rédaction révisé, corrigé approuvé, etc.
auteurs_doc, list 25 C'est une liste de tous les auteurs ayant le droit de participer dans le cycle de production des documents.
mots_cles, alphanumérique 50 Les mots clés sont des champs permettant une re-cherche rapide sur un document.
dep_eme alphanumérique 25 Il s'agit du département concerné par l'émission ou la responsabilité du document.
balise_xml alphanumérique 30 La balise XML est l’élément qui signale la version d’xml référencée, la police de caractères, et d’autres informations de ce type : c’est la balise d’ouverture généralement située en tête de fichier
« Méthodes » creer_doc,modi-fier_doc,supprimer_doc deplacer_doc, rename_doc
Ce sont les opérations qu’un utilisateur peut faire sur un docu-ment. Elles sont ensuite prises en charge par notre système afin de maintenir l’intégrité de la base de documents.
notifier_doc Lorsque des modifications sont faites à l’intérieur du document, le document en est notifié
« Classe Auteurs» Cette classe représente les auteurs. La notion d’auteur est représentée au niveau du modèle de données pour qu’il soit possible de leur attribuer ou non des droits spécifiques pour les manipulations aux documents.
« Attributs » Nom Attribut Type de
donnée longueur Libellé
Id_auteur alphanumérique 15 Chaque auteur est identifié par un identifiant unique.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 112 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
nom_auteur alphanumérique 40 Il ne s’agit que d’un rappel de l’identité de l’auteur, de manière à ce que l’on puisse le retrouver si on veut savoir qui a participé lors de la création du do-cument.
auteur_type alphanumérique 30 Pour ce champ, il existe trois types d'auteurs : 1.- Les experts qui rédigent les documents 2.- Les correcteurs qui corrigent les épreuves du do-
cument 3.- Les lecteurs
« Méthodes » demander.creation, deman-der.modification, deman-der.suppression, deman-der.lecture, demander.transmission, de-mander.changement, et vali-der.etape
Ces méthodes décrivent les possibles manipulations qu'un auteur ou un groupe d'auteurs peuvent réaliser sur un document. Ces manipulations sont liées aux événements que se produisent.
Classe « Element » C’est l’unité de base du document, le nœud de l’arbre du document où peuvent être attachés d’autres élé-ments (éléments composites), et/ou du contenu (texte ou multimédia).
« Attributs » Nom Attribut Type de
donnée longueur Libellé
id_ele numérique 10 C’est l’identifieur de l’élément
type_ele alphanumérique 2 Ce champ permet de déterminer le type d’élément : composite ou simple, contenu texte et/ou multimédia
type_vers_doc alphanumérique 2 Ce champ permet d'identifier la raison pour laquelle a été créée une nouvelle version. Ce peut être des mi-ses à jour importantes de contenus, identifiées par (MS), des suppressions de contenus (SU), des ajouts de nouvelles sections (AJ), et ainsi de suite. Un exemple de ce type est : lorsque l'utilisateur a modifié un élément, le système doit créer soit auto-matiquement soit par demande explicite de l’utilisateur, une nouvelle version.
nom_tag alphanumérique 30 Il s’agit bien ici du nom de tag au sens XML du terme. Notons par ailleurs que les attributs non gérés par le système (ceux liés aux liens ou aux contenus multimédias) sont conservés à cet endroit
Classe « Version_du_document » Les versions de documents sont formées d’une séquence d’éléments. Toute modification de cette séquence conduit à la création d’une nouvelle version du document. Seules des modifications internes aux éléments peuvent ne pas conduire à la création d’une nouvelle version. C’est alors l’auteur qui prend la décision.
« Attributs » Nom Attribut Type de
donnée longueur Libellé
id_vers_doc numérique 10 C’est l’identifieur de la version du document
numero_vers_doc numérique 6 C’est le numéro de version du document, à ne pas confondre avec l’identifiant de version du document. Il peut exister plusieurs versions du document ayant
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 113 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
comme numéro de version 2, pour des documents dif-férents. Alors que l’identifiant est unique.
type_vers_doc alphanumérique 25 Il s’agit du type de version (relativement à la version précédente). Ce peut être des mises à jour importan-tes de contenus, des suppressions de contenus obso-lètes, des ajouts de nouvelles sections, etc.
date_vers_doc date La date de création de cette nouvelle version. Un uti-lisateur désireux d’obtenir des informations sur un produit ou des renseignements dans un document se référera en priorité à la date pour sa recherche plutôt qu’a un numéro de version. Le système sera capable de lui proposer tous les documents mis à jour à cette date.
statut_vers_doc alphanumérique 30 Précise l'état actuel de la version du document. Plu-sieurs états sont considérés : En cours de rédaction, Brouillon, En cours de finalisa-tion, Corrigé, Final, Transmis. Si un auteur décide de la création d’une nouvelle ver-sion, celle-ci est créée et modifiée au fil de ses édi-tions, tout en n'étant pas encore validée. Par la suite, l’auteur satisfait valide et « fige » sa version. Toute nouvelle édition entraîne alors la création d’un nou-veau document.
modificateur_doc alphanumérique 30 Ce champ permet de connaître l’auteur qui a fait des changements sur ce document par rapport à la ver-sion précédente
Classe « Version_d_element » C’est la version d’élément qui détient l’éventuel contenu texte du nœud. Cela permet d’éviter la création d’une nouvelle version du document chaque fois qu’un auteur retouche un texte. En effet, cela ne se produi-ra pas car si le contenu est changé, seule une nouvelle version de l’élément est créée. La version du docu-ment est constituée d’éléments et non pas de versions d’éléments.
« Attributs » Nom Attribut Type de
donnée longueur Libellé
id_vers_ele numérique 10 C’est l’identifieur de la version d’élément.
numero_vers_ele numérique 6 C’est le numéro de version de l’élément, à ne pas confondre avec l’identifieur de version d’élément.
date_vers_ele date La date de création de cette nouvelle version. C’est grâce à elle que l’utilisateur qui consulte les docu-ments obtient des documents à jour pour une date donnée.
contenu_ele CLOB Le contenu texte de l’élément.
modificateur_ele alphanumérique 30 Ce champ permet de connaître l’auteur qui a fait des changements sur ce document par rapport à la ver-sion précédente.
Chapitre 4 / Modélisation des données
ALVAREZ Abraham 114 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon
Classe « Lien » Les liens sont une spécialisation des éléments. L’élément, qui est aussi un lien, peut avoir comme tous les autres éléments, du contenu texte ou du contenu multimédia (comme dans le cas d’une image sur laquelle on clique et qui dirige vers une nouvelle page, en html). Un lien désigne en revanche une ou plusieurs ver-sions d’éléments. Cela peut être une (ou des) version(s) d’éléments racines du document dans le cas d’un lien désignant un document entier sans plus de précisions. Cela peut également être un élément de l’arbre du document, dans le cas d’un lien désignant un paragraphe ou une sous section, interne ou externe.
« Attributs » Nom Attribut Type de don-
née longueur Libellé
id_lien numérique 10 C’est l’identifieur du lien.
type_de_lien
alphanumé-rique
30 Quand on parle de liens, on parle aussi de types. Par exemple : Type simple interne :TSI, Type étendu (TE), Type simple externe :TSE, Type utilisateur (TU)
statut_du_lien alphanumé-rique
40 Lors de la suppression d’un élément, si celui-ci est désigné par un lien, un auteur peut choisir de l’invalider. C’est un état « provisoire » qui peut servir à attendre la création d’une nouvelle cible pour le lien.
url Table_url
Ce sont les URL des éléments liés. Elles sont stockées dans une table imbriquée car il peut y en avoir plu-sieurs. Note : le type Table_url est un type que nous avons défini.
« Classe Multimedia » Les éventuels contenus multimédia des éléments sont conservés dans cette entité a part. Ces contenus mul-timédia seront stockés dans la base, sous forme de BLOB par exemple, pour éliminer les risques de modifica-tions non prises en charges par le système.
« Attributs » Nom Attribut Type de
donnée longueur Libellé
id_m numérique 6 C’est l’identifieur de l’élément multimédia.
desc_m alphanumérique 30 description du contenu muiltimédia (image, audio, vi-déo, …) et format.
Contenu_m ordimage il s’agit du contenu lui-même, sous forme d’un bloc binaire.
4 Conclusion
Nous avons présenté en détail la partie concernant la modélisation des don-
nées. Notre modèle a été conçu selon trois dimensions : de la structure, des versions
et finalement des auteurs. Ces trois dimensions permettent de représenter les docu-
ments, leurs liens et les versions avec une représentation au niveau élément du docu-
ment). Également la formalisation des documents, des liens et des versions des liens
a été abordée.