Data Definition Facilities in Admin

Data Definition Facilities in Admin Naveen Prakash, Parimala N. and N. Bolloju Systems Group, Computer Maintenance Corporation Ltd., Jeevan Vihar, 3, Parliament Street, New Delhi-110001, India INTRODUCTION Admin is a database management system suited for administrative work. That is, it is aimed to be used in decision making and allied corporate management tasks. It is an experimental, research DBMS aimed finally at the release of a commercially exploitable product. Admin aims at providing a database interface to a large number of host languages such as COBOL, FORTRAN and Pascal. In order to ensure this (as with the CODASYL'S DDL) the DDL defined is treated like an 'abstract' DDL from which language-specific subschemas (see next section) can be generated. This DBMS is based on the network model of data. It differs considerably from the CODASYL DDLC proposals1 and, in its basic model resembles Sangrah2 rather more closely. However, even when compared with this DBMS there are marked differences in Admin. We list below some of the special features of Admin. 1. No repeating groups or vectors are allowed. 2. Areas are not supported in the logical structure. 3. Set types (coset types, in Admin terminology) cannot contain more than one member record type (corec type in Admin). The reason behind departing from CODASYL terminology is that we make a fair number of departures from the CODASYL notions of a record type and a set type. Consequently, we chose the relatively neutral terms, corec and coset to denote these two types, respectively. 4. As a consequence of (2) above, there is no notion of a current of Area. There is also no current of rununit. In fact, there are only two currency indicators, the current of corec type and the current of coset type, respectively. 5. There is a capability to define value sets. With the help of these, a field of a record can be specified to take on values from a user defined set of values. 6. It is possible to define new corec types on top of existing corec types. These newly defined types may be designated as snapshots or evolving views. As will become obvious later, our notion of snapshots and evolving views is not identical to that described by Tsichritizis.3 7. It is also possible to define new coset types on existing corec types. 8. Member duplicates on a sort key can be further ordered in an ascending or descending manner. 9. Facilities exist to provide a certain amount of decentralization in the definition of schemas. 10. There is an authorization scheme based on passwords. 11. Access right specification is not based on the lock/ key mechanism. Instead, access rights are explicitly specified. 12. There is provision for the specification of integrity constraints on corec and coset types. 13. There is a simplified user interface for handling concurrency. 14. Errors encountered while executing a DML statement are not reported by an exception code in an error-status register. Instead, errors are handled by the introduction of standard functions and by giving fatal errors. In this paper, we shall consider only a few of these features of Admin. For un understanding of features (1) to (4) above, the reader is referred to Ref. 4. Error reporting is covered in Ref. 5. In the next section we shall,first,describe the schema to subschema relationship in Admin. Thereafter, we shall describe the manner in which different language-compatible subschemas are produced. In the subsequent sections we shall consider value sets, the definition of new corecs and new cosets, and authorization and access control. THE SCHEMA/SUBSCHEMA RELATIONSHIP The basic assumption is that every schema is a subschema. Fairly often, we refer to the schema as a subschema at level 0. It is recognized that the subschema at level 0 is the most privileged subschema in a database system. Consequently, this subschema has all access rights (see below) granted to it. The second rule followed in Admin is that a subschema can spawn other subschemas. Thus, over the subschema at level 0, it is possible to build subschemas at level 1. Likewise, over these latter subschemas we can construct subschemas at level 2 and so on. In theory, by this process we can construct any number of levels of subschemas once the subschema at level 0 is defined. However, because of the implementation restrictions, we can CCC-OOIO-4620/83/0026-0329 $03.50 © Wiley Heyden Ltd, 1983 THE COMPUTER JOURNAL, VOL 26, NO. 4,1983 329 Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 Admin is a database management system based on the network model of data. It has a number of data definition facilities over and above those provided by the CODASYL DDLC. It is possible to define a schema and build subschemas on top of it. Further, one can build another layer of subschemas on any given subschema, subject to the restriction that a total of 63 subschemas are built on top of any schema. It is also possible to define one's own value sets from which fields of records can take on values. Further, one can build 'new' corecs over currently existing corecs. Similarly, one can also define new cosets between any pair of corec types currently existing in a subschema. There is also an authorization and access control specification available with Admin. All these features are described herein. N. PRAKASH, PARIMALA N. AND N. BOLLOJU 330 THE COMPUTER JOURNAL, VOL. 26, NO. 4,1983 We shall now consider the manner in which a subschema is denned. The first part of a subschema definition is the subschema header. This part is mandatory. It is followed by a value set part, which might be empty, a corec definition part and a possibly empty coset definition part. These parts must appear in the order in which they are specified here. We shall consider the header here. The header introduces the definition of a subschema. As mentioned above, each schema is a subschema. However, we use the two words schema and subschema in the headers as follows: (a) logical schema Name « switch list» (b) logical subschema mine; schema is Name « switch list)); The use of schema and subschema is for documentation purposes only. The interesting thing in the header is the switch list. In this list it is possible to specify both processing options and language options. As an example of the former consider the option SYNTAX. When this option is specified, then the subschema processor performs an analysis of the definition of the subschema, but does not convert it to an internal form. Thus, all trivial errors are trapped without too much expenditure of machine time. Another switch is the LIST option which produces a listing of the subschema being processed. The language options allow us to specify the language(s) which will be used as the host. It is the duty of the processor to convert the definition of the subschema into a form compatible with the language(s) specified. As a first implementation, the language options that can be specified are Pascal, COBOL and FORTRAN. Of these, Pascal has already been implemented. The notion of language options helps us to view the DDL of Admin as an abstract language. This DDL is not oriented towards any specific host language. On the contrary, the user is free to decide the language in which he wishes to write his programs. It is, of course, possible that the users of subschemas may want to write different programs in different languages. In such a case, they have to choose more than one host language and have to exercise more than one language option. As mentioned above, the processor would then produce 'object' subschemas which are compatible with the various languages given in the switch list. Once the various host language-compatible-subschemas are developed we expect that the user of Admin will run the COBOL DML processor or the Pascal DML processor, etc. These processors will pick up the definition of the COBOL oriented subschemas, the Pascal oriented subschemas etc. and include it in the user program. The Pascal DML processor has already been implemented by us. VALUE SETS A value set is a set of values. When a field of a record is defined then it is mandatory to specify the value set from which thisfieldwill take on values. The most elementary value sets are the primitive types. For Admin, these are the types integer, real, Boolean and character string. Using these elementary value sets a Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 construct only two further levels once the schema is denned. That is, we can construct subschemas at levels 1 and 2 once the schema is available to us. Further, a total of 63 such subschemas can be constructed in any implementation. In order to establish the desirability of a facility for building different levels of subschemas consider a manufacturing concern. Let this concern be represented by a schema 5 which contains information about sales, personnel and its engineering activities. Corresponding to each of these activities, let there be three subschemas 51, S2, S3 built on S. Now, it is possible that this organization has split up its engineering wings into two parts called the design department and the production department. One can see that, if the information to be conveyed to these departments is a subset of the information in 53, then it would be most useful to build two subschemas S3' and 53" over 53, corresponding to these two departments. It should be obvious that 5 is the subschema at level 0, 51, 52, and 53 are subschemas at level 1 and 53' and 53" are subschemas at level 2. It is possible, even in the case considered above, to write two separate subschemas 53' and 53" at the same level as 53. However, we do not favour this because of the extra burden that this would impose on the DBA. Instead, we prefer to associate a sub-DBA function with each subschema. That is, the subschema 53 in the example considered above would have its own DBA who would be responsible for the creation of other subschemas. This DBA would function within his own realm and, as we shall see, could create new corecs or cosets as needed. He can also do limited amounts of reorganization and performance monitoring. This, however, is restricted to the corecs/cosets that he has created in subschemas denned by him. From this, we can draw the third rule of Admin, namely, all DBAs (called owners of subschemas by us) can reorganize and monitor the performance of all objects created by them. We shall see below that all subschema owners can pass on, to other subschemas created by them, a subset of the access rights that they possess over the objects in the respective subschemas owned by them. From the foregoing, we see that the facility for the definition of subschemas at various levels gives rise to a hierarchy of subschemas. As the level number increases in this hierarchy a progressively smaller part of the database with lesser access capability is made available along a given path of the hierarchy. Further, at each node of this hierarchy (that is, at each subschema) sufficient decision making capability exists to define nodes at a higher level number with this node as the root. In this way, the conventional DBA function can be decentralized. This will most certainly reduce the responsibility of a centralized DBA and, we conjecture, will result in 'better' information being available at various nodes of the hierarchy. Now, the fourth rule of Admin says that each subschema can, potentially, have users who wish to manipulate the data made visible to them by the subschema. These users are programmers who write application programs to use the database. The authorization mechanism used to check for authority of use will be considered below. We shall also consider the manner in which subschema owners are distinguished from users of the subschema. DATA DEFINITION FACILITIES IN ADMIN DBA can define his own value sets. There are two kinds of value sets in Admin, called the domain and the subrange, respectively. When a domain is defined, the values that can be taken on by a field defined on this domain are enumerated as follows: Week = (1,2,3,4,5,6,1); Colour = ('green', 'brown', 'cream') Month = 1 to 12; Subranges can be defined over the integers only. With each value set a string of blanks or a zero is automatically included by the system. This is dictated by the underlying type of the value set. The string of blanks has a length equal to the length of the character string defined in the value set. The owner of a subschema at level 0 can define value sets and use these to describefieldsof records within this framework. However, all other subschema owners must follow certain conventions when defining and using value sets in their own subschemas. These conventions are given below: (1) A subrange can be defined in a subschema. It can be used to designate the type offieldprovided one of the following conditions hold: (a) the corresponding field in the underlying subschema is defined over the integers (b) the corresponding field in the underlying subschema is defined over a subrange and the subrange just defined is a subrange of that in the underlying schema. (2) A domain can be defined in the subschema. It can be used to designate the type of a field provided one of the following conditions hold: (a) The corresponding field in the underlying subschema is either integer or real. (b) The corresponding field in the underlying subschema is itself defined over a domain and the domain just defined is a subset of that in the underlying subschema. DEFINING CORECS AND COSETS In this section we shall consider the manner in which corecs and cosets can be defined in Admin. In doing so, we shall concern ourselves, with only the more interesting aspects of this definition, namely, those that deal with new corecs and new cosets. At the outset, we would like to state that the facility of defining new corecs has become very restricted as compared to the original proposals with which we started out. In the originating proposals we envisaged the New corecs We define two kinds of corect types in Admin. These are called unqualified corecs and qualified corecs, respectively. Unqualified corecs are the conventional corecs whereas qualified corecs are new corecs. A qualified corec type is built over two unqualified corec types, called the base types, which must have been previously defined. A qualified corec type can either be a snapshot or an evolving view. A qualified corec, by virtue of the fact that it is built over two corec types, contains in it selected portions of these two types. Thus, the corec being defined presents an altogether new view of the underlying corecs. The new corec may have either of two properties as follows: (i) It may reflect, at all times, all updates made to the base corecs and all updates made to it may be reflected in the base types, or (ii) Once created, it may become independent of updates made to the base types. Similarly, updates made to it may not be reflected in the base corec types. The former kind of qualified corec types are called evolving views and the latter are called snapshots. Now, the construction of qualified corec types is dictated by the manner in which selected portions of underlying corecs are combined together to form the new corec type. One method of construction relies upon selecting totally arbitrary portions of the base corecs whereas the other exploits the occurrence of common fields in the two bases. These fields are called joining fields. We shall consider both these methods in some detail here: Totally arbitrary portions. When a qualified corec Z is built over two bases X and Y then any part of X and Y may be selected to define it. Since there is no rule by which Z is constructed over X and Y, initial loading of Z can only be performed by a user-written program which exploits real world knowledge. Hence Z can be loaded by retrieving X and Y and thereafter by creating Z in the UWA and storing it. Since recourse has to be taken to a user's real world knowledge to make an entry of type Z in the database, it follows that Z can be a snapshot corec type only. This is because the system is unable to ensure that all updates to Z are reflected in X and Y and vice versa. It must be noted that a definition of Z can only be made in a subschema which contains in its view both X and Y, otherwise its initial loading will be impossible. Joiningfields.As mentioned above, joining fields are those which can be exploited for the definition of qualified THE COMPUTER JOURNAL, VOL. 26, NO. 4,1983 331 Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 Value sets which are of the kind domain can be identified over the elementary value sets integer, real and character string only. It must be noted that we assume no ordering among the values specified for a domain. Further, when domains are defined over character string then all values in the domain must have the same length. For example, the domain Colour has values of length 5 characters only. A value set which is a subrange provides a lower bound and an upper bound on the values which a field defined on the subrange can take on as follows: definition of new corecs by the owner of any subscema in the database. However, as the design got more detailed and as the implementation got more crystallized we found that this generality could not be achieved without severely compromising efficiency. Further, we decided to adopt a cautious approach towards this generality. Accordingly, we felt that until we had implemented and studied the behaviour of a restricted definition of new corecs we should not attempt to realize the original proposals. We shall present here the part of these proposals which have been accepted in Admin. N. PRAKASH, PARIMALA N. AND N. BOLLOJU corec types. We shall consider the meaning of joining fields before explaining the way in which they can be used for the construction of corec types. Let the two base corec types used in the construction of a qualified type be Basel and Basel. Let Fieldlistl and Fieldlistl be the lists of fields of these corec types, respectively. Then these two lists could be designated as the joining field of the newly constructed corec type provided: (i) either both Fieldlistl and Fieldlistl (see above) are unique keys of their respective types, or (ii) one of the field lists, say Fieldlistl, is a unique key whereas the other, Fieldlistl, is not. It follows that these conditions help us to build 1:1 and 1 :N relationships between Basel and Basel. Note that an M:A^ relationship (both field lists being non-unique keys) is barred because of implementation reasons. Let us now see the manner in which snapshots and evolving views can be developed by a use of joining fields: Snapshots. When the new corec type is a snapshot then it may exist in a subschema which does not contain the base corecs provided that this schema is at a level one higher than that containing the base corec types and is built on top of this latter subschema. The loading of such a snapshot can be done by the Rload utility (considered later). Evolving views. A new corec defined as an evolving view must be defined at all levels from the schema up to the present level in all subschemas along the path linking the schema to the current subschema. After its definition in the schema it should be included in the subschemas at the various levels as per the normal methods of subschema definition. In doing so, recourse may have to be taken to the reorganization utility available with Admin. Initial loading of data into evolving views should be done using the Rload utility. By virtue of the fact that snapshots become independ332 THE COMPUTER JOURNAL, VOL. 26, NO. 4,1983 (i) A record occurrence for both the types is not found. In this case, the subsets of Basel and Basel constituting cored are stored after cored itself has been stored. (ii) A record occurrence of one of the types, say Basel is found. Here, all fields of Basel which appear in cored are compared with the corresponding fields of the record found. If the values in these fields match, then a store into Basel is not performed. However, the subset of Basel is stored after storing cored. On the other hand if values in the fields of cored do not match those in the record of Basel then the user is trying to store records which have duplicate values in their joiningfields.This violates a 1:1 relationship. Consequently the user's program is aborted. (lii) A record each in Basel and Basel is found. The same action as in (ii) above is taken for both the base records. The Rload utility was mentioned above in connection with loading of snapshots and evolving views. This utility searches the occurrences of the base corec types to find a match on the joining fields. If a qualified corec capturing a 1:1 relationship is to be loaded then whenever an occurrence of Basel has joining fields identical to those in Basel, an occurrence of the new corec is stored. If the qualified corec type captures a 1: N relationship between Basel and Basel then for every occurrence of Basel all the occurrences of Basel which match on the joining fields are searched for. For each such match an occurrence of the qualified corec type is created. As pointed out by the referee of this paper, it is possible to construct qualified corecs by using predefined coset relationships. This, however has not been attempted by us. New cosets New cosets can be defined in any subschema at any level. It is necessary that the corec types over which these coset types are defined be included in the subschema concerned. These new cosets are equivalent in every respect to other cosets, e.g. one can specify integrity constraints on them. The only restriction that is imposed on new cosets is on their inclusion and retention properties. For new cosets Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 (a) each field in Fieldlistl is of the same type as that of the corresponding field in Fieldlistl, and (b) the two field lists are defined as keys, not necessarily unique of the respective corec types. The purpose of defining joining fields is to develop a rule by which occurrences of the new corec type have to be created. In such cases those occurrences of the underlying types are selected which have the same values in their respective field list. Thereafter, the appropriate parts of the two records selected by this process are picked up, reordered if necessary, and combined together to define the occurrence to be created. Whereas the foregoing gives an idea of the way in which joining fields can be used, it is by no means the end of the story. We shall consider the use of joining fields in greater detail later. For the moment it must be understood that a match on the values contained in the joining fields is the cirterion we use for the creation of occurrences of the new corec type. Now, having considered the notion of joining fields let us see how they can be used for construction of new corec types. A new corec type can be defined on two base corec types, Basel and Basel provided: ent of the base corec types giving rise to them, they are relatively simple to handle. However, evolving views are complex objects. As an example of their complexity consider the store operation for an evolving view corec type called cored. Let it capture a 1:1 relationship between two base types Basel and Basel. If either of Basel or Basel is stored then it becomes necessary tofindout whether an occurrence of cored has to be created or not. In order to do so, a search has to be performed to find out whether the joining fields of Basel and Basel match. If they do match then the action considered above for the storage of an occurrence of an evolving view has to be initiated, otherwise not. Now consider the effect of storing an occurrence of cored. A search is initiated for records of both Basel and Basel using the values of the joining field in cored. The following cases arise: DATA DEFINITION FACILITIES IN ADMIN is is necessary that (a) inclusion be manual, and (b) retention be optional. AUTHORIZATION AND ACCESS CONTROL Authorization The authorization check relies on a password mechanism, which is described here. When a subschema, be it at the level zero or at any higher level, is being processed then it is expected that a password will be supplied to the system. In fact, the processor, once it finds that a valid subschema has been fed to it, outputs a message on the terminal asking for a password or for two passwords (see below). The password supplied is then stored together with the definition of the subschema for further use. Let us study this general framework in more detail. If the processor is currently processing the subschema at level 0 then the password supplied is treated as the password of the owner of the subschema at this level. Later, when a user asks for DBMS facilities such as reorganization, database performance, cross-reference listing etc. for the schema, he is expected to supply this password. Upon receiving the password supplied by the user, the system checks out whether the password supplied is, indeed, the password associated with the owner of the subschema at level 0. All subschemas at levels 1 and 2 will have two passwords associated with them. These are called the owner and the user passwords, respectively. A user who supplies the owner password of a subschema at any of these levels is given all the privileges of the owner of this subschema. On the other hand, a user who supplies the user password of such a subschema can access the part of the database defined by the subschema in the role of an application programmer. From the foregoing, it follows that there is a certain skewness in the authorization technique for subschemas at level 0 and those at higher levels. We shall give the reasoning behind this. As a general principle, we propounded the existence of two passwords, the owner and the user passwords for every subschema. This is because these two classes of user groups have different privileges with respect to the subschema concerned. The only way in which a password mechanism can determine what privileges are to be granted to different users is on the basis of differences in the passwords supplied. Now, whereas it is reasonable to assume that various application programmers will interact with subsets of the database, it is unlikely that there will be any application programmer who wishes to manipulate the entire database. Consequently, it seems reasonable to introduce (i) The owner of a subschema at level 0 can change his own password and the password of any other person, be he the owner or the user of a subschema, (ii) The subschema owner at level / (i greater than zero) can change the owner password as well as the user password of the subschema owned by him and of all subschemas spawned by him. (iii) Any user of a subschema at level i (i greater than zero) can change the user password of his own subschema. Access rights The system provides various access rights on the database. Associated with each access right is a set of operations that can be performed by a user having this right (see Table 1). At the time a subschema is defined, it is possible to associate access rights with eachfield,corec type or coset type defined in it. Consequently, a user who is authorized to access the database via this subschema can perform only those operations on the objects in the database as are determined by the access rights defined on these objects. As an example of the way in which access rights are defined consider Corec Person; Find, Obtain, Store; Age Value from integer; Modify; end; Here a corec, Person, is defined and the rights, Find, Obtain and Store are granted. The field Age is allowed to be modified. It must be noted that the owner of the subschema at level 0 has universal rights. In other words, he can perform any operation on any element in the database. This is because we adopt the philosophy that the authority which defines a logical structure can manipulate it in any way. As a result of this, if a snapshot is defined by a subschema owner for a subschema at level / then all access rights are granted for this snapshot to the owner of this subschema. However, because of the nature of the network model of Admin there are certain limitations on the access THE COMPUTER JOURNAL, VOL. 26, NO. 4,1983 333 Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 As is well known, authorization refers to the prevention of unauthorized users from accessing the database. Access control, on the other hand, deals with the problem of ensuring that authorized users access the database according to well defined rules. Thus, if there is an authorized user (/of a database then he might be allowed to read a record but not to update it. Such an access rule falls under the purview of access control. We shall now consider both authorization and access control in turn. the notion of user and owner passwords for all subschemas except the one at level 0. Therefore, we departed from the general principle enunciated earlier and chose to create the skewness referred to above, namely, all subschemas have an owner and a user password except the one at level 0 which has an owner password only. Since every owner password is more privileged than the user password, in those rare cases where access to the entire database is desired, an application programmer can supply the owner password of the subschema at level 0 and can perform the manipulation desired. We have considered above the manner in which passwords can be defined. In order to preserve the privacy of the database it is more than likely that all persons interacting with a database will wish to change their passwords at some time or other. Changes to passwords can be made by using the Password utility. The rules according to which this utility functions are as follows: N. PRAKASH, PARIMALA N. AND N. BOLLOJU Table 1. Access right D ML operations that can be performed Comment INVOKE, MARKER, DEFINE These declarations do not need any access rights. These statements do not require any access rights. These Boolean valued functions can be referred with no access rights. MARK, RESTORE, SHIFT, ESTABLISH, TBEG, TEND FIND (oncorec) FIND (oncoset) OBTAIN (oncorec) OBTAIN (oncoset) rights that can be granted to different subschemas. As an example, consider the delete right. Let Cr be a corec type of a subschema at level /. Let Cr participate as an owner type in a coset CS. Further, let CS have retention fixed or mandatory. Now let there be a corec type, cored, defined in a subschema, SS, at level i• + 1. Now, our desire is to grant the delete right on correcl. In order for us to be able to do so, it is necessary to ensure that deletion of cored is possible in SS. This is so because if the logical structure of SS is such that deletion is not possible then, clearly, it is useless to give this access right in SS. In order for deletion to be possible, SS should possess the following structural characteristics: (a) It cored is a subset of Cr then CS should be available in the subschema. (b) If cored is a subset of an evolving view, cored, such that cored is built using Cr, then CSmust be included in the subschema. The delete right can be granted without any restriction on all corec types not covered by the two conditions above. Once it is ensured that these structural characteristics are indeed met by SS, we can grant the delete right on cored. It is however, unfair to leave the owners of the subschemas alone to check out if certain operations can be performed at all in a subschema or not. Admin is able to provide some help in this regard. This is as a direct consequence of the fact that we do not use a lock and key mechanism for the specification of access control. On the other hand, because we ask for access rights to be specified explicitly in terms of the operations to be performed, we can determine, precisely, those operations that are intended to be performed. However, we also know the structural characteristics which permit an operation to be performed. Consequently, the processor can check out that a given access right is meaningless because the action that can be performed under it is not possible. In fact, this processor can even ouput a message detailing the exact structural deficiency which results in the access right being meaningless. In the foregoing, we have considered the limitations imposed by the network model of Admin in granting 334 THE COMPUTER JOURNAL, VOL. 26, NO. 4,1983 May only May only May only May only May only May only be specified on the coset type. be specified on the coset type. be specified on the coset type. be specified on a field. be specified on corec types. be specified on corec types. access rights. These limitations are to be viewed in the overall rule that one can only grant access rights to another in such a way that the access rights granted are a subset of the rights possessed by oneself. Thus, the access right mechanism has to ensure two things: (a) The access rights are in conformity with the structural characteristics of a subschema. (b) The access rights being granted by X are a subset of the access rights possessed by X. Once both these checks are found to be valid the access right mechanism is through. However, we must not lose sight of the fact that granting access rights is a dynamic process. It may happen that the access rights of a user have to be augmented with yet others or that a given right has to be revoked. This kind of dynamism is handled by the reorganization utility of Admin. In doing this the utility has to ensure that: (a) No user of a subschema meddles with his own or some other users access rights. (b) No owner of a subschema usurps more rights than are to be granted to him. In order to ensure (a) above, we allow access right modification only by those people whose password identifies them as owners of subschemas. Further, in order to enforce rule (b) above we allow an owner of a subschema to modify the access rights of all subschemas spawned by him subject to the restriction that he is allowed to modify the rights of only those structures which he has created and passed over into the subschemas. In other words, he cannot modify the rights of a subschema with respect to structures created within the subschema. CONCLUSION We have described here the data definition facilities of Admin. Admin is currently under implementation at the DEC-10 at LIT. Kanpur. It is being written in Pascal with all machine dependent parts in BLISS-10. Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 REMOVE TRANSFER INSERT MODIFY STORE DELETE FOUND, COSBEG, COSEND, EMPTY, TENANT, CORBEG, CORSEND FIND on the corec type. FIND on both the owner and member corec types through the coset type. OBTAIN on the corec type. 0 BTAIN on both the owner and member corec types through the coset type. REMOVE on the member corec type in the coset type. TRANSFER on the member corec type in the coset type. IN SE RT on the member corec type in the coset type. MODIFY on the field of a corec type. STORE on the corec type. DELETE on the corec type. DATA DEFINITION FACILITIES IN ADMIN REFERENCES 1. Report of the DDLC. Inform Sys. 247-320 (1978). 2. Naveen Prakash and Parimala N, A typed data definition language. Technical Report, NCSDCT.TIFR, Bombay (1980). 3. 0. C. Tsichritizis and F. H. Lochovsky, Data Base Management Systems, Academic Press (1977). 4. Naveen Prakash et al., Samhita—A. data base management system. The Computer Journal 24 (1), 48-51 (1981). 5. Naveen Prakash and P. N. Gejji, Error reporting and recovery in Sangarh. Software—Practice and Experience, 1 1 , 613-621 (1981). Received December 1982 Downloaded from https://academic.oup.com/comjnl/article-abstract/26/4/329/377423 by guest on 09 April 2019 THE COMPUTER JOURNAL, VOL. 26, NO. 4,1983 335