Patent ID: 12210500

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described in detail with reference to a few embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention.

FIG.1shows an exemplary database structures diagram—a mind map, which can be understood in two different ways:1. Items A101, B102, C103, D106, E105, and F104are objects;2. Items A101, B102, C103, D106, E105, and F104are the objects collections (i.e. a data structure).

The following example shows an important approach of data processing capabilities in a database, especially in a mind map database technology as shown inFIGS.6and7. Two distant elements can be linked by a transition to the next closest object/structure.FIG.1illustrates that the element ‘A’101is associated with the element ‘E’105, because the element ‘A’101is in a direct relation with the element ‘D’106, which has a direct relation with element ‘C’103, which has a direct relation with object ‘F’104, which is directly related with object ‘E’105: A→D→C→F→E.

In an automatic analysis, occurrence of the above relationship may be statistically insignificant due to the distance between two objects. However, from the point of view of database data drilling and knowledge extraction, this information may allow the ability to draw appropriate conclusions or to discover a significant piece of information.

For the purpose of this patent application, the following assumption was made—information is sets of data stored in an RDBMS and an RDBMS is the element of data processing.

Knowledge is a collection of such data that the human mind understands, allowing a person to draw appropriate conclusions and make decisions. In order to make the correct decisions a significant amount of data is required so that a decision may be based on knowledge rather than random or partially related pieces of information.

In the current IT era, the amount of publically available data is increasing tremendously over the years. The increasing costs of maintaining such significant volumes of data led to the need for a new data management technology, low-calorie data sets, hereinafter referred to as Big Data. The processing of such information requires the use of statistical analysis and distributed processing. For this purpose mainly Apache HADOOP™ is used as a data storage technology. The most famous example of Big Data usage is an Internet search engine provided by GOOGLE™ Co. Google's search engine statistical information processing methodology does not allow finding an answer based on the connections to results previously obtained, and thus the knowledge extraction from provided information, unless a human mind-mapping capabilities are added.

One of the main examples of this kind of issue would be the attempt to find information in a compound system that has a multi-level relationship with a number of related data. For example, identifying the car steering problems that derive from inadequate structure of the car tires.

The result of a search process focused around a phrase ‘steering vibration’ gives only a one-dimensional set of answers, in which solution to the problem, most of the time, cannot be discovered without connecting the information. Data analysis is then carried out by the mind of the user and may not result directly from the information model or the search algorithm, thus being limited.

Processing of information by human brain can be basically summarized in the following steps (as shown inFIG.2). Step201is to obtain basic information using the senses (color, odor, sentence, etc.). Next, step202is to categorize information, and adding it to the ‘shelf’ with a similar elements (all green, all predators etc.). Further, step203is to combine information with other ‘shelves’, and/or other objects.

In the same manner mind maps are constructed. The process of obtaining knowledge can be summarized as shown inFIG.3. The first step301is to enter an appropriate ‘shelf’ i.e. information domain. Next, at step302there is executed searching for the needed information in the ‘shelf.’ Further, at step303there is executed jumping to another ‘shelf’ using filtered information and certain connection types. Finally, at step304one may return to the second step (302) until a conclusion is made or knowledge is obtained.

An example of such a query could be a process of finding a tiger.1. Entrance into big teeth ‘shelf’;2. Jumping through connection to wild animals;3. Filtering the big cats results;4. Jumping into the ‘shelf’ with regions5. Filtering only the Indian results from the ‘shelf’;6. Obtaining a result—for instance tiger.

The example is admittedly exaggerated, and shows that for any information query the human mind can come out with result. The most important suggestion is that using this approach requires the minimum amount of query parameters needed to find appropriate answer from a large dataset.

By using such approach a knowledgeable person may often find results comprising objects that are somehow related only in the mind of this particular person and which often do not appear related to other persons. Hence, in principle, a large database may logically comprise unlimited number of relations, just as in real world.

However, relational databases arc not programmed to easily extend hardcodcd relations. Programming of relations is not a trivial task and potentially is a source of errors, bottlenecks or deadlocks. Frequently, a process such as addition or edit of a record must trigger numerous other operations on related tables and/or records. Therefore, the end user may not easily create new relations in an end product as this requires in depth knowledge of the particular database system design and database programming knowledge.

An aim of embodiments of the present invention is to allow storing ad hoc relations between previously unrelated database objects assigned to different database structures, which may be very beneficial for knowledge extraction.

FIG.4presents a method for storing ad-hoc relations. The process is designed for databases where there exist at least three database structures A, B and C and where there exists a relation between objects of A and objects of B and where there exists a relation between objects of B and objects of C. There may of course exist many relations between A and B a user may choose from. Similar assumption applies to B-C relation. The above structure is assumed to have been created in a step401.

Next, at a step402, a filtering of data is executed on the A structure, for example employees are filtered according to their name. Further, at a step403, structure B is accessed using a selected path (relation), between structure A and structure B. Frequently there will be more that one path to choose from. After that, at a step404, information about filtering (step402) of the first data structure (A) and information on selected path (step403) between A and B is stored (or recorded).

At this stage, results obtained from data structure B may be filtered at a step405and at a step406data structure C may be accessed using a selected path/relation, between structure B and structure C. Similarly to step404, at a step407information about filtering (step405) of the second data structure (B) and information on selected path (step406) between B and C is stored (or recorded).

Optionally, results obtained from data structure C may be further filtered at step408. Such filter may be stored (or recorded) at a step409in case step408has been executed.

Another option that may be executed in a similar manner steps of filtering and moving between data structures, is to apply steps406,407to a further data structure, for example D, related to structure C at a step409.

FIG.5shows an exemplary result of the method shown inFIG.4. The result is a definition of a path defining the identified multi-table logical relation called herein a path. This result is embodied in an XML (Extensible Markup Language) file. The file defines several level of hierarchy in order to define a path comprising identification of a set (setToFilter), conditions of filtering of a particular set (conditions). Further the file defines a relation (stepRelation) selected to connect two chosen sets. As may be appreciated, there is not any limit with respect to the number of tables (sets) to be used in a cross-querying path. Hence such definitions are very powerful for database designers and users who wish to create complex, ad-hoc logical relations between different data sets.

The system presented herein is especially useful in databases based on mind maps such as a database disclosed in the co-pending European Patent Application number EP13461516.0 (U.S. patent application Ser. No. 14/222,795) by the same Applicant, which is hereby incorporated in its entirety by reference. In that particular database type it is especially easy to execute a process of finding objects of interest that are related to different data structures because, a relation between objects is present in the OBJECT RELATIONS data structure.

The following section of the specification presents portion of the Applicant's co-pending European Patent Application number EP13461516.0 (U.S. patent application Ser. No. 14/222,795).

FIG.6, corresponding toFIG.2of the co-pending application, shows a new database system according to the present invention. In order to perfectly cooperate with mind maps the database system according to the invention has been designed differently than known database systems. The database system comprises six core sets of data and optional sets. The core sets comprise SETS, OBJECTS, COLUMNS, CHARACTERISTICS, RELATIONS and OBJECTS RELATIONS. It has to be noted that the names above are exemplary only and the respective core sets are defined rather by their function within the system than their name.

The first set of data is called SETS604, because it is used to logically hold data related to sets of data. The sets of data may be represented on a mind map as nodes. Each entry in the SETS data structure604comprises at least a unique identifier605aand preferably also its name605. Referring back to example fromFIG.1from the co-pending application there are three SETS, namely COLORS having ID of 1, MATERIALS having ID of 2 and TOOLS having ID of 3. The SETS data structure is a top level structure and does not refer to other data structures but other data structures refer to it as identified by respective arrows between the sets ofFIG.6.

Each set of data is, as in the real world, characterized by some properties typically called columns. Hence, the second set of data is called COLUMNS606. A property, called typically a column, is uniquely identified with an identifier ID607and is associated with a set, defined in the SETS data structure604, by means of an identifier herein called SET ID608. A column also preferably is associated with a name609. As indicated by an arrow604a, the COLUMNS data structure logically, directly references the SETS data structure, because the COLUMNS data structure uses the identifiers of sets. If, for example, each color of the set called COLORS had another property, say RGB value, there could be added an entry comprising the following values: ‘1’, ‘4’, ‘RGB’. At this level of the system the types of respective data such as text, integer, binary large object (BLOB) are not considered as their application in the present system is routine work.

Having defined data structures of SETS and COLUMNS there may be defined objects that will form elements of respective SETS and will have properties defined by the COLUMNS data structure. Objects are held in a second data structure or OBJECTS601data structure. This data structure holds entries uniquely identified with an identifier ID603and associated with a set, defined in the SETS data structure604, by means of an identifier herein called SET ID602. As indicated by an arrow601a, the OBJECTS data structure logically, directly references the SETS data structure, because it uses the identifiers of sets.

A fourth core data structure is a data structure that holds data entries of each property of each object. This data structure has been called CHARACTERISTICS301inFIG.6. This is one difference from all known databases where there arc rows of data that comprise entries for all columns of a data table. In the present invention each property of an object is stored as a separate entry, which greatly improves scalability of the system and allows for example adding objects properties in real time.

Referring toFIG.7, CHARACTERISTICS701data structure holds entries uniquely identified with an identifier OBJECT ID702and is associated with a property, defined in the COLUMNS data structure606(FIG.6), by means of an identifier herein called COLUMNID703. Further each entry in the CHARACTERISTICS data structure, comprises a value704of the given property of the particular object. As indicated by respective arrows originating from sources A and B, the CHARACTERISTICS data structure701logically, directly references the COLUMNS data structure and the OBJECTS data structure, because it uses the identifiers from the respective data structures.

A fifth core data structure, of the databases system according to the present invention, is designed to hold data regarding relations present in the database. This data structure has been called herein RELATIONS705. This is a structure that may hold an identifier of a relation ID707and preferably also holds the textual description of the relation i.e. a NAME706. As indicated by an arrow705a, the RELATIONS data structure logically, directly references downwards the OBJECTS RELATIONS data structure, because the OBJECTS RELATIONS use the identifiers of the relations.

A sixth core data structure of embodiments of the present invention is the mentioned OBJECTS RELATIONS data structure708. This data structure is designed to provide mapping between a relation from the RELATIONS data structure705and two objects from the OBJECTS data structure701. For example the first entry in the OBJECTS RELATIONS data structure708defines that the relation having Rel.ID711of 1 exists between object having an OBJECTID710of 1 and the object having an OBJECTID709of 6.

Optionally a seventh data structure exists in the database system of embodiments of the present invention. This data structure holds data regarding relations between the respective data sets and inFIG.7is called SETS RELATIONS712. This data structure is designed to provide mapping between a relation from the RELATIONS data structure705and two sets from the SETS data structure604. For example, the first entry in the SETS RELATIONS data structure712defines that the relation having identifier of 1 exists between a set having an identifier of 1 and a set having an identifier of 2. Providing an entry in the SETS RELATION data structure712between a set having an identifier of 1 and a set having an identifier of 2 as well as between a set having an identifier of 2 and a set having an identifier of 1, allows for creating a bidirectional relation.

There is also a possibility of self referencing from a given set in embodiments provided herein. For example such case may be present when there is a set of persons and there exists a student—teacher relation between persons assigned to a particular set.

As described, for example a relational database system of a hundred tables will in the present system be stored in the six above-described data structures. Naturally, most of the data will be kept in the OBJECTS and CHARACTERISTICS data structures.

As can be seen in the mind-map-type database, objects arc directly related by means of object relations.

FIG.8presents an exemplary database system embodying features of the present invention, for which the present method has been designed and by which it may be implemented. The database system comprises a client801and a server802. The client801accesses the data and is typically a remote terminal from the server802that hosts a database806and a database management system807responsible for responding to client's queries and also having memory and CPU808. The client is typically a computer comprising a memory803, a processor804and a module805for executing methods such as those defined inFIG.4. It will be evident that a suitable communications channel must be established between the client801and the server802.

It can be easily recognized, by one skilled in the art, that the aforementioned a computer-implemented method for storing ad hoc relations between previously unrelated database objects assigned to different database structures may be performed and/or controlled by one or more computer programs. Such computer programs are typically executed by utilizing the computing resources in a computing device such as personal computers, personal digital assistants, cellular telephones, receivers and decoders of digital television or the like. Applications are stored in non-volatile memory, for example a flash memory or volatile memory, for example RAM and are executed by a processor. These memories are exemplary recording media for storing computer programs comprising computer-executable instructions performing all the steps of the computer-implemented method according the technical concept presented herein.

While the invention presented herein has been depicted, described, and has been defined with reference to particular preferred embodiments, such references and examples of implementation in the foregoing specification do not imply any limitation on the invention. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader scope of the technical concept. The presented preferred embodiments are exemplary only, and are not exhaustive of the scope of the technical concept presented herein. Accordingly, the scope of protection is not limited to the preferred embodiments described in the specification, but is only limited by the claims that follow.

While preferred embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is intended that the following claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby.