Index: openacs-4/packages/acs-core-docs/www/parties.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/parties.html,v diff -u -r1.12 -r1.13 --- openacs-4/packages/acs-core-docs/www/parties.html 20 Aug 2003 16:20:16 -0000 1.12 +++ openacs-4/packages/acs-core-docs/www/parties.html 14 Oct 2003 11:02:58 -0000 1.13 @@ -1,21 +1,20 @@ - -
+
by Rafael H. Schloming
OpenACS docs are written by the named authors, and may be edited
by OpenACS documentation staff.
-
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 in many respects both individuals and groups are treated in an identical manner. It is this latter class of application that makes it extremely useful to model individuals and groups as specializations of one supertype. This concept is so commonly used throughout human language and thought that we don't even need to invent for it some bizarre and specialized terminology. This -supertype is called a "party".
A classic example use of the "party" supertype is evident +supertype is called a "party".
A classic example use of the "party" supertype is evident in a common address book. A typical person's address book might contain the address of his doctor, and his cable company. So what do we label the first field in an entry in his address book? It isn't a person, and it -isn't a company. It is a "party".
Most developers who do significant work with the OpenACS will become +isn't a company. It is a "party".
Most developers who do significant work with the OpenACS will become intimately familiar with the parties data model, and probably extend it on many occasions. For this reason the parties developer guide will begin with an introduction to the data model.
Parties
The central table in the parties data model is the parties table itself. @@ -24,7 +23,7 @@ permissions may granted and revoked on parties and auditing information is stored in the acs objects table.
-create table parties ( +create table parties ( party_id not null constraint parties_party_id_fk references acs_objects (object_id) @@ -47,7 +46,7 @@ Also note that an individual need not be known to the system as a user. A user is in fact a further specialized form of an individual.-create table persons ( +create table persons ( person_id not null constraint persons_person_id_fk references parties (party_id) @@ -64,16 +63,16 @@ in the users table then there must be a row in the persons table and a row in the parties table.One of the interesting benefits of decomposing all the information associated with a user into the four tables (acs_objects, parties, persons, -users) is that it is now possible to "nuke" a user from a live +users) is that it is now possible to "nuke" a user from a live system by removing his entry from the users table, but leaving the rest of his information present (i.e. turning him from a user into a person). This is -because wherever possible the OpenACS 5.0.0d data model references the persons or +because wherever possible the OpenACS 5.0.0a1 data model references the persons or parties table, not the users table. If this feature is desired when extending the system, then the developers should be careful to only references the users table in situations where it is clear that the references is to a user and not to an individual.
-create table users ( +create table users ( user_id not null constraint users_user_id_fk references persons (person_id) @@ -107,7 +106,7 @@ is another piece to the groups data model that records relations between parties and groups.-create table groups ( +create table groups ( group_id not null constraint groups_group_id_fk references parties (party_id) @@ -118,7 +117,7 @@Group Relations
One surprise here is that there are actually two relations involved. One is the normal membership relation between parties and groups. A party may be -a "member" of a group. The other relation is a composition +a "member" of a group. The other relation is a composition relation between two groups. To fully understand why two relations are necessary, and the situations in which each is appropriate, let's consider an example. Greenpeace is an organization that can have as members @@ -129,7 +128,7 @@ itself. Now let's consider a multinational corporation. This corporation might have a U.S. division and a European division. A member of either the U.S. or European division is automatically a member of the company. In this -situation the U.S. and European divisions are "components" of +situation the U.S. and European divisions are "components" of the company, i.e., membership is transitive with respect to composition. Having a membership relation between groups and parties, and having a composition relation between groups and groups allows us to easily @@ -141,7 +140,7 @@ member. This is because there is a distinction between direct membership and indirect membership (membership via some component or sub component).
-create or replace package membership_rel +create or replace package membership_rel as function new ( @@ -191,7 +190,7 @@ good idea to not give them the option to create a composition relation that would result in a cycle.-create or replace package composition_rel +create or replace package composition_rel as function new ( @@ -212,12 +211,12 @@ show errors -
The data model described above does a reasonable job of representing many of the situations one is likely to encounter when modeling organizational structures, but 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 @@ -232,7 +231,7 @@ 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 ... @@ -241,15 +240,15 @@ Note that this view will return 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 is the same as the 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 ... @@ -258,7 +257,7 @@ direct membership and indirect membership. It simply returns all members of a group including members of components. (It is 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 ... @@ -271,20 +270,20 @@ 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 ...This view is the same as above 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 ... -
As is, the parties data model can represent some fairly sophisticated real +
As is, the parties data model can represent some fairly sophisticated real world situations, and a lot of work has been put into making this efficient, but it is foolish to assume that this data model is sufficient for every application. It therefore seems likely that developers will want to extend @@ -299,7 +298,7 @@ have a primary key that references the users table, thereby guaranteeing that each row in the mensa_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 MENSA community.
Specializing Groups
If one were to build an intranet application on top of the 5.0.0d party +store any extra information relevant to the MENSA community.
Specializing Groups
If one were to build an intranet application on top of the 5.0.0a1 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. @@ -313,4 +312,4 @@ 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 membership relation to store extra information as it is to extend the users -table or the groups table.
Prev | Home | Next |
Writing OpenACS 5.0.0d Application Pages | Up | OpenACS 4.x Permissions Tediously Explained |
Prev | Home | Next |
Writing OpenACS 5.0.0a1 Application Pages | Up | OpenACS 4.x Permissions Tediously Explained |