OpenACS Relationship Tables

"Relationships" are generic N x M mapping between OpenACS objects.

Relationships can have parameters associated, constraints on the object types of both sides of the relationship and being objects themselves, they can be subject to permissions themselves.


 

 

Table

Cols

Rows

Description

[acs_rel_roles]

3

10

List of relationship "roles". Example: A user may be related to a company in the role "Employee".

[acs_rel_types]

9

12

Each row in acs_rel_types represents a type of relationship between objects. For example, the following DML statement:

insert into acs_rel_types
  (rel_type,
   object_type_one, role_one, min_n_rels_one, max_n_rels_one,
   object_type_two, role_two, min_n_rels_two, max_n_rels_two)
 values
  ('employment',
   'person', 'employee', 0, null,
   'company', 'employer', 0, null)

defines an "employment" relationship type that can be expressed in in natural language as: A person may be the employee of zero or more companies, and a company may be the employer of zero or more people.

[acs_rels]

4

1838

The acs_rels table is essentially a generic mapping table for acs_objects. Once we come up with a way to associate attributes with relationship types, we could replace many of the ACS 3.x mapping tables like user_content_map, user_group_map, and user_group_type_modules_map with this one table. Much application logic consists of asking questions like "Does object X have a relationship of type Y to object Z?" where all that differs is X, Y, and Z. Thus, the value of consolidating many mapping tables into one is that we can provide a generic API for defining and querying relationships. In addition, we may need to design a way to enable "type_specific" storage for relationships (i.e., foreign key columns for one-to-many relationships and custom mapping tables for many-to-many relationships), instead of only supporting "generic" storage in the acs_rels table. This would parallel what we do with acs_attributes.

[composition_rels]

1

17

Relationships of type "composition rel". These are relationships between groups, indicating that one group is included in another group.

[group_rels]

3

9

Stores the relationship types available for use by each group. Only relationship types in this table are offered for adding relations. Note that there is no restriction that says groups can only have relationship types specified for their group type. The group_type_rels table just stores defaults for groups of a new type.

[group_type_rels]

3

9

Stores the default relationship types available for use by groups of a given type. We May want to generalize this table to object_types and put it in the relationships sql file, though there is no need to do so right now.

[membership_rels]

2

638

Sub-class of acs_rels, describing the relationship of users being member of a group.

[rel_constraints]

5

0

Defines relational constraints. The relational constraints system is intended to support applications in modelling and applying constraint rules on inter-party relatinships based on relational party segmentation.

[rel_segments]

4

2

Defines relational segments. Each relational segment is a pair of group_id / rel_type, or, in english, the parties that have a relation of type rel_type to group_id.

  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

08902 Hospitalet de Llobregat (Barcelona)

Spain

 Tel Europe: +34 609 953 751
 Tel US: +1 415 200 2465
 Mail: info@project-open.com