通过使用 JDBC 数据视图,可使 LDAP 客户端应用程序能够访问关系数据库。有关 JDBC 数据视图的工作方式的信息,请参见《Sun Java System Directory Server Enterprise Edition 6.3 Reference》中的“JDBC Data Views”。
有关如何创建和配置 JDBC 数据视图的信息,请参见以下过程。
无法使用 DSCC 执行此任务。请使用命令行,如以下过程所述。
为关系数据库创建 JDBC 数据源。
$ dpconf create-jdbc-data-source -h host -p port -b db-name -B db-url -J driver-url \ [-J driver-url]... -S driver-class source-name |
目前,每个 JDBC 数据视图只支持一个 JDBC 数据源。换句话说,您无法跨 JDBC 数据源实现负载平衡。要访问多个 JDBC 数据源,可以为每个数据源创建一个数据视图,然后通过联接视图将这些数据视图联接在一起。
在创建 JDBC 数据源时,必须设置以下属性:
关系数据库的名称,例如 payrolldb。
指向数据库的 URL,格式为 jdbc: vendor:driver://dbhost: dbport。
db-url 不是完整的 JDBC 数据库 URL,因为它不包含数据库名称。(数据库名称由 db-name 属性指定。)
对于 MySQL、DB2 和 Derby 数据库,db-url 必须以 / 结束;对于 Oracle 数据库,则必须以 : 结束。
JDBC 驱动程序类,例如 org.hsqldb.jdbcDriver。
JDBC 驱动程序所在的路径,例如 file:/// path/to/hsqldb/lib/hsqldb.jar。
driver-url 属性是多值属性。因此,driver-url 可以为 JDBC 驱动程序支持多个 JAR 文件,以确保连接到不同平台上的 JDBC 源。
创建 JDBC 数据源池。
$ dpconf create-jdbc-data-source-pool -h host -p port pool-name |
将 JDBC 数据源连接到此 JDBC 数据源池。
$ dpconf attach-jdbc-data-source -h host -p port pool-name source-name |
创建 JDBC 数据视图。
$ dpconf create-jdbc-data-view -h host -p port view-name pool-name suffix-DN |
(可选的)查看 JDBC 数据视图列表,以检查是否已成功创建数据视图。
$ dpconf list-jdbc-data-views -h host -p port |
无法使用 DSCC 执行此任务。请使用命令行,如以下过程所述。
查看 JDBC 数据视图的属性。
$ dpconf get-jdbc-data-view-prop -h host -p port view-name |
JDBC 数据视图的默认属性如下所示:
alternate-search-base-dn : - attr-name-mappings : none base-dn : o=sql1 contains-shared-entries : - description : - distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : - is-enabled : true is-read-only : false is-routable : true jdbc-data-source-pool : pool-name lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
更改步骤 1 中列出的一个或多个属性。
$ dpconf set-jdbc-data-view-prop -h host -p port view-name property:value \ [property:value ... ] |
JDBC 对象类。将一个或多个 JDBC 表映射到 LDAP 对象类。
JDBC 表。为每个关系数据库表定义。
JDBC 属性。从 JDBC 表的指定列中定义 LDAP 属性。
为关系数据库中的每个表创建 JDBC 表。
% dpconf create-jdbc-table jdbc-table-name db-table |
db-table 的名称区分大小写。请确保使用的大小写与关系数据库中使用的相同,否则针对该表的操作可能会失败。
为每个关系数据库表中的每个列创建 JDBC 属性。
% dpconf add-jdbc-attr table-name attr-name sql-column |
创建 JDBC 属性会将表列映射到 LDAP 属性。
(可选的)如果关系数据库中的列区分大小写,请更改 JDBC 属性的 LDAP 语法。
% dpconf set-jdbc-attr-prop table-name attr-name ldap-syntax:ces |
默认情况下,ldap-syntax 的值为 cis。这表明 jdbc-attr 不区分大小写。如果您的关系数据库区分大小写,请将值更改为 ces。
默认情况下,某些关系数据库(如 Oracle 和 DB2)区分大小写。LDAP 在默认情况下不区分大小写。当目录代理服务器检测到关系数据库表的某个列区分大小写时,在过滤器中具有相应属性的 ldapsearch 查询将被转换为使用函数 UPPER 的 SQL 查询。
例如,查询 ldapsearch -b "dc=mysuffix" "(attr=abc)" 将被转换为以下 SQL 查询:
SELECT * FROM mytable WHERE (UPPER(attr)='ABC') |
默认情况下,此类查询不会编制索引。因此,具有此特性的查询可能会造成较大的性能影响。
可通过以下两种方式减轻性能影响:
将 jdbc-attr 的 ldap-syntax 属性设置为 ces。
对于每个可能会在 LDAP 过滤器中使用的 jdbc-attr,使用函数 UPPER 创建索引。
如果关系数据库不区分大小写,请使用 ldap-syntax 的默认值,即 cis。不区分大小写的数据库不支持 ldap-syntax:ces。
为 LDAP 关系数据库表创建 JDBC 对象类。
% dpconf create-jdbc-object-class view-name objectclass primary-table \ [secondary-table... ] DN-pattern |
创建 JDBC 对象类实际上是指定将与这些表相关联的 LDAP 对象类。JDBC 对象类还将指定主表和从表(如果这些表存在)。
创建 JDBC 对象类时将指定 DN 模式。DN 模式用于描述将使用哪些属性来构建条目的 DN。例如,如果将 DN 模式指定为 uid,则会使用属性 uid 和数据视图的视图基来构建条目的 DN。例如,uid=bjensen,ou=people,dc=example,dc=com。DN 模式可以由多个属性组成。在这种情况下,应使用 ,(逗号)来分隔各个属性。例如,如果将 DN 模式指定为 uid,country,则数据视图返回的条目 DN 为 uid=bjensen,country=America,ou=people,dc=example,dc=com。
对于在 JDBC 对象类的 DN 模式中定义的所有子树组件,均应为其定义 JDBC 对象类。例如,如果 JDBC 对象类中具有 DN 模式 uid,ou,则应为 DN 模式 ou 定义一个 JDBC 对象类。这对于目录代理服务器构建结构正确的 DIT 很有必要。否则,在搜索结果中不会返回具有类似于 ou=xxx,base-DN 值的子树。
如果存在从表,请定义主表和从表之间的联接规则。
% dpconf set-jdbc-table-prop secondary-table-name filter-join-rule:join-rule |
联接规则在从表上进行定义,用于确定该表中的数据如何链接到主表数据。对象类主表和从表关系的定义方式非常重要。有关详细信息,请参见定义 JDBC 表之间的关系。
指定 JDBC 对象类的超类。
% dpconf set-jdbc-object-class-prop view-name objectclass super-class:value |
超类表示 JDBC 对象类所继承的 LDAP 对象类。
最简单的情况是 JDBC 对象类只包含一个(主)表。不存在从表,因此无需定义表之间的关系。
如果对象类包含多个表,则必须明确定义这些表之间的关系。表之间的关系始终在从表上进行定义。可以使用从表的以下属性定义这些关系:
is-single-row-table 指定 LDAP 条目在表中只有一个匹配行。
contains-shared-entries 指定从表中的一行由主表中的多个行使用。
filter-join-rule 表示应如何根据主表内容从从表中检索条目。
以下示例将说明如何根据前两个属性的值定义过滤器联接规则。这些示例假定对象类具有一个主表和一个从表。
以上是这些属性的默认值。在此案例中,主表和从表之间的关系为 n->1,也就是说,主表中的 n 个行将引用从表中的一个共享行。
在关系数据库中,外键 (foreign key, FK) 在主表中定义,它指向从表的某个列。
例如,在某个组织中,一位经理可以管理多名员工。定义了两个关系数据库表,结构如下:
primary table : EMPLOYEE [ID, NAME, FK_MANAGER_ID] secondary table : MANAGER [ID, NAME] |
定义了以下对象类和属性:
object-class : employee attr : name (from primary EMPLOYEE.NAME) attr : manager (from secondary MANAGER.NAME) |
在从表中定义了以下过滤器联接规则:
ID=\${EMPLOYEE.FK_MANAGER_ID}" |
如果存在多个从表,则必须为每个从表配置 filter-join-rule。有关如何为多个从表配置 filter-join-rule 的详细信息,请参见步骤 11。
在此配置下,LDAP 操作的运行方式如下:
添加员工条目。如果员工条目中的经理在表中不存在,将创建一个新行。如果该经理存在,则使用现有行。
替换条目中 "manager" 属性的值。MANAGER.NAME 行的值将发生更改。
删除员工条目。从表中的行不会删除,因为经理条目为共享条目。
从条目中删除 "manager" 属性。从表中的行将被删除,并且外键 (EMPLOYEE.FK_MANAGER_ID) 被设置为 NULL。
在此案例中,主表和从表之间的关系为 1->1 或 1<-1,也就是说,从表中的一行将引用主表中的一行。
在关系数据库中,外键 (foreign key, FK) 可能在主表中定义,也可能在从表中定义。
例如,在某个组织中,员工的 UID 存储在一个表中,其姓氏存储在另一个表中。定义了两个关系数据库表,结构如下:
primary table : UID [ID, VALUE, FK_SN_ID] secondary table : SN [ID, VALUE] |
定义了以下对象类和属性:
object-class : employee attr : uid (from primary UID.VALUE) attr : sn (from secondary ID.VALUE) |
在从表中定义了以下过滤器联接规则:
ID=\${UID.FK_SN_ID} |
此配置也可能是另外一种方式,即外键 FK_UID_ID 存储在从表中,并指向 UID.ID。
在此案例中,主表和从表之间的关系为 1->n,也就是说,从表中的 n 个行将引用主表中的一行。此示例说明了多值属性的情况。多值属性在从表中以一组行表示,每个属性值为一行。
在关系数据库中,外键在从表中定义,它指向主表中的某个列。
例如,在某个组织中,员工可以有多个电话号码。定义了两个关系数据库表,结构如下:
primary table : EMPLOYEE [ID, NAME] secondary table : PHONE [ID, VALUE, USER_ID] |
定义了以下对象类和属性:
object-class : employee attr : cn (from primary EMPLOYEE.NAME) attr : telephoneNumber (from secondary PHONE.VALUE) |
在从表中定义了以下过滤器联接规则:
USER_ID=\${EMPLOYEE.ID} |
目录代理服务器目前不支持此案例。