[acs_attribute_descriptions]

4

0

Human readable descriptions for acs_attributes

[acs_attribute_values]

3

58

Stores the values for acs_attributes with a storage type of "generic". For example, this is used by the acs_workflow. However, this storage is NOT used by the ]po[ DynField package, which stores attribute values table columns.

[acs_attributes]

14

247

Each row in the acs_attributes table defines an attribute of the specified object type. Each object of this type must have a minimum of min_n_values values and a maximum of max_n_values for this attribute.

[acs_datatypes]

2

14

Defines the set of available datatypes for acs_attributes. These datatypes are abstract, not implementation-specific, i.e., they are not Oracle datatypes. The set of pre-defined datatypes is inspired by XForms (http://www.w3.org/TR/xforms-datamodel/).

[acs_function_args]

4

850

Human redable description of function arguments.

[acs_object_context_index]

3

39670

Denormalized index of object parent/child relationship (based on the context_id field) created by a trigger on acs_objects. Used to accelerate checks if an object is a child/parent of another object.

[acs_object_type_tables]

3

45

This table is used for objects that want to vertically partition their data storage, for example user_demographics stores a set of optional columns that belong to a user object.

[acs_object_types]

16

124

Each row in the acs_object_types table represents a distinct class of objects. For each instance of any acs_object_type, there is a corresponding row in the acs_objects table. Essentially, acs_objects.object_id supersedes the on_which_table/on_what_id pair that ACS 3.x used as the system-wide identifier for heterogeneous objects. The value of having a system-wide identifier for heterogeneous objects is that it helps us provide general solutions for common problems like access control, workflow, categorppization, and search. (Note that this framework is not overly restrictive, because it doesn't force every type of object to be represented in the acs_object_types table.) Each acs_object_type has:
* Attributes (stored in the acs_attributes table)
Examples:
* the "user" object_type has "email" and "password" attributes
* the "content_item" object_type has "title" and "body" attributes
* Relationship types (stored in the acs_rel_types table)
Examples:
* "a team has one team leader who is a user" (in other words, instances of the "team" object_type must have one "team leader" relationship to an instance of the "user" object_type)
* "a content item may have zero or authors who are people or organizations, i.e., parties" (in other words, instances of the "content_item" object_type may have zero or more "author" relationships to instances of the "party" object_type)
Possible extensions include automatic versioning, logical deletion, and auditing.

[acs_objects]

13

16886

The root table for the acs object heirarchy. It all starts here folks.

[acs_static_attr_values]

3

0

Stores static values for the object attributes. One row per object type.

[general_objects]

3

0

This table can be used to treat non-acs_objects as acs_objects for purposes of access control, categorization, etc.