RetourMême si toutes les contraintes du schéma EAP ne sont pas exploitables avec une DTD, nous allons proposer un certain nombre de règles (d'heuristiques) permettant de faire évoluer la structure déterminée au paragraphe précédent. Dans cette section, nous nous occuperons des cardinalités. Dans la suivante, nous verrons comment exploiter les contraintes formulées sur le schéma.
Nous allons d'abord nous occuper des associations binaires hiérarchiques (des fonctions), c'est-à-dire des associations concernant deux entités et dont une des deux cardinalités est de la forme "_,1", avec "_" remplaçant "0" ou "1". Le traitement standard est le suivant (en fait valable quelque soit le type d'association !) :
Dans cet exemple générique, comme dans les suivants, nous présentons deux cas : une association sans propriété et une association avec propriétés.
Le premier cas intéressant concerne les associations binaires hiérarchique de type "1..1". Dans ce cas, il est possible d'intégrer cette association du côté "1..1" comme c'est fait lors du passage EAP vers Relationnel. Dans le cas d'une association sans propriété, il suffit alors d'ajouter un attribut obligatoire de type IDREF référençant l'entité côté "_..n". Si l'association possède des propriétés, alors soit elles sont ajoutées à l'élément, soit il est créé un contenu représentant l'association.
Cette solution peut être grandement améliorée en constant que "B" n'est lié qu'à une seul "A". Aussi, il est possible d'exploiter la hiérarchie naturelle de XML en supprimant l'élément "liste-B" et l'attribut "S1-A" (dans le premier cas ; dans le second les propriétés de l'association peuvent être mises dans "B" par exemple) et en mettant "A → B*" (car nous avons "0..n" du côté de A, "1..n" aurait mené à "B+" au lieu de "B*").
Si l'association possède une cardinalité "0..1" au lieu de "1..1", alors l'attribut ajouté devient optionnel ("#IMPLIED") ou l'élément facultatif ("?"). Ceci donnera alors :
Dans le cas d'associations maillées (binaires ou non), des relations, le cas général donne ("n..m" remplace "0..1", "1..1", "0..n" ou "1..n") :
C'est le cas standard du paragraphe précédent. Cependant, il est possible de structurer différemment le document. En particulier, dans le cas d'une association n-aire, si l'une des cardinalités est "0..1" ou "1..1". Dans ce cas, il est possible d'appliquer les règles des associations hiérarchiques. Ceci donne les cas suivants :
Remarques :
Dans le cas où il n'y a pas de cardinalité "_..1", il est possible de choisir une entité et d'appliquer un principe similaire. Comme nous pouvons le voir dans l'exemple ci-dessous, plusieurs cas sont possibles. Pour un cas abstrait comme celui-ci, les solutions 1 et 3 sont équivalentes. Par contre, la solution 2 est légèrement différente. Comme S1-B a une cardinalité de "1..n" au lieu de "0..n", le contenu de B est "S1+" au lieu de "S1*". D'une manière générale, l'opérateur "+" étant plus fort que l'opérateur "*" (dans le sens de la contrainte imposée), il est préférable de choisir une entité "1..n".
Nous pouvons appliquer ces règles à l'exemple du Mariage. D'abord, nous pouvons appliquer les règles concernant les associations hiérarchiques :
Puis, nous pouvons appliquer les règles concernant les associations maillées :
En utilisant la syntaxe des DTD, nous obtenons alors :
Dans cet exemple, le texte indique que les témoins, considérés comme des invités, sont au nombre de 2 au moins. Il y a donc non pas "au moins un" mais "au moins deux" invités. Il convient donc d'ajuster cette dernière DTD pour obtenir :
Remarque : pour l'attribut "Statut" de l'élément "Invité", il peut prendre ses valeurs dans {Témoins, Proche, Standard}. Donc, il faudrait écrire "<!ATTLIST Invité Statut (Témoin|Proche|Standard) 'Standard'>".
Évidemment, ces règles n'exploitent, pour chaque association, qu'une seule cardinalité. Pour aller plus loin, c'est-à-dire pour prendre en compte toutes les cardinalités, il faut introduire de la redondance. Du coup, lors de la manipulation du document, il faudra faire attention à certains problèmes de cohérence conséquences de cette redondance (comme dans le cadre des bases de données relationnelles qui ne sont pas normalisées correctement).
Nous allons donc nous occuper des autres entités, celles qui n'ont pas "reçu l'association". Le traitement dépend de la cardinalité de l'entité vis à vis de l'association et du traitement de l'association. En effet, une association génère un élément ou est intégrée dans l'élément d'une entité. Dans le premier cas, afin de pouvoir la référencer, il faut créer un identifiant. Cet identifiant d'élément (de l'association) peut être construit par concaténation des identifiants des éléments associés aux entités participantes (ajusté à la syntaxe des noms XML bien sûr). En conséquence, il est possible de considérer les entités n'ayant pas fait l'objet des règles précédentes et d'appliquer les règles suivantes selon la cardinalité de l'entité :
Remarque : il est aussi possible de traiter les associations "_..1" comme les "_..n" en créant un élément contenu "E-S1" pour le "1..1" ou "E-S1?" pour le "0..1". Cette méthode sera utile, dans un prochain paragraphe, pour le traitement des contraintes.
Sur l'exemple Mariage, cela donnera alors :
Remarque : évidemment, les noms proposés ici peuvent être modifiés pour mieux coller au système représenté.
Il reste à évoquer deux cas des diagrammes EAP que nous n'avons pas encore traité : les associations unaires et les entités faibles.
Ce cas ne change pas des cas vus précédemment. Il faut seulement identifier les rôles afin de différencier les références dans les éléments. Ceci donnera par exemple les cas suivants :
Le rôle peut aussi être présent dans les associations n-aires. Il est utilisable dans la construction des noms de référence.
Dans ce type d'entité, le calcul de l'identifiant est effectué en prenant en compte aussi l'identifiant de l'entité de référence. Pour le reste, nous avons une association "1..1" classique.
Rappel : attention, les identifiants XML doivent être tous différents dans un document XML même pour des éléments différents.
Sur ce dernier cas, une meilleur solution est d'inclure "B" dans "A" sous la forme "A → B*" (comme pour les association de type fonction vues plus haut).