| Prev | Chapter�10.�Development Reference | Next |
|---|
While many applications must deal with individuals and many applications must deal with groups, most applications must deal with individuals or groups. It is often the case with such applications that @@ -11,20 +11,20 @@ practical way to manage both. This concept is so mundane that there is no need to invent special terminology. This -supertype is called a "party".
A classic example of the "party" supertype is evident +supertype is called a "party".
A classic example of the "party" supertype is evident in address books. A typical address book might contain the address of a doctor, grocery store, and friend. The first field in an entry in the address book is not labeled a person or -company, but a "party". -
The parties developer guide begins with an introduction to the parties data model, since OpenACS -community applications likely require using it in some way.
Parties
The central table in the parties data model is the parties table itself. +community applications likely require using it in some way.
Parties
The central table in the parties data model is the parties table itself. Every party has exactly one row in this table. Every party has an optional unique email address and an optional url. A party is an acs object, so permissions may be granted and revoked on parties and auditing information is stored in the acs objects table.
-
+
create table parties (
party_id not null
constraint parties_party_id_fk references
@@ -34,54 +34,54 @@
constraint parties_email_un unique,
url varchar(200)
);
-
+
-The persons and -groups tables extend the -parties table. A row in the persons table represents the +
The persons and
+groups tables extend the
+parties table. A row in the persons table represents the
most generic form of individual modeled. An individual need not be known to the system as a user. A
user is a further specialized form of an individual (discussed later). A
row in the groups table represents the most generic form of group
modeled, where a group is an aggregation of zero or more
-individuals.
Persons
If a party is an individual then there will be a row in the persons table -containing first_names and -last_name +individuals.
Persons
If a party is an individual then there will be a row in the persons table
+containing first_names and
+last_name
for that individual. The
-primary key of the persons table (person_id) references the primary key of
-the parties table (party_id), so that there is a corresponding row in the
+primary key of the persons table (person_id) references the primary key of
+the parties table (party_id), so that there is a corresponding row in the
parties table when there is a row in the persons table.
-create table persons (
+create table persons (
person_id not null
constraint persons_person_id_fk
references parties (party_id)
constraint persons_person_id_pk primary key,
first_names varchar(100) not null,
last_name varchar(100) not null
);
-
+
-Users
The users table is a more -specialized form of persons table. A row -in users table represents an individual that has login access to the +
Users
The users table is a more
+specialized form of persons table. A row
+in users table represents an individual that has login access to the
system. The primary key of the users table references the primary
key of the persons table. This guarantees that if there is a row
-in users table then there must be a
-corresponding row in persons
-and parties tables.
Decomposing all the information
+in users table then there must be a
+corresponding row in persons
+and parties tables.
Decomposing all the information associated with a user into the four tables (acs_objects, parties, persons, users) has some immediate benefits. For instance, it is possible to remove access to a user from a live system by removing his entry from the users table, while leaving the rest of his information present (i.e. turning him from a user into a -person).
Wherever possible the OpenACS data model references the persons or -parties table, not the users table. +person).
Wherever possible the OpenACS data model references the persons or
+parties table, not the users table.
Developers should be careful to
only reference the users table in situations where it is clear that the
reference is to a user for all cases and not to any other individual
for any case.
-create table users (
+create table users (
user_id not null
constraint users_user_id_fk
references persons (person_id)
@@ -106,34 +106,34 @@
password_question varchar(1000),
password_answer varchar(1000)
);
-
+
-Groups
The final piece of the parties data model is the groups data model. A +
Groups
The final piece of the parties data model is the groups data model. A group is a specialization of a party that represents an aggregation of zero or more other parties. The only extra information directly associated with a group (beyond that in the parties table) is the name of the group:
-create table groups (
+create table groups (
group_id not null
constraint groups_group_id_fk
references parties (party_id)
constraint groups_group_id_pk primary key,
group_name varchar(100) not null
);
-
+
There is another piece to the groups data model that records relations between parties and groups. -
Group Relations
Two types of group relations are represented in the data model: +
Group Relations
Two types of group relations are represented in the data model: membership relations and composite relations. The full range of sophisticated group structures that exist in the real world can be modelled in OpenACS by these two relationship types.
Membership relations represent direct membership relation between parties and groups. A party may be -a "member" of a group. Direct membership relations are +a "member" of a group. Direct membership relations are common in administrative practices, and do not follow basic set theory rules. If A is a member of B, and B is a member of C, A is -not a member of C. Membership relations are not transitive. +not a member of C. Membership relations are not transitive.
Composition relation represents composite relation between two groups. Composite relation is transitive. That is, it works like @@ -149,11 +149,11 @@ group that is a member of Greenpeace. Now, consider a multinational corporation (MC) that has a U.S. division and a Eurasian division. A member of either the U.S. or Eurasian division is automatically a member of the MC. In this -situation the U.S. and Eurasian divisions are "components" of +situation the U.S. and Eurasian divisions are "components" of the MC, i.e., membership is transitive with respect to composition. Furthermore, a member of a European (or other) office of the MC is automatically a member of the MC. -
Group Membership
Group memberships can be created and manipulated using the membership_rel +
Group Membership
Group memberships can be created and manipulated using the membership_rel package. Only one membership object can be created for a given group, party pair.
@@ -166,7 +166,7 @@ member of a household (indirect membership) at a video rental store.
-
+
# sql code
create or replace package membership_rel
as
@@ -208,17 +208,17 @@
end membership_rel;
/
show errors
-
+
-Group Composition
Composition relations can be created or destroyed using the +
Group Composition
Composition relations can be created or destroyed using the composition_rel package. The only restriction on compositions is that there cannot be a reference loop, i.e., a group cannot be a component of itself either directly or indirectly. This constraint is maintained for you by the API. So users do not see some random PL/SQL error message, do not give them the option to create a composition relation that would result in a circular reference.
-
+
# sql code
create or replace package composition_rel
as
@@ -239,88 +239,88 @@
end composition_rel;
/
show errors
-
+
-The parties data model does a reasonable job of representing many of the situations one is likely to encounter when modeling organizational structures. We still need to be able to efficiently answer questions like -"what members are in this group and all of its components?", and -"of what groups is this party a member either directly or -indirectly?". Composition relations allow you to describe an arbitrary +"what members are in this group and all of its components?", and +"of what groups is this party a member either directly or +indirectly?". Composition relations allow you to describe an arbitrary Directed Acyclic Graph (DAG) between a group and its components. For these reasons the party system provides a bunch of views that take advantage of the internal representation of group relations to answer questions like these -very quickly.
The group_component_map +very quickly.
The group_component_map
view returns all the subcomponents of a group including components of
-sub components and so forth. The container_id column is the group_id of the
-group in which component_id is directly contained. This allows you to easily
+sub components and so forth. The container_id column is the group_id of the
+group in which component_id is directly contained. This allows you to easily
distinguish whether a component is a direct component or an indirect
-component. If a component is a direct component then group_id will be equal
-to container_id. You can think of this view as having a primary key of
-group_id, component_id, and container_id. The rel_id column points to the row
-in acs_rels table that contains the relation object that relates component_id to
-container_id. The rel_id might be useful for retrieving or updating standard
+component. If a component is a direct component then group_id will be equal
+to container_id. You can think of this view as having a primary key of
+group_id, component_id, and container_id. The rel_id column points to the row
+in acs_rels table that contains the relation object that relates component_id to
+container_id. The rel_id might be useful for retrieving or updating standard
auditing info for the relation.
-create or replace view group_component_map
+create or replace view group_component_map
as select group_id, component_id, container_id, rel_id
...
-
+
-The group_member_map view is similar to group_component_map except for membership relations. +
The group_member_map view is similar to group_component_map except for membership relations.
This view returns all membership relations regardless of membership state.
-create or replace view group_member_map
+create or replace view group_member_map
as select group_id, member_id, container_id, rel_id
...
-
+
-The group_approved_member_map -view is the same as group_member_map except +
The group_approved_member_map
+view is the same as group_member_map except
it only returns entries that relate to approved members.
-create or replace view group_approved_member_map
+create or replace view group_approved_member_map
as select group_id, member_id, container_id, rel_id
...
-
+
-The group_distinct_member_map +
The group_distinct_member_map
view is a
useful view if you do not care about the distinction between
direct membership and indirect membership. It returns all members of a
group including members of components --the transitive closure.
-create or replace view group_distinct_member_map
+create or replace view group_distinct_member_map
as select group_id, member_id
...
-
+
-The party_member_map view is the same as group_distinct_member_map, except it includes the +
The party_member_map view is the same as group_distinct_member_map, except it includes the
identity mapping. It maps from a party to the fully expanded
list of parties represented by that party including the party itself. So if a
party is an individual, this view will have exactly one mapping that is from
that party to itself. If a view is a group containing three individuals, this
view will have four rows for that party, one for each member, and one from
the party to itself.
-create or replace view party_member_map
+create or replace view party_member_map
as select party_id, member_id
...
-
+
-The party_approved_member_map view is the same as party_member_map except that when it expands groups, it only +
The party_approved_member_map view is the same as party_member_map except that when it expands groups, it only
pays attention to approved members.
-create or replace view party_approved_member_map
+create or replace view party_approved_member_map
as select party_id, member_id
...
-
+
-The parties data model can represent some fairly sophisticated real +
The parties data model can represent some fairly sophisticated real world situations. Still, it would be foolish to assume that this data model is sufficiently efficient for every application. This section describes some -of the more common ways to extend the parties data model.
Specializing Users
Some applications will want to collect more +of the more common ways to extend the parties data model.
Specializing Users
Some applications will want to collect more detailed information for people using the system. If there can be only one such piece of information per user, then it might make sense to create another type of individual that is a further specialization @@ -331,18 +331,18 @@ have a primary key that references the users table, thereby guaranteeing that each row in the chess_club_users table has a corresponding row in each of the users, persons, parties, and acs_objects tables. This child table could then -store any extra information relevant to the Chess Club community.
Specializing Groups
If one were to build an intranet application on top of the party +store any extra information relevant to the Chess Club community.
Specializing Groups
If one were to build an intranet application on top of the party system, it is likely that one would want to take advantage of the systems efficient representation of sophisticated organizational structures, but there would be much more specialized information associated with each group. In this case it would make sense to specialize the group party type into a -company party type in the same manner as Specializing Users.
Specializing Membership Relations
The final portion of the parties data model that is designed to be +company party type in the same manner as Specializing Users.
Specializing Membership Relations
The final portion of the parties data model that is designed to be extended is the membership relationship. Consider the intranet example again. It is likely that a membership in a company would have more information associated with it than a membership in an ordinary group. An obvious example of this would be a salary. It is exactly this need to be able to extend membership relations with mutable pieces of state that drove us to include a single integer primary key in what could be thought of as a pure relation. -Because a membership relation is an ordinary acs object with object identity, it is as easy to extend the +Because a membership relation is an ordinary acs object with object identity, it is as easy to extend the membership relation to store extra information as it is to extend the users table or the groups table.