Gérer des relations de base de données
Les bases de données relationnelles, comme l'indique leur nom, présentent généralement des relations définies entre leurs tables. En prenant comme exemple la base de données Altova.sqlite trouvée dans le dossier <Documents>\Altova\MapForce2023\MapForceExamples\Tutorial\, plusieurs relations y existent, par exemple :
•Le modèle d’entreprise (correspondant à la table "Altova") consiste en un ou plusieurs bureaux (par exemple, à Brenton et à Vereno). Dans la terminologie de base de données, il existe une relation one-to-many entre les tables "Altova" et "Office". En d'autres termes, pour chaque entrée PrimaryKey dans la table "Altova", il peut y avoir plusieurs entrées ForeignKey dans la table "Office". Toute entrée "Office" où la valeur ForeignKey correspond à la valeur PrimaryKey dans "Altova" devrait donc être considéré être un bureau de "Altova".
•Chaque bureau comprend un ou plusieurs départements (par exemple "Marketing", "IT", "Development"). Ici, on retrouve une relation one-to-many entre les tables "Office" et "Department".
•Finalement, chaque département consiste en une ou plusieurs personnes. Donc, la relation one-to-many entre les tables "Department" et "Person".
Les relations entre les tables de base de données sont importantes pour des raisons de mappage. MapForce garde une trace de ces relations de base de données lorsque vous ajoutez une base de données au mappage. Cela vous permet de préserver les relations de base de données lorsque vous mappez des données de ou vers une base de données. Pour mieux comprendre ce concept, ajoutez la base de données Altova.sqlite au mappage (utilisant la commande de menu Insérer | Base de données). Nous appellerons chacune des tables ci-dessous une table "root" :
Tables "Root"
En agrandissant une table "root", vous voyez apparaître en-dessous toutes les tables liées dans une vue arborescente. Par exemple, si vous agrandissez la table Office, veuillez noter comment la hiérarchie de la table liée est affichée :
•Une flèche orientée vers la gauche ( 
) devant une table montre qu'il s'agit d'une table enfant. Par exemple, Address est un enfant d'Office. Department est aussi un enfant d'Office, de même qu'une table "frère" d'Address, les deux ont donc le même niveau de retrait. Comme vous pouvez le voir, la relation dans le mappage correspond au diagramme ci-dessus.
•Une flèche orientée vers la droite ( 
) devant une table montre qu'il s'agit d'une table Parent. Par exemple, Altova est un parent d'Office.
Cette représentation hiérarchique des tables vous aide à préserver les relations de base de données existantes lorsque votre mappage est lu depuis ou écrit dans une base de données. Par exemple, partons du principe que vous souhaitez obtenir tous les enregistrements de la table Person dans un fichier XML, regroupé par département. Plus spécifiquement, votre fichier XML devrait relier chaque personne à un département, comme pour la base de données Altova.sqlite utilisée dans cet exemple :
Comme illustré ci-dessus, le département "Administration" contient trois personnes, "Marketing" contient deux personnes, "Engineering" contient six personnes, etc.
Lorsque vous mappez des données depuis cette base de données, si vous souhaitez que chaque personne soit distribuée dans le département correct, il est important d'utiliser Department en tant que table "root", puis que vous mappiez depuis la table Person table qui est un enfant de Department:
Le mappage ci-dessus est un DB_Altova_Hierarchical.mfd modifié du dossier <Documents>\Altova\MapForce2023\MapForceExamples\. Lorsque vous prévisualisez le mappage, le résultat est que chaque personne sera regroupée par département, ce qui était le résultat escompté. Donc, "Administration" contient trois personnes, "Marketing" contient deux personnes, "Engineering" contient six personnes, etc.
À présent, observons le mappage légèrement modifié ci-dessous, où des connexions ont été tirées délibérément de manière à ce que Department et Person sont des tables "root".
Cette fois, lorsque vous prévisualisez le mappage, toutes les personnes (quelque soit leur département de source) sont groupées sous chaque département de cible, ce qui n'était pas le résultat escompté. Donc, "Administration" contient 21 personnes, "Marketing" contient 21 personnes, "Engineering" contient 21 personnes, etc.
Dans le deuxième exemple, les relations de base de données sont ignorées, en raison de la manière dont les connexions ont été établies.
Pour cette raison, lorsque vous souhaitez préserver des relations de base de données, assurez-vous que les connexions soient tirées vers et de la même table "root", qui contient des tables enfant desquelles vous voulez préserver les relations. Ceci fonctionne de la même manière pour les bases de données source et cible. Pour des exemples de mappages de la base de données qui préservent les relations, voir les fichiers DB_Altova_Hierarchical.mfd et Altova_Hierarchical_DB.mfd disponibles dans le dossier <Documents>\Altova\MapForce2023\MapForceExamples\ (voir aussi Insérer les données dans de multiples tables liées).
Il pourrait également y avoir des cas où vous ne voulez pas préserver les relations de base de données. Par exemple, assumons que vous voulez exporter toutes les données depuis la base de données Altova.sqlite vers un fichier XML plate adhérant à la spécification SQL/XML (partie 14 de la spécification du « Structured Query Language » (SQL) specification). Ce type de mappage est illustré par le modèle DB_Altova_SQLXML.mfd, disponible dans le dossier <Documents>\Altova\MapForce2023\MapForceExamples\. L’objectif du mappage est de recevoir des données de base de données comme fichier XML plat. Le schéma cible SQL/XML a été généré avec XMLSpy, utilisant la commande de menu Convertir | Créer Schéma XML de la Structure BD.
DB_Altova_SQLXML.mfd
Comme illustré ci-dessus, chaque table de base de données possède un élément correspondant dans le XML cible. Lorsque vous prévisualisez le résultat de mappage, vous pouvez constater que les lignes de base de données de chaque table sont écrites dans les éléments "row" dans la cible.
Comme le montre la sortie XML, aucune hiérarchie n'existe entre les éléments XML ; il s'agit d'une structure SQL/XML plat. Les relations de base de données ont été ignorées parce que nous avons intentionnellement mappé des données depuis plusieurs tables "root".