GB2411256A - An extendable associative database and methods for storing data - Google Patents

Abstract

A database structure including: a first table comprising one or more element identifiers and an element type associated with each element identifier; and a second table defining one or more relationships between element identifiers. In the first table, at least one element type may be further associated with an item of element data. The item of element data may be of a form selected from a group including (not exclusively): numerical value; text; alphanumeric string; date; time; flag. Alternatively, the item of element data may comprise a reference to another element identifier. Also provided is a method of storing data in a database, the method comprising: storing in a first table one or more element identifiers, each element identifier being associated with an element type; and defining in a second table one or more relationships between element identifiers. A method of constructing an element of data in a database, and a method of retrieving data from a database, are also provided.

Description

241 1 256

AN EXTENDABLE DATABASE AND METHODS FOR STORING DATA

This invention relates to an extendable database and associated methods for storing data.

BACKGROUND TO THE INVENTION

The relational data model has been one of the principal tools of commercial software development for at least two decades. In this model data is stored in tables, with a table for each type of thing recorded in the system. In each table a column corresponds to some attribute common to all or most instances of the given type. A row represents the particular instance. For each table a set of attributes, known as the key, is specified. Each row in the table is identified by a unique key value. A table may include the key attributes of other tables among its own attributes, so a row in one table can store the key value of a row in another table, representing a link from one instance to the other.

Among the strengths of the model are: Non-technical users easily understand the table-based systems.

The model corresponds closely to the interfaces it supports.

Structured Query Language (SQL) is a powerful, declarative (that is, non-procedural) access language.

20. Correct design ('normalization') minimises the redundant storage of duplicate information.

However, relational systems are rather rigid: In general, data which does not fit a given collection of tables is hard to record.

Missing (unknown or irrelevant) data must be accommodated by defining a 'null' cell value. Exceptional data requires either a column which is frequently empty, or an extra linked table. This can be a particular problem if a standard system has to be adapted for many users.

Each table has its own format, and its data can only be understood by reference to the table definition.

Changing a system over time is difficult, as existing information must be adjusted to fit the new format.

Past versions of data are difficult to store. Versions tend to store redundant information, as the whole record must be saved even if only one field is modified.

Saved records must be modified to fit the current database, or programs must be written to restore past formats.

Further, defining and using keys is non-trivial: Choosing the attributes to form a record key can be difficult. Even if a natural key exists, it may be inconvenient to specify it at the moment the record is created. It is possible (according to many authors it is even advisable) to introduce dummy keys, but users of the system need to be aware of this, and it can cause difficulty for users without technical knowledge. The 'join' operation of SQL to aggregate the contents of related tables is a rather ungainly part of the language.

Differing key formats make it difficult to allow an attribute to be filled by reference to one of several tables. Even if the keys are standardized, links are only implicit, so information must be added to differentiate between tables.

In general, variable formats, both of keys and tables, make it difficult to write generic programs or reusable components.

SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a database structure including: a first table comprising one or more element identifiers and an element type associated with each element identifier; and a second table defining one or more relationships between element identifiers.

The term "table" as used herein should be interpreted broadly, in the sense of a basic unit of storage in a database system. It will be appreciated by those skilled in the art that tables need not be limited to arrangements of rows and columns as illustrated herein.

Preferably, in the first table, at least one element type is further associated with an item of element data.

The item of element data may be of a form selected from a group comprising: numerical value; text; alphanumeric string; date; time; flag.

Alternatively, the item of element data may comprise a reference to another element identifier.

In the first table, each element type may be designated by a corresponding element type identifier, and the system may further include a third table in which element type identifiers are associated with corresponding element type names.

According to a second aspect of the invention there is provided database apparatus incorporating a database structure in accordance with the first aspect of the invention.

According to a third aspect of the invention there is provided a method for storing data, comprising: storing in a first table one or more element identifiers, each element identifier being associated with an element type; and defining in a second table one or more relationships between element identifiers.

Preferably the method further comprises storing in the first table at least one item of element data, said item of element data being associated with an element type.

The item of element data may be of a form selected from a group comprising: numerical value; text; alphanumeric string; date; time; flag Alternatively, the item of element data may comprise a reference to another element identifier.

The method may further compose designating each element type in the first table by a corresponding element type identifier, and storing in a third table element type identifiers and their corresponding element type names.

According to a fourth aspect of the invention there is provided a method of constructing an element of data in a database, the method composing: storing a plurality of element types in the database; and constructing an element of data by forming a compound of element types.

Preferably the method further comprises associating an element identifier with each element type; and constructing an element of data by forming a compound of any element types which share a common element identifier.

Preferably the method further comprises associating one or more element types with a cross-reference to another element identifier; and constructing an element of data by forming a compound of any element types which share a common element identifier and any element types having other element identifiers referred to in a said cross-reference.

Additionally, the method may further comprise associating one or more element types with an item of element data; and constructing an element of data by forming a compound of any element types which share a common element identifier or have another element identifier referred to through cross-referencing, and any associated items of element data.

According to a fifth aspect of the invention there is provided a method of retrieving data from a database, the database employing a database structure in accordance with the first aspect of the invention, the method of retrieving data comprising retrieving those element types which share a common element identifier, any element types having other element identifiers referred to by cross-referencing of their element identifiers, and any associated item of element data.

The database may be accessed via a standardised control interface such as, for example, Open Database Connectivity (ODBC) or Java Database Connectivity (JDBC) using a declarative language similar to SQL. It will be appreciated by those skilled in the art that the database may be accessed by other control interfaces or protocols.

According to a sixth aspect of the invention there is provided a computer program which, when executed by processing means, is operable to perform a method in accordance with the third, fourth or fifth aspects of the invention.

According to a seventh aspect of the invention there is provided a computer program in accordance with the sixth aspect of the invention, stored on a data carrier.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example, and with reference to the drawings in which: Figure 1 illustrates a database comprising a first table (Element Table) and a second table (Structure/Component Table); Figure 2 illustrates a computer (or equivalent processing means) in communication with the database of Figure 1; and Figure 3 is a flow diagram illustrating a method by which data may be stored in the database of Figure 1.

It should be noted that the data shown in the example tables in Figure 1 are extracted from the more comprehensive Tables 2.9a and 2.9b given in the following description of preferred embodiments.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present embodiments represent the best ways known to the applicant of putting the invention into practice. However they are not the only ways in which this can be achieved.

1 Overview and derivation of the new model, XRDM A simple example is used to introduce a transformation of the traditional model to a new model which embodies the present invention. The new model preserves the strengths of the traditional model, but yields a much simpler storage structure which is flexible and is capable of being processed by simple standardized procedures. The new model can be regarded as an extendable relational data model and is referred to herein by the term "XRDM".

1.1 Overview Example 1 The following tables, Tables 1.1a and 1.1b, illustrate part of a simplified example of a table- based order system: Customer Customer number Customer name Smith Brothers Ltd. 873 Fred Jones

Table 1.1a Order

Order number Order date Customer number 6111 29.07.2002 145 6118 15.08.2002 145 9654 28.11.2002 873

Table 1. 1b

A typical query might be 'Who placed an order on 28.11.02 ?' A user or application can only access the name of the customer by knowing that the customer number links the order found to the customer record.

The first step is to number each line uniquely (and arbitrarily), as shown in Tables 1.2a and 1.2b: Customer Customer number Customer name Smith Brothers Ltd. 1 1 873 Fred Jones

Table 1. 2a Order

Order number Order date Customer number 6 6111 29.07.2002 145 6118 15.08.2002 145 12 9654 28.11.2002 873

Table 1.2b

The record numbers can then be listed with their types (Table 1.3): Record Type Customer Order 9 Order 11 Customer 12 Order

Table 1.3

and their contents (Table 1.4): Record Column Type Content Customer number 145 Customer name Smith Brothers Ad.

6 Order number 6111 6 Order date 29.07.2002 6 Customer number 145 Order number 6118 9 Order date 15.08.02 9 Customer number 145

Table 1.4

These steps have standardised the representation of data in the tables, but the linkages are still only implicit in the data. The fact that (Customer number, 145) appears in records 5 and 9 links the customer 'Smith Brothers Ltd.' with the order placed on 15.08. 02, but any user of the system needs to remember that customer and order are linked by customer number.

Directly recording the fact that order record 9 uses customer record 5 removes the need for any user to know the detailed form of the linkage. Indeed it removes the need to decide in advance that the customer number is the key of a customer record.

Further, if column content pairs from Table 1.3 are individually numbered the usage of data and references to other tables can be handled consistently: Number Column Type Content 31 Customer number 145 32 Customer name Smith Brothers Ltd. 33 Order number 6111 34 Order date 29.07.2002 37 Order number 6118 38 Order date 15.08.02

Table 1.5

This table can be combined with Table 1.3 to give: Number Record/Column Type Content Customer 6 Order 9 Order 11 Customer 12 Order 31 Customer number 145 32 Customer name Smith Brothers Ltd. 33 Order number 6111 34 Order date 29.07.2002 37 Order number 6118 38 Order date 15.08.02

Table 1.6

and Table 1.4 becomes: Record Record/Column 32 6 33 6 34 6 5 9 37 9 5

Table 1.7

Since the relationships between order and date and order and customer are held in exactly the same form, that of usage, no special mechanism is needed to link information from separate Stables'. Once the link to customer has been made, the same mechanism can also bring in the customer name and number.

A query such as 'Who placed an order on 28.11.02 ?' can be answered by: finding Orders with links to Order date 28.11.02; following the link from each Order to Customer; and following the link from each Customer to Customer name There are some refinements to allow for more complicated relationships, considered below, but the core of the system is: A table of numbered elements (as in Table 1.6) and a table recording the fact that one element is a component of another (as in Table 1.7); and A standardized procedure for following links.

The preceding discussion shows that it is possible to map tables and the links between them to a standardised form. It should also be apparent that dealing with missing or exceptional data is unproblematic. Data which is unavailable or irrelevant for a particular element simply does not appear as a component. Exceptional data can be added as a component for one element without any impact on other elements of the same type. Similarly new requirements can be adopted without having to modify existing data. Changes can be recorded at the cell- level, so it is easy to observe the history of those changes, and archive only those changes.

Beyond rectifying some 'technical' problems of the relational model, XRDM also supports another form of relationship in a more intuitive way than does the original. To see this, consider a more realistic extension of the above order system, containing products and order details, as described in Example 2: 1.2 Overview Example 2 Product Product number Product name Unit Price 5111 Hammer 1 615,56 5117 Paintbrush 1 64,25 7654 Paint 2,5L 69,88 9543 Nails 50 60,59

Table 1.8a

Customer Customer number Customer name Smith Brothers Ltd. 873 Fred Jones

Table 1. 8b Order

Order number Order date Customer number 6111 29.07.2002 145 6118 15.08.2002 145 9654 28.11.2002 873

Table 1.8c

Order line Order number Line number Product number Quantity 6111 1 5111 1 6111 9543 4 6118 1 9543 2 9654 7654 2 9654 5117 1

Table 1. ad

As before, each record and item of data can be numbered: Number Label Content Product 2 Product Product Product Customer 6 Order Order line 8 Order line Order 11 Customer 12 Order 13 Order line 14 Order line Product number 5111 16 Product name Hammer 17 Unit 1 18 Price 615,56 19 Product number 9543 31 Customer number 145 32 Customer name Smith Brothers Ltd 33 Order number 6111 34 Order date 29.07.2002 Quantity 1 36 Quantity 4 37 Order number 6118 38 Order date 15.08.02

Table 1.9

Note that the original line number has been discarded. It could be useful for controlling display and printing sequence, but any comments in this regard can also be applied to other attributes. Its function in providing unique addressing for the record is now taken by the standardized record number.

The links between elements and between elements and data can then be extracted: Record Record/Column 1 15 1 17 1 18 32 6 34 6 7 7 35 6 8 8 2 8 36 9 37

Table 1.10

Not all element linkages have been transformed as before. The usage of the customer number from record 5 in order record 9 is directly recorded, but this is not the case for the appearance of the order number from record 6 in records 7 and 8, which represent order lines. In addition to discarding the original line numbers, the usage here has been reversed.

XRDM effectively treats order line as a multivalued type of component, which seems intuitively reasonable.

This reorganization occurs when the linkage between tables represents a parent-child relationship with multiple children. The tables of the relational model do not inherently differentiate between 1-N parenVchild relationships and simple N-1 references (N orders can refer to any 1 customer.) The relationship can be inferred from the primary keys, since the child key usually consists of the parent key and a further identifier which need only be unique over children of the same parent.

Two tables in a relational model with completely identical keys usually indicate that one table provides additional information which is only relevant for some subset of the entries in the other. It may be appropriate to regard this extra table as a child component, but XRDM supports two further forms of linkage, based on identity and extension. The meaning and advantages of these forms depend to a significant degree on the access methods of XRDM, so discussion is deferred until these methods are introduced. s

XRDM is sufficiently close to the relational model to support existing methodologies and interface styles. The storage of information is much simpler - tables and the linkages between them are maintained in a consistent fashion. The linkages themselves can be made more flexible. Structural information is stored with the data, so that non-standard information and structural changes can be accommodated.

1.3 References Connolly, Thomas & Carolyn E. Begg, Database Systems: A Practical Approach to Design, Implementation and Management, Addison-Wesley, 2001 Date, C. J., An Introduction to Database Systems, eighth edition, Addison-Wesley, 2 Further (more detailed) embodiments The following describes further embodiments of a database structure which embodies the present invention. The storage form and its interpretation are explained, as are the operations which support using the data.

2.1 Storage model

Element Table

| Element Id1 | Type | Element Id2 or Data or Empty |

Table 2. 1a

Element1's type is specified, and it may further be related to another Element or to Data. In the following discussion this relationship will be interpreted as Element1 'extending' Element2 or the Data, but it may be helpful to consider an entry in this table naming or renaming the element or data.

Structure/ComPonent Table | Element Id 1 | Element Id2 l

Table 2. 1b

Element2 is a component of Element1, or Element1 'has' Element2

2.1.1 Example

Element Table

Element Id Type ElemenVData 4711 Firm 9165 Name Jones Engineering |

Table 2. 2a

Structure/Component Table Element1 Element2 | 4711 9165

Table 2.2b

An entry with the last column empty is often equivalent to a table or entity in other database systems.

There are various ways of expressing the relationship in natural language: the firm has the name 'Jones Engineering' the name ofthe firm is 'Jones Engineering' the firm('s) name is 'Jones Engineering' 2.2 Relationships between elements Element Ids are purely arbitrary, meaningless to any human user of the system. They serve purely to record the relationships between the elements, and ultimately between data items, which are meaningful to the user.

In the above example an element Id represents some data, and two elements are linked by the structure-component relationship. There are two other relationships which the model can represent. One element can extend another, and entries may share the same Id.

2.2.1 Example

Element Table

Element Id Type ElemenVData 4711 Firm 4712 Customer *4711 1256 Customer 1256 Person

Table 2.3

Both firms and people can be customers. The Id 4712 represents a customer which is an extension of the firm represented by Id 4711 (the element Id is denoted by a * to distinguish it from the number 4711 as data). The same element Id 1256 denotes both a customer and a person. The implication of these relationship forms for data retrieval is further discussed below.

2.2.2 Consistency Structure, component and extended element Ids must be defined in the element table, and every element must have a type. Duplicate (Element Id1, Type) and (Structure, Component) pairs add no new information and complicate retrieval routines, so these are not allowed.

2.3 Types In an XRDM implementation arbitrary identifiers will also represent types. This allows type names to be modified later, or perhaps translated, without affecting the stored information.

S The element information: Element Type ElemenVData 4711 Firm 4712 Customer *4711 1256 Customer 1256 Person 9165 Name Jones Engineering

Table 2.4

will be stored as:

Element Table

Element Type Id ElemenVData 4711 11 4712 43 *4711 1256 43 1256 12 9165 Jones Engineering

Table 2. 5a

Type Table

Type Id Type Name 2 Name 11 Firm 12 Person 43 Customer

Table 2.5b

Further information can be added to the type. In particular, datatypes types describing elements which extend data - must provide additional information to support processing.

Datatypes must at a minimum indicate how data is stored and represented to the user, but may also support comparison or computation.

The representation of types in a table should be regarded loosely. Individual systems will probably impose constraints on allowed combinations of types for semantic reasons, and it is likely that some other storage format, such as XML, will prove more suitable for representing such constraints. Mechanisms for enforcing constraints are not further considered here.

In general the mapping of type names to Ids is straightforward and for discussion purposes it is simpler to refer to types by their names. This convention is followed unless there is particular reason to mention the internal representation.

2.3.1 Child types A type may be defined to be a child of another (nondata) type. This allows names for type names to be reused. Elements with such types only appear as components in elements of the parent type.

2.3.2 Examples

Firm', 'Person' and 'Customer' above are types. 'Name' is a simple datatype, as any values can be stored as strings which are displayed to the user without further editing. An alternative might be to define a 'Name' type as a child type of firm ('Firm.Name'), if the stored name required non-standard editing here, for example.

Child types are more useful than might at first seem apparent. For example, an order will often be placed on one day and delivered on another, and a system must record both.

Element Table

Element Id Type ElemenVData 1234 Order 1235 Order. Placed *1236 1236 Date 25.08.02 1237 Order. Delivered *1238 1238 Date 04.09.02

Table 2. 6a

Structure/Component Table Structure Component 1234 1235 1234 1237

Table 2.6b

The'.' in the name here denotes the parent-child type relationship. Each child type will have its own Id, so the above element table would be stored as:

Element Table

Element Type Id ElemenVData 1234 92 1235 994 *1236 1236 25.08.02 1237 995 *1238 1238 04.09.02

Table 2. 7a

Type Table

Type Id Type Name Parent Type 92 Order 994 Placed 92 995 | Delivered 192 l

Table 2. 7b

The names 'placed' and 'Delivered' can be reused in other situations as required.

The fact that the child extension acquires an element of its own can also be useful. For example, people attend a meeting.

Element Table

Element Id Type ElemenVData Person 111 Name Bob Smith 152 Person 153 Name Marion Jones 4711 Meeting 4712 Meeting.Attendee *110 4713 Meeting.Attendee *152

Table 2. 8a

Structure/Component Table Structure Component 111 152 153 4711 4712 4711 4713

Table 2. 8b

If the system needs to record that Marion Jones chaired the meeting, it can do this by adding a component for 'Role' to the 'Meeting.Attendee' element Id 4713.

The possibility of system changes makes including default child types advisable. If Order.Date' already exists for components of 'Order', it is easy to rename this as Order.Placed' if the system later needs to record delivery. This is more difficult if dates are direct components of orders.

2.4 Aspects and Inheritance Entries with the same element Id can be regarded as representing different aspects of the same thing. Any references to elements are represented by the Id, and there is no way of specifying that one version or another of the Id is intended. Significantly, a reference is of a particular type, if any of the elements are of that type, regardless of how the reference was originally defined. Similarly, the storage model provides no way of marking components as belonging to one version of the Id. Once a component is added, it belongs to all the entries with that Id.

One or more aspects of an element can be extensions of other elements. The original element inherits the characteristics of the extended element in this case. It acquires all its components, and any types - the extended element Id might also be shared. Inheritance is recursive, but only runs in one direction. Extended elements do not acquire characteristics from the extending element.

2.4.1 Expanding references It is useful to make the concepts aspect and element more precise. In the following an aspect refers to an entry of the form type extended element Id I data I empty specified by an element Id. Any element Id will specify one or more aspects.

Since the aspects specified by given Id can contain extended element Ids, and the characteristics of extended elements are regarded as describing the original Id, the aspects of any extended element can be regarded as aspects of the original Id. This process could in theory extend to any depth, although it is in practice unlikely to involve more than two or three levels. Regardless of the number of levels, the process must eventually reach an element Id which identifies only data or empty types.

Given an element Id, it is useful to construct the complete list of aspects which either share the original Id or share an extended Id at any level. This list allows the type of the element to be checked, since the element is of a given type if any of the aspects in the list have this type. It also allows all the components of the element to be found. All components identified by element Ids from the list of aspects must be added to the list of direct components identified by the element Id.

It is useful to regard an element as the combination of an element Id and the list of aspects it directly or indirectly specifies. An element is of a given type if any of its aspects is of that type. An element's components consist of all component Ids specified by the original Id directly, or by any Ids in its aspects.

2.5 Accessing data As noted, element Ids have no direct meaning to a user of the database. They serve only as links to other elements, and ultimately to the data, which does have external meaning. The user must thus have access to methods which use data to specify the elements of interest, and which are able to extract the data elements related to a selected element. The user should not need to know how the links expressed by the element Ids are being navigated.

An attribute is an ordered list of types which specifies the sequence of links to be followed.

In the following, attributes will be written as 'type1.type2 typeN'. (An alternative would be 'typeN of typeN-1 of... type1', so 'Date of Birth' instead of 'Birth.Date'. Following normal English usage, compounding is preferred, but interfaces in different languages could conceivably accept a form with prepositions.) In cases of ambiguity, a child type should be preferred to the global type. For example, if 'Order.Date' exists as a child type, then the attribute 'Order.Date' has 'Order.Date' rather than 'Date' as second type after the first type 'Order'.

2.5.1 Simple attributes The value of an attribute for a particular element is a list of elements, calculated as follows: If the attribute has length zero, then the value is the element itself.

If the attribute is of length one (a single type), the value of the attribute consists of all elements of the required type which are components of the given element.

Extensions to elements must be considered for both the original element and any components, because components are inherited, and because the type of the S component depends on its aspects.

2.5.2 Example

Element Table Element Id Type ElemenVData Customer Customer. Number A12345 126 Name

Jones Engineering 500 Product 501 Name Hammer 511 Product 512 Name Nails 4711 Order 4712 Order. Number 5998/2002 4713 Order.Placed *4714 4714 Date 25.08.02 4715 Order.Delivered *4716 4716 Date 05.09.02 4717 Order.Customer *120 4720 Order. Line | 4721 | Order.LIne l

Table 2.9a

Structure/Comoonent Table Structure Component 125 126 500 501 511 512 4711 4712 4711 4713 4711 4715 4711 4717 4711 4720 4711 4721 4720 500 4721 511

Table 2. 9b

Data extracted from these tables is shown for illustrative purposes in Figure 1. Figure 1 depicts a database 10 which includes a first table 12 (entitled "Element Table") and a second table 14 (entitled "Structure/Component Table"). The first table 12 and second table 14 are adapted from the above Tables 2.9a and 2.9b respectively.

The order has attributes 'Order. Number', 'Order. Placed', 'Order. Delivered', 'Order.Customer' and 'Order.Line' as direct components. 'Order.Line' is double-valued. It also has the double- valued attribute 'Date' because both 'Order.Placed', and 'Order. Delivered' extend elements with this type.

The customer has name and number. The products have names.

2.5.3 Compound attributes To obtain the value of an attribute of length two, the value for the leading type is first calculated. For each element in this result, the values for the second type are then aggregated. This list is the value of the length-two attribute for the original element.

Values of attributes of successively greater length are similarly given by finding the value of a type for a previous list of elements and aggregating the results as the start point for the next level of the attribute. The calculation can be abandoned at any stage where the aggregated list is empty.

The form of the attribute definition resembles addressing instructions in models which actually store their data in hierarchical form, such as XMLdocuments. The hierarchy here is however only implicit in the links between elements, is flexible and can be assembled as required. Any element which contains a product, for example, has a 'Product.Name' attribute.

2.5.4 Example

From the above, the order has the value 'Jones Engineering'for attribute 'Customer.Name' and the pair ('Hammer', 'Nails') for attribute '(Order.) Line.Product.Name'.

2.5.5 Unconstrained attributes The above defines attributes relative to some given starting element, but the idea can usefully be extended to an attribute with no previously specified structure. The value of the length zero attribute is undefined, but an attribute of length one has all elements of the given type. Thereafter, the values of compound attributes are calculated as before.

2.5.6 Example

Name' has values ('Jones Engineering', 'Hammer', 'Nails'); 'Product.Name' has only ('Hammer', 'Nails').

2.5.7 Shared Ids The meaning of the 'shared Id' relationship is again worth emphasising. Since components belong to the element Id, and not to a particular entry, entries with the same Id share ALL their attributes. To compare this with extension: the extending element acquires all the attributes of the extended element, but the extended element acquires nothing from the extending one.

2.5.8 Example

An order system models customers, which can be firms or people. A customer has a number. A firm has a name and registration number; a person has a name.

Using shared Ids:

Element Table

Element Id Type ElemenVData Firm 11 Registration 1 23-456 12 Name Jones Brothers Ltd. Person 21 Name Joe Samuels Customer 31 Customer. Number 12233 Customer 41 Customer.Number 14509

Table 2. 10a

Structure/Component Table Structure Component 11 12 21 31

Table 2. 10b

and with extension:

Element Table

Element Type ElemenVData Firm 11 Registration 123-456 12 Name Jones Brothers Ltd. Person 21 Name Joe Samuels Customer *10 31 Customer.Number 12233 Customer *20 41 Customer. Number 14509

Table 2. 11a

Structure/Component Table Structure Component 11 12 21 31 41

Table 2.1 1b

Both systems can find the name 'Joe Samuels' for the customer with number 14509, but only the first returns 'Customer.Number' 12233 for the firm with registration '123-456'.

2.6 Working with attributes Testing and displaying attributes are the basis of a functional system. A user of the system can find relevant data by testing the values of an element's attributes, and display these attributes or other related ones. Testing also identifies the target for modifications.

XRDM can use any comparison supported by the type to test the results against constant data or other attributes based on the same type. For elements of all types, XRDM can test whether an element is of a particular type, or represents the same element as another result.

Test results can be combined with the usual Boolean operators (not, or, and).

To provide usable results XRDM must be able to display or print the values of attributes.

Only data elements inherently have displayable representations, as determined by their respective datatypes. Representations of structures, in terms of their data components, are discussed below.

Attributes are potentially multivalued. At each stage in the evaluation the result is a list, which may contain zero, one or more elements. This implies that any operations supported by an interface must allow for setor list-based functions. Such functions are to a great degree derived from operations on the elements. For example, listing a set is largely a matter of convention, once the output form of an individual element is determined.

Comparing sets or testing membership depends on defining element equality. For this reason, explicitly set-oriented processing is unlikely to be a major area of difference between XRDM and other database systems. This observation applies equally to the use of Boolean operators to combine tests.

Tests based on the values of single elements are useful if the attribute is expected to be single-valued. An attribute should pass a test if the element found passes it. In the event that the attribute is empty or multvalued, the result of such a test is strictly undefined.

However, a prototype implementation which regarded such cases as simple failures delivered sensible results.

2.7 Working with elements As before, an element is regarded as an Id with an expanded list of aspects. An element is of a given type if any of its aspects is of that type. For other purposes, attention can be restricted to those aspects which do not extend other elements. An element must have at least one such aspect, containing a type and, optionally, data, since these aspects terminate the expansion.

An aspect which contains data can be manipulated in any way supported by the datatype.

Most datatypes will at least support some definition of equality. Text and numeric types can also allow greater-than-less-than comparisons and text can provide search functions. Some datatypes will support arithmetic or other operations. If an element contains an aspect which satisfies a test supported by the datatype, then the element satisfies the test.

An element can be tested against data specified by the user of the system, or against another element. If an element contains data of the type specified by the user, or if elements both contain data of the same type, this data can be compared in any of the ways supported by the datatype. However, it is also possible to test whether elements represent the same thing. Testing whether two elements are identical does not depend on data, so can be applied to elements of any type.

2.7.1 Examples

In the above order system, a user might need to find all orders placed on the 25.08.02. By manipulating and comparing placement and delivery dates, a user can identify orders which were not fulfilled within a month. Once two orders have been identified according to some criteria, a user can check whether the same customer placed them.

2.8 Database operations At a basic level a database engine must be able to add or remove entries from the two tables. A component may be removed at any time; an element only if the Id is no longer used elsewhere, either as a component or by being extended. The table entries do not need to be modifiable. Changes in the database are recorded by deleting components and inserting new ones. A record may be physically deleted, or marked as logically deleted. The latter makes reversing unwanted changes possible.

Components of a deleted structure, and any child elements, are unusable but they do not have to be deleted directly Indeed, if element records are only logically deleted, leaving components unaltered allows the structure to be reinstated simply.

If records are only logically deleted, or unused components are allowed to remain in place, the system should periodically be reorganised to prevent excessive use of space. Unused data elements can also be removed, because they can be re-created at any time if necessary. This does not apply to non-data elements. For example, details about a firm do not become irrelevant merely because the firm is not currently referenced by other elements of the system. An application must specifically decide when to remove unused non-data elements.

2.9 System interface As noted above the element Ids are meaningless to users of the database, whether these are human or other computer systems. Only data elements have any intrinsic meaning outside the database. An interface can save element Ids for short term processing, but in the end it must translate elements and their relations into usable data, or follow user instructions to manipulate the relationships stored in the database.

XRDM was designed as a more flexible version of the table-based relational database system. Since this model is well known and has an intuitive text-based query language, SQL, the examples are based around a variant of this language. Although instructions available to a screen- based system may be ultimately more flexible, most of the steps necessary to build an interface can be illustrated by considering these text instructions.

Significantly the variant supports queries over multiple types by using XRDM attributes, and does not require (table-)joins. XRDM's storage of the links between elements allows the linkage-following algorithm of attributes to access data in related elements.

2.9.1 Building lists of elements The following useful SQL-like fragment defines a list of elements attr1 WHERE attr2 condition AND/OR attr3 condition...

by calculating and testing the attributes attr2, 3, ... for the list of elements given by attr1, and accepting or rejecting each item. Attribute attr1 can refer to a previously defined element, or be unconstrained as discussed above. If attr1 is unconstrained the list contains elements which exist independently of other elements. Such lists are therefore referred to as 'entity lists' in the following.

2.9.2 Displaying elements Using the list-building instruction from above: SELECT (list1, list2... FROM) entity list calculates and displays or prints the attribute-values for each element in the list, or the element itself when no attributes are specified. The output can thus be viewed as a table, although each cell may be multivalued or empty.

2.9.3 Adding data A user interface can insert a new element of a particular type, or an item of data: (NEW) type (new can often be deduced from the insert context, see below) datatype = constant value These statements are not particularly useful in isolation. Creating an element with no relationship to anything else is unlikely to be sensible, and, as noted above, data elements can be created as necessary, so an unrelated one is superfluous.

Extending an existing element or sharing an existing Id relates elements to one another, and so is more useful.

type EXTENDS entity list type IS entity list All these instructions can, however, be regarded as delivering a list (often with a single- element), and, in conjunction with the list instructions above, can support an instruction which builds structures.

INSERT entity list (AS child type) INTO (list FROM) entity list Each element in the first list becomes a component of the structures produced by the second. The addition of an 'AS' clause locally extends ('renames') the element in the first list, and adds this extension as the component.

A simple type name in place of an entity list, or (list FROM) entity list can be defaulted to NEW type, as mentioned above. It is unlikely that both lists would be defaulted in this way, since it would produce a relationship between the two new items, but no relationship to any userreadable data.

2.9.4 Recursive insertion Inserting data into child substructures presents a particular problem for a text-based interface. The system must be able to add identifying data to the child as it is created. A possible extension to standard SQL is the keyword WITH in the 'NEW type' clause. s

INSERT NEW line WITH product = ... INTO order WHERE...

2.9.5 Removing data Removing data broadly follows the pattern for displaying it.

DELETE list1, list2... FROM entity list removes the links from structures in the entity list to their components in list1, lists, ....

Local extensions could be deleted directly, or this responsibility could be left to a garbage collection routine.

Links can always be removed, but deleting elements without testing their usage could leave the database inconsistent.

DELETE entity list deletes the qualifying elements themselves, but only if the elements are unreferenced.

2.9.6 Modifying data Modifying data is a combination of removal and new insertion. The instructions INSERT entity list (AS child type) INTO (list FROM) entity list and UPDATE (list FROM) entity list SET entity list (AS child type) should result in the same data being present in the database after the instruction runs. The UPDATE should also remove conflicting data first. Data with the same type as the SET-list, or as the child type, conflicts with the new data. It should be noted that this compressed DELETE, INSERT may be difficult to use correctly if the SET is inherently multivalued.

It is very important to note that UPDATE works by removing and adding links to elements in the target list; elements replaced by the SET list are not themselves modified.

2.10 User Keys An important feature of the foregoing discussion is the fact that any attribute, or combination of attributes, is equally valid as a means of specifying and accessing data. The database designer does not need to define any particular attribute as a key. This can be useful if no simple combination of attributes is recognised by users as an obvious identifier of an element, for example, if the combination changes over the element's life cycle, or if different users need different identifiers.

In the first case, consider a system recording the details of project meetings. Users might need details of a meeting on a given day, or when a particular topic was discussed, or when a meeting was attended by a particular set of people, but would seldom have memorised a meeting number.

The second and third cases can be illustrated by considering an order system. Orders may eventually acquire an order number to allow for processing, such as accounting, far removed from the original data collection. For the salespeople, however, this number may be completely irrelevant, or even irritating if it is possible for orders to be combined or abandoned. A salesperson's criteria for identifying an order could be a combination of customer, product and date, and as long as a given order can be found again, this is a sensible key combination.

Most current database systems deal with such situations inelegantly. They require a unique key for a table, and since this key is used to relate tables to one another the key must be specified very early in the life cycle of a table entry. Thus programs have to ensure that meeting or order numbers are allocated as the entries are created, and programmers and users need to be aware of them in querying the database. Use of alternative identifiers requires special processing.

XRDM also assigns Ids as elements are created, but these are meaningless except in links between elements, and are hidden from all users of the database. This does not, however, imply that the concept of user keys is discarded. They are still useful, but XRDM allows them to be used more flexibly.

2.11 User interface As noted above, a selected attribute may not be directly displayable. Thus it may be useful to have a standard combination of attributes which is displayed in this case. The same idea applies to the selection of elements. A user can identify a non-data element by specifying a combination of data values.

2.11.1 Example

If the firm's registration number has been defined as a key, and cities are keyed by name SELECT Firm WHERE Address.City = 'London' can be used instead of SELECT Registration FROM Firm WHERE Address.City.Name ='London' Note that the display can dynamically decide which attributes to apply, so users who regard different attribute combinations as the key to firm could potentially run the same query. This observation obviously does not apply to the identifying clause for city, but a screen-based interface could generate a form asking the user for his or her chosen identifier.

Screen-based interfaces can also offer search functions to enable a user to find a desired element, either in order to display its details or to enter it as a component in another structure. Such search functions are usually built as sorted lists of key attributes.

2.12 Database access If a particular combination of attributes is frequently used to identify elements of a given type, it may be efficient in a large database to store the values of the occurring combinations with direct pointers to the elements they identify. This concept corresponds to the indexes frequently seen in other database systems. Since fast access usually requires that keys be sorted, such a system simplifies the building of search functions as described above.

2.13 Data integrity This document has not discussed semantic rules in any detail. Any realistic system is likely to depend on keys to define uniqueness, and to automatically prevent duplication. However, XRDM allows more flexibility than is usually found in current databases. In the order system described above, an order number would be unique, once specified, but the salesperson's combination of customer, product and date need not be. A salesperson should probably be warned that an order has been created which might be a duplicate, but it is not inherently wrong. Two orders for the same product could be received from the same customer on the same day. If they really are identical, it does not matter which is selected for further processing - including being given a unique identifier- if, say, the customer confirms one order.

3 XRDM Simple Implementation As shown in Figure 2, the database 10 may be accessed and managed using a personal computer 20 or other suitable data processing means, forming a database system for storing and manipulating data. Data may be transferred between the database 10 and the computer 20 via any suitable data communications connection 22, which may incorporate a network.

3.1 Storage model The basic steps by which data is stored in the database system are illustrated in Figure 3.

* One or more element identifiers are stored (30) in the Element Table (the "first table"), each element identifier being associated with an element type. At least one item of element data may also be stored (32) in the Element Table, said item of element data being associated with an element Id and type. One or more relationships between element identifiers are then defined (34) in the Structure/Component Table (the "second table").

in practice, an implementation of this model preferably stores the following information:

3.1.1 Element table

A list of elements of the form: | Element Id | Type | Element id or Data or Empty l Element Ids are purely arbitrary. Depending on Type, the Element can optionally refer to another element, or contain data. Data is in itself meaningful, for example, quantities, monetary amounts, dates, text or flags (e.g. identifying the status of an entity as ON or OFF.) 3.1.2 Structure component table A list associating components with structures: | Structure Element Id | Component Element Id Element Ids exist in the element table.

3.1.3 Type information For logical purposes type could be represented in any way which allows the type of an element to be tested against a given type.

In practice, to support any sensible interface, the implementation must be able to store: | Type Id | Type name | Data Implementation or Empty | The Type Id will appear in the Type column of the Element table. If the type requires data, then the type must provide details of the programs needed to manipulate data items. For example, dates are often stored and displayed in different formats, and a 'Date' type must indicate how mapping should be performed. Programs to test for the equality of two data items, or otherwise compare them, may be required.

3.2 Supported operations To maintain information the system must be able to: Add an element of a given type to the stored list, with reference to an existing element or data, if required. The addition should allocate an Element Id for the new element.

Add and remove a specified element as the component of a structure.

Elements themselves should not be modified, and can only be removed if they are no longer referenced. This 'garbage collection' is not fundamental to the system's operation.

To manipulate existing information the system must be able to: find the entries corresponding to a given Id, test whether each is of a specified type, and return the referenced Ids or data access all elements of a given type access all components of a given structure apply tests to and display the information 3.3 Possible implementation Elements can simply be appended to a file. The length of data items differs from item to item but cannot change once the element is created, since data is immutable. A record cannot change length, and neither can its predecessors, so position is also fixed until the complete file is reorganised to remove unused elements.

Although searching the complete file for element Ids is possible, performance demands will almost certainly require an index of Ids. This can be implemented with a simple B-Tree (for example, see The Art of Computer Programming in the references below), recording the position of the corresponding record against its Id. Similarly, indexing records by type, improves the performance of this access function. The (B-Tree) index must thus support duplicate keys.

Indexing simplifies the storage of the structure-component information. In fact, it is sufficient just to store an index of structure Ids pointing to the positions of the component Ids. Again keys may be duplicate. Adding a component to or removing it from a structure just requires adding or removing an index entry.

Type information must be accessible by name to support a user interface. Depending on the scale of the system and the level of semantic checking required, there are a variety of possible implementations. A simple properties file or an indexed file could be sufficient.

Alternatively more complex information could be represented using an XML dialect. Object orientated languages offer a simple way of implementing the processing of data types. An interface defines the operations required to manipulate data - transformations, checking, and so on - and each data type need only retain the name of a concrete class which implements this interface.

In relational terminology datatypes are 'domains'. In Foundation for Future Database Systems Date & Darwen discuss representing domain data by objects from a class corresponding to the domain, and the possibility of hierarchical domains corresponding to class hierarchies. These ideas carry over to XRDM datatypes. Date & Darwen also make further interesting observations on relational and object-oriented databases which suggest useful approaches to modelling type relationships in general.

3.4 Navigating the database Navigating the links in the database is the basis of any implementation. It must be able to build the list aspects of any element Id, and evaluate attributes.

3.4.1 Expanding elements To construct the list of aspects: Read the one or more aspects directly identified by the element Id from the element

table into the list.

S Read the list sequentially. If an aspect extends another element Id, then add its aspects to the list.

As long as adding to the list does not disturb the read operation, all aspects which extend element Ids will eventually be processed. At some point, only aspects without extensions will be added and the process will terminate when the end of the list is reached.

3.4.2 Evaluating attributes An attribute is a list of zero or more types.

For a given element Id in a database, the value of the attribute is a list of elements, to be derived as follows: Construct the element from the Id, as described above. Set up a starting list containing this one element.

For each type from the attribute in turn: Set up an empty list of elements as the result 20. For each component of each element in the starting list: o Construct a new element (Id + aspects) c If any aspect is of the required type, add the new element to the result If the result is still empty, then stop. Otherwise, if there is still another type, use the result as the next starting list.

3.4.3 Length-Zero and Unconstrained Attributes The above algorithm evaluates length-zero attributes correctly. The list of expanded aspects for the element is built and the algorithm stops.

The initialization step for an unconstrained attribute is slightly different. The starting list contains all elements with an aspect matching the first type of the attribute For this reason length-zero unconstrained attributes are undefined, and in practice most such attributes will consist of a single type, used to construct entity lists. In any practical implementation it will be necessary to index entries by type, so that element Ids can be read directly. The full list of aspects for these Ids must still be checked to construct the starting list of elements.

3.5 Working with data An implementation must do little more to support an interface at least as comprehensive as the SQL-like prototype. A user must be able to construct the statements and have them executed (see Command Pattern in Design Pattems). A relatively simple text parser is sufficient to enter instructions, although more comfortable interfaces are easily conceivable.

An SQL-like implementation would be a basis for adapting XRDM to deliver results capable of being processed by tools using ODBC/JDBC to access a database.

The statements are all based on constructing and manipulating lists of elements. Lists of existing elements are constructed using the above algorithms, usually beginning with an entity list. Once an element has been constructed, tests can be applied to determine whether it is relevant for the list. Such tests may require attributes of the element to be constructed, again using the methods above. An implementation must support set-based operations on lists of elements and Boolean operations on test results. Manipulating and testing data involves mapping operations to methods of the classes used to implement datatypes. Since testing data usually expects an attribute to be single-valued, a policy (for example, always fail) must be implemented for multivalued results.

The contents of a list, or of further attributes based on the list, can be displayed by invoking display methods of the datatype implementation onthe data aspects of the elements.

Following SQL, the results can be displayed as a table, with a one row per list element, and a column per attribute. The implementation must define a convention for multivalued and empty attributes.

Database manipulation instructions support variants which explicitly create new elements or aspects, but otherwise use lists extensively. The user instructions map straightforwardly to instructions on the underlying storage.

3.6 Alternative implementations and enhancements There are useful alternatives to the iterative algorithms shown above for evaluating expanded elements and attributes. Some programming languages or coding styles might prefer the equivalent recursive algorithms. More significantly, queries will frequently need to evaluate several attributes for a given element Id. In such cases it would be more efficient to test any components against all first level types at once, accumulating the results for the respective attributes. Caching intermediate results in the evaluation may also be useful in some circumstances.

In a large database it is likely to be more efficient to implement tests against constant data in a 'bottom up' style. That is, find data entries which satisfy the test requirement, and then reverse the algorithms to identify the elements of which they are attributes. For such an approach to work effectively it would be necessary to index data. Using the above simple data store, a combination of datatype and data would be used to access the position of the corresponding entry. This extension suggests the idea of indexing other frequently-used attributes directly. A given value of an attribute could point directly to the positions of elements containing that value. Building an index of such attribute values, or conceivably combinations of attribute values, would improve access times and also easily support sequenced display of information.

Knowing which types of elements can be accessed by which combination of attributes also allows the value of the attributes to be substituted for the element automatically, if the result of a query is an element which does not contain data.

3.7 References Date, Chris, & Hugh Darwen, Foundation for Future Database Systems: The Third Manifesto, Addison-Wesley, 1998 Gamma, Erich, Richard Helm, Ralph Johnson, John Vlissides Design Pattems, Addison-Wesley, 1995 Knuth, Donald, The Art of Computer Programming: Sorting and Searching, Addison Wesley, 1998

4 Comparison with prior art systems

The present invention is not the first system which represents data in such a simple form.

Prior art includes existing "triple store" databases, and the Sentences (RTM) development environment and database management system provided by Lazy Software Limited and based on its "Associative Model of Data" as described in GB 2 360108 B. The principal difference between this prior art and the present invention is the interpretation of the columns, and thus the way information is accessed.

These systems in essence represent information as a network of nodes and links.

Nodes are identified with 'things' - real-world entities, such as firms, people, or products.

Instances of these entities will have obvious unique identifiers, names, reference numbers and so on. Things which represent definite values - for example dates, or monetary amounts - are also nodes.

Thing Type, NameNalue Verbs link the things.

Thing - Verb - Thing The tables in these models store lists of nodes and links, and the names of entity types and verbs.

There are important differences between this representation and that used by XRDM.

Obviously, the idea of'obvious unique identifiers'- rejected in XRDM - is again prominent.

The node-link model also emphasises the different representations of things and actions, a distinction which was not made in discussing XRDM.

The reason for this omission is that in any XRDM model - and indeed in any existing relational system - actions, such as ordering, purchasing and employing, are almost always represented as 'entities' in exactly the same way as are firms, persons and so on. This representation is preferred because it is more consistent and much more flexible when a variety of roles and role-players are involved in the action.

For example, consider the simple action 'customer buys product'. The first difficulty is the equivalent relationship 'product is bought by customer'. Either this link must be added explicitly, or any access system must understand active/passive forms and be able to navigate links in both directions. This difficulty is even more pronounced for actions such as meeting', where the verb is in a sense its own passive. A four- way meeting requires 12 links, or some complex form of reasoning about the relationship.

Adding other roles is similarly problematic. 'Sentences' (RTM), for example, allows a link to be the head of another link, so that seller information can be added to a 'customer buys product' link. However, this then requires another new form of access via the original link to connect sellers to products. Any decision about how roles and relationships are allocated can have a significant effect on the future ease with which applications can be built.

Unfortunately, these decisions must be made very early in the system's life cycle.

Most relational systems would represent 'Sale/Purchase' as an entity with its own table.

Each purchase has a reference to the relevant customer, seller and product, or uses subentities to support multiple references. XRDM follows this pattern. Purchases are regarded as things, to which as many customers, sellers and products as desired can be added. Further identifying information can be added or not as the system requires, and all purchases can be accessed in the same way for any of the role-players, as the application demands. A meeting is simply a thing with references to all the relevant attendees.

Dropping the insistence on identifiers and reinterpreting nodes and links produces a better modelling method.

Nodes represent concrete things, noun verbs, and data.

Concrete thing/Noun verb/data Type, optional value Links show why one thing is related to another ThingNerb - Role - Thing This is conceptually correct, but misses some convenient features of XRDM. Roles and types are handled separately and extension is missing. Adding extension, and recognising role assignment as an example of this allows: Thing (Base/Role/Extension) Type + optional ThingNalue The triple-relationship can then be replaced with the simple composition table.

4.1 References Williams, Simon, The Associative Model of Data, Lazy Software Limited, 2000 TriStarp Project, School of Computer Science and Information Systems, Birkbeck College, www.dcs. bbk.ac. uk/TriStarp GB 2 360 108 B. Lazy Software Limited

Claims (24)

1. A database structure including: a first table comprising one or more element identifiers and an element type associated with each element identifier; and a second table defining one or more relationships between element identifiers.

2. A database structure as claimed in Claim 1 wherein, in the first table, at least one element type is further associated with an item of element data.

3. A database structure as claimed in Claim 2, wherein the item of element data is of a form selected from a group comprising: numerical value; text; alphanumeric string; date; time; flag.

4. A database structure as claimed in Claim 2, wherein the item of element data comprises a reference to another element identifier.

5. A database structure as claimed in any preceding claim wherein, in the first table, each element type is designated by a corresponding element type identifier, and wherein the system further includes a third table in which element type identifiers are associated with corresponding element type names.

6. Database apparatus incorporating a database structure as claimed in any preceding claim.

7. A method of storing data in a database, the method comprising: storing in a first table one or more element identifiers, each element identifier being associated with an element type; and defining in a second table one or more relationships between element identifiers.

8. A method as claimed in Claim 7, further comprising storing in the first table at least one item of element data, said item of element data being associated with an element type.

9. A method as claimed in Claim 8, wherein the item of element data is of a form selected from a group comprising: numerical value; text; alphanumeric string; date; time; flag.

10. A method as claimed in Claim 8, wherein the item of element data comprises a reference to another element identifier.

11. A method as claimed in any of Claims 7 to 10, further comprising designating each element type in the first table by a corresponding element type identifier, and storing in a third table element type identifiers and their corresponding element type names.

12. A method of constructing an element of data in a database, the method comprising: storing a plurality of element types in the database; and constructing an element of data by forming a compound of element types.

13 A method as claimed in Claim 12, further comprising: associating a element identifier with each element type; and constructing an element of data by forming a compound of any element types which share a common element identifier.

14. A method as claimed in Claim 13, further comprising: associating one or more element types with a cross-reference to another element identifier; and constructing an element of data by forming a compound of any element types which share a common element identifier and any element types having other element identifiers referred to in a said crossreference.

15. A method as claimed in Claim 13 or Claim 14, further comprising: associating one or more element types with an item of element data; and constructing an element of data by forming a compound of any element types which share a common element identifier or have another element identifier referred to through cross-referencing, and any associated items of element data.

16. A method of retrieving data from a database, the database employing a database structure as claimed in any of Claims 1 to 5, the method of retrieving data comprising retrieving those element types which share a common element identifier, any element types having other element identifiers referred to by cross-referencing of their element identifiers, and any associated item of element data.

17. A method as claimed in Claim 16, wherein the database is accessed via a standardized control interface.

18. A computer program which, when executed by processing means, is operable to perform a method as claimed in any of Claims 7 to 17.

19. A computer program as claimed in Claim 18, stored on a data carrier.

20. A database structure substantially as herein described with reference to and as shown in any combination of the accompanying drawings.

21. A method of storing data substantially as herein described with reference to and as shown in any combination of the accompanying drawings.

22. A method of constructing an element of data in a database substantially as herein described with reference to and as shown in any combination of the accompanying drawings.

23. A method of retrieving data from a database substantially as herein described with reference to and as shown in any combination of the accompanying drawings.

24. A computer program substantially as herein described with reference to and as shown in any combination of the accompanying drawings.