WO2016101301A1

WO2016101301A1 - Objectification and virtualization mechanism for mode of relational database table

Info

Publication number: WO2016101301A1
Application number: PCT/CN2014/095494
Authority: WO
Inventors: 郭树盛; 唐素芳; 徐志伟
Original assignee: 广东电子工业研究院有限公司
Priority date: 2014-12-25
Filing date: 2014-12-30
Publication date: 2016-06-30
Also published as: CN104462559A; CN104462559B

Abstract

An objectification and virtualization mechanism for a mode of a mainstream relational database table. Rational database tables with huge physical differences are converted into a uniform object model, that is, each of the database tables is simply regarded as a p-v object instance system, and each database table field is converted into a pojo instance to serve as a key attribute of the p-v object instance system and is persistent in a cloud database meta node database so as to form a virtual table resource. Thus, a complex physical structure of a multi-element heterogeneous database is evolved into a uniform virtual database platform with a relatively simple logic, a mapping is established between a logic element and a physical element, and an operation mode of concept of a logic layer is defined and mapped into an operation mode for the physical element, complex underlying physical details and differences are shielded, and a cloud database virtualization platform uniformly based on an object model operation is provided. The solution solves the problem that database data cannot be uniformly managed and cannot interconnect and interwork, and thus can be used for the interconnection and interworking of the database data.

Description

Relational database table schema objectification and virtualization mechanism

Technical field

The present invention relates to the field of computer application technologies, and in particular, to a relational database table schema objectification and virtualization mechanism.

Background technique

Data sources are diverse, heterogeneous, and off-site. They are the basic forms of existing software application systems. The database used varies due to the complexity of the system business and the application environment. The data between the systems cannot be directly interconnected, and even more Conduct unified management. At this stage, the mainstream relational database technologies are also inconsistent and difficult to grasp. It is difficult for development and maintenance personnel to take into account the management and maintenance of all types of relational databases, and it is impossible to realize data interconnection from the underlying physical structure of the database. This will inevitably lead to the separate use of the data and information of the software application systems of each information interconnection to form an "island" of information that is not connected to each other. With the advent of the era of big data, data sharing and correlation analysis mining has become more and more important, not only providing important information for upper-level decision-making, but also has many immeasurable business values.

Summary of the invention

The invention is directed to the phenomenon that the data source of the existing software application system is diverse, heterogeneous, and off-site, and the database data cannot be uniformly managed and interconnected to form an "island" of information, and a mainstream relational database table schema object is provided. The mechanism of virtualization and virtualization.

The technical solution of the present invention to solve the above technical problem is:

The mechanism is implemented by a virtual database, a virtual table, a virtual view, and a many-to-many mapping between them and a physical application server, a database server, a database, and a data table;

The virtual database is a virtual space organized and managed in a network environment; there is a corresponding virtual table (virtual level virtual resource), a role that can allocate virtual table usage rights, a virtual library resource user, and a virtual database. Other entities such as views (virtual tables created based on virtual tables): and other network knowledge and activities derived from behavioral relationships within their lifecycle, the virtual database is a logical virtual network space with defined boundaries, as: 1) Specific network cohesive space composed of users, virtual resources, and roles; 2) interface between virtual space and network physical elements; operation of virtual database: creation, modification, and deletion; virtual resources can be moved or copied between virtual databases. Different virtual database administrators can share virtual resources;

The virtual table is an abstract concept representing a database server, a database, and a table at a logical level. It belongs to a specific virtual database, and has a relationship characteristic, having a schema and a constraint; implementing and specific through the pr mode and the vr mode. The physical table of the database forms a one-to-one correspondence; the virtual table satisfies the relational operation operator, and a new virtual table, that is, a virtual view, can be formed through operations such as connection and association, thereby forming an access and mapping relationship between the virtual tables having the hierarchical structure; Complex data models and connections that can be used to represent business needs; operations of virtual tables: create, delete, modify, and interface to read, write, change, and delete data;

The virtual view is a composite virtual table based on a virtual table, and is a logical view recombined based on a virtual table field. The virtual view also has a relationship characteristic, having a schema and a constraint; it can correspond to multiple virtual The table has no direct correspondence with the physical table, but is indirectly mapped to each database physical table field according to the virtual table field; that is, the upper level vr mode and the lower vr mode are used to implement the hierarchical mapping relationship; The library table data integration and the sql association operation realize the sharing and association operation of the data information without changing the physical attributes of the underlying databases;

Mapping: The mapping relationship reflects the operation mapping between the virtual database, the virtual table/view, and the physical application server, the database server, the database, and the data table (file); the operation of facing the virtual database and the virtual table at the logical layer is finally mapped to The operation of the corresponding one or more physical concept entities; this mapping is many-to-many, and can also be cross-constraint; the virtual table can establish a mapping relationship between the physical database and the table (including files), and the mapping relationship is non- One-to-one correspondence, a virtual table schema Can be mapped to one or more database servers, databases, tables (files) on the network;

Each library table corresponds to a p-v object instance system, and the library table field corresponds to a pojo instance; thereby shielding the complex physical details and differences of the current software application system database.

All heterogeneous relational library tables are controlled by a unified virtual table logic concept, that is, each library table is simply regarded as a pv object instance system, and is persisted into a virtual table resource, and the basic virtual table and the actual relational database table. Establish a one-to-one mapping relationship, through the virtual view mode customization and virtual table data operations (additions and deletions, joins, unions, etc.) can be finally mapped to the corresponding operations of the underlying library table; in the case of shielding the underlying heterogeneous database differences Users can perform some operations across the library by building views on the underlying virtual tables.

The main features of vr mode and pr mode are: they all include the concept of objectization and persistence; objectification level: MetaVr object model of vr mode corresponding to library table, mainly by virtual library ID, virtual table ID, field attribute (library Table field pojo group json string), creation time, owner ID and other attributes; pr mode corresponding to the library table MetaPr object model, also mainly by virtual library ID, virtual table ID, field attributes (library table field pojo group Json string), creation time, owner ID and other attributes; only the virtual surface layer has both vr mode and pr mode, they establish mapping through specific field mapping; while virtual view layer only has vr mode layer, through upper vr mode Layer-to-lower vr mode layer mapping relationship is layer-by-layer mapping, and finally mapped to the virtual surface layer; persistence level: vr mode corresponds to a specific data record of the metabase table of the cloud database base library table; pr mode corresponds to the cloud database base library table metapr A specific data record of the table; vr mode and pr mode, the relationship between the upper vr mode and the lower vr mode is through the representative virtual table Site, field mapping value field value or attribute value to associate and establish mapping relationships.

Among the mechanisms described, the main steps of virtualization are as follows:

The first step is to install a virtualized heterogeneous data integration service platform on each node, and then Configure other application server nodes in the configuration file of the previous node;

The second step is to deploy the initial environment required for system operation: 1) Import the system base library, which is the meta node database. 2) Register the virtual library account and activate it, and the system administrator approves it;

In the third step, the virtual library administrator logs in to the system, creates his own virtual database, registers the virtual table, creates a virtual view based on the virtual table, and then creates his own ordinary users and user roles. The virtual library administrator can use this function to create the virtual database n required by other applications. When creating a virtual database, you can register the virtual tables required by the virtual database or create virtual views. You also need to specify the storage location of the physical library tables mapped by these virtual tables. Each time a virtual database is created, at least one ordinary user is allocated to the virtual database. After the ordinary user logs in to the system, the resources of the virtual database can be used and operated (within the authority). Similarly, a virtual database m can be created on the service platform, and each virtual database number is globally unique, ensuring that multiple virtual databases can have a uniform global unique number;

In the fourth step, an application developed for any virtual database can use a virtual database label. The virtual table label (vdbid.vid) transparently accesses various resources through the access interface of the virtual table, wherein the program developer is not necessarily a virtual database. The user, while the program is running, will access the internal logic of the interface to determine whether the user has access to the virtual table/view based on the identity of the currently accessed user.

The beneficial effects of this method are:

By summarizing and abstracting the physical concepts at the logical level, with the three logical concepts and mappings of virtual databases, virtual tables, and virtual views, it is possible to represent and operate the physical application servers, database servers, databases, and table. Such a large number of operations for designing, developing, deploying, maintaining, and managing Internet applications and resources can be directly based on these two logical concepts, shielding the cumbersome details of physical operations that must be prioritized before, ensuring the convenience of using the Internet platform. And the scalable, portable, and loosely coupled nature of the application.

Using the method of the present invention, the cloud database virtualization platform can transparently develop, deploy, and manage network applications in a distributed network environment, without paying attention to physical resources and running application servers. Location, transforming heterogeneous relational library tables and library tables into a series of unified object model instances for control and operation. The heterogeneity of resources and the details of physical operations are shielded; applications developed based on this virtual platform are globally accessible, deployable, and portable, ensuring the convenience of using the cloud database platform.

DRAWINGS

The present invention is further described below in conjunction with the accompanying drawings:

Figure 1 is a diagram of the various elements of the multi-heterogeneous software architecture and its virtualization mechanism;

Figure 2 is a diagram of the database library table field objectification and persistence process;

FIG. 3 is a hierarchical field mapping relationship diagram between virtual view virtual tables.

detailed description

In Figure 1, several basic elements of the cloud database virtualization platform are included, as well as the correspondence between these basic elements and the virtual database and virtual table. The general network application is served by the application server and the database server connected to the back end for multiple front-end users, and the database server has its corresponding database. Each network application calls its own virtual resource, that is, a virtual table, according to its own needs, and then calls the data resource through the mapping relationship between the virtual table and the underlying database through the virtual resource address. When the user scale or data size of the system is expanded, the application server and the database server can be separately expanded to form a networked cluster service platform. At the same time, when the load of a single database server is too high, it is possible to further split multiple tables in one or more libraries and deploy them to different database servers, so that a single database can be reduced in a finer granularity. The load of the server.

In Figure 2, after the relational database library table attribute is objectified, it is converted into json string, which is the attribute value of MetaPr and MetaVr object. Finally, it is persisted to metavr and metapr library table by java object and library table orm technology to become its specific data. Record the value.

In Figure 3, the upper virtual table (virtual view) field is mapped to the lower virtual view or the underlying virtual table by address, and each underlying virtual table mode (named vr in the figure) has a unique fixed pr mode. Corresponding, and the pr table has a one-to-one correspondence with the underlying physical table relationship.

All the heterogeneous relational library tables in this issue are controlled by the unified virtual table logic concept, that is, each library table is simply regarded as a pv object instance system, and is persisted into a virtual table resource, and the basic virtual table is actually The relational database table establishes a one-to-one mapping relationship, and the virtual view mode customization and the operation of the virtual table data (addition, deletion, modification, join, union, etc.) can be finally mapped to the corresponding operations of the underlying library table. In the case of shielding the underlying heterogeneous database differences, users can perform some operations between the inter-libraries by building views in the basic virtual table, such as join, union, etc.

The virtual table belongs to a specific virtual library. In the virtualization platform, it is managed by a virtual library. The essence is a data record of the metavr table of the cloud database meta-node database and a materialization of the metapr table data record associated with the phase mapping. It is similar to the actual database table. The field is the basic unit. Each field corresponds to a pojo instance. That is, the virtual table field of the virtual table or upper view is mapped to an actual database library table field. The virtual table field pojo has some unique attributes such as mapping, mapping, code, etc. in addition to those of the actual physical library table, such as field type, field name, and field length. The virtual table field is also the only identifiable number. In addition to some properties similar to the actual library table, the virtual table also has its own unique properties, such as the unique address of the virtual table, the creator, the creation time, and so on.

The virtualized resource layer (virtual table) operation performed by the user through the virtualization platform essentially changes the logical table layer schema of the library table and does not directly change the actual library table schema. The actual database table (hereinafter referred to as the underlying physical table), the basic virtual table, the view (virtual table view) built on the basic virtual table is through the hierarchical mapping to establish the relationship. In the basic virtual surface layer, each virtual table has its corresponding vr mode, and there is an unchangeable pr mode. The vr mode and the pr mode establish a field-to-one mapping relationship through a field mapping relationship, and the user operates the upper layer vr mode by mapping the address layer. The layer resolves to the final concrete pr mode field, and the pr mode field establishes a solid one-to-one correspondence with the physical library table fields. Therefore, the upper vr mode field will eventually map to the specific physical library table field.

The main features of vr mode and pr mode are: they all include the two-layer concept of objectification and persistence. Objectization level: The MetaVr object model corresponding to the library table in vr mode is mainly composed of virtual library ID, virtual table ID, field attribute (json string of library table field pojo group), creation time, owner ID and other attributes. The pr mode corresponds to the MetaPr object model of the library table, and is mainly composed of a virtual library ID, a virtual table ID, a field attribute (a json string of a library table field pojo group), a creation time, an owner ID, and the like. Only the virtual surface layer has both the vr mode and the pr mode, and they establish a mapping relationship through specific field mapping. The virtual view layer only has the vr mode layer, and the layer-level association mapping is performed through the mapping relationship between the upper vr mode layer and the lower vr mode layer, and finally mapped to the virtual surface layer. Persistence level: The vr mode corresponds to a specific data record of the metavr table of the cloud database base library table. The pr mode corresponds to a specific data record of the metabase table of the cloud database base library table. The vr mode and the pr mode, the relationship between the upper vr mode and the lower vr mode are related by establishing a mapping relationship by representing a virtual table address, a field mapping value field value or a field value attribute value.

The invention realizes database virtualization, and the main steps are as follows:

The first step is to install a virtualized heterogeneous data integration service platform on each node and then configure other application server nodes in the current node's configuration file.

The second step is to deploy the initial environment required for system operation: 1) Import the system base library, which is the meta node database. 2) Register the virtual library account and activate it, and the system administrator approves it.

In the third step, the virtual library administrator logs in to the system, creates his own virtual database, registers the virtual table, creates a virtual view based on the virtual table, and then creates his own ordinary users and user roles. The virtual library administrator can use this function to create the virtual database n required by other applications. When creating a virtual database, you can register the virtual tables required by the virtual database or create virtual views. You also need to specify the storage location of the physical library tables mapped by these virtual tables. Each time a virtual database is created, at least one ordinary user is assigned to the virtual database. After the ordinary user logs in to the system, it can be used and operated (within the authority) The resources of the virtual database. Similarly, a virtual database m can be created on the service platform, and each virtual database number is globally unique, ensuring that multiple virtual databases can have a uniform global unique number.

The invention provides a database virtualization mechanism and method, which virtualizes the current mainstream relational databases to a unified platform, shielding the underlying physical differences, and on the basis of a high degree of abstraction, The multi-heterogeneous structure evolves into a logical, relatively simple and unified object-based model architecture. Each complex and diverse physical table structure is unified in the form of basic elements such as virtual libraries and virtual tables, and the library table and library table fields are unified and objectified. The multi-heterogeneous database of each application system is connected to the cloud database virtualization platform, and the user can customize a self-management and self-consumption data information service platform according to his own needs. It embodies the advantages of two aspects: 1) mode: users can design and create unified virtual table resources by themselves; 2) technically: the transformation of physical platform to logical platform, the server and port, data source and resource of a large number of physical existence on the network The cumbersome development and design process is hidden internally and enhances the level of application development.

Claims

A relational database table schema objectification and virtualization mechanism, characterized in that: the mechanism is composed of a virtual database, a virtual table, a virtual view, and a physical application server, a database server, a database, and a data table. Many-to-many mapping implementation;

The virtual database is a virtual space organized and managed in a network environment; there is a corresponding virtual table (virtual level virtual resource), a role that can allocate virtual table usage rights, a virtual library resource user, and a virtual database. Other entities such as views (virtual tables created based on virtual tables): and other network knowledge and activities derived from behavioral relationships within their lifecycle, the virtual database is a logical virtual network space with defined boundaries, as: 1) Specific network cohesive space composed of users, virtual resources, and roles; 2) interface between virtual space and network physical elements; operation of virtual database: creation, modification, and deletion; virtual resources can be moved or copied between virtual databases. Different virtual database administrators can share virtual resources;

The virtual table is an abstract concept representing a database server, a database, and a table at a logical level. It belongs to a specific virtual database, and has a relationship characteristic, having a schema and a constraint; implementing and specific through the pr mode and the vr mode. The physical table of the database forms a one-to-one correspondence; the virtual table satisfies the relational operation operator, and a new virtual table, that is, a virtual view, can be formed through operations such as connection and association, thereby forming an access and mapping relationship between the virtual tables having the hierarchical structure; Complex data models and connections that can be used to represent business needs; operations of virtual tables: create, delete, modify, and interface to read, write, change, and delete data;

The virtual view is a composite virtual table based on a virtual table, and is a logical view recombined based on a virtual table field. The virtual view also has a relationship characteristic, having a schema and a constraint; it can correspond to multiple virtual The table has no direct correspondence with the physical table, but is indirectly mapped to each database physical table field according to the virtual table field; that is, the upper level vr mode and the lower vr mode are used to implement the hierarchical mapping relationship; The library table data integration and the sql association operation realize the sharing and association operation of the data information without changing the physical attributes of the underlying databases;

Mapping: The mapping relationship reflects the operation mapping between the virtual database, the virtual table/view, and the physical application server, the database server, the database, and the data table (file); the operation of facing the virtual database and the virtual table at the logical layer is finally mapped to The operation of the corresponding one or more physical concept entities; this mapping is many-to-many, and can also be cross-constraint; the virtual table can establish a mapping relationship between the physical database and the table (including files), and the mapping relationship is non- One-to-one correspondence, a virtual table schema can be mapped to one or more database servers, databases, tables (files) on the network;

Each library table corresponds to a p-v object instance system, and the library table field corresponds to a pojo instance; thereby shielding the complex physical details and differences of the current software application system database.
The database table schema objectification and virtualization mechanism according to claim 1, wherein all heterogeneous relational library tables are controlled by a unified virtual table logical concept, that is, each library table is simply regarded as one. Pv object instance system, and persisted into a virtual table resource, the basic virtual table and the actual relational database table to establish a one-to-one mapping relationship, through the virtual view mode customization and virtual table data operations (additions and deletions, join, union, etc.) You can finally map to the corresponding operation of the underlying library table; in the case of shielding the underlying heterogeneous database differences, users can perform some operations across the library by building a view in the underlying virtual table.
The database table schema objectification and virtualization mechanism according to claim 1, wherein the main features of the vr mode and the pr mode are: they both include a two-layer concept of objectification and persistence; and an objectification level: a vr mode corresponding library The MetaVr object model of the table is mainly composed of a virtual library ID, a virtual table ID, a field attribute (a json string of a library table field pojo group), a creation time, an owner ID, and the like; a pr mode corresponds to a MetaPr object model of the library table, It is also mainly composed of virtual library ID, virtual table ID, field attribute (json string of library table field pojo group), creation time, owner ID and other attributes; only virtual surface layer has vr mode and pr mode at the same time, they pass specific The field mapping is used to establish the mapping relationship; the virtual view layer only has the vr mode layer, and the layer-level association mapping is performed through the mapping relationship between the upper vr mode layer and the lower vr mode layer, and finally mapped to the virtual surface layer; the persistence layer: the vr mode corresponds to the cloud database A specific data record of the metavr table of the base library table; the pr mode corresponds to a specific data record of the metapr table of the cloud database base library table; the vr mode and the pr mode, the relationship between the upper vr mode and the lower vr mode are represented by the virtual table Address, field mapping value field value or field value attribute value for association and mapping.
The database table schema objectification and virtualization mechanism according to claim 2, wherein the main features of the vr mode and the pr mode are: they both include a two-layer concept of objectification and persistence; and an objectification level: a vr mode corresponding library The MetaVr object model of the table is mainly composed of a virtual library ID, a virtual table ID, a field attribute (a json string of a library table field pojo group), a creation time, an owner ID, and the like; a pr mode corresponds to a MetaPr object model of the library table, It is also mainly composed of virtual library ID, virtual table ID, field attribute (json string of library table field pojo group), creation time, owner ID and other attributes; only virtual surface layer has vr mode and pr mode at the same time, they pass specific The field mapping is used to establish the mapping relationship; the virtual view layer only has the vr mode layer, and the layer-level association mapping is performed through the mapping relationship between the upper vr mode layer and the lower vr mode layer, and finally mapped to the virtual surface layer; the persistence layer: the vr mode corresponds to the cloud database a specific data record of the metafr table of the base library table; the pr mode corresponds to a specific data record of the metapr table of the cloud database base library table; vr mode pr mode, the upper vr mode to associate and establish mapping relationship with the relationship between the underlying models are vr virtual address table, field mapping value field value or attribute value through a representative.
The database table schema objectification and virtualization mechanism according to any one of claims 1 to 4, wherein in the mechanism, the main steps of virtualization are as follows:

The first step is to install a virtualized heterogeneous data integration service platform on each node, and then configure other application server nodes in the configuration file of the current node;

The second step is to deploy the initial environment required for system operation: 1) Import the system base library, which is the meta node database. 2) Register the virtual library account and activate it, and the system administrator approves it;

In the third step, the virtual library administrator logs in to the system, creates his own virtual database, registers the virtual table, creates a virtual view based on the virtual table, and then creates his own ordinary users and user roles. The virtual library administrator can use this function to create the virtual database n required by other applications. When creating a virtual database, you can register the virtual tables required by the virtual database or create virtual views. You also need to specify the storage location of the physical library tables mapped by these virtual tables. Each time a virtual database is created, at least one ordinary user is allocated to the virtual database. After the ordinary user logs in to the system, the resources of the virtual database can be used and operated (within the authority). Similarly, a virtual database m can be created on the service platform, and each virtual database number is globally unique, ensuring that multiple virtual databases can have a uniform global unique number;

In the fourth step, an application developed for any virtual database can use a virtual database label. The virtual table label (vdbid.vid) transparently accesses various resources through the access interface of the virtual table, wherein the program developer is not necessarily a virtual database. The user, while the program is running, will access the internal logic of the interface to determine whether the user has access to the virtual table/view based on the identity of the currently accessed user.