05/15/80	mrds.cmdsm_source

Function:	 This describes the syntax of the source text for the create_mrds_dsm
command that defines the makeup of a mrds database submodel.  The source
segment must have the suffix .cmdsm on it.


Syntax:
The basic syntax of the submodel definition source is as follows:

relation: submodel_rel_name1 { = model_rel_name1 }
		( submodel_attr_name1 { = model_attr_name1 }
		  submodel_attr_name2 { = model_attr_name2 }
			.
			.
		  submodel_attr_nameN { = model_attr_nameN } ) {,
	. . . . . . . . . . . ,
	submodel_rel_nameN { = model_rel_nameN}
		( submodel_attr_name1 { = model_attr_name1 }
			.
			.
		  submodel_attr_nameN { = model_attr_nameN  }  )	}  ;

default relation access: (relation_access_list) ;

default attribute access: (attribute_access_list) ;

relation access: submodel_rel_name1 (relation_access_list),
		.
		.
	         submodel_rel_nameN (relation_access_list)
		with attribute access (attribute_access_list) ;

attribute access: submodel_attr_name1 (attribute_access_list),
		.
		.
	        submodel_attr_nameN in submodel_rel_nameI
		(attribute_access_list) ;


Semantics:
The purpose of the submodel view is to allow renaming, reordering, and
elimination of relations and attributes from the view as seen in the database
model.

The submodel_name = model_name allows for this renaming convention, where
model_name refers to the name of the attribute or relation as it appears in the
database model, and the submodel_name is the proposed alias for this submodel.

If not all attributes within a relation, or all relations in the model are
present, then a partial view of the model is seen from the submodel.

Since the attribute and relation names can be given in any order, the submodel
defines its own order for the view it sees.

If the { = model_name } option is not used, the submodel name will be that of
the model, and the submodel_names must then agree with the model relation or
attribute name they are meant to reference.

Access control statements are optional.	 They only have effect if the database
has been secured and the submodel is installed in the databases
secure.submodels directory.

The relation_access_list may have access modes of append_tuple (append tuple,
or a), delete_tuple (delete tuple, or d), null or n.  The attribute_access_list
may have access modes of read_attr (read attr, or r), modify_attr (modify attr,
or m), or null or n.

Default access statements refer to all relations or attributes in the submodel.
They may be overridden with an explicit relation or attribute access statement.
The "with" option of the relation access statement is a per relation default
attribute access mechanism that may also be overriden.  The "in" option of the
attribute access statement allows specifying access for an attribute within a
particular relation, rather than all attributes of that name.

Default access is null for all relations, and read attr for all attributes.


Example:	If the model source looks like the following

     domain: code fixed bin, address char(20) ; relation: zip(code* address) ;

and the submodel source looks as follows

     relation: zip_code = zip ( number = code ) ;

     attribute access: number in zip_code (modify attr) ;

Then the meaning of the submodel definition is to first remove the attribute
address from the submodel view, second to rename the attribute code as number,
and finally to rename the relation zip as zip_code.

If there had been no { = name } option for the relation name, then the relation
would have been known as zip, and that name would have to be used in the
submodel definition name for the relation.

The overall access allowed for the user of this submodel in a secured database
is null on the relation zip_code, and read and modify operations on the
attribute number.


                                          -----------------------------------------------------------


Historical Background

This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. 
as a contribution to computer science knowledge.  
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system. 
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture 
for managing computer hardware properly and for executing programs. Many subsequent operating systems 
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., 
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .

                                          -----------------------------------------------------------

Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
    Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
    Copyright 2006 by BULL HN Information Systems Inc.
    Copyright 2006 by Bull SAS
    All Rights Reserved