Access Control and the Database Adapter

Understanding Oracle Virtual Directory Adapters 2-7 After the JDBC libraries are loaded into Oracle Virtual Directory you can define a new Database Adapter connection by either selecting a predefined database type, or by specifying the JDBC URL as defined by the manufacturer. The Database Adapter supports predefined JDBC URLs for the following databases: ■ Hypersonic ■ IBM DB2 ■ Microsoft SQLServer ■ MySQL ■ OpenBase ■ Oracle ■ PostgreSQL ■ Sybase ■ Sun ODBC-JDBC Bridge

2.3.3 Understanding Database Adapter Mapping

The following is a list of aspects related to mapping relational data structures into a hierarchical directory when using the Database Adapter, including: ■ Entry Name Formation ■ Indexes for Mapped Tables ■ Multiple Table Writes ■ Multiple Valued Attributes ■ Searches and Multiple Row Objects ■ Writes to Tables ■ Cascading Deletes ■ Substring Searches Entry Name Formation All database fields that are used as part of an entrys name—except for the portion of the DN that is the adapters root—must be contained in the table rows that are mapped and returned to Oracle Virtual Directory through the Database Adapter. For example, to create a hierarchy in which user objects contain both a common name cn and an organizational unit ou in their DN, for example, cn=Joe User,ou=Marketing, both the cn and ou must be part of the entry. In pure LDAP, the ou attribute would not normally be required as it is part of the parent entry. Since databases are not hierarchical, you can generate multilevel DNs without requiring considerable new metadata to be created and managed to define hierarchy. Indexes for Mapped Tables To improve performance when using a Database Adapter, Oracle recommends creating the appropriate indexes on the database tables that are being mapped. For example, a table named employee contains columns named salary and employeename and the cn name is mapped to employeename. To improve performance, create a function index for employeename as follows: create index upper_employee on employee upperemployeename;