DATABASE INTERFACE

RELATED APPLICATIONS

[001] This application claims priority from U.S. Provisional Application No. 61/318,453 filed March 29, 2010, which is hereby incorporated by reference in its entirety.

FIELD

[002] Embodiments described herein relate to systems and methods for providing and creating a graphical user interface (GUI) to a relational database.

BACKGROUND

[003] In relational database theory, a relationship between two tables is created by including a column (field) within the "child" table to store the primary key (or other candidate key) of its "parent" table. This column is referred to as the foreign key of the parent table. In each row, the stored value of the primary key is referred to as the primary id of the row and the stored values of any foreign keys are the row's foreign ids.

SUMMARY

[004] In a first aspect, a method is provided to create a graphical user interface to a relational database as a database interface system.

[005] In another aspect, a computer implemented method for creating a graphical user interface (GUI) to a relational database is provided. The method comprising: specifying a relationship between at least two tables; dynamically generating the GUI by creating layers of page frames according to the specified relationships; and displaying the GUI.

[006] In a preferred case, the GUI is organized into page frames comprising levels of structural blocks.

[007] In another case, the GUI comprises a browser based interface. [008] In another case, the database tables and fields are created or updated (modifying the table or field name, field data type, nullability and/or addition/removal of indexes) for the graphical user interface when a database is rebuilt by or through the embodiments as described in more detail herein.

[009] In another case, audit columns are automatically added to corresponding tables in the graphical user interface when a database is rebuilt by or through the embodiments as described in more detail herein.

[010] In another aspect, a non-transitory machine-readable memory is provided. In various embodiments the non-transitory machine-readable memory stores statements and instructions for execution by a processor for performing any of the methods described herein.

[011] In another aspect, a system is provided to create a graphical user interface to a relational database as a database interface system.

[012] In another aspect, a system for creating a graphical user interface (GUI) to a relational database is provided. The system comprises: a display; and a processor configured to: specify a relationship between at least two tables; and dynamically generate the GUI by creating layers of page frames according to the specified relationships; and display the GUI on the display.

[013] In a preferred case, the system further comprising an input device, wherein the relationships between the at least two tables are specified based on input provided to the input device.

[014] In another case, the display and the processor are distributed in an n-tier architecture.

[015] In another case, the GUI is organized into page frames comprising levels of structural blocks.

[016] In another case, the GUI comprises a browser based interface.

[017] In another case, the database tables and fields are created or updated (modifying the table or field name, field data type, nullability and/or addition/removal of indexes) for the GUI when a database is rebuilt by or through the embodiments as described in detail below. [018] In another case, audit columns are automatically added to corresponding tables in the GUI when the relational database is rebuilt by or through the embodiments described in detail below.

[019] In another aspect, a programming language is provided to create a graphical user interface to a relational database as a database interface system.

BRIEF DESCRIPTION OF DRAWINGS

[020] Embodiments will now be described, by way of example only, with reference to the attached Figures, wherein:

[021] Figure 1 illustrates a block diagram of a GUI creation system according to an embodiment;

[022] Figure 2 shows a chart with sixteen types of theoretical relationships in a relational database according to an embodiment;

[023] Figure 3 shows a page selection section controlling 30 pages of data according to an embodiment;

[024] Figure 4 shows a page selector fly-out according to an embodiment;

[025] Figure 5 shows a page frame according to an embodiment;

[026] Figure 6 shows the page frame of Figure 5 with the first row selected according to an embodiment;

[027] Figure 7 shows the page frame of Figure 5 where the first row is edited according to an embodiment;

[028] Figure 8 shows a table with a drilldown row according to an embodiment;

[029] Figure 9 shows a table with two S1 child tables in display mode according to an embodiment;

[030] Figure 10 shows a table with two S1 child tables in edit mode according to an embodiment;

[031] Figure 1 1 shows an S4 relationship according to an embodiment; [032] Figure 12 shows three states of an M-Table filter button according to an embodiment;

[033] Figure 13 shows an M-Table filter button's right-click menu according to an embodiment;

[034] Figure 14 shows the states of an M-Table status indicator according to an embodiment;

[035] Figure 15 shows an M1 relationship according to an embodiment;

[036] Figure 16 shows a field validation message according to an embodiment;

[037] Figure 17 shows a field verification message according to an embodiment;

[038] Figure 18 shows a delete verification message according to an embodiment;

[039] Figure 19 illustrates a property inheritance model according to an embodiment;

[040] Figure 20 illustrates an example of a reference display GUI according to an embodiment;

[041] Figure 21 illustrates an example of a reference edit GUI according to an embodiment;

[042] Figure 22 illustrates an example of the reference popup window according to an embodiment;

[043] Figure 23 illustrates an example of a change format button;

[044] Figure 24 illustrates an example of an edit button;

[045] Figure 25 illustrates an example of a show/hide record toggle button; and

[046] Figure 26 illustrates a flow chart diagram of the basic operational method executed by the system of Figure 1 . DETAILED DESCRIPTION

[047] It will be appreciated that numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Furthermore, this description is not to be considered as limiting the scope of the embodiments described herein in any way, but rather as merely describing the implementation of the various embodiments described herein.

[048] The embodiments of the systems and methods described herein may be implemented in hardware or a combination of hardware and software. Some embodiments can be implemented in software. Some embodiments are implemented in computer programs executing on programmable computers each comprising at least one processor, a data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. For example and without limitation, the programmable computers may be a personal computer, laptop, personal data assistant, a smartphone, and a cellular telephone. Program code is applied to input data to perform the functions described herein and generate output information. The output information is applied to one or more output devices, in known fashion.

[049] Each program is preferably implemented in a high level procedural or object oriented programming and/or scripting language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Each such computer program is preferably stored on a storage media or a device (e.g. ROM or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The inventive system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.

[050] Furthermore, the system, processes and methods of the described embodiments are capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions for one or more processors. In various embodiments the computer readable medium is a physical computer readable medium. In some embodiments the computer readable medium is a non-transitory computer readable medium. In some embodiments, the medium may be provided in various forms, including one or more diskettes, compact disks, tapes, chips, wireline transmissions, satellite transmissions, internet transmission or downloadings, magnetic and electronic storage media, digital and analog signals, and the like. The computer useable instructions may also be in various forms, including compiled and non-compiled code.

[051] Some embodiments described herein relate to systems and methods for providing and creating a graphical user interface (GUI) to a relational database. Some embodiments described herein relate to a programming language that is used to create a graphical user interface (GUI) to a relational database. In particular, the programming language introduces concepts of the relational interface and the relational interface development language.

[052] In a relational interface, the organization of the graphical user interface (GUI) reflects the established relationships within the database. A relational interface development language is a programming language that enables the programmer to create a relational interface.

[053] Some embodiments relate to a system for creating a GUI to a relational database. An example embodiment is illustrated in Figure 1 , which is a block diagram of GUI creation system 100. GUI creation system 100 comprises a processor 1 10, a storage medium 120, an output device 130 and an input device 140. In various embodiments, storage medium 120 is a non- transitory storage medium. In various embodiments storage medium 120 is utilized to store data for use in a relational database as described in greater detail below. Output device 130 can be any appropriate output device such as for example, but not limited to, an LCD monitor. Input device 140 can be any appropriate user input device such as for example, but not limited to, a key board. Some embodiments utilize devices that combine input and output functions such as a touch screen. Processor 1 10 is utilized to execute computer executable instructions, which may be for example stored on storage medium 120, for the creation of a GUI that is displayed on output device 130. In some embodiments, the instructions executed by processor 1 10 can be stored on a storage medium other than storage medium 120.

[054] It should be understood that in various embodiments system 100 is not implemented as a single computing device. In particular, in various embodiments, the elements of system 100 are distributed in a multi-tier (or n- tier) architecture. Accordingly, monitor 130 and input device 140 may be part of computing device that interacts in a client server manner with on more computing devices that include processor 1 10 and storage medium 120.

[055] As shown in Figure 2, there are 16 different types of relationships which can be established between tables (entities). Various embodiments described herein support all relationship types in which the child table has only one parent table. In the case of a child table with multiple parent tables, various embodiments described herein support the three relationship types which do not specify a minimum number of child records for each unique combination of parent records.

[056] Relationship types S2, S4, S6, S7 and S8 are supported by ensuring that new parent records are not created without also creating the specified minimum number of required child records.

[057] In order to support relationship types M2, M4. M6, M7 and M8, any new record created in parent table A would require a new child record (X new child records for cases M7 and M8) in table C for every existing record in parent table B. All the new required C records would have to be created before the new A record could be saved. These theoretical relationships are not practical and therefore not supported in some of the embodiments that are described herein.

[058] Relationship Types:

(a) Single-Parent Relationships

The child table in an S1 - S8 relation has a single parent table. CD S1

Each record in the parent table has 0 or 1 record in the child table.

Tables with this type of relationship can be used to create optional groups of data within records.

(11) S2

Each parent record has 1 record in the child table.

Tables with this type of relationship can be used to create physically separate groups of data within records.

(iii) S3

Each parent record has 0 or more records in the child table.

Each parent record has 1 or more records in the child table. (v) S5

Each parent record has between 0 and Y records in the child table, where Y > 1 .

(vi) S6

Each parent record has between 1 and Y records in the child table, where Y > 1 .

(vii) S7

Each parent record has between X and Y records in the child table, where X > 1 and Y >= X.

(viii) S8

Each parent record has X or more records in the child table, where X > 1 (b) Multiple-Parent Relationships

The child table in an M 1 - M8 relationship has two or more parent tables.

(i) M1

Each unique combination of parent records has 0 or 1 records in the child table. (ii) M2

Each unique combination of parent records has 1 record in the child table. This type of relationship is not supported in various embodiments.

(iii) M3

Each unique combination of parent records has 0 or more records in the child table.

(iv) M4

Each unique combination of parent records has 1 or more records in the child table. This type of relationship is not supported in various embodiments.

(v) M5

Each unique combination of parent records has between 0 and Y records in the child table, where Y > 1 .

(vi) M6

Each unique combination of parent records has between 1 and Y records in the child table, where Y > 1 . This type of relationship is not supported in various embodiments.

(vii) M7

Each unique combination of parent records has between X and Y records in the child table, where X > 1 and Y >= X. This type of relationship is not supported in various embodiments. (viii) M8

Each unique combination of parent records has X or more records in the child table, where X > 1 . This type of relationship is not supported in various embodiments.

[059] Nomenclature: For the purposes of this application, an S1 table is defined as the child table of an S1 relationship, etc. An S1 row or record is defined as the row in the child table where the foreign id matches the primary id of the row in the parent table, etc. A Foreign table is any parent table of a relationship. A table's relational tree refers to the collection of tables including the table itself and all its ancestor tables (all parent tables and their parent tables, etc.). A table's relational parents are all the tables in its relational tree except for the table itself.

[060] GUI Organization: The GUI described herein is organized into levels of structural blocks called page frames. The tables included in the topmost page frame are either (1 ) all of the tables in the application, (2) only those tables which do not have parent tables, (3) all the tables from option (2) plus a manual selection of tables, or (4) a manual selection of tables. Tables in subsequent page frames are dependent on the tables of the previous levels.

[061] Page Frames: A page frame consists of several distinct sections.

[062] Table Selection Section: The table selection section is the part of the page frame interface that enables the user to select one table from amongst a list of tables. Various embodiments described herein implement this section as a group of tabs which look similar to the tabs on a file folder. This section could also be implemented as a group of radio buttons, a select list (drop-down list) or any other type of pick-one list. Each tab or item in the list displays the table's caption and represents a page of the page frame. Each page has its own Table Data and Page Selection section. Clicking or otherwise selecting a tab (item) in the group (list) switches the display of the Table Data and Page Selection section to that of the selected page. The active page of the page frame is the currently selected page.

[063] Toolbar Section: This section provides access to the high-level functions of the GUI. Each tool consists of a clickable icon (which could also be a button) and optional tooltip text. The tools provide access to essential functions of the GUI such as Create New Record, Copy Existing Record, Save Changes, Cancel Changes and Delete Selected Record. Edit Selected Record could also be included here; in various embodiments described herein the selected record is edited by simply clicking on it. Each tool functions within the context of the active page. The toolbar can also provide access to other important but less-essential functions of the interface. Many of the functions exposed on the toolbar have keyboard shortcuts, for example Ctrl+S is a shortcut to Save Changes.

[064] Table Data Section: This section provides access to the data of one or more tables in the database. The criteria used to determine which tables are included in a particular page will be discussed later. Each page has one primary table which consists of required inline fields and optional drilldown fields. The data of the inline fields of the page's primary table are displayed in a grid of inline rows and columns in the order in which the developer added them to the interface. The field caption is displayed above each inline column in the grid. Clicking on the inline field caption sorts the data by that column in ascending order; clicking the column again will resort the data in descending order. If the main table has any drilldown fields, they are displayed in a separate drilldown row which is only displayed for the selected record, pinned records and for any records which are in edit mode. In contrast to the grid format of the inline row, the fields of the drilldown row float within the row container. The fields float from the top-left of the container in the order in which the developer added them to the interface. A record's drilldown row appears immediately below its inline row. The fields of any supplemental tables (S1 , S2, M 1 or Foreign tables) are always drilldown fields and each supplemental table has its own drilldown row which is only displayed for the selected primary table record, pinned records and for any records of the supplemental table which are in edit mode. A table with a drilldown row is shown in Figure 8. Unlike the primary table drilldown rows, the table caption of the supplemental table appears to the left side of its drilldown rows. In the display mode of the drilldown row the field caption of each field is displayed in bold text to the left of the field value. If the field value is empty then its caption is displayed in a light grey font colour.

[065] The inline rows are alternately highlighted in translucent yellow and translucent white. Clicking on an inline row selects the row and displays any associated drilldown rows for the record. The selected row (including any drilldown rows) is highlighted in translucent red. Clicking on a selected row or pressing the Enter key will switch the record from display mode to edit mode. In display mode none of the row data can be modified. In edit mode each field has its own control for modifying its data. There are several different field types the developer may choose from when developing their application and the edit controls for each field type are specific to the type of data it stores. The properties and functions of each of these field types are beyond the scope of this document.

[066] Pinned Records: A row of the data table is pinned by selecting the record and then clicking on the Pin Record toolbar button. The drilldown rows of a pinned record stay in place when the selected record changes. The row colouring of a pinned record (including any drilldown rows) follows the alternating translucent yellow / translucent white scheme. A record is unpinned by selecting it and then clicking on the Unpin Record toolbar button. All the pinned records in a data table can be unpinned simultaneously by right- clicking the Pin Record / Unpin Record toolbar button and selecting Unpin All Records from the context-sensitive menu.

[067] Page Selection Section: The number of rows displayed in the table section is a property the developer can modify. The default is 15 rows which will be used for this discussion. The data is sorted by the field(s) the developer specifies or which the user selects. The number of rows available in the dataset is affected by any filters the developer or user may have defined. The first page displays the first 15 results; the second page displays results 16 - 30 and so on. The last page of data may display less than 15 rows. As shown in Figure 3, the page selection section displays one or more page selectors (clickable numbers) which represent pages in the dataset. Clicking on the page selector retrieves and displays the specified page of data and also highlights the text of the page selector. Clicking on the current (highlighted) page selector will requery the page data and refresh the page. In large data sets a method is used to reduce the number of pages displayed in the page selector. Whenever this paring method is implemented a page selector fly-out is displayed. When clicked, the page selector fly-out displays a textbox with which the user can enter a specific page to display, as shown in Figure 4.

[068] Page Frame Participation: A page frame is shown in Figure 5. Figure 6 shows the page frame of Figure 5 with the first row selected. Figure 7 shows the page frame of Figure 5 with the first row selected for editing. The placement of a table within the GUI is dependent upon the type of relationship established with its parent(s) as defined in Figure 2. The developer can choose to include in the topmost page frame (1 ) all of the tables in the application, (2) only those tables which do not have parent tables, (3) all the tables from option (2) plus a manual selection of tables, or (4) a manual selection of tables. The end-user may also have the ability to change (add or remove from the developer's selection) which tables are included in the topmost page frame. Each tab (page) of a page frame has its own child page frame; the child page frame is only displayed when a record is selected in the parent tab's primary table. Since only one tab of a page frame can be active at any time, only the active tab's child page frame will ever be displayed in the child page frame level. In various embodiments described herein, the child page frame is always displayed immediately beneath the parent page frame. The child page frame could also be displayed above the parent page frame or to the left or right of it. In any scenario, the child page frame is only displayed when a record has been selected from the main table of its parent tab in the parent page frame. The tables included in the child page frame are determined by a method which examines the relationships defined between the application's tables. If the method does not identify any tables for participation in the tab's child page frame then the child page frame is never displayed. The records displayed for the data tables of each page are retrieved by dynamically generated SQL statements which are constrained by the foreign ids established through the relationships involving the parent page frame(s).

[069] Filtered Tables: The developer may choose to filter any table out of the application. A table may be filtered (1 ) to test alternate configurations, (2) because the user is not permitted to view the table or (3) for any other reason. There may also be tables in the database which the developer can choose not to include in the application. The application will render the interface as if the filtered tables did not exist.

[070] Page Frame Participation Method: The page frame participation method determines which tables to include in a child page frame based on the tables of a parent tab.

[071] Committed Tables: The committed tables are a list of every participating table in all the parent tabs.

[072] Uncommitted Relational Parents: A table's uncommitted relational parents are a list of all its relational parents which are not already committed.

[073] Primary Tables: Every primary table in the page frame will have its own page in the page frame. The method examines the relational tree of every uncommitted table in the application. To participate in the page frame, at least one of the table's relational parents must participate in the parent page. If the table's relational parents participate in more than one parent page, they must be consecutive pages starting from the immediate parent page and working up to the active page of the topmost page frame. All the uncommitted relational parents of each participating table will also participate as a primary table in the page frame.

[074] Filtering S1 , S2 & M1 Tables: The developer can choose to omit from primary table page frame participation (1 ) all S1 and S2 tables, (2) all M1 tables, (3) all S1 , S2 and M1 tables, (4) any of (1 ), (2) or (3) plus a manual selection of S1 , S2 or M1 tables or (5) a manual selection of S1 , S2 or M 1 tables. Filtering an S1/S2/M1 table from primary table page frame participation will neither affect its participation as a supplemental table of any page nor will it prevent the page frame participation of any of its uncommitted parents, although any of the uncommitted parents may also be filtered out if they themselves are an S1 , S2 or M1 table which matches the filter criteria. The end-user may also have the ability to change (add or remove from the developer's selection) which S1/S2/M 1 tables are filtered from primary table page frame participation. [075] Supplemental Tables: Each page of the page frame is now examined for more tables to participate in the page.

[076] Foreign Tables: All of the primary table's uncommitted relational parents will participate as a foreign table of the page.

[077] S1 , S2 & M1 Tables: The method examines the relational tree of every uncommitted S1 , S2 and M1 table in the application. If all of the S1 /S2/M1 table's parent tables are committed or participate in the page then the relationship's child table will also participate in the page. The page participation used for this part of the method is dynamic. Initially it includes the primary table and all foreign tables. Each S1 , S2 and M1 table that is identified for participation in the page is added to the list before examining the next table's relational tree. The tables are examined in the order in which the developer added them to the application. Since the application will not allow a developer to add a child table before its parent table(s) have been added, the method is ensured of pulling into the page participation any S1 , S2 or M1 tables that are themselves a child of another S1 , S2 or M1 table.

[078] Alternate Implementation: The supplemental tables could each be rendered as a primary table in the child page frame of their primary table's tab. Including them within their primary table's page has the advantage of being more user-friendly.

[079] The GUI

[080] S1 & S2 Tables: The child record of an S1 or S2 relationship is displayed immediately beneath its parent record. The S1/S2 row only appears when its parent row is selected or is in edit mode. If more than one S1 or S2 relationship exists, the records are displayed in the order the developer added the tables to the application. If a child record does not exist in the database then no row is displayed in display mode. S1/S2 rows are edited in conjunction with their parent row and are always displayed in edit mode. In display mode, an S1 row can be deleted by clicking on the delete icon to the left of the S1 row. In edit mode, any changes to the row can be cleared by clicking on the cancel changes icon which takes the place of the display mode delete icon. The S1 edit row will still be displayed after clicking the cancel changes icon. Since an S2 row is required, no delete or cancel icons are displayed for it.

[081] In Figure 9, the Transactions table has two child S1 tables, Disability and Ambulance. The selected Transaction record does not have a child record in the Ambulance table, so no row appears for the Ambulance table in the display mode of the row. When the Transaction row is switched to edit mode, (by clicking on any field of the Transaction row or the Disability row), the Ambulance row is displayed, as shown in Figure 10.

[082] S3 - S8 Tables: Each participating S3 - S8 table will have its own tab of which it is the primary table. Figure 1 1 shows an example of an S4 relationship.

[083] M1 & Foreign Tables: The GUI representation of M1 and Foreign tables is similar to that of S1 and S2 tables but unlike the S1 and S2 rows, the M1 and Foreign rows can be edited and deleted independently of their primary row. The Foreign tables will have fields that are defined as inline (when the table is accessed as the primary table of a page) but these inline fields will appear as drilldown fields in the Foreign row. In display mode, an M1 or Foreign row can be deleted by clicking on the delete icon to the left of the row. In edit mode, the cancel changes icon takes the place of the display mode delete icon. Clicking on the cancel changes icon will discard any changes made to the row data and switch the row to display mode. Deleting a Foreign row will also delete its primary row and any other primary row on the page that is a child of that Foreign row.

[084] M-Table Filter Button: When one or more M tables have a relational parent participating in the page, the leftmost column of the data grid's header row displays an M-Table filter button. The states and meanings of the M-Table filter button are illustrated and explained in Figure 12.

[085] When the M-Table filter button controls the filtering of two or more M-Tables, a right-click menu becomes available on the M-Table filter button. Figure 13 shows an example of an M-Table filter button's right-click menu. Selecting a table from the right-click menu will display only those primary rows with an existing row in the participating relational parent table of the selected M-Table and the M-Table filter button then displays a gray checkmark.

[086] M-Table Status Indicator: An M-Table status indicator appears in the leftmost column of each primary row when one or more M-Tables have a relational parent participating in the page. The states and meanings of the M- Table status indicator are explained Figure 14.

[087] Figure 15 shows an example of an M1 relationship, where the Patient Policy table is the M1 child of the Patient table and the Insurance Policy table. The M-Table status indicator includes a button only when there are one or more participating M1 tables on the page and one or more M1 rows are missing from the primary row. The main purpose of the button is to provide a method for the user to add the missing M1 rows. Clicking on the M- Table status indicator button will display every missing M1 row in edit mode. If all missing M1 rows are displayed in edit mode then clicking on the M-Table status indicator button will hide all of these new rows. If only some of the missing M1 rows are displayed in edit mode then clicking on the M1 status button will display all the other missing M1 rows in edit mode.

[088] M3 & M5 Tables Each participating M3 & M5 table will have its own tab of which it is the primary table.

[089] Order of Appearance: The order in which the parts of a selected row are displayed is as follows:

1. The inline row of the tab's primary table

2. The drilldown row of the tab's primary table

3. S1 & S2 child rows of the primary table

4. Foreign rows + their S1 & S2 child rows

5. M1 rows + their S1 & S2 child rows

[090] Within sections 3, 4 & 5 of the row, the tables appear in the order in which the developer added them to the application. S1 & S2 rows always appear immediately beneath their parent row. If a parent row has more than one S1 or S2 child rows, they all appear immediately beneath their parent row in the order in which the developer added them to the application.

[091] Editing Multiple Records: Any displayed row on the page (primary, Foreign, S1 , S2 or M1 ) can be edited in conjunction with any other row on the page. S1 and S2 rows are always edited in conjunction with their parent row. The tables of only one page of any of the application's page frames can be edited at any time, unless new primary rows are being added to a table (see below). Regardless of how many rows are being edited, only one row will ever be selected at any time. The tab's child page frame always displays the child records of the selected parent row.

[092] Adding New Primary Rows to a Table: When new rows are added to a primary table, new rows can also be added to any primary tables participating in the tab's child page frame. This provision extends to all the descendant tables of the initial primary table. Relationship types S4, S6, S7 & S8 require this capacity in that each of these relationships requires one or more child record for each parent record. If the primary table is an S5, S6 or S7 table and the maximum number of allowed records already exist, the user is informed and no new record is added.

[093] Saving Changes: All the changes made in every open edit row on the page (and its descendant page frames in the case of new records) are saved together by clicking the save tool in the toolbar or pressing Ctrl+S. Before the changes are committed to the database the changes are validated and verified.

[094] Validations and Verifications: The developer may specify a validation and / or verification function for each field in the application. These functions are called when changes are saved. The naming conventions [table name]_[field name]_validate and [table name]_[field name]_verify are used for the names of these functions.

[095] Field Message Area: Validation / verification messages are displayed in an area immediately below an inline field and to the right of a drilldown field. [096] Each validation / verification function is passed the following five parameters:

name":{"field name":"field value", ... }, ...}

[097] If the developer passes back a non-empty string from a validation / verification function, the text is displayed in the field message area, the field fails validation / verification and the record is not saved. If no validation / verification function exists for the field then it passes validation / verification. If a field fails validation, its value (or possibly the value of another field in the row) must be adjusted before the save will succeed. A field validation message is shown in Figure 16. In the case of a verification message, as shown for example in Figure 17, the user may choose to proceed with the save without changing the data or they may cancel the save and make changes first. Validations are displayed in a red block of the GUI while verifications are displayed in an orange block.

[098] If the user attempts to save a new S4, S6, S7 or S8 parent record without also creating the required number of child records, a validation message is displayed and the save is cancelled. If the user is adding new S5, S6 or S7 records to an existing parent record, the database is checked to ensure the total number of child records will not exceed the allowed number; if it will, a validation message is displayed and the save is cancelled.

[099] Deleting Records: The developer may specify a row delete validation function for each table. The naming convention [table nam e]_row_validate Delete is used for the names of these functions.

[0100] Each delete validation function is passed the following four parameters:

[0101] If the developer passes back a non-empty string from a row validate delete function, the delete fails validation, the user is informed and the delete is cancelled.

[0102] If the delete passes validation and the number of non-S1/S2 child records is > 0 (parameter 3), the user is informed of the number of child records they are about to delete and they must confirm the delete before it is executed. A delete verification message is shown in Figure 18. [0103] Reference Fields

[0104] In many cases, it is desirable to incorporate data from a foreign table within the child data table itself. A classic example is an order tracking database consisting of three data tables: "orders", "order items" and "products". In this database, "order items" has both "orders" and "products" as foreign tables. It makes sense to follow the description of paragraph entitled "S3 - S8 Tables" and display the order items in the page frame following orders but if only the description of paragraph entitled "M1 & Foreign Tables" is followed for the product, then the product name would not be displayed until a row is selected. In this example, the interface would be much more user- friendly if the product name is a field in the inline row. In other scenarios, the foreign information is better suited to placement in the data table's drilldown row. The functionality of including information from one data table within the inline or drilldown row of another data table is provided by the reference field.

[0105] Nomenclature

[0106] A reference field is a field in the data table which displays a string representation of one or more fields from a foreign data table within the inline or drilldown row of the reference field's data table. A reference field can be any field in a data table other than the data table's primary key or one of its foreign keys.

[0107] The referenced fields of the reference field refers to the list of fields from the foreign, referenced data table.

[0108] The child data table of a referenced data table is the data table which contains the reference field.

[0109] Adding a Reference Field to the GUI

[0110] A reference field is appended to a data table by its .appendReference or .appendDrilldownReference function. The new reference field will be appended to the data table's inline or drilldown fields, respectively. [0111] Specification

0112] A reference field is specified by the following parameters:

[0113] Pa ra mete r N otes

[0114] Parameter 1 - Physical Field Name: FNFDA refers to a Field Name or Field Definition Array (FDA). A field name is specified by a string whereas a field definition array is specified by an array in the form ["field name'V'data type",{options}] or [["field name'V'old field name"], "data type", {options}]. A field definition array is used when (re)building the database with some of the embodiments described herein. The first form of the array is used when creating a database table, adding a field to an existing database table or changing the data type of a field in an existing database table. The second form of the array is only used when renaming a field in an existing database table. The options available for the third parameter of the FDA are:

[0115] Parameter 2 - Field Caption: A string value or an array of two string values is required. If the specified value (or first parameter of an array) is non-string then the field name will be used as the caption. If the field name is desired as the field caption then undefined should be specified as the field caption. If there is no suitable caption for the field, then an empty string ("") should be specified. The normal format of the field GUI is to display the field caption and then the field value or edit elements in the format Field Caption: [Field Value / Edit Elements]. If the field value and edit elements should be displayed within the field caption, then specify the location of the field value / edit elements with "[— ]" as in "Field Caption Before [— ] Field Caption After".

[0116] The developer may choose to include a field in a grouped collection of fields in either the inline or drilldown portion of a row. An array of two strings should be specified for any field that is part of an inline or drilldown group. The first parameter of the array is used within the GUI of the display and edit rows while the second parameter is used everywhere else when referring to the field. For example, consider the field "hphone" which is part of a group named "Phone Numbers". The proper field caption array for this field would be ["Home", "Home Phone Number"].

[0117] Parameter 5 - Optional Properties

[0118] The property inheritance model is illustrated in Figure 19.

[0119] The default value of each property is the initial value set by various embodiments in app. properties. dataTables.fields.reference{properties}. The developer can override these default values and set new default values for every reference field in the entire application. Each data table in the GUI inherits .properties.fields.reference{properties} from app. properties. dataTables.fields.reference{properties}. The developer can override these inherited values and set new default values for every reference field appended to the specific data table. Each reference field in the GUI inherits .properties from its data table's .properties.fields.reference{properties}. The developer can override these inherited values for each individual reference field.

[0120] ■type

[0121] .ignoreCase: Only applies to reference fields of type "quickpop" or type "quickpick". This property specifies whether or not the search of existing items should respect the case of the user-entered text.

[0122] .inputSize: This property specifies the width (in number of characters to display) of the field's edit input.

[0123] .isRequired: If the field's database column does not allow nulls then .isRequired is true, otherwise .isRequired is inherited. If .isRequired is true, the user will be forced to select a value before the record can be saved.

[0124] .isSortable: If .isSortable is true and the field is inline, the user can sort the data by clicking on the field's header cell. For both inline and drilldown fields, sortable columns are listed in the data table's sort dialog.

[0125] .isUnique: If .isUnique is true, the field value must be unique to the database table, within the current foreign ids (entire database table if the data table does not have foreign keys); the user will not be able to save the record if another record exists with the same value.

[0126] Reference Field GUI

[0127] The reference field displays a string representing a row selected from another data table. The displayed string is calculated by passing the referenced fields from the referenced table to the field's data-driven format function(s).

[0128] When using a reference field with .type = "quickpop" or .type="quickpick", one or more data-driven format functions can be used with the field; when .type = "poptable" only one data-driven format function may be used.

[0129] When using only one data-driven format function, the naming convention [data table name]_[field name]_format must be used.

[0130] For multiple data-driven format functions, the functions must be consecutively numbered starting with 0 and following the naming convention [data table name]_[field name]_format[N].

[0131] Multiple data-driven format functions are used for enabling quickpick searches of the referenced table by different orders of the referenced fields; left- clicking on the change format button (Figure 23) cycles through the formats while right-clicking on the button displays a context menu of all the formats.

[0132] When using multiple data-driven format functions, the displayed value of the field is calculated using the first (N = 0) function. Table 1 lists examples of single and multiple data-driven format functions.

[0133] If no data-driven function exists for the field, the displayed value will be the referenced field values concatenated with a space.

[0134] Clicking the edit button (Figure 24) of the reference field edit GUI will pop up the referenced table in a modal dialog. The user may change the referenced record by choosing a record in the modal dialog and pressing the Select button.

[0135] The modal dialog contains one page of a page frame without a tab. The tables participating in the modal dialog's page include the referenced table and any S1/S2/foreign table(s) to the referenced table. The modal dialog's page does not spawn a child page frame even if the referenced data table would normally spawn a child page frame.

[0136] All of the normal table functions including CRUD (create, update and delete) are available to the user for the table(s) in the popup modal dialog.

[0137] Reference fields of the tables in the modal dialog may themselves spawn additional modal dialogs. Each spawned modal dialog is organized into a separate layer of the GUI with no access to the layer beneath it. A translucent div element provides the physical boundary between layers enabling the user to see the data of lower levels put preventing access to that data until the modal dialog is closed.

[0138] If the developer does not specify a data-driven format function, various embodiments described herein will use a concatenation of the values of the referenced fields with a separator of a single space (" ").

[0139] An example of the reference display GUI is shown in Figure 20.

[0140] An example of the reference edit GUI is shown in Figure 21 .

[0141] An example of the reference popup window is shown in Figure 22.

[0142] Reference Field Data-Driven Format Function

[0143] The data-driven functions are developer-created functions which are named following precise naming conventions. The naming convention for the reference field's format data-driven function is

[data table name]_[field name]_format or [data table name]_[field name]_format[N].

[0144] The parameters and return value of the format data-driven function are as follows:

[0145] Examples:

{return t + " " + (u?u + ". ":"") + s;}

TABLE 1 EXAMPLES OF THE REFERENCE FIELD'S DATA-DRIVEN FORMAT FUNCTION [0146] Relational Effect of Reference Fields

[0147] Each reference field links a field of its data table to the primary key of a foreign table, establishing an S3 relationship from the referenced data table (parent) to the reference field's data table (child).

[0148] Referenced Record as a Foreign Table in the GUI: When included as a foreign table of a page (as per the paragraph entitled "Foreign Tables"), the GUI of a referenced record follows the paragraph entitled "M1 & Foreign Tables" with the exception that the record is initially hidden from view. The display of the referenced record is toggled by clicking on the show / hide record toggle button (Figure 25) of the related reference field. Any foreign records to the referenced record are initially displayed; their display can be toggled with their reference field's show/hide record toggle button. Alternate implementations here include (1 ) referenced records being initially displayed, (2) toggling the display of foreign records to the referenced record along with the referenced record and (3) both (1 ) and (2).

[0149] Page Frame Participation: A referenced data table will participate in the page frame participation method of the paragraph entitled "Primary Tables" only if it does not appear in the relational pillar of its child data table. If the referenced data table does participate in the page frame participation method, the referenced data table is treated as an uncommitted relational parent in the method of the paragraph entitled "Primary Tables".

[0150] Relational Pillars: A relational pillar is a group of interrelated data tables in an application. Each application will have one or more relational pillars. The following steps are used to calculate the relational pillars of an application: 1. Collect a list of relational trees of data tables which do not have any child tables.

2. Combine any items with intersecting relational trees.

3. Each item (group of tables) in the list is a relational pillar of the application. [0151] Clone-Spawning Reference Fields: If a referenced data table appears within its child table's relational pillar then a clone of the relational pillar will be created. The fourth step in the method of the paragraph entitled "Relational Pillars" is to (1 ) set a flag for each reference field in the data tables of each relational pillar indicating whether or not it is a clone-spawning reference field and (2) set a pointer to its relational pillar.

[0152] Inclusion of Non-Clone-Spawning Reference Fields in the Relational Pillars: The fifth step in the method of the paragraph entitled "Relational Pillars" is to add the relational tree of the referenced table of any non- clone-spawning reference field to its relational pillar. When a relational pillar is cloned, the non-clone spawning reference fields in the cloned relational pillar will reference a table in the cloned relational pillar.

[0153] Clone-Linking Relationship: The sole link between a relational pillar and its clone is an S3 relationship between the reference field's referenced data table and the clone of the reference field's data table from the primary key of the referenced data table to the reference field in the clone of the reference field's data table.

[0154] Self-Referenced Reference Fields: A self-referenced reference field is a reference field which specifies its own data table as its referenced data table. A self-referenced reference field is always a clone-spawning reference field.

[0155] Clone Naming: Each data table in the clone of the relational pillar is assigned a unique table name in the application.

[0156] The new name is a concatenation of the original name and an iterative counter. If another data table exists in the application with the same name as the new name then the counter is incremented and the process repeated until a unique name is found. [0157] Tab Caption: In order to uniquely identify the clone of the reference field's data table to the user, the caption of the cloned data table's page frame tab follows the naming convention "[data table caption]: [reference field caption] [reference field's formatted display value]". For example, in an "employee" data table (caption "Employees") containing the self-referenced reference field "reportsTo" (caption "Reports To"), the page frame tab caption of the clone of the employee data table is "Employees: Reports To " + [reference field's formatted display value]. The "Employees: Reports To" part of the caption is static while the reference field's formatted display value will differ for each record in the original "employee" data table. If the referenced fields parameter (parameter 4) of the reference field is ["salutation", "firstName","lastName"] with field values ["Dr.","Leonard","McCoy"], respectively in the original "employee" data table, then the page frame tab caption for the clone of "employee" data table will be "Employees: Reports To Dr. Leonard McCoy" for that referenced record. Note that for this example since no data- driven format function is specified, the reference field's formatted display value is simply a space-delimited concatenation of the values of the referenced fields.

[0158] Timing of Clone Creation: When the application is launched, the only data table that is cloned is the reference field's data table. Clones of all the other data tables in the relational pillar are made only if (1 ) the user clicks on the page frame tab of the clone of the reference field's data table or (2) if the clone of the reference field's data table is the first or only primary data table in its page frame, then the copies are made when the user selects a record in the reference field's referenced data table.

[0159] Delaying the bulk of the data table cloning serves to speed up application launch following just-in-time programming practices and also prevents what would otherwise be a race condition with endless propagation of clones of relational pillars.

[0160] Clones' Foreign Keys: Once the cloned table has been assigned a new name, its foreign tables are scanned and each foreign table's name (pointer) is replaced with the name of the foreign table's clone in the cloned relational pillar.

The reference fields of the data table are then scanned and the names of the referenced tables are likewise replaced with the name of the referenced table's clone in the cloned relational pillar.

[0161] The cloned data tables are processed in the order in which the developer added them to the application to ensure that a cloned data table will always be renamed before any relational pointers to itself are encountered in the method of the paragraph entitled "Clones' Foreign Keys"..

[0162] The method of the paragraph entitled "Clones' Foreign Keys" does not include the clone-linking relationship established in the paragraph entitled "Clone-Linking Relationship". The reference field in the clone of the reference field's data table retains this pointer to the referenced data table in the original relational pillar.

[0163] Multiple layers of cloned relational pillars are possible with the number of clones limited only by how deeply the user navigates the GUI following the steps outlined in the paragraph entitled "Timing of Clone Creation".

[0164] Clone-Linked Boundary: The single S3 relationship established between the reference field's referenced data table and the clone of the reference field's data table by the clone-spawning reference field is the only relationship between these two data tables. This relationship serves as a boundary (clone- linked boundary) between the original relational pillar and its clone.

[0165] In the GUI, the clone-linked boundary separates the original relational pillar from its clone. The data tables of the cloned relational pillar only participate in the page frame participation method of the paragraph entitled "Page Frame Participation Method" in descendant page frames of the reference field's referenced data table.

[0166] When some embodiments described herein create SQL statements to retrieve the various data for a page of a page frame involving the cloned relational pillar, the clone-linked boundary is never crossed with the single exception of the one S3 relationship between the original clone-linking data table and the clone of the clone-linking data table. In other words, any foreign ids that have been set by selecting records in the data tables of the original relational pillar do not apply to the SQL statements created for the data tables of the cloned relational pillar with the exception of the foreign id from the clone-spawning reference field in the original clone-linking data table to the primary key of the cloned clone-linking data table.

[0167] The S3 relationship between the reference field's referenced data table and the clone of the reference field's data table serves as a link between a relational pillar and its clone. For the first clone, the link is to the group of original data tables. For the second clone, the link is between the second and first clones of the relational pillar (not to the original relational pillar).

[0168] Reference is now made to Figure 26, which is a flowchart diagram illustrating the basic method performed by system 100 of Figure 1 . At 210, relationships are specified between tables. In various embodiments, the relationships are specified by a developer. In various embodiments, a relationship between at least two tables is specified.

[0169] At 220, a graphical user interface is dynamically generated by creating layers of page frames according to the specified relationships.

[0170] At 230, the GUI is displayed. In various embodiments, the GUI is displayed on monitor 130 of system 100.

[0171] It should be understood that in various embodiments, the creation of the graphical user interface is dynamic. Accordingly, as relationships are specified the GUI is updated displayed dynamically.

[0172] The above-described embodiments are intended to be examples only. Those of skill in the art can effect alterations, modifications and variations without departing from the scope.

[0173] Although this disclosure has described and illustrated certain embodiments, it is also to be understood that the system, apparatus and method described is not restricted to these particular embodiments. Rather, it is understood that all embodiments which are functional or mechanical equivalents of the specific embodiments and features that have been described and illustrated herein are included. [0174] It will be understood that, although various features have been described with respect to one or another of the embodiments, the various features and embodiments may be combined or used in conjunction with other features and embodiments as described and illustrated herein.