| |
Le tableau suivant présente une vue générale du mode d'assignation d'objets eDirectory à des objets de base de données par le pilote.
| Objet eDirectory | Objet Base de données |
|---|---|
Arborescence |
Schéma |
Classe |
Table |
Attribut |
Colonne |
Association |
Clé primaire |
Par classe de base de données logique, on entend l'ensemble des tables et des vues utilisées pour représenter une classe eDirectory dans une base de données. Une classe de base de données logique peut se composer d'une vue unique ou d'une table parent et de zéro ou plusieurs tables enfant. Le nom de la classe de base de données logique est le nom de la table ou vue parent.
Dans un modèle de synchronisation indirecte, le pilote procède aux assignations suivantes :
Dans l'exemple suivant, la classe de base de données logique « EMP » se compose d'une table parent EMP et d'une table enfant PHONE. Elle est assignée à la classe eDirectory User.
CREATE TABLE DIRXML.EMP
(
EMPNO NUMERIC(8) NOT NULL,
FNAME VARCHAR(64),
LNAME VARCHAR(64),
PWDMINLEN NUMERIC(4),
CONSTRAINT PK_EMPNO PRIMARY KEY (EMPNO)
);
CREATE TABLE DIRXML.PHONE
(
EMPNO NUMERIC(8) NOT NULL,
PHONE VARCHAR(64),
CONSTRAINT FK_EMPNO FOREIGN KEY (EMPNO) REFERENCES
EMP(EMPNO)
);
<rule name="MappingRule">
<attr-name-map>
<class-name>
<nds-name>User</nds-name>
<app-name>EMP</app-name>
</class-name>
<attr-name class-name="User">
<nds-name>Given Name</nds-name>
<app-name>FNAME</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Surname</nds-name>
<app-name>LNAME</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Password Minimum Length</nds-name>
<app-name>PWDMINLEN</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Telephone Number</nds-name>
<app-name>PHONE.PHONENO</app-name>
</attr-name>
</attr-name-map>
</rule>
Les tables parent sont des tables assorties d'une contrainte de clé primaire explicite qui contiennent une ou plusieurs colonnes. Dans une table parent, une contrainte de clé primaire explicite est requise pour indiquer au pilote les champs à inclure dans une valeur d'association.
CREATE TABLE DIRXML.EMP
(
EMPNO NUMERIC(8) NOT NULL,
...
CONSTRAINT PK_EMPNO PRIMARY KEY (EMPNO)
);
Tableau 1. Exemples de données de table DIRXML.EMP
| EMPNO | FNAME | LNAME |
|---|---|---|
1 |
Jean |
Untel |
L'association résultante pour cette ligne serait la suivante :
EMPNO=1,table=EMP,schema=DIRXML
Les colonnes de table parent ne peuvent contenir qu'une valeur. À ce titre, elles conviennent parfaitement pour l'assignation d'attributs eDirectory à valeur unique. Ainsi, l'attribut eDirectory à valeur unique Password Minimum Length (longueur minimale du mot de passe) serait assigné à la colonne de table parent PWDMINLEN.
Les données de type binaire et chaîne en grande quantité doivent en principe être assignées à des colonnes de table parent. Pour être assigné à une colonne de table enfant, un type de données doit pouvoir faire l'objet d'une comparaison dans une instruction SQL. Or, les types de données en grande quantité ne peuvent pas être comparés dans des instructions SQL.
Les données de type binaire et chaîne en grande quantité peuvent être assignées à des colonnes de table enfant si les événements de ces colonnes comprennent des éléments <remove-value> qui sont transformés dans les feuilles de style en éléments <remove-all-values> suivis d'une série d'éléments <add-value>, à raison d'un élément par valeur ajoutée.
Une table enfant est une table qui comporte une contrainte de clé étrangère sur la clé primaire de sa table parent, ce qui relie les deux tables entre elles. Les colonnes qui composent la clé étrangère de la table enfant DOIVENT porter le même nom que les colonnes contenues dans la clé primaire de la table parent.
L'exemple suivant illustre la relation qui existe entre la table parent EMP et sa table enfant PHONE. Notez que le même nom de colonne EMPNO est utilisé dans les deux tables.
CREATE TABLE DIRXML.EMP
(
EMPNO NUMERIC(8) NOT NULL,
...
CONSTRAINT PK_EMPNO PRIMARY KEY (EMPNO)
);
CREATE TABLE DIRXML.PHONE
(
EMPNO NUMERIC(8) NOT NULL,
PHONE VARCHAR(64),
CONSTRAINT FK_EMPNO FOREIGN KEY (EMPNO) REFERENCES
EMP(EMPNO)
);
Les tables enfant peuvent contenir plusieurs valeurs et conviennent donc parfaitement à l'assignation d'attributs eDirectory à valeurs multiples. Chaque attribut à valeurs multiples doit être assigné à une table enfant différente. Par exemple, l'attribut eDirectory Telephone Number (Numéro de téléphone) est assigné à la colonne PHONENO de la table enfant PHONE.
Tableau 2. Exemple de données de table enfant DIRXML.PHONE
| EMPNO | PHONENO |
|---|---|
1 |
111-1111 |
2 |
222-2222 |
En cas d'assignation d'un attribut eDirectory à valeurs multiples à une colonne de table enfant, le nom de cette dernière doit être précédé du nom de la table enfant (par exemple, PHONE.PHONENO).
Il s'agit d'établir des relations référentielles synchronisées entre des classes de base de données logiques à l'aide de plusieurs contraintes de clé étrangère. Dans l'exemple suivant, deux classes de base de données logiques, USERS et GROUPS, sont reliées par l'intermédiaire d'une table enfant unique, MEMBERS.
CREATE TABLE USERS
(
IDU NUMBER(8) NOT NULL,
LNAME VARCHAR(64) NOT NULL,
CONSTRAINT PK_USERS_IDU PRIMARY KEY (IDU)
);
CREATE TABLE GROUPS
(
IDG NUMBER(8) NOT NULL,
CONSTRAINT PK_GROUPS_IDG PRIMARY KEY (IDG)
);
CREATE TABLE MEMBERS
(
IDG NUMBER(8) NOT NULL,
MEMBER NUMBER(8) NOT NULL,
CONSTRAINT FK_MEMBERS_IDG FOREIGN KEY (IDG) REFERENCES
GROUPS(IDG),
CONSTRAINT FK_MEMBERS_MEMBER FOREIGN KEY (MEMBER)
REFERENCES USERS(IDU)
);
<rule name="Mapping Rule">
<attr-name-map>
<class-name>
<nds-name>User</nds-name>
<app-name>USERS</app-name>
</class-name>
<attr-name class-name="User">
<nds-name>Surname</nds-name>
<app-name>LNAME</app-name>
</attr-name>
<class-name>
<nds-name>Group</nds-name>
<app-name>GROUPS</app-name>
</class-name>
<attr-name class-name="Group">
<nds-name>Member</nds-name>
<app-name>MEMBERS.MEMBER</app-name>
</attr-name>
</attr-name-map>
</rule>
Dans l'exemple ci-dessus, l'attribut MEMBERS.MEMBER est considéré comme faisant partie de la classe GROUPS parce que la colonne IDG figure avant la colonne MEMBER dans la table MEMBERS.
Dans l'exemple suivant, l'attribut MEMBER_OF.GROUP est considéré comme faisant partie de la classe USERS parce que la colonne IDU figure avant la colonne GROUP dans la table MEMBER_OF.
CREATE TABLE USERS
(
IDU NUMBER(8) NOT NULL,
LNAME VARCHAR(64) NOT NULL,
CONSTRAINT PK_USERS_IDU PRIMARY KEY (IDU)
);
CREATE TABLE GROUPS
(
IDG NUMBER(8) NOT NULL,
CONSTRAINT PK_GROUPS_IDG PRIMARY KEY (IDG)
);
CREATE TABLE MEMBER_OF
(
IDU NUMBER(8) NOT NULL,
GROUP NUMBER(8) NOT NULL,
CONSTRAINT FK_MEMBER_OF_IDU FOREIGN KEY (IDU) REFERENCES
USERS(IDU),
CONSTRAINT FK_MEMBER_OF_GROUP FOREIGN KEY (GROUP)
REFERENCES GROUPS(IDG)
);
<rule name="Mapping Rule">
<attr-name-map>
<class-name>
<nds-name>User</nds-name>
<app-name>USERS</app-name>
</class-name>
<attr-name class-name="User">
<nds-name>Surname</nds-name>
<app-name>LNAME</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Group Membership</nds-name>
<app-name>MEMBER_OF.GROUP</app-name>
</attr-name>
<class-name>
<nds-name>Group</nds-name>
<app-name>GROUPS</app-name>
</class-name>
</attr-name-map>
</rule>
En général, il est seulement nécessaire de synchroniser les attributs référentiels dans l'une ou l'autre classe, pas dans les deux. Pour synchroniser les attributs référentiels des deux classes, il faudrait construire deux tables enfant, une par classe.
En pratique, pour la synchronisation des objets Utilisateur et Groupe, Novell recommande de synchroniser l'attribut Group Membership (Adhésion au groupe) de la classe Utilisateur au lieu de l'attribut Member (Membre) de la classe Groupe. En effet, en cas de synchronisation de l'attribut Member (Membre), il est possible que des événements relatifs aux utilisateurs non associés parviennent au canal Abonné. En cas de synchronisation de l'attribut Group Membership (Adhésion au groupe), seuls les groupes qui correspondent à des utilisateurs associés parviennent au canal Abonné.
Dans un modèle de synchronisation directe, le pilote procède aux assignations suivantes :
| Objet eDirectory | Objet Base de données |
|---|---|
Classes |
Vues |
Attributs |
Afficher les colonnes |
1 classe |
Vue |
Attribut à valeur unique |
Afficher la colonne |
Attribut à valeurs multiples |
Afficher la colonne |
Une vue est une table logique. Contrairement aux tables parent/enfant, elle n'existe pas physiquement dans la base de données. En tant que telles, les vues ne peuvent pas comporter de contraintes de clé primaire/clé étrangère. Pour indiquer au pilote les champs à utiliser lors de la génération de valeurs d'association, une ou plusieurs colonnes de vue doivent porter le préfixe « PK_ » (sans distinction majuscules/minuscules).
REMARQUE : Les vues doivent être construites de telle sorte que les colonnes dotées du préfixe « PK_ » identifient une ligne de façon unique.
Les fonctionnalités de mise à jour des vues sont très variables selon les bases de données. La plupart des bases permettent une mise à jour des vues dans certaines conditions. Si les vues sont strictement en lecture seule, il est impossible de les utiliser pour l'acheminement des données via le canal Abonné. Sous Microsoft SQL Server 2000 et Oracle 8i, 9i, il est possible de définir une logique de mise à jour sur les vues dans INSTEAD_OF_TRIGGERS, ce qui permet à une vue de joindre plusieurs tables tout en restant modifiable.
CREATE TABLE DIRXML.EMP
(
EMPNO NUMERIC(8) NOT NULL UNIQUE,
FNAME VARCHAR(64),
LNAME VARCHAR(64),
PWDMINLEN NUMERIC(4),
PHONENO VARCHAR(64)
);
CREATE VIEW DIRXML.VIEW_EMP
(PK_EMPNO, FNAME, LAME, PWDMINLEN, PHONENO)
AS
SELECT EMPNO, FNAME, LNAME, PWDMINLEN, PHONENO FROM DIRXML.EMP;
<rule name="MappingRule">
<attr-name-map>
<class-name>
<nds-name>User</nds-name>
<app-name>VIEW_EMP</app-name>
</class-name>
<attr-name class-name="User">
<nds-name>Given Name</nds-name>
<app-name>FNAME</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Surname</nds-name>
<app-name>LNAME</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Password Minimum Length</nds-name>
<app-name>PWDMINLEN</app-name>
</attr-name>
<attr-name class-name="User">
<nds-name>Telephone Number</nds-name>
<app-name>PHONENO</app-name>
</attr-name>
</attr-name-map>
</rule>
Par défaut, le pilote suppose que tous les attributs eDirectory assignés aux colonnes d'une table parent ou d'une vue sont à valeur unique. Comme le pilote ne reconnaît pas le schéma eDirectory, il n'a aucun moyen de savoir si un attribut eDirectory est à valeur unique ou à valeurs multiples. En conséquence, les assignations d'attributs à valeur unique et à valeurs multiples sont traitées à l'identique.
Le pilote met en oeuvre l'algorithme MRT (Most Recently Touched - Modifié en dernier) vis-à-vis des colonnes de table parent ou de vue à valeur unique. Un algorithme MRT garantit le stockage dans la base de données de la valeur d'attribut ajoutée ou supprimée en dernier. Cet algorithme fonctionne si l'attribut en question est à valeur unique et a des effets indésirables si l'attribut comporte plusieurs valeurs.
Lorsqu'une valeur est supprimée d'un attribut à valeurs multiples, le champ de base de données auquel elle est assignée sera défini comme vide (NULL) et le restera jusqu'à l'ajout d'une nouvelle valeur. Plusieurs solutions à ce comportement indésirable sont exposées ci-après.
| |