Esta primera amplia sección describe en detalle cómo los metadatos describen la base de datos y cómo se proporciona el modelo SDO requerido al DAS Relaiconal.
Cuando se invoca al constructor del DAS Relacional, es necesario pasarle varias piezas de información. El volumen de información, pasado como un array asociativo al primer argumento del constructor, indica al DAS Relacional qué necesita conocer sobre la base de datos relacional. Describe los nombres de las tablas, columnas, claves primarias y claves foráneas. and foreign keys. Debería ser bastante sencillo comprender los que se requiere, y una vez escrito se puede colocar en un fichero PHP e incluido cuando sea necesario. El resto de información, pasada en el segundo y tercer parámetros al constructor, indica al DAS Relacional qué necesita conocer sobre las relaciones entre objetos y la forma del grafo de datos; en última instancia determina cómo se van a normalizar los datos de la base de dtaos en un grafo.
El primer argumento del constructor describe la base de datos relacional objetivo.
Cada tabla se describe por un array asociativo con hasta cuatro claves.
| Clave | Valor |
|---|---|
| name | El nombre de la tabla. |
| columns | Un array listando los nombres de las columnas, en cualquier orden. |
| PK | El nombre de la columna que contiene la clave primaria. |
| FK | Un array con dos entradas, 'from' (desde) y 'to' (hacia), que define una columna de que contiene una clave foránea, y una tabla hacia la que apunta la clave foránea. Si no existen claves foráneas en la tabla, no es necesario especificar la entrada 'FK'. Sólo se puede especificar una clave foránea. Sólo se puede especificar una clave foránea que apunte a la clave primaria de la tabla. |
<?php
/*****************************************************************
* METADATOS QUE DEFINEN LA BASE DE DATOS
******************************************************************/
$tabla_compañía = array (
'name' => 'compañía',
'columns' => array('id', 'nombre', 'empleado_del_mes'),
'PK' => 'id',
'FK' => array (
'from' => 'empleado_del_mes',
'to' => 'empleado',
),
);
$tabla_departamento = array (
'name' => 'departamento',
'columns' => array('id', 'nombre', 'ubicación', 'número', 'id_comp'),
'PK' => 'id',
'FK' => array (
'from' => 'id_comp',
'to' => 'compañía',
)
);
$employee_table = array (
'name' => 'empleado',
'columns' => array('id', 'nombre', 'NS', 'director', 'id_dept'),
'PK' => 'id',
'FK' => array (
'from' => 'id_dept',
'to' => 'departamento',
)
);
$metadatos_bd = array($tabla_compañía, $tabla_departamento, $employee_table);
?>
Estos metadatos corresponden a una base de datos relacional que podría haber sido definida para MySQL como:
create table compañía ( id integer auto_increment, nombre char(20), empleado_del_mes integer, primary key(id) ); create table departamento ( id integer auto_increment, nombre char(20), ubicación char(10), número integer(3), id_comp integer, primary key(id) ); create table empleado ( id integer auto_increment, nombre char(20), NS char(4), director tinyint(1), id_dept integer, primary key(id) );
o para DB2 como:
create table compañía ( \ id integer not null generated by default as identity, \ nombre varchar(20), \ empleado_del_mes integer, \ primary key(id) ) create table departamento ( \ id integer not null generated by default as identity, \ nombre varchar(20), \ ubicación varchar(10), \ número integer, \ id_comp integer, \ primary key(id) ) create table empleado ( \ id integer not null generated by default as identity, \ nombre varchar(20), \ NS char(4), \ director smallint, \ id_dept integer, \ primary key(id) )
Observe que aunque en este ejemplo no existen claves foráneas especificadas en la base de datos y por lo tanto no se espera que la base de datos fuerce la integridad referencial, la intención de la columna id_comp de la tabla departamento y la columna id_dept de la table empleado es que deberían contener la clave primaria de su compañía contenedora o el registro del departamento, respectivamente. Así, estas dos columnas están actuando como claves forámeas.
Existe una tercera clave foránes en este ejemplo, que proviene de la columna empleado_del_mes del registro de la compañía a una única fila de la tabla empleado. Observe que la diferencia a propósito entre esta clave foránea y las otras dos. La columna employee_of_the_month representa una relación monoevaluada: sólo puede existir un empleado del mes para una compañía dada. Las columnas id_comp e id_dept representan relaciones polievaluadas: una compañía puede contener muchos departamentos y un departamento puede contener muchos empleados. Esta distinción será evidente cuando el resto de los metadatos identifiquen las relaciones compañia-departamento y departamento-empleado como relaciones de contención.
Existen unas pocas sencillas reglas a seguir al construir los metadatos de la base de datos:
Todas las tablas deben tener claves primarias, y las claves primarias deben ser especificadas en los metadatos. Sin claves primarias no es posible seguir la pista de identidades de objetos. Como se puede obcervar con las sentencias SQL que crean las tablas, las claves primarias pueden ser autogeneradas, esto es, generadas y asignadas por la base de datos cuando se inserta un registro. En este caso la clave primaria autogenerada se obtiene de la base de datos y es insertada en el objeto de datos inmediatamente después que insertar la fila en la base de datos.
No es necesario especificar en los metadatos todas las columnas que existen en la base de datos, solamente aquellas que serán usadas. Por ejemplo, si la compañía tuviera otra columna con la que la aplicación no quiere acceder con SDO, no es necesario que sea especificada en los metadatos. Por otra parte, tampoco sería perjudicial especificarla: si se especifica en los metadatos pero nunca se recupera,o se asigna mediante la aplicación, la columna no usada no afectará a nada.
En los metadatos de la base de datos observe que las definiciones de la clave foránea no identifican la columna destino en la tabla a la que apunta, sino a la tabla misma. Estrictamente, el modelo relacional permite que el destino de una clave foránea sea una clave no primaria. Solo las claves foráneas que apuntes a una clave primaria son útiles para construir el modelo SDO, por lo que los metadatos especifican el nombre de la table. Se entiende que la clave foránea apunte a la clave primaria de la tabla dada.
Dadas estas reglas, y dadas las sentencias SQL que definen la base de datos, debería ser fácil construir los metadatos de la base de datos.
El DAS Relacional usa los metadatos de la base de datos para formar la mayoría del modelo SDO. Para cada table de los metadatos de la base de datos se define un tipo SDO. Cada columna que pueda representar un valor primitivo (las columnas que no están definidas como claves foráneas) se añade como una propiedad del tipo SDO.
A todas las propiedades primitivas se les da un tipo string en el modelo SDO, sin tener en cuenta su tipo SQL. Cuando se vuelve a escribir valores en la base de datos, el DAS Relacional creará sentencias SQL que tratan los valores como string, y la base de datos los convertirá al tipo apropiado.
Las claves foráneas son interpretadas en una de dos formas, dependiendo de los metadatos del tercer argumento del constructor que define las relaciones de contención de SDO. Por lo tanto se aplaza una discusión de esto hasta la sección sobre relaciones de contención de SDO más abajo.
El segundo argumento del constructor es el tipo raíz de la aplicación. La verdadera raíz de cada grafo de datos es un objeto de un tipo raíz especial y todos los objetos de datos de la aplicación están en algún lugar por debajo de él. De los varios tipos de aplicación del modelo SDO, uno tiene que ser el tipo de aplicación inmediatemente por debajo de la raíz del grafo de datos. Si solo existe una tabla en los metadatos de la base de datos, el tipo raíz de la aplicación puede ser deducido, y este argumento se puede omitir.
El tercer argumento del constructor define cómo van a ser vinculados los tipos del modelo entre ellos para formar un grafo. Identifica las relaciones padre-hijo entre los tipos que colectivamente forman un grafo. Las relaciones necesitan ser soportadas por claves foráneas para ser encontradas en los datos, de una forma descrita dentro de poco.
Los metadatos son un array que contiene uno o más arrays asociativos, cada uno identificando un padre y un hijo. El ejemplo de abajo muestra una relación padre-hijo desde la compañía hacia el departamento, y otra desde el departamento hacia el empleado. Cada una se convertirá en una propiedad SDO que define una relación de contención polievaluada del modelo SDO.
<?php
$contenedor_departamento = array( 'parent' => 'compañía', 'child' => 'departamento');
$contenedor_empleado = array( 'parent' => 'departamento', 'child' => 'empleado');
$metadatos_contenedor_SDO = array($contenedor_departamento, $contenedor_empleado);
?>
Las claves foráneas de los metadatos de la base de datos son interpretadas como propiedades con relaciones de contención polievaluadas o referencias de no contención monoevaluadas, dependiendo de si tienen una relación de contención correspondiente especificada en los metadatos. En el ejemplo, las claves foráneas desde el departamento a la compañía (la columna id_comp de la tabla departamento) y desde el empleado al departamento (la columna id_dept de la tabla empleado) son interpretadas como soportando las relaciones de contención de SDO. Cada relación de contención mencionada en los metadatos de las relaciones de contención de SDO deben tener una clave foránea correspondiente presente en la base de datos y ser definidas en los metadatos de la base de datos. Los valores de las columnas de clave foránea para las relaciones de contención no aparecen en los objetos de datos, en su lugar cada uno es representado por una relación de contención desde el padra al hijo. Así, la columna id_comp de la fila departamento de la base de datos, por ejemplo, no aparece como una propieadad del tipo departamento, sino como una relación de contención llamada departamento en el tipo compañía. Observe que la clave foránea y la relación padre-hijo parecen tener significados opuestos: la clave foránea apunta desde el departamento hacia la compañía, mientras que la relación padre-hijo apunta desde la compañía hacia el departamento.
La tercera clave foránea de este ejemplo, el empleado_del_mes , es tratada de forma diferente. No es mencionadaen los metadatos de las relaciones de contención de SDO. Como consecuencia es interpretada de la segunda forma: se convierte en una referencia de no contención monoevaluada del objeto compañía, a la que se le pueden asignar referencias a objetos de datos de SDO del tipo empleado. No aparece como una propiedad del tipo compañía. La forma de asignarle un valor en el grafo de datos SDO es tener un grafo que contenga un objeto empleado a través de las relaciones de contención, y asignarle el objeto. Esto es ilustrado en los ejemplos de más de abajo.