WO2016071682A1 - Database interrogation system and method - Google Patents

Abstract

The invention provides systems and methods relating to database interrogation and analysis. The invention provides a solution wherein one or more objects are defined and stored in a library. An object includes a logical statement such as an SQL statement which relates to a key item of interest in the application area, eg a patient, a customer, a product etc. During use, the object queries are executed upon a source database so that each query produces a list of unique identifiers relating to the key item of interest. The lists are then stored in association with their respective objects. During use, the user can analyse and query the lists to answer questions about the underlying data, but without having to actually access it. The object lists can be updated as and when required or practically feasible. As the identifiers are simple data types eg numeric IDs, they are economical to store and process. The invention also comprises an interface which enables the user to view and manipulate objects, and also control processing of lists. The interface may comprise a variety of input mechanisms such as mouse input, gesture input or input via a touch screen. The interface enables the user to drag and drop objects, re-organise and categorise objects, share objects with other users and connect objects to construct complex interrogations.

Description

Database Interrogation System and Method

This invention relates generally to database technologies, and more particularly to tools and techniques for the interrogation of databases. The invention is particularly suited, but not limited to, use with large databases which are populated with large volumes of data which may need analysing.

Relational databases such as Oracle or SQL Server are well known. Such databases allow the storage and organisation of large volumes of data, so that the data can be searched, retrieved and analysed using specially designed software tools. However, in order to perform such analysis one must have access to the database itself which can cause problems in respect of confidentiality or ownership of the data.

In the business intelligence field, Online Analytical Processing (OLAP) enables users to answer multi-dimensional analytical (MDA) queries by pre-defining the items of data they are interested in. A multidimensional 'OLAP cube' is then constructed to allow the user to ask questions about the data. However, OLAP solutions typically require a large amount of storage space as it is necessary to store every possible result that could be generated from the selected data items.

Moreover, existing business intelligence tools comprise user interfaces which follow the 'dashboard' approach, comprising charts and graphs. Such tools do not provide the flexibility or ease of use that is often desired. Existing technologies do not enable a user to interrogate or analyse a database using terminology that is intuitive and reflects the 'real world' environment or application area in which they are operating. They need to be technically proficient in order to manipulate the interrogation tools and/or understand the results which are generated.

Thus, it is desirable to provide an improved technique for database interrogation and analysis and for the extraction of sought information. Such an improvement would ideally provide swift results to questions asked by users, avoid the need for continual access to the underlying database, and necessitate minimal storage. Such a solution would also enable users to build questions which they want to pose about the data in a simple and fast manner.

Such an improved solution has now been devised. Thus, in accordance with the present invention there is provided a solution as defined in the appended claims.

Therefore, in accordance with the invention there is provided a database interrogation system comprising:

a library comprising at least one object representative of a database query;

a list of identifiers stored in association with the object;

a list generation component arranged to execute the query on a database so as to generate the list of identifiers.

Additionally or alternatively, the invention may be referred to as a 'database system', or a 'database retrieval tool' .

The object may be defined using a logical statement. The statement may be formed using a query language. The query language may be SQL. Preferably, the library comprises one or more objects. Therefore, the library is a collection of at least one object. The library may be stored locally or remotely with respect to the database. The library may be stored in the cloud. Access may be provided as a cloud- based service. Each object may represent, define or model a query relating to a key item. The key item may be an entity (physical, logical or virtual) which is central or at least important within the application area of the database. The application area may be any commercial or noncommercial market or domain. The invention is not limited with respect to the nature of the database, its architecture or the nature, purpose or architecture of the data which it contains. The object(s) within the library may be shared between a plurality of users. An object may be tagged or otherwise modified to indicate which users it may be accessed and/or used by. The ability to share objects provides significant benefits. For example, if user A is able to share objects with user B and the shared objects have a common key ID (for example patientID or National Insurance number) this provides the advantage that user B can ask questions which span user B's objects and user A's objects without having access to user A's source data.

The database may be referred to herein as the 'underlying' database, the 'data source' or 'source database'.

The invention may be considered as providing an additional layer between the database and the user. Therefore, in one sense, the system of the invention may be considered to be an interface (which may in itself comprise a user-interface). The additional layer provides an architectural and technical advance over the prior art as well as a functional advance. It facilitates communication between the user and the database via an object-based infrastructure.

Preferably, the object comprises at least one attribute. There may be no limit to the number of attributes per object in the library.

Preferably, each identifier is a unique identifier relating to an item in the database. The item may be a key item as described above. The identifier may relate to a record or row in a database. The identifier may be a simple data type. For example, it may be a numeric value or an alphanumeric type, or text (char) based. In programming terms, it may be a primitive data type. The advantage of this is that the identifiers are economical to store, and easy to process.

The identifier(s) may be processed after their selection from the database. For example, the identifiers may be modified to anonymise them. This provides advantages in respect of sensitive or confidential data. Additionally or alternatively, the identifiers can be replaced with alternative identifiers to provide the desired anonymity. The object may be associated with one or more further objects. Thus, groups of associated objects may be formed. The objects may be logically linked. They may be linked into groups using attributes. An attribute which is common to (shared among) a plurality of objects may thus create an association or category of objects.

The system may comprise one or more components for processing and/or analysing a plurality of lists, each list being associated with an object, to produce a resultant list. The resultant list may be stored. It may be used to generate a new object which is then stored within the library.

Preferably, the library comprises a plurality of objects, each object associated with one or more sets (lists) of identifiers. An object may be associated with a plurality of lists. The list generation component may be configured to re-execute the query so as to update the set (list) of identifiers. The list may be an empty list if, for example, the query returns no results from the database; or it may comprise one element (identifier); or a plurality of elements. The object's query may be executed upon command by a user. Additionally or alternatively, it may be executed on the database at a predefined time or after a pre- determined length of time has elapsed. It may be triggered by a certain event.

The invention may comprise a user interface arranged to represent at least one of the objects in the library on a screen such that a user is able to control processing of one or more lists via the interface. The list may be a list which is associated with the object, or a new list which is generated as the result of processing a list associated with an object. The interface may be arranged to enable the user to manipulate the at least one object in the library. The user may therefore be able to manipulate and control the analysis or interrogation via the user interface. The interface may be a graphical user interface. The interface may comprise a variety of input and/or output arrangements. The interface may be arranged to allow input from a user via a mouse and/or keyboard. The user interface may be arranged to represent one or more objects on a screen. It may be a touchscreen. The interface may be configured to receive input from the user via the touchscreen. Additionally or alternatively, the user may be able to manipulate the objects and/or control the list processing via a gesture-based input mechanism. In such an embodiment, the user may be able to provide input using movement in free space.

The user interface may be arranged to enable an object in the library to be linked with one or more further objects in the library. This may be achieved via a drag and/or swipe motion on the touchscreen.

Also in accordance with the invention there is provided a database interrogation method, the method comprising the steps:

creating an object representative of a database query;

executing the query on a database to generate a list of zero, one or more identifiers;

storing the list in association with the object.

The object may comprise at least one attribute. Preferably each identifier is a unique identifier relating to an item in the database. The method may further comprise the step of associating an object with one or more further objects. It may comprise the step of processing the list to generate list-related data. It may comprise the step of generating a library comprising a plurality of objects, each object associated with one or more lists. It may comprise the step of re-executing the query so as to update the list. The query may be re-executed after a predetermined period of time has elapsed, or at a scheduled time. The method may further comprise the step of defining the object using a query language. It may comprise the step of anonymising the identifiers.

The invention may be arranged to track how useful an object is. Thus, objects may be prioritised. This feature may be a proxy for how relevant an object is for a particular task, or how interested a user is in the object. This may be achieved by recording how often a user requests the object, how often they interact with it and/or how often they share it with others. Additionally or alternatively, the user may also affect the priority by explicitly changing a setting eg by selecting whether they find the object interesting or not. The user may say they always want to see that object as it is a high priority. They may say they never want to see that object ie it is a low priority. A number of intermediate priority levels in between 'high' and 'low' may also used.

This feature allows the invention to then present objects to users in a priority order. This may be particularly advantageous when the invention is deployed on a mobile device where screen size may be limited. In such cases it may be beneficial that invention is able to predict what is useful to the user and only present these objects. This saves the user the task of searching for objects using text searches or moving through a hierarchy to find an object.

The invention may also comprise an Object Geolocation feature. Every object may have a list with an associated geographical reference. This may allow the location of the object to be represented on a map. Examples of geographical references may include postcode, zip code, longitude and latitude. In an embodiment arranged for deployment on a

mobile/handheld device (eg tablet, smart phone etc) the invention may also use

geographical references to allow objects to be represented using augmented reality. Such an embodiment may super impose the location of an object onto the view through a camera associated with the device. As the user moves the device and views the surrounding world, the objects may move to display to the user where in the world the objects are located.

Additionally or alternatively, the objects in the object library may be used to predict the future. A number of algorithms and processes exist to model and predict the future.

However these all specify the data set or sets that are required. The process used by the present invention is novel in that it allows any object to be applied to a prediction algorithm. Therefore, because of the process used by the invention to create and store objects, they may be presented to an object model without having to change the source data. For example, with the prior art solutions, if data set A is used with a given predictive model, data set B cannot then be used with the model if the structure or content varies. However, as the object library represents objects and not raw data, data set A and B are represented in the object library as objects and can therefore be applied to the predictive model. Thus, the invention may enable any source data set to be applied to the predictive model. According to another aspect of the invention there is provided a graphical user interface arranged to display:

at least one object representative of a database query;

a list of identifiers stored in association with the object, wherein the list is the result of executing the query on a database.

Preferably, the interface is arranged to enable a user to control processing of the list associated with the object via the user interface. The graphical user interface may be arranged and configured for operation with an arrangement as described above. The user interface may be arranged to enable the object to be linked with one or more further objects. The user interface may be arranged to allow a user to control processing of the list using a drag and drop facility.

Any feature mentioned above in relation to one aspect or embodiment of the invention may also be applicable and used to advantage in relation to one, any or all of the other aspects/embodiments of the invention. Any feature described in relation to the method may be used in relation to the corresponding system and vice versa.

Thus, the invention may be considered to provide an improved method and system for communicating with a database. Additionally or alternatively, it may be considered to provide a more effective and efficient solution relative to the prior art because the results can be achieved far more rapidly than with known technologies, requiring less processing time and resources. As the invention does not require constant access to source data it does not impact on source data performance or degrade its hardware performance. Further still, the invention is able to work on any data source irrespective of its structure or architecture. The novel and inventive user interface provides an improved control mechanism for interaction between a user and a database because it allows the user to easily, intuitively and quickly create new objects which can then be used to query the database, extract relevant information and store it. The user is able to perform operations and make selections based on terminology and concepts which he is familiar with from the application space (e.g. healthcare) rather than having to use technical database-related terminology and techniques.

Thus technical effects associated with the present invention include, for example, efficient data processing, efficient and improved data storage, and enhanced security of data.

These and other aspects of the present invention will be apparent from and elucidated with reference to, the embodiment described herein. An embodiment of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

Figure 1 illustrates an overview of the present invention.

Figure 2 illustrates how the invention can be used to create simple lists from complex data in a healthcare-related application area.

Figures 3 illustrates an embodiment of the invention being used by a user on a work space within the interface. Figure 4 illustrates an embodiment of the invention wherein two objects are being used.

Figure 5 illustrates an embodiment of the invention wherein the two objects of figure 4 are joint to enable processing of the lists from both objects. Figure 6 provides an overview of an illustrative structure used in accordance with the invention. Turning to Figure 1, the invention provides an improved solution for interrogating, searching and/or selecting from an electronic data source 2. This is typically a large database 2 comprising many items of data. The data items are organised according to some structure, such as table 2a containing records or rows of related data items.

As the invention lends itself for use with any data set where there is a point of focus (e.g. patient, customer, product etc.) it can be used to advantage in a wide variety of application areas including healthcare, manufacturing, retail, defence, banking, consumer financial, media. The invention is not intended to be limited in relation to the nature of the data stored in the database it interacts with, the architecture of the database or its application area.

The invention provides a mechanism for creating a repository of search results which is stored separately from the underlying database 2. The search results are generated by executing a predefined query on the database 2, and comprise simple data items which can be searched and processed quickly eg numeric, textual or alphanumeric identifiers. As the search results have been generated using a pre-defined query, the search results have a 'context' in the sense that they can be stored, organised and searched in a manner that is useful and meaningful for an end user 3 such as a database operator, researcher or administrative staff.

An important feature of the invention is that the system comprises predefined queries. These are designed according to the user's requirements. Once the queries have been determined and written, they can be saved and executed repeatedly to generate results which are stored separately from the source database. These results can then be stored and processed independently of the database, meaning that continual access is not required. In addition, the results are simple data types which are easily stored, processed and manipulated, thus making efficient use of computing resources, while still enabling complex operations to be built and performed.

Hereafter, the predefined query will be referred to as an Object' and the search results produced by executing an object will be referred to as a 'list' . Each list 5 comprises zero, one or more simple, unique identifiers 6 selected from the database 2. For example, in the medical example, objects might include 'patients with diabetes', or 'patients admitted to hospital this year', or 'patients who are taking medicine X'.

The objects 4 are defined using one or more logical statements. In a typical

implementation, a database language such as SQL is used for this purpose. An object may comprise more than one query. The objects are stored in a collection 1, which may be called an 'object library' . In some implementations, the objects 4 are categorised which enables them to be organised into a hierarchy. The objects 4 in the library 1 are given identifiers which will be referred to hereafter as 'object IDs'.

Upon execution of an object's query, a list 5 of unique identifiers 6 is generated. The lists 5 are then stored in association with the respective object from which they were created so that they can be processed or searched in a meaningful way at a later time. The lists may be, for example, patient ID numbers. The identifiers 6 relate to key items of interest, such as patients. In other examples, it might be company products, or any entity which is potentially the subject or focus of a user's query. In certain cases, more than one list may be associated with an object. For example, a query may be executed more than once if the user's search is time sensitive.

Each object 4 can comprise one or more attributes 10 which define information relevant to the respective object. These attributes 10 enable the user 3 to navigate around the library 1 and the objects 4 therein so as to find the appropriate object for their current needs. Each object can comprise one or more attributes. The number of attributes 10 per object is not limited. Examples of attributes might include descriptive text, or groups/categories used to assist the user in navigating a hierarchy of objects via text search or visual navigation of a tree structure. For example, a 'Diabetes' object may have a text-based attribute which labels or describes the disease, and/or an attribute that groups the object into a category called 'disease'. Another example of an attribute might be 'finance' relating to the cost of an item. In the example object shown in Figure 3, 5 attributes are shown for the 'Diabetes' object.

The user 3 is able to ask questions of an object or objects with reference to one or more attributes 10. For example, the user can select an object from a menu and then ask to see which other objects with a shared attribute also have a list comprising the same identifiers. Continuing the healthcare example, 'diabetes' and 'asthma' objects can be logically linked within the same category because they both comprise the 'disease' group attribute. The user can then explore the data by asking, for example, which diseases are associated with patients who have been admitted to hospital. To do this, the system uses the patient IDs contained in the list associated with the 'admitted to hospital' object. These patient IDs can be compared with those contained in the lists associated with objects having the 'disease' attribute. If there's a match (ie a particular patient ID is found in both the 'admitted to hospital' object list, and also the 'diabetes' object list) then this can be displayed and added to a count variable. As the items being compared (patient IDs) are small and simple, this processing can be performed swiftly and without access to the underlying source database.

Considering a retail-based example as an alternative, a user is able to select an object relating to 'Female Customers'. Suppose that the user wishes to know what types of television female customers have purchased. Therefore, the user performs an analysis using the group attribute "TV Type". There is an object for LED TVs and the TV Type attribute is 'LED'. There is an object for Plasma TV and the TV Type attribute is

'Plasma' . Therefore, when the user performs an analysis by 'TV Type' the result is a count broken down by TV Type - that is LED and Plasma. Thus, for example, the 'Female' Object has a list comprising 150 (female customer) identifiers. Analysing by 'TV Type' displays 90 LED and 60 plasma.

Therefore, the attributes provide a powerful investigative tool as the user does not necessarily know exactly what they are looking for eg LED TV's, but simply that they are interested in 'TV Type'. After a user has asked a question, perhaps by combining objects, the resultant list may be saved as a new object. This new object can then be used as described above. For example, suppose a user asks "how many customers bought a television and have a good credit rating?". After getting the answer as described previously they decide to save that resultant list as a new object as it is something they wish to use frequently. The user can then ask more questions about this new object as they would with any other pre-defined object. This provides a system architecture which can be tailored easily over time in response to a user's needs. Thus, the interaction between the invention and the underlying database 2 can evolve, adapt and improve incrementally.

In addition, users can choose to share objects with other users. This is beneficial as a new user does not have to create a new object from scratch and can use one that another user has previously created. This is achieved by storing a list of user identifiers (ID's) against each object that the user wishes to share. In addition, sharing can be performed by individual users or groups of users. This is achieved as users can choose to be part of a group, for example should they wish to work on a common project. In addition objects can be shared a template data structure can be designed and created for each application area. For example, a data structure template can be defined for healthcare and whilst users do not need to adhere to it for using the invention, if they do adhere to it they can share objects.

Figure 6 shows examples of the structures which may be used in accordance with the invention. For example, an object can comprise an ID and a name. The object attribute table allows multiple attributes per object and includes a description and the logic e.g. SQL that allows the object list to be created. The object attribute table allows multiple attributes and also multiple logic/SQL statements if required. The Main attribute table describes the attribute. The Object lists table stores the lists of identifiers 6 and objects. This is the narrow table which allows fast access to counting items in a list. In certain embodiments, users are given access to the database so that they may ask their own questions. However, such embodiments are expected to be suitable in situations where the user is technically experienced. Such embodiments are arranged to incorporate an open architecture which allows technical users to directly query the database or to use an API (Application Program Interface) and or SDK (Software Development Kit).

Users can also use a graphical user interface 7 to ask questions and interact directly with the object library 1. In one illustrative embodiment, the interface 7 is displayed on a touchscreen which allows a graphical representation of an object 4 to be selected by dragging it from a menu section onto the main work area 8. The objects in the library 1 are available from a collapsible/expandable menu 11 which, in the illustration of Figures 3 to 5 is shown on the left hand side of the screen. The menu displays objects in a hierarchical fashion by displaying a category label which, when clicked on, expands to shown the objects available in this library. Referring to figure 3, for example, clicking on the 'diagnosis' option causes drop down options to appear: COPD, Frailty, Asthma, diabetes, Measles, RTI. Each of these options represents an object. When the user clicks on one of the drop down options eg diabetes the selected object appears in a visual form.

This menu facility enables users to operate in a very intuitive manner, referring to entities or items which are familiar to them from the application area (eg healthcare) rather than technical database terminology. Thus, the interface provides an improved database communication tool.

The selected object image 4 remains in the work area 8 where the user 3 can interact with it. This dragging or swiping motion is a faster and more intuitive way for a user to place their object or objects onto the work area. When an object 4 is placed on the screen 8, information about that object (eg attributes 10) appears inside it.

More than one object can be dragged or swiped onto the work area. As shown in figures 4 and 5. As shown in figure 5, the user can then join two objects together by touching a pre- designated 'sensitive' part of an object and then dragging or swiping their finger to the sensitive part of another object. This causes a visual line 12 to be drawn between the two objects. The sensitive area of an object may indicated by a visual marker, a different colour or icon 14. The visual line 12 may be labelled to provide information and functionality for further processing. As shown in figure 5, a string of text explains which objects have been linked - in this case, 'diabetes' and 'inpatient attendance' . A count of the key items found in both lists is calculated and displayed - in this case, 25. Icons 13 are also displayed which, when clicked, allow the user perform tasks such as saving the new list, expanding the information relating to the processing, generating a graph of the results etc.

The interface 7 also provides a search facility to enable the user to search for an object within the library by entering a string.

Example use - Healthcare application

Figure 2 shows an example of the present invention in use within a healthcare context. However, the invention is not limited to use with healthcare applications. According to the prior art, an organisation stores information about patients in a database which comprises tables of information about the patient and their interaction with healthcare services including admissions, diagnosis, drugs prescribed etc. The key item of interest in healthcare is 'the patient' . Traditionally one is able ask questions or analyse the data using a variety of database tools and techniques.

In accordance with the present invention, however, an object library 1 is created comprising a collection of objects 4 which describe various aspects of the patients' interaction with the health service. This approach is technically and conceptually different to prior art approaches.

There is no limitation on the subject of an object other than a logical statement (query) can be written to describe the object. Examples of objects in healthcare would be 'patients with diabetes', 'patients who are female', 'patients who are under the age of 18', 'patients who have been admitted to hospital' etc. Each object 4 is assigned an Object ID.

The logical statement is executed on the underlying data base 2. This may happen at a predetermined time eg 8pm each day, or after a certain period of time has elapsed eg every 24 hours and/or upon manual instruction. Execution of the query returns a list 5 of unique identifiers 6, each associated with a key item of interest. In this case, the key item of interest is the patient and the identifiers 6 are patient IDs. The length of the list 5, therefore, depends upon the number of 'hits' returned by the query. The list 5 may be empty, have one element in it or more. There is no upper limit on the number of elements in a list. The system stores the list of patient IDs for each of the objects based on the logical description of that object. Therefore a list of patient ID's with diabetes (1) is created and stored, a list of patient ID's who are female (2) is created and stored.

In some situations it may be desirable to hide or obscure confidential identifiers.

Therefore, the system may be arranged to anonymise the identifiers prior to them being viewed by the user. This may be achieved by modifying the identifiers or replacing them with alternatives. For example:

Diabetes Object (1), list of patient ID's = 1,2,3,4,7,8,9,

Female Object (2), list of patient ID's = 1,2,3,4,5,6

Once the object queries have been executed and the resultant lists 5 stored, the user 3 can now interrogate the data in the objects' lists 5 without having access to the original source data 2. For example, if the user wishes to know how many patients have diabetes, it is possible to count how many elements (patient identifiers) are in the 'Diabetes' object list. In this example shown in figure 2, seven identifiers have been returned as a result of this query. If the user wishes to know many patients are female, it is possible to count the number of identifiers in the 'female' object's list, which is six.

The user can also combine objects to answer questions as shown in figure 5. If one wishes to know how many patients are diabetic and female, one simply needs to count the identifiers which appear in both lists, which is three. This count can then be displayed. The identifiers themselves can also be displayed. This resultant list can be saved and so a new object has been created: 'Diabetic Female patients'.

Each of these operations is possible without (asking questions of the data, creating objects) without access to the source data. This is achieved very quickly as the lists are numeric and therefore can be accessed from memory very rapidly. In addition, other users can share a user's objects because they are independent of the source data 2.

Other features can be incorporated into the invention, including the following.

Object Priorities

The object library can be arranged and configured to track how useful an object is from the user's perspective. This feature enables the system to determine how relevant or interesting an object is for the user. It does this, for example, by recording how often a user requests the object, how often they interact with it and how often they share it with others. The user may also affect the priority of an object by selecting an item in a list or using some other technique to manually indicate whether they find a particular object interesting or not. The user may stipulate that they always want to see that object as it is a high priority, or they may indicate they never want to see that object (i.e. it is a low priority). A number of levels in between can also be utilised to provide more granularity in the prioritisation process.

The software application can then present objects to the user in a priority order. This is particularly useful on a mobile device where screen sizes are limited. As the inventive application is able to predict what is useful to the user it can selectively show only these objects. This avoids the need for the user to search for objects using text searches or moving through a hierarchy to find an object.

Object Geolocation

Every object can have a list with an associated geographical reference. This allows the location of that object to be represented on a map. Postcode, Zip code, Longitude and Latitude are examples of such a reference. A mobile application in accordance with the invention can also use geographical references to allow objects to be represented using augmented reality. That is, it can enable the location of an object to be superimposed onto the view through a camera associated with the device. As the user moves the device and views the surrounding world, the objects move to display to the user where in the world the objects are located.

Prediction

The objects in an object library can be used to predict the future. A number of algorithms and processes are known to exist to model and predict future events. However these all specify the data set or sets that need to be used with them. By contrast, the process applied by the present invention allows any object to be applied to a prediction algorithm.

Therefore, because of the process used to create and stored objects in accordance with the invention, they can be presented to an object model without having to change the source data. For example, in the prior art, if data set A is used with a given predictive model, it is not then possible to use data set B if the structure or content varies. However, as the present invention uses a library to represents objects and not raw data, data sets A and B are represented in the object library as objects and can therefore be applied to the predictive model. This allows any source data set to be applied to the model. The invention is of particular use and benefit to:

• organisations, companies or individuals who have data which needs to be analysed or categorised

• database owners who wish to allow other users to analyse their data without giving access to the source data

· Users who want to ask questions about potentially complex data

• Users who want to analyse data with limited or no technical expertise other than, for example, drag, drop and swiping and also users who want to analyse without having to understand how the underlying data is stored or structured.

• Users who want to add their own data and then use other users 'shared' objects rather than create their own

Users of the invention may include: • Technical users with responsibility for data and who want to analyse themselves or give access to others

• Analysts i.e. technical users who want to use the objects to create their own

analysis of the source data

• Non-technical users who want to interrogate, analyse and search data.

Benefits of the invention are numerous, including that it provides:

• an ability to analyse data without constant access to the source data

• an ability to define complex events/scenarios/services/components etc using objects (however, the invention is not an object oriented database)

improved speed of analysis

• Analysis which is only constrained by the number of objects; that is, once all

objects are defined the user is able to analyse anything without needing a specialist to write reports or run queries

• it places a real world key item of focus at its centre. Eg patients, customers,

components etc and then build objects around them

• it will work on any data set

• the concept of sharing objects between users facilitates improved database

manipulation; while the prior art arrangements allow users to share queries and reports, this requires a vast amount of reports to be shared. This may not be what the user needs. By enabling objects to be shared, an object needs only be created once and then a user can create what they require themselves

• as the invention does not require constant access to source data it does not impact on source data performance or degrade its hardware performance

• a specialist does not need to be consulted in order for a non-technical user to create complex analysis

• the user interface of the invention uses objects described in a real world manner combined with intuitive methods such as swipe, drag & drop, menu options and so on.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, "comprises" means "includes or consists of and "comprising" means "including or consisting of. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A database interrogation system comprising:

a library comprising at least one object representative of a database query;

a list of identifiers stored in association with the object;

a list generation component arranged to execute the query on a database so as to generate the list of identifiers.

2. A system according to claim 1 wherein the object comprises at least one attribute.

A system according to claim 1 or 2 wherein:

i) each identifier is a unique identifier relating to an item in the database; and/or ii) the object is or can be associated with one or more further objects.

A system according to any preceding claim wherein the system comprises one or more components for processing or analysing a plurality of lists, each associated with an object, to produce a resultant list.

A system according to any preceding claim wherein:

i) the library comprises a plurality of objects, each object associated with one or more sets of identifiers;

ii) the list generation component is configured to re-execute the query so as to update the set of identifiers; and/or

iii) the list generation component is configured to re-execute the query after a predetermined period of time has elapsed, or at a scheduled time.

6. A system according to any preceding claim wherein the object is defined using a query language such as SQL. 7. A system according to any preceding claim wherein the library comprises a plurality of objects, said objects being organised or capable of being organised into categories and/or a hierarchy. A system according to any preceding claim wherein the object is capable of being tagged or otherwise arranged such that it can be accessed and/or used by more than one user.

A system according to any preceding claim and further comprising:

a graphical user interface arranged to represent at least one of the objects in the library on a screen such that a user is able to control processing of the list, and/or a further list, via the user interface;

preferably wherein:

the user interface is arranged to enable an object in the library to be linked with one or more further objects in the library.

A database interrogation method, the method comprising the steps:

creating an object representative of a database query; and/or

executing the query on a database to generate a list of zero, one or more identifiers; storing the list in association with the object.

A method according to claim 10 wherein:

i) the object comprises at least one attribute; and/or

ii) each identifier is a unique identifier relating to an item in the database.

12. A method according to claims 10 or 11 wherein the method further comprises the step of:

i) associating an object with one or more further objects; and/or

ii) processing the list to generate list-related data;

iii) generating a library comprising a plurality of objects, each object associated with one or more lists;

iv) generating a library comprising a plurality of objects, said objects being organised or capable of being organised into categories and/or a hierarchy;

v) tagging or otherwise arranging the object such that it can be accessed and/or used by more than one user; vi) anonymising the zero, one or more identifiers; and/or

vii) defining the object using a query language.

13. A method according to claims 10 to 12 wherein the method further comprises the step of:

re-executing the query so as to update the list,

preferably wherein the query is re-executed after a predetermined period of time has elapsed, or at a scheduled time.

14. A database interrogation tool comprising a graphical user interface arranged to

display:

at least one object representative of a database query; and/or

a list of identifiers stored in association with the object, wherein the list is the result of executing the query on a database.

15. A database interrogation tool according to claim 14 wherein the interface is arranged: i) to enable a user to control processing of the list, and/or a further list, via the user interface;

ii) to enable the object to be linked with one or more further objects; and/or iii) to allow a user to control processing of the list using a drag and drop facility.