CN112084340A - Management method for organizational structure change version based on neo4j graph database - Google Patents
Management method for organizational structure change version based on neo4j graph database Download PDFInfo
- Publication number
- CN112084340A CN112084340A CN202010856833.3A CN202010856833A CN112084340A CN 112084340 A CN112084340 A CN 112084340A CN 202010856833 A CN202010856833 A CN 202010856833A CN 112084340 A CN112084340 A CN 112084340A
- Authority
- CN
- China
- Prior art keywords
- version
- attribute
- organization
- node
- nodes
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
Links
Images
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/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
- G06F16/367—Ontology
-
- 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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2246—Trees, e.g. B+trees
-
- 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/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/31—Indexing; Data structures therefor; Storage structures
- G06F16/316—Indexing structures
- G06F16/322—Trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/33—Querying
- G06F16/3331—Query processing
- G06F16/334—Query execution
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Software Systems (AREA)
- Life Sciences & Earth Sciences (AREA)
- Animal Behavior & Ethology (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a management method for an organizational structure change version based on a neo4j graph database. The method leads organization unit information in an organization structure needing to be managed into a neo4j graph database, each organization unit corresponds to a node in the neo4j graph database, the attribute of each organization unit is maintained through the attribute in the node, and the relationship of each organization unit is represented through the edge in the neo4j graph database. The invention analyzes the newly increasing, withdrawing, merging and splitting of organization units or departments in the organization structure management process respectively by utilizing the characteristics of high performance, high expandability and flexible design of the neo4j graph database, summarizes a set of effective management methods for the organization structure change version, and can conveniently check the information of each historical version in the organization structure change process.
Description
Technical Field
The invention relates to the field of application of a neo4j graph database, in particular to a method for managing organizational structure change versions based on a neo4j graph database.
Background
Many organizational structure relations in daily life are tree-shaped relations, for example, our country has 34 provinces and administrative divisions, there are many cities under each province, there are many counties and districts under each city, and many villages and towns are governed under each county (district); for example, the department of education belongs to many colleges and universities, and the colleges and universities include many colleges and departments, and many offices under each college. These organizations can be regarded as a tree-like relationship, and the organization is characterized by a huge number of organization units, and the organization units may have new addition, withdrawal, merging, splitting, etc. of units or departments due to some management requirement over time. Therefore, the management of the organization architecture information not only needs to flexibly deal with the requirement of organization evolution, but also needs to manage various historical versions in the evolution process of the organization units, and at the same time, the tree relationship of the whole or part of the organization units may need to be displayed to the user. Then managing such huge organizational structure data and complex relationships, the conventional relational database has not achieved the performance requirement.
The neo4j graph database is a non-relational database, and has the greatest advantages of supporting massive data and flexibly processing complex data relations. The method can well adapt to the changing business requirements. Therefore, the organizational structure change requirement can be well realized by modeling the organizational structure data and the relation through the neo4j graph database.
Disclosure of Invention
The invention aims to provide a management method for an organizational structure change version based on a neo4j graph database. The invention comprehensively analyzes the change rule and the requirement of the organization architecture, models the traditional organization architecture information by combining the characteristics of flexible design, high expandability and high performance of the neo4j graph database, and provides a set of perfect management method for the change version of the organization architecture aiming at the service requirement of the traditional organization architecture in the evolution process.
Analyzing the common organizational structure evolution process: mainly comprises the steps of adding, withdrawing, merging and splitting an organization unit or a department (hereinafter, referred to as a unit in a unified way). The new addition means that a subunit is newly added under a certain organization unit; cutting means cutting a certain organization unit; merging refers to merging a plurality of organization units into one organization unit or merging other organization units below a specified organization unit. Splitting refers to splitting a given organizational unit into multiple units.
The neo4j graph database needs to manage the organizational structure information, and first needs to import the organizational structure information and the relationship between each organizational unit into the database. The neo4j graph database stores data and relations by nodes and edges, each organizational unit in the organizational structure corresponds to one node in the neo4j graph database, the nodes with the same property are provided with the same label, and one node can possess a plurality of labels, and the labels are different for the organization unit playing different roles in different scenes. The attribute of each organization unit can be stored in the attribute of the node in the corresponding neo4j graph database, the membership between the organization units is represented by the edge in the neo4j graph database, if multiple relations exist between the two organization units, multiple edges are correspondingly arranged in the graph database, and each edge has respective label and attribute. For a small amount of organization structure information, the data relationship is imported by creating nodes and edges through cypher statements, but for a huge amount of organization structure information, the data relationship is imported in batches through LOADCSV, so that the data relationship is more convenient and efficient.
After the data is successfully imported, an initial version attribute is added to each node, and a naming rule with a continuously increasing value is set in the initial version attribute (essentially, the effect of managing the organizational structure version can be achieved by adding a label to the node, but the label is often used for distinguishing the node property, so the invention manages the organizational structure version by adding the attribute to the node), such as version1, version2 and version3. version means version, the number of the following numbers continuously increases, and the naming rule facilitates version statistics. The value of the attribute may be set to the current timestamp or other descriptive information. The continuously increasing number behind the version is called a version attribute change value, only one version attribute change value is added in one change operation, however, the nodes after combination and before combination need to be distinguished in combination, and the nodes after splitting and before splitting need to be distinguished in splitting, so that after combination or splitting, a new node can be found, and old nodes can be filtered. If two adjacent version attribute change values are set for the combined old and new sections, the change times of the organization structure are not favorably counted later. Therefore, we need to add a number or letter or other characters to the version attribute after changing the value, as long as the named attribute conforms to the attribute naming specification of neo4j graph database, for example, a merge operation can use version3 and version3Pre to distinguish nodes before and after merging. If "Pre" uses the first three letters of the previous word, version3Pre is the node that needs to be changed for the third time. version3 is the node version attribute after the third change. The advantage of this is that when we need to obtain how many times the organizational structure is changed or how many versions are currently available, we only need to search the maximum attribute change value behind the attribute of the current version, that is, the number of versions owned by the current organizational structure. The latest version is the node with the character string of 'Pre' after version and then the attribute node with the character of 'Pre' is filtered out.
If the initial version attribute of each node is set as version1, when an organization unit node needs to be added, a new attribute version2 needs to be added to the added node, and an edge relationship is established between the added node and a parent node of the added node, and when an organization architecture of a new version needs to be obtained, only nodes containing the attributes of version1 and version2 need to be searched through cypher statements. If the last organization structure information version data needs to be obtained, only the node with the version1 attribute needs to be screened out.
When an organization unit needs to be revoked in an organization architecture, a new version attribute with a value of a zone value is added to a corresponding node in a neo4j graph database, and if some unit nodes need to be revoked by taking the newly added new version as an example, a version attribute version3Pre is newly added to the unit node needing to be revoked, and other nodes and edges remain unchanged. Here, it should be noted that the node to be revoked needs to be filtered out in the new version, and the operation of revoking does not add a new node, so the revoking only needs to add the attribute with the distinguishing value in the new version attribute directly to the revoking node. If new organization structure information data needs to be acquired, only the nodes with the attributes of version1 and version2 need to be screened out, and then the nodes with the attribute of version3Pre are filtered out. If the organization architecture information data of the last version needs to be acquired, only the nodes with the attributes of version1 and version2 need to be screened out.
When some units need to be merged due to some management requirements in an organization structure, in the neo4j graph database, only new version attributes need to be added to the merged new node and the child nodes under the new node, and a distinguishing value is added to the nodes needing to be merged based on the newly added version attribute value. For example, when some nodes need to be merged, for example, taking the deleted latest version as an example, version attribute version4 is added to the new node and its child nodes to be merged, attribute version4Pre based on the new version attribute zone score is added to the node to be merged, and then the relationship of the edge between the new node and the child node is added. If the latest version of organization architecture information data needs to be acquired, only the nodes with the attributes of version1, version2 and version4 need to be screened out, and then the nodes with the attributes of version3Pre and version4Pre need to be screened out.
When a unit(s) needs to be split due to some management requirements in an organization structure, in the neo4j graph database, only new version attributes need to be added to a split new node and a child node under the new node, and a distinguishing value is added to the node and the child node which need to be split based on the added version attribute value. For example, taking the merged latest version as an example, when a certain node(s) needs to be split, version attribute version5 is added to the new node and its child nodes after splitting, a partition value is added to the node needing to be split based on the new version attribute, for example, set to version5Pre, and then the relationship of edges between the new node and the child nodes is added. If the latest version of organization architecture information data needs to be acquired, only the nodes with the attributes of version1, version2, version4 and version5 need to be screened out, and then the nodes with the attributes of version3Pre, version4Pre and version5Pre need to be filtered out.
The invention has the beneficial effects that:
neo4j graph databases are superior to relational databases in handling data relationships, and are aligned in three sets of experiments below. Relational database this experiment used the mysql database.
And 6 groups of organizational structure sample data are used for controlling the depth and the height of the organizational tree to be unchanged, the data volume is 100 in step length, when the data volume is increased from 100 to 600, a neo4j database and a mysql database are respectively used for query, in order to ensure the accuracy of query results, the average value is taken and recorded for three times of query execution each time, and the experimental results are shown in fig. 6.
The number of nodes of the fixed organization structure is 600, the height of the organization tree is controlled to be unchanged, the depth of the tree is changed, the tree structure is traversed by using a neo4j database and a mysql database respectively, and the experimental structure is shown in fig. 7.
The number of the nodes of the initial version organization structure is 600, the depth of the organization tree is 6, the maximum height of the organization tree is 50, the organization tree is sequentially subjected to operations of adding one node, deleting one node, combining two leaf nodes into one new node with the same father node and dividing a certain leaf node into two leaf nodes with the same father node, which is equivalent to the addition of four versions, data version query is respectively carried out by utilizing a neo4j database and a mysql database, and the obtained experimental result is shown in fig. 8.
Analysis of the above three results can result in that the neo4j graph database is more efficient in querying data relations relative to the mysql relational database.
Drawings
FIG. 1 is a diagram of data imported by an organizational unit or department according to the present invention;
FIG. 2 is a diagram of data after the organization unit or department is added, wherein (2) and (3) are diagrams of data after the organization unit or department is added;
FIG. 3 is a data diagram of the organization unit or department after evacuation, wherein (5) and (6) are data diagrams after evacuation;
FIG. 4 is a data diagram of the organization unit or department after merging, wherein (8) and (9) are data diagrams after merging;
FIG. 5 is a data diagram of the organization unit or department after being split, wherein (11) and (12) are the data diagrams after being split;
FIG. 6 is a graph showing the results of the experiment.
FIG. 7 is a graph showing the results of the experiment.
FIG. 8 is a graph showing the results of the experiment.
Detailed Description
The invention is further illustrated by the following figures and examples.
First, the organization unit information is imported into the neo4j graph database, and here, change management of the neo4j graph data based on the organization structure is mainly described, so that the imported data is not described in detail. Since the neo4j graph database has the capability of supporting massive data and efficiently searching complex relationships, a small amount of nodes are introduced to highlight the version management of the neo4j graph database on the change of the organization architecture.
For example, the imported data is shown in FIG. 1: A. b, C, d.. respectively, represent unit names in the organizational structure, with B, C, D three sub-units under the a unit, E one sub-unit under the B unit, F, G two sub-units under the C unit, and H one sub-unit under the D unit. And each node has a version1 attribute with the value set to the current timestamp. Version management of new addition, revocation, merging and splitting during the change of the organizational structure by the neo4j graph database will be discussed separately below.
(1) Newly adding organization units:
when a unit needs to be added to the existing organization structure newly according to a certain management requirement, the organization structure can be subdivided into two situations, wherein the first situation is to add a node below a leaf node of the existing organization node; the second is to add a new node under the non-leaf node. Taking fig. 2 as an example, it is now necessary to add an I node to the G node, or add an I node to the C node, which are respectively shown in (2) and (3) in fig. 2. Only new version attribute version2 needs to be added to the newly added node, and other nodes do not change, so that when the organization and architecture information of the current version needs to be acquired, the nodes with the attributes of version1 and version2 can be screened out in the neo4j graph database through cypher statements. If the last version of organization tree information needs to be obtained, all nodes with the version1 attribute need to be searched for the value.
(2) Organization unit withdrawal:
as shown in fig. 3, when it is necessary to tear down some units in the organizational tree due to a certain management requirement, there are two cases, if we are based on the newly added (3) in fig. 2 as the current version, the first is to tear down the unit without subordinate unit, and the corresponding deleted leaf node in the neo4j graph database, for example, the tear down G node shown in (5) in fig. 3; the second is to tear down the unit with subordinate units, and delete the corresponding intermediate node in the neo4j graph database, for example, (5) tear down the C node and its child nodes in fig. 3. The organization information version management for both cases is specifically analyzed below.
1) When the first type of evacuation condition is adopted, the node corresponding to the unit of evacuation is a leaf node, and is similar to the newly added leaf, only a new attribute version3Pre needs to be added to the node needing evacuation, and other nodes are not changed, so when new version organization information needs to be obtained, only the attribute nodes with the version1 and the version2 need to be screened out through cypher sentences, and then the nodes with the attribute of the version3Pre are filtered. If the organization information of the last version needs to be viewed, all the nodes with the attributes of the version1 and the version2 only need to be screened through cypher statements.
2) When the arbitration is the second case, the node corresponding to the arbitration unit is not a leaf node, so that a version3Pre attribute needs to be added to the arbitrated node and all child nodes thereof, and other nodes are not changed. Then when the latest version of organization information data needs to be acquired, only the nodes with the attributes of version1 and version2 need to be screened out through the cypher statement, and then the nodes with the attributes of version3Pre need to be filtered out. If the organization information of the last version needs to be viewed, all the nodes with the attributes of the version1 and the version2 only need to be screened through cypher statements.
(3) Merging of organization units:
as shown in fig. 4, when the merging of organization units is required due to a certain management requirement, which corresponds to the merging of nodes in the neo4j graph database, there are two cases, and we assume that we are based on (5) in fig. 3 after evacuation as the current version. The first is to merge the child nodes under the same father node, as shown in (8) in fig. 4, merge the C and D nodes under the a node into a new node J, then add a new version attribute version4 directly to the new J node and its child node F, I, H node, and add a version attribute version4Pre that is differentiated based on the newly added version attribute to the C and D nodes that need to be merged; the second is child node merging under different father nodes, for example, it is necessary to merge the node I under the node C and the node H under the node D in (7) in fig. 4 into a node K, and if the node K is under the node D, it is necessary to add a version attribute version4 to the newly added node K and its leaf nodes (since there is no leaf node in K, the leaf nodes are not newly added), and add an attribute version4Pre based on the new version attribute band score to the nodes I and H that need to be merged. When the latest version attribute needs to be acquired, the nodes with the attributes of version3Pre and version4Pre are only required to be queried through the cypher statement, and then the nodes with the attributes of version1, version2, version3 and version4 are filtered.
(4) Splitting an organization node:
as shown in fig. 5, when a certain organization unit needs to be split into a plurality of units due to a certain requirement, the corresponding neo4j graph database is split of unit corresponding nodes. At this time, two cases can be divided, and it is assumed that the merged data is based on the latest organization structure version as shown in (9) of fig. 4. The first is leaf node splitting without subordinate sub-units, for example, splitting a node K as shown in (11) in fig. 5 into two nodes L and M, then only adding a new version attribute version5 to L and M, and adding an attribute version5Pre that is differentiated based on the added version attribute to the node K that needs splitting. The second is that the split unit has subordinate sub-units, i.e. the split node has subordinate sub-nodes. As shown in (12) of fig. 5, the D node needs to be split into N, O two nodes, and the original child node of the D node needs to be the child node of the O node. Only new version attribute version5 needs to be added to the split N and O nodes and their child nodes K, and attribute version5Pre based on the new version attribute is added to the node D that needs to be split, so when the organization architecture information of the current latest version needs to be acquired, only the nodes with attributes of version1, version2, version3, version4, and version5 need to be screened out, and the nodes with attributes of version3Pre, version4Pre, and version5Pre are filtered out.
In short, when the organization architecture information of the specified version needs to be acquired, only the nodes having the specified version and the previous version attribute need to be screened out, and the nodes having the distinguishing value attribute of the specified version and the previous version thereof need to be filtered out. For example, it is necessary to obtain the organization structure information of the 4 th version, it is only necessary to obtain the nodes having the attributes of version1 to version4 and filter the nodes having the attributes of version2Pre to version4Pre (because the initial version1 does not have version1Pre, all the nodes do not need to be filtered, and if some versions have no corresponding distinguished value version, the node having the attribute is empty, and therefore the query result is not affected). When the change of the organization architecture needs to be checked, the maximum value after version in all the contacts is the number of the versions of the current organization architecture.
Claims (8)
1. A management method for organizational structure change version based on neo4j graph database, characterized in that the method comprises the following steps: the information of organizational units in organizational structure needing management is imported into a neo4j graph database, each organizational unit corresponds to a node in the neo4j graph database, the attribute of each organizational unit is maintained through the attribute in the node, and the relationship of each organizational unit is represented through the edge in the neo4j graph database.
2. The management method of the change version of organization structure based on neo4j database as claimed in claim 1, wherein each organization unit corresponds to a node in the neo4j database, and organization units of the same nature all have the same label, and nodes corresponding to different organization units may have different attributes; each node is provided with an initial version attribute, and the value of the version attribute is set as the current timestamp or the description information.
3. The method as claimed in claim 2, wherein each organization unit and the corresponding node establish a tree relationship by the direction of the edge, and the edges corresponding to the superior and inferior relationships with the same property have the same label, and different edges have different properties.
4. The method as claimed in claim 3, wherein when some organizational units need to be pruned, added, merged, or split due to management requirements, the new addition of nodes of an organizational tree and the new addition of new attributes of the associated nodes are created in the neo4j map database.
5. The method for managing a change version of an organization architecture based on a neo4j graph database according to claim 4, wherein if an organization unit needs to be added or removed, a new version attribute is directly added to a node corresponding to the organization unit needing to be added, and other nodes and edges are not changed; and adding a new version attribute with the zone value to the node corresponding to the organization unit needing to be cut back.
6. The method for managing organizational structure change versions based on the neo4j graph database according to claim 5, wherein if some organizational units need to be merged and split, only new version attributes need to be added to the merged or split new node and its child nodes in the neo4j graph database, the attribute value of the added version attribute is set as a timestamp or description information, and an attribute based on a distinguished value on the new version attribute is added to the node that needs to be merged or split, and the attribute value can be set as a timestamp or description information.
7. The method as claimed in claim 6, wherein when the organization tree data of the current latest version is required to be obtained, all the nodes are searched out and the nodes having the attribute of the distinguishing value are filtered out; when the organization structure data of the designated version needs to be acquired, the attribute of the designated version only needs to be found out, and the attribute of the designated version and the attribute node of the designated version with the distinguishing value are filtered out.
8. The method for managing a change version of an organization structure based on a neo4j graph database as claimed in claims 1 to 6, wherein only one version attribute change value is added for one change operation, however, merging needs to distinguish nodes after merging and before merging, and splitting needs to distinguish nodes after splitting and before splitting, so that after merging or splitting, new nodes can be found and old nodes can be filtered; thus, a distinction is made by adding a number or letter or other character to the version attribute after the value is changed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010856833.3A CN112084340A (en) | 2020-08-24 | 2020-08-24 | Management method for organizational structure change version based on neo4j graph database |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010856833.3A CN112084340A (en) | 2020-08-24 | 2020-08-24 | Management method for organizational structure change version based on neo4j graph database |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112084340A true CN112084340A (en) | 2020-12-15 |
Family
ID=73727959
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010856833.3A Withdrawn CN112084340A (en) | 2020-08-24 | 2020-08-24 | Management method for organizational structure change version based on neo4j graph database |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112084340A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112764719A (en) * | 2021-01-13 | 2021-05-07 | 平安普惠企业管理有限公司 | Configuration updating method, device, equipment and storage medium for organization architecture information |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160260063A1 (en) * | 2015-03-03 | 2016-09-08 | Adp, Llc | Dynamic nodes for managing organization structure |
| CN107545019A (en) * | 2017-03-02 | 2018-01-05 | 微云数聚（北京）科技有限公司 | A kind of method for visualizing and system of chart database data-driven |
| CN108509614A (en) * | 2018-04-03 | 2018-09-07 | 中山大学 | A kind of task record management and analysis method based on chart database |
| US20180268342A1 (en) * | 2017-03-15 | 2018-09-20 | Malcolm Edward Duncan | Competency Management System |
| CN110414771A (en) * | 2019-06-04 | 2019-11-05 | 腾讯科技（深圳）有限公司 | Update method, device, server and the client of enterprise organization structure data |
| CN110851663A (en) * | 2019-11-05 | 2020-02-28 | 北京明略软件***有限公司 | Method and apparatus for managing metadata |
-
2020
- 2020-08-24 CN CN202010856833.3A patent/CN112084340A/en not_active Withdrawn
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160260063A1 (en) * | 2015-03-03 | 2016-09-08 | Adp, Llc | Dynamic nodes for managing organization structure |
| CN107545019A (en) * | 2017-03-02 | 2018-01-05 | 微云数聚（北京）科技有限公司 | A kind of method for visualizing and system of chart database data-driven |
| US20180268342A1 (en) * | 2017-03-15 | 2018-09-20 | Malcolm Edward Duncan | Competency Management System |
| CN108509614A (en) * | 2018-04-03 | 2018-09-07 | 中山大学 | A kind of task record management and analysis method based on chart database |
| CN110414771A (en) * | 2019-06-04 | 2019-11-05 | 腾讯科技（深圳）有限公司 | Update method, device, server and the client of enterprise organization structure data |
| CN110851663A (en) * | 2019-11-05 | 2020-02-28 | 北京明略软件***有限公司 | Method and apparatus for managing metadata |
Non-Patent Citations (1)
| Title |
|---|
| 靳永超等: "基于Neo4j处理大数据中元数据溯源的研究", 《现代计算机(专业版)》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112764719A (en) * | 2021-01-13 | 2021-05-07 | 平安普惠企业管理有限公司 | Configuration updating method, device, equipment and storage medium for organization architecture information |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7930322B2 (en) | Text based schema discovery and information extraction | |
| Karnitis et al. | Migration of relational database to document-oriented database: structure denormalization and data transformation | |
| CN102467521B (en) | Easily-extensible multi-level classification search method and system | |
| CN101840400B (en) | Multilevel classification retrieval method and system | |
| CN110618983A (en) | JSON document structure-based industrial big data multidimensional analysis and visualization method | |
| US20080270381A1 (en) | Enterprise-Wide Information Management System for Enhancing Search Queries to Improve Search Result Quality | |
| TW200842630A (en) | A method of data storage and management | |
| US10445370B2 (en) | Compound indexes for graph databases | |
| CN110795526B (en) | Mathematical formula index creating method and system for retrieval system | |
| Kricke et al. | Graph data transformations in Gradoop | |
| CN105095436A (en) | Automatic modeling method for data of data sources | |
| CN112270628A (en) | Intellectual property theme library management method and system | |
| CN113190645A (en) | Index structure establishing method, device, equipment and storage medium | |
| CN112084340A (en) | Management method for organizational structure change version based on neo4j graph database | |
| CN108985567B (en) | Method and system for dynamically generating index analysis label based on user-defined index label | |
| CN112800143A (en) | Structure of data object and method for dynamically managing data object | |
| CN111125045B (en) | Lightweight ETL processing platform | |
| Batini et al. | A survey of data quality issues in cooperative information systems | |
| KR101846347B1 (en) | Method and apparatus for managing massive documents | |
| CN109902148A (en) | A kind of method of the enterprise name auto-complete of address book contact | |
| CN116303641A (en) | Laboratory report management method supporting multi-data source visual configuration | |
| CN115309789A (en) | Method for generating associated data graph in real time based on intelligent dynamic business object | |
| CN111881323B (en) | Table separation method based on sequencing field and time routing | |
| WO2014114761A1 (en) | Data management system | |
| CN113742498A (en) | Method for constructing and updating knowledge graph |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20201215 |