Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/25—Integrating or interfacing systems involving database management systems
  • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/26—Visual data mining; Browsing structured data
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching
  • Y10S707/99934—Query formulation, input preparation, or translation
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching
  • Y10S707/99935—Query augmenting and refining, e.g. inexact access
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99941—Database schema or data structure
  • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99941—Database schema or data structure
  • Y10S707/99943—Generating database or data structure, e.g. via user interface

Definitions

• the present invention relates to the field of data processing, and more particularly to relational computer databases, and to systems and methods for automatically generating without any custom programming a user interface for the database, and/ or a complete application utilizing the database.
• Modern databases - and in particular, complex or large databases which serve many concurrent users - are constructed as “client/ server” or “n-tier” (client/server/server) systems, wherein specialized components perform separate (and carefully delineated) functions.
• client/ server or "n-tier” (client/server/server) systems
• specialized components perform separate (and carefully delineated) functions.
• RDBMS relational database management system
• Such systems are generally composed of a "back-end” relational database management system (RDBMS) - which maintains o and manipulates information according to requests submitted by other components or software processes (or expert human administrators) via open-standard query Ian- guages (i.e., SQL) - nd a "front-end” presentation ates the end-users' work with the back-end data.
• RDBMS relational database management system
• Developing such a database system consists both in defining the organizational structure to be used by the back-end for storing data (that is, the complement of tables which store data, and the relational links between these tables) - known as a "schema” or “data model” - and in building a front-end program (or "application”) via which end-users can manipulate this data (and which communicates with the back-end on the users' behalf).
• data that is, the complement of tables which store data, and the relational links between these tables
• a front-end program or "application”
• the back- and front-end components must be closely synchronized and reflect similar structures, these respective development efforts are typi- cally rather separate - with the requisite synchronization and parallels in structuring being effected only manually.
• front-end applications is generally undertaken using conventional third- or fourth-generation computer languages, which require by- hand coding at a very low level of functionality.
• Current tools for easing the develop- ment burden are limited to fairly specific (and, still, fairly low-level) uses - among them, providing more-sophisticated or "richer” controls for manipulating individual data elements; associating individual user-interface elements with specific back-end storage locations; or - at best - offering "form generator” or "wizard” facilities to automatically generate the code for a simple UI display which manipulates a single under- lying (back-end) data table.
• UI user interface
• the application so presented reveals (and enforces) the relational/ hierarchical organization among the tables within the back-end via smoothly integrated UI mechanisms which are embedded directly into the base-table screen displays - providing a natural, powerful, and easy-to-use environment for managing complex data relationships and interactions.
• One embodiment (the "reference implementation") of the present invention achieves these and other objects by providing a system, currently written in Java and JSP, which automatically and dynamically ("on-the-fly") generates (in HTML, Javascript, and HTTP/ CGI code), a fully functional UI system, based upon, and connected directly to, the underlying data model (as instantiated within an Oracle ⁇ i SQL RDBMS).
• the UI is built based on an automated interrogation of the RDBMS, either as needed (on-the-fly) or by building an in-memory representation of the data model.
• the generated UI comprises all mode displays (e.g., browse, search, edit, and add) for all tables, and a full complement of mechanisms, integrated into the mode displays for representing, navigating, and managing relationships across tables.
• This embodiment has the capability of creating such a UI where the underlying RDBMS is complex and comprises a plurality of tables, constraints, and rel til sffifJslJHriiffllifee ⁇ , feii » lfy ⁇ Mohi-&al "context stack" for maintaining (and suspending) the working state of a particular table (comprising selected record, display "mode", pending form-field entries, in-effect search-filter parameters, Browse-mode scroll position, and any filter constraints im- posed from above stack contexts) while “drilling down” across relationships to work with related information (in a possibly constrained working context) and returning relevant changes to the parent-context table, and a corresponding UI convention for displaying and navigating this stack.
• the embodiment provides a set of rules for traversing/navigating the context stack. It further provides naming conventions and anno- tational methods for enhancing and extending the representation of table structures, constraints, and relationships within the back-end so as to more fully support revelation of the schema structure through external interrogation.
• FIG. 1 is a normal "browse mode" display from the reference implementation.
• FIG. 2 is a normal "search mode" display from the reference implementation .
• FIG. 3 is a normal "edit mode" display from the reference implementation .
• FIG.4 is a normal "add mode" display from the reference implementation.
• FIG. 5 is a diagram of the demonstration RDBMS schema from the reference im- plementation.
• FIG. 6 is a diagram of the relationship types comprised in the paradigm of the present invention.
• FIG. 7 is an annotated screen dump showing the active elements in a "browse mode” display.
• FIG. 8 is an annotated screen dump showing* e ⁇ eti ⁇ "add” or "search” mode display.
• FIGs. 9A - 9E show an exemplary "master/ detail drill-down" and a doubly- constrained subordinate table search as rendered in the reference implementation.
• the preferred embodiment of the invention corresponds in most respects to an implementation of the invention being developed under the trademark SCHEMALIVETM which is herein referred to as the "reference implementation.”
• the preferred embodiment is further represented substantially in full by the reference-implementation source code files, documentation and scripts in the appendices accompanying and incorporated by reference into this application, as further described in the text that follows.
• the preferred embodiment includes in addition some further developments which are herein described which have not as yet been rendered in the reference implementation.
• the preferred embodiment operates in accordance with a comprehensive and formal- ized paradigm for presenting a(n end-)user interface to any arbitrarily large or complex relational database schema (or "data model”), as represented via generally accepted data-modeling conventions (comprising the explicit declaration of any cross-table "ref- erential integrity" [ET] constraints, and full explo a €6r ⁇ 'r ⁇ f ⁇ afa le, fi*i ⁇ FK B S datatype- and constraint-attribute declaration mechanisms) and instantiated within a commercial-grade SQL RDBMS engine (Oracle ⁇ i, for example, in the reference implementation).
• the paradigm encompasses: • A set of “modes” for interacting with a(ny) given database table (which modes, taken together, cover all desired end-user operations which may be effected upon such tables), and a corresponding display format ("screen” or “window” architecture) for each mode.
• modes comprise:
• a TITLE BAR which indicates current mode, current table, context- constraint (if any), and filter indicator (if search-filter is in effect)
• a TABLE-NAVIGATION HEADER which provides direct "random access" to any system table, in either Browse or Search mode, via either a full (dropdown)-list of all (available) system tables or a short list of (clickable) "quick links" to key tables. Use of this header will also reset (and abandon) any nested stack-contexts in effect
• a CONTEXT-STACK DISPLAY which indicates the active table and mode at each level in the context stack (described below), and also allows direct navigation ("pop-up") to any suspended (“higher”) stack-level (with abandonment of all lower levels)
• a MODE-NAVIGATION BAR which allows the user to move amongst the various available mode displays for the current working table ( ⁇ T" stack level").
• the list of av$ilt1 li '' ni «s according to both the user's access rights (described below) and the current state of the working session (i.e., whether a search-filter is currently in effect).
• the full list of possible mode-navigation options is: FULL BROWSE, FILTERED BROWSE, NEW SEARCH, REVISED SEARCH, and ADD.
• FILTERED BROWSE and REVISED SEARCH appear only when a search-filter is currently in effect; if so, the former restores a Browse-mode display with the most recent filter and scroll- position, while the latter pre-populates a Search-mode display with the current filter parameters
• DELETE capability is also readily incorporated - as either (or both) true record-removal from the underlying table, and/ or record "flagging" for UI suppression (with continued underlying-table record retention) - simply by adding (according to the user's access rights, potentially) another pushbutton within the Edit-mode display
• a set of rules and methods for moving among the modes (and, hence, displays) for a given table comprising:
• MASTER DETAIL (a.k.a. "parent/ child” or "one-to-many")
• the paradigm specifies a "default" behavior for determining this name field within the foreign-table record, based (optionally) upon a combination of field-naming conventions, field datatype (i.e., character data), field constraints (i.e., unique values), and/ or order of appearance within the table definition (i.e., first non-primary-key field meeting other requirements) •
• this field is the first one whose name ends with "_NAME” - or, in special-case handling for 1a- bles containing "LAST_NAME", “FIRST_NAME”, and "MIDDLE_NAME” columns, a composite "Last, First Middle” value.
• Additional special-case processing supports successive cross-referencing through multiple tables until a " MAME" field is discovered, if (and only if) intervening tables include unique-value constrained FK columns. If no name field can be resolved, the UI displays the actual key values (that is, the primary-key values from the foreign table) themselves • Alternatively, the rules for determining the name field can themselves be made "soft" - that is, specified once (globally) by a system administrator, and used thereafter to drive all (default) name- field constructions.
• a dropdown list includes the display-names for all for- eign-table records, and UI actions on this list are correlated to the underlying keys
• record displays incorporate a "pseudo- field" for each associated detail-table, which indicates the number
• these pseudo-fields can also be (and have been, in alternate implementations) readily incorporated into the Browse-, Search-, and Add-mode displays, at the cost of added complexity in supporting views (i.e., correlated-subqueries for Browse-mode displays) and state-management logic (i.e., transitioning to Edit mode for not-yet-completed Add-mode transactions before allowing navigation to associated detail-table contexts where the user might add dependent "child” records), and the attendant per- formance implications
• the on-screen field is presented as a multiline, vertically scrollable control with multiple-row visibility, rather than the default single-row (and non-scrollable) entry field.
• Failed validation (upon field-exit and/ or at page-submission time, depending on the type of validation) puts the "focus” back into the corresponding problem-field (or the first of several), highlights (“selects”) the entire field contents, and displays an informational pop-up dialog box explaining the problem.
• a hierarchical "context stack” for maintaining (and suspending) the working state of a particular table (comprising selected record, display mode, pending form- field entries, in-effect search-filter parameters, Browse-mode scroll position, and any filter constraints imposed from above stack contexts) while “drilling down” across relationships to work with related information (in a possibly constrained working context) and returning relevant changes to the parent-context table, and a corresponding UI convention for displaying and navigating this stack
• a superseding filter is applied to all detail-table mode displays, separate from (and invisible to) any lower-context search-filters which may subsequently be applied by the user
• Cross-reference drill-downs are "context sensitive" to the parent- field status: A drill-down from a blank parent-field enters the subordinate stack context in "Add” mode, while a drill-down from a non-blank parent-field enters the subordinate stack context in "Edit” mode for the already-selected (cross-referenced) secondary-table le- cord. Nevertheless, the default drill-down mode can be "overridden” (that is, abandoned) via a lateral or horizontal mode-switch in the lower stack context.
• the RDBMS is first interrogated or scanned by this software, applying a body of rules to interpret the data model (comprising its tables; their column-complements, datatypes, and constraints; and relationships across the tables), and to correlate same to the UI paradigm (either "on-the-fly", or by building an in-memory representation, or "cache", of said data model, and by automatically deriving enhanced back-end “views" of all tables, which are consistent with the paradigm and which, further, co- herently incorporate”any and all extensions, which may have been specified as described below).
• a body of rules to interpret the data model (comprising its tables; their column-complements, datatypes, and constraints; and relationships across the tables), and to correlate same to the UI paradigm (either "on-the-fly", or by building an in-memory representation, or "cache", of said data model, and by automatically deriving enhanced back-end “views" of all tables, which are consistent with the paradigm and which, further
• a core complement of naming conventions and annotational methods (written in XML, in the reference implementation) is used for enhancing and extending the representation of the table structures and relationships (entirely within the back-end representation of the data model, in the reference implementation) so as to more fully support revelation of the schema structure through external interrogation.
• the generated UI comprises all mode displays for all tables, with integrated(-into-the-mode-displays) mechanisms for representing, navi- gating, and managing relationships across tables (comprising hierarchical context constraint/enforcement, and pass-through/ "pop-up" return, or "propagation", of subordinate-context results).
• the preferred embodiment applies logic to (re-)convert column- and table-names retrieved through RDBMS interrogation from all-uppercase text, if necessary (as it is with Oracle ⁇ i, in the reference implementation) into mixed-case, initial-caps text (where only the first letter of each word - or "token” - is capitalized), and to replace underscore characters with spaces.
• the case- restoration logic is designed to also consider a list of approved acronyms - or, more generally, "exceptions" - which, when encountered as tokens within object-name strings, are instead cased exactly as they appear in the list. (This could mean all- uppercase, all-lowercase, or any non-conventional mixture of cases, such as "ZIP- code”.)
• This case-exceptions list is provided once, globally, for the entire system, and impacts all table- and column-name references throughout the UI presentation.
• the list is defined as a string array within a public "Cus- tomCaps" object; this object could in turn be initialized via a disk file, or a special da- tabase table.
• the software also constructs and utilizes the above-described hierarchical context stack for maintaining (and suspending) the working state of a particular table (comprising selected record, display mode, pending form-field entries, in-effect search-filter parameters, Browse-mode scroll position, and any filter constraints im- posed from above stack contexts) while "drilling down" across relationships to work with related information (in a possibly constrained working context) and returning relevant changes to the parent-context table, and a corresponding UI convention for displaying and navigating this stack (see annotations regarding stack display in Fig. 9C).
• a particular table comprising selected record, display mode, pending form-field entries, in-effect search-filter parameters, Browse-mode scroll position, and any filter constraints im- posed from above stack contexts
• a corresponding UI convention for displaying and navigating this stack (see annotations regarding stack display in Fig. 9C).
• the result- ing error screen also incorporates a stack display.
• the default error- screen behavior is to restart the user's session after a timed delay (and thereby abandon all work in progress), the user will often be able to recover his session by making a selection from the error-page stack display
• the preferred embodiment further provides a structured collection of methods, mechanisms, tools, techniques, and facilities for extending, customizing, adapting, or overriding the baseline UI paradigm and software to support non-standard and/ or special requirements ("business rules"), comprising:
• Such overrides can be useful, for example, when the foreign (referenced) table lacks a (resolvable) name column; when a composite (multiple-field), treated, or otherwise modified display-name is desired; when the sort-order within display lists should be modified; or when the foreign-table records depend on yet other table-records
• a specification consists of a listi ⁇ ii ⁇ ' ' fhe > ' the desired display order (either by name or, alternatively, by ordinal position in the actual underlying table)
• Such a derived (non-table) result-set is typically generated by a "stored query” or "SQL VIEW" within the back-end RDBMS, and nevertheless can be rendered and presented by the UI as if it were an actual single base-table (subject to certain limitations which may be imposed by the underlying RDBMS - particularly, the inability to edit or add "records" for such result-sets, rendering them effectively "read-only”)
• a specification identifies the foreign table which contains the dropdown-list values, and the column (either by name or, alternatively, by ordinal position within that table) which supplies the actual values
• a mechanism is provided to create a (series of) cross-referential link(s) from the individual cells (row- values) in a given column of a Br ⁇ l ge md&i 'Sifj )Ig.y ' fcft Sl ⁇ fJi Ink forwarding the user to a secondary display - most commonly, to an Edit form for the underlying base-table containing that cell's value (although it is, in fact, possible to link-through to any arbitrary table, row, and column, and in any "mode")
• the link appears as a highlighting (in the reference i - plementation, a "clickable link” or HTML "HREF") of the cell-value itself. (Empty cells display the value "NONE" so as to still enable drilldown navigation.)
• the display forwards (typically) to an Edit form for the corresponding record in the appropriate underlying base-table, with the proper edit-field pre-selected (i.e., given the "focus").
• the system auto-navigates to the same exact base-table Edit form, selected- record, and edit-field that the user could (theoretically) navigate to himself, manually, in order to alter the underlying datum that supplies the custom view
• a specification identifies the underlying (or "target”) base-table
• a special-case extension of the specification can be associated as a table-level annotation with the custom view itself (rather than one of its columns).
• the specification will modify the behavior of the leftmost-column "row label" links (which, in normal-table Browse-mode displays, link to Edit-mode displays for the corre- sponding table-records).
• a common use for such specifications is to support master/ detail-style transitions to secondary Browse-mode displays of records which "belong to" the selected custom-view record
• specifications are made via a spe- cial XML tag (" ⁇ customDrillDown>”) which, in turn, contains sub-tags indicating the target base-table (" ⁇ tableName>”), display- mode (" ⁇ mode>”), identifying-FK field within the custom view (“ ⁇ keyColumn>”), constraining-context or master/ detail key, if any (" pkrentColumn>”), and target il ilOT ⁇ Bc i ⁇ iil ⁇ ⁇ Mnds:'''*- tached to the corresponding view-column as a "comment”
• the preferred embodiment also supports the specification and enforcement of both global and granular (by table and function) access rights and activity-stamping, according to a group-based (rather than hierarchical) permissions scheme, and based on table entries which themselves can be entered and maintained via the system:
• the PEOPLE table contains an Active_Flag field, which allows for
• the USERS table incorporates (among others) a Login_ID field, which is correlated against the system-user's operating-environment credentials. (In the reference implementation, this is the UID which has been authenticated and forwarded by the web server; alternatively, it could be the user's OS login.)
• a Login_ID field which is correlated against the system-user's operating-environment credentials.
• this is the UID which has been authenticated and forwarded by the web server; alternatively, it could be the user's OS login.
• the system establishes a new user-session (upon the user's initial contact), it attempts this correlation to a valid USERS.LoginJD. If no correlation can be made, access to the system is denied; otherwise, the corresponding USERS.Users_Key value is henceforth associated with that user's session
• SECURITY__TABLE maintains a list of all security-mediated tables and custom views. (Alternatively, this list could be automatically derived from the system's data-model interrogation; the use of an explicit and hand-managed "special” or “hidden” tables and/ or views)
• SECURITY_GROUP supports the definition of functional security roles. In and of themselves, entries to the SECURITY_GROUP table are little more than descriptive names; their primary purpose is to serve as "connective conduits" between USERS and SECURITY TABLEs. It is important to note (again) that SECURITY_GROUPs are non-hierarchical; that is, each group can be granted any mix of rights to any arbitrary set of tables, without re- spect to the rights of other groups. And USERS can be assigned to any number of SECURITY_GROUPs; When a user belongs to multiple groups, her aggregate rights comprise a superset of the rights for each of the groups to which she belongs
• SECURITY_GROUP_USERS simply effects many-to-many relation- ships between USERS and SECURITY_GROUPs, and is defined (via the methods described above) as a "detail" table to both of these
• SECURITY_GROUP_TABLE supports many-to-many relationships between SECURITY_GROUPs and SECURITY_TABLEs (and is a "detail" table to both). Additionally, however, the SECURITY_GROUP_TABLE incorporates Boolean (true/false) columns which indicate permission for the related SECURITY_GROUP to (respectively) browse, add to, edit, or delete from the corresponding SECURITY_TABLE. This forms the nexus of access-rights control All UI displays automatically adjust to the current user's access rights. In particular, the following navigational elements ("links", as defined in the reference implementation), appear or are suppressed according to the user's rights:
• Mode-navigation bar links (browses/ searches/ add); here, suppressed links are entirely removed from the display, rather than simply "disabled” (or made links, below)
• custom views with custom-drilldown specifications are subject to "double" security mediation: If edit permission to the custom view itself is withheld for a given user, then all custom-drilldown links will also be disabled. But (even) if the custom-view edit permission is granted, the user must also have the necessary rights to support each particular drilldown (e.g., edit or browse permission on an underlying table) before the corresponding link will be enabled
• all sys- tern add/ edit activity can be time- and user-stamped at the table-record level (optionally, on a per-table basis).
• Security-stamping is completely automatic, and is governed (in the reference implementation) by the presence of four special columns within the table: Entered_By_Users_Key, Entry_Date, Modi- fied_By_Users_Key, and Last_Modified_Date.
• any "add” event causes the current USERS.UsersJKey (from the user's session) to be recorded in both the Entered_By_Users_Key and Modified_By_Users_Key columns, and the current system time to be stamped into both the Entry_Date and Last_Modified_Date columns.
• "Edit” events update only the Modi- fied_By_Users_Key and Last_Modified_Date columns. Note further that when they exist in a table, these fields are visible only in Browse and Search displays; they are hidden (but automatically updated) from Add and Edit displays
• RO ⁇ -LEVEL SECURITY allows for t-S6 ltaaK ltl-! *Nfe .(f&- ij$
• row-level security can be said to affect only "content” visibility, rather than “structural” visibility (as with other security axes); a row-level security filter impacts which particular table- entries are presented, but never which classes or types of data elements
• a specification thus identifies the filter condition (i.e., WHERE clause) that relates one or more table-columns to (some transfor- mation/JOIN-sequence on) the current user. (Note that such "user relations" may optionally involve attributes of the particular user, and/ or those of "security groups" to which the user belongs) • Specifications are associated as table-level annotations with the actual underlying table
• Edit-function mediation is processed by the UI on a per-field basis, either (or both) during rendering (where display conventions utilize read-only fields, or otherwise signal non-editability via labeling conventions [such as italicized text]) and/ or processing ' (where attempts to change nol ⁇ iEbl .lilffi,,te ,' Mjea , dp th an alert notification to the user)
• the system can detect this particular error, provide a detailed explanation of how and why it might have occurred, and (per above) allow the user to recover her session-in-progress without any loss of work
• SECURITY VIOLATIONS Generally, the system proactively prevents the user from attempting access to any authorized system modes or functions. However, in the (web-based) reference implementation, it is not impossible for the user to navigate to a situation where he might possibly attempt an illegal transition - or to manually adjust a URL so that it attempts such unauthorized access without triggering a session-sequence error (as described above). In these cases - and in the simpler case, when a user attempts access without any system rights whatsoever - the system provides a plain-English report of exactly what access rights the user has tried to violate
• Custom follow-on actions can be associated with specific errors, so that special-case recovery procedures can be specified. (For instance, a database-detected data-entry violation might cause a return to the previous data-entry form.) "Mined" runtime-environment information can also be used here to govern the behavior of said follow-on actions
• a generalized, extensible, and data-driven "pop-up help" facility is also included in the reference implementation.
• This facility allows for the specification of descriptive text wruc i can be associated both wfM!i GifldHli ⁇
• wruc i can be associated both wfM!i GifldHli ⁇
• the specifications are stored within back- end tables - so that they, too, may be administered via the system UI - although any of the above-described annotational methods could alternatively be used.
• the detailed implementation of each of the foregoing capabilities is set forth in full in the accompanying source code, which represents the complete source code for a working version of the reference implementation.
• a full demonstration RDBMS schema upon which this system can operate has been provided, and accompanies this application and is incorporated herein by reference (see Fig. 5 and the CreateSchema.sql script).
• a set of mechanisms, rules, and methods may be provided through which each end-user can evolve (and manage) personalizations to the UI architecture (with persistent back-end storage and tracking by user and/ or group) - including (but not limited to) preferred table-navigation hierarchies; UI "entry points” based on usage-frequency patterns; default (or most-recent) searches/ filters for each back- end table; default "page size” for Browse-mode lists (adjusted for the particular user's screen resolution, for example); default
• a generalized journaling/ auditing subsystem may also be integrated. Such a subsystem could, for instance, utilize database "triggers" to update a master table with a new tuple (comprising table-name, record-key, column-name, old-value, new-value, user-key, and timestamp) whenever any table-record is modified. Such a mechanism would (at a cost in system performance, of course) permit complete backtracking/ "rollback" to previous database states, and guarantee the ability to recover from any rogue data modifications (whether accidental or malicious) and identify the actors
• journaling/ auditing support is the ability to require a user to explain his justification for (only) certain data-field changes, and then either record that explanation to the system journal or audit log (along with the other tuple information), or (possibly) roll-back the transaction (if the user declines to supply an explanation).
• Such a facility could be implemented with additional text-entry fields integrated into the primary Edit-mode display, or alternatively, with "pop- up window” logic (which, within World Wide Web presentation, could comprise additional browser windows or DHTML "sim ⁇ l edr ⁇ '( ⁇ - l i r.'mati Wfe5;: « The specification of which data-fields should require such justification would be considered a "business rule", and could be implemented via any of the annotational methods described elsewhere in this document. Such specifications could also be assigned at various levels of global vs. local "scoping" (i.e., perhaps automatically for all date fields, or only for specifically assigned text fields)
• the corresponding column could simply track the current (primary) sort-order column (as described above), if implemented
• any changg SinfthHjb srfi ⁇ i ⁇ llng S ljuiim would then automatically regenerate the tab list, according to the range of actual (sorted) leading characters appearing within that column. In this way, numeric tabs would appear for a "social- security number” column, vs. alphabetic tabs for a "last name” column
• the reference-implementation Search-form paradigm comprises a single set of fields (corresponding to the underlying table-columns), where any entered filter-values (for the respective columns) are logi- cally "AND"ed together.
• a more general and flexible search facility could:
• phrase which is “AND”ed or “OR”ed together (selectably, as above) with the parenthetical phrases for other sub-forms
• the reference-implementation Add-form logic does not "initialize” fields for which the back-end defines "default" values - that is, although the underlying table-column will (properly) be set to its default value if the corresponding Add-form fie ⁇ T ⁇ s not explicitly set, the user I ; $l ifcIiiii3n ting the new record) of that default value. Instead, the form could automatically pre-populate the appropriate fields with their corresponding default values (as determined through interrogation of the underlying column-constraints)
• Each tuple could (optionally)' to "scope" the relation - for instance, so that the filter should consider only so many levels above the current stack-context, or that the filter only applies if certain other tables also do (or do not) appear in intervening levels - and possibly, even, only in a specific sequence. It would also, of course, be further possible to assign multiple such "sensitivities" to the same target-column.
• a project-management schema in which both equipment and technicians are assigned to projects; techni- cians have specific equipment certifications; and schedules apply both to projects and to technicians.
• a sin- gle many-to-many table might connect technicians to projects; if the table is accessed directly (that is, at the topmost stack-level, rather than by drilling-down to it from the associated project record), then each time the "project"-dropdown is altered, the "technician” dropdown-list would be automatically regenerated ac- cording to the above-described criteria.
• (potentially multiple) specifications per target-column would resemble those for context-sensitive dropdowns, except (of course) that the "superior-level table” and “scoping extensions” would be irrelevant here. Note that although these two dropdown-types are similar - and that, in some cases (namely, where context-sensitive drop- downs utilize only direct drill-down relations), the former could AS simulated with the latter - which makes it more suitable for certain types of use
• the user-stamping fields described above (Entered_By_Users_Key and Modi- fied_By_Users_Key) generally appear together within the same fables, always share identical dropdown lists, and can (potentially) grow quite long over time; logic to retrieve the shared list once from the RDBMS - rather than twice - for use within both dropdown controls can effect meaningful gains in system responsiveness.
• the preferred embodiment comprises a stand-alone application which interacts (on a client/ server basis) with a back-end RDBMS, it may in some circumstances become desirable instead to integrate some or all of the invention directly into said RDBMS product (or a tightly-coupled extension or utility to same). Of course, any such alternative embodiment would still conform to the principles of the described invention.
• LinkedList 1 (LinkedList) session . getAttribute ("sessionStack”) ;
• StackElement se (StackElement) 1.getLast () ;
• buttonLabel + TableDescriptorDisplay .
• StringBuffer tableHelp new StringBuffer () ; while (displayFieldsEnumeration.hasMoreElements () ) ⁇
• EditTargetlFlag rs .getBoolean (3) ; rs .next () ;
• StringBuffer tableHeaders new StringBuffer () ;
• DataDictionaryTD ddtd dd. getDataDictionaryTD (tableName) ;
• Debug. doLog ("Pre search-string suffix: “+qStr, Debug. INFO) ; Debug. doLog ("Search string:
• Java .util . Date beginView null; if (Debug. areDebugging) ⁇
• topRow Math.min (Math. max (1, topRow), (rowCount - pageSize) +
• NAME newPageSize
• loopCellFlag EditTarget2Flag; ⁇ else if (targetTable .equals ( "EDIT_TARGET 1") SS cdd . getMode ( ) .
• abolish loopCellFlag BrowseTargetlFlag;
• loopCellFlag BrowseTarget2Flag; ⁇ if (canEditFlag SS loopCellFlag) ⁇
• Began DD getlnstance: ⁇ % df. format (beginDD) %> ⁇ br>
• Ended DD getlnstance: ⁇ % df. format (endDD) %> ⁇ p>
• Enumeration parameterNames request . getParameterNames () ;
• DataDictionaryTD ddtd dd. getDataDictionaryTD (tableName) ;

Landscapes

• Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Digital Computer Display Output (AREA)

Priority Applications (7)

Applications Claiming Priority (4)

Related Parent Applications (1)

Related Child Applications (1)

Publications (2)

Family

ID=26957949

Family Applications (1)

Country Status (4)

Cited By (14)

Families Citing this family (222)

Citations (1)

Family Cites Families (26)

• 2001
  • 2001-10-31 CA CA002427354A patent/CA2427354A1/en not_active Abandoned
  • 2001-10-31 WO PCT/US2001/042867 patent/WO2002059793A2/en active Application Filing
  • 2001-10-31 EP EP01994070A patent/EP1364313A2/en not_active Ceased
• 2003
  • 2003-04-30 US US10/428,209 patent/US7318066B2/en not_active Expired - Lifetime

Patent Citations (1)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events