Systems and methods for accessing a database management system

Disclosed is a method of accessing a network of relationship instances and data field values of entity instances in a combined entity relationship- and relational-model database management system. The method comprises the steps of receiving a query that natively references relationship types including data fields to be accessed; parsing the query into a parse tree; converting the parse tree to a query graph; optimising the query graph by consolidating equivalent nodes in the query graph; analysing the nodes in the optimised query graph; codifying each node of the optimised query graph into a first table of state transition rules; codifying the data fields to be accessed into a second table of field rules; preparing a query that includes the first and second tables; identifying entity instances to be accessed by the prepared query by iteratively following relationship instances according to the first table; and loading data fields of the identified entity instances according to the second table.

This application is a National Stage Patent Application of PCT/AU2017/000186, filed on Sep. 6, 2017, which claims the benefit of priority to Australian Patent Application No. 2016231506, filed on Sep. 20, 2016, the disclosures of all of which are incorporated by reference herein in their entireties.

TECHNICAL FIELD

The present invention relates generally to databases and, in particular, to a query language for a database management system having a combined entity-relationship and relational data model.

BACKGROUND

A database management system with a combined entity-relationship (ER) and relational data model typically has performance issues as well as maintenance overhead when acquiring data fields from the database management system.

A query language is typically used to access the data fields from the database management system by first specifying a root entity instance and a network of relationship types that should be followed to one or more target entities to acquire the requested data fields from the target entities. A problem, however, arises when the queries are complex because, when each relationship type is followed, there are multiple relationship type paths leading to each target entity type, resulting in a large amount of duplicate data fields being accessed.

One alternative option for the query language is to query the set of data fields of an entity instance and relationship types individually in order to determine the exact set of data fields and relationship types to access on target entities. However, the alternative option requires multiple queries to the database server, which negatively impacts on performance substantially.

Thus, a need exists for a query language, and a system and method for the processing and execution of those queries, that enables for simpler queries and more efficient processing.

SUMMARY

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. We present the term ReadiNow Intelligent Engines (RIE) to refer to the introduced technology.

According to a first aspect of the present disclosure, there is provided a method of accessing a network of relationship instances and data field values of a group of entity instances in a combined entity relationship- and relational-model database management system, the method comprising the steps of: receiving a query text that natively references relationship types including the network of relationship types and data fields to be accessed; parsing the query text into a parse tree; converting the parse tree to a query graph; optimising the query graph by combining nodes in the query graph, the combined nodes being nodes with equivalent actions or incoming relationship types; analysing the nodes in the optimised query graph; encoding inbound and outgoing relationship types, a source node, and a target node to be accessed for each node of the optimised query graph into a first table of state transition rules; encoding the data fields to be accessed for each node into a second table of field rules; preparing a structured query language (SQL) query that includes the first and second tables; identifying entity instances to be accessed by the prepared SQL query by applying a state-machine technique to iteratively follow relationship instances according to the first table, wherein entity instances identified in each iteration are simultaneously processed in the subsequent iteration; and loading data fields of the identified entity instances according to the second table.

According to a second aspect of the present disclosure, there is provided a computer program product comprises program instructions for causing a computer to perform the above described method.

Other aspects are also disclosed.

Appendix A is an example of the SQL query generated by the method shown inFIG. 8.

DETAILED DESCRIPTION INCLUDING BEST MODE

The query language described herein is designed for accessing a database and associated data held in a database management system employing a combined ER and relational data model. When a device requests access to the data in the database, the disclosed query language returns a portion of the database together with the associated data to the requesting device. The requesting device can then access the data from the returned portion of the database.

The query language is efficient through its capability of combining ER paths when accessing (i.e., updating or retrieving) the database from the database management system. Such a combining of ER paths enable the database access to use less server processing power. Further, the amount of duplicate data fields being returned from the database management system would also be reduced due to the combined ER paths.

One example of a conventional query language is the Structured Query Language (SQL), which is capable of managing data fields in a relational-model database management system. However, the combination of ER- and relational-models means that the query language must traverse both models to access the combined database management system.

One example data structure of a combination ER- and relational-model database management system includes an entity table listing the entity instances of the database. For example, the table can be arranged in multiple rows and columns, so that one row of the table stores an entity instance and data fields associated with that entity instance, such that the data fields are stored on the same row but on different columns.

An entity instance is an instance of an entity type. Examples of entity types are employees, projects, clients, contracts, risks, and the like. Examples of entity instances are specific instances of the same, such as specific clients and specific contracts. Examples of data fields relating to an entity instance are names, dates, amounts, relationship instance linking the entity instance to another entity instance, and the like. Alternatively, the data fields may be stored in one or more separate tables. In the alternative arrangement, the one or more separate tables may store each data field in one row of the one or more separate tables.

A relationship instance relates an entity instance to another entity instance. More specifically, an entity instance (e.g., a specific client) of a particular entity type (e.g., client) may be related to another entity instance (e.g., a specific project) of another entity type (e.g., a project), via a relationship instance (e.g., a specific relationship between the specific client and the specific project) of a particular relationship type (i.e., a type of the specific relationship). For example, an employee (i.e., an entity instance) can be related to a project (i.e., an entity instance) via a relationship instance, which may have a relationship type named ‘project-employee’.

The combined ER and relational database may be configured so that there is an interconnected schema between entity types and relationship types. The database may then be created using an interconnected network of data consisting of entity instances and relationship instances. The entity instances and relationship instances can then be traversed when obtaining data fields from specific entity instances for the purpose of presenting reports, running workflows, and the like.

FIG. 5Ais an example of an ER-model500. As shown inFIG. 5, the ER-model500includes entity instances510A,510B,510C,510D,510E,510F,510G,510H, and510I (shown as rectangular boxes), and relationship instances520A,520B,520C,520D,520E, and520F (shown as arrows with the relationship type recited next to the respective arrow).

Each of the entity instances510A to510I will be generically referred to as the entity instance510hereinafter and the entity instances510A to510I will be collectively referred to as the entity instances510.

Each of the relationship instances520A to520F will be generically referred to as the relationship instances520hereinafter and the relationship instances520A to520F will be collectively referred to as the relationship instances520.

FIG. 5Bshows a relationship table540representing the ER-model500. Each row550of the relationship table540represents a relationship instance520having a From Entity field552, a To Entity field554, and a Relationship Type field556. In implementing the relationship table540, the data contained within each of the fields552,554, and556are typically assigned with an identification number.

As shown inFIG. 5A, an entity instance510is related to at least another entity instance510via a relationship instance520. For example, the entity instance510A of “Client A” is related to both the entity instances “Project1”510B and “Project2”510C via a relationship instance520A of a relationship type “client-projects”.

FIG. 5Cis an example of an ER-schema560including entity types570A,570B,570C, and570D (shown as rectangular boxes); relationship types580A,580B,580C,580D,580E, and580F (shown as arrows with the relationship type name recited next to the respective arrow); and data fields590A,590B,590C,590D, and590E (shown as text within each rectangular box, below the entity type name). The ER-schema560represents the types of entity instances that are permissible in the ER-model; the types of relationship instances that are permissible between entity instances of particular entity types; and the field data that is permissible on entity instances of each entity type. The schema560is the schema on which the ER-model560is built.

Each of the entity types570A to570D will be generically referred to as the entity type570hereinafter and the entity types570A to570D will be collectively referred to as the entity types570.

Each of the relationship types580A to580F will be generically referred to as the relationship type580hereinafter and the relationship types580A to580F will be collectively referred to as the relationship types580.

Overview

The combination ER- and relational-model database management system may be implemented on a cloud platform that is capable of providing a web-based service that enables users to create and customize the users' web or desktop software applications without the need for computer programming or other technical knowledge. The cloud platform also provides other functionalities such as backup, security, scalability, and the like.

The cloud platform enables users to build software applications by either writing the applications or choosing from a suite of customizable pre-written applications. The software applications may be directed towards customer relationship management, business continuity management, expense tracking, and the like.

The software applications include various graphical user interface software modules, such as dashboards, data entry forms, reports, charts and the like, as well as interactivity modules such as running workflows, triggering business processes, importing and exporting data, template document generation, email notifications, and the like.

FIG. 1Ais a schematic diagram illustrating the physical infrastructure100of a cloud platform102. The cloud platform102is arranged in an N-tier architecture including a plurality of front end web servers104, a cache server106, and a database server108. The cloud platform102receives requests from users110using a user device such as a smartphone111, for example, by an application delivery controller (ACD)112that routes requests to the front-end web server104.

The database server108stores the combined ER- and relational-model database management system, and the cache server110stores pre-calculated queries for acquiring data fields quickly.

The majority of the platform software resides on the front-end web servers104.FIG. 1Bis a block diagram of the front-end web servers104depicting a number of internal software modules140and external software modules130. The external software modules130are modules exposed by the front-end web servers104to support client-side (web browser) code, whereas the internal software modules140are configured to support various internal features.

The external software modules130may include an application management module162that enables the installation/removal/management of software applications, an expression editing module163that allows syntax checking for calculations that a user can enter when editing reports, and a connector module164that enables the cloud platform102to interoperate with other online systems by exposing a data communication application programming interface (API). A console module165for loading user interface elements such as navigation links and sections, and an entity information service166for reading and writing entity-relationship data for communication between the client devices110and the front-end web servers104may also be provided.

The external software modules130may also include a report export module167that provides a tabular report to be converted into a CSV (comma separated variables) or Excel file, a CSV/Excel import module168that allows tabular data to be imported into the database server108as entities, a file and image management module169that supports tracking and download of documents, files, and images for storing in the ER model, and a file upload module170that uploads files by breaking the files into multiple chunks, reassembling the chunks on the server104, and storing the files in the database server108. Other external modules may include a login module171for handling user login, authentication, lockout policy, password policy, encryption, etc., and a long running tasks module172for tracing a time-consuming process, such as importation of a large data set.

The external software modules130further include a reports module173that enables database queries to be graphically constructed, a document templates module174that enables macro-style Word templates to drive automated document generation, a security module175that enables access rules to be configured to control access to entities, a workflow module176that enables users to design business processes as flow charts, which can then be triggered when certain events are detected (for example, if the user presses a certain button).

An edit form module177enables developers to build data entry forms, and present those forms to end users and an actions module178allows application developers to control the activities performed on entities, for example through a right-click context menu. The activities may include editing/deleting a resource, starting a workflow, or generating a document.

The internal modules140include an event handler module179for detecting low level changes in the ER model and performing internal code activities when the changes are detected, an entity module180, which represents the ER model, and a form layout module181for generating default edit forms from database schema objects. An entity request parsing module182is provided for accepting a request from the entity information service module and converting the text into an object structure for processing. An expression evaluation module183for performing the actual calculation process for calculations that have been entered into workflows or reports, an inter-process communications module184for allowing the front-end web servers104to communicate with each other (primarily to notify each other of data changes), and a report evaluation module185for converting reports into SQL database server queries, and formatting the results are also provided.

The internal software modules140may include an application and tenant management module186that supports application management, a monitoring module187that collects system diagnostics information, and a scheduling module188for scheduling activities (such as running a workflow) to occur at certain times. An access control module189may also be provided to implement and enforce internal security rules. Other internal modules130may include an audit log module190to detect and record security sensitive events, a workflow module191to implement the actual execution of a workflow, a strongly typed entities module192that allows an entity schema to be defined in XML and generates source code to allow programmers to program against those entities, and a cache infrastructure module193for caching internal server data, such as entity information, report results and so on.

In many cases, the software modules130and140may be interconnected with and depend on each other. AlthoughFIG. 1Bclearly distinguishes between internal and external software modules130and140, the boundary between the modules130and140may sometimes be fuzzy.

The database server108hosts multiple clients (tenants). Each storage area for each tenant can have different versions of different applications installed. Separate from the tenants, an application library hosts every available version of every available application. User data is also stored within the storage area associated with each tenant.

FIG. 1Cdepicts a block diagram of an exemplary database server108, including storage areas150,152, and154for three tenants and an application library160. A single set of database tables holds all ER data fields for all tenants.

All user data is represented as entity instances and relationship instances, as described above. Additionally, all application components are described in the ER model.

Moreover, the schema (or metadata) about the application is also described using entity instances and relationship instance to define the entity types that are possible; the fields that they may possess; the relationship types that are defined; and rules for validating input.

The unique structure means that all software modules developed to power the cloud platform102equally enrich the user's web-based applications, and vice versa.

As described previously, the above database management system runs on the cloud platform102. Additionally, a body of code (a software client) is sent to and runs on the user's web browser. This code is configured to provide a user interface for the dynamically generated applications. For application developers, this code can also support application building.

The software client is structured as a single paged application (SPA), whereby all code is loaded up front, and communication only goes back to the cloud platform102to fetch or modify data.

Front End Web Server Description

FIGS. 2A and 2Bdepict a general-purpose computer system200, upon which the front end web servers104can be practiced.

As seen inFIG. 2A, the computer system200includes: a computer module201; input devices such as a keyboard202, a mouse pointer device203, a scanner226, a camera227, and a microphone280; and output devices including a printer215, a display device214and loudspeakers217. An external Modulator-Demodulator (Modem) transceiver device216may be used by the computer module201for communicating to and from a communications network220via a connection221. The communications network220may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection221is a telephone line, the modem216may be a traditional “dial-up” modem. Alternatively, where the connection221is a high capacity (e.g., cable) connection, the modem216may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network220.

The computer module201typically includes at least one processor unit205, and a memory unit206. For example, the memory unit206may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module201also includes an number of input/output (I/O) interfaces including: an audio-video interface207that couples to the video display214, loudspeakers217and microphone280; an I/O interface213that couples to the keyboard202, mouse203, scanner226, camera227and optionally a joystick or other human interface device (not illustrated); and an interface208for the external modem216and printer215. In some implementations, the modem216may be incorporated within the computer module201, for example within the interface208. The computer module201also has a local network interface211, which permits coupling of the computer system200via a connection223to a local-area communications network222, known as a Local Area Network (LAN). As illustrated inFIG. 2A, the local communications network222may also couple to the wide network220via a connection224, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface211may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface211.

The I/O interfaces208and213may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices209are provided and typically include a hard disk drive (HDD)210. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive212is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Btu-ray Disc™), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system200.

The components205to213of the computer module201typically communicate via an interconnected bus204and in a manner that results in a conventional mode of operation of the computer system200known to those in the relevant art. For example, the processor205is coupled to the system bus204using a connection218. Likewise, the memory206and optical disk drive212are coupled to the system bus204by connections219. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple Mac™ or like computer systems.

The method of accessing the combined ER- and relational-model database management system may be implemented using the computer system200wherein the processes ofFIGS. 4, 7A-7C, and 8, to be described, may be implemented as one or more software application programs233executable within the computer system200. In particular, the steps of the method of accessing the combined ER- and relational-model database management system are effected by instructions231(seeFIG. 2B) in the software233that are carried out within the computer system200. The software instructions231may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the ER- and relational-model database management system access methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system200from the computer readable medium, and then executed by the computer system200. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system200preferably effects an advantageous apparatus for accessing the ER- and relational-model database management system.

The software233is typically stored in the HDD210or the memory206. The software is loaded into the computer system200from a computer readable medium, and executed by the computer system200. Thus, for example, the software233may be stored on an optically readable disk storage medium (e.g., CD-ROM)225that is read by the optical disk drive212. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer system200preferably effects an apparatus for accessing the ER- and relational-model database management system.

In some instances, the application programs233may be supplied encoded on one or more CD-ROMs225and read via the corresponding drive212, or alternatively may be read from the networks220or222. Still further, the software can also be loaded into the computer system200from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system200for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray™ Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module201. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module201include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs233and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display214. Through manipulation of typically the keyboard202and the mouse203, a user of the computer system200and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers217and user voice commands input via the microphone280.

FIG. 2Bis a detailed schematic block diagram of the processor205and a “memory”234. The memory234represents a logical aggregation of all the memory modules (including the HDD209and semiconductor memory206) that can be accessed by the computer module201inFIG. 2A.

When the computer module201is initially powered up, a power-on self-test (POST) program250executes. The POST program250is typically stored in a ROM249of the semiconductor memory206ofFIG. 2A. A hardware device such as the ROM249storing software is sometimes referred to as firmware. The POST program250examines hardware within the computer module201to ensure proper functioning and typically checks the processor205, the memory234(209,206), and a basic input-output systems software (BIOS) module251, also typically stored in the ROM249, for correct operation. Once the POST program250has run successfully, the BIOS251activates the hard disk drive210ofFIG. 2A. Activation of the hard disk drive210causes a bootstrap loader program252that is resident on the hard disk drive210to execute via the processor205. This loads an operating system253into the RAM memory206, upon which the operating system253commences operation. The operating system253is a system level application, executable by the processor205, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

The operating system253manages the memory234(209,206) to ensure that each process or application running on the computer module201has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system200ofFIG. 2Amust be used properly so that each process can run effectively. Accordingly, the aggregated memory234is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system200and how such is used.

As shown inFIG. 2B, the processor205includes a number of functional modules including a control unit239, an arithmetic logic unit (ALU)240, and a local or internal memory248, sometimes called a cache memory. The cache memory248typically includes a number of storage registers244-246in a register section. One or more internal busses241functionally interconnect these functional modules. The processor205typically also has one or more interfaces242for communicating with external devices via the system bus204, using a connection218. The memory234is coupled to the bus204using a connection219.

The application program233includes a sequence of instructions231that may include conditional branch and loop instructions. The program233may also include data232which is used in execution of the program233. The instructions231and the data232are stored in memory locations228,229,230and235,236,237, respectively. Depending upon the relative size of the instructions231and the memory locations228-230, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location230. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations228and229.

In general, the processor205is given a set of instructions which are executed therein. The processor205waits for a subsequent input, to which the processor205reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices202,203, data received from an external source across one of the networks220,202, data retrieved from one of the storage devices206,209or data retrieved from a storage medium225inserted into the corresponding reader212, all depicted inFIG. 2A. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory234.

The disclosed arrangements use input variables254, which are stored in the memory234in corresponding memory locations255,256,257. The arrangements produce output variables261, which are stored in the memory234in corresponding memory locations262,263,264. Intermediate variables258may be stored in memory locations259,260,266and267.

Referring to the processor205ofFIG. 2B, the registers244,245,246, the arithmetic logic unit (ALU)240, and the control unit239work together to perform sequences of micro-operations needed to perform “fetch, decode, and execute” cycles for every instruction in the instruction set making up the program233. Each fetch, decode, and execute cycle comprises:

a fetch operation, which fetches or reads an instruction231from a memory location228,229,230;

a decode operation in which the control unit239determines which instruction has been fetched; and

an execute operation in which the control unit239and/or the ALU240execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit239stores or writes a value to a memory location232.

Each step or sub-process in the processes ofFIGS. 4, 7A-7C, and 8is associated with one or more segments of the program233and is performed by the register section244,245,247, the ALU240, and the control unit239in the processor205working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program233.

User Device Description

FIGS. 3A and 3Bcollectively form a schematic block diagram of a general purpose electronic device301exemplifying a user device100. The electronic device301may be, for example, a mobile phone, a portable media player or a digital camera, in which processing resources are limited. Nevertheless, the methods to be described may also be performed on higher-level devices such as desktop computers, server computers, and other such devices with significantly larger processing resources.

As seen inFIG. 3A, the electronic device301comprises an embedded controller302. Accordingly, the electronic device301may be referred to as an “embedded device.” In the present example, the controller302has a processing unit (or processor)305which is bi-directionally coupled to an internal storage module309. The storage module309may be formed from non-volatile semiconductor read only memory (ROM)360and semiconductor random access memory (RAM)370, as seen inFIG. 3B. The RAM370may be volatile, non-volatile or a combination of volatile and non-volatile memory.

The electronic device301includes a display controller307, which is connected to a video display314, such as a liquid crystal display (LCD) panel or the like. The display controller307is configured for displaying graphical images on the video display314in accordance with instructions received from the embedded controller302, to which the display controller307is connected.

The electronic device301also includes user input devices313which are typically formed by keys, a keypad or like controls. In some implementations, the user input devices313may include a touch sensitive panel physically associated with the display314to collectively form a touch-screen. Such a touch-screen may thus operate as one form of graphical user interface (GUI) as opposed to a prompt or menu driven GUI typically used with keypad-display combinations. Other forms of user input devices may also be used, such as a microphone (not illustrated) for voice commands or a joystick/thumb wheel (not illustrated) for ease of navigation about menus.

As seen inFIG. 3A, the electronic device301also comprises a portable memory interface306, which is coupled to the processor305via a connection319. The portable memory interface306allows a complementary portable memory device325to be coupled to the electronic device301to act as a source or destination of data or to supplement the internal storage module309. Examples of such interfaces permit coupling with portable memory devices such as Universal Serial Bus (USB) memory devices, Secure Digital (SD) cards, Personal Computer Memory Card International Association (PCMIA) cards, optical disks and magnetic disks.

The electronic device301also has a communications interface308to permit coupling of the device301to a computer or communications network320via a connection321. The connection321may be wired or wireless. For example, the connection321may be radio frequency or optical. An example of a wired connection includes Ethernet. Further, an example of wireless connection includes Bluetooth™ type local interconnection, Wi-Fi (including protocols based on the standards of the IEEE 802.11 family), Infrared Data Association (IrDa) and the like.

Typically, the electronic device301is configured to perform some special function. The embedded controller302, possibly in conjunction with further special function components310, is provided to perform that special function. For example, where the device301is a digital camera, the components310may represent a lens, focus control and image sensor of the camera. The special function components310is connected to the embedded controller302. As another example, the device301may be a mobile telephone handset. In this instance, the components310may represent those components required for communications in a cellular telephone environment. Where the device301is a portable device, the special function components310may represent a number of encoders and decoders of a type including Joint Photographic Experts Group (JPEG), (Moving Picture Experts Group) MPEG, MPEG-1 Audio Layer 3 (MP3), and the like.

The methods for enabling user to access the ER- and relational-model database management system through the provided API may be implemented using the embedded controller302, where the processes may be implemented as one or more software application programs333executable within the embedded controller302. The methods for providing API to enable user to access the database management system will not be described in detail herein. The electronic device301ofFIG. 3Aimplements these methods. In particular, with reference toFIG. 3B, the methods are effected by instructions in the software333that are carried out within the controller302. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software333of the embedded controller302is typically stored in the non-volatile ROM360of the internal storage module309. The software333stored in the ROM360can be updated when required from a computer readable medium. The software333can be loaded into and executed by the processor305. In some instances, the processor305may execute software instructions that are located in RAM370. Software instructions may be loaded into the RAM370by the processor305initiating a copy of one or more code modules from ROM360into RAM370. Alternatively, the software instructions of one or more code modules may be pre-installed in a non-volatile region of RAM370by a manufacturer. After one or more code modules have been located in RAM370, the processor305may execute software instructions of the one or more code modules.

The application program333is typically pre-installed and stored in the ROM360by a manufacturer, prior to distribution of the electronic device301. However, in some instances, the application programs333may be supplied to the user encoded on one or more CD-ROM (not shown) and read via the portable memory interface306ofFIG. 3Aprior to storage in the internal storage module309or in the portable memory325. In another alternative, the software application program333may be read by the processor305from the network320, or loaded into the controller302or the portable storage medium325from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that participates in providing instructions and/or data to the controller302for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, flash memory, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the device301. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the device301include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. A computer readable medium having such software or computer program recorded on it is a computer program product.

The second part of the application programs333and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display314ofFIG. 3A. Through manipulation of the user input device313(e.g., the keypad), a user of the device301and the application programs333may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers (not illustrated) and user voice commands input via the microphone (not illustrated).

FIG. 3Billustrates in detail the embedded controller302having the processor305for executing the application programs333and the internal storage309. The internal storage309comprises read only memory (ROM)360and random access memory (RAM)370. The processor305is able to execute the application programs333stored in one or both of the connected memories360and370. When the electronic device301is initially powered up, a system program resident in the ROM360is executed. The application program333permanently stored in the ROM360is sometimes referred to as “firmware”. Execution of the firmware by the processor305may fulfil various functions, including processor management, memory management, device management, storage management and user interface.

The processor305typically includes a number of functional modules including a control unit (CU)351, an arithmetic logic unit (ALU)352, a digital signal processor (DSP)353and a local or internal memory comprising a set of registers354which typically contain atomic data elements356,357, along with internal buffer or cache memory355. One or more internal buses359interconnect these functional modules. The processor305typically also has one or more interfaces358for communicating with external devices via system bus381, using a connection361.

The application program333includes a sequence of instructions362though363that may include conditional branch and loop instructions. The program333may also include data, which is used in execution of the program333. This data may be stored as part of the instruction or in a separate location364within the ROM360or RAM370.

In general, the processor305is given a set of instructions, which are executed therein. This set of instructions may be organised into blocks, which perform specific tasks or handle specific events that occur in the electronic device301. Typically, the application program333waits for events and subsequently executes the block of code associated with that event. Events may be triggered in response to input from a user, via the user input devices313ofFIG. 3A, as detected by the processor305. Events may also be triggered in response to other sensors and interfaces in the electronic device301.

The execution of a set of the instructions may require numeric variables to be read and modified. Such numeric variables are stored in the RAM370. The disclosed method uses input variables371that are stored in known locations372,373in the memory370. The input variables371are processed to produce output variables377that are stored in known locations378,379in the memory370. Intermediate variables374may be stored in additional memory locations in locations375,376of the memory370. Alternatively, some intermediate variables may only exist in the registers354of the processor305.

The execution of a sequence of instructions is achieved in the processor305by repeated application of a fetch-execute cycle. The control unit351of the processor305maintains a register called the program counter, which contains the address in ROM360or RAM370of the next instruction to be executed. At the start of the fetch execute cycle, the contents of the memory address indexed by the program counter is loaded into the control unit351. The instruction thus loaded controls the subsequent operation of the processor305, causing for example, data to be loaded from ROM memory360into processor registers354, the contents of a register to be arithmetically combined with the contents of another register, the contents of a register to be written to the location stored in another register and so on. At the end of the fetch execute cycle the program counter is updated to point to the next instruction in the system program code. Depending on the instruction just executed this may involve incrementing the address contained in the program counter or loading the program counter with a new address in order to achieve a branch operation.

Each step or sub-process in the processes of the methods described below is associated with one or more segments of the application program333, and is performed by repeated execution of a fetch-execute cycle in the processor305or similar programmatic operation of other independent processor blocks in the electronic device301.

A Method for Accessing the Database

FIG. 4is a flow diagram of a method400for accessing (i.e., updating or retrieving) a combined ER- and relational-model database management system, which is being stored in the database server108. The method400would be executed by the processor205of the front end web server104.

The method400commences at step405where a query is received to retrieve data fields of entities. The query is received by the processor205of the front end web server104from the processor305of a user device110. An example of such a query text is “clientname, client-projects.projectname, client-projects.owner.name”.

The purpose of the example query text is to acquire the data field of “clientname” from the entities “Client A”510A, the data field “projectname” from “Project1”510B and “Project2”510C, and the data field “name” from “Employee1”510E. The example query text is an example query language structure. The structure of the query text may be different according to a convention defined by an author of a query language.

In this example, the Extended Backus-Naur Form (EBNF) definition of the query language used is as follows:

In the example query text, the query text does not define the root entity instance of the query, as typically the root entity instance is defined independently outside of the query language. For example, the root entity instance can be defined as a parameter in the API, as displayed on the user device110. By defining the root entity instance independently, less computer processing power is required in processing the query text. Alternatively, a root entity instance can be included in a query text.

The query text starts with the query term of “clientname” to acquire the data field of “clientname” of the entity instance “Client A”510A. The next query term of “client-projects.projectname” has the terms “client-projects” and “projectname”. The term “client-projects” is a relationship type of “client-projects”580A, which prompts the query language to follow the relationship instance of “client-projects”520A to the next entity instances510B and510C. The subsequent query term of “projectname” refers to the data field590B and instructs the query language to acquire the data field of “projectname” of the entities “Project1”510B and “Project2”510C.

The next query term “client-projects.owner.name” follows, which means that the query language is to follow the relationship instances520A of relationship-type “client-projects”580A from the entity instance510A to entity instances510B and510C. The term “owner” prompts the query to follow the relationship instances520B of relationship type “owner”580B, from both the entity instances510B and5100, to the entity instance “Employee1”510E and acquire the data field of “name” from the entity instance “Employee1”510E. If there are more query terms, the query would continue for the remaining relationship type paths.

The query text may also include sub-query expressions. In the example above, a sub-query expression may be “let @p={projectname, owner.name}”. Thus, the query text with sub-expressions is: “clientname, client-projects.@p”. As shown above, the query text natively references relationship types and data fields to be accessed.

The method400then proceeds to step410.

At step410, the received query text is parsed into a parse tree. The entity request parsing module182, as described above, converts the query text into the parse tree, which is an object structure with an ordered rooted tree representing the syntactic structure of a string according to a context-free grammar. The parse tree is also called a parsing tree, a derivation tree, or a concrete syntax tree. The entity parsing module182is implemented as one of the internal software modules140of the front end web servers104, as described above.

FIG. 6Ashows the parse tree670of the query text discussed above. The parse tree670includes boxes672and arrows674. Each of the boxes672represents a query term (e.g., clientname, client-projects, etc.). Each of the arrows674represents a term from the parse tree.

The method400then proceeds to step415.

At step415, the parse tree is converted into a query graph.FIG. 6Bshows an example of a query graph600generated from the query text example discussed in relation to the step405of the method400.

The query graph600, which represents the object structure of the query to be performed, includes nodes605,610,615, and620and arrows650. When processed, each of the nodes605,610,615, and620operates over a number of entity instances510and identifies a data field or data fields of the entity instances510to be acquired. The arrows650identifies the relationship type580and the relationship instances520that should be followed by any of the nodes605,610, and615according to the query text received at step405.

In the above query text example, the node605is applied to the entity instance “Client A”510A and acquires the data field of “name” of the entity instance “Client A”510A. For the query term “client-projects.projectname” the node605then follows the relationship instances520A of relationship type “client-projects”580A so that the next node610identifies the entity instances “Project1”510B and “Project2”510C. The node610also identifies that the data fields of “projectname”590B of the entity instances “Project1”510B and “Project2”510C are to be acquired.

For the query term “client-projects.owner.name,” the node605follows the relationship instances520A of relationship type “client-projects”580A to the next node615. The query then follows the relationship instances520B of relationship type “owner”580B to the node620, which identifies the entity instance “Employee1”510E. The node620also identifies that the data field of “name”590C of the entity instance “Employee1”510E is to be acquired.

The method400then proceeds to step420.

At step420, the query graph is optimised.FIG. 7Ashows a method700for optimising the query graph. The method700starts at step715where the nodes605,610, and615of the query graph600are consolidated based on equivalent actions or incoming relationship types. For example, if a first node and a second node are instructed to access the data field of the same entity instance, then the first and second nodes can be combined. In another example, if a first node and a second node have the same incoming relationship type, then the first and second nodes can be combined.

To illustrate the optimisation method700, the following alternative example query text is used:

The alternative query text shown in the paragraph above is applied to the entity instance “Project1”510C of the ER-model500. The query text starts with the query term of “projectname” to acquire the data field of “projectname” of the entity instance “Project 2”510C. The next query text is “owner.email”, which leads the query to follow the relationship instances520B of relationship type “owner”580B to the next entity instance “Employee1”510E. The subsequent query term of “email” instructs the query language to acquire the data field of “email”590E from the entity instance “Employee1”510E.

The query term “owner.department.name” follows, which means that the query is to follow the relationship instances520B of relationship-type “owner”580B and the instances520F of relationship-type “department”520F, which lead to entity instance “Department1”510H and acquire the data field of “name”590D from the entity instance “Department1”510H.

The query term “reviewer.email” follows, which means that the query language is to follow the relationship instances520C of relationship-type “reviewer”580C to the entity instance “Employee3”510G and acquire the data field of “email”590E from the entity instance “Employee3”510G.

The query term “reviewer.department.name” follows, which means that the query language is to follow the relationship instances520C of relationship-type “reviewer”580C and the relationship instances520F of relationship-type of “department”580F to the entity instance “Department2”510I and acquire the data field of “name”590D from the entity instance “Department2”510I.

The alternative query text is processed by the steps410and415of the method400to obtain the query graph900(shown inFIG. 9).

One example implementation of performing the consolidation process of step715is shown in the method7150ofFIG. 7B.

The method7150starts at step715A where each node (i.e.,605,610,615, and620in the query graph600; or905,910,915,920,925,930, and935in the query graph900) in the query graph600or900is analysed. The nodes (i.e.,605,610,615, and620in the query graph600; or905,910,915,920,925,930, and935in the query graph900) can be analysed using a graph-walk method e.g., depth-first search algorithm, breadth-first search algorithm and the like. The analysis for each node (i.e.,605,610,615, and620in the query graph600; or905,910,915,920,925,930, and935in the query graph900) includes determining the outgoing relationship type and the data field to be acquired for each node. The method7150then proceeds to step715B.

At step715B, a dictionary is created where a key object is created for each node (i.e.,605,610,615, and620in the query graph600; or905,910,915,920,925,930, and935in the query graph900). Each key object represents a unique set of outgoing relationship type and data field to be acquired in each node.FIG. 10Ashows an example of a dictionary1000A created for the query graph900.

Step715B proceeds to step715C where the nodes having duplicate keys are consolidated.FIG. 10Bshows an example of a dictionary1000B where entries in the dictionary1000A with the same key have been consolidated. Thus, nodes910and920have been consolidated. Similarly, nodes915and925; and nodes930and935have been consolidated.

FIG. 10Cshows a query graph1100, which is the consolidated query graph900. The method7150concludes and the method700proceeds to step720.

At step720, nodes (i.e.,605,610,615, and620in the query graph600; or905,910,915,920,925,930, and935in the query graph900) with equivalent inputs and data field are consolidated.

One example implementation of consolidating the nodes (i.e.,605,610,615, and620in the query graph600; or905,910,915,920,925,930, and935in the query graph900) is shown in the method7200ofFIG. 7C. The method7200starts at step720A where each node905,910,915, and930of the consolidated query graph1100is analysed. The method7200then proceeds to step720B.

At step720B, the dictionary1000B is amended to include key objects corresponding to nodes905,910,915, and930in the query graph1100. Each key object represents a unique set of inbound relationship type in each node905,910,915, and930.FIG. 11Ashows an example of a dictionary1000C, which is an amended dictionary1000B, showing the inbound relationship type for each node905,910,915, and930.

Step720B proceeds to step720C where the nodes having the same key are consolidated. The data fields to be acquired in a consolidated node are the data fields to be acquired from each of the consolidated nodes.FIG. 11Bshows a dictionary1000D where entries in the dictionary1000C with the same key have been consolidated. Thus, nodes910and915have been consolidated.

FIG. 11Cshows a query graph1200, which is the consolidated query graph1100. The method7200concludes and the method700proceeds to step725.

At step725, the method700determines whether any consolidations were made at steps715and720. If any consolidations are made (YES), then the method700returns to step715. Otherwise (NO), the method700concludes, which also concludes step420. The method700is repeated if consolidations have been made in order to ensure that there are no further optimisations possible.

In summary, the query graph600or900is optimised at the step715of the method700to produce the query graph1100ofFIG. 10C. The query graph1100is then further optimised at the step720of the method700to produce the query graph1200. If at step725, it is determined that there are further consolidations to be made, the query graph1200is further optimised by repeating the optimisations at the steps715and720of the method700.

The method400then proceeds to step425.

At step425, an SQL query is prepared. The SQL query is prepared by generating a table of data that represents a state machine. The SQL query mechanism operates by treating the consolidated query graph1200as a state machine and using the set-based operation of SQL servers to simultaneously follow all paths in the query graph1200. The generated SQL query mechanism also enables the SQL queries to be performed in a single batch call such that round trips are not required. However, multiple data fields are returned.

A state machine is a mathematical structure for determining if a sequence of tokens matches a set of rules. The state machine defines a set of states, and transitions between those states. Each time a token is encountered, the state machine attempts to follow a transition that matches that token from the current state to a subsequent state.

FIG. 8Ashows a method800for preparing the state machine rules for the SQL query mechanism. The method800commences at step805where all the nodes905,910, and930of the query graph1200are analysed and assigned a unique identifier. For example, all the nodes905,910, and930may be analysed using a breadth first graph walk, or other algorithms, so that a unique identifier (e.g., a number) can be assigned to each node905,910, and930. The method800then proceeds to step810.

At step810, an SQL query is defined. The SQL query may define a temporary working table that also functions to hold a result set.

For example, the working table defines the following:1. The entity instance (e.g.,510C,510A, etc.) to be processed.2. The node (e.g.,905) relating to the entity instance (e.g.,510C) to be processed.3. A flag indicating if the entity instance (e.g.,510C) has been processed4. The relationship type (e.g.,580A, etc.) followed to arrive at that entity instance (e.g.,510C), if any.5. The source entity instance (e.g.,510A) that led to the entity (e.g.,510C) being processed, if any.

The method800then proceeds to step815.

At step815, the inbound and outgoing relationship types, source node, target node(s), and data fields to be accessed for each node605,610, and615are converted to a table-valued parameter, ready to be input into the SQL query. The fields to be loaded for each node605,610,615are similarly converted to a table-valued parameter (i.e., a table of field rules).

Thus, the table-valued parameters codify, for each node605,610, and615in the query graph600, the unique identifier, the source node, the relationship type(s), the target node(s), and the data field to be accessed. The relationship type(s) being identified are forward and reverse relationships. For example, for the entity instance “Project 2”510C of ER model500, the forward relationship types are relationship types “depends-on”580D, “owner”580B, and “reviewer”580C leading to entity instances “Project3”510D, “Employee1”510E, and “Employee3”510G, respectively. The reverse relationship types are relationship types “depends-on”580D and “client-projects”580A from the entity instances “Project1”510B and “Client A”510A, respectively.

A table-valued parameter codifying inbound and outgoing relationship types, a source node, and a target node to be accessed for each node of the optimised query graph is called a table of state transition rules.

A table-valued parameter codifying the data fields to be accessed for each note is called a table of field rules.

In a case where data fields are stored across multiple tables, for example if there is one table per data field type, then the data fields are accessed on a per-data field-table basis.

The above codified information may be stored in a table external to the SQL query mechanism. Alternatively, the codified information may be stored in a table-value constructor of the text of the generated SQL mechanism. In another alternative implementation, the codified information may be stored in a permanent database table and accessed by the SQL query mechanism as required. In another alternative implementation, the codified information may be written inline into a generated SQL query.

The same form of query may be executed multiple times, but starting from a different root entity instance. The same query text yields the same SQL query mechanism, regardless of starting instance. Therefore, the SQL query mechanism can and should be cached to enable the SQL database server108to perform its own execution plan caching more effectively as well.

A standard caching strategy may be employed. A cache key is calculated to uniquely identify a query text to enable the front end server104to check the cache for the same key value before building a SQL query mechanism. If a cached SQL query mechanism for the query text is found, then the cached SQL query mechanism is returned. Otherwise, the SQL query mechanism is created using the method800and caches it by the same key. The front end server may then issue the SQL query to the database server108.

As the SQL query mechanism is being prepared, any data fields or relationship types that are encountered are recorded. A watch is then scheduled to monitor for any schema changes to those data field definitions or relationship type definitions in the entity-relationship schema. If any such modifications are detected then the cache entry is invalidated such that any subsequent calls cause a new SQL query mechanism to be prepared.

The cache key for the query may be an identity that represents the query; or a hash of the query text; or the object reference for the query; or the entirety of the query text itself.

The SQL query mechanism returns several tables of data in a single call. For example, the SQL query mechanism returns all relationship instances in a first table and all data fields in a second table.

The results acquired from the query can also be cached. A standard caching mechanism is employed that uses a combination of the same cache key used for the cached SQL query mechanism and the identities of the entity types that are used to run the query.

Cache invalidation is performed by any of the following methods:1. Invalidating if any data change is made.2. Watching for changes to any data field on any entity instance, where the field definition matches one used in the query; and watching for changes to any relationship instances on any entity instance, where the relationship type matches one used in the query.3. Watching for changes to any of the entities returned by the query, including relationship instances in or out.4. Watching for changes to applicable fields and relationship instances on entities returned by the query.
These variants allow for varying cache behaviours with increasing granularity to maximise cache longevity, traded off against increasing overhead.

If a cache is used, then steps420to430of the method400may be skipped and the cached SQL query mechanism is used to access the requested data field.

The method800concludes, which also concludes step425of the method400. The method400then proceeds to step430in which the SQL query mechanism is executed by the processor205of the front end web server104in communication with the database server108In operation, the step430is performed by pre-filling a working set table with the entity instances (e.g.,510A) that the user device110has requested to start with, which may be any entity instances510in the database500. As described above, such a request is received at the server104at step405of the method400.

The working set table is then used to perform an iterative loop to follow all nodes905,910, and930in the query graph1200by tracking the nodes905,910, and930that have been processed. This is achieved as follows:1. The working set table is filtered to only include yet-to-be-processed nodes (e.g.,910and915, if node905of the query graph1200has been processed).2. The working set table is joined to the relationship type transition rules table that has been created by connecting the node of the working set table to the source node of the relationship type transition rules table.3. The working set entity instance identities and the transition rules relationship type identities are then together joined to the entity model relationship instance table.4. This set operation simultaneously yields: all directly related entity instances across all relationship types identified in the transition rule for all to-be-processed entities given the node that those entities are currently at.5. Moreover, the join from step30also yields the next node for each of related entity instances via the target node identity of the transition rules table. The transition rules table also contains the relationship type identity that is used to arrive at this node.6. This result set is then joined back against the result set (working set) of entities to filter out any instances that have already been processed. This is to ensure that each entity-id-node-id pair is only visited once, i.e. that the data for any given instances is only loaded once for any given query node, to ensure that the system does not end up in an infinite loop.7. The query graph may follow some relationship types in the forward direction, and some relationship types in the reverse direction. Because the different columns are involved (namely, relationship FromEntity and ToEntity are reversed), it is convenient to have a relationship type transition table for the forward direction, and a separate relationship type transition table for the reverse direction. Steps 1-6 are repeated once for the forward relationship type transitions and once for the reverse relationship type transitions following the same pattern except with FromEntity and ToEntity reversed.8. The results from steps 1-7 are inserted back into the result set. The new entity identity is the entity instance at the other end of the relationship instance, the new node identity is the target node identity from the transition table. The relationship type identity is the type of relationship that was followed. The previous set of rows in the working set table is marked as complete, and the new set of rows becomes the work to do on the next iteration.9. If any actual relationship instances were successfully followed, then control returns to step 1.10. The result set is further joined to the field rules table-valued parameter and the field data table such that the field data for each entity instance is returned where an entity instance was loaded for a particular node and the field rules table codifies that a particular field should be returned for that node. The step430is complete.
There are many possible implementation specific variants such as the specific ordering of the table joins, or whether forward and reverses are processed simultaneously, or whether a two-state or three state flag is used to keep track of progress, or whether the above steps are performed in a single insert statement, or as multiple statements. These possible implementations do not affect the operation of the step430because the query is represented in a table of state-machine transition rules, so that work can be processed iteratively as subsequent relationship instances are followed. However, all entity and relationship instances currently available for processing are done so simultaneously at each stage of processing.
The entity instances to be accessed by the prepared SQL query are then identified. Such identifications are performed by applying the state machine technique to iteratively follow relationship instances according to the relationship type transition rules table. The entity instances identified in each iteration are simultaneously processed in the subsequent iteration.
The working set now contains all entity instances that were visited in the result, along with the type of relationship along which the entity instances was reached, and the node identities for which query rules applied. The resulting data, including the working set and the field values are returned from the SQL server108.

The method400then proceeds to step435.

At step435, the database server108returns a query result network to the user device110. The query result network is produced from the execution of the query text. The query result network is formatted from the relationship instances returned from the SQL database, with the field data attached to each entity instance node. The query result network is returned to the processor205of the front end web server104, which forward the returned query result network to the API of the user device110that requested the data field. That is, the requested data fields of the entity instances are loaded according to the relationship type transition table.

FIG. 12Ashows an example of the relationship instance data1200which results from executing the query text (received at step405) on the ER-model500, starting at the entity instance510A. The relationship instance data1200includes a FromEntity column1210, a ToEntity column1220, and a RelationshipID column1230. Each row1240of the data1200describes the relationship between columns1210to1230. For example, the first row1240includes the FromEntity column with the data “Null”, the ToEntity column with the data “ClientA”, and the RelationshipID column with the data “Null”. Thus, the first row1240identifies that the “ClientA” does not have an originating entity instance (i.e., “Null”) and a relationship instance from the originating entity instance (i.e., “Null”).

FIG. 12Bshows an example of the field data1250which results from the same query. Thus, as shown inFIG. 12B, the entity instance “ClientA” returns the field data of clientname with the value “Client A”. The relationship instance data1200is formatted into a query result network1300(shown inFIG. 12C) by translating each relationship instance row1240into a directed connection (arrow) in the result network1300, leading from the ‘From Entity’ to the ‘To Entity’. The relationship type is also stored on each edge in the network1300. The field data1250is attached to each entity instance510in the query result network by attaching each field value in the field data1250to the entity instance specified in each row1240.

INDUSTRIAL APPLICABILITY

The arrangements described are applicable to the computer and data processing industries and particularly for accessing data fields of an entity-relationship database that is implemented over a SQL relational database management system.

In the context of this specification, the word “comprising” means “including principally but not necessarily solely” or “having” or “including”, and not “consisting only of”. Variations of the word “comprising”, such as “comprise” and “comprises” have correspondingly varied meanings.