La première longue section décrit en détail comment les métadonnées décrivant la base de données et le modèle SDO requis est fourni à DAS Relationnel.
Lorsque le constructeur de DAS Relationnel est appelé, il doit recevoir plusieurs informations. La majeure partie des informations, passée en tant qu'un tableau associatif dans le premier argument du constructeur, dit à DAS Relationnel ce qu'il doit savoir à propos de la base de données relationnelle. Il décrit les noms des tables, des colonnes, des clés primaires et des clés secondaires. On devrait comprendre assez facilement ce qui est requis et une fois écrit, il peut être placé dans un fichier PHP et inclut lorsque nécessaire. Le reste des informations, passé dans un deuxième et troisième arguments du constructeur, dit au DAS Relationnel ce qu'il doit savoir à propos des relations entre les objets et la forme du graphique de données; il détermine finalement comment les données de la base de données seront normalisées dans le graphique.
Le premier argument du constructeur décrit la base de données relationnelle cible.
Chaque table est décrite par un tableau associatif avec jusqu'à quatre clés.
| Clé | Valeur |
|---|---|
| name | Le nom de la table. |
| columns | Un tableau listant les noms des colonnes, dans n'importe quel ordre. |
| PK | Le nom de la colonne contenant la clé primaire. |
| FK | Un tableau avec deux entrées, "from" et "to" (provenance et destination), qui définissent une colonne contenant la clé étrangère et une table dans lequel la clé étrangère pointe. S'il n'y a pas de clé étrangère dans la table, alors l'entrée "FK" est optionnelle. Seulement une clé étrangère peut être spécifiée. Seulement une clé étrangère pointant à une clé primaire d'une table peut être spécifiée. |
<?php
/*****************************************************************
* MÉTADONNÉES DÉFINISSANT LA BASE DE DONNÉES
******************************************************************/
$company_table = array (
'name' => 'company',
'columns' => array('id', 'name', 'employee_of_the_month'),
'PK' => 'id',
'FK' => array (
'from' => 'employee_of_the_month',
'to' => 'employee',
),
);
$department_table = array (
'name' => 'department',
'columns' => array('id', 'name', 'location', 'number', 'co_id'),
'PK' => 'id',
'FK' => array (
'from' => 'co_id',
'to' => 'company',
)
);
$employee_table = array (
'name' => 'employee',
'columns' => array('id', 'name', 'SN', 'manager', 'dept_id'),
'PK' => 'id',
'FK' => array (
'from' => 'dept_id',
'to' => 'department',
)
);
$database_metadata = array($company_table, $department_table, $employee_table);
?>
Les métadonnées correspondent à une base de données relationnelle qui peut avoir été définie comme étant MySQL :
create table company ( id integer auto_increment, name char(20), employee_of_the_month integer, primary key(id) ); create table department ( id integer auto_increment, name char(20), location char(10), number integer(3), co_id integer, primary key(id) ); create table employee ( id integer auto_increment, name char(20), SN char(4), manager tinyint(1), dept_id integer, primary key(id) );
or to DB2 as:
create table company ( \ id integer not null generated by default as identity, \ name varchar(20), \ employee_of_the_month integer, \ primary key(id) ) create table department ( \ id integer not null generated by default as identity, \ name varchar(20), \ location varchar(10), \ number integer, \ co_id integer, \ primary key(id) ) create table employee ( \ id integer not null generated by default as identity, \ name varchar(20), \ SN char(4), \ manager smallint, \ dept_id integer, \ primary key(id) )
Notez que bien que dans cet exemple n'a pas de clé étrangère de spécifiée à la base de données et que la base de données n'est pas prévue à forcer l'intégrité référentielle, l'intention derrière la colonne co_id de la table departement et la colonne dept_id de la table employe est qu'elles pourraient contenir la clé primaire de leur compagnie les contenant ou l'enregistrement du département, respectivement. Alors ces deux colonnes actent comme des clés étrangères.
Il y a une troisième clé étrangère dans cet exemple, elle est de la colonne employe_du_mois de la table compagnie qui est compris dans une ligne de la table employe. Notez la différence dans l'intention entre cette clé étrangère et les deux autres. La colonne employe_du_mois représente une relation de valeurs simples : il peut y avoir seulement un employé du moi pour une compagnie donnée. Les colonnes co_id dept_id représentent des relations de valeurs multiples : une compagnie peut contenir plusieurs département et un département peut contenir beaucoup d'employés. Cette distinction deviendra évidente lorsque le reste des métadonnées sélectionne les relations entre la compagnie-département et le département-employé comme étant une relation contenue.
Il y a un peu de règles simples qui doivent être suivies lorsque l'on construit les métadonnées de base de données :
Toutes les tables doivent avoir des clés primaires et les clés primaires doivent être spécifiées dans les métadonnées. Sans clés primaires, il n'est pas possible de garder une trace des identités des objets. Comme vous pouvez le voir avec les requête SQL qui créent les tables, les clés primaires peuvent être générées automatiquement, ce qui signifie, qu'elles sont générées et assignées par la base de données lorsque l'enregistrement est inséré. Dans ce cas, la clé primaire générée automatiquement est obtenue de la base de données et insérées dans l'objet de données immédiatement après que la ligne soit insérée dans la base de données.
Il n'est pas nécessaire de spécifier les métadonnées de toutes les colonnes qui existent dans la base de données, seulement celles qui seront utilisées. Par exemple, si la table compagnie avait un autre colonne que l'application ne souhaite pas accéder avec SDO, il n'est pas nécessaire de la spécifiée dans les métadonnées. En contrepartie, cela ne devrait pas causer de problème de la spécifier : si elle est spécifiée dans les métadonnées mais jamais récupérée ou assignée par l'application, alors la colonne inutilisée ne devrait rien affecter.
Dans les métadonnées de base de données, notez que les définitions des clés étrangères n'identifient pas la colonne de destination dans la table qui est pointée, mais le nom de la table elle-même. Strictement, le modèle relationnel permet la destination d'une clé étrangère à être une clé non primaire. Seules les clés étrangères qui pointent à une clé primaire sont utiles pour la construction du modèle SDO, puisque les métadonnées spécifient le nom de la table. Il est entendu que la clé étrangère pointe vers la clé primaire d'une table donnée.
Ayant donné ces règles et les requêtes SQL qui définissent les bases de données, les métadonnées de base de données devrait être faciles à construire.
Le DAS Relationnel utilise les métadonnées de base de données pour former la plupart des modèles SDO. Pour chaque table dans les métadonnées de base de données, un type SDO est défini. Chaque colonne qui peut représenter une valeur primitive (les colonnes qui ne sont pas définies comme étant des clés étrangères) est ajoutée comme propriété au type SDO.
Toutes les propriétés primitives sont données par un type de chaîne de caractères dans le modèle SDO, sans se soucier de leur type SQL. Lors de la ré-écriture des données dans la base de données, le DAS Relationnel créera une requête SQL qui traitera les valeurs comme étant des chaînes de caractères et la base de données les convertira dans le type approprié.
Les clés étrangères sont interprétées de une des deux manières, dépendamment des métadonnées contenues dans le troisième argument du constructeur qui définissent les relations de SDO contenues. Une discussion de cela est donc reportée dans la section relations SDO contenues ci-dessous.
Le second argument du constructeur est l'application du type de racine. La vraie racine de chaque graphique de données est un objet d'un type de racine spécial et tous les objets de données des applications viennent quelque part sous cela. De la plupart des types d'application dans le modèle SDO, une doit être le type d'application immédiatement sous la racine du graphique de données. S'il y a seulement une table dans les métadonnées de base de données, le type de racine de l'application peut être impliqué et cet argument peut être omis.
Le troisième argument du constructeur définit comment les types dans le modèle seront liés ensemble pour former un graphique. Cela identifie les relations parent-enfant entre les types qui collectivement forment un graphique. Les relations doivent être supportées par les clés étrangères pour être trouvées dans les données, d'une manière rapide d'être décrit.
Les métadonnées sont un tableau contenant un ou plusieurs tableaux associatifs, chacun d'eux identifie un parent et un enfant. L'exemple ci-dessous montre une relation parent-enfant de compagnie au département et un autre du département aux employés. Chacune d'elles deviendra un propriété définissant une relation de valeur multiples contenue dans un modèle SDO.
<?php
$department_containment = array( 'parent' => 'company', 'child' => 'department');
$employee_containment = array( 'parent' => 'department', 'child' => 'employee');
$SDO_containment_metadata = array($department_containment, $employee_containment);
?>
Les clés étrangères dans les métadonnées de base de données sont interprétées comme des propriétés avec soit des relations de valeurs multiples contenues ou des références de simples valeurs non contenues, dépendamment si elles ont une relation SDO contenue correspondante spécifiée dans les métadonnées. Dans cet exemple ici, les clés étrangères du département à la compagnie (la colonne co_id dans la table de departement) et de l'employé au département (la colonne dept_id dans la table employe) sont interprétées comme supportant les relations SDO contenues. Chaque référence contenue mentionnée dans les métadonnées de relations contenue de SDO doit avoir une clé correspondante présente dans la base de données et définie dans les métadonnées de base de données. Les valeurs des colonnes de la clé étrangère pour les relations contenues n'apparaissent pas dans les objets de données; à la place, chacune d'entre elles est représentée par une relation contenue du parent à l'enfant. Alors la colonne co_id dans la ligne de département de la base de données, par exemple, n'apparaît pas en tant que propriété du type de département, mais apparaît à la place comme une relation contenue appelée departname sur le type de compagnie. Notez que la clé étrangère et la relation parent-enfant semble avoir un sens opposé : la clé étrangère pointe du département à la compagnie, mais la relation parent-enfant pointe de la compagnie au département.
La troisième clé dans cet exemple, le employe_du_mois, est gérée différemment. Elle n'est pas mentionnée dans les métadonnées de relations SDO contenues. Ceci a pour conséquence d'être interprété de la seconde manière : elle devient une référence de valeur simple non contenue sur l'objet compagnie, sur lequel vous pouvez assigner des références au type d'employé d'objets de données SDO. Elle apparaît comme une propriété du type de compagnie. Le moyen pour lui assigner une valeur dans le graphique de données est d'avoir un graphique qui contient un objet employé avec les relations contenues et d'assigner l'objet à celui-ci. Ceci est montré dans les exemples plus loin.