WO2004063940A1 - Adaptive data architecture for information management systems - Google Patents

Adaptive data architecture for information management systems Download PDF

Info

Publication number
WO2004063940A1
WO2004063940A1 PCT/CA2003/000012 CA0300012W WO2004063940A1 WO 2004063940 A1 WO2004063940 A1 WO 2004063940A1 CA 0300012 W CA0300012 W CA 0300012W WO 2004063940 A1 WO2004063940 A1 WO 2004063940A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
management system
data structure
information management
primary
Prior art date
Application number
PCT/CA2003/000012
Other languages
French (fr)
Inventor
Rajesh Vadavia
Original Assignee
Sygenics Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sygenics Inc. filed Critical Sygenics Inc.
Priority to AU2003201237A priority Critical patent/AU2003201237A1/en
Priority to PCT/CA2003/000012 priority patent/WO2004063940A1/en
Publication of WO2004063940A1 publication Critical patent/WO2004063940A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML

Definitions

  • the invention relates to the field of information management systems. More specifically, the invention is directed to an adaptive data architecture for information management systems using database management systems (DBMS).
  • DBMS database management systems
  • the overall timeframe for application development is dependent on sequentially completing each stage and then moving on to the next. For example, all of the business requirements must be completely defined before the structure of the database tables and fields, as well as their relationships, can be designed. Similarly, the table structure must be completed before the access routines can be written. Based on the completed data schema and procedures, the software programmers then start to develop the business modules and corresponding user interfaces.
  • RDBMS relational database management systems
  • this fixed data architecture consists of fixed data elements such as tables, data fields, memo fields, records, spreadsheets, data files, indexes and relationships.
  • a data model including a fixed physical data structure and data access routines, is designed and implemented based on predetermined business rules and requirements known at the time of design. This data model often dete ⁇ riines the success or failure of the resulting application.
  • changes to this data model in order to implement new business requirements are very difficult, due to limitations imposed by the fixed data structure and the dependence of the data model thereon, such that both the data structures and the business rules become locked in to each other.
  • relational database management systems often have difficulty integrating with modern object-oriented application development, which introduces objects defined by dynamic templates that are able to adapt and change according to the needs of the application. This is due to the fact that the fixed data structure of the conventional relational database management system originated at a time when business requirements were known well in advance of the system design and were not expected to change once systems were designed and deployed. Thus, the fixed data structure used by relational database management systems is a severe bottleneck in the development, life cycle and flexibility of any data-centric software solution.
  • the invention provides a data architecture for an information management system for storing and retrieving data, where the system is characterized by a set of data processing rules.
  • the data architecture includes a database management system implementing a primary data structure including a plurality of data elements for storing data, the primary data structure being characterized by a fixed data schema.
  • the database management system further implements a secondary data structure defining a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system, whereby the primary data structure is independent of the data processing rules of the information management system.
  • this novel data arcliitecture improves the flexibility and functionality of the information management system, which is used for the storage and retrieval of information.
  • the data architecture allows for the separation of the fixed primary data structure from the data processing rules of the system, such that the system becomes flexible and adaptive to modifications to the data processing rules. More specifically, the actual physical data structure of the information system does not have to be modified when the data processing rules must be changed to implement new requirements.
  • the novel data architecture is applied to an N-tier client/server information management system, which is operative to store and retrieve information for implementing different business applications.
  • the information management system includes an N-tier application layer and an N-tier data management layer.
  • the data management layer includes a plurality of database management systems.
  • Each database management system implements a primary data structure including a plurality of data elements for storing data, where this primary data structure is characterized by a fixed data schema.
  • the primary data structure is a physical data structure in which the physical layout of the stored data is fixed.
  • database management systems examples include relational database management systems (RDBMS), hierarchical database management systems and XML database management systems, among other possibilities.
  • RDBMS relational database management systems
  • XML database management systems XML database management systems
  • the application layer of the information management system is characterized by at least one set of data processing rules, also referred to as business rules or business logic.
  • a data processing rule is a directive, policy or procedure, either established within an organization or by an outside source, which defines information and/or information relationships that must be supported by the system.
  • Each set of rules is associated with the processes and functions of a particular business application implemented by the information management system, and guides the data processing performed by the system under this particular, business application.
  • the application layer of the information management system also includes a plurality of different client application user interfaces, each user interface being associated with a respective set of data processing rules, and thus with a respective business application. Each user interface is operative to present information to a system user, to prompt the user for input and to obtain data from the user.
  • the database management system also implements a secondary data structure.
  • the secondary data structure defines a plurality of data relationships between the data elements stored in the primary data structure, where these data relationships are established on the basis of the corresponding set of data processing rules. Accordingly, the primary data structure of the database management system is completely independent of the data processing rules.
  • the secondary data structure is a logical data structure defined by a particular organization of the data elements of the primary data structure, and characterized by a dynamically variable data model. This logical data structure is compatible with the application layer, and the primary data structure acts simply as an interface for channeling or exchanging data between the logical data structure and the application layer.
  • a data access module allows for data to be exchanged between the database management system and the application layer.
  • the data access module includes a primary data access unit and a secondary data access unit.
  • the primary data access unit is responsible for exchanging data with the database management system, and generates primary data instructions for transmission to the database management system.
  • the database management system is responsive to these primary data instructions to modify the data elements of the respective primary data structure.
  • the secondary data access unit is operative to communicate and exchange data with the application layer of the system. More specifically, the secondary data access unit generates secondary data instructions on a basis of the data processing rules of the application layer, each secondary data instruction being indicative of a modification to be made to at least one of the data relationships defined by the secondary data structure.
  • the primary data access unit is responsive to a secondary data instruction generated by the secondary data access unit to convert the secondary data instruction into a primary data instruction for transmission to the database management system.
  • the primary data access unit may implement various different algorithms and techniques to convert secondary data instructions into primary data instructions.
  • the invention provides an information management system for storing and retrieving data.
  • the information management system includes an application layer characterized by a set of data processing rules, as well as a data management layer.
  • the data management layer includes at least one database management system implementing a primary data structure including a plurality of data elements for storing data, where this primary data structure is characterized by a fixed data schema.
  • the database management system also implements a secondary data structure operative to define a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system, whereby the primary data structure is independent of the data processing rules of the information management system.
  • the invention provides a computer readable storage medium containing a program element for execution by at least one computer including a processor and a memory for implementing in the memory of the at least one computer an information management system.
  • the information management system includes an application layer characterized by a set of data processing rules, as well as a data management layer.
  • the data management layer includes at least one database management system implementing a primary data structure including a plurality of data elements for storing data, where this primary data structure is characterized by a fixed data schema.
  • the database management system also implements a secondary data structure operative to define a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system, whereby the primary data structure is independent of the data processing rules of the information management system.
  • Figure 1 illustrates a commonly used front end N-tier client/server architecture for an information management system
  • Figure 2 depicts a functional representation of the front and back end data architecture of an N-tier client/server information management system, according to an example of implementation of the present invention
  • Figure 3 depicts a functional block diagram of an example of a computing platform implementing at least one component of the information management system shown in Figure 2;
  • Figure 4 shows a functional block diagram of an example of a single server implementing the entirety of the information management system shown in Figure 2;
  • Figures 5A, 5B and 5C illustrate the secondary data structure of the information management system shown in Figure 2, according to a specific, non- limiting example of implementation;
  • Figure 6 shows a table defining the relationships between object classes and property classes for the examples shown in Figures 5A, 5B and 5C;
  • Figure 7 shows a table defining, for each object instance, the value of each corresponding property class, for the example shown in Figures 5 A, 5B and 5C.
  • FIG. 1 illustrates a typical front end N-tier client/server architecture for an information management system, in this example a Relational DataBase Management System (RDBMS) capable to implement different business applications, for example a storage bank of customer and employee information.
  • RDBMS Relational DataBase Management System
  • the system 10 includes three main components, notably the user interface components 12, the business components 14 and the Database Management System (DBMS) 18.
  • DBMS Database Management System
  • Each user interface component 12 contains input/output rules, and is used to present information to the system user and to obtain input from the user.
  • the user interface component 12 implements presentation logic that provides menus of display options that allow the user to navigate through the different parts of the business application and, in addition, allow for the manipulation of input and output fields through a display device, such as a computer terminal.
  • Each business component 14 contains business data processing rules implementing business logic that governs both the functions and processes of the business application. These functions and processes are invoked by either a user interface component 12 when a user requests an option or by another function or process.
  • a set of access routines 16 is associated with each DBMS 18 for implementing data access logic that interfaces to the database system 18.
  • the data access functions of each set of access routines 16 are generally invoked by a business function or process of one of the business components 14; however, they may also be invoked directly by a user interface component 12.
  • Figure 2 depicts a functional representation of the font and back end data architecture of an N-tier client/server information management system, according to an example of implementation of the present invention.
  • the information management system 20 is operative to store and retrieve information, for implementing different business applications.
  • the information management system 20 includes an N-tier application layer 21, also referred to as the front end of the system 20, and an N-tier data management layer 23, also referred to as the back end of the system 20.
  • the data management layer 23 includes a plurality of database management systems 25.
  • Each database management system 25 implements a primary data structure 22 including a plurality of data elements for storing data, where this primary data structure 20 is characterized by a fixed data schema.
  • the primary data structure 22 is a physical data structure in which the physical layout of the stored data is fixed.
  • the data elements of the primary data structure 22 may consist of database tables, data fields of fixed or variable length, records, word processing documents, spreadsheets, data files, database files, indexes, relationships, among many other possibilities.
  • Examples of such database management systems 25 include relational database management systems (RDBMS), hierarchical database management systems and XML database management systems, among other possibilities.
  • RDBMS relational database management systems
  • XML database management systems XML database management systems
  • the primary data structure 22 includes a database containing a plurality of tables for storing data, where each table includes a fixed number of columns and a dynamically variable number of rows.
  • each table includes a fixed number of columns and a dynamically variable number of rows.
  • the physical layout of the tables in the primary data structure 22 is fixed, the size, or more specifically the length, of each table is variable. More specifically, the number of rows in a table of the primary data structure 22 may vary as a result of the type and quantity of data input to the system 20 for storage.
  • a data element stored in the primary data structure might include textual information and/or binary information.
  • the application layer 21 of the information management system 20 is characterized by at least one set of data processing rules 24, also referred to as business rules or business logic.
  • a data processing rule is a directive, policy or procedure, either established within an organization or by an outside source, which defines information and/or information relationships that must be supported by the system 20. Examples of business rules established by an outside source include government regulations and membership association guidelines.
  • Each set of rules 24 is associated with the processes and functions of a particular business application implemented by the information management system 20, and guides the operation of the system 20, more specifically the data processing performed by the system 20, under this particular business application.
  • the application layer 21 of the information management system 20 also includes a plurality of different client application user interfaces 26, each user interface 26 being associated with a respective set of data processing rules 24, and thus with a respective business application. As discussed above in relation to Figure 1, each user interface 26 is operative to present information to a system user, to prompt the user for input and to obtain data from the user.
  • the functionality and implementation of such a user interface is well known to those skilled in the art, and is not critical to the present invention, such that it will not be described in further detail.
  • the application layer 21 is implemented in software, and uses an object- oriented application development language, such as C++, JAVA or Visual Basic, among other possibilities.
  • object- oriented application development language such as C++, JAVA or Visual Basic, among other possibilities.
  • the functionality and implementation of the application layer of an information management system is well known to those skilled in the art, and will not be described in further detail.
  • the database management system 25 also implements a secondary data structure 28.
  • the secondary data structure 28 defines a plurality of data relationships between the data elements stored in the primary data structure 22, where these data relationships are established on the basis of the corresponding set of data processing rules 24. Accordingly, the primary data structure 22 of the database management system 25 is completely independent of the data processing rules 24.
  • examples of possible data relationships defined by the secondary data structure 28 may include the association of an e-mail address to a customer, the association of an address to a customer, the association of a telephone number to an employee, among many other possibilities.
  • the secondary data structure 28 is a logical data structure defined by a particular organization of the data elements of the primary data structure 22.
  • This logical data structure 28 is compatible with the object-oriented development language of the application layer 21, and the primary data structure 22 acts as an interface for channeling or exchanging data between the logical data structure 28 and the application layer 21.
  • the primary data structure 22 is itself transparent to the application layer 21, which communicates with the logical data structure 28.
  • the primary data structure 22 is separate from the data processing rules 24 of the application layer 21 and unaffected by any modifications made to the data processing rules 24.
  • the secondary data structure 28 is characterized by a dynamically variable data model.
  • a data model says what information is to be contained in a data structure, how the information will be used, and how the items in the data structure will be related to each other.
  • dynamically variable is implied that the secondary data structure 28 is capable to adapt to different quantities and types of information to be stored in the information management system 20.
  • the creation and modification of the secondary data structure 28 is driven by the actual data processing rules 24 of the system 20.
  • a data access module 30 allows for data to be exchanged between the database management system 25 and the application layer 21.
  • the data access module 30 includes a primary data access unit 32 and a secondary data access unit 34.
  • the primary data access unit 32 is responsible for exchanging data with the database management system 25, and generates primary data instructions for transmission to the database management system 25.
  • the database management system 25 is responsive to these primary data instructions to modify the data elements of the respective primary data structure 22.
  • the primary data instructions generated by the primary data access unit 32 implement the basic data access routines of the information management system 20, notably the Read, Write and Delete routines.
  • the Read routine allows for data to be read from the primary data structure 22, while the Write routine allows for data to be written to the primary data structure 22.
  • the Delete routine allows for data to be removed from the primary data structure 22.
  • the secondary data access unit 34 is operative to communicate and exchange data with the application layer 21 of the system 20. More specifically, the secondary data access unit 34 generates secondary data instructions on a basis of the data processing rules 24 of the application layer 21, each secondary data instruction being indicative of a modification to be made to at least one of the data relationships defined by the secondary data structure 28.
  • the secondary data instructions generated by the secondary data access unit 34 are access routines associated specifically with the logical data structure 28, in order to create, edit and delete data stored in the dynamic tables of the primary data structure 22, among other possible processes. For each different business application, and thus for each different set of data processing rules 24, the same set of access routines implemented by the secondary data access unit 34 allows for the customization of the data relationships defined by the secondary data structure 28. The particular set of access routines implemented by the secondary data access unit 34 will be described in further detail below.
  • the primary data access unit 32 is responsive to a secondary data instruction generated by the secondary data access unit 34 to convert the secondary data instruction into a primary data instruction for transmission to the database management system' 25.
  • Various different algorithms and techniques may be implemented by the primary data access unit 32 to convert secondary data instructions into primary data instructions. Such algorithms and techniques are not critical to the present invention and, as such, will not be described in further detail.
  • the separation of the fixed primary data structure 22, which stores the information being managed by the system 20, from the data processing rules 24, which define requirements to be met by the system 20, provides a flexible and adaptive data architecture for the information management system 20.
  • the implementation of a dynamically variable logical data structure 28 within the database management system 25 allows the system 20 to address new business requirements and needs that may arise over time with regard to an existing business application, without having to recreate or modify the primary data structure 22.
  • the design, development and deployment of the information management system 20 can proceed simultaneously, since the data architecture shown in Figure 2 supports future changes to the business rules and requirements of the system 20. More specifically, the specific details of the primary data structure 22 may be completed, and the data processing rules 24 added and refined, while the development of the system 20 is in progress.
  • each component of the information management system 20, including in particular the data access module 30, the data processing rules 24 and the user interfaces 26, is software implemented on one or more computing platforms, for example a server and several client workstations.
  • Figure 3 depicts a functional block diagram of one example of a computing platform 36 implementing at least one component of the information management system 20.
  • the computing platform 36 implements the data access module 30 of the information management system 20.
  • the latter is implemented by a program element that is stored in the memory 38, and executed by the controller 40, of the computing device 36.
  • the data access module 30 may be stored on a computer readable medium, such as a floppy disk, that is external to the computing device 36.
  • the floppy disk can be read by a floppy drive to load the program instructions in the memory 38.
  • the computer readable medium may be part of a remote computing platform that is in some way connected to the computing platform that executes the program element for allowing the data transfer necessary to pass the program element to the computing platform on which the execution will take place.
  • a file server containing the program element that can be accessed over any suitable connection by another computing platform to obtain the program element is considered a computer readable medium storing the program element.
  • Figure 4 shows a functional block diagram of a single server 42 implementing the entirety of the information management system 20 shown in Figure 2.
  • a memory 44 contains a program element that controls the operation of the server 42. That program element is comprised of individual instructions that are executed by various controllers 46.
  • the program element includes several functional blocks that manage several tasks. One of those functional blocks is the Primary Data Management System (PDMS) 48, which provides efficient and effective use and maintenance of the primary data structure 22.
  • the primary data structure 22 consists of a plurality of relational databases
  • the PDMS 48 is a Relational Database Management System (RDBMS).
  • RDBMS Relational Database Management System
  • the RDBMS will not be described in detail because it is well known to those skilled in the technological field to which the present invention belongs.
  • the primary and secondary data structures 22, 28 are stored in the memory 44, which also provides random access storage, capable of holding data elements such as data packets that the processors manipulate during the execution of the program element.
  • primary and secondary data structures 22, 28 are part of the memory 44 of the server 42.
  • either one or both of the primary and secondary data structures 22, 28 may be stored on a separate storage medium, such as a non-volatile medium interconnected through a high speed data bus with the memory 44 so the record set from the data structure can be quickly loaded in the random access memory 44 for processing.
  • the collection of data which makes up either one or both of the data structures 22, 28 may be stored remotely on one or a set of physical storage device(s), for instance a disk. In such a case, one of the server's device drivers would be responsible for communicating directly with the peripheral device(s) in order to access the database.
  • the particular business application to be implemented by the information management system 20 is the creation of a database for storing and retrieving customer and employee information.
  • the business requirements are:
  • the information management system 20 is characterized by the following data processing rules 24, also referred to as business rules or business logic:
  • the information management system 20 includes an RDBMS engine, whereby the primary data structure 22 is formed of a plurality of relational databases.
  • the fixed data schema of the relational database structure 22 is integrated with a modern, object-oriented development language, such as C++, JAVA or Visual Basic, for implementing the secondary data structure 28.
  • the secondary data structure 28 includes object-based tables and the set of data access routines implemented by the secondary data access unit 34 are object-oriented.
  • objects are comprised of data (properties) and processes (methods).
  • a "customer" object would be comprised of information (first name, last name, address, password, etc) and specific processes to access or update that information (read methods, write methods, etc).
  • object-oriented development languages and techniques are well known to those skilled in the art, and as such will not be discussed in further detail.
  • FIGS 5A, 5B and 5C illustrate the data schema of the secondary data structure 28, according to this specific example of implementation.
  • the secondary data structure 28 includes five tables, T1-T5, to match the defined classes and properties.
  • Tl is a table listing all of the defined object classes
  • T5 is a table listing all of the defined property classes.
  • T3 is a table defining the relationships between the defined object classes and the defined property classes.
  • T2 is a table listing the different instances of the object classes and T4 is a table defining, for each object class instance, the value of each corresponding property class, as shown in Figure 7.
  • a particular set of data access routines must also be defined, to be implemented by the secondary data access unit 34 for calling the methods of each defined property class and object class in order to customize the data relationships defined by tables T1-T5 of the secondary data structure 28.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

A data architecture for an information management system for storing and retrieving data, where the system is characterized by a set of data processing rules. The data architecture includes a database management system implementing a primary data structure including a plurality of data elements for storing data, the primary data structure being characterized by a fixed data schema. The database management system also implements a secondary data structure defining a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system. Accordingly, the primary data structure is independent of the data processing rules of the information management system, such that the primary data structure is unaffected by changes to the data processing rules of the information management system.

Description

TITLE: ADAPTIVE DATA ARCHITECTURE FOR INFORMATION
MANAGEMENT SYSTEMS
FIELD OF THE INVENTION
The invention relates to the field of information management systems. More specifically, the invention is directed to an adaptive data architecture for information management systems using database management systems (DBMS).
BACKGROUND OF THE INVENTION
The traditional approach to the design of information management systems using relational databases typically progresses through five mutually exclusive stages:
■ define business requirements;
■ design table structure (data schema);
■ program create/update and access routines for given data schema;
■ program business rules in application modules and user interfaces; ■ test and deploy system.
The overall timeframe for application development is dependent on sequentially completing each stage and then moving on to the next. For example, all of the business requirements must be completely defined before the structure of the database tables and fields, as well as their relationships, can be designed. Similarly, the table structure must be completed before the access routines can be written. Based on the completed data schema and procedures, the software programmers then start to develop the business modules and corresponding user interfaces.
This traditional approach can take considerable time. Making changes to a previously completed stage turns into a time consuming process requiring the developers to go "back to the drawing board" and re-work what was already completed. The design phase is most critical because fundamental decisions are made about the general use, purpose and shape of the application. If this foundation work is flawed, it is extremely difficult and expensive to correct later. If there are design weaknesses, the entire process has to be backed up and repeated.
Conventional relational database management systems (RDBMS) are typically built using a fixed data architecture, where this fixed data architecture consists of fixed data elements such as tables, data fields, memo fields, records, spreadsheets, data files, indexes and relationships. Specifically, a data model, including a fixed physical data structure and data access routines, is designed and implemented based on predetermined business rules and requirements known at the time of design. This data model often deteπriines the success or failure of the resulting application. Unfortunately, once completed, changes to this data model in order to implement new business requirements are very difficult, due to limitations imposed by the fixed data structure and the dependence of the data model thereon, such that both the data structures and the business rules become locked in to each other.
Consequently, the life span of the traditional information management system is relatively short, as the completed data model rapidly becomes obsolete in the face of new and evolving business requirements. The fixed data architecture limits the growth of the system, as the overall system is unable to evolve to address future business needs and requirements. . .
Furthermore, relational database management systems often have difficulty integrating with modern object-oriented application development, which introduces objects defined by dynamic templates that are able to adapt and change according to the needs of the application. This is due to the fact that the fixed data structure of the conventional relational database management system originated at a time when business requirements were known well in advance of the system design and were not expected to change once systems were designed and deployed. Thus, the fixed data structure used by relational database management systems is a severe bottleneck in the development, life cycle and flexibility of any data-centric software solution.
The common solution to the limitations of the existing RDBMS engines is the regular re-working of the fixed data architecture, time and time again, in order to implement new business processes. When unforeseen applications require access to the data schema previously developed for an. existing RDBMS, another possible solution is , the development of separate databases that run independently from the original database, even though some data may be duplicated in both the original and new databases. Such solutions are expensive, time consuming and extremely inefficient.
Against this background, a need exists in the industry for an improved data architecture for information management systems using conventional DBMS engines.
SUMMARY OF THE INVENTION
According to a broad aspect, the invention provides a data architecture for an information management system for storing and retrieving data, where the system is characterized by a set of data processing rules. The data architecture includes a database management system implementing a primary data structure including a plurality of data elements for storing data, the primary data structure being characterized by a fixed data schema. The database management system further implements a secondary data structure defining a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system, whereby the primary data structure is independent of the data processing rules of the information management system.
Advantageously, this novel data arcliitecture improves the flexibility and functionality of the information management system, which is used for the storage and retrieval of information. The data architecture allows for the separation of the fixed primary data structure from the data processing rules of the system, such that the system becomes flexible and adaptive to modifications to the data processing rules. More specifically, the actual physical data structure of the information system does not have to be modified when the data processing rules must be changed to implement new requirements.
In a specific, non-limiting example of implementation, the novel data architecture is applied to an N-tier client/server information management system, which is operative to store and retrieve information for implementing different business applications.
The information management system includes an N-tier application layer and an N-tier data management layer. The data management layer includes a plurality of database management systems. Each database management system implements a primary data structure including a plurality of data elements for storing data, where this primary data structure is characterized by a fixed data schema. In other words, the primary data structure is a physical data structure in which the physical layout of the stored data is fixed.
Examples of such database management systems include relational database management systems (RDBMS), hierarchical database management systems and XML database management systems, among other possibilities.
The application layer of the information management system is characterized by at least one set of data processing rules, also referred to as business rules or business logic. A data processing rule is a directive, policy or procedure, either established within an organization or by an outside source, which defines information and/or information relationships that must be supported by the system. Each set of rules is associated with the processes and functions of a particular business application implemented by the information management system, and guides the data processing performed by the system under this particular, business application.
The application layer of the information management system also includes a plurality of different client application user interfaces, each user interface being associated with a respective set of data processing rules, and thus with a respective business application. Each user interface is operative to present information to a system user, to prompt the user for input and to obtain data from the user.
Specific to the present invention, the database management system also implements a secondary data structure. For each business application, the secondary data structure defines a plurality of data relationships between the data elements stored in the primary data structure, where these data relationships are established on the basis of the corresponding set of data processing rules. Accordingly, the primary data structure of the database management system is completely independent of the data processing rules.
The secondary data structure is a logical data structure defined by a particular organization of the data elements of the primary data structure, and characterized by a dynamically variable data model. This logical data structure is compatible with the application layer, and the primary data structure acts simply as an interface for channeling or exchanging data between the logical data structure and the application layer.
A data access module allows for data to be exchanged between the database management system and the application layer. The data access module includes a primary data access unit and a secondary data access unit. The primary data access unit is responsible for exchanging data with the database management system, and generates primary data instructions for transmission to the database management system. The database management system is responsive to these primary data instructions to modify the data elements of the respective primary data structure. The secondary data access unit is operative to communicate and exchange data with the application layer of the system. More specifically, the secondary data access unit generates secondary data instructions on a basis of the data processing rules of the application layer, each secondary data instruction being indicative of a modification to be made to at least one of the data relationships defined by the secondary data structure.
The primary data access unit is responsive to a secondary data instruction generated by the secondary data access unit to convert the secondary data instruction into a primary data instruction for transmission to the database management system.
Various different algorithms and techniques may be implemented by the primary data access unit to convert secondary data instructions into primary data instructions.
According to another broad aspect, the invention provides an information management system for storing and retrieving data. The information management system includes an application layer characterized by a set of data processing rules, as well as a data management layer. The data management layer includes at least one database management system implementing a primary data structure including a plurality of data elements for storing data, where this primary data structure is characterized by a fixed data schema. The database management system also implements a secondary data structure operative to define a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system, whereby the primary data structure is independent of the data processing rules of the information management system.
According to yet another broad aspect, the invention provides a computer readable storage medium containing a program element for execution by at least one computer including a processor and a memory for implementing in the memory of the at least one computer an information management system. The information management system includes an application layer characterized by a set of data processing rules, as well as a data management layer. The data management layer includes at least one database management system implementing a primary data structure including a plurality of data elements for storing data, where this primary data structure is characterized by a fixed data schema. The database management system also implements a secondary data structure operative to define a plurality of data relationships between the data elements of the primary data structure on a basis of the data processing rules of the information management system, whereby the primary data structure is independent of the data processing rules of the information management system.
BRIEF DESCRIPTION OF THE DRA WINGS
These and other features of the present invention will become apparent from the following detailed description considered in connection with the accompanying drawings, of which: ,
Figure 1 illustrates a commonly used front end N-tier client/server architecture for an information management system;
Figure 2 depicts a functional representation of the front and back end data architecture of an N-tier client/server information management system, according to an example of implementation of the present invention;
Figure 3 depicts a functional block diagram of an example of a computing platform implementing at least one component of the information management system shown in Figure 2;
Figure 4 shows a functional block diagram of an example of a single server implementing the entirety of the information management system shown in Figure 2; Figures 5A, 5B and 5C illustrate the secondary data structure of the information management system shown in Figure 2, according to a specific, non- limiting example of implementation;
Figure 6 shows a table defining the relationships between object classes and property classes for the examples shown in Figures 5A, 5B and 5C; and
Figure 7 shows a table defining, for each object instance, the value of each corresponding property class, for the example shown in Figures 5 A, 5B and 5C.
In the drawings, embodiments of the invention are illustrated by way of example. It is to be expressly understood, however, that the drawings are provided only for purposes of illustration and as ari aid to understanding, and are not intended to be a definition of the limits of the invention, for which reference should be made to the appending claims.
DETAILED DESCRIPTION
Figure 1 illustrates a typical front end N-tier client/server architecture for an information management system, in this example a Relational DataBase Management System (RDBMS) capable to implement different business applications, for example a storage bank of customer and employee information. The system 10 includes three main components, notably the user interface components 12, the business components 14 and the Database Management System (DBMS) 18.
Each user interface component 12 contains input/output rules, and is used to present information to the system user and to obtain input from the user. The user interface component 12 implements presentation logic that provides menus of display options that allow the user to navigate through the different parts of the business application and, in addition, allow for the manipulation of input and output fields through a display device, such as a computer terminal.
Each business component 14 contains business data processing rules implementing business logic that governs both the functions and processes of the business application. These functions and processes are invoked by either a user interface component 12 when a user requests an option or by another function or process.
A set of access routines 16 is associated with each DBMS 18 for implementing data access logic that interfaces to the database system 18. The data access functions of each set of access routines 16 are generally invoked by a business function or process of one of the business components 14; however, they may also be invoked directly by a user interface component 12.
Figure 2 depicts a functional representation of the font and back end data architecture of an N-tier client/server information management system, according to an example of implementation of the present invention.1 The information management system 20 is operative to store and retrieve information, for implementing different business applications.
The information management system 20 includes an N-tier application layer 21, also referred to as the front end of the system 20, and an N-tier data management layer 23, also referred to as the back end of the system 20.
The data management layer 23 includes a plurality of database management systems 25. Each database management system 25 implements a primary data structure 22 including a plurality of data elements for storing data, where this primary data structure 20 is characterized by a fixed data schema. In other words, the primary data structure 22 is a physical data structure in which the physical layout of the stored data is fixed. The data elements of the primary data structure 22 may consist of database tables, data fields of fixed or variable length, records, word processing documents, spreadsheets, data files, database files, indexes, relationships, among many other possibilities.
For the purposes of clarification, the following example of implementation will be described in the context of a single database management system 25, although the same implementation may be applied to the plurality of database management systems 25.
Examples of such database management systems 25 include relational database management systems (RDBMS), hierarchical database management systems and XML database management systems, among other possibilities.
In a specific example, the primary data structure 22 includes a database containing a plurality of tables for storing data, where each table includes a fixed number of columns and a dynamically variable number of rows. Although the physical layout of the tables in the primary data structure 22 is fixed, the size, or more specifically the length, of each table is variable. More specifically, the number of rows in a table of the primary data structure 22 may vary as a result of the type and quantity of data input to the system 20 for storage.
It should be noted that a data element stored in the primary data structure might include textual information and/or binary information.
The application layer 21 of the information management system 20 is characterized by at least one set of data processing rules 24, also referred to as business rules or business logic. A data processing rule is a directive, policy or procedure, either established within an organization or by an outside source, which defines information and/or information relationships that must be supported by the system 20. Examples of business rules established by an outside source include government regulations and membership association guidelines. Each set of rules 24 is associated with the processes and functions of a particular business application implemented by the information management system 20, and guides the operation of the system 20, more specifically the data processing performed by the system 20, under this particular business application.
The application layer 21 of the information management system 20 also includes a plurality of different client application user interfaces 26, each user interface 26 being associated with a respective set of data processing rules 24, and thus with a respective business application. As discussed above in relation to Figure 1, each user interface 26 is operative to present information to a system user, to prompt the user for input and to obtain data from the user. The functionality and implementation of such a user interface is well known to those skilled in the art, and is not critical to the present invention, such that it will not be described in further detail.
The application layer 21 is implemented in software, and uses an object- oriented application development language, such as C++, JAVA or Visual Basic, among other possibilities. The functionality and implementation of the application layer of an information management system is well known to those skilled in the art, and will not be described in further detail.
Specific to the present invention, the database management system 25 also implements a secondary data structure 28. For each business application, the secondary data structure 28 defines a plurality of data relationships between the data elements stored in the primary data structure 22, where these data relationships are established on the basis of the corresponding set of data processing rules 24. Accordingly, the primary data structure 22 of the database management system 25 is completely independent of the data processing rules 24.
Take for example the situation where the business application to be implemented by the information management system 20 is the creation of a database of customer and employee information. In this case, examples of possible data relationships defined by the secondary data structure 28 may include the association of an e-mail address to a customer, the association of an address to a customer, the association of a telephone number to an employee, among many other possibilities.
More specifically, the secondary data structure 28 is a logical data structure defined by a particular organization of the data elements of the primary data structure 22. This logical data structure 28 is compatible with the object-oriented development language of the application layer 21, and the primary data structure 22 acts as an interface for channeling or exchanging data between the logical data structure 28 and the application layer 21. In this way, the primary data structure 22 is itself transparent to the application layer 21, which communicates with the logical data structure 28. Thus, the primary data structure 22 is separate from the data processing rules 24 of the application layer 21 and unaffected by any modifications made to the data processing rules 24.
The secondary data structure 28 is characterized by a dynamically variable data model. As is well known to those skilled in the art, a data model says what information is to be contained in a data structure, how the information will be used, and how the items in the data structure will be related to each other. By "dynamically variable" is implied that the secondary data structure 28 is capable to adapt to different quantities and types of information to be stored in the information management system 20. Thus, the creation and modification of the secondary data structure 28 is driven by the actual data processing rules 24 of the system 20.
A data access module 30 allows for data to be exchanged between the database management system 25 and the application layer 21. As shown in Figure 2, the data access module 30 includes a primary data access unit 32 and a secondary data access unit 34. The primary data access unit 32 is responsible for exchanging data with the database management system 25, and generates primary data instructions for transmission to the database management system 25. The database management system 25 is responsive to these primary data instructions to modify the data elements of the respective primary data structure 22.
In a specific example, the primary data instructions generated by the primary data access unit 32 implement the basic data access routines of the information management system 20, notably the Read, Write and Delete routines. The Read routine allows for data to be read from the primary data structure 22, while the Write routine allows for data to be written to the primary data structure 22. The Delete routine allows for data to be removed from the primary data structure 22.
The secondary data access unit 34 is operative to communicate and exchange data with the application layer 21 of the system 20. More specifically, the secondary data access unit 34 generates secondary data instructions on a basis of the data processing rules 24 of the application layer 21, each secondary data instruction being indicative of a modification to be made to at least one of the data relationships defined by the secondary data structure 28.
The secondary data instructions generated by the secondary data access unit 34 are access routines associated specifically with the logical data structure 28, in order to create, edit and delete data stored in the dynamic tables of the primary data structure 22, among other possible processes. For each different business application, and thus for each different set of data processing rules 24, the same set of access routines implemented by the secondary data access unit 34 allows for the customization of the data relationships defined by the secondary data structure 28. The particular set of access routines implemented by the secondary data access unit 34 will be described in further detail below.
The primary data access unit 32 is responsive to a secondary data instruction generated by the secondary data access unit 34 to convert the secondary data instruction into a primary data instruction for transmission to the database management system' 25. Various different algorithms and techniques may be implemented by the primary data access unit 32 to convert secondary data instructions into primary data instructions. Such algorithms and techniques are not critical to the present invention and, as such, will not be described in further detail.
Thus, the separation of the fixed primary data structure 22, which stores the information being managed by the system 20, from the data processing rules 24, which define requirements to be met by the system 20, provides a flexible and adaptive data architecture for the information management system 20. In particular, the implementation of a dynamically variable logical data structure 28 within the database management system 25 allows the system 20 to address new business requirements and needs that may arise over time with regard to an existing business application, without having to recreate or modify the primary data structure 22. Furthermore, the design, development and deployment of the information management system 20 can proceed simultaneously, since the data architecture shown in Figure 2 supports future changes to the business rules and requirements of the system 20. More specifically, the specific details of the primary data structure 22 may be completed, and the data processing rules 24 added and refined, while the development of the system 20 is in progress.
According to the present example of implementation, each component of the information management system 20, including in particular the data access module 30, the data processing rules 24 and the user interfaces 26, is software implemented on one or more computing platforms, for example a server and several client workstations. Figure 3 depicts a functional block diagram of one example of a computing platform 36 implementing at least one component of the information management system 20. Assume for example that the computing platform 36 implements the data access module 30 of the information management system 20. The latter is implemented by a program element that is stored in the memory 38, and executed by the controller 40, of the computing device 36. Alternatively, the data access module 30 may be stored on a computer readable medium, such as a floppy disk, that is external to the computing device 36. The floppy disk can be read by a floppy drive to load the program instructions in the memory 38. The computer readable medium may be part of a remote computing platform that is in some way connected to the computing platform that executes the program element for allowing the data transfer necessary to pass the program element to the computing platform on which the execution will take place. For example, a file server containing the program element that can be accessed over any suitable connection by another computing platform to obtain the program element is considered a computer readable medium storing the program element.
In another example, Figure 4 shows a functional block diagram of a single server 42 implementing the entirety of the information management system 20 shown in Figure 2. In this case, a memory 44 contains a program element that controls the operation of the server 42. That program element is comprised of individual instructions that are executed by various controllers 46. The program element includes several functional blocks that manage several tasks. One of those functional blocks is the Primary Data Management System (PDMS) 48, which provides efficient and effective use and maintenance of the primary data structure 22. For example, in the case where the primary data structure 22 consists of a plurality of relational databases, the PDMS 48 is a Relational Database Management System (RDBMS). The RDBMS will not be described in detail because it is well known to those skilled in the technological field to which the present invention belongs. The primary and secondary data structures 22, 28 are stored in the memory 44, which also provides random access storage, capable of holding data elements such as data packets that the processors manipulate during the execution of the program element.
In the example shown in Figure 4, primary and secondary data structures 22, 28 are part of the memory 44 of the server 42. Alternatively, either one or both of the primary and secondary data structures 22, 28 may be stored on a separate storage medium, such as a non-volatile medium interconnected through a high speed data bus with the memory 44 so the record set from the data structure can be quickly loaded in the random access memory 44 for processing. Alternatively, the collection of data which makes up either one or both of the data structures 22, 28 may be stored remotely on one or a set of physical storage device(s), for instance a disk. In such a case, one of the server's device drivers would be responsible for communicating directly with the peripheral device(s) in order to access the database.
In a specific, non-limiting example of implementation of the present invention, assume that the particular business application to be implemented by the information management system 20 is the creation of a database for storing and retrieving customer and employee information. For this particular business application, the business requirements are:
CUSTOMER
For each customer, the following information must be captured: Name Last Name Physical Addresses
Addrl Addr2 City Electronic Addresses Email-Address
Cell Numbers
EMPLOYEE
For each employee, the following information must be captured: Name Log Name
Password
Physical Addresses Addrl Addr2 City
Country Electronic Addresses Email-Address Cell Numbers Further, assume that the information management system 20 is characterized by the following data processing rules 24, also referred to as business rules or business logic:
1- Every time a customer is added to the database, you must have a first name, a last name and a physical address. 2- Every time an employee is added to the database, you must have a first name, a last name and an electronic address.
Assume that the information management system 20 includes an RDBMS engine, whereby the primary data structure 22 is formed of a plurality of relational databases. The fixed data schema of the relational database structure 22 is integrated with a modern, object-oriented development language, such as C++, JAVA or Visual Basic, for implementing the secondary data structure 28. More specifically, the secondary data structure 28 includes object-based tables and the set of data access routines implemented by the secondary data access unit 34 are object-oriented. Typically, under an object-oriented development language, objects are comprised of data (properties) and processes (methods). For example, a "customer" object would be comprised of information (first name, last name, address, password, etc) and specific processes to access or update that information (read methods, write methods, etc). Such object-oriented development languages and techniques are well known to those skilled in the art, and as such will not be discussed in further detail.
The following steps must be followed in order to generate an object-oriented secondary data structure 28 :
1. Define required class elements: a. Property class(es) b. Object class(es)
2. Define methods for: a. Property class(es) b. Object Class(es) 3. Define a data schema to match the defined classes and properties (table layout of the secondary data structure 28).
4. Write an application programming interface to call all the methods of these classes and properties (data access routines of the secondary data access unit 34).
Continuing with the specific, non-limiting example of implementation of the database of customer and employee information, the following property and object classes are defined: Property classes Object classes
Name Customer
Last Name Employee
First Name P-Address
Addrl E-Address Addr2
City Country Email-Address Cell Number Log Name
Password
For each defined property class, the following methods are defined: i. Create instances of property class ii. Update instances of property class iii. Delete instances of property class
Similarly, for each defined object class, the following methods are defined: i. Create instances of object class ii. Update instances of object class iii. Delete instances of object class
Figures 5A, 5B and 5C illustrate the data schema of the secondary data structure 28, according to this specific example of implementation. As seen in Figure 5C, the secondary data structure 28 includes five tables, T1-T5, to match the defined classes and properties. Tl is a table listing all of the defined object classes, while T5 is a table listing all of the defined property classes. As shown in Figure 6, T3 is a table defining the relationships between the defined object classes and the defined property classes. T2 is a table listing the different instances of the object classes and T4 is a table defining, for each object class instance, the value of each corresponding property class, as shown in Figure 7.
A particular set of data access routines must also be defined, to be implemented by the secondary data access unit 34 for calling the methods of each defined property class and object class in order to customize the data relationships defined by tables T1-T5 of the secondary data structure 28. The following is one example of such a set of data access routines:
AddObjectClass(("ObjectClass") (Insert ObjectClass into Tl )
Add PropertyClass (("PropertyClass") (Insert PropertyClass into T5 ) AssociateOCPC(ObjectClass, PropertyClasses)
(
Loop for number of PropertyClasses
Insert ObjectClassID, PropertyClassesID into 't3
End loop )
CreatPropertInstance(Obj ectClass, Obj ectClassInst, PropertyClasses Values)
(
Insert Obj ectClassInst into T2
Loop for number of PropertyClasses Values
Insert ObjectClassID, PropertyClassesID, ObjectClassInstID,
PropertyClasses Values into t4 End loop )
Get info("ObjectClassInst"," PropertyClasses")
(
Select values from T5 as a, T2 as b , Tl as c , T3 as d where a.oiid = b.oiid and c.oid = b.oid and d.opid = a.opid, etc. Advantageously, using these data access routines, it is possible to:
• Create any Property class • Create any Object class
• Associate any Object class with any Property class
• Create an Object class instance with Property class values
Now, assume that information indicative of a new customer is input by a user for storage in the information management system 20. This inputted data will drive the secondary data structure 28 to create a new Object class instance in table T2 for this new customer, prompting the user for the associated Property class values in order to complete the table T4. Thus, in this scenario, the tables T2 and T4 will be dynamically varied by the addition of one or more new rows for the new customer information. In a different scenario, a customer could be deleted from the database, such that the corresponding Object class instance in table T2 would be deleted, and at least one row from each table T2 and T4 would be deleted.
Although several embodiments have been illustrated, this was for the purpose of describing, but not limiting, the invention. Various modifications will become apparent to those skilled in the art and are within the scope of this invention, which is defined more particularly by the attached claims.

Claims

CLAIMS:
1. A data architecture for an information management system for storing and retrieving data, the information management system including an application layer characterized by a set of data processing rules, said data architecture comprising: a) at least one database management system implementing: i) a primary data structure including a plurality of data elements for storing data, said primary data structure , being characterized by a fixed data schema; ii) a secondary data structure operative to define a plurality of data relationships between the data elements of said primary data structure on a basis of the data processing rules of the information management system, whereby said primary data structure is independent of the data processing rules of the information management system.
2. A data architecture as defined in claim 1, wherein said secondary data structure is characterized by a dynamically variable data model.
3. A data architecture as defined in claim 2, wherein said primary data structure is a physical data structure and said secondary data structure is a logical data structure.
4. A data architecture as defined in claim 3, wherein said primary data structure includes at least one database containing the data elements.
5. A data architecture as defined in claim 4, wherein said secondary data structure is defined by a particular organization of the data elements of said primary data structure.
6. A data architecture as defined in claim 5, wherein the data elements are selected from the group consisting of tables, data fields, memo fields, records, spreadsheets, data files, indexes and relationships.
7. A database architecture as defined in claim 1, wherein said information management system is an N-tier information management system.
8. A database architecture as defined in claim 1, wherein said database management system is a relational database management system.
9. A database architecture as defined in claim 8, wherein said primary data structure includes a plurality of relational databases.
10. A database architecture as defined in claim 1, wherein said database management system is a hierarchical database management system.
11. A database architecture as defined in claim 1, wherein said database management system is an XML database management system.
12. A computer readable storage medium storing the data architecture defined in claim 1.
13. An information management system for storing and retrieving data, said information management system comprising: a) an application layer characterized by a set of data processing rules; b) a data management layer including: i) at least one database management system implementing:
(1) a primary data structure including a plurality of data elements for storing data, said primary data structure being characterized by a fixed data schema;
(2) a secondary data structure operative to define a plurality of data relationships between the data elements of said primary data structure on a basis of the data processing rules of the information management system, whereby said primary data structure is independent of the data processing rules of the information management system.
14. An information management system as defined in claim 13, wherein said secondary data structure is characterized by a dynamically variable data model.
15. An information management system as defined in claim 14, wherein said primary data structure is a physical data structure and said secondary data structure is a logical data structure.
16. An information management system as defined in claim 15, wherein said primary data structure includes at least one database containing the data elements.
17. An information management system as defined in claim 16, wherein said secondary data structure is defined by a particular organization of the data elements of said primary data structure.
18. An information management system as defined in claim 17, wherein said data management layer further includes a data access module operative to exchange data between said at least one database management system and said application layer.
19. An information management system as defined in claim 18, wherein said data access module includes a primary data access unit in communicative relationship with said database management system, said primary data access unit being operative to generate primary data instructions, said database management system being responsive to said primary data instructions to modify the data elements of said primary data structure.
20. An information management system as defined in claim 19, wherein said data access module further includes a secondary data access unit in communicative relationship with said application layer, said secondary data access unit being operative to generate secondary data instructions on a basis of the data processing rules of said application layer, each secondary data instruction being indicative of a modification to be made to at least one of the data relationships defined by said secondary data structure.
21. An information management system as defined in claim 20, wherein said primary data access unit is operative to convert said secondary data instructions to primary data instructions for transmission to said database management system.
22. An information management system as defined in claim 13, wherein said application layer is an N-tier application layer and said data management layer is an N-tier data management layer.
23. An information management system as defined in claim 13, wherein said database management system is a relational database management system.
24. An information management system as defined in claim 13, wherein said database management system is a hierarchical database management system.
25. An information management system as defined in claim 13, wherein said database management system is an XML database management system.
26. A computer readable storage medium containing a program element for execution by at least one computer including a processor and a memory for implementing in the memory of said at least one computer an information management system, said information management system including: a) an application layer characterized by a set of data processing rules; b) a data management layer including: i) at least one database management system implementing:
(1) a primary data structure including a plurality of data elements for storing data, said primary data structure being characterized by a fixed data schema; (2) a secondary data structure operative to define a plurality of data relationships between the data elements of said primary data structure on a basis of the data processing rules of the information management system, whereby said primary data structure is independent of the data processing rules of the information management system.
PCT/CA2003/000012 2003-01-10 2003-01-10 Adaptive data architecture for information management systems WO2004063940A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2003201237A AU2003201237A1 (en) 2003-01-10 2003-01-10 Adaptive data architecture for information management systems
PCT/CA2003/000012 WO2004063940A1 (en) 2003-01-10 2003-01-10 Adaptive data architecture for information management systems

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CA2003/000012 WO2004063940A1 (en) 2003-01-10 2003-01-10 Adaptive data architecture for information management systems

Publications (1)

Publication Number Publication Date
WO2004063940A1 true WO2004063940A1 (en) 2004-07-29

Family

ID=32686696

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2003/000012 WO2004063940A1 (en) 2003-01-10 2003-01-10 Adaptive data architecture for information management systems

Country Status (2)

Country Link
AU (1) AU2003201237A1 (en)
WO (1) WO2004063940A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2079029A2 (en) * 2008-01-09 2009-07-15 Accenture Global Services GmbH Call center application data and interoperation architecture for a telecommunication service center

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1081609A2 (en) * 1999-09-03 2001-03-07 Cognos Incorporated Metadata model
WO2002059793A2 (en) * 2000-10-31 2002-08-01 Michael Philip Kaufman System and method for generating automatic user interface for arbitrarily complex or large databases

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1081609A2 (en) * 1999-09-03 2001-03-07 Cognos Incorporated Metadata model
WO2002059793A2 (en) * 2000-10-31 2002-08-01 Michael Philip Kaufman System and method for generating automatic user interface for arbitrarily complex or large databases

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ARNOLD-MOORE T ET AL: "Architecture of a content management server for XML document applications", WEB INFORMATION SYSTEMS ENGINEERING, 2000. PROCEEDINGS OF THE FIRST INTERNATIONAL CONFERENCE ON HONG KONG, CHINA 19-21 JUNE 2000, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 19 June 2000 (2000-06-19), pages 97 - 108, XP010521842, ISBN: 0-7695-0577-5 *
PETROU C ET AL: "An XML-based, 3-tier scheme for integrating heterogeneous information sources to the WWW", DATABASE AND EXPERT SYSTEMS APPLICATIONS, 1999. PROCEEDINGS. TENTH INTERNATIONAL WORKSHOP ON FLORENCE, ITALY 1-3 SEPT. 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 1 September 1999 (1999-09-01), pages 706 - 710, XP010352389, ISBN: 0-7695-0281-4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2079029A2 (en) * 2008-01-09 2009-07-15 Accenture Global Services GmbH Call center application data and interoperation architecture for a telecommunication service center
EP2079029A3 (en) * 2008-01-09 2009-07-22 Accenture Global Services GmbH Call center application data and interoperation architecture for a telecommunication service center
US8068599B2 (en) 2008-01-09 2011-11-29 Accenture Global Services Limited Call center application data and interoperation architecture for a telecommunication service center

Also Published As

Publication number Publication date
AU2003201237A1 (en) 2004-08-10

Similar Documents

Publication Publication Date Title
US9886245B2 (en) Software development tool using a workflow pattern that describes software applications
US5937409A (en) Integrating relational databases in an object oriented environment
Bauer Hibernate in action
US7020660B2 (en) Data object generator and method of use
KR20060045622A (en) Extraction, transformation and loading designer module of a computerized financial system
JP2002538546A (en) ABAP Code Converter Specifications
WO1996034350A1 (en) Modeling of object-oriented database structures, translation to relational database structures, and dynamic searches thereon
Dittrich et al. An event/trigger mechanism to enforce complex consistency constraints in design databases
US7464095B2 (en) Adaptive data architecture for information management systems
CN103744647A (en) Java workflow development system and method based on workflow GPD
US20060085473A1 (en) Method and system for business process super-transaction
EP1492035A2 (en) Defining user-defined data types and/or user-defined methods using an interpreted programming language
US20060129985A1 (en) Development and execution platform
US8433729B2 (en) Method and system for automatically generating a communication interface
US20070067254A1 (en) Business model data management
US20230333972A1 (en) Software testing in parallel with different database instances
US11860772B2 (en) Software testing in parallel threads with a record-locking database
US11720482B1 (en) Retrying failed test cases in software testing using parallel threads
WO2004063940A1 (en) Adaptive data architecture for information management systems
CN111966687B (en) Mainframe DB2 database table partitioning method and device
CA2393111A1 (en) Adaptive data architecture for information management systems
CN107025110A (en) A kind of tense modeling method based on software development key element and its contact
Batz et al. The application-specific task area
Neill et al. ASTROS enhancements
Neill et al. ASTROS Enhancements: Volume 2–ASTROS Programmer’s Manual

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP