WO2009090437A1

WO2009090437A1 - Database and a method for creating thereof

Info

Publication number: WO2009090437A1
Application number: PCT/HU2009/000001
Authority: WO
Inventors: Nàndor KEREKES
Original assignee: SZILÁGYI, Zoltàn
Priority date: 2008-01-16
Filing date: 2009-01-15
Publication date: 2009-07-23

Abstract

The invention is a database having a first table (T0) comprising cells (C) and a second table (Tn) comprising cells (C), wherein the second table (Tn) is in a logical connection with the first table (T0). The second table (Tn) according to the invention is in a logical connection with one of the cells of the first table (T0) in a way that the second table (Tn) is stored in the cell (C). Further, the invention is a method for creating a database, in which the second table (Tn) is brought into a logical connection with a cell (C) of the first table (T0) in a way that the second table (Tn) is stored in the cell (C).

Description

DATABASEANDA METHOD FOR CREATING THEREOF

TECHNICAL FIELD

The invention relates to a database and to a method for creating thereof.

BACKGROUND ART

According to the prior art, a number of database models (in short: data models) exist. For the storage of large quantities of data, hierarchical, network, relational or object oriented data models are most commonly used.

The hierarchical data model stores data in a hierarchical tree structure. Each node of the tree structure corresponds to a record type. The basis of the hierarchical model consists in the fact that, in practice, organisations or other structures have often a hierarchical structure (e.g. company hierarchy, hierarchy of the components of a product). The DMLs (Data Model Language) associated with the model apply a record oriented data approach. The drawback of the model is that it permits more complex data relationships to be represented only in roundabout ways.

The network data model is an improved version of the hierarchical model which is more suited to the representation of more complex data relationships. In this model, as illustrated in Fig. 1A, arbitrary systems of relationships and networks of relationships can be created between the entities. As the network can be as large as wished, the data structure is described not by using a single data unit but by using several smaller hierarchically structured data units. Also in the case of this model, a record-oriented data approach is applied in the construction of the DML. DBMSs (Database Management Systems) based on the network model are very commonly used in mainframe environments, as the network model permits a relatively quick processing of large amounts of data. The complexity and the rather rigid structure of the control language are barriers to a more widespread use of this data model.

The relational data model, as compared to the former, ensures a much more flexible data structure. The database is composed of tables containing the same record types and where each table is completely equivalent and, in contrast to the former models, there are no relationship and frame that are definitively fixed at data definition. Relationships between entities in the relational model are realized through data values. The drawback of the model is that the storage of the large amount of data with many properties in the relational database may result in an almost unmanageable quantity of tables for the programmer. A solution for a relational database and method for the creation of the latter are known for example from EP 0 927 940 B1. The known solution has the disadvantage that the logical relationships between the tables in the database, i.e. the relations are stored in a separate table. This brings about a significant increase in the storage requirements of the database, as well as in the time of data search and access. Relational database models are illustrated for example in Figs. 1 B and 1C.

The objective of the object oriented data model is the creation of a database structure, through the application of the object orientated approach, which is as close to reality as possible. Entities in fact are more readily describable with objects than with the records in the relational model. A wider application of the data model is hindered by the lack of uniform theoretical bases and by implementation difficulties.

DESCRIPTION OF THE INVENTION

The object of the invention is to construct a database, as well as to provide a method for its creation, which are free from the defects of the solutions according to the prior art. A further object was to create a database structure with low storage requirements, permitting quick data access and possibly protected against damages.

According to the basic idea of the invention, in a cell of a basic table another table is placed. Of course, further tables can be placed in the cells of the inserted table to the extent desired using this, same method. This data model henceforth will be referred to as "intra-cell table storage model".

The model according to the invention permits a more easily understandable and more flexible data storage as it makes it possible to store, without any constraints, tables containing cells and records of different types. In the intra-cell table storage model it is possible to display the whole database with each table also in an easily overviewed tree structure. Using a recursive algorithm, a simple and efficient search method can be written for a database of this kind, which in cycle time is comparable with the search between the indexes of the relational data tables and the structure produced in this way does not include the adding of indexes.

It is a significant feature of the model that the tables are not stored separately from each other and their logical connections are not implemented with index fields of some kind or other. Each table of the data model according to the invention includes physically the associated tables. This way, practically, the database is constituted by one single table which, according to the suitable hierarchy, includes the tables of the lower levels. As a result, there is no need for indexes or for any other fields representing the relationship, which, from the point of storage, saves storage area and, from the point of operation, processor time. The logical network of the relationships is determined by the physical arrangement of the tables, by their actual spatial locations. It is unnecessary to define the relationships separately and to record them in the programming.

The types of relationships 1-1, 1-N and N-M here do not mean any limits for data recording and for design. The relative relationship of the data is defined at recording and at modification of the stored data the database will change together with the data.

It is another property of the intra-cell table storage model according to the invention that it has spatial characteristics, as opposed to the types according to the prior art.

It is a further advantageous property of the data model that each sub-table ("child") has the characteristics of the basic table ("parent"). Therefore, the same methods are valid for any of the tables and the very same operations are defined in each table as in all of the others, be they anywhere in the database. This also means that it is possible to issue a data managing command for any table from any table, and what is more, it is not necessary to launch the export or import of data from the root, i.e. the basic table. All this is to be understood not only between a particular table of another opened database and the actual table, but it applies to a file according to the model discussed which is not opened, i.e. read in. All this is true the other way round: any of the tables of database can be "cloned" into a given cell of another database, but it can also be saved as a separate file. In this latter case evidently an independent database is obtained.

According to a first aspect, the invention, is a database having

- a first table comprising cells and

- a second table comprising cells, wherein the second table is in a logical connection with the first table, characterized in that the second table is in a logical connection with one of the cells of the first table in a way that the second table is stored in the cell.

According to a second aspect, the invention is a method for creating a database, wherein a second table comprising cells is brought into a logical connection with a first table comprising cells, characterized in that the second table is brought into logical connection with a cell of the first table in a way that the second table is stored in the cell.

Preferred embodiments of the invention are defined in the dependent claims.

The database according to the invention possesses the advantages of the solutions according to the prior art, but through the elimination of their disadvantages permits the application of a new attitude and new techniques. The data model according to the invention preserves the favourable feature of the hierarchical databases consisting in permitting data structures that are readily applicable to real life. In the model it is also easy to create a structure corresponding to the network data model. If necessary, mathematical relations of the relational databases are also applicable, but in the vast majority of the cases the invention provides a simpler solution to perform the necessary operations.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, exemplary preferred embodiments of invention are explained by drawings where

■ Fig. 1A is an example illustrating a network data model of the prior art,

Figs. 1 B and 1C are examples illustrating a relational data model of the prior art, having the same data content, Fig. 2 is a schematic example of a database according to the invention having the same data content as the databases 1 B and 1C,

Fig. 3 is another exemplary embodiment of the data model according to the invention,

Fig. 4 is a database according to the invention extracted in two viewpoints,

Fig. 5 is another database according to the invention extracted in two viewpoints,

Fig. 6 is a schematic diagram illustrating a database filtering (expansion) operation,

Fig. 7 is a schematic diagram of one of the concrete physical realisations of the data model according to the invention,

Fig. 8 is a schematic diagram of an application example for the storage of spatial characteristics,

Fig. 9 is a schematic diagram of a database serving for storing spatial forms,

Fig. 10 is a schematic diagram of a database serving for storing further spatial forms,

Figs. 11-19 illustrate steps of a management of a database compiler according to the invention,

Fig. 20 is the complete database in string format created according to Figs. 11-19 and

Figs. 21 and 22 illustrate further extensions to the database

MODES FOR CARRYING OUT THE INVENTION

Differences between the database models according to the prior art and the database according to the invention are illustrated by Table 1.

Table 1 The use of links in the cells of the database is important, because

- the amount of the characters used for the purpose of links is significantly lower than the amount of the characters stored in an index field performing a similar function in the case of relational databases (particularly, when the table of the relational database contains a high number of records),

- it is suitable for avoiding data replications and

- from the point of data access the reference will return the target table in a much shorter time.

With the help of links different branches can be connected, it is enough to store the same data once and also independent databases are able to work on the same data. Of course, the use of external links outside of the database is also possible.

Compared to the network data model illustrated in Fig. 1A, the relational data models also belonging to the prior art, shown in Figs. 1 B and 1C, represent a significant improvement. The relational databases according to Figs. 1 B and 1C have identical data contents where only the implementation of indexing is different. The number of characters stored in the system according to Fig. 1 B (without headers) is 108. The database according to Fig. 1C contains a separate relational database and in this case the number of characters stored (without headers) is 90.

Fig. 2 shows an exemplary database according to the invention which has the same data content as the databases according to Figs. 1 B and 1 C. In this case the number of characters stored is 89 and also the database does not contain any headers. It can be seen that the logical connection according to the invention is realized through the physical location whereby significant savings in storage capacity can be achieved.

The database according to Fig. 2 comprises a first table TO (basic table) in the first cell C of which a second table T1 , also having cells, is stored. A further table T11 is stored in the first cell of table T1. The first cell of table TO and the tables T1 and T11 which are threaded on the former define jointly two persons who have the same surname and first name, but have different dates of birth. Table T2 is stored in the second cell of table TO, defining two persons with the same surname, but with different first names. Tables T21 and T22 are stored in two cells of table T2, respectively, containing the dates of birth of the persons.

A table name N is also recorded in those cells where a further table is stored. This table name N corresponds to the collective concept of a linked sub- table.

It is advisable to introduce the concept of levels. The term zero level denotes the table serving as the starting point, i.e. which is not contained by a cell of a table positioned above. It follows that the term first level can be used to refer to the table stored in one of the cells of the basic table, while the terms second, third etc. levels can be used to refer to the tables stored by one of the cells of the tables positioned lower. In terms of logic, the database appears as one single table. This is the table located at the "0" level of the system. The further levels are located in the respective cells of the "0" level table.

Accordingly, the tables T1..T3 are also referred to as "first level" Tn tables and the tables T11...T34 as "second level" Tnn tables.

The Tnn tables also include ones that contain the same data in their first cell as other Tnn tables. In order to store the data only once, in the cells where the data occurs subsequently it is possible to store a link to the cell of the data stored on a single occasion, instead of the data itself.

Fig. 3 shows a schematic diagram of a database having also the data content according to Fig. 1 A. As the subjects are stored in a separate table T1 , it is sufficient to store the link to the them in the tables T21 , T22 and T23, which is indicated by the sign "\".

The data model according to the invention can also be called as a point of view database, since the data can easily and quickly rearranged according to changes in the point of view. There are no restrictions in design or in run-time relative to the rearrangement, modification or expansion of the database. It is due to the fact that the properties of entity occurrences are stored in a complete table, instead of record organisation (this cannot be said of the data models according to the prior art). For changing the point of view, the translocation of the stored tables can be carried out during run-time, or in order to avoid eventual multiplication of data a so-called "linking" can be applied. Fig. 4 illustrates two ways of data extraction according to the point of view. In the upper part of the Fig., the individual employees are visualised grouped by companies, whereas in the lower part of the Fig. the full time and part time job relationships are visualised grouped by employees.

Fig. 5 schematically illustrates the flexibility of the use of the database. In the upper part of the Fig., the members of families divided in two part by table T1 and the dentists divided into districts by table T2 are arranged in a database. In the lower part of the Fig., information relative to the districts is assigned to the members of families in the forms of links, whereby the relationship between the members of families and the dentists can be established.

Therefore, the tables in the database according to the invention are not joined via connection fields or index columns, but the table located at a higher level contains physically all the ones underneath. The complete extraction of a database of 4 levels comprising 4x4 tables means a total of 85 tables.

In creating a database two requirements have to be met:

1) Every cell containing data (table) has to be given a name. This is the table name N.

2) It is possible to work with several identical table names, but these cannot be present at the same table level.

These two restrictions permit the construction of an algorithm which will facilitate the quick movement throughout the whole database. For example: in the case of a three level table To = upper table Ti = first level T2 = second level L_x = query data F_x = field number R_x = record number

Tonamei\name₂\name₃ = L_x T₂\namei = L_x T₂[F₁R] = L_x T₀[F₁R]-[F₁R]-[F₁R] = L_x In the storing it was considered to be important to use only one type of data, namely preferably the string format. So, in a cell of a table having levels, any required data can be stored, which means that not only another table, but any other data can be placed into the cell that has previously been converted to string format. The retrieval of the data is the task of the software to which the data table has been created. On the basis of these considerations, a cell can provide storage for an image, a list, a character or for a further table.

As storing is accomplished at cell level, this way there are no restrictions relative to the fields and the eventually used field name is only for information purposes. It is important to note that in the case of the intra-cell table storage individual data tables perform not only the task of storage, but can also be used as display tables. The term display table is to be understood not only as referring to the case when the table is displayed to the user, but the term display table also applies to cases where the cells of the given table do not contain any further tables. This term has importance in filtering and in sorting

Tables can be expanded in a very flexible way as the addition of a new field or new record will not modify the logical structure of the database. A given level, as a logical unit, is independent from the table of the higher level on which is contained, therefore the property and the location of the cell of the higher level table will not change. Fig. 6 shows an example of the expandability which can be carried out using a simple algorithm written in PASCAL language, e.g. the addition of a column.

No particular preparations are required to accomplish the expansion, this way it can be carried out also by the user if it is permitted by the user software (managing the database according to the invention). The insertion of a cell, a record or even a new table can be carried out in run-time with a single add command.

In the creation of relational databases (with good approximation) the procedure given below is followed:

- Field names have to be given.

- Field type has to be selected. - Field size has to be given (field size reserves the necessary/possible storage capacity in advance).

- Definition of formats and masks (defines the way in which data appear: number, currency, date, text, capitals, small letters, separators, decimal places, allowance of zero length etc.).

- Title for the presentation of the field name as header (form, report).

- Default values, validation rule, validation text, text displayed on entering invalid data.

- (Eventual) indexation relative to the field.

All this is dispensable in the case intra-cell table storage because the interpretation of the data is the task of the programme reading the database and visualising its content for the user. This way a flexible storage structure is obtained.

Therefore the physical storage of the whole database is preferably done in a string format where the data and the tables containing the former are stored together. This way one single long string is obtained. Presently, the upper limit is 2 GByte in the case of the 32 bit Windows which implicitly permits the storage of ~2 billion characters, including also the storage of the geometry of the table.

With the storage of the geometry data security is also increased because in case of eventual damage of the database it will be possible to retrieve surviving data and to decide on which level they were located. In parallel, the encryption of data can also be accomplished using a simple algorithm.

The storage of the tables is preferably carried out according to the following:

^Λ, Table level, column number, ordinal number, table name, one separator per cell (a comma in this case).

In the case of a 2x3 table, on the first table level it looks as follows:

^Λ,1 ,2,3,Name,,,,,,,

The format outlined above is a table containing no data. In the following table example some data can be found in the second row of the first column:

^Λ,1 , 2, 3, Name,, "Some data" The following example illustrates that another table can be found in the second row of the first column of the table "name" which table consists of two columns and two rows and data is present in its first column, first cell.

M ,2,3,Name,, "^Λ,1 ,2,2,"'Αnother tableYSome data"",,,,,,",,,,,

Data boundaries are indicated by quotation marks. The reading of the stored data (string) can be implemented depending on the given programming language. In the development environment Delphi produced by the company Borland a preliminary data arrangement into one string was carried out when reading the data in. This way, it became possible to manage the data in an object- centred manner (see above: To/name/name/name = Lo) after arranging the cells of the levels into another string. Furthermore, it is also possible to read the data directly as data boundaries are marked and the three parameters after the marks make clear their location in the string. Of course, this is a more difficult way of handling the data, but on the other hand, permits a quicker execution of operations than if the table of the given level were extracted. The term "execution of operations" is primarily understood as searching and filtering across the whole extent of the database.

Data processing can be carried out in the memory and this way a very rapid execution of operations is possible. A test was carried out on the portfolio data file of a pension fund. The stocks were stored in 20 fields. By multiplying the data, the size of the database was increased as high as 24.9 MB producing 1 cell and 1024 records in the main table the cells of which had further 3 table levels located under them. The innermost tables together contained a total of 132,900 records with 20 fields. The 2,658,000 cells produced this way could be read in within less than 2 seconds. In the main table it took 2.2 seconds to completely extract ten cells into a tree structure. The same operation took 22 seconds in the case of 100 cells, and 225 seconds for 1024 cells.

No prior arrangements are necessary to create the database. The saving of the complete table is contained as a property by the other tables created in the main table. This way a saving operation launched from any level will save the data of the whole structure including the main table.

Technically, the creation of a table can be done as follows (in PASCAL language): Var

T:TObjectTable; // ,,T" as table ...

Begin

T:=TObjectTable.Create(Self);

T.ColCount:=10; // In the lack of specifying field and

T.RowCount:=50; // record number a 2X2 table will be saved

T.WriteBinDataCCΛData.tbl');

T. Free;

End;

At this point already a working database is at disposal in which further tables can be inserted. The saved table contains 10 fields and 50 records.

Of course, there is a more flexible way for creating table systems of large quantity and of great depth.

Var

TTObjectTable; // Basic table

LTObjectTable; // In the present case a "L" 2x2 table (end table)

Begin

T:=TObjectTable.Create(Self);

L:=TObjectTable.Create(Self);

T.Table[5,43].[1 ,1].[ 1 ,1].[ 1 ,1]:=L; // Three tables are inserted between the LWriteTable; // cell in the 43^rd row of the 5^th column of T and L

T.Table[5,44].[1 ,1].[ 1 ,1]:=L; LWriteTable;

T.Table[5,48].[1 ,1].[ 1,1].[ 1 ,1].[1,1]:=L; LWriteTable;

T.Table[9,11].[1 ,1].[ 1 ,1].[ 1 ,1]:=L; L.WriteTable;

T.WriteBinData('C:\Data.tbl');

T. Free; L. Free; End;

This time 14 tables have been created and the greatest depth is level 4. The database contains four branches and each branch is comprised of 2X2 basic tables. These tables can later be modified and expanded or split into branches or translocated to another table level.

The database can be created also in the following way:

Var

TTObjectTable;

LTObjectTable; // In the present case ,,L" is the leaf ...

Begin

T:=TObjectTable.Create(Self);

T.ReadBinData('C:\Data.tbl');

T.Table[5,43]:=L;

LColCount:=4;

L.RowCount:=6;

L.WriteTable; // Now a new table is inserted into the 43^rd

// record of the 5^th field of table "T" T.WriteBinData('CΛData.tbl');

T. Free; L. Free; End Data entry is preferably done from a special user interface via so-called controls which controls in each case convert the entered data into a string thus ensuring the independence from the type. Data entry can equally be done from another table, from another cell and from another file into any of the tables of the database. Display is also preferably done in controls which controls can be suitable for the modification of the data as well.

The field-record content of the tables is easy to convert. Since the individual fields and records can be gathered into a list, practically the field that has been read in into a list can also be saved as a record, and also the other way round, a record that has been read in into a list can also become a field.

Filtering utilises the property of the table that an added field does not necessarily imply the storage of the latter. A filtering cannot be performed directly on the data that have been read in. An additional field has to be provided for the algorithm responsible for the filtering for the temporary storage of the results of the operation. It is evident from what had been described above in relation to the expandability that the creation of a new field will not encounter any difficulty.

In the following an example is given to show how filtering is done.

Ti.ColCount:= Ti.ColCount+1 ; T-iFilterCol:= T₁ ColCount-1; T-i.PosFilter;

(If the result of the filtering is wished to be saved: T1.WriteTable;) (TI PosFilter: show identical, TI NegFilter: hide identical.)

This code is suitable for comparing the data in the selected cell in the currently selected field in the display table with data in other cells and in case they are identical, it will display them while eliminating those that are not identical.

Query is an analogy of filtering with the difference that here not only the identicalness with one element is regarded but the elements of a group are considered as reference. This operation requires the adding of another field therefore: T1.ColCount:= T1.ColCount+1; T1 FilterCol:= T1.CoICount-1 ; T1.ColCount:= T1.ColCount+1 ; T1 SelectCol:= T1.CoICount-1 ; TlPosSelect;

Searching is basically performed by means of recursion. The starting position can be not only the basic table (root of 0 level), but it can be accomplished starting from a given cell towards the lower levels. Thereby the location and size of any table can be determined precisely. The operation this time requires the extraction of the table levels, but it can be executed directly on the raw data which is significantly faster.

With the links the table basically offers the possibility to make an external reference to data stored otherwise in other branches.

Link = TO/name/name/name/cell, or Link = T2/cell

In this way, it is made possible in an eventual extension to bring together data previously without any logical connection between them. Here a redirection of the user interface is done over to another point of the database.

The data model discussed is suitable for the creation of both deterministic databases (local database having a static table structure) and procedural databases (specified depending on the application, , with a client-server connection). In the former case it is the task of the programmer to make the functions and the processes of the database parameterizable for the user, thereby ensuring the execution of operation from the command line, if needed.

Furthermore, the possibilities of the data model can be extended concerning the procedures with the enlargement of the command set of the SQL language. Thus the database model is capable of supporting the creation of commands with which it is made possible to implement the management of the database structured according to the invention even in a standard client-server connection. Since the data model does not contain types (type independent), this way the entered data will not cause any database error at recording. For example, the appearance of a piece of data in text form, expected as a number, could cause an error at the rereading and processing of data, but these errors can be prevented adequately at programming with the handling of exceptions. Already at data entry it is possible to create a protection with the masking of the input controls or with the control of data at recording.

The damage of the database means the breaking of the stored string and its becoming fragmented. If the database stored breaks into two at some point, the data remain interpretable from the point of break (if they miss from the start) or to the point of break (if the end is missing). The system is not able to regenerate the lost part, but with the help of the level and table identifiers, the table structure of the existing sections can be restored and the stored data can be displayed.

If some inner sections of the stored data flow are lost, i.e. it becomes fragmented, the data remained are also be readable.

Possibilities for an advantageous application of the data model according to the invention are the following.

Integrated company management systems have a very important role in business informatics. The applications nowadays in use are exclusively based on relational databases. The inventive database can much more easily be adjusted to the structure and operation of the respective organisations, which database comprises all the advantages of the hierarchical systems that can be applied in this field. With the application of links, individual data can be shared within the database in a very flexible manner which makes it possible to avoid redundant data storage and permits a very rapid access to data even in case of modelling very complicated company processes.

The system, resulting from its nature, offers the possibility of constructing distributed databases. Its application helps in achieving a rapid and safe data transfer. The hierarchical logical model of the database can be kept integrally during the construction of the distributed database. The data stored in a distributed manner simultaneously ensure data safety based on redundant storage of data and optimise data traffic of the network. In contrast to the traditional systems, where the mirrored storage is a further increase in the load on the network, the inventive network model distribute the load in a balanced manner and in case individual system elements suffer damage the data can fully be restored form other elements. Fig. 7 is an example of such an application where the servers and clients are physically separate computer units. Each computer unit stores the data of the levels below, therefore the whole system can be recovered in case of a failure of certain elements of the system. In such a system, it is not necessary to mirror the data, since the relationship of both the lower and the upper levels is also a mirror.

The other important field is the storage of 3D graphical objects, which occurs e.g. in CAD systems, with cartography or medicine (layer images: CT, MRI, ultrasound). The intra-cell table storage model has no. difficulty with storing 3D objects within one database.

The similarity between space (spatial coordinate system) and the intra-cell storage can be used for these applications. The concept of "level" is interpretable on the axis "Z", while the field can be projected on the^'axis "X" and the record onto the axis "Y". A conceptual scheme of such an application is shown in Fig. 8 according to which by dividing the space into spatial units the characteristics present in the given unit or temporal (e.g. air traffic control) events can be stored in the database according to the invention.

The table in connection with a given spatial unit of space can store not only the characteristics present in the spatial unit, but also their temporal presence. Thereby the storing of the data of spatial changes can be solved in the same place using the same method.

The flexible expandability already discussed also makes it possible that the appearance of new properties in the given spatial unit does not involve necessarily a significant restructuring of the database, but it becomes manageable with the "insertion" of a field into the given table in run-time. Though the property group of the table thus produced may exhibit differences from the tables adopted for other spatial units, all this will not cause any problem in data management as each table can be interpreted in itself.

In order to start with the creation of the database it is necessary to determine the cell number of the (0 level) basic table in conformity with the spatial size of the given object and with the precision of storage. Taking the determined resolution into consideration, the number of storage levels has also to be determined. These two parameters (field and record number of the basic table and the number of levels) form a 3D raster. According to the simplest application, only those cells have to be filled with data that include the points of the objects. Subsequently, the tables can be saved into the basic table according to the model. Only one more piece of data is required: it is necessary to determine the offset between the cells. Using this index number, it is achieved that there is no need for the table to physically contain also the sizes of the original object, the relative positions of the points are sufficient (empty tables will not be stored). By changing the index number, the object can be enlarged or reduced in scale. The method permits fast and simple description of 3D objects.

Of course, the storage with offset has importance only when a small quantity of data is wished to be stored in a relatively big unit. If the data are wished to be recorded without any offset, the most convenient way is to create a database filling the entire space.

Besides the storage of the object, "unlimited" additional information can be stored in connection with the individual points of the object, even if the points of another shape and the data belonging to it are stored in the same cell. Fig. 9 shows a database segment of 10x10x10 in size containing two shapes (TO cannot be seen in the Fig.). The lowermost point of the shapes is common and the two sides of the shape "H" and those of the shape "S" are stored in the cell belonging to this point. The third side of the shape "H" is stored in the corresponding cell of table T5. In an analogue manner, more complex shapes can also be stored according the way shown in Fig. 10.

The following Figs, show operation steps carried out by an exemplary database management system according to the invention. A user interface of the exemplary management system shown in Fig. 11 is divided into three parts. The controls are situated on the left side which are buttons provided with titles of the given functions and input fields. The middle of the user interface displays tables and on the right size the tables are displayed in a tree view. The middle is divided into four parts. The uppermost edit field shows the current directory path. Below this the main table (i.e. the 0 level) is displayed. The grid beneath the main table displays the table of the current table level while the white area underneath is a "notepad".

Fig. 12 illustrates the creation of tables. The notepad provides information on the factual content of the "First_Table". From the tree view and from the controls "Path" it can be seen that the current position is the second table level where an empty table is found.

The picture according to Fig. 13 illustrates the creation of a table hierarchy within the table named "Third_Table". Here it is also possible to create a branch from Table 3/3. The current position in the picture according to Fig. 14 is on the last table of this branch where already factual data storage occurs. The data in this case is the text "This is located on the 6^th level of the 3^rd table". If desired, the table can also be provided with a header.

According to the picture seen in Fig. 15 a new branch is created in the path denoted as "a" of the branched Table 3/3. In this case two further tables are created in the Table 3/5_a and also text data is stored in some of the remaining empty cells.

The picture according to Fig. 16 shows the "Second_Table" in an empty state and the tree view shows that a link has been made from Table 3/7_b to the second table. In Fig. 17 this link is shown from the point of view of Table 3/7_b. The tree view of the editor preferably creates automatically a colour match between the corresponding relationships.

Fig. 18 shows the database fully extracted in a tree view with the indication of the interrelated elements.

Fig. 19 shows the effective content of the "Third_Table" displayed in string format. The Fig. illustrates how one table is embedded in the other and also the separators of the table geometry are visible.

Fig. 20 shows the complete database written in bytes into a file in a string format. In order to provide some guidance, the link "\SECOND_TABLE" is highlighted in grey and in capital letters.

Figs. 21 and 22 illustrate that a new table has been added to the database constructed in accordance with the aforesaid and a picture has been placed into the table. As seen from the statistical part in the uppermost part of the editor, 354,335 characters were used to store the two images. The image displayed is stored in 248,630 characters and this includes also the table geometry. The real size of the file without the images is 3.13 KB and together with the tables containing the two images is 349 KB.

The data model according to the invention is also suitable for the creation of high-capacity archives, wherein tape storage is very commonly used. In these systems hierarchical databases are still very widely applied. The intra-cell storage database could provide the following advantages in the field of archives maintained on tapes:

The applied physical storage form (string) results in a very fast search as it is never necessary to return to a part of the tape already read in within the same search cycle. Due to the type of physical storage, the location of the data can precisely be determined with the identification by means of the table level and table names.

Semantic storage is a further possibility of application offered in the field of the Semantic Web.

The Internet (WEB), as an inexhaustible source of information, gives at least as much help for users as much difficulty is involved in obtaining the desired information. For years it has been an important research field for World Wide Web Consortium (W3C, www.w3c.org) to achieve ease search of the data on the Internet in an ordered and categorised form for programs. The essence of it consists in that all data regardless of their format (image, sound, video, text information) should be provided with standard notes of descriptive character, so- called Resource Description Framework (RDF) information. These standard expression then will be found quickly and precisely by search robots, therefore the information looked for becomes really accessible even for those who would otherwise be unable to process the otherwise given source of information (sound, image).

The above mentioned search robots, in order to speed up their work, build up databases from the individual searches and hits. This way the results of a former search can be reused for a similar topic. It is where the intra-cell table storage database could be of importance. As RDF information is also hierarchically organised, they can readily be placed into the data model elaborated by me. Auxiliary data (URL addresses, traffic data) can be compiled to the database in run-time without any restrictions, while the tree hierarchy and storage in string format permits fast retrieval.

A significant advantage of the database creation method according to the invention consists in the simple and transparent data management and storing method which brings about significant savings in the time required for program development as well as requiring no special database management skills from lay users.

It can be seen that the database and database creation method according to the invention is fundamentally different from the systems based on any of the database models now in use.

Of course, the invention is not limited to the preferred embodiments described above but further modifications and changes are possible within the scope of protection defined in the claims. For example, the database can be expanded with levels to any depth desired. Furthermore, it is not necessary to use the string format in a uniform manner within the database. It is also possible to conceive the application of database formats other than string in a uniform way or differing from table to table or from cell to cell.

Claims

1. A database having

- a first table (TO) comprising cells (C) and

- a second table (Tn) comprising cells (C), wherein the second table (Tn) is in a logical connection with the first table (TO), characterized in that the second table (Tn) is in a logical connection with one of the cells of the first table (TO) in a way that the second table (Tn) is stored in the cell (C).

2. The database according to claim 1 , characterized in that first table (TO) is a basic table and the first or the second table (TO, Tn) contains a further cell (C) that is in logical connection with a further table (Tn, Tnn) in a way that the further table (Tn, Tnn) is stored in this further cell (C).

3. The database according to claim 1 , characterized in that it comprises a cell (C) that contains a link to a content of another cell (C) of the database instead of a data.

4. The database according to any of claims 1 to 3, characterized in that it comprises tables (TO, Tn Tnn) stored in string format, wherein the contents of the cells (C) of the individual tables (TO, Tn Tnn) are stored in the same logical order, following each other in string format and separated from each other by a separating character.

5. The database according to claim 4, characterized in that it is stored as a single string in a way that the second table (Tn) is embedded in that cell (C) of the first table (TO) to which the second table (Tn) is logically connected.

6. The database according to claim 5, characterized in that it in the string each table (TO, Tn Tnn) starts with a special character which is followed by data relating to the level of embeddedness of the table (TO, Tn Tnn) and to the size of the table (TO, Tn Tnn).

7. A method for creating a database, wherein a second table comprising cells is brought into a logical connection with a first table comprising cells, characterized in that the second table is brought into logical connection with a cell of the first table in a way that the second table is stored in the cell.

8. The method according to claim 7, characterized in that the tables are stored in string format, wherein the contents of the cells of the individual tables are stored in the same logical order from table to table, separated from each other by separating characters.

9. The method according to claim 8, characterized in that it is stored as a single string in a way that the second table is embedded in that cell of the first table to which the second table is logically connected.

10. The method according to claim 9, characterized in that in the string each table starts with a special character, after which data relating to the level of embeddedness of the table and to the size of the table are placed.

11. The method according to any of claims 7 to 10, characterized in that each data is stored only once and the other cell(s) containing the same data are provided with a link to the content of the cell containing the data.