Gérer les clés étrangères dans un ficher XSD

Version imprimable

Bonjour tout le monde
J'ai une question concernant la gestion des clés étrangères dans un fichier XML schema (.xsd).
Supposons que nous avons deux entités:
Etudiant(<souligne>cin</souligne>,nom,prenom,age,#section);

Section(<souligne>nom</souligne>)
et que nous devons les représenter en xsd, qu'est ce que je dois ajouter sous l’élément section (pour montrer que c'est une clé étrangère)un key ou un keyref?
voici le code que j'ai écrit:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
 
<?xml version="1.0"  encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
	<xs:complexType name="Etudiant">
		<xs:sequence>
			<xs:element name="cin" type="xs:int" nillable="false"  >
 
			<xs:unique name="cinEtudiant">
				<xs:selector xpath="Etudiant/cin" />
				<xs:field xpath="cin" />
			</xs:unique>
		</xs:element>
			<xs:element name="nom" type="xs:string" />
			<xs:element name="prenom" type="xs:string" />
			<xs:element name="age" type="xs:int" />
 
 
			<xs:element name="section" type="xs:string" />
 
 
			</xs:sequence>
 
 
	</xs:complexType>
 
 
	<xs:complexType name="Section">
		<xs:sequence>
 
			<xs:element name="nomSection" type="xs:string" >
 
			<xs:key name="nomSec">
				<xs:selector xpath="./Section" />
				<xs:field xpath="." />
			</xs:key>
 
			<xs:keyref name="sectionRef" refer="nomSec">
				<xs:selector xpath="./Section" />
				<xs:field xpath="."/>
			</xs:keyref>
 
 
			</xs:element>
 
 
 
		</xs:sequence>
 
 
 
	</xs:complexType>
</xs:schema>

Merci d'avance :D.

Un schema comme tel est incapable de reçevoir les contraintes voulues: cettes contraintes devraient coder par rapport aux éléments plutot qu'aux types. Et puis, il y a une considération de la portée des key, keyref et même unque qui semblent tout à fait incorrecte.

En plus, il y a des erreurs dans la conception des selector et field si je comprehends bien, mais c'est secondaire par rapport aux problèmes élevés précédamment.

Laissez-moi de renommer ces types Etudiant et Section comme etudiantType et sectionType successivement. Supposons la structure de xml comme ça:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<racine>
    <Etudiants>
        <Etudiant>
            <cin>1</cin>
            <!-- etc etc... -->
            <section>BTS Option A (Mercatique et gestion hôtelière)</section>
        </Etudiant>
        <!-- etc etc... Etudiant -->
    </Etudiants>
    <sections>
        <section>
            <!-- etc etc -->
            <nomSec>BTS Option A (Mercatique et gestion hôtelière)</nomSec>
            <!-- etc etc -->
        </section>
        <section>
            <!-- etc etc -->
            <nomSec>BTS Viticulture Oenologie</nomSec>
            <!-- etc etc -->
        </section>
    </sections>
</racine>

Voici ce que xsd devrait structurer en gros.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
<xs:element name="racine">
    <xs:complexType>
        <xs:sequence>
            <xs:element ref="Etudiants" />
            <xs:element ref="sections" />
        </xs:sequence>
    </xs:complexType>
    <xs:keyref name="sectionRef" refer="nomSec">
        <xs:selector xpath="Etudiants/Etudiant" />
        <xs:field xpath="section" />
    </xs:keyref>
    <xs:key name="nomSec">
        <xs:selector xpath="sections/section" />
        <xs:field xpath="nomSec" />
    </xs:key>
</xs:element>
 
<xs:element name="Etudiants" type="etudiantsType">
    <xs:unique name="cinEtudiant">
        <xs:selector xpath="Etudiant" />
        <xs:field xpath="cin" />
    </xs:unique>
</xs:element>
 
<xs:element name="sections" type="sectionsType" />
 
<xs:complexType name="etudiantsType">
    <xs:sequence>
        <xs:element ref="Etudiant" maxOccurs="unbounded" />
    </xs:sequence>
</xs:complexType>
 
<xs:complexType name="sectionsType">
    <xs:sequence>
        <xs:element ref="section" maxOccurs="unbounded" />
    </xs:sequence>
</xs:complexType>
 
<xs:element name="Etudiant" type="etudiantType"/>
<xs:element name="section" type="sectionType" />
 
<xs:complexType name="etudiantType">
    <xs:sequence>
        <xs:element name="cin" type="xs:int" nillable="false" />
        <!-- etc etc ce que vous avez sans unique, key, et keyref -->
        <xs:element name="section" type="xs:string" />
    </xs:sequence>
</xs:complexType>
 
<xs:complexType name="sectionType">
    <xs:sequence>
        <!-- etc etc si il y en a quelque chose d'autre -->
        <xs:element name="nomSec" type="xs:string" />
        <!-- etc etc si il y en a quelque chose d'autre -->
    </xs:sequence>
</xs:complexType>

Il y a plein de choses à faire attention la-desus que je serais mal à mettre en discours, mais le plan d'ensemble, c'est ça.

21/05/2012, 12h43
fioreT

Merci infiniment :ccool:
Mais juste il reste quelques choses à ajouter je suis dans un contexte de génération à partir d'un fichier XSD vers une représentation objets en java (complexType étudiant donne une classe Etudiant {})
Est ce que c'est crucial d'ajouter la racine dans le schema?

Code:

<xs:element name="racine">

De plus avoir des complexTypes tels que "sectionsType" ne me permet pas d'avoir en contre partie dans la représentation objets une classe Section je pense que la gestion des clés va compliquer le processus de génération :(
Merci
21/05/2012, 15h31
tsuji

Citation:

Est ce que c'est crucial d'ajouter la racine dans le schema?

La signification génerique du rôle de "racine" ici est, en fin de compte, d'identifier et d'avoir une balise qui englobe les sections individuellement (comme "sections" dans mon exemple démo) comme déscendants (pas nécessairement enfant, ils peuvent être grand-enfants ou grand-grand...); et cette même balise "racine" doit englober les Etudiant individuellement aussi. La raison est pourque la portée de key et keyref peut couvrir tous les sections et Etudiant; et pourque keyref peut se réferé au key proprement comme sibling dans xsd. On peut se demander encore pourquoi? La raison aussi est que les axes renversantes sont défendues de paraître dans xs:selector et xs:field. Voilà les raisons et la seule raison d'être de ce "racine" qui doit être satisfaite. La structure concrète dedans la "racine" n'est pas rigide et celle dans mon exemple démo est figuratif au plus.

En ce qui concerne les mappings, je pense jaxb 2.0+ est capable de gérer ce genre de structure, non?
21/05/2012, 22h15
fioreT

Merci pour les informations :)

Citation:

En ce qui concerne les mappings, je pense jaxb 2.0+ est capable de gérer ce genre de structure, non?

Oui, mais je suis en train de faire mon propre générateur :mrgreen: