-- 9-27-82.minutes
-- further discussions on multiple-segment data bases (Rick and John)

We examined a number of different models for multiple-segment data bases.  In order of increasing complexity they are:

0) segments: Neither domains nor relations cross segment boundaries.  There may be domains named "Person" in two different segments, but they are different domains.  If an application wants to correlate the information in the two domains, it must do it on its own.
1) augments: Domains may cross segment boundaries.  Relations may not.   For instance, the domain "Person" could be in several segments.  There might be a white pages segment with ages and phone numbers, a private segment with salary information, and a mail segment with an rName.  The relations remain disjoint even though the domain is spread across several segments.  To find all of the information about a particular person you must look in each segment.  He or she might not be in all of the segments.  There might be Relations named "age" in two different segments, but they are different relations.
2) augments: Both relations and domains cross segment boundaries.  If relations in different segments have the same name, they are logically the same relation.
3) versions: (subtractive augments).

	models 1, 2, and 3 could all be built on top of model 0 by industrious applications.  The question we asked was: how much of the work should be incorporated into DBView?  If code is moved to DBView, then all of the applications can use it.  But it shouldn't penalize applications that don't need it, and it must have a simple, clean semantics.
	
	Here is a design for model 1) that makes the fewest changes to the semantics of DBView:
	
	If there are domains in two different segments that have the same name then they are logically the same domain.  If two different entities have the same name and are in the same logical domain then they are logically the same entity.  In spite of this, domains and entities will have different handles if they come from different segments.  The only procedures that will make use of the logical equivalence of entities are SetF, RelationSubset, and Eq.
	Here are some of the procedures defined in DBView.  Only the ones that are marked with a "*" have changed:
	*Translate[Entity, Segment] translates the entity to its logical equivalent in the segment given.  If none exists, it is created.  If the domain doesn't exist, it is also created. (?)
	*AugmentOf[Entity] returns the augment in which the entity resides.
	DeclareDomain[Segment, name] creates a domain in the segment given.  The domain handle returned is only valid for that segment.  
	DestroyDomain[Domain] only destroys the domain in the handle's segment.
	DeclareRelation[Segment, name] creates a relation only in the segment given.  The relation handle returned is only valid for that segment.
	DestroyRelation[Relation] only destroys the relation in the handle's segment.
	DeclareSubType[of, is: Domain] raises an error if the two domains are not in the same segment.
	DeclareIndex[Relation, AttributeList] raises an error if the attributes are not from the same segment as the relation.  (?)
	DeclareEntity[Domain, name] creates an entity in the domain's segment.  The entity handle is only valid for that segment.
	DestroyEntity[Entity] only destroys the entity in the handle's segment.
	*DeclareRelship[Relation, AttributeValueList] creates a relship in the relation's segment.  If any of the entities in the AttributeValueList belong to a different segment, they are first translated to their logical equivalent in this segment.  This may require creating new entities.  (And perhaps a new domain with subType information?  How do you detect errors?)
	DeclareRelship[Domain, name] creates an entity in the domain's segment.  The relship handle is only valid for that segment.
	*SetF[Relship, Attribute, Value] first translates the Value to the Relship's segment.  Raises a signal if the Attribute is from a different segment.  (?)
	(GetEntityByName is superseded by DeclareEntity)
	DomainOf[Entity] returns the domain handle of the domain in the entity's segment.
	RelationOf[Relship] returns the relation handle of the relation in the relship's segment. 
	*Eq[Entity, Entity] is TRUE iff the two entities are logically equivalent.  (What about for domains?)
	*RelationSubset[Relation, AttributeValueList] first translates values to the relation's segments.  Raises an error if the attributes are from a different segment.  (?)
	*DomainSubset[Domain] will only return the entities from the domain's segment unless the domain is one of the system domains such as DomainDomain, RelationDomain, etc.  In this case it will return entities from ALL of the segments.  (The system domains do not belong to a particular segment).
	*GetAllRefAttributes[Entity] returns attributes from ALL of the segments that refer to the logical entity.   This is a polymorphic procedure, and it will most likely be used by applications that don't know the schema of the entity beforehand.
	*GetDomainRefAttributes[Domain] returns attributes from ALL of the segments that refer to the logical domain. 
	Properties are a shorthand for Attributes.  They will have the same semantics.
	
	Some changes will be necessary to Squirrel and to Palm:
	1) DBNotify now passes an augment.  Applications should only define their schema when their augment is opened.  All other notifies should be ignored.
	2) Applications must be prepared to deal with uninitialized entities.
	3) the Palm displayer will display information from all of the augments.  The information will either be labeled or separated into groups by augment.
	4) the Palm editor will allow the user to specify where the entity will be created.  The default is the augment where it came from.  Next to each attribute is the augment where the relship is to be created.   If necessary, the entity will be created in more than one augment.