On Bounding-Schemas for LDAP Directories Sihem Amer-Yahia
AT&T Labs{Research
[email protected]
H. V. Jagadish
Laks V. S. Lakshmanan
U of Michigan, Ann Arbor
[email protected]
Concordia University and IIT{Bombay
[email protected]
Divesh Srivastava
AT&T Labs{Research
[email protected]
Abstract As our world gets more networked, ever increasing amounts of information|e.g., about people, network resources, and policies|are being stored in directories, in particular, in X.500 style directories that use the lightweight directory access protocol (LDAP). While LDAP directories have considerable exibility in the modeling and retrieval of information for network applications, the notion of schema they provide for enabling consistent and coherent representation of directory information is rather weak. In this paper, we propose an expressive notion of bounding-schemas for LDAP directories, and illustrate their practical utility. Bounding-schemas are based on lower bound and upper bound speci cations for the content and structure of an LDAP directory. Given a bounding-schema speci cation, we present algorithms to eciently determine: (i) if an LDAP directory is legal, i.e., it satis es the bounding-schema, (ii) if directory insertions and deletions preserve legality, and (iii) if a bounding-schema is consistent, i.e., there is at least one LDAP directory instance that satis es the bounding-schema. Finally, we show that the notion of bounding-schemas has wider applicability, beyond the speci c context of LDAP directories.
1 Introduction X.500 style directories have proliferated with the growth of the Internet, and are being used to keep track of a wide variety of information such as corporate white pages about people and organizations, network resources and policies [1], and operating system resources [11]. The dominant protocol for accessing such information is the lightweight directory access protocol (LDAP), and such directories have come to be known as LDAP directories. In a nutshell, an LDAP directory consists of nodes (referred to as directory entries) organized in a forest, with each directory entry containing a set of (attribute, value) pairs for some entity, and the hierarchy (forest) of entries typically re ecting real-world organizational and functional classi cations. LDAP directory applications then retrieve entries that match (a boolean combination of) conditions on individual attributes, the retrieval typically scoped to some subtree of the hierarchy. In most directory applications, entities of the same type may be quite heterogeneous. For example, person john may have no e-mail address (or may have deliberately suppressed it), person jack may have a single e-mail address, while person mary may have multiple e-mail addresses. Again, jack may have no cellular phone number, while both john and mary may have one. In such situations, relational databases have used null values, with limited success, in an attempt to capture the heterogeneity. A possible solution might be to treat e-mail address as a set-valued attribute; however, this su ers from the disadvantage of introducing an additional level of indirection for accessing an e-mail address, and is also very inecient in representation if it turns out that only a small fraction of persons do have multiple e-mail addresses. De ning sub-types of person based on the existence of certain attributes, while sometimes useful, does not always work well: as is evident from the previous example, the number of sub-types could become combinatorial in the number of attributes. Given the pervasive heterogeneity of entities represented in the directory, traditional class de nitions and traditional class inheritance are both inappropriate as directory schema elements. LDAP directories facilitate the modeling of heterogeneous real-world entities using two complementary approaches. First, an attribute associated with an object class (a term used in the LDAP literature for a weak notion of class) may be denoted to be an allowed attribute, permitting each entity that belongs to that object class to specify zero or more distinct values for this attribute. Thus, e.g., cellularPhone can be speci ed to be an allowed attribute of object class person. Second, an object class can be denoted as auxiliary, permitting an entity to belong to zero or more auxiliary object classes, and to specify (possibly multiple) values for the attributes of the auxiliary object classes. This is in contrast to requiring, as is traditionally the case in object-oriented databases, that an entity belong to a single, most-speci c class in a class hierarchy. Thus, e.g., an object class online, with allowed attribute mail, can be denoted as auxiliary, and both a person entity and an organization entity can additionally belong to object class online. We argue in this paper that LDAP schemas, while very exible, are too weak for their intended 1
usage of enabling information to be represented in the directory in a consistent fashion. One cannot restrict inappropriate combinations of object classes. For example, one cannot prohibit a person entity from also belonging to the auxiliary object class packetRouter. Similarly, even though entities are structured in a forest, usually with some principles in mind, there is no way to specify the principles or structural rules that have been followed. For example, we might want to require that each organization have a person as a descendant, and prohibit any person entity from having an organization entity as a child. There is no mechanism for stating and enforcing such schema speci cations in the LDAP model. The purpose of this paper is to address such limitations, thereby ensuring that applications have a consistent and coherent view of the directory data.
1.1 Contributions and Organization In this paper, we make the following contributions:
We propose a rich and useful notion of schema called bounding-schemas, that restricts legal
directory instances, without sacri cing the exibility o ered by the LDAP model (Section 2). The basic idea is to specify both lower bounds and upper bounds on both (i) Content Schema: what attributes and object classes to expect for any entity type, and (ii) Structure Schema: what hierarchical relationships to expect between entity types represented in the directory.
We present algorithms to eciently determine: (i) if an LDAP directory is legal, i.e., it satis es the bounding-schema (Section 3), and (ii) if directory updates preserve legality (Section 4). A key component of our algorithms is a natural reduction from structure bounding-schema speci cations to hierarchical directory queries of [9], such that an LDAP directory is legal if and only if the corresponding hierarchical query evaluated against the directory is empty.
We describe a procedure based on an inference system, to determine whether a bounding-
schema is consistent, i.e., there is at least one LDAP directory that satis es the boundingschema (Section 5). The main novelty of our inference system is the complex interaction between the content and the structure bounding-schema speci cations, in the presence of object class hierarchies.
We demonstrate that the notion of bounding-schemas has wider applicability, beyond the speci c context of LDAP directories, to semi-structured data models (Section 6).
1.2 Motivating Example We now describe a simple corporate white pages directory to motivate the need for boundingschemas in LDAP directories. More sophisticated directories, such as those for directory-enabled network (DEN) applications, also exhibit similar needs for bounding-schemas. 2
o: att objectClass: organization objectClass: orgGroup objectClass: online objectClass: top uri: http://www.att.com/
ou: attLabs objectClass: orgUnit objectClass: orgGroup objectClass: top location: FP
uid: armstrong objectClass: staffMember objectClass: person objectClass: top name: m armstrong
ou: databases objectClass: orgUnit objectClass: orgGroup objectClass: top
uid : laks objectClass: researcher objectClass: facultyMember objectClass: person objectClass: online objectClass: top name: laks lakshmanan mail:
[email protected] mail:
[email protected]
uid: suciu objectClass: researcher objectClass: person objectClass: top name: dan suciu
Figure 1: A Corporate White Pages Directory Instance An organization like AT&T employs a diverse collection of persons, such as researchers, developers, managers, secretaries, consultants, summer students, short term visitors, etc. These persons work in a wide variety of organizational units, across the organization. A corporate white pages directory needs to contain information both about the individual persons and the organizational units, in order to support a variety of queries about individual employees, managers in given organizational units, etc. LDAP directories are very well suited for white pages directories, and are used extensively for this purpose. A fragment of a corporate white pages LDAP directory is depicted in Figure 1. The directory consists of an entry for each employee, and for each organization unit. Information about an entity is represented as a set of (attribute, value) pairs in the directory entry corresponding to the entity. For example, the entry corresponding to person laks contains, among other (attribute, value) pairs, two values for the attribute mail. The values of the special attribute objectClass denote the various types associated with the entity. The hierarchical organization of the directory entries in the corporate white pages re ects a natural organizational hierarchy. Employees directly belonging to an organization unit are created as children entries of the entry corresponding to the organizational unit. Thus, persons suciu and laks directly belong to the databases organizational unit, and indirectly belong to the attLabs organizational unit. 3
Schema speci cations are important to ensure coherency of data, and to re ect the principles used in structuring the data in the directory. One useful \content schema" speci cation to ensure a certain basic level of consistency among the various employees is to require that each person entry in the directory specify values for the attributes name and uid. Again, while person entries can additionally belong to facultyMember, it is natural to forbid an orgUnit from also belonging to facultyMember. Similarly, \structure schema" speci cations would require that each orgUnit have at least one person as a descendant, and forbid person entries from having children entries. This combination of lower bound (required) and upper bound (forbidden) schema speci cations give rise to the notion of bounding-schemas for directories. Bounding-schemas ensure coherency of data, while permitting considerable heterogeneity in the directory instance.
2 Bounding-Schemas The directory data model centers around the notions of attributes and object classes. We assume in nite sets A; C of attributes and object classes, as well as a set T of types. Each type t 2 T S has an associated domain, denoted dom(t). We use dom(T ) to abbreviate t2T dom(t). We also assume the existence of a function : A ! T that associates a type with each attribute. Without loss of generality, we assume that the attribute objectClass is in A, that T includes the basic type string, and that (objectClass) = string.
2.1 Directory Instance Just as the relational model uses relations as a single uniform data structure, the directory model uses a forest as a single data structure. We call nodes of this forest directory entries. Each entry may \hold" information in the form of a set of (attribute, value) pairs. Informally, an entry may be regarded as an entity and an object class as an entity type. These intuitions are formalized below. We assume an in nite set R of objects called directory entries.
De nition 2.1 [Directory Instance] A directory instance D = (R; class; val; N ) is such that: 1. R R is a nite set of directory entries. 2. the function class : R ! 2C associates with each directory entry a nite, non-empty set of object classes from C , to which the entry belongs. 3. val : R ! 2Adom(T ) is a function that associates with each directory entry a nite set of (attribute, value) pairs such that the following conditions are satis ed: (a) for each entry r 2 R, if val(r) contains a pair (a; v ) then (a) = t and v 2 dom(t), for some t 2 T . That is, the value v must be of the right type. 4
(b) for every object class c 2 C , for every directory entry r 2 R, (objectClass; c) 2 val(r) i c 2 class(r). That is, the object classes that r belongs to must be the values of r's objectClass attribute. 4. N R R is a binary relation, such that the graph (R; N ) is a forest.1
2.2 Directory Schema A directory schema consists of two components, re ecting the nature of directory instances. The rst component is a content schema, which says what attributes and object classes to expect for entity types represented in the directory, and is itself subdivided into two parts: an attribute schema and a class schema. The second component is a structure schema, which says what hierarchical relationships to expect between entity types represented in the directory. We now formally present the di erent components of a directory schema.
De nition 2.2 [Attribute Schema] An attribute schema A = (C; A; r; a) consists of: (1) a nite set of object classes C C , (2) a nite set of attributes A A, (3) a function r : C !2A that speci es the required attributes for each object class, and (4) a function a : C !2A that speci es the allowed attributes for each object class. We require that r (c) a (c); 8c 2 C . Attribute schemas are part of the standard LDAP schema speci cation. The intuition is that a directory entry that belongs to a given class must have one or more values for each of the required attributes of the class, and may have zero or more values for the additional allowed attributes of the class. For example, attributes name and uid could be required attributes of object class person in the white pages directory of Figure 1. We do not present the complete attribute schema for the white pages directory due to lack of space. Since a directory entry can belong to multiple object classes, the attribute schema is not suf cient by itself to identify which attribute cannot occur in an entry, or which attributes cannot co-occur. The class schema, described next, will help us resolve this issue. LDAP directories distinguish between core object classes2 and auxiliary object classes. Notationally, we assume that the classes C are partitioned into in nite sets Cc of core classes and Cx of auxiliary classes. We next de ne the notion of a class schema.
De nition 2.3 [Class Schema] A class schema H = (C; E; Aux) consists of: In an LDAP directory, each entry is associated with a \distinguished name", and the set of distinguished names induces the forest structure. For the purposes of this paper, distinguished names are not important, and the abstraction of a forest simpli es the presentation. 2 Core object classes are referred to as \structural" object classes in the LDAPv3 proposed standard [16, 15]. We use the term \core" class to avoid confusion with the structure schema of a directory. 1
5
top
orgGroup { online }
organization
person { online }
orgUnit staffMember { manager, secretary, consultant }
researcher { manager, consultant, facultyMember }
Figure 2: Class Schema
A nite set of core object classes Cc = C \ Cc, which contains the special object class top. A binary relation E Cc Cc, such that the graph (Cc; E ) is a tree with top as its root.
Informally, the tree (Cc; E ) represents a single inheritance hierarchy of core classes. If an entry e belongs to core object class ci , and cj is the parent (or, superclass) of ci, then e is required to belong to cj as well. We denote this by ci | cj . Furthermore, for core object classes ci and cj , when neither of ci and cj is a superclass of the other, the single inheritance semantics forbids any entry e from belonging to both ci and cj . We denote this by ci | cj .
A set of auxiliary classes Cx = C \ Cx. A function Aux : Cc!2Cx that associates a set of auxiliary classes with each core class. Informally, an entry that belongs to a core class c may also belong to classes in Aux(c). For the white pages directory application, the class schema is depicted in Figure 2. The core object classes form a single inheritance hierarchy, e.g., we can see that organization | orgGroup holds, and we may conclude organization | person. Further, the auxiliary object classes associated with each core object class are indicated in parentheses. Based on this class schema, laks belongs to the core object classes researcher, person and top, and the auxiliary object classes facultyMember and online. We have focused on the di erent components of a directory's content schema so far. We present the structure schema next.
De nition 2.4 [Structure Schema] A structure schema is a triple S = (Cr; Er; Ef ) of required
object classes Cr , required structural relationships Er , and forbidden structural relationships Ef , de ned as follows:
Cr Cc is a subset of core object classes. We use the notation c to denote that c 2 Cr .
Informally, c says that there must be at least one directory entry one of whose core object classes is c. 6
orgGroup
organization
orgGroup
orgGroup
person
person
organization
top
orgUnit orgUnit
orgUnit
Figure 3: Structure Schema
Er Cc fch; de; pa; ang Cc is a relation. We use the notations ci ?! cj , ci ?!! cj , cj ?! ci , and cj ?!! ci to denote triples of the form (ci ; ch; cj), (ci; de; cj), (ci; pa; cj) and (ci; an; cj ), respectively, in Er . Informally, ci ?! cj says each entry that belongs to object class ci must have at least one entry that belongs to object class cj as its child. Other patterns have an analogous meaning.
Ef Cc fch; deg Cc is a relation. We use the notation ci ?! cj ; ci ?! ! cj to denote triples of the form (ci ; ch; cj ); (ci; de; cj ) in Ef . Informally, ci ?! cj says for no pair of entries, say ei and ej , that belong to object classes ci and cj respectively, can ej be a child of ei . ci ?! ! cj has a similar meaning.
For the white pages directory application, the structure schema is depicted in Figure 3. For example, the required structural relationship orgGroup ?!! person intuitively says that every organizational group must (directly or indirectly) employ a person. Such a person could additionally belong to either of the object classes researcher or staffMember; the structure schema does not mandate either. Similarly, the forbidden structural relationship person ?! top says that a person cannot have any child in a legal directory instance.
De nition 2.5 [Directory Schema] A directory schema S = (A; H; S) consists of an attribute schema A, a class schema H, and a structure schema S. A schema corresponding to the directory instance of Figure 1 would have the attribute schema sketched following De nition 2.2, the class schema of Figure 2, and the structure schema of Figure 3. It is easy to verify that the directory instance lies within the bounds imposed by this schema.
2.3 Legal Directory Instance Intuitively, a directory instance is said to be legal if it satis es the intention of each of the three components of the bounding-schema. We formalize this intuition below, with the help of the following de nition.
De nition 2.6 [Schema Element Satisfaction] We de ne satisfaction of a schema element by a directory instance D = (R; class; val; dn), denoted D j= , as follows: 7
When is c , D j= provided R contains at least one directory entry that belongs to core object class c.
When is ci ?! cj (resp., ci ?!! cj , cj ?! ci and cj ?!! ci), D j= provided when-
ever R contains an entry ei that belongs to object class ci , ei has a child (resp., descendant, parent, ancestor) entry ej that belongs to object class cj .
When is ci | cj , D j= provided every entry that belongs to object class ci in R also belongs to object class cj .
When is ci ?! cj (resp., ci ?! ! cj ), D j= provided R contains no pair of entries ei; ej
that belong to core classes ci ; cj respectively, such that ej is a child (resp., descendant) of ei .
When is ci | cj , D j= provided no entry in R belongs both to object class ci and to object class cj .
De nition 2.7 [Legal Directory Instance] Let S be a schema and D = (R; class; val; dn) a directory instance. We say D is legal w.r.t. S provided D satis es the following conditions: Attribute Schema : For every entry e in R, the following conditions on val(e) must be satis ed: if c 2 class(e) and a 2 r (c), then val(e) must contain an (attribute, value) pair (a; v), for some value v . That is, each required attribute must be present. for each (a; v) 2 val(e), class(e) must contain an object class c, such that a 2 a(c). That is, only allowed attributes may be present.
Class Schema : For every entry e in R, the following conditions on class(e) must be satis ed: for every object class c 2 class(e), it must be the case that c 2 C . That is, only object
classes mentioned in the schema may be present. class(e) must contain at least one (core) object class from Cc. D j= for every schema element of the forms ci | cj and ci | cj . That is, single inheritance of the core object classes must be respected. for every object class cx 2 class(e) such that cx 2 Cx, class(c) must contain a core object class cc 2 Cc such that cx 2 Aux(cc ). That is, only allowed auxiliary classes may be present.
Structure Schema : D j= for every schema element of the forms ci ?! cj , ci ?!! cj , cj ?! ci , cj ?!! ci, ci ?! cj , ci ?! ! cj and c . For example, the fragment of the white pages directory instance depicted in Figure 1 is legal w.r.t. the bounding-schema depicted in Figures 2 and 3. 8
2.4 Philosophy of the Directory Data Model The directory data model has a fundamentally di erent philosophy for its key modeling primitives of attributes and object classes, compared with traditional relational and object-oriented data models. First, directory attributes are all in a single namespace, i.e., the de nition of an attribute is independent of the object classes in which the attribute is present. Second, auxiliary object classes provide a exible way for directory entries to belong to multiple object classes; using multiple inheritance to achieve a similar objective can lead to a combinatorial explosion in the number of object classes in the schema. Third, all the attributes in a schema are multi-valued; individual values are not associated with the object classes to which the entry belongs, but only with the directory entry itself. Finally, the directory data model de nes a hierarchical namespace for entries, which enables distributed management of entries across multiple directory servers, while still permitting a conceptually uni ed view of the data. In contrast, traditional (relational and object-oriented) data models associate attributes with tables or classes; attributes with the same name may have di erent meanings (and even di erent types) in di erent classes. A consequence is that object-oriented data models that permit multiple inheritance must deal with attribute name clashes, when superclasses of a given class have attributes with the same name. Further, in this case, objects belonging to the subclass must have a separate value for each of the homonymous attributes inherited by the subclass.
3 Testing Legality of Directory Instances The principal reason for specifying a directory schema is to ensure consistent and coherent representation of information in the directory. This is guaranteed by testing legality of instances.
3.1 Content Schema Testing that a directory instance is legal with respect to the content schema, i.e., the attribute and class schemas, can be performed on each directory entry independently. Essentially, the test involves verifying that each directory entry contains the required object class co-occurrences and attributes, and only contains the allowed object class co-occurrences and attributes. Testing that an entry e satis es the class schema can be performed in a straightforward manner in time O(jclass(e)j+maxc2Cc (jAux(c)j)depth(H)), where jclass(e)j is the number of object classes that entry e belongs to, depth(H) is the depth of the core class hierarchy, and maxc2Cc (jAux(c)j) denotes the maximum number of auxiliary classes associated with any core class in the schema. Testing that an entry e satis es the attribute schema can be performed in a straightforward P manner in time O(jval(e)j + c2class(e) (j a(c)j)), where jval(e)j is the number of (attribute, value) pairs of e, and j a(c)j denotes the number of allowed attributes associated with object class c. 9
3.2 Structure Schema Testing that a directory instance is legal with respect to the structure schema, in particular the required and forbidden structural relationships, involves checking a set of binary relationships between directory entries. A straightforward approach would compare every pair of (parent, child) entries and every pair of (ancestor, descendant) entries, against the structure schema. This approach has the following drawbacks:
It takes time O((jErj + jEf j) jDj ), where Er is the set of required structural relationships, 2
and Ef is the set of forbidden structural relationships. This is quadratic in the size of the directory instance D.
An important problem concerning legality is eciently testing its preservation under directory updates. The above approach o ers little insight into this problem.
We now present an elegant and ecient technique for testing legality against the structure schema. First, we focus only on the required and forbidden structural relationships, Er and Ef , of S. The key idea behind our technique for testing legality of a directory instance D against (Er; Ef ) is to translate each relationship in Er and each relationship in Ef into a hierarchical selection query in the directory query language introduced in [9]. We then show that D is legal w.r.t. (Er ; Ef ) if and only if each of the hierarchical selection queries thus obtained (and hence their disjunction) is empty. It was established in [9] that every hierarchical selection query Q can be evaluated very eciently, with an I/O complexity of O(jQj jDj), where jQj is the size of the query Q, when the directory entries are sorted. This forms the basis for an ecient test for legality w.r.t. (Er ; Ef ). Consider the required structural relationship orgGroup ?!! person from our white pages directory. Recall that ci ?!! cj says each entry that belongs to object class ci must have at least one descendant entry that belongs to object class cj . The hierarchical selection query (d (objectClass=orgGroup) (objectClass=person)) retrieves each directory entry that belongs to object class orgGroup provided that it has at least one descendant entry that belongs to object class person. The following hierarchical selection query retrieves the remaining directory entries that belong to object class orgGroup:
Q1 : (?
d
(objectClass=orgGroup) (
(objectClass=orgGroup)(objectClass=person)))
Observe that a directory instance D is legal w.r.t. the relationship orgGroup ?!! person if and only if the query Q1 evaluated against D is empty. The other required structural relationships in Er can be translated to hierarchical selection queries [9] in an analogous manner. Consider now a forbidden structural relationship of the form person ?! top from our white pages directory. Recall that ci ?! ! cj says for no pair of entries, say ei and ej , that belong to object classes ci and cj respectively, can ej be a descendant of ei . Thus, the query 10
Schema Element ci
?! ?! ?!! ?!! ?! ?! !
cj
cj ci
ci
cj
cj
ci
ci
cj
ci
cj
c
Hierarchical Selection Query
(? (objectClass=ci) (c (objectClass=ci) (objectClass=cj)))
(? (objectClass=ci) (p (objectClass=ci) (objectClass=cj)))
(? (objectClass=ci) (d (objectClass=ci) (objectClass=cj)))
(? (objectClass=ci) (a (objectClass=ci) (objectClass=cj))) (c (objectClass=ci) (objectClass=cj)) (d (objectClass=ci) (objectClass=cj)) (objectClass=c)
Figure 4: Translating Structure Schema to Hierarchical Selection Queries
Q2 : (c
(objectClass=person) (objectClass=top))
evaluated against D is empty if and only if D is legal w.r.t. person ?! ! top. The other forbidden structural relationship in Ef can be translated to a hierarchical selection query in an analogous manner. The complete set of translations from relationships in Er and Ef to hierarchical selection queries is provided in Figure 4. Finally, we focus on the required object classes Cr of S. Recall that c says that there must be at least one directory entry one of whose object classes is c. As an example, a requirement such as orgUnit , from our white pages directory, is satis ed by D i the query:
Q3 : (objectClass=orgUnit) evaluated against D is non-empty. So, D is legal w.r.t. Cr if and only if each of the atomic selection queries thus obtained (and hence their conjunction) is non-empty. To summarize, ecient legality testing of D against the structure schema S is based on reductions to directory queries, which are known to be eciently evaluable.
Theorem 3.1 (Legality Testing) : Consider a directory instance D and a directory schema S = (A; H; S). Testing if D is legal w.r.t. S can be performed in time O(jDj (maxe2D (jclass(e)j)+ P maxc2Cc (jAux(c)j) depth(H) + maxe2D (jval(e)j) + maxe2D ( c2class e (j a(c)j)) + jSj)). ( )
4 Testing Legality Against Updates We now describe how to eciently check whether updates to the directory instance preserve legality.
4.1 Granularity of Updates for Testing Legality The entries in an LDAP directory instance are organized in a forest. LDAP directories require that newly created entries must either be roots in the forest, or must be children of existing directory 11
entries. Similarly, LDAP directories allow only leaf entries to be deleted from the forest; a directory entry that has descendants cannot be deleted, unless all its descendants are rst deleted. We consider \update transactions", consisting of a sequence of distinct directory entry insertions and deletions. Our goal is to incrementally determine whether such an update transaction would preserve legality. A key question before we can proceed with checking preservation of legality under updates is: what is a meaningful granularity of updates for testing legality? Testing legality at the granularity of a single directory entry insertion or deletion is not a robust choice, under the notion of a directory schema. The problem is that violation of legality caused by one update operation may be reversed by another update operation in the same transaction, which is awkward. Consider for example, the directory instance fragment shown in Figure 1. Suppose that the directory instance is updated by adding a new orgUnit entry as a child of the attLabs entry, and by adding a few person entries as children of the newly created orgUnit, such that the updated directory instance is legal. However, if one were to test for legality immediately after the new orgUnit entry had been added, the required structural relationship orgGroup ?!! person would be violated, because none of its person child entries has been added yet. While one could use the entire sequence of directory entry insertions and deletions as the granularity for testing preservation of legality, such an approach is neither modular, nor does it allow an elegant characterization of cases where incremental legality checking is possible. For the purpose of our analysis, we propose abstracting a directory update transaction as inserting a set of subtrees into, and deleting a set of subtrees from, the forest, where no two subtree roots form an (ancestor, descendant) pair. This abstraction has a very desirable modularity property as shown by the following result.
Theorem 4.1 Let S be a directory schema, and D a legal instance of S . Consider an update transaction U that is a sequence of distinct directory entry insertions into and deletions from D. Let D 0 denote the directory instance obtained by applying U to D . Let D ; : : :; Dn denote the subtrees inserted into D as a result of U , and Dn ; : : :; Dm denote the subtrees deleted from D as a result of U . Let Di ; 1 i m denote the instance obtained by updating Di? by (adding or deleting, as appropriate) Di , where D = D and D0 = Dm . Then D0 is legal w.r.t. S i each of Di ; 1 i m, is legal w.r.t. S . 1
+1
1
0
Intuitively, the above result says that independent of the actual sequence of directory entry insertions and deletions in the update transaction, we can check for legality by rst inserting subtrees corresponding to inserted directory entries (checking legality after each subtree insertion), and then deleting subtrees corresponding to deleted directory entries (checking legality after each subtree deletion). In the next subsection, we show that this abstraction helps us characterize cases where incremental legality checking is possible. Hence, we restrict our attention to directory updates that consist of the insertion or deletion of a single subtree. We denote the updated directory 12
instance by D + D for insertions, by D ? D for deletions, and by D D when the nature of the update is unimportant.
4.2 Incremental Testing of Legality Consider a schema S = (A; H; S), and an arbitrary directory instance D that is legal w.r.t. S . Testing whether the update D preserves legality, i.e., D D is legal, with respect to the content schema (A; H) can always be performed eciently. Insertion of a subtree D preserves legality w.r.t. (A; H) i D, viewed as a directory instance, is legal w.r.t. (A; H). Deletion of a subtree D cannot violate legality w.r.t. (A; H). These are consequences of the fact that legality w.r.t. the content schema can be tested by independently checking each entry in the instance. Incrementally testing whether an update D preserves legality with respect to the structure schema S = (Cr ; Er; Ef ) is more complex. Legality of D D cannot, in general, be tested by simply examining D itself. Consider for example, the directory instance fragment shown in Figure 1. Suppose that the directory instance is updated by adding a new orgUnit entry as a child of the suciu entry, and adding a few person entries as children of the newly created orgUnit. The updated directory instance D + D is clearly not legal, since it violates both orgGroup ?! orgUnit and person ?! top. However, neither of these violations can be detected by solely examining the insertion D. In general, we may need to examine D +D (for insertions), D ? D (for deletions), D, or even nothing, depending on the speci c structural relationship. Suppose we want to incrementally test whether the insertion D preserves legality w.r.t. the required structural relationship orgGroup ?!! person . We can make e ective use of the hierarchical selection query corresponding to the structural relationship, for this purpose. For the above structural relationship, the corresponding hierarchical selection query is given by Q1 (from Section 3.2), reproduced below:
Q1 : (?
d
(objectClass=orgGroup) (
(objectClass=orgGroup)(objectClass=person)))
The result of Q1 should be empty for the relationship orgGroup ?!! person to be satis ed. Denote by Q[D] the result of applying query Q on a directory instance D . Suppose Q1 [D] = ;. Then, we can show that Q1 [D + D] = ; if and only if Q1 [D] = ;. The rationale is that adding D to D cannot make any entries of D violate the relationship. Thus, the only way D + D could violate the required structural relationship is if D violated it. As another example, consider the required structural relationship orgGroup ?! orgUnit and the forbidden structural relationship person ?! top. Consider deleting a subtree. We can show that, in these cases, no check needs to be performed after the deletion; in other words, as long as the original instance satis es these relationships, no deletion can violate them. Deletion could, however, violate the relationship orgGroup ?!! person ; in this case, we may have to check for the satisfaction of the relationship in the entire updated instance, D ? D. 13
?! cj cj ?! ci ci ?! ! cj cj ?! ! ci ci ?! cj ci ?! ! cj
Y/N yes yes yes yes yes yes
?! cj cj ?! ci ci ?! ! cj cj ?! ! ci ci ?! cj ci ?! ! cj
no yes no yes yes yes
ci
ci
for Insertions (? (objectClass=ci)[D] (c (objectClass=ci)[D] (objectClass=cj)[D])) (? (objectClass=ci)[D] (p (objectClass=ci)[D] (objectClass=cj)[D + D])) (? (objectClass=ci)[D] (d (objectClass=ci)[D] (objectClass=cj)[D])) (? (objectClass=ci)[D] (a (objectClass=ci)[D] (objectClass=cj)[D + D])) (c (objectClass=ci)[D + D] (objectClass=cj)[D]) (d (objectClass=ci)[D + D] (objectClass=cj)[D]) Q for Deletions (? (objectClass=ci) (c (objectClass=ci) (objectClass=cj)))[D ? D] Q
(? (objectClass=ci)[;] (p (objectClass=ci)[;] (objectClass=cj)[;]))
(? (objectClass=ci) (d (objectClass=ci) (objectClass=cj)))[D ? D] (? (objectClass=ci)[;] (a (objectClass=ci)[;] (objectClass=cj)[;])) (c (objectClass=ci)[;] (objectClass=cj)[;]) (d (objectClass=ci)[;] (objectClass=cj)[;])
Figure 5: Q Query Expressions for Insertions and Deletions We now formalize these intuitions. Consider a (required or forbidden) structural relationship , and let Q be the hierarchical selection query such that an instance D is legal w.r.t. if and only if Q [D] = ;. We would like to eciently determine whether or not Q [DD] = ;, taking advantage of the knowledge that Q [D] = ;. The key idea is to identify a query expression Q (D; D D ) that is syntactically identical to Q , except that each sub-expression of Q may be evaluated on any one of ;, D , and D + D (in the case of insertion) or D ? D (in the case of deletion).
De nition 4.1 [Incremental Testing of Legality] Let ; Q and Q be de ned as above.
Then, we de ne the following:
is incrementally testable against insertion if at least one sub-expression of Q is evaluated on ; or on D . We call Q the -query for . is incrementally testable against deletion if at least one sub-expression of Q is evaluated on ; or on D . We call Q the ? -query for . +
Figure 5 lists the various required and forbidden structural relationships in (Er ; Ef ), indicates whether or not they are incrementally testable for insertion or deletion, and gives the corresponding Q query expressions. The following result shows that the gure provides a complete characterization of structural relationships w.r.t. incremental testability.
Theorem 4.2 (Incremental Testing of Legality) : A structural relationship is incrementally
testable for insertion or deletion if and only if it is so indicated in Figure 5.
14
In an analogous fashion, we can show that the required object classes Cr in the structure schema S are incrementally testable for insertion. If we had the ability to associate each ci with the number of entries that belong to ci , then Cr would also be incrementally testable for deletion; in the absence of counts, Cr is not incrementally testable for deletion. We skip the details.
5 Testing Schema Consistency Bounding-schemas are suciently expressive so as to permit speci cations which no instance can satisfy. A schema S is said to be consistent provided it admits at least one legal instance. In this section, we show that schema inconsistency is due to just two causes: cycles and direct contradictions. However, detection of these forms of inconsistencies is not straightforward: the elements of the structure and the class schemas can interact in subtle ways to create inconsistency.
5.1 Cycles Consider, for example, a speci cation that includes the following elements of the structure schema: c1 , c1 ?! c2 , and c2 ?!! c1 . Together, they entail that no legal instance can be nite, since there must exist an entry that belongs to object class c1, each entry that belongs to object class c1 must have a child entry that belongs to object class c2 , and each entry that belongs to object class c2 must have a descendant entry that belongs to object class c1.3 Since legal instances have to be nite, the presence of such a cycle in the required portion of the structure schema is a cause of schema inconsistency. While cycles can arise purely because of the required elements of the structure schema, interactions with the object class hierarchy in the class schema can also result in cycles. Consider, for example, a speci cation that includes the following required elements of the structure schema: c1 , c3 ?! c2, and c5 ?!! c4. While there appears to be no cycles leading to inconsistency, one immediately arises if c1 is a subclass of c2, c3 is a subclass of c4 and c5 is a subclass of c1 . Figure 6 presents inference rules that derive, from a bounding-schema S , additional schema elements that must be satis ed by all legal instances that satisfy S . By ` , we signify that is derivable from using nitely many applications of the inference rules. We use the notation ; to indicate the assertion that there exists an entry with no associated object class. Clearly, the schema element ; admits no legal instance and it signi es inconsistency. Note that schema elements of the form ci ?!! ; and ; ?!! ci do not signify inconsistency, since they are satis ed by instances that do not have any entries belonging to object class ci . The inference rules of Figure 6 suce to detect schema inconsistencies due to cycles. Note that just having the two required structural relationships in the schema, without having c1 , is not inconsistent, since it can be satis ed by an instance that has no entries that belong either to c1 or to c2 . 3
15
Inferences from Structure Schema Nodes and Edges: , ?! ` . , ?!! ` . , ?! ` . , ?!! ` . Paths: ?! ` ?!! . ?! ` ?!! . Transitivity: ?!! ?!! ` ?!! . ?!! ?!! ` ?!! . Loops: ?!! ` ?!! ; . ?!! ` ; ?!! . Inferences from Class Schema Re exivity: ` | . Transitivity: | | ` | . Combined Inferences from Structure and Class Schemas Source: ?! | ` ?! . ?!! | ?! | ` ?! . ?!! | Target: ?! | ` ?! . ?!! | ?! | ` ?! . ?!! | ci
ci
ci
cj
cj
ci
ci
cj
ci
ci
ci ;
ci
c
ci
ci
cj
ci
cj
cj
ci
ci
cj
cj
ci
cj
cj
ci
cj
ck
ck
ci
ci
cj
cj ; cj
cj
cj
ci
cj
cj
ci
ck
ck
ci
ci
ci
ci
ci
c
cj ; cj
ck
0
cj ; c i 0
ci
ci
ci ; ci
ci
cj ; c j
cj
ci ; cj
cj
0 0
ck
0
ci
cj
ci
0
cj
ci 0
ci
cj
0
cj
ci
cj
ci
cj
0
cj ; c i 0
ci ; ci
ci ci 0
c j ; cj
cj
ci ; cj
cj
0
` ?!! . ` ?!! . ` ?!! . ` ?!! . 0
ci
cj
0
cj
ci
ci
cj
0
0
cj
ci
Figure 6: An Inference System for Detection of Inconsistencies Due to Cycles
5.2 Contradictions Schema inconsistency can also arise in the absence of cycles. For example, suppose that the speci cation includes the following elements of the structure schema: c1 , c1 ?!! c2 , and c1 ?! ! c2. Together, they entail a contradiction: there must exist an entry that belongs to object class c1 , each entry that belongs to object class c1 must have a descendant that belongs to object class c2 , and no pair of entries e1; e2 that are related by an (ancestor, descendant) relationship can belong to object classes c1 and c2, respectively. Again, interactions with the class schema can result in contradictions, where none existed purely within the structure schema. Figure 7 presents additional inference rules, that along with the inference rules of Figure 6, suce to detect schema inconsistencies due to contradictions.
5.3 Results We say that a set of schema elements logically implies a schema element , denoted j= , provided every instance that satis es also satis es . The following result establishes the soundness of the inference system of Figures 6 and 7.
Theorem 5.1 Let S be a directory schema, be the set of all schema elements of S , and denote an arbitrary schema element. Then, ` only if j= . 16
Paths:
ci
Direct Con ict:
ci
Source and Target:
ci
Parenthood: Ancestorhood:
ci
ci
Inferences from Structure Schema ?!! top ` ?! top . top ?! ! ` top ?! . ?! top ` ?! ! top. top ?! ` top ?! ! . ?!! ?! ! ` ?!! ; . ?!! ?! ! ` ; ?!! . Combined Inferences from Structure and Class Schemas ?! | | ` ?! . ?! ! | | ` ?! ! . ?! | ` ?! . ?!! ?! ! ?! ! | ` ?! ! .
cj cj
ci
ci
ci
cj
cj ; ci
0
cj
ci ; c j
0
c j ; ci
ci ; cj
ci ; cj
cj
0
cj
0
ci ; c j ck
cj
ci
0
cj ; ci
ck
c i ; cj
ci
ci
0
ci
cj
0
cj
ci
ci
0
cj
ci
ck ; ck
c j ; cj
ck
ck
ci
Figure 7: Additional Inference Rules for Detection of Inconsistencies Due to Contradictions However, the inference system consisting of the inference rules of Figures 6 and 7 is clearly ! ck j= ci ?! ck . However, ci ?! ! ck 6` ci ?! ck . Note that the incomplete. For example, ci ?! order in which the inference rules are applied is immaterial. Further, a remarkable property of the inference system is that it does not need to be complete in order to detect inconsistency, as the following result indicates:
Theorem 5.2 (Consistency Theorem) : Let S = (A; H; S) be a directory schema and the set of schema elements in H and S. Then S is consistent if and only if 6` ; . Further, consistency of S can be checked in time polynomial in the size of the schema.
6 Discussion We begin this section by rationalizing the design decisions we made in choosing the schema elements for bounding-schemas. We then discuss the role played by schema in di erent kinds of databases, and nally show that the elements of bounding-schemas have wider applicability beyond LDAP directories, to semi-structured databases.
6.1 Rationale for Design Decisions Our choice of schema elements for bounding-schemas was motivated by their utility for directories. However, there are many conceivable, and potentially useful, schema elements that are not part of the bounding-schema proposal. Here, we rationalize some of our design decisions, and describe how some traditional notions of schema can be easily combined with bounding-schemas.
Structural Relationships on Attributes: The co-occurrence and structural relationships that
we have considered in the paper have all been with respect to object classes that must or must not 17
occur. In addition, one could consider having requirements on attributes that must or must not occur in an entry based upon other attributes in the same entry, or in structurally related entries. Similarly, we could have requirements on object classes that must or must not occur at an entry based on attributes that occur in structurally related entries. Most of these relationships can be captured in a two-step manner through co-occurrence and structural relationships on object classes followed by the attribute schema speci cation on object classes. Furthermore, in most cases, such a two-step formulation is actually preferable (and arguably more natural) in terms of encapsulation and modularity at the object class level. As such, even though we believe that the work presented in this paper could be extended to deal with co-occurrence and structural relationships on attributes, we have chosen not to do so.
Numeric Restrictions: By default, each entry in an LDAP directory can have multiple values
for each attribute. Often, it is useful to specify that particular attributes may have only a single value. For example, whereas a person may have multiple values for telephoneNumber and mail, and perhaps even for name and address, we may require that there be only a single value for socialSecurityNumber. For this purpose, LDAP provides a schema speci cation wherein particular attributes can be declared to be \single-valued". Such a speci cation is clearly orthogonal to the requirements captured by our bounding-schema, and can easily be incorporated in our framework.
Keys: Keys are a critical part of the schema for a relational database. In other types of databases,
including object-oriented and semi-structured databases, the role of keys is sometimes just as important, but often less emphasized. For LDAP directories, the distinguished name of an entry serves as a key, uniquely identifying an entry at any point in time. Other notions of keys can easily be incorporated in our framework as values of attributes. However, given the relatively loose notion of an object class, any notion of a key in an LDAP directory must be unique across all entries in the directory instance, not just within a single object class. Speci cation of keys is again orthogonal to our de nition of a bounding-schema.
Complex Integrity Constraints: It is often useful to de ne integrity constraints, or invariants,
for a database. Upon each update, incremental integrity constraint checking algorithms, if available, can be used to verify that the integrity constraints are not violated. The richer the class of integrity constraints permitted, the more expressive, and hence more useful, the constraints can be. On the other hand, the richer the class of integrity constraints, the more expensive they are likely to be to verify, and the harder it is likely to be to check for consistency of the integrity constraints. In the case of a relational database, there is a more or less well-understood notion of a schema, distinct from integrity constraints. The former includes speci cation of each table name, the column names and types for each column, identi cation of keys, and of (at least certain basic kinds of) 18
functional dependencies. Everything else is considered an integrity constraint. In the case of an LDAP directory, clearly, object classes, and attributes and types belong in a schema. What attributes and object classes must co-occur and cannot co-occur are also legitimate parts of the schema. Finally, there is the issue of structural relationships. Clearly, some basic speci cations on what types of nodes can appear below what other types of nodes are critical schema components. These we have included in our schema speci cation language. On the other hand, there is no end to the complexity of assertions that could be made about structural relationships. As a design decision, we have chosen to draw the line at a fundamental set of structure schema de nition components, and relegated everything else that is more involved to the status of integrity constraints.
6.2 Related Work Schema plays a central role in the design and administration of databases. In fact, the presence of a schema is a central property that distinguishes an organized database from an arbitrary collection of data. There is vast literature on schema speci cation and database design in the relational and object-oriented contexts; see, e.g., [7, 10]. A crucial di erence between bounding-schemas and schema speci cation in traditional (relational and object-oriented) databases is that schemas for traditional databases are rigid, i.e., they allow very little exibility in what constitutes a legal instance. As a consequence, schema evolution (even adding an attribute to an existing table or class) in traditional databases is typically a heavy-weight operation. In contrast, many kinds of schema evolution, such as adding a new allowed attribute to an object class, or adding a new auxiliary object class to the auxiliary object classes associated with a core object class is extremely lightweight, involving no modi cations to existing directory entries. More recently, the notion of semi-structured databases has been proposed, which permit more
exible schemas than traditional databases [2, 4]. The dominant notion here is one of descriptive, rather than prescriptive, schema. The challenge is to discover the schema from observed instances rather than to create instances that adhere to the schema. Several alternatives have been proposed to specify the schema, and then to compare a schema with a database instance. Schema could be speci ed as a graph with simulation used for comparison [5], speci ed as a graph with a nite automaton used for comparison [8], or speci ed as a monadic Datalog program with program evaluation used for comparison [12]. The need for approximate schema has also been observed in [12], leading to explicit descriptions of lower and upper bound schemas (see [13] for more details). In the directory context, while exibility remains a central objective, schema is meant to be prescriptive, as opposed to the semi-structured world discussed above. There is considerable activity surrounding the enhancement of the current LDAPv2 standard [17], with at least some of these enhancements relating to richer schema speci cation. There are a variety of embellishments incorporated in di erent proposals, including [16, 15, 14]. These include: the notion of a single inheritance hierarchy of core object classes; the notion of auxiliary object classes; and the notion of 19
an extensible object that allows all possible attributes. Bounding-schemas build on many of these ideas, and considerably enhance the expressiveness of schema speci cations for directories. To our knowledge, the notions of testing legality of instances, preservation of legality under updates, and of consistency of schema have not been addressed for directories in the literature. While some of these notions have been addressed in other contexts (e.g., relational, object-oriented and semi-structured databases), there is no obvious way of adapting that work in a manner that will lead to natural and ecient tests for these properties for the LDAP directory model.
6.3 A Wider Applicability of Bounding-Schemas Path constraints have been proposed for semi-structured databases based on labeled paths where the path length is xed [6], and based on regular expressions that constrain the destination of the path [3]. These path constraints do not suce for expressing structural relationships of the form ci ?!! cj and ci ?! ! cj , where the path length between the ancestor ci and the descendant cj can be arbitrary. Such required and forbidden structural relationships may be very useful in semi-structured databases. For example, one might want to specify that each person node must have a (descendant) name node, without having to x the length of the path between these nodes. As another example, while one might want to allow a country node to have children corporation nodes (national corporations could be modeled thus), a corporation node to have children country nodes (international corporations could be modeled thus), and a corporation node to have children corporation nodes (conglomerates could be modeled thus), one might want to forbid a country node to be a descendant of another country node. Thus, in principle, our notions can be used to usefully enhance the notion of schema for semi-structured databases.
7 Conclusions We have proposed a rich and useful notion of schema called bounding-schemas, that restricts legal directory instances, without sacri cing the exibility o ered by the LDAP data model. Given a bounding-schema speci cation, we present algorithms to eciently determine if an LDAP directory is legal, if directory updates preserve legality, and if the schema is consistent. We have focused on the importance of schema from the perspective of the semantic bene t provided. However, the presence of a schema is useful in other ways as well. In particular, index structures rely upon notions of schema, and query optimization is facilitated using schema. The use of bounding-schemas for these topics is a subject of future study.
20
References [1] Directory enabled networks ad hoc working group. http://www.murchiso.com/den/. [2] S. Abiteboul. Querying semi-structured data. In Proceedings of the International Conference on Database Theory, pages 1{18, 1997. [3] S. Abiteboul and V. Vianu. Regular path queries with constraints. In Proceedings of the ACM Symposium on Principles of Database Systems, pages 122{133, 1997. [4] P. Buneman. Semistructured data. In Proceedings of the ACM Symposium on Principles of Database Systems, pages 117{121, 1997. [5] P. Buneman, S. Davidson, M. Fernandez, and D. Suciu. Adding structure to unstructured data. In Proceedings of the International Conference on Database Theory, pages 336{350, Delphi, Greece, 1997. [6] P. Buneman, W. Fan, and S. Weinstein. Path constraints in semistructured and structured databases. In Proceedings of the ACM Symposium on Principles of Database Systems, pages 129{138, 1998. [7] R. Elmasri and S. B. Navathe. Fundamentals of Database Systems. Benjamin/Cummings Publishers, second edition, 1994. [8] R. Goldman and J. Widom. DataGuides: Enabling query formulation and optimization in semistructured databases. In Proceedings of the International Conference on Very Large Databases, 1997. [9] H. V. Jagadish, L. V. S. Lakshmanan, T. Milo, D. Srivastava, and D. Vista. Querying network directories. In Proceedings of the ACM SIGMOD Conference on Management of Data, Philadelphia, PA, June 1999. [10] A. Kemper and G. Moerkotte. Object-oriented database management applications in engineering and computer science. Prentice Hall, 1994. [11] Microsoft. Active directory. Available from http://www.microsoft.com/ntserver/basics/future/activedirectory/. [12] S. Nestorov, S. Abiteboul, and R. Motwani. Extracting schema from semistructured data. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 295{306, 1998. [13] D. Suciu. Managing web data. SIGMOD'99 tutorial., 1999. [14] M. Wahl. A summary of the X.500(96) user schema for use with LDAPv3. Request for Comments 2256. Available from ftp://ds.internic.net/rfc/rfc2256.txt, Dec. 1997. [15] M. Wahl, A. Coulbeck, T. Howes, and S. Kille. Lightweight directory access protocol (v3): Attribute syntax de nitions. Request for Comments 2252. Available from ftp://ds.internic.net/rfc/rfc2252.txt, Dec. 1997. [16] M. Wahl, T. Howes, and S. Kille. Lightweight directory access protocol (v3). Request for Comments 2251. Available from ftp://ds.internic.net/rfc/rfc2251.txt, Dec. 1997. [17] W. Yeong, T. Howes, and S. Kille. Lightweight directory access protocol. Request for Comments 1777. Available from ftp://ds.internic.net/rfc/rfc1777.txt, Mar. 1995.
21
