Fonctions Pre-définies En XQUERY on a des fonctions min

Fonctions Pre-définies
En XQUERY on a des fonctions min, max, count, sum et avg analogues à celles de
SQL. On a déjà vu des exemples avec count.
Quels livres sont plus chers que la moyenne ?
let $b := doc("books.xml")//book
let $avg := average( $b//price )
return $b[price > $avg]
On obtient :
⇒
180
<book year = "1999">
<title>The Economics of Technology and Content for
Digital TV</title>
<editor>
<last>Gerbarg</last>
<first>Darcy</first>
<affiliation>CITI</affiliation>
</editor>
<publisher>Kluwer Academic Publishers</publisher>
<price>129.95</price>
</book>
N.B : price est le nom d’un élément, pas un type tel que on puisse calculer le
maximum de < valeur1 (price), ..., valeurn (price) >, mais max extrait la séquence des
valeurs de price, et fait la conversion réquise.
181
On a aussi des fonctions numériques comme round, floor et ceiling.
On a des fonctions des chaı̂nes de caractères comme :
concat,
string-length,
starts-with,
end-with,
substring,
upper-case,
lower-case.
Puis : distinct-values et doc (déjà vues).
182
Et encore : not.
Quels sont les livres dont aucun auteur s’appelle Stevens ?
for $b in doc("books.xml")//book
where not(some $a in $b/author satisfies $a/last="Stevens")
return $b
La fonction empty teste si une séquence est vide.
Quels sont les livres qui ont au moins un auteur ?
for $b in doc("books.xml")//book
where not(empty($b/author))
return $b
On aurait pu aussi écrire :
for $b in doc("books.xml")//book
where exists($b/author)
return $b
183
La fonction string, appliqué à un noeud, renvoie la réprésentation sous forme de
chaı̂ne de caractères du texte trouvé dans le noeud et ses déscendants. Par exemple, la
requête :
string((doc("books.xml")//author)[1])
calcule la chaı̂ne ‘‘Stevens W.’’ (le nom du premier auteur dans le document).
La fonction data, appliqué à un noeud, renvoie la valeur typée d’un noeud ; exemples
d’utilisation de cette fonction dans le TD.
184
Fonctions définies par l’utilisateur
On peut définir une fonction qui calcule une requête donnée, et la réutiliser. Par exemple :
define function books-by-author($last, $first)
as element()*
{
for $b in doc("books.xml")/bib/book
where some $ba in $b/author satisfies
($ba/last=$last and $ba/first=$first)
order by $b/title
return $b/title
}
définie une fonction qui crée une fonction qui liste les livres auteur par auteur, et la
nomme books-by-author.
185
XQUERY supporte la définition de fonctions récursives.
Suppose qu’un chapitre de livre est constitué de sections, qui peuvent être imbriquées. La
requête suivante crée une table des matières, containant les sections et leur titres, selon la
structure des sections du livre.
define function toc($book-or-section as element())
as element()*
{for $section in $book-or-section/section
return
<section>
{ $section/@* , $section/title , toc($section) }
</section>}
<toc>
{
for $s in doc("xquery-book.xml")/book
return toc($s)
}
</toc>
186
Quelque éléments de réponse à la question sur : “XQUERY et Mises à Jour”
– Lien :
http://www.w3.org/TR/xquery-update-10
This document defines an update facility that extends the XML Query language,
XQuery. The XQuery Update Facility provides expressions that can be used to make
persistent changes to instances of the XQuery 1.0 and XPath 2.0 Data Model.
– Lien :
http://exist.sourceforge.net/update_ext.html}
Previous versions of eXist already offered some functions to execute XUpdate queries
from within XQuery. However, this approach had its limitations, mainly due to the lack
of integration between the XUpdate language and XQuery....
We thus provide an extension to XQuery, which maps each of the XUpdate instructions
to a corresponding XQuery expression.
Un exemple sur ce site :
update insert <email type="office">[email protected]</email>
into //address[fname="Andrew"]
187
9
Une Etude de Cas
187-1
On va modéliser un même ensemble d’informations à l’aide des 3 modèles : relationnel,
à objet, et semi-structuré.
But : illustrer analogies et différences entre les trois approches, limites respectives, etc.
188
La BD des BD
Une bande dessinée a un ou plusieurs auteurs, qui sont scénaristes ou/et dessinateurs
et/ou coloristes de l’ouvrage en question. Elle a un unique éditeur, un unique titre, un
unique ISBN, un unique format et un unique prix.
Les mangas sont des bandes dessinées particulières, qui n’ont pas de coloriste mais ont
un attribut supplémentaire, sens de lecture, qui vaut gauche droite ou droite gauche.
Un auteur a un nom, parfois un prénom, une ou plusieurs adresses, parfois une
thématique, et parfois il est sous contrat d’exclusivité avec un éditeur.
Un éditeur a un nom, une adresse et parfois a des auteurs sous contrats.
Les adresses sont constituées d’un numéro, d’un nom de rue, d’une ville et d’un pays.
189
Une Modèlisation Relationnelle
Une parmi les modèlisations possibles crée un schéma avec 7 tables : BD pas Mangas,
Mangas, Infos Auteur, Auteur Adresses, Auteur Oeuvres Pas Mangas
Auteur Oeuvres Mangas,
Contrats.
Chaque schéma de table est en BCNF (Forme Normale de Boyce Codd).
⇒
190
BD pas M angas :
titre
ISBN
long
larg
prix
Ident edit
num rue ed
rue ed
ville ed
pays ed
Dépendances Fonctionnelles F :
{ISBN → titre, long, larg, prix, Ident edit, num rue ed, rue ed, ville ed, pays ed}
Clé : ISBN
Ce schéma de table est en BCNF : les seules dépendances fonctionnelles significatives
sont celles à partir de la clé.
191
M angas : même table que pour BD pas Mangas, avec, en plus, l’attribut
sens de lecture, dont le domaine est {“GD ′′ , “DG′′ } (de gauche à droite, de droite à
gauche).
Dépendances Fonctionnelles F : les mêmes que pour BD pas Mangas, plus
ISBN → sens de lecture.
Clé : ISBN
Ce schéma de table est en BCNF.
192
Inf os Auteur :
NSS
nom
prenom
thematique
Dépendances Fonctionnelles F : {N SS → nom, prenom, thematique}
Clé : NSS
Ce schéma de table est en BCNF.
193
Auteur Adresses :
NSS
num rue aut
rue aut
ville aut
pays aut
Dépendances Fonctionnelles F : seulement la dépéndance banale :
N SS, num rue aut, rue aut, ville aut, pays aut → N SS, num rue aut, rue aut, ville aut,
Clé : {N SS, num rue aut, rue aut, ville au, pays aut}.
Ce schéma de table est en BCNF.
NB : Le fait qu’il faut tous les attributs dans la clé est du à l’hypothèse qu’un auteur peut
avoir plusieurs adresses, au fait que 2 adresses distinctes peuvent contenir le même
numéro, où la même rue, où la même ville, ou le même pays (mais pas coincider sur
tout), et, enfin, à l’hypothèse (implicite) que deux auteurs peuvent vivre à la même
adresse.
194
Auteur Oeuvres P as M angas :
NSS
ISBN
scen
col
dessin
où le domaine est le même pour les attributs scen, col et dessin : l’ensemble des booléens
{True, False} (l’auteur est scénariste ou pas, coloriste ou pas, déssinateur ou pas, pour la
bd en question).
Dépendances Fonctionnelles F : {N SS, ISBN → N SS, ISBN, scen, col, dessin}
Clé : {N SS, ISBN }.
Ce schéma de table est en BCNF.
NB : il faut les 2 attributs dans la clé, car un auteur peut avoir réalisé plusieurs oeuvres,
et une oeuvre peut avoir plusieurs auteurs. Et puis, un auteur donné peut être juste
scénariste pour une bande déssinnée, mais scénariste et déssinateur pour une autre, etc.
195
Auteur Oeuvres M angas :
NSS
ISBN
scen
dessin
où le domaine est le même pour les attributs scen, dessin : l’ensemble des booléens
{True, False} (l’auteur est scénariste ou pas, déssinateur ou pas, pour la manga en
question).
Dépendances Fonctionnelles F : {N SS, ISBN → N SS, ISBN, scen, dessin}
Clé : {N SS, ISBN }.
Ce schéma de table est en BCNF.
NB : On a juste enlévé col de la table Auteur Ouvres P as M angas. Mais il faudrait
de quelque façon séparer les ISBN des mangas des ISBN des pas mangas... Passons.
196
Contrats :
NSS
Ident ed
Dépendances Fonctionnelles F : {N SS ⇒ Ident ed} car un auteur est sous contrat
exclusivement avec un éditeur (tandis qu’un éditeur peut avoir plusieurs auteurs sous
contrat).
Clé : {N SS}.
Ce schéma de table est en BCNF.
197
On n’a pas exprimé la contrainte qu’un auteur a forcement au moins une adresse, sauf si
on pose la contrainte (naturelle) :
πN SS (Inf os Auteur) = πN SS (Auteur Adresses)
=
πN SS (πN SS (Auteur Oeuvres P as M angas) ∪ πN SS (Auteur Oeuvres P as M angas))
N.B. Grâce à la table Auteur Oeuvres P as M angas, on peut reperer pour quelle bd
un auteur est seulement scénariste et pour quelle autre est aussi déssinateur, par exemple,
et idem pour Auteur Oeuvres M angas. Et on a exprimé aussi la contrainte que les
mangas n’ont pas de coloriste.
198
On n’exprime pas les “parfois”, non plus :
– On n’a pas exprimé qu’un auteur a parfois une thématique (donc il peut aussi ne pas en
avoir) ;
– On n’a pas exprimé qu’un auteur a parfois un prénom.
Pour pallier ces problème, il faudrait admettre des valeurs nulls. Remarquer que le
modèle relationnel “propre” ne veut pas de valeurs nuls ! Cette limite est vraiment
intrinséque au modèle relationnel.
199
N.B. Si jamais on pose aussi les contraintes :
πIden edit (BD pas M angas) ⊆ πIden edit (Contrats)
et
πIden edit (BD pas M angas) ⊆ πIden edit (Contrats)
on n’exprimera pas non plus la contrainte qu’un éditeur a parfois un contrat avec un
auteur (donc il peut ne pas en avoir).
Problème analogue si on pose :
πN SS (Auteur Oeuvres pas M angas) ⊆ πN SS (Contrats)
et
πN SS (Auteur Oeuvre M angas) ⊆ πN SS (Contrats)
200
Une Modèlisation Objet
Une parmi les modèlisations possibles crée un schéma avec 5 classes : BD, Auteur,
Editeur, Adresse, Mangas, où Mangas est une sous-classe de la classe BD.
NB : pas de correspondance exacte avec les tables relationnelles (mais on aurait pu faire
autrement, et ne pas utiliser de sous-classes, par exemple).
⇒
201
class BD (key ISBN extent les_bd) {
attribute string titre;
attribute integer ISBN;
attribute format struct dimensions{float long, float larg} format;
attribute float prix;
relationship <Auteur> a_scénariste inverse Auteur::scénariste_de;
relationship <Auteur> a_déssinateur inverse Auteur::scénariste_de;
relationship <Auteur> a_coloriste inverse Auteur::coloriste_de;
relationship Editeur a_éditeur inverse Editeur édite}
class Mangas extends BD (extent les_mangas)
attribute enum directions{GD,DG} sense_lecture
202
class Auteur (key NSS extent les_auteurs) {
attribute integer NSS
attribute string nom;
attribute string prénom;
attribute string thématique;
relationship Set<BD> scénariste_de inverse BD::a_scénariste
relationship Set<BD> déssinateur _de inverse BD::a_déssinateur
relationship Set<BD> coloriste_de inverse BD::a_coloriste
relationship Set<Adresse> a_adresse inverse Adresse::adresse_de;
relationship Editeur contrat_avec_ed inverse Editeur contrat_avec_aut}
class Editeur (key Ident\_edit extent les_editeurs) {
attribute integer Ident\_edit
attribute string nom;
relationship Adresse éd_a_adresse inverse Adresse::adresse_de_éd;
relationship Set<Auteur> contrat_avec_aut inverse Auteur contrat_avec_ed;
relationship Set<BD> edite inverse BD a_éditeur}
203
class Adresse (key (num, rue, ville, pays) extent les_addresses) {
attribute integer num;
attribute string rue;
attribute string ville;
attribute string pays;
relationship Set<Editeur> adresse_de_éd inverse Editeur::éd_a_adresse;
relationship Set<Auteur> adresse_de inverse Auteur::a_adresse;
relationship Set<Auteur> contrat_avec_aut inverse Auteur contrat_avec_ed}
204
On n’a pas exprimé :
1. La contrainte qu’un auteur a forcement au moins une adresse (notre déclaration
permet qu’un auteur ait un ensemble vide d’adresses ; pourquoi ?).
2. La contrainte qu’une Manga n’a jamais de coloriste (à cause de la relation de
sous-classe ; mais on aurait pu l’éviter).
N.B. On peut reperer pour quelle bd un auteur est seulement scénariste et pour quelle
autre est aussi déssinateur, par exemple.
205
On n’exprime pas les “parfois”, non plus :
– on n’a pas exprimé qu’un auteur a parfois une thématique (comme pour le relationnel).
– on n’a pas exprimé qu’un auteur a parfois un prénom (comme pour le relationnel).
– on n’a pas exprimé qu’un auteur a parfois un contrat.
Comme pour le relationnel, cette mauvaise gestion des “parfois” est intrinséque :
ODL ne permet pas de faire la différence entre :
- la contrainte qu’un objet o d’une classe C1 est lié à un nombre indeterminé n d’objets
de C2 (n ≥ 0)
- la contrainte qu’un objet o d’une classe C1 est lié à un nombre n d’objets de C2 où
n ∈ {0, 1}.
Pourquoi ?
206
Une modèlisation semi-structurée
Un DTD que l’on peut écrire : ⇒
207
<!ELEMENT (bande_dessinnée)+, auteur+,editeur+>
<!ELEMENT bande_dessinée (manga|pas-manga)>
<!ELEMENT pas_manga (titre,format,prix)>
<!ATTLIST pas_manga ISBN ID #REQUIRED a_scénariste IDREF #REQUIRED
a_déssinateur IDREF #REQUIRED a_coloriste IDREF #IMPLIED
a_editeur IDREF #REQUIRED>
<!ELEMENT manga (titre,format,prix)>
<!ATTLIST ISBN ID #REQUIRED a_scénariste IDREF #REQUIRED
a_déssinateur IDREF #REQUIRED a_editeur IDREF #REQUIRED
sens_lecture (GD|DG)>
<!ELEMENT titre PCDATA>
<!ELEMENT titre CDATA>
<!ELEMENT format (long,larg)>
<!ATTLIST format unité_més CDATA #REQUIRED>
<!ELEMENT prix CDATA>
<!ATTLIST prix dévise CDATA #REQUIRED>
<!ELEMENT long CDATA>
208
<!ELEMENT larg CDATA>
<!ELEMENT auteur (nom,prenom?, (adresse)+,thématique?)>
<!ATTLIST auteur NSS_aut ID #REQUIRED réalise IDREFS #REQUIRED
contrat_avec_ed IDREF #IMPLIED>
<!ELEMENT nom PCDATA>
<!ELEMENT prenom PCDATA>
<!ELEMENT thématique PCDATA>
<!ELEMENT adresse (numéro, rue, ville, pays)>
<!ELEMENT numéro CDATA>
<!ELEMENT rue PCDATA>
<!ELEMENT ville PCDATA>
<!ELEMENT pays PCDATA>
<!ELEMENT editeur (nom,adresse)>
<!ATTLIST editeur NSS_ed ID #REQUIRED édite IDREFS #REQUIRED
contrat_avec_aut IDREFS #IMPLIED>
209
On exprime :
– Les mangas sont des BD ;
– La contrainte qu’un auteur a forcement au moins une adresse (on a le + !)
– La contrainte qu’une Manga n’a jamais de coloriste.
– Pour une bd un auteur est seulement scénariste et pour une autre est aussi déssinateur,
par exemple.
210
On exprime les “parfois” :
– Un auteur a parfois une thématique (fils thématique ? de auteur) ;
– Un auteur a parfois un prénom (prénom ?).
– Un auteur a parfois un contrat (L’attribut contrat avec ed de auteur est
optionnel)
N.B. La possibilité de déclarer balise ? dans le DTD permet d’exprimer qu’une
relation lie un individu x à 0 ou 1 individus, chose qui ni le relationnel ni l’objet
permettent de faire.
211
At-on exprimé la contrainte qu’un cible d’un lien a scénariste doit forcement être
un noeud auteur ? (Même question pour a déssinateur et a coloriste).
Non : on peut écrire un document xml où, pour une bd, a scénariste pointe à une
autre bd, par exemple, et le document sera validé !
En général, dans un DTD on ne peut pas spécifier la balise attendue pour la cible d’un
attribut de type IDREF ou IDREFS !
En XML-schéma non plus, d’ailleurs.
212