MULTICS TECHNICAL BULLETIN MTB-641 To: MTB Distribution From: Paul W. Benjamin <Benjamin @ System-M>, Ronald B. Harvey <Harvey @ System-M>, L. A. Dupuis <Dupuis @ System-M> Date: 12/20/83 Subject: The View Manager Facility Forum Meeting: >udd>m>mtgs>End_User_Data_Access (euda) ABSTRACT This paper describes the View Manager Facility, a comprehensive new package for information management. It was first discussed in MTB-621, An Architecture for End User Data Access. It is an overview, supported by 4 more detailed papers: MTB-642 The View Manager Facility: Subroutine Interfaces MTB-643 The View Manager Facility: View Master Subsystem MTB-644 The View Manager Facility: SQL Parser MTB-645 The View Manager Facility: Data Dictionary Interface This set of papers represents a major portion of the workplan for the End User Support Unit for the next 2 years, with MR12 as the target release. _________________________________________________________________ Multics Project internal working documentation. Not to be reproduced or distributed outside the Multics Project. MTB-641 View Manager Background This proposal emerged in early to mid-1983 from a discussion initiated by Roger Lackey about something called a 'join manager'. The idea was that an intermediary could sit between MRDS and the user that could request retrievals and do joins. The retrievals could be from separate databases or even from non-MRDS tables. An informal group was established to discuss the idea further. That group soon determined that another key idea in the design should be the replacement of LINUS with a new end-user facility, and that a new selection languange more along the lines of the IBM (and potential industry standard) SQL language should be used. Those discussions continued and were expanded to include several more people. The project was internally dubbed PITS, an acronym for "Pie in the Sky". The result of those meetings was MTB-621, An Architecture for End User Data Access, a crude manifesto that listed 9 authors and detailed the concept as it existed at that time. That paper is recommended to the reader. The information therein that has not been substantially altered is not reproduced here and it will provide an historical perspective on this topic. After the publication of that early paper, PITS development went on the back burner in favor of MR10.2 activities (MRDS, LINUS, GES), but weekly discussion sessions were held to progress towards a more concrete design and to keep the idea alive. Much evolved during that period, as will become apparent as you read these papers. When MR10.2 was in place, full attention was turned to the PITS implementation, and a lot more changes took place. Introduction These MTBs are the result of the effort discussed above and will serve as a basis for the development work to follow. They are intended as living documents, will evolve first into design specifications for the planned prototype effort, then serve the same purpose for the actual implementation, and then finally be kept up to date as the product goes into production and maintenance. It should be understood, therefore, that these are the first versions of many, that there are unanswered questions and inconsistencies, but that they are being published in hopes of obtaining feedback from the Multics development community. As this is a complex subject, introducing many terms and concepts, 3 appendices are supplied to the reader, that may be of use throughout the reading of these papers: Appendix A, Module Organization; Appendix B, View Manager Terminology; and Appendix C, Permissions on View Manager Objects. They are located at the end of this document. View Manager MTB-641 The SQL Language The language used to do relational operations (both in the end user facility and via the programming interfaces) is SQL, as defined by IBM literature, followed as closely as possible. There was lengthy discussion within the group on how close to follow the language, whether or not to multicize it. The consensus was not to be tempted to "improve" on an language that is a) commercially successful and b) close to becoming an industry standard. The language is described in exhausting detail in MTB-644. The parser for these statements will be implemented using LALR. This raises some concerns about LALR being an unsupported product. It is a given in this proposal that it will become a supported product, although the questions of who and when are not resolved. MTB-621 discussed the "uniform translator proposal". We had proposed a common parser that could accept not only SQL but existing LINUS and MRDS selection language as well. We have now backed off from that aspect of it, for reasons discussed in MTB-644. The parser will produce what is being called Canonical Query Language. MTB-621 discussed CQL in some detail, particularly the Honeywell efforts to produce a common language across various product lines. As of this writing there is no such common language. An investigation of the GCOS CQL proved it to be less than optimal for these purposes. The option is still left open however, to converting to such standards should they be established. The View Master Subsystem The proposed end user facility is called View Master. It will be an interactive subsystem using ssu_. There are 2 ways to enter SQL statements, either at request level or via an input_sql request. The former approach involves the command processor and may require quoting, while the latter allows the user to type into an input buffer. The standard ssu_ requests are available, as are the requests associated with the LINUS Report Writer. A useful by-product of excising the the Report Writer from LINUS and making it available to View Master will be that it will be made generally available as a standalone offering. It is described in detail in MTB-643. MTB-641 View Manager View Manager Subroutine Interfaces At the core of things lives the view manager itself (vm_). It accepts input in the form of CQL and returns data. To do this, it communicates with the various file managers (MRDS, Lister, the "native file" manager) through Table Interface Modules (TIMs). These TIMs are a veneer that have a standard calling sequence and communicate with the appropriate specialized interfaces that the file managers use. In some cases (MRDS for example) the TIM will likely be a separate module that calls the file manager's standard subroutine interface (dsl_ in this case). In others (native files, perhaps Lister), the TIM may be an integral part of the package and the only available subroutine interface. The vm_ module also does a great deal of communicating with the data dictionary interface, described below. The vm_ module is described in MTB-642. While the parser may be identified as a vm_ entrypoint, it should be stressed that it is not an integral part of vm_. It shares no data structures, other than those passed (or pointed to) as parameters, with vm_. It is a primary design goal that any parser or other program capable of producing CQL is sufficient for the View Manager's purposes. The SQL parser just happens to be the one that is being provided, for now. Data Dictionary Interface The term "Data Dictionary" is much abused. Everybody wants one. Many systems claim to have one. One approach to the term revolves around the "meta-data" that describes a data structure or database. In that sense, the MRDS model is a crude data dictionary. On the other end of the spectrum is the "active data dictionary", an all encompassing facility that keeps track of databases, programs, data items, etc., anything the site chooses to add, and adjusts everything involved when something listed therein changes. The latter is a hot button with customers. It is also far beyond our resources to provide. Our goal, then, is to provide the facility needed for meta-data handling, without precluding the ultimate implementation of such an active facility. Again, the IBM implementation is taken as a model. The meta-data is treated as relational data, organized in tables and manipulated by the View Manager software. See MTB-645 for details. Native Files, Integrity, Security This is an area that was not addressed in MTB-621. No thought was given to a native file type. The original design goals for the product included cross-database retrievals, a better EUF, support of non-MRDS tables, etc., but nothing on integrity or View Manager MTB-641 security. There was a spirited debate among the group about the issues of integrity and security. The end result was that there was a requirement for a level of integrity and security no less than that currently offered with MRDS, and that, as a desirable item, much more was needed. It soon became apparent that something must be chosen as a native file type. What would be created when the user typed "create table"? If temporary tables were handled, what form would they take? Should it use MRDS? This seemed unfortunate from many standpoints, not the least of which was that a single relation MRDS database seemed overkill for such purposes. Lister was out of the question. How about something new? The discussion soon turned to the relation manager interface. FAMIS was determined to be the vehicle of choice. This is an attractive route as it deals with the integrity issue. It also provides transaction and rollback capabilities, an integral part of the IBM implementation. Further, it is plug-compatible with vfile_relmgr_ which can be used, as needed, in the development effort. Note that this decision about native files was a turning point. After starting out to create a package that would tie together MRDS, Lister, etc., what was under discussion had become a new database manager, more or less. What of security, though? Even though FAMIS files are ring-2 entities, if you know the calling sequence of relation_manager_, you can do what you please, disregarding any security that was built into the view manager. This is essentially what is wrong with MRDS today, even with secure submodels. The IBM model that is being emulated exists in a very different environment, one that would require domains to be implemented properly. Discussion of domains with Olin Sibert and others has convinced the group that domains are not something easily or appropriately implemented on Multics. So, what else? What is desired is the ability to control access through a data dictionary, to restrict users to looking at data through views, views that might hide portions of a physical file from a user while allowing the update of other parts of it. This has to be enforced by the view manager software itself, cannot be accomplished via acls. The answer lies in FAMIS pseudo-rings. Stored in the FAMIS file are pseudo-rings. That portion of the view manager that controls access resides in ring-2. FAMIS compares the rings in the file to the validation level of the calling program. The view manager files will require the caller to be executing in ring-2. Only view manager, therefore, will be able to modify the files. Knowing the calling sequence of relation_manager_ will not be enough. MTB-641 View Manager Security and Usage Considerations One of the goals of the view_manager design is to be able to have data content security for any given (native) table. At least the same `security' offered by MRDS is also a goal. This is thought to be most easily accomplished with views. Properly used, views can provide data content security and column (MRDS submodel-type) security. Consider the following view definitions: CREATE VIEW DEPT_512 AS SELECT * FROM EMPLOYEES WHERE DEPT_NO = 512 CREATE VIEW EMP_VACATION AS SELECT NAME, DEPT_NO, MAIL_STATION, HIRE_DATE, VACATION_DAYS_USED FROM EMPLOYEES If a user (say, the manager of department 512) were given access to the table EMPLOYEES and to the view DEPT_512, then there would be no way to keep the data in EMPLOYEES secure. If, however, access is not GRANTed to the table EMPLOYEES for the manager, but only to the view DEPT_512, then the manager can only see the data selected by the view. The access to a given table or view is only relevant when that table/view name is specified in a FROM clause. Similarly, a user given access to only the EMP_VACATION view would not be able to determine salary data. To this end, the permissions on a view are kept with the view, and the permissions on the built-upon tables are only relevant when the view is created and when the permissions on the built-upon tables are changed to modify the access for the creator of the view. In this way, a user does not need access to a table (cannot say `FROM FOO') in order to use a view that references it. As mentioned previously, when a view is created the creator's permissions on the tables referenced in the FROM clause of the definition are used to form the permissions on the view for that user. No one is then allowed to put more permissions on that view than already exist. That is, the user could not change a SELECT permission on a given column to SELECT, UPDATE permission. Also, if the user does not have GRANT access to all of the base tables involved, no permissions for other users will be permitted on the view. In this way, the view actually has the permissions on the lower level tables. Users have access only if they have access to the view. If the creator of the view ever loses permissions on one or more of the tables built upon, then that change in permission should "ripple" and cause the view permissions to either change (as in the case of removing UPDATE), or cause the view to be deleted (as when all access to a table disappears). Where more permissions are given (adding UPDATE to a column), nothing automatic should happen. This will keep accidents from happening. The GRANT request will probably be View Manager MTB-641 able to be used on the view to add the permission if the appropriate permission is available on the built-upon table. Data Security and Multics Security While all of this automagical access determination sounds very nice (and is similar to competitors' offerings), it places a big burden on the view manager and data dictionary software. In a Multics environment, a user needs modify permissions on the containing directory of a file system object in order to change an acl on that object. Also, the user must have access to an object in order to use it - even if, as in the DEPT_512 case above, the user may not know the object (the EMPLOYEES table) is being used. These Multics realities can cause problems when views, assertions and triggers are created in an environment where not all users have permissions on all of the base tables involved. Also, a user (other than the creator) attempting to GRANT permissions to other users may be limited by the lack of modify permission on the containing directory of the object. There are several considerations involved in determing how security and Multics acls should be handled in this product. A goal is that it should be as close as possible to the competitors' products. The easiest way to assure that this can happen would be to put all objects in ring 2 with regular Multics acls of (rw sma) *.*.* and enforce the security by checking the appropriate data dictionary (which would also have similar real Multics acls). While this is the easiest, it also leaves open the door to more accidents (any code in ring 2 going amuck could cause damage) or misuse of ring 2 access by users not associated in any manner with the data involved. In order to limit this possibility, the current plan is to have tablespaces for storing native tables. A tablespace would be a ring 2 directory (ring brackets of 2,2) and an acl entry of `sma *.*.*'. This will allow any user authorized by the data dictionary to create tables, delete tables and change acls on tables. Although it may take some work to determine what acl should be on a given table for a given user at any time, the problem is thought to be solvable. This is still open to problems, however. Today, there is a bug in v1 forum which will allow a user to create a meeting in a ring 2 directory - such as a tablespace. Another argument against the `rw *.*.*' scheme is that one whole dimension of Multics security (in fact, the one most visible to normal users) would disappear. There is precedence for this, however, as mailboxes and message segments (where daemon requests are placed) are implemented in this fashion. It would be the complete and total responsibility of the view manager and the data dictionary to always be right about who is allowed to access MTB-641 View Manager what. This could open the door in the database software for security holes which don't exist in the Multics acl mechanism. These holes may be difficult to detect. Hopefully, they will not be difficult to plug. Another consideration is that unless you know which data dictionary owns a file system object, it would not be possible to determine what set of users had access (or even owns) the object. There is a similar concern even with specific acls. Given that views (and links to other data dictionaries) can place acls on file system objects, the owner of a table may be able to see who has an acl entry. But it may be impossible for a normal query of the owning data dictionary to determine WHY those people have access (or even differences between INSERT and UPDATE). It is possible that the view_manager should not get into the business of automagically setting acls at all and that native tables should be created with acl terms for the creator only. Unfortunately, this would mean that special code (or cql!) will have to be created to set acls on native tables, since they would be in ring 2 (and have pseudo-acls of ring 2 as well). This is also pretty far away from the competitors' world of access control and table management because the user would be responsible for doing everything by hand - including removing acls after permissions have been revoked. Ripples: Their Meaning and Some Implications Ripples are actions that are performed by the data dictionary and/or the view manager as a result of some other action. An example would be that DROPping a base table would cause a view that referenced it to be DROPped as well. Of course, if there were a view built upon this first view, then it would be dropped as well. With the exception of dropping a tablespace, all of the `drop type' ripples are controlled by and completely performed by the data dictionary software. In the tablespace case, the view manager will probably have to drop each table individually, and then drop the tablespace. A second type of ripple (and one which can cause more headaches) is one in which Multics acls need to be changed on an object. These can be caused by permissions being granted on views, by the creation of assertions and triggers, and, possibly, by dropping views, triggers or views, as well as, of course, simply revoking permission on a base table. If a Multics acl needs to be changed, the data dictionary will have to inform the view manager so that it can do the deed. There is a possiblity that synonyms will not be involved in `drop type' ripples. This would allow base tables to be switched out from underneath them so that a production data dictionary could View Manager MTB-641 be switched into `test mode' for a period of time. If a base table looked different from the one that was previously in its place, many problems could result. This is still under investigation. With the concept of links being used to enable data dictionaries to share tables and views, rippling can get very complex. The data dictionary software may have to lock several data dictionaries in order to do a simple task like adding a column to a base table. It is thought that this can be a potential cause of deadlocks. Also, with links and automatic updating through them, a user must have some way of modifying the other data dictionaries (under data dictionary control, of course) that have links to the data dictionary being used. This is especially important in the case where a view on a table in the current data dictionary is defined in some other data dictionary. Since the access on a view is kept with a view, access changes on the underlying tables MUST be able to trickle to all views. Application Programmer's Interface The vm_ interface is designed specifically for subsystem programming in a PL/1 environment. One of its biggest customers will be the View Master subsystem. There will be no pains taken to accomodate the applications programmer or the non-PL/1 programmer. There may be arguments required that use data types (pointers, for example) unavailable outside of PL/1. There may be approaches taken that are confusing or awkward for the applications programmer. For example, in order to have a SQL statement executed via the vm_ interface, you must, at the very least, call convert_sql_to_cql_ and then vm_$execute_cql. There are very good reasons for having 2 distinct calls here, very necessary to the subsystems programmer, but from a human factors standpoint, this is less than deluxe. It is recognized that the optimal interface for applications programming is via a compile-time preprocessor. It would be necessary to write such interfaces for COBOL, Fortran, PL/1 and perhaps Pascal. There are simply not enough resources for this. So, proposed, but not described in any detail in these papers, is the Applications Programmer's Interface (API). In the example above, a single call, for sake of argument, vm_api_$execute_sql, would be made. No pointers would be used, to accomodate users of COBOL or Fortran. Other End User Interfaces One of the original goals of this project was to provide an architecture that would facilitate the creation of additional end MTB-641 View Manager user interfaces. The design is such that a Query-by-Example package that produced CQL could be implemented with "relative ease". The information management market is evolving rapidly, and with it, the demand for menu- and forms-driven packages increases. Further, the latest intelligence out of IBM indicates that they are going in the direction of integrating SQL and QBE into a single package. It is recognized that, to be competitive in the marketplace, a foray into the video arena is critical. However, given the ambitious nature of the overall design and the resources available, a complete answer to this problem may not be available. Further, the lack of a generalized forms package on Multics would make any forms-oriented implementation very difficult. There will, therefore, be no attempt to implement a separate QBE-style forms interface in the MR12 timeframe. However, the View Master subsystem will provide a menu/prompting video-oriented interface in addition to the traditional request-oriented interface. This interface is taken as a desirable feature or "stretch goal" and will be investigated in the prototype effort. Risks, Benefits and Conclusions The proposed implementation of the View Manager represents one of the largest single undertakings the Multics project has ever attempted. While once a pioneer of sorts in the field of relational database technology, we have fallen behind. This is an attempt to make a quantum leap into the next generation of software, from database management to information management. It represents a large and costly investment in the future and can only succeed if we are willing to commit ourselves fully to it. It should, therefore, not be entered lightly. To start with the negatives, what are the risks? 1) Chasing IBM, in any area, can be a risky business. Halfway through the early planning stage of this project, they announced DB2 and QMF, a departure, on some levels, from the earlier things we had analyzed. There was much scrambling to make the design reflect the changes discovered. It will take a couple of years to get this product out. The competition will not stand still. Perhaps a better approach is to mimic the Japanese and attempt an end-run around the competition and investigate knowledge-based systems. 2) FAMIS. We are relying on FAMIS for integrity and for transaction capabilities. As of this writing FAMIS has significant performance problems. As FAMIS is not yet a product, our reliance on it could be considered a risk. Further, this design calls View Manager MTB-641 for rollbacks to checkpoints within a transaction, something currently not implemented (albeit planned) in FAMIS. 3) Effect on other products. Part of the scenario presented is that MRDS and LINUS development will effectively be frozen during the MR11/MR12 period, except for those changes necessary for the View Manager. Our customers are not likely to appreciate this. 4) Overall complexity. This is a very big project. MDC's track record with big projects is subpar. Having typed in 1) so convincingly, it might be appropriate to attempt to speak to the arguments presented. The intent here is not to compete head-on with Big Blue. The intent is to conform to what appears to be an industry standard, and therein open up, to some extent, the arenas in which we can compete. So far as still being behind once the implementation is complete, this is true to some extent, but the alternative is standing still. Looking at what is or may be the competition (DEC, INGRES, Oracle, et al) rather than IBM, the comparison might not be so unflattering. The bottom line is that we must go in this direction to survive. So, on to the benefits. 1) Users will be presented with a single, industry-standard selection language, SQL, usable at both the end user and programming levels. This language will offer many capabilities beyond the current MRDS repertoire, including cross-database retrievals, outer joins, sorting, triggers, assertions, etc. 2) There will be a single end-user facility that can access various types of tables, including, but not restricted to, MRDS databases, Lister files, native View Manager files and flat files. 3) Native files will be truly secure in that you cannot circumvent the access mechanisms by calling the underlying file manipulation routines directly. 4) Checkpoint/rollback services will be available. 5) A platform for building alternative end user facilities will be in place. 6) By putting our development resources into a new product rather than continually enhancing and maintaining MRDS, we can end up in a much better posture from a maintenance standpoint. Maintenance is a resource sink, and it is proven that the older a product is and the more it is enhanced/"fixed" MTB-641 View Manager the incidence of bugs and expenditure of maintenance dollars increase. To summarize, the View Manager, while not an attempt to boldly go where no man has gone before, is an attempt to bring Multics into the 1980s in the field of relational technology. It is a lofty proposal, one that should be given the closest degree of review by all parties involved. I strongly urge the reader to read the accompanying documents. View Manager MTB-641 Appendix A. Module Organization _________________ _________________ __________ | | | | | | | Report Writer |<--| View Master |-->| parser | |_______________| |_______________| |________| | |______ ^ | ________|_____| | | | v v v _______ _______ | | | | | vm_ |<-->| DDI | |_____| |_____| ________| | |__________ | | | | | | v v v _______ _______ _______ | | | | | | | TIM | | TIM | | TIM | |_____| |_____| |_____| | | | v v v ________ ____________ __________ | | | | | | | MRDS | | Relation | | Lister | |______| | Manager | | | |__________| |________| View Manager MTB-641 Appendix B. View Manager Terminology API See Application Programmer's Interface. Application Programmer's Interface The standard interface to the View Manager Facility (more specifically to vm_, the SQL parser and the DDI), designed for usage by applications programmers of languages such as PL/1, COBOL and Fortran. assertion A condition defined on a table or set of tables that provides for data integrity rule enforcement during delete, insert, and update operations. base table A table that exists as a real, physical entity, i.e. not a view. A base table can be either a native table or a non-native table. Canonical Query Language. The translated internal representation of an SQL statement. Other translators can produce CQL from inputs other than SQL. checkpoint A point within a transaction where all changes made to tables since the last checkpoint, or the beginning of the transaction if there is no last checkpoint, are applied. The SQL save statement is used to create a checkpoint. The SQL restore statement is used to rollback to a checkpoint. The SQL rollback work statement is used to rollback past checkpoints to the beginning of the transaction. column the set of like data elements that comprise that Nth element of each row of a table. commit The final point within a transaction where all changes made to tables are applied and made permanent, and the transaction is complete. CQL See Canonical Query Language. data dictionary MTB-641 View Manager The collection of system tables. (MTB-645) Data Dictionary Interface That portion of the View Manager Facility that specifically handles and manipulates the system tables. (MTB-645) DDI See Data Dictionary Interface. link An entry in a data dictionary that refers to an item in the table namespace of another data dictionary. (MTB-645) native table A table that was created by the View Manager Facility. non-native table A table created outside of the View Manager Facility, for example, a Lister database or a MRDS relation, that has been 'registered' for use with the View Manager Facility. parser A software program that accepts some sort of input and produces CQL as output. Often used to refer to the SQL Parser. permissions The allowed actions that an individual or group of people can perform on various objects. The objects include tables, views, links, tablespaces, and data dictionaries. The actions are the SQL statements that manipulate these objects, and permissions are expressed in terms of these statements. privileges See "permissions". request A View Master character string read by the subsystem utilities listener which results in the execution of a procedure to perform some pre-defined operation. ripple One or more actions that happen as a result of performing some relational operation. The deletion of a table would have the ripple affect of deleting all indexes associated with that table, all views which reference that table, all links which link to that table, and all synonyms and permissions defined on that table. rollback View Manager MTB-641 The final point within a transaction where all changes made to tables since the beginning of the transaction are backed out and the tables return to the same state as when the transaction began. row The collection of one or more column values that make up one record of a table. SQL See Structured Query Language. SQL Parser That portion of the View Manager Facility that accepts SQL statements as input and produces CQL as output. (MTB-644) statement An SQL character string which specifies that some relational operation be performed on behalf of a user. Structured Query Language. A collection of statements which permit data manipulation, data definition, and data control. (MTB-644) synonym An alternate name for a table or view. system provided keys A key provided by the system to uniquely identify a row in a table. This key is not user-visible. system table A table that contains specific data pertaining to the characteristics of one or more tablespaces and its contents (meta-data), that is used by the View Manager Facility through the Data Dictionary Interface (DDI). (MTB-645) table A set of rows defined as being made up of one or more columns, where each row in the table has the same number and type of columns. The term may be applied to either a base table or a view. Table Interface Module A standard interface that is called by vm_ to perform various relational operations on different table types. There will be, for example, a MRDS TIM, a Lister TIM, a TIM for native tables, etc. (MTB-642) table namespace MTB-641 View Manager The set of names of tables (native and non-native), views, synonyms and links in the data dictionary. All names must be unique within this set of names. tablespace A Multics storage system directory which contains tables created by the View Manager. Native tables must reside in a tablespace. TIM See Table Interface Module. transaction The basic unit of work with a well defined beginning and end. At the end of the transaction all relational operations which resulted in tables being changed are either made permanent or removed. trigger A method for specifying the automatic execution of SQL statements upon occurence of a specified action. view A virtual table generated from one or more tables by an SQL select statement. As a view is a specialized form of table, the term table may often refer to a view. View Manager Used to refer to the set of software programs that includes: vm_, View Master, the SQL parser, the Data Dictionary Interface, and the TIM for native tables. Could conceivably be used to include other TIMs supplied by Honeywell as standard offerings. View Master The end user facility to the View Manager Facility. (MTB-643) vm_ That portion of the View Manager Facility that accepts CQL as input and invokes TIMs to do relational tasks, performing relational tasks itself, where necessary, on the data returned by the TIMS. The vm_ subroutine entries will be called primarily by the View Master and by programs requiring a more sophisticated interface than is provided by the API. (MTB-642) unique index An index defined on a table that allows only unique values to be stored in the column or columns the index is composed of. View Manager MTB-641 Appendix C. Permissions on View Manager Objects Permissions Tables Views select X X insert X X delete X X update X X link X X null X X index X alter X Permissions Dictionaries access X administrator X create_synonym X create_tablespace X create_view X deregister_link X deregister_table X drop_synonym X drop_tablespace X drop_view X register_link X register_table X null X Permissions Tablespaces alter_tablespace X create_table X drop_table X null X Statement Permissions Permission Type alter table . . . . . . . . . alter table alter tablespace . . . . . . alter_tablespace tablespace comment . . . . . . . . . . . alter table commit work . . . . . . . . . create assertion . . . . . . alter (1) table create index . . . . . . . . index table create synonym . . . . . . . create_synonym dictionary create table . . . . . . . . create_table tablespace create tablespace . . . . . . create_tablespace dictionary create trigger . . . . . . . alter (2) table create view . . . . . . . . . create_view, dictionary, MTB-641 View Manager select table delete . . . . . . . . . . . delete table deregister link . . . . . . . deregister_link, dictionary, link table, view deregister table . . . . . . deregister_table dictionary drop assertion . . . . . . . alter (1) table drop index . . . . . . . . . index table drop synonym . . . . . . . . drop_synonym dictionary drop table . . . . . . . . . drop_table tablespace drop tablespace . . . . . . . drop_tablespace dictionary drop trigger . . . . . . . . alter table drop view . . . . . . . . . . drop_view dictionary grant . . . . . . . . . . . . (3) dictionary, tablespace, table, view insert . . . . . . . . . . . insert table, view lock table . . . . . . . . . (4) table register link . . . . . . . . register_link dictionary link table, view register table . . . . . . . register_table dictionary restore . . . . . . . . . . . revoke . . . . . . . . . . . (5) dictionary, tablespace, table, view rollback work . . . . . . . . save . . . . . . . . . . . . select . . . . . . . . . . . select table, view update . . . . . . . . . . . update column, table, view (1) Alter permission on the table or tables the assertion is being made on, and at least select on the other referenced tables. (2) Necessary access to the referenced tables or views to perform the requested operations. (3) Must have grant option for permission being granted. (4) Must have at least select permission on the table. (5) Can only revoke permissions that you have granted, or have administrator permission.