Gestionar relaciones de BD
Las bases de datos relacionales, tal y como indica su nombre, suelen tener relaciones definidas entre sus tablas. Por ejemplo, la base de datos Altova.sqlite de la carpeta <Documentos>\Altova\MapForce2023\MapForceExamples\Tutorial\ tiene estas relaciones:
•La compañía del ejemplo (correspondiente a la tabla "Altova") está compuesta como mínimo por una oficina (p. ej. Brenton y Vereno). En las bases de datos esto se denomina relación de uno a varios y este tipo de relación existe entre las tablas "Altova" y "Office". En otras palabras por cada registro PrimaryKey de la tabla "Altova" puede haber varios registros ForeignKey en la tabla "Office". Por tanto, los registros de "Office" donde el valor de ForeignKey se corresponda con el valor de PrimaryKey de "Altova" se considerarán oficinas de "Altova".
•Cada oficina está compuesta como mínimo por un departamento (p. ej. "Marketing", "IT", "Development"). Una vez más, podemos decir que existe una relación de uno a varios entre las tablas "Office" y "Department".
•Por último, cada departamento está compuesto como mínimo por un empleado. Por tanto, existe una relación de uno a varios entre las tablas "Department" y "Person".
Las relaciones entre las tablas de la base de datos son muy importantes en las asignaciones de datos porque MapForce controla dichas relaciones de base de datos cuando la base de datos se añade al diseño de asignación. Esto permite conservar las relaciones mientas se crean las asignaciones de datos. Veamos un ejemplo para comprenderlo mejor: añada la base de datos Altova.sqlite a la asignación (con el comando de menú Insertar | Base de datos). A las tablas que aparecen a continuación las llamaremos tablas raíz:
Tablas raíz
Si expandimos cualquier tabla raíz, aparecen todas las tablas relacionadas. Por ejemplo, si expandimos la tabla Office, aparece la jerarquía de tablas relacionadas con esta tabla:
•La flecha 
de una tabla indica que la tabla es una tabla secundaria. Por ejemplo, Address es una tabla secundaria de Office y Department es una tabla secundaria de Office, así como una tabla hermana de Address, por lo que ambas tienen el mismo nivel de sangría. Como puede ver, la relación en la asignación de datos se corresponde con el diagrama que aparece al principio de este apartado.
•La flecha 
indica que la tabla es una tabla primaria. Por ejemplo, Altova es la tabla primaria de Office.
Esta representación jerárquica de las tablas ayuda a conservar las relaciones que existen en la base de datos cuando la asignación lee o escribe datos en una base de datos. Por ejemplo, imaginemos que queremos obtener todos los registros de la tabla Person y escribirlos en un archivo XML agrupados por departamento. Concretamente, el archivo XML debería vincular todos los empleados con un departamento (más o menos como en la base de datos Altova.sqlite utilizada en este ejemplo):
Como muestra la imagen, el departamento "Administration" tiene tres empleados, "Marketing" tiene dos, "Engineering" tiene seis, etc.
Si queremos que cada empleado se asigne al departamento correcto, debemos usar como tabla raíz la tabla Department y después crear asignaciones de datos desde la tabla Person, que es una tabla secundaria de Department.
La asignación de la imagen anterior es una versión modificada del archivo DB_Altova_Hierarchical.mfd de la carpeta <Documentos>\Altova\MapForce2023\MapForceExamples\. En la vista previa de resultados veríamos que los empleados se agrupan por departamentos tal y como queríamos. Es decir, "Administration" tiene tres empleados, "Marketing" tiene dos, "Engineering" tiene seis, etc.
Ahora veamos otra versión de la misma asignación en la que las conexiones dibujadas convierten las tablas Department y Person en tablas raíz.
En esta ocasión, en la vista previa de resultados aparecen todos los empleados (sin importar su departamento de origen) en cada departamento de destino. Es decir, "Administration" tiene 21 empleados, "Marketing" tiene 21, "Engineering" tiene 21, etc.
En este segundo ejemplo, debido al modo en que se dibujaron las conexiones, MapForce no tiene en cuenta las relaciones de la base de datos.
Por tanto, si queremos conservar las relaciones de la base de datos, debemos asegurarnos de dibujar conexiones entre las mismas tablas raíz, pues estas contienen las tablas secundarias cuyas relaciones deseamos conservar, tanto si se trata de la base de datos de origen como de la de destino. Para ver ejemplos de asignaciones de datos que conservan las relaciones de las bases de datos consulte los archivos DB_Altova_Hierarchical.mfd y Altova_Hierarchical_DB.mfd de la carpeta <Documentos>\Altova\MapForce2023\MapForceExamples\ (véase Insertar datos en tablas vinculadas).
También puede darse el caso de que no sea necesario o conveniente conservar las relaciones de la base de datos. Por ejemplo, imaginemos que queremos exportar todos los datos de la base de datos altova.mdb a un archivo XML plano conforme a la especificación SQL/XML (parte 14 de la especificación SQL). Este tipo de asignación puede verse en el diseño DB_Altova_SQLXML.mfd de la carpeta <Documentos>\Altova\MapForce2023\MapForceExamples\. El objetivo de la asignación es obtener los datos de la base de datos en forma de archivo XML plano. El esquema SQL/XML de destino se generó con XMLSpy (con el comando Conversión | Crear esquema XML a partir de la estructura de la BD).
DB_Altova_SQLXML.mfd
Como muestra la imagen, a cada tabla de la base de datos le corresponde un elemento en el XML de destino. En la vista previa de resultados podemos ver que las filas de cada tabla de la base de datos se escriben en elementos "row" en el XML de destino.
Como puede verse en el XML de salida, no existen jerarquías entre los elementos XML, es decir, se trata de una estructura SQL/XML plana. Las relaciones de la base de datos se pasaron por alto porque se asignaron datos de varias tablas raíz de forma deliberada.