Citation
Disseminating functionality solutions to the functionality anomaly problem

Material Information

Title:
Disseminating functionality solutions to the functionality anomaly problem
Creator:
Kalathil, Ravi K
Publication Date:
Language:
English
Physical Description:
vii, 77 leaves : illustrations ; 29 cm

Subjects

Subjects / Keywords:
Database management -- Computer programs ( lcsh )
Database management -- Computer programs ( fast )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Bibliography:
Includes bibliographical references (leaf 77).
General Note:
Submitted in partial fulfillment of the requirements for the degree, Master of Science, Computer Science and Engineering.
Statement of Responsibility:
Ravi K. Kalathil.

Record Information

Source Institution:
University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
32480700 ( OCLC )
ocm32480700
Classification:
LD1190.E54 1994m .K35 ( lcc )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

DISSEMINATING FUNCTIONALITY SOLUTIONS TO THE FUNCTIONALITY ANOMALY PROBLEM by Ravi K. Kalathil B.Sc., St. Stephen's College, India, 1979 M.B.A., University of Delhi, India, 1981 A thesis submitted to the Faculty of the Graduate School of the University of Colorado at Denver in partial fulfillment of the requirement for the degree of Master of Science Department of Computer Science and Engineering 1994

PAGE 2

t:--) ,c \._ 1994 by Ravi K. Kalathil All rights reserved.

PAGE 3

This thesis for the Master of Computer Science degree by Ravi K. Kalathil has been approved for the Department of Computer Science and Engineering by Carol A. Keene Gita Alaghband __ ik,:i!.!..fi ___ t_Lf1 i Date

PAGE 4

Kalathil, Ravi K. (M.S., Computer Science) Disseminating Functionality: Solutions to the Functionality Anomaly Problem Thesis directed by Professor Carol A. Keene ABSTRACT Functionality is any unit of constructive activity, such as accessing, creating or changing information, performed on a database. With significant advancements in software development technologies, the ad-hoc creation of Functionality is proliferating. As one user creates Functionality, with no system for exchange of Functionality information, the relative knowledge of the remaining user community diminishes. This thesis provides a visual strategy to solve the problem of disseminating Functionality information. This abstract accurately represents the content of the candidate's thesis. I recommend its publication. Signed Carol A. Keene

PAGE 5

To my parents Vasumati Gopalakrishnan and Dr. Kalathil Gopalakrishnan

PAGE 6

Chapter 1. Chapter 2. Chapter 3. Chapter 4. Chapter 5. Chapter 6. Chapter 7. Bibliography Contents Introduction ............ ..... ....... ..... ....... ......................... .......... The Functionality Anomaly ............................................... Historic Approaches to Cataloging Functionality .............. Fundamentals of Hypertext .............................................. Visualization and Fisheye Views ...................................... Design of the Functionality System .................................. Architecture, Implementation and Future Developments .. VI Page 1 Page 4 Page 24 Page 31 Page 38 Page 41 Page 71 Page 77

PAGE 7

Acknowledgements I would like to express rny deeply felt gratitude to Prof. Carol Keene for her guidance and advice. I thank Prof. G. Alaghband, Prof. J. Rothman, Prof. J. Paul and Prof. W. Wolfe for participating in the thesis defense. I would also like to thank my wife Radha R. Kalathil for her steadfast support, assistance and encouragement throughout the Master's degree program. VII

PAGE 8

Chapter 1 INTRODUCTION Significant advancements in development technologies, such as relational databases with semantic/stored procedures and data and process modeling using CASE (Computer Aided Software Engineering), have facilitated the creation of software to access and change database information. Such software is collectively called Functionality. This thesis addresses the issue of disseminating, cataloging and accessing Functionality. The central problem is stated as an anomaly. Assume that user A is creating new Functionality against a database, thereby increasing net Functionality. The anomaly is that with no concurrent flow of information, regarding this Functionality, to the rest of the user community their relative knowledge about the database decreases as net Functionality increases. The problem is severe because historically the creation of Functionality has been stressed over cataloging it. In the relational database world, advancements such as electronic normalization of data, built-in data dictionaries, declarative referential integrity and extensive dictionary based comment structures have resulted in a substantial proliferation in the ad-hoc creation of Functionality. This brings a certain urgency to solving the problem. Additionally, if Functionality were cataloged and effectively disseminated, productivity would increase as users re-use established Functionality instead of re creating it. Page 1

PAGE 9

Historically, Functionality access has been solved using Menu structures and Natural Language Processing (NLP). Menus are limited by their simplicity and single dimensional mode of presentation. NLP is a still evolving technology that is very complex, is often unable to deal with industrial strength problems and cannot address access to Functionality that deals with multiple issues, including different output formats. NLP also lacks a visual paradigm that would provide stimuli to problem solving. An analysis of historic approaches suggests that the development of a visual presentation strategy, in conjunction with effective storage and access mechanisms, would help solve the Functionality anomaly. A study of the fundamentals of Hypertext provided the student with constructive suggestions in understanding the cognitive process and in the grouping, storing and presentation of information. "Generalized Fisheye Views", a seminal work by George Furnasr11, provided a valuable visualization strategy for knowledge presentation. Fisheye views map the cognitive process and provide a varying reference point based presentation of knowledge structures. Concepts from Hypertext and Fisheye Views are used to develop a visualization paradigm that helps solve the Functionality anomaly. A system is developed, within the relational database model, to support and implement the paradigm. The Functionality System presents Functionality Space as a collection of groups of Functionality. The view varies with the location of the user in this space and the Page 2

PAGE 10

mode of usage. A user is allowed to zone in on a desired Functionality, in accordance with multiple restrictive criteria, and then traverse the Functionality Space surrounding that Functionality. After locating a Functionality unit, a user can execute it. Functionality information dissemination is facilitated by a concept called Domains that allows a user access to another user's set of Functionality. Session Memory constructs allow a user to re-visit a Functionality Space traversal. Finally, the thesis presents the architecture within which a prototype of the Functionality System has been developed and discusses design, implementation and future considerations. Page 3

PAGE 11

Chapter 2 THE FUNCTIONALITY ANOMALY PROBLEM Outline This chapter begins by explaining the concept of Functionality in an information system and the Functionality anomaly problem. Next, the efficacy of the relational database model and normalization rules inherent to it, in creating an effective layout for data is established. Relational database concepts such as built-in data dictionary, declarative referential integrity and dictionary based comment and help structures establish properties of Navigability and Meaningfulness which in turn provide users access to the database schema. Next, the Oracle database system's dictionary model for maintaining this layout information is studied and a mechanism of translating this information into a graphical data map is suggested. The utility of this map in creating Functionality both from a data access and a transaction processing perspective is discussed. In conclusion, the fact that in an increasingly dominant relational database world, the creation of Functionality is ad-hoc and substantial is established. Addressing the Functionality anomaly problem is, therefore, considered to be of value. Objective A Data Base Management System (DBMS) is essentially defined by its data repository and the set of utilities and software used to manage the data. These utilities provide features such as concurrent access, transaction based processing, Page4

PAGE 12

task recovery and cleanup, system recovery, backup, roll back/roll forward, space management, and performance tuning, in addition to software programs that access and manipulate data. The issues addressed by this thesis are best reviewed in terms of the last two utility features: data accessibility and manipulation. Capabilities created to handle these two issues will, for the rest of the thesis, be referred to as the Functionality of the database. The essential idea does, however, extend to the other utilities mentioned before. The issue of Functionality is central to this effort and merits further illustration. Functionality is any significant, constructive action on a database. Writing a report to access database information and produce a printed output, in a specific format, is Functionality. If a user were to write a report that listed revenue generated by a group of products, for each quarter of the current year, he/she would have created Functionality. Functionality is, however, not limited to information access and reporting. A user or systems analyst/programmer creating a screen for on-line or batch transaction processing activity, such as adding a new employee to the payroll database, is also involved in the creation of Functionality. Originally, trained system professionals created, cataloged and optimized Functionality. Graphical User Interface (GUI) tools, CASE and fourth generation languages have substantially simplified the creation of Functionality and allowed user groups to create Functionality in an isolated and ad-hoc manner. The resulting proliferation of Functionality highlights a serious cataloging problem that is best expressed as an anomaly. Page 5

PAGE 13

The Anomaly The Total Functionality of the database is defined as the sum of all distinct Functionality currently existing for that database. User Functionality is defined as the sum of all distinct Functionality that currently exists for a user. Relative User Functionality is defined as the ratio: User Functionality Total Functionality and serves as a measure of dissemination of Functionality and knowledge of a database held by a user. Consider user A creating new Functionality on a given database, while the rest of the users of the database are dormant. The Total Functionality of the database increases with the new Functionality creation. From user A's perspective, there is a corresponding increase in his/her catalog of Functionality, until Functional Attrition (the loss of Functionality because of explicit removal or users forgetting the existence of Functionality over time) sets in. However, other users of the database experience the Functionality Anomaly: Assuming no exchange of information between user A and any other user 8, B's level of Relative User Functionality decreases while Total Functionality increases. As one user adds Functionality to a system, with no mechanism for Functionality information dissemination, other users are left with diminished knowledge about system capabilities. Efforts in the database arena can be categorized into two major classes: Class 1. Increasing Total Functionality. Class 2. Increasing Relative User Functionality. Page6

PAGE 14

Efforts belonging to Class 1 are language developments such as SQL(Structured Query Language) GUI facilitated efforts to access and change database information and embedded database extensions to third generation languages. Class 2 efforts are largely focused on and recognized as menu creation facilities. Industry and academic efforts have concentrated on Class 1 efforts. The increased capability to produce Functionality and the lack of a corresponding increase in the ability to disseminate Functionality information is termed the Functionality Access Gap. This thesis recognizes the widening of the Functionality Access Gap and proposes a solution to bridge this gap. The Proliferating Functionality Problem The relational database model and the normalization rules inherent to it promote a proliferation in ad-hoc Functionality creation. In relational databases, data is partitioned into distinct tables. If a relationship exists between two tables, these can be joined. Normalization rules ensure that data pertinent to a particular table is only maintained with that table, thereby ensuring simplicity and integrity in the data layout. In addition to top-down and bottom-up hierarchical relationships, the relational model also allows for peer, recursive and many-to-many relationships. The resultant simplicity and flexibility of the model provides a very powerful basis for understanding how data is laid out and related in a database. Consider a simple database system with two Entities: Employees and Departments. This system is modeled, using an Entity-Relationship (E-R) Page 7

PAGE 15

Diagram, in accordance with the Oracle Case Method121 convention. The schema for the database is then derived from the E-R Diagram. The syntax of the database schema conforms to the Oracle Relational Database Management System131 The example, considered below, also serves as a brief primer to relational database modeling and schema derivation. The concepts and terminology addressed in this example will be used in chapter 6, in developing the solution to the Functionality Anomaly problem. EMPLOYEE SSN Name Gender Date_of_Hife Pay_Rate consists of belong to managed by manage Figure 1. E-R Diagram The E-R Diagram relates the two entities as follows: DEPARMENT Code C1ty Name Address Each Department may consist of one or more than one Employee. Each word of the above relationship statement is, in accordance to the Oracle convention, directly derived from the diagram. 'Each Department' is directly derived from the leading Entity (Department in this case). 'May' is derived from the dotted line (----) nature of the relationship line connecting to Department. This is an optional relationship. 'Consists of' is derived from the label attached to the relationship line at the leading entity (Department) side. 'One or more than one' is Page 8

PAGE 16

derived from the forked nature of the relationship line at the secondary Entity (Employee) side. 'Employees' is derived from the secondary Entity. Toggling the same relationship and viewing it from Employee as the leading Entity yields: Each Employee must belong to one and only one Department. The relationship can, once again, be derived as enunciated above. There are two differences. 'Must' is derived from the observation that the connection of the relationship line to the leading Entity (Employee) is solid. This is a mandatory relationship. 'One and only one' is derived from non-forked nature of the relationship line at the secondary Entity (Department) side. The second relationship can be similarly expressed as: Each Employee may be managed by one and only one Employee, An Employee may manage one or more than one Employees. This relationship, however, does generate couple of interesting issues. Besides the recursive nature of the relationship (the leading and secondary Entities are the same), it should also be noted that the relationship is optional at both ends. This, however, may not reflect physical reality as we should expect -Each Employee must be managed by one and only one Employee. (It is reasonable to expect all employees to have a manager; the top Employee manages him/her self). Expressing the relationship as mandatory, however, leads to a chronological impasse. When the first employee is established, the instantiation requires a valid Page 9

PAGE 17

employee for manager but none as yet exists! Within each entity, its Attributes are stated. Normalization axioms141 translate the Entities to Tables and Attributes to Columns with relationships contributing to additional Columns and in some cases Tables. This process is usually performed electronically using CASE tools. Although it is beyond the scope of this work to establish this process, the schema generated for the Employee, Department data model is next considered. The Department Entity translates into the Departments Table as follows: CREATE TABLE departments (code varchar(6) not null ,city varchar (16) not null name varchar (20) not null ,address varchar (30) not null ,PRIMARY KEY (code,city) CONSTRAINT departments_pk ); The Employee entity translates into the Employees Table as follows: CREATE TABLE employees (ssn varchar (9) not null ,name varchar (30) not null ,gender varchar (1) not null ,date_of_hire date not null ,pay_rate number (5,2) not null ,dept_ code varchar(6) not null ,dept_city varchar (16) not null ,manager varchar (9) null ,PRIMARY KEY (ssn) CONSTRAINT employees_pk ,FOREIGN KEY (dept_code,dept_city) REFERENCES departments (code,city) CONSTRAINT employees_ departments_ fk 1 ,FOREIGN KEY (manager) REFERENCES employees (ssn) CONSTRAINT employees_ employees_fk 1 Page 10

PAGE 18

); The Attributes of the two Entities have translated into appropriate Columns with mandatory value conditions. It should also be noted that normalization rules duplicate the compound primary key (code, city) of Departments in the Table Employees as the Columns dept_ code and dept_ city with the appropriate foreign key constraint. Thus every employee acquires a valid department to which he/she belongs. Similarly, each employee optionally acquires a manager that references another valid employee. The relational model thus establishes a sound basis for conceptualizing data. However, it should also be evident that substantial data dictionaries can be intractable. The problems are Navigability and Meaningfulness. Navigability is the capability to know what Tables exist in a schema, the Attributes belonging to a Table and the relationships between Tables. Meaningfulness is knowing what is contained in a Table, the purpose, nature and content description about an Attribute and a commentary about a relationship. Historically, three developments in the relational model have addressed the problems of Navigability and Meaningfulness: Built -in built data dictionary. Declarative relational integrity. Dictionary based comment/help structures. Page 11

PAGE 19

Built-in Data Dictionary In a built-in data dictionary, all database objects accessible to a user are cataloged in a series of system Tables. Information about the data dictionary can be retrieved from these Tables using SQL. Database objects usually are Tables, Views (limited projections of Tables that span one or more Columns) and Indices. The Userobjects Table defines the database objects available to a user as follows: OBJECT _NAME OBJECT_ID OBJECT_ TYPE CREATED LAST _DOL_ TIME STATUS Name of Object Object Number View, Index or Table Timestamp Timestamp of last activity Valid or Invalid The Columns of a Table or view can be obtained from User_tab_columns: TABLE_NAME COLUMN_NAME DATA_ TYPE DATA_LENGTH DA TA_PRECISION DATA_ SCALE NULLABLE COLUMN_ID DEFAULT _LENGTH DATA_DEFAULT NUM_DISTINCT LOW_ VALUE HIGH_ VALUE Name Name Datatype Length Precision for numeric data Scale for numeric data Can field be nulled Position of column in Table Length of default value for column Length of default column value Number of distinct values for column Lowest value in column Highest value in column The Tables and Views can be derived by: SELECT object_name, object_ type FROM user_objects ORDER BY object_ name; The Columns for a Table or View are derived by: Page 12

PAGE 20

SELECT column_name FROM user_tab_columns where Table_name ='X' ORDER BY column_id; Declarative Relational Integrity The progression of relational technology began with the development of data layouts that conformed to the relational standard. Following efforts concentrated on enhancing parsing and optimizing techniques to improve performance. The next progression phase emphasized data integrity. Enforcing mandatory (non null) value constraints on columns and/or a range of values or domains for columns (a date type field is a generic example) promotes data integrity. Additionally, the normalized relationship based nature of the relational model significantly contributes to integrity. Normalization, in its substantial sophistication and complexity, very clearly and decisively ensures that data is not placed redundantly in the same or multiple Tables. The integrity advantage of this highly evolved technique is evident, in the sense that data is placed in a single site with no chance of data structures carrying conflicting, redundant values. The exception to this rule is the primary/candidate key of a base Table. These Attributes are duplicated, as foreign keys, in the Table that is on the many side of an Entity relationship. Referential integrity requires that the foreign key values be checked, for validity against the primary key values. In the Employee-Department example, referential integrity ensures that the dept_ code in Employees refers to a valid department. Initial approaches, for example Sybase System Version 4, used pre-insert and pre-update triggers that enforced referential integrity. Triggers are procedures specified to the database engine that fire on a certain event happening. A pre-insert or pre-update trigger is a Page 13

PAGE 21

procedure that is associated with a Table and fires prior to committing an insert or update action. These triggers can be used to enforce the uniqueness of primary keys or the validity of a foreign key. For example, while creating or updating an Employees record, triggers could ensure that the ssn field is unique and the dept_ code field references a valid code in the Departments Table. Such a trigger would read as: ON INSERT OR UPDATE ON EMPLOYEES SELECT CODE FROM departments WHERE departments.code=CURRENT.dept_code; ON ERROR RETURN (') ROLLBACK; Although CASE tools sensed the E-R model and often electronically generated the above code, the data schemas generated by this approach were copious and cumbersome. It was left to the programmer or CASE tool to generate the integrity trigger thereby increasing the risk of error or sub-optimal performance. To overcome these problems, later progressions (Oracle Version 7) built integrity constraints into the Table definitions in accordance with deterministic syntax conventions. This approach is observed in the Employee-Department example, in the Oracle system data definition syntax, where foreign key and primary key constraints are specifically stated. This restricted syntax should be contrasted to the trigger based approach. The declarative nature of the syntax, as demonstrated in the Oracle schema, allows the database engine to codify these constraints in data dictionary Tables. Just as the database engine validates a SQL command for correct Table/Column names Page 14

PAGE 22

and types, it is left to the engine to scan the data dictionary for relationships and enforce these. This approach results in a briefer and more clearly stated database schema and also ensures optimality of code generated to impose referential integrity. Codifying referential integrity rules into the data dictionary surfaced an initially unnoticed feature. The dictionary Tables can be accessed through standard SQL to procure three basic information components to the referential road map: Primary Keys of a Table. Tables to which a particular Table has referential or foreign key links. Columns that are linked from one Table to another. Once this is achieved, a graphical system can be developed that comprehensively outlines the Tables, Columns and relationships of a database and the goal of Navigability is attained. Next, the methodology used by Oracle to formalize referential information in its data dictionary Tables shall be delineated. Referential (and other constraints) are stated in two data dictionary Tables: User_ Constraints and User_ Cons_ Columns. The User_ Constraints Table specifies all the constraints pertinent to a Table. The User_ Cons_ Columns states Columns of a Table that participate in these constraints. USER_ CONSTRAINTS: OWNER CONSTRAINT_NAME CONSTRAINT_ TYPE TABLE_NAME Owner of constraint definition Constraint Name Type of constraint Name of Table with which constraint is associated Page 15

PAGE 23

SEARCH_ CONDITION R_OWNER R_ CONSTRAINT _NAME DELETE_ RULE STATUS USER_ CONS_ COLUMNS: OWNER CONSTRAINT _NAME TABLE_NAME COLUMN_NAME POSITION Text of any search condition involved Owner of Table used in a referential constraint Name of primary key or unique constraint in referenced Table Toggle for cascade deletes Constraint is Enabled or Disabled Owner of constraint defintion Constraint Name Name of Table with which constraint is associated Name of column with which constraint is associated Position of column in constraint definition The SQL for procuring the primary key for a Table is: SELECT a.table_name TABLE_NAME, b.column_name "PRIMARY KEY" FROM user_cons_columns b, user_constraints a WHERE a.constraint_type = 'P' AND b.constraint_name = a.constraint_name ORDER BY a.table_name,b.position; This SQL essentially identifies a Table constraint of type primary key (a.constraint_type = 'P') and joins that constraint with Column constraints. Ordering the Column constraints by position provides the primary key in the right sequence (if the key is of compound (multiple columns) nature). This SQL yields the following output for the Employee-Department model: TABLE NAME Departments Departments Employees PRIMARY KEY Code City Ssn The SQL for procuring the Tables to which particular Table has referential links is: Page 16

PAGE 24

SELECT DISTINCT a.table_name "FROM TABLE", b.table_name "TO TABLE" from user_ constraints b, user_constraints a WHERE a.table_name = &Table_name AND a.constraint_type= 'R' AND b.constraint_name = a.r_constraint_name; The construct "&table_name" prompts the user/program interface for a specific Table for which referential integrity is being traced. The SQL self joins the user_ constraints Table, lining up relational constraints (constraint_type = 'R') with primary or unique constraints at the other end of the relationship. For the Employees Table this SQL yields: FROM TABLE Employees Employees TO TABLE Departments Employees The first tuple is for the foreign key relationship between dept_ code and dept_ city of Employees to code and city of Departments. The second tuple is for the recursive relationship betwen manager of Employees and ssn of Employees. The SQL that lines up Columns of a Table to another Tableto which it has referential integrity is as follows: SELECT a.table_name "FROM TABLE", c.table_name "TO TABLE", b.column_name "FROM COLUMN", c.column_name "TO COLUMN" FROM user_ constraints a, user_cons_columns b, user_cons_columns c WHERE a.constraint_type= 'R' AND a.table_name = &Table_name AND b.constraint_name = a.constraint_name AND c.constraint_name = b.r_constraint_name AND c.position = b.position ORDER BY a.table_name, c.table_name, a.constraint_name, c.position; Page 17

PAGE 25

This SQL retrieves all relational constraints of a specific Table from User_-constraints. Next, it joins a relational constraint to User_cons_columns retrieving all columns participating in the constraint. Next, it self joins User_cons_columns matching a column in a relational constraint with its complementary column in the Table at the other end of the relationship (c.constraint_name=b.r_constraint_name). Matching the positions (c.position = b.position) lines up the relating columns. Output for the Employee Table would be: FROM TABLE Employees Employees Employees TO TABLE Departments Departments Employees FROM COLUMN Dept_ code Dept_ city Manager TO COLUMN Code City Ssn In summary, standard SQL yields the Tables and Views accessible to a user, the Columns belonging to a Table, the Tables related to a particular Table and the alignment of Columns in the relationship. Thus a comprehensive map of a database schema can be obtained thereby establishing Navigability. Meaningfulness or a commentary on the content structure of a schema can be similarly derived from the data dictionary. Once again the Oracle DBMS serves as the frame of reference. Comments in Oracle are cataloged in the following Tables: USER_ TAB_COMMENTS: TABLE_NAME TABLE_ TYPE COMMENTS USER_ COL_ COMMENTS: TABLE_NAME COLUMN_NAME Name of object Table or View Comment on Table or view Object Name Column name Page 18

PAGE 26

COMMENTS Comment on the column in the Table Comments on a Table or View are obtained from: SELECT comments FROM user_tab_comments WHERE Table_name= ; Comments on a Column can be derived from: SELECT comments from user_col_comments where Table_name=
AND column_name= ; As of October, 1994 although the Oracle DBMS requires that each constraint be clearly typed (primary key, unique, foreign key, not nullable) the constraints do not have a comment structure attached to them. Adding a comment attribute to the User_constraints easily achieves this. Once again, from a point of view of cataloging and accessing database structure, the issues of Navigability and Meaningfulness have been established. Next, the contributions of Navigability and Meaningfulness to proliferating Functionality are studied. In the case of information access, if the Tables, Columns and relationships of a database can be easily acquired, explained and pictorially depicted, Columns can be selected from a Table and joined with one or more related Tables to create access routines of significant variety, complexity and significance. As an example we shall explain the look and feel of the Oracle Data Browser product. Access to Employee, Department tables are shown in the following sequence of figures, begining with the "Include Datasources" screen. Page 19

PAGE 27

Figure 2. Displaying Data Sources Selecting the Departments Table presents all its attributes. [lie [dh D FJelds Query Layout Window t:telp : .. : ::: CODE ...................... A. cnv A ..... E A ADDRESS A Figure 3. Displaying Table Attributes Page 20

PAGE 28

Tables related to Departments can be procured using the 'Include Related' function. Choose Datacourcec l'!liWWJM\.ttm:J l;nnwB =:rrrr=l ..,,.... ...... ,. ......-.. Figure 4. Displaying Related Tables Selecting Employees shows the relationship between the Employee and Department tables. (Iota l'(elds !;iuery Loyeut Window tfelp .. .::: ... : _:t:. : .-.-: .. : .. ... ,. : :;: : .. .A .....,., !A ,. .... ..................... A .. AboFII'ss ..... : .. <:, .. ..... ................. A. .. ,, ..... DAr.E ........ 1111. "\:y: .. Figure 5. Displaying Relationships Page 21

PAGE 29

Selecting the Employee's social security number, Employee's name and the Department's name automatically joins the two Tables and provides the following results (note the column headers have been re-titled). file fdlt D.ta Fields Layout ltllndaw Help SSM IIAWE I DEPARTMENT I I !; i .... : .. : ..... ::::.:.: ... .... .. :::::: .. ..... ::::: ................. ............................................... IIi! f-'-'-r-!L r-!! r-!!r-!!-,_..!L ....... r-1!r-!!......................... :ill .:: 1:.: I Figure 6. Displaying Results Thus all relevant Tables and the relationships between Tables can easily be made visible to a user. Information can be accessed by selecting Columns from multiple Tables. Additionally, a user can access comments on each Table and its attributes thereby completely establishing Navigability and Meaningfulness. It should be remembered that the encapsulation of the data structures and relationships in the data dictionary are the basis for this rich graphical display. Page 22

PAGE 30

From a transaction processing point of view, Navigability and Meaningfulness facilitate the process of building a data entry form that includes the right Tables and relevant Columns. Navigability also allows easy building of look up lists that procure base key values for foreign key elements in a Table. This is a particularly important aid to data entry and allows data validation on a prompt by prompt basis (as opposed to the whole form). An example using the Powerbuilder product shall be considered to illustrate these concepts. The following example allows the creation of an employee record. The foreign key attributes of manager, dept_ code and dept_ city are managed through a drop down list box that procures valid values from the base Tables. These values are limited by entries in the prompt (e.g. a 1% would only return department codes that begin with a 1 ). In some form development tools, the creation of these list boxes and subsequent validation of entered values is automatically done. -_ .. .. :. .. . . Untitll!d . . ;-: .:; : .. Figure 7. Creating an On-line screen In conclusion, relational database technologies, fourth generation languages and GUI tools have significantly contributed to the creation and proliferation of Functionality. Solving the Functionality Anomaly problem is, therefore, of value. Page 23

PAGE 31

Chapter 3 HISTORIC APPROACHES TO CATALOGING FUNCTIONALITY Outline This chapter review two historic approaches to accessing information in a system: Menus and Natural Language Processing. The relative advantages and disadvantages of each approach are documented. The student concludes that a visual paradigm is essential for solving the issue of accessing Functionality, and this leads to a study of Hypertext. Historic Trends Two major approaches to disseminating information about systems are Menus and Natural Language Processing. A brief evaluation of both these approaches follows. Menu Systems Menus have provided a simple, popular and persistent mechanism for categorizing user developed Functionality. Menus also provide a stepwise guide to a particular Functionality. The 'knowledge representation' is fundamentally hierarchical, navigating from generalization levels down towards specialization hierarchies. The major advantage of this approach is the inherent hierarchical segmentation of Functionality. As many knowledge representations are hierarchical in nature, proposed solutions will borrow from the menu approach. Page 24

PAGE 32

Menu styles essentially follow two approaches: the hierarchical and pull down structures. Figure 8. Hierarchical Menus The hierarchical approach is strictly top-down. Exploding any one menu item could obscure peer items. The visualization does not depict any lower level explosions. Item descriptions are also limited to one line (couple of words). Figure 9. Pull Down Menus Page 25

PAGE 33

With pull down menus top level peer items are not obscured. However, beyond the top level, the hierarchical limitations persist. This approach does add a horizontal dimension and movement to the single dimensional top-down approach. The menu approach has some substantial benefits: Visual stimuli to suggest the existence of cataloged Functionality. Effective grouping of Functionality. Stepwise approach of moving from one area of focus to another. Inherent upward short term memory. (That is, the user can move back up to a previous level. Major disadvantages of menus are: Cumbersome Navigation Users may require many steps to get to a desired function. This is often addressed by a "go to" capability. Noise Menus can get large and complex. This is true for substantial systems. This is partly addressed by pull down menus. Lack of a wild card search feature Users frequently need to find items to a particular subject or keyword. Despite the limitations of the menu structure it has persisted, with good reason, as a successful metaphor for presenting Functionality. The value of grouping, stepwise focus and visual stimuli should be part of any different approach. Page 26

PAGE 34

Natural Language Processing Natural Language Processing (NLP) discards the visual paradigm and uses language as the access tool to Functionality. To understand how this works consider the Employee, Departments example of chapter 2. To answer the question, "What department does John Smith belong to?", a conceptual graph is derived. A conceptual graph is a finite, connected, bipartite graph151 The graph nodes are either concepts or conceptual relations. Nouns and verbs qualify as concepts. A conceptual relation simply relates two concepts. Since the graph is bipartite, concepts can only have arcs to concept relations. The conceptual graph for the question is shown in Figure 10. Belongs to Agent Person Object Entity Figure 10. Conceptual Graph Page 27

PAGE 35

Next, a type hierarchy is used to translate this graph: Person --> Belonging to --> Entity == Entity is Department; Person --> Belonging to --> Entity == Person is Employee; Belongs to Agent Employee Object Department Figure 11. Enhanced Conceptual Graph Knowing the two interacting tables, NLP can arrive at the following conclusions: Select clause: Select departments. name Predicate Clause: departments.code = employees.dept_code employees.name = 'John Smith' This yields the SQL: Select departments. name from departments, employees where departments.code = employees.dept_code and employees.name = 'John Smith'; Page 28

PAGE 36

The complexity of achieving the above is evident. The fact that the same question can be phrased in different manners compounds the issue. In more complex data dictionaries there could be substantial non-determinism at every phase of the translation process. Functionality also includes reports and on line transactions that simultaneously address multiple, complex issues. It may not be possible to phrase these into simple questions. For example, how does a user ask for a report that lists, by sales territory, customers who have bought a certain group of products but not another in the first six months of 1994? NLP has used concepts such as frames and scripts to address the issue of complexity161 These methods, however, are still in a nascent phase of development and continue to grapple with the inherent non-determinism in language. The NLP approach also does not address various details such as the format of presentation of data (Type of headers, totals, cross-tab format, etc.). Consequently, a question such as "Who hired John Doe?" is well within the NLP realm. However, formatting a report that does the following is very difficult: List all sales for a particular division of a company to all non domestic customers. In the second quarter of 1994 Presented in tabular form with customers along the y-axis and products along the x-axis With customers grouped by country With total sales per country per product. Page 29

PAGE 37

Finally, the lack of a visual paradigm in NLP limits a user from receiving visual stimuli that would guide and direct the process of accessing established Functionality and invoking it. Page 30

PAGE 38

Chapter 4 FUNDAMENTALS OF HYPERTEXT Outline Hypertext and the hypermedia that supports it is an attempt to present information in a more effective manner. Most standard forms of knowledge presentation (for example text books) sequence learning from one contiguous chunk to the next. Learning, however, is considered to be fundamentally non-serial, with the learner having to transition from one concept to the next based on individual aptitude, preference and prior knowledge[7). Hypertext provides a system that accommodates individualized, non-serial learning. Hypermedia is the combination of different message carrying media used in a presentation. This chapter briefly describes the basic features and issues addressed by hypertext. The methodologies and characteristics for grouping information, developing an idea into an information block and/or topic and traversing from one information quantum to the next are formally laid out. History The concept of hypertext, as a presentation that facilitated non-serial thinking was first stated by Vannevar Bush in 1945181. The first implementation of hypertext was by Douglas Engelbart at the Stanford Research Institute from 1962 through 1978. These efforts began with the coining of the term Hypertext191 and the creation of the Augment System1101 Similar efforts in hypertext were in process at Brown University Page 31

PAGE 39

under Andries Van Dam[7]. The common theme was the development of a single repository of knowledge that could then be traversed in a non-serial manner. The emphasis was indexing techniques to quickly retrieve knowledge blocks. Progress however remained theoretical and of a very large scope. By 1976 advancements in multi-media and indexing technologies allowed efforts to be focused on specific problem solving. At Carnegie Mellon, a rapid response network named Zag lead to the first commercial system implementation of hypertext as an organization, regulation, planning and evaluation application for the USS Carl Vinson171. Contemporary efforts proceeded at the Architecture Machine Group at MIT under Nicholas Negroponte and Richard Bolt[7]. The emphasis was on the development of multi-media environments and knowledge user interfaces leading to refining the concept of information space. These pioneering efforts culminated in the development of sophisticated commercial hypertext systems. The first of these was KMS (Knowledge Management System) developed on SUN workstations by the Zag group1111. This was followed by Peter Brown's work at the University of Kent and the Guide system developed by the Office Workstation Limited at Edinburugh, ,. Scotland1121. The look and feel of these systems was scroll like with non-serial knowledge linking. Later, systems such as Hypercard developed at Apple by Bill Atkinson[7] envisaged the user interface as a stack of linked index cards. Page 32

PAGE 40

Components of Hypertext The basic components of hypertext are: Nodes: A quantum of information. Links: Connection between nodes that allows for bi-directional movement. Figure 12. Construction of Nodes and Links Buttons: A specifically marked location in hypertext from which travel along a link to another node is possible Features of Hypertext The Fundamental properties of hypertext are: Rapid browsing -The capability to bi-directionally travel from one node to another. The route taken is dependent on the learning characteristic in play. Bi-directionality implies that a historical trail of the link route needs to be maintained. Non-linear associative mapping structure -The above method of browsing allows multiple ways to associate and group information unlike a top-down linear approach. Besides this inter-node travel based association, Page 33

PAGE 41

information association is also facilitated by methodologies which "chunk" or group data into a node. Dissemination control -Specifies who has access to data and who can alter it. Personalized Text-Allows copies of information to be gathered and altered/individualized and annotated (similar to the concepts of sticky notes that can be placed on a document). Usage Hypertext features and hypertext media can be used in multiple usage modes such as author, user, editing, administration. Security is uniformly considered in the domain of the administrative mode. However, the fundamental idea of clustering information into nodes or quantums of information could be considered overlapping responsibilities of the author, edit or administrative modes. The administrative mode may permit a particular user to group information only in certain types of characteristics or information categories. In the edit mode a user would typically set up additional grouping criteria for the same information, customize and annotate text. Metacognition Links fundamentally differentiate hypertext from typical serial knowledge representations. Linking strategies are based on an understanding of metacognition or information about the cognitive process. Understanding the cognitive process Page 34

PAGE 42

allows for positively influencing learning outcomes. This is achieved by monitoring cognitive behaviors and employing diverse organizing methodologies. Studies by Weinstien and Mayer (1986)[7J demonstrated a functional correlation between knowledge presentation techniques and learning outcomes. Requirements for effective hypertext based knowledge presentations are: Knowledge base about the cognitive process and learning outcomes. Management of the learning process and the process of organizing information into presentation blocks. Hypertext knowledge base. Human Factors and User Interface design. Graphics Skills. Hypertext Development Issues Development Methodology The metacognitive process, from the perspective of hypertext, is influenced by two significant developmental issues: Constructing a Node or block of information. Establishing and traversing links between nodes. A development methodology is required to address both these issues and create an effective hypertext presentation. One such methodology is Robert Horn's Information Mapping[7). This methodology sequences the creation effort and Page 35

PAGE 43

systematically applies a series of rules and quality criteria to guide each stage of the development. The components of Information Mapping are: Rhetoric -Rules for developing a document for a particular purpose. Information Types -Categorizes the knowledge base into distinct types of nodes which provide the basic building blocks. Information Blocks -Nodes that can be categorized into Information Types. Grouping/Chunking Analyses -Principles that need to be used for constructing an Information Block. Content Topics -Relating and grouping Information Blocks into a topic of discussion/presentation. Sequencing-Arranging Content Topics into one or many traversal paths (in knowledge space). Node Construction An information block can be constructed based on a process of intuitive chunking. Intuitive chunking could occur when the size of a block is limited by the size of what can contiguously be seen on the screen. By contrast, Information Mapping recommends applying the following four constraining principles to provide "precision modularity" to information blocking: Comprehension Principle -Limit size of block to empirically established limits of comprehension. This could be a function of subject matter. Relevancy Principle -Limit a block to relevant block issues. Page 36

PAGE 44

Labeling Principle -Categorize an information block as belonging to one of the information types that have been pre-defined for the document. Consistency Principle-Develop and constrain like type blocks similarly. This establishes a "feel" and profile for each information type. Links facilitate non-serial learning. Although serial learning is an essential component of the learning process it is limited as follows: Unknown termination -Readers might stop too soon leaving a concept un clarified. Serial sequencing --This is the only tool available for indicating importance of a concept. Inhibits reader from seeking non-contiguous information. Implicit memory hierarchy Readers tend to only remember top level structures. Holistic learning is substantially more multi-dimensional. It allows: Explicit transitioning between concepts. Learning that switches on contrast and similarity cues. Creation of extended metaphors. Multi-dimensionality is a vital characteristic of holistic learning. Consequently, links need to be variedallowing different patterns of knowledge space traversal. This brief study of hypertext provides constructive suggestions in understanding the cognitive process and in the grouping, storing and presentaion of information. Page 37

PAGE 45

Chapter 5 VISUALIZATION AND FISH EYE VIEWS Outline This chapter re-states the hyperspace placed emphasis on visual stimuli. Next, a concept of fisheye views is studied as an effective visualization strategy. Visual Strategies The importance of a visual, non-serial paradigm for information access is critical to hypertext. The visual stimulus provided by links and buttons is apparent. In conjunction with the visual constructs suggested by hypertext, ideas proposed by George Furnas in "Generalized Fisheye Views"111 provide an interesting basis for an effective visual presentation of information. The problem explored by Furnas is that of representing potentially huge structures through windows sometimes as small as 24x80. In a typical presentation of information, the small window linearly scrolls through contiguous pieces of information. A user can easily be lost in some incomprehensible place with little idea about navigating to more conducive tracts of information. Furnas' central view is that this happens because scrolling views have little information about the global structure and where the current view fits. The suggested solution is a viewing strategy based on an analogy to a very wide angle or "fish eye" lens. Such a paradigm would show places nearby in great detail and remote regions in Page 38

PAGE 46

successively less detail. This would leave the user with a reference point. A typical analogy is a roadmap that would show Manhattan in street by street detail, counties for the surrounding boroughs and the tri-state area and the rest of the US as a terrain west of the Rockies. This picture would change as the user ventures to different territories. Thus the fundamental motivation of the fisheye strategy is to provide balance to local detail and global context. From a cognitive psychologist's viewpoint, fisheye views have additional value as the visualization paradigm is similar to the way the brain represents large structures. In many contexts, humans represent their own "neighborhood" in greater detail and only major landmarks further away. This idea goes beyond spatial connotations. For example, while thinking of US Presidents most references are to a detailed chronology for recent Presidents and pre-eminent aspects for past Presidents. Formalizing these concepts, Furnas suggests two definitions. Degree of Interest (DOl) is a function expressing a user's interest in seeing a structure, given the current task. The other concept is A Priori Importance (API) which represents the global importance of a structure. The functional dependency is expressed as: DOIIisheve (xly) = API(x) D(x,y) That is the Degree of Interest of the point x given that the user is at y is the A Priori weight of x minus the Distance of x from y. In visual strategies, structures with larger DOl functional values are represented more centrally and with greater emphasis. Page 39

PAGE 47

Furnas' paper then applies these functions to various structural representations of knowledge structures. To demonstrate the efficacy of this strategy, Furnas provided case subjects with a very unfamiliar structure (the botanical taxonomy of the class of Dicotyledons). The subjects were provided a navigation related task in terms of needing to identify which class came first. Two flat and two fish eye views were developed for the structure. The following table represents the findings: Information given to subjects Accuracy of answer 2 Flat views 52% 2 Fisheye Views 75% 1 Flat, 1 Fisheye View 64% Adapted from "Generalized Fisheye Views" 111 Figure 13. Effectiveness of Fisheye Views Generalized Fisheye views provide a valuable visualization strategy that maps the cognitive process and provides a varying reference point based presentation of knowledge structures. Page 40

PAGE 48

Chapter 6 DESIGN OF THE FUNCTIONALITY SYSTEM Outline This chapter addresses the design of the Functionality System that is used to solve the Functionality Anomaly problem. The chapter begins w;th a synopsis of key design issues of the system. Studies of Menus, Natural Language Processing and Hypertext influence the design of the Functionality System. This is followed by a detailed profile of the components and features of the system. This high level view of the system leads to the data model. The data model lays out, in entity relationship format, the data structures and relationships required to support the objectives of the Functionality System. The data model leads to an enumeration of the rules governing the system. A study of these rules should facilitate an understanding of the overall design of the system and help the reader's comprehension of the normalized database schema that follows. The schema is a formal definition of the data structures and is built by applying normalization rules to the data model using a formal CASE (Oracle) methodology. The schema is interspersed with comments about how particular tables contribute toward achieving objectives of the Functionality system. The chapter ends with a discussion of panels that provide a look and feel about the Functionality System and its user interface. Page 41

PAGE 49

Key Design Issues Limit and define the scope of the effort. Successful implementations of hypertext followed solutions that addressed very specific contexts and problems. The Functionality System is specifically concerned with cataloging existing useful activity (Functionality) that operates on a database. Differentiate the Functionality System and the tools used to design the system from the Functionality that the system catalogs. The Functionality System is designed using Powerbuilder, a GUI development tool, connected to a relational database system developed in Oracle. However, the Functionality that is being cataloged, need not belong to and is not restricted to these technologies. A Functionality, once it is located, can be invoked using technologies relevant to that Functionality. Use a visual strategy to establish an effective non-serial learning paradigm. The strategy provides information gathering and learning stimuli to the user. The user is allowed to zone in, according to various selection criteria, on a Functionality and the space around it, procure information and invoke desired Functionality. Employ grouping technologies to collate and organize Functionality into groups. Categorizing information is critical to the learning process. Effective grouping is cognizant of restrictive principles such as comprehension, relevancy, labeling and consistency. Develop effective and efficient storage and access strategies for cataloging Functionality information. The Functionality System uses CASE tools to model Page 42

PAGE 50

data storage in a relational database. The Oracle database system provides storage and access mechanisms. Develop a strategy for users to share and disseminate information about the creation and modification of Functionality. The Functionality System allows a user access to another user's catalog. Additionally, a user X can create a Functionality catalog A that 'points to' another user's catalog B. Changes in B are thus automatically mirrored in A. The visual paradigm also informs user X of changes in catalog B. Preserve learning patterns or information gathering sessions. The Functionality System allows a user to re-visit and step through a previous session. Customize the view of knowledge (or Functionality) space and vary it by user, mode of usage and position of user in the space. Components and Features of the Functionality System Figure 14 provides a typical representation of cataloged Functionality by the Functionality System. This schematic will be used as a reference point for delineating the components and features of the system. Page 43

PAGE 51

Functionality Space 1 ROI FS1 Func1ionality Space 11 ROI Mise Figure 14. Functionality Space-1 1. A Functionality is a unit of constructive activity against a database. Functionality is either a transaction that inserts, deletes or modifies a set of rows in the database or an activity that derives information from the database. Each Functionality has four attributes: a label that titles it, a description that documents the Functionality, a pointer to an executable file and an executable type stating the technology required to execute the associated binary file. F1 and F1 0 are examples of Functionality. Functionality is also refered to as elementary Functionality. Page 44

PAGE 52

2. A Functionality Space (Space) is a region of collected Functionality that can be documented and cataloged. Figure 14 is a representation of the Functionality Space FS-1. 3. A Region of Interest is the first (or highest) sub division of a Functionality space. Regions of Interest compartmentalize Functionality Space into various areas of related Functionality. ROI-1 and ROI-2 are examples. 4. A Functionality Group is a labeled grouping of other Functionality Groups or Functionality. A Region of Interest also qualifies as a Functionality. FG-1 and FG-2 are examples. 5. Functionality Entity (Entity) is a collective term for Functionality Spaces, Regions of Interest, Functionality Groups and elementary Functionality. 6. Location is the Functionality Entity that is the current selected area of focus or interest for a user. A Group Location is a Location that is a Functionality Space, Region of Interest or Functionality Group. 7. A Usercode is a login name that is granted access to the underlying database system. 8. Registration is a process by which a Usercode initializes and owns a Functionality Space. An initialized Functionality Space immediately acquires a default Region of Interest labeled Miscellaneous (ROI-Misc in Figure 14). This is the 'catchall' Region to which all Functionality Groups and Functionality that are not attached to another specific Region of Interest are assigned. It is this requirement for a catchall Region that mandates that a Region be specifically different from another Functionality Group. Any newly created Functionality Page 45

PAGE 53

Group automatically attaches itself to the Miscellaneous Region. Newly created Regions can, however, independently exist. If a Functionality Group or Functionality is detached from its parent it gets assigned to the Miscellaneous Region (unless it is completely deleted). This methodology prevents dangling Functionality Entities from increasing the clutter and width span of any Space representation. A Usercode can acquire more than one Functionality Space. This was allowed to reduce the cardinality of the space covered at any time thereby reducing response times and increasing performance. Registration also causes a Functionality Space to be entered as a Functionality Entity. This is done because a Functionality space shares all properties of Functionality Entities and also to simplify the top down derivation of Functionality Entities that belong to a Functionality Space 9. A Registered User (User) is a Usercode with an assigned valid Functional Space. Registered User is often addressed by the shorter User terminology. 10. An Owner of a Functionality Space is the Registered User that initialized and acquired the space. A Functionality Space is owned by one and only one Usercode. 11. Modification Rights can be conferred on another Usercode by an Owner of a Functionality Space. This allows the said Usercode to alter the Functionality Space. All Usercodes are allowed access (or visibility) to all Functionality Spaces. 12. A Registered User can claim Domain over any Functionality Entity that he/she owns or over any Entity that belongs to another User's Functionality Space. This Page 46

PAGE 54

causes the Functionality Entity to be checked into the Registered User's Group Location. The Domained Functional Entity is maintained by its original Owner (or Usercodes that have been assigned Modification Rights). Changes to the Entity, however, are visible to all Domain claimants. Entities that are claimed as domains are termed Domained Entities. An Entity that points to a Domained Entity is termed a Domainee Entity. 13. Launching a Functionality Entity causes the attached code to be performed for elementary Entities. If the Entity is a Functionality Group, launching provides a pictorial representation of the grouping structure of the Entity. The Functionality Group is referred to as the Anchor and procuring and displaying the group structure is termed Explosion. 14. Usermodes are various manifestations of a Usercode. 15. Context is the view of a Functionality Group as seen by a Usermode from a Location. Context properties include: The tabular or radial Visual Paradigm used to view a Functionality Entity. The radial Distance or left to right ordering of a Functionality Entity. The Levels to which a Group Location is expressed. The Zoom Radius or area over which a Functionality Entity is presented. As any Functionality Entity can repeat itself anywhere in a visual representation, Context requires being able to physically locate an Entity on a visual template. This allows the view to change when Context varies to a particular location of an Entity and allows for a particular Location to acquire certain visual properties, dependent on the current Context. This physical location of an Entity cannot be Page 47

PAGE 55

attained through a grid pattern based fixing of x,y co-ordinates as these change with Context and on zooming. Consequently physical location needs to be algorithmically derived. This is done by Exploding the Anchor into its groups in a breadth first, level by level basis. At each level, an Entity receives a level number and a sequential number. The combination of Anchor, level number and sequence number ensures a unique location. Context can be set by this location and Context properties can be conferred on other such locations. Since positional location is algorithmically derived it need not be stored. To ensure a consistent derivation of position, an incremental sequence number is provided to each grouping relationship. Entities then explode on a level by level basis in a consistent fashion. It should be noted that the 'value based' orientation of relational technology could return tuples in a non-deterministic manner. Ordering returned tuples by the incremental sequence number prevents this inconsistency. These concepts will be addressed in more detail as the data model is discussed. Next, the data model that supports the above constructs will be developed. Page 48

PAGE 56

FUNCTIONALITY_HIERARCHY hava a parent In be 1 he parent of c I aim domal n IO \I/ have a ch II d In \I/ be valid tor FUNCTIONALITY_ENTITY E be the domain -. of CONTEXT \II be anchored In \II belong \II to SESSION_ACTIVITY balong to be conllltutad o o I \ be de I i ned I or 1 have have [usEFMJOE belong IO be anchored In be of r be aaeoclated: have a context In ext cone let of I wl th FUNCTIONALITY_SPACE [TYPE ] be owned by own have LL-_USER -J Figure 15. E-R Diagram for Functionality System Page 49

PAGE 57

The relationships outlined by the data model (formally termed functional dependencies) are listed below. Note that these relationships are stated once from the many end Entity. Each usermode must belong to one and only one ALL_ USER usercode. Each Functionality_space must be owned by one and only one ALL_ USER usercode. Each Functionality_ entity must belong to one and only one Functionality_space. Each Functionality_entity must be of one and only one type. Each Functionality_entity may claim domain to one and only one Functionality_ entity. Each Functionality_hierarchy must have a parent in one and only one Functionality_ entity. Each Functionality_hierarchy must have a child in one and only one Functionality_entity. Each context must be valid for one and only one Functionality_ entity. Each context must be defined for one and only one usermode. Each session must belong to one and only one usermode. Each session_activity must belong to one and only one session. Each session_activity must be anchored in one and only one Functionality_ entity. Each session_activity must have a context in one and only one Functionality_entity. Page 50

PAGE 58

These functional dependencies provide the following schematic. A schematic lays out data in related tables and columns according to normalization rules. The schematic outlined below is derived electronically using the ORACLE CASE tool[21 CREATE TABLE usermode/*defines different modes for a user*/ (usermode VARCHAR (17) NOT NULL ,description VARCHAR (30) ,usercode VARCHAR (17) NOT NULL ,PRIMARY KEY (usercode,usermode) ,FOREIGN KEY (usercode) REFERENCES all_users (usemame) ); I* A dml (data modification language implying insert, update, delete) trigger ensures that all Usercodes have an entry for themselves as a usermode. This default entry is used for defining Context for Usercodes that are traversing Functionality Space without Usermode specification. */ /*all_ users is a system provided table in the data dictionary that catalogs all users that can access the database *I TABLE Functionality_space /*list of all Functionality spaces per user*/ (space VARCHAR(17) NOT NULL ,description VARCHAR(255) NOT NULL ,usercode VARCHAR (17) NOT NULL ,PRIMARY KEY (usercode,space) ,FOREIGN KEY (usercode) REFERENCES all_users (usemame) ); CREATE TABLE type I* list of valid types of FunctionalityFunctionality Space, Region of Interest, Functionality Group and Elementary Functionality *I (type VARCHAR(8) not null ,description VARCHAR(30) not null Page 51

PAGE 59

,PRIMARY KEY (type) ) ; CREATE TABLE Functionality_entity /*list of Functionality entities*/ (usercode VARCHAR(17) NOT NULL ,space VARCHAR(17) NOT NULL ,entity VARCHAR(17) NOT NULL ,description VARCHAR(255) NOT NULL ,type VARCHAR(B) NOT NULL ,domain_user VARCHAR(17) NULL ,domain_space VARCHAR(17) NULL ,domain_entity VARCHAR(17) NULL ,domain_change_date DATE NULL/* date & time domained entity changed *I ,domain_lookup_date DATE NULL/* date & time domained entity was looked up by user*/ ,file_pointer VARCHAR(255) NULL /*pointer to executable file in case of elementary Functionality*/ ,executable_type VARCHAR (17) /*describes system used to invoke executable*/ ,PRIMARY KEY (usercode,space,entity) ,FOREIGN KEY (type) REFERENCES type(type) ,FOREIGN KEY (usercode,space) REFERENCES Functionality_space (usercode,space) ,FOREIGN KEY (domain_user,domain_space,domain_entity) REFERENCES Functionality_entity (usercode, space, entity) ); /* For sake of procedural simplicity, each Functionality Space is entered as a Functionality Entity. This allows the Functionality Space to participate in all Entity properties such as group 'explosions' and Context. */ CREATE TABLE Functionality_hierarchy I* list of Functionality groupingthis is a many to many recursive structure with groupings achieved through a parent child relationship. Starting with any parent, all children of the parent x levels deep, can be procured */ (usercode VARCHAR (17) NOT NULL ,space VARCHAR (17) NOT NULL ,parent_entity VARCHAR (17) NOT NULL ,child_entity VARCHAR (17) NOT NULL ,relationship_sequence NUMBER (10) NOT NULL UNIQUE ,status VARCHAR (1) /*is association deleted or not*/ Page 52

PAGE 60

,PRIMARY KEY (usercode,space, parent_entity,child_entity) ,FOREIGN KEY (usercode,space,parent_entity) REFERENCES Functionality_entity (usercode,space,entity) ,FOREIGN KEY (usercode,space,child_entity) REFERENCES Functionality_entity (usercode,space,entity) ); I* The relationship_sequence is an incrementally increasing sequence number that ensures the consistent, ordered retrieval of Functionality Entities belonging to a Group Functionality ; CREATE TABLE context/* sets up context properties for a location ; (usercode VARCHAR (17) NOT NULL ,space VARCHAR (17) NOT NULL ,context_entity VARCHAR (17) NOT NULL ,context_level NUMBER (4) NOT NULL ,context_sequence NUMBER (5) NOT NULL ,anchor_entity VARCHAR (17) NOT NULL ,location_level NUMBER (4) NOT NULL ,location_sequence NUMBER (5) NOT NULL ,usermode VARCHAR (17) NOT NULL ,level NUMBER (4) NOT NULL ,distance NUMBER (3) NOT NULL ,zoom_radius NUMBER (3) NOT NULL ,visual_paradigm VARCHAR (1) NOT NULL /*R for radial, T for tabular ; ,PRIMARY KEY (usercode,usermode,space,context_entity,context_level context_ sequence, anchor_ entity ,location_level,location_ sequence) ,FOREIGN KEY (usercode,space,context_entity) REFERENCES Functionality_entity (usercode,space,entity) ,FOREIGN KEY (usercode,space,anchor_entity) REFERENCES Functionality_entity (usercode,space,entity) ,FOREIGN KEY (usercode,usermode) REFERENCES usermode (usercode,usermode) ); I* A tuple belonging to this table states that a User can, using a Location in the explosion of an Entity (the Context Entity), set the context properties for the representation of a Location in the explosion of another Entity (the Anchor Entity). Page 53

PAGE 61

Context properties assume default values if they have not been explicitly stated. If Entity A 1 has been exploded and context is changed to a location holding an Entity B1 then the spatial representation of A 1 and its children Entities could change as per tuples in this table. Next, if Entity C1, which appears in A1's representation, were to be exploded, the system firsts checks if Context is defined for C1 with respect to the current Context B1. If this is not the case, the system checks if Context is defined for C1 with respect to itself (context_entity = C1 and context_levei=O and context_ sequence= 0). If this search also is empty, default context properties are applied. *I I* The breadth first nature of the algorithm (that assigns level based sequence number locations to Functional Entities) and the chronologically incrementing sequence number of Functional_hierarchies (that guides the assignment of the level based sequence numbers) reduces the need to modify records in this table as spatial representations change; except in the case of explicit deletes. For deletes, the status field of functional_ hierarchy is set to 'D' thereby preserving the numbers handed out by the algorithm. An alternate approach would be to fix up all location changes. *I CREATE TABLE session I* list of descriptions of user sessions that need to be captured *I (usercode VARCHAR (17) NOT NULL ,usermode VARCHAR (17) NOT NULL ,session NUMBER (6) PRIMARY KEY ,session_description VARCHAR (255) NOT NULL ,session date DATE NOT NULL/* date and time when session was last executed *I ,FOREIGN KEY (usercode,usermode) REFERENCES usermode (usercode,usermode) Page 54

PAGE 62

); CREATE TABLE session_activity I* list of activities performed in a captured user session *I (usercode VARCHAR (17) NOT NULL ,space VARCHAR (17) NOT NULL ,session NUMBER (6) NOT NULL ,activity sequence (6) NOT NULL/* chronological sequence of activity *I ,anchor_entity VARCHAR(17) NOT NULL ,context_entity VARCHAR (17) NOT NULL ,context_level NUMBER(4) NOT NULL ,context_sequence NUMBER(5) NOT NULL ,location_entity VARCHAR (17) NOT NULL ,location_level NUMBER(4) NOT NULL ,location_sequence NUMBER(5) NOT NULL ,PRIMARY KEY (session, activity_sequence) FOREIGN KEY (usercode,space,context_entity) REFERENCES Functionality_ entity (usercode, space, entity) ,FOREIGN KEY (usercode,space,anchor_entity) REFERENCES Functionality_entity (usercode,space,entity) ,FOREIGN KEY (session) REFERENCES session (session) ); I* This table stores for each session a chronological sequence of-from what Entity (Anchor) with what Context, what location (location_level, location_ sequence) was launched *I I* The Context Entity and the Location Entity could be derived from their respective levels and sequence numbers. These are explicitly stored in the data structure to expedite the process that displays the characteristics of a Session *I Page 55

PAGE 63

Design of The User Interface User Interface Standards The User Interface assumes the user device is mouse capable. All 'click' references are to a two button mouse. Each screen has a top level Menu Bar that displays options that a User can exercise. Options on the Menu bar are also available by right clicking the mouse. This replicates the Menu Bar on a pull down tablet from which an option can be selected. The Menu bar has an Undo option that voids the previously completed action. The Menu bar has a Menu option that displays other screens belonging to the Functionality System. The Menu Bar has a Help option that provides hypertext based, indexed help presented in the Microsoft Windows based help standard. When data is presented in a grid format, the columns of the grid can be dragged to any width. Graphical User Interface objects are repeatedly re-used to provide a consistent look and feel. Logging In The database administration function provides a User with access to the Functionality System application and data structures in addition to the original existing data structures and applications Access to the Functionality System is secured through the Login screen. This screen receives a Usercode and Password combination that is validated against usercode/password security, maintained in the database for which the Functionality System has been implemented. Page 56

PAGE 64

..... Figure 16. Login Registration A Registered User is one that owns at least one Functionality Space. This user can directly enter the system and start traversing the Functionality Space. He/she could, at any point, start invoking or cataloging Functionality. The process of initializing the first Functionality Space is called Registration. This is done using the Create Functionality Space screen. This screen can also be used for creating additional Functionality Spaces for a User. Undo Menu Help Figure 17. Create Functionality Space Page 57

PAGE 65

The Create Functionality Space Screen can also be used for retrieving Functionality Spaces that belong to the current Usercode. This retrieval is based on wild-card enabled entries in the Functionality Space or description prompts. Based on these entities one or more Space definitions are displayed, in grid format. Undo Menu Hel .... Oisplay Function
PAGE 66

Selecting Functionality Both Registered and non-registered Users can directly move to the Select Functionality Entity screen. This screen allows a User to zone in on any Functionality Entity cataloged by the Functionality system. This access spans Functionality Spaces and Entities belonging to other Users. Select functionality Entity Switch Context Groupings Domain Usermode Help Undo [ ......................... I 1 ..................... 1 ........................ 1 L ........ Jl Figure 19. Select Functionality Entity This screen allows the User to peruse and select any Functionality Entity cataloged in the System. The User gets a pull down list for all categories such as Usercode, Functionality Space, etc. from which he/she can retrieve any specific Entity. Full Page 59

PAGE 67

selections or wild card entries in any one prompt, restrict the values returned by the other prompts, as well as values returned by the pull down list. The entire selection can be constrained by Domain controls. Values can be restricted to Domainee Entities that have changed since a previous look up, or Domained Entities. The sequence of restriction follows chronological entry. The process can be Undone from the menu bar. A selected Entity can be Launched by double clicking or the groupings for this Entity can be explored (Launching and groupings will be shortly addressed). The Domained and Domainee buttons are turned on if either case holds. The Domain option on the Menu Bar pops up the Display/Select Functionality Entity screen to display Domainee or Domained entities. The Retrieve button, returns Entities in a grid format, restricted by the selection criteria. OlsplayJSeled functionality Eo4ity Figure 20. Display Functionality Entity Page 60

PAGE 68

Any specific Entity can be selected from the grid and Launched (double clicking) or the groupings for this Entity can be examined. If an Entity is a Domainee and points to another Entity, the row displayed starts with o. If the Entity is Domained or other Entities have claimed domain to it, the display row starts with ax. For such entities the Domain option produces a listing of the Domained Entity or Domainee Entities. The screen used for this listing is the same Display/Select Functionality Entity screen. Groupings The hierarchical position of an Entity, within Functionality Groupings, is depicted by the grouping screens. The purpose of this screen is to be able to walk up or down the grouping tree structures to see parent, child and peer level Entities and select the appropriate Functionality Entity to launch. Right clicking on any Entity informs the User of the description and domain information regarding that Functionality (via the Display/Select Functionality Entity screen). A single left click on any Entity makes it the current Entity. Page 61

PAGE 69

Entity tree Structure (Groupings) Figure 21. Groupings A double left click on an entity launches it. The Functionality selection allows a User to zone in on Elementary or Group level Functionality. The grouping screens allow a User to peruse the environment surrounding the selected Functionality and Explode Functionality at the right level. Page 62

PAGE 70

Selecting a Usermode Before launching a Functionality Entity, a User might want to select a Usermode. This selection would influence Context or the view of a Functionality Entity as it is visually represented. Usermode selections are also used to invoke Long Term or Session Memory (these topics will be discussed in greater detail later). The select button on the Create Usermode and Display Usermode screens selects a Usermode. In the Display Usermode screen, double left clicking a Usermode selects it (this feature is also available in the Create/Select Usermode screen). These also allow the User to peruse the Usermode set up for other Users. However, all Usermodes are only modified and created for the Usercode currently logged in. ...... .. t,J_sermode Figure 22. Create/Select Usermode Page 63

PAGE 71

As Usermodes are largely used in setting up Context, the Used in Context button allows the selection to be restricted to Usermodes for which Context has been established. If no Usermode is selected, the logged in Usercode is the default Usermode. The Entity option in the Menu bar provides a list of all Functionality Entities for which Context has been defined. The screen used for this list is the same as the Display/Select Functionality Screen. Usenuodc Figure 23. Display/Select Usermode Switching Context The Switch Context option toggles between a Context On /Context Off state. The User can arrive at a Functionality Entity and Switch Context (on) to that Location. Next, the User can traverse to any other Entity and launch it with the previously set Context. At any point, the current Context setting can be switched off via the toggle. Page 64

PAGE 72

Visual Presentation Paradigms and Context At this point, a User can zone in a particular Entity, set Usermode and Context and Launch the Entity. The Entity is Launched with a default Context of a tabular view, exploded one level deep. The Functionality Space FS-1 that was used at the beginning of this chapter will appear as shown below. FSt Describe Group Set Context Switch Context Create t.4ove Copy Save Session t.4enu Undo Hel Figure 24. Visualization of FS-1 Note that the Title indicates the Anchor Entity. Any displayed Entity (including the Title) can be highlighted (single left click). Using the Menu Bar, this Entity can be described (via the Display/Select Functionality Entity screen) and its groupings can be navigated (via the Groupings screen). If the Create option is exercised the Create Functionality Entity Screen (shown later) is invoked and the Functionality Entity is placed under the highlighted Entity. Highlighted Entities can be moved and Page 65

PAGE 73

copied by invoking Menu options and dragging to a new location. Create, Move and Copy options will alter group Entities. A warning box informs the User of Functionality Groups and Domains that are affected by the change. Clicking on the box produces a list of affected Entities (via the Display/Select Functionality Entity Screen). The list can be perused and the change can, if necessary, be undone. Context records might need to be altered to accommodate changes in Functionality Grouping. Context can be switched according to paradigms explained earlier. In the next screen, Context has been switched to the FS-1 for which Context has been specifically been set for a radial presentation with one level of Explosion. Also note that the Zoom Radius is lower for ROI-Misc. When presenting ROI-1, the diagram also notes that its' explosion level is set to 1. This causes a further explosion of ROI-1. Describe Group Set Context Switch Context Create Move Copy Save Session Menu Undo Help Figure 25. Visualization of FS-1 with FS-1 as Context Page 66

PAGE 74

While viewing a visual presentation a User can, by clicking and dragging the mouse, rubberband or create a box around multiple Functionality Entities. Next, he/she can zoom in and out of the area of interest by pressing Cntri-Z. Invoking the Set Context option from the Menu Bar, pops up the Set up Context Properties screen. This screen can be used to create, modify or delete context properties for the highlighted Entity. Note that default Context propertiesare supplied for Entities for which these have not been explicitly set. Sel up Cantext Properties Figure 26. Set up Context Properties Page 67

PAGE 75

Creating Functionality Functionality can be created by exercising the Create option on the visual presentation screens This invokes the Create Functionality Entity Screen Create Functionality Entity Undo Menu Hel p Figure 27. Create Functionality Entity If Functionality Type is elementary, a box appears requesting the file name of the attached binary If the Domain button is turned on, the Select Functionality Screen is invoked to select the Domained Entity. Session Memory The Create Session screen allows a User to create a Session with a description, modify the description or delete a Session. This screen is typically invoked in create mode while a User is reviewing the visual presentation of a Functionality Entity. The Page 68

PAGE 76

Save Session option on the Menu Bar invokes the Create Session screen. This screen allows a User to describe a Session. All Functionality Entities that have been launched in the User Session, are then captured in the session_activity table. Session Memory Figure 28. Session Memory The Retrieve button, returns Session activity information, in a grid format, restricted by the selection criteria. Session memory can be invoked for any Usercode thereby facilitating sharing of learning patterns. Another User's session can be acquired by a User selecting the Session Memory and simply modifying the Usercode. Evidently, the modified Usercode needs to be the one logged in. Page 69

PAGE 77

Display Session Activity Figure 29. Display Session Activity The Display Session Activity returns, in time sequence, the various Entities launched by a User in a Session. A User can delete any sequence (for owned Sessions). By double clicking a sequence, a User can launch the Session from that activity forward. This would put the User in the visual presentation screens that have been described above. The Enter keystroke steps the User through the Session chronology and a (Cntrl, Enter) sequence causes a step back. The above screens provide a look and feel for the user interface, constructs and paradigms used to establish and present the Functionality System. Page 70

PAGE 78

Chapter 7 ARCHITECTURE, IMPLEMENTATION AND FUTURE DEVELOPMENTS Outline The Functionality System is currently under development and is in proto-type state. This chapter addresses the architecture used to develop the Functionality System, and some of the implementation considerations, problems and future developments. Architecture The Functionality System is generally useful for databases with substantial data dictionaries and a large established Functionality base. The Functionality System is currently implemented on an Oracle database (Version 7.1) with support for declarative referential integrity, database triggers and stored procedures. The database runs on a Symmetric Multi-Processing (SMP) architecture such as the HP9000/800, a PA-RISC processor based SMP machine running SMP capable UNIX (HP-UX 8.x) A SMP architecture has been employed to allow scalability. Page 71

PAGE 79

SYMMETRIC MUL Tl PROCESSING Redundant SCSI SCSI SCSI SCSI Hewlett Packard 9000/890 Architecture Figure 30. Symmetric Multi Processing As demonstrated by the above schematic, SMP architectures provide step wise scalability from a processor, memory and secondary 10 perspective. The Functionality Application is itself written in the Graphical User Interface toolkit, Powerbuilder, supplied by the Powersoft Corporation. Additionally some direct calls to the Microsoft Windows Graphical Design Interface (GDI) Application Programming lnterface(API) are used for the user interface. The application runs in pure client server mode on a Windows 3.11 PC with Open Database Connectivity (ODBC) to the backend Oracle database. This architecture is, once again, chosen to ensure scalability. In the client server architecture, the applicaition runs exclusively on the front end (client) PC using Powebuilder and Windows APis. The Page 72

PAGE 80

backend (server) machine exclusively runs the database engine. The connection to the backend is on Ethernet using the TCP/IP protocol. In this architecture all that passes on the wire is SQL to the database and the data to satisfy the SQL. This clear division of tasks allows for substantial efficiencies in data communications and a dispersion of processor load. In the schematic shown below, a third machine can be used as a compute server. The compute server receives Remote Procedure Calls (RPC) to perform processor intensive computations. Client Server Specialization Hierarchies Database Server Client Compute Server Figure 31. Client Server Architectures Multiple users access the Functionality System through client server technology on a fiber ring connected network. Page 73

PAGE 81

CLIENT SERVER Figure 32. Client Server Network Topology Implementation and Future Developments The architecture of the Functionality System allows the database and the Functionality System to be exclusively implemented on a PC with a local database. However, the User Interface is of significant size. Its size, complexity and resource utilization increases dramatically with increasing numbers of cataloged Functionality and deeper levels of nesting with grouped Functionality The short term memory strategy of nesting one anchor explosion after another (with grouping and display screens included for good measure) also contributes to the resource intensiveness. Page 74

PAGE 82

Consequently, even within the dispersed processing environment of client server, the application runs into memory constraints. This problem is compounded by the underlying limitation of 640K resident memory in MS-DOS that is the underlying operating system to Windows 3.11. The application is currently being tested on a beta version of the Windows 95 product (previously termed Chicago). Besides providing a more robust extended memory access, this product also provides a multi threading architecture that allows parallel establishment of different parts (say Regions of Interest) of the visual presentation of a Functionality Entity. This approach has substantially increased the speed of the presentation of dense visualizations. Another problem with the MS Windows GDI, is the lack of rubberband and continuous zoom API call. Zoom in the Windows API is largely discrete in implementation. Rubberbanding is used to select an area of a visualization and focus/zoom in on that area. Continuous zoom is used to accommodate the zoom radius property of Context. Both these issues are handled more easily in the Motif GDI. Some relief is again expected with Windows 95. An interesting extension to the Functionality System is cataloging Functionality against database tables. This would allow a User to review Functionality that works with a certain combination of tables. For example, to determine who hired John Smith and what department he works for, a User could search for Functionality that goes against the Employees and Department tables and zone in on the desired report. It would be possible to search Functionality binaries for strings of table names. Currently this approach has yielded inconsistent results. Page 75

PAGE 83

A more interesting approach could be to access repositories that catalog Functionality or 'methods' against tables. These repositories are the basis of Object Oriented database and systems designs. The Object Oriented approach combines Process Modeling and Data Modeling techniques, essentially formally documenting tables and the methods (or Functionality) that operate on them. The student feels that these system development methodologies will dominate in the near future11311141. Page 76

PAGE 84

BIBLIOGRAPHY 1. Furnas G. W. "Generalized Fisheye Views" CHI Proceedings, April, 1986. 2. Barker R. The Oracle Case Method-Entity Relationship Modeling. Addison Wesley Publishing Co., Wokingham, U.K., 1990. 3. Oracle SQL Language Reference ManualVersion 7.0. Oracle Corporation, Redwood Shores, CA, 1992. 4. Ullman J.D. Principles of Database and Knowledge -Base Systems. Volume 1: Classical Database Systems. Computer Science Press, Rockville, MD., 1988. 5. Sowa J.F. Conceptual Structures: Information Processing in Mind and Machine. Addisson-Wesley, Reading, MA, 1984. 6. Schank R.C.; Nash-Weber B.L. Theoretical Issues in Natural Language Processing. Association for Computational Linguistics, 1975. 7. Hom R.E. Mapping Hypertext. Analysis. Linkage, and Display of Knowledge for the Next Generation of On-Line Text and Graphics. Lexington Institute, Lexington, MA., 1989. 8. Bush V. "As We May Think" Atlantic Monthly 176.1, 1945, 101-8. 9. Englebart D.C.; Editors Howerton P.O.; Weeks D.C. A Conceptual Framework for the Augmentation of Man's Intellect. Vistas in Information Handling, Vol.1. Spartan Books, Washington D.C., 1963 10. Englebart D.C. "Authorship Provisions in Augment" Proceedings of the 1984 COMPCON Conference Feb 27 March 1. 1984. COMPCON '84 Digest, 1984, 465-72. 11. Akscyn R.; McCracken D.; Yoder E. "KMS: A Distributed Hypermedia System for Managing Knowledge in Organizations" Hypertext '87 Papers November 13-15, 1987. 12. Brown P.J. "Turning Ideas into Products: The Guide System" Hypertext '87 Papers, November 13-15, 1987. 13. Shlaer S.; Mellor S. Object-Oriented Systems Analysis. Modeling the World in Data. Yourdon Press, Englewood Cliffs, NJ.,1988. 14. Shlaer S.; Mellor S. Object Lifecycles. Modeling the World in State. Yourdon Press, Englewood Cliffs, NJ.,1992. Page 77