[go: up one dir, main page]

WO2018156043A1 - Système de commande de données maîtres sur des actifs - Google Patents

Système de commande de données maîtres sur des actifs Download PDF

Info

Publication number
WO2018156043A1
WO2018156043A1 PCT/RU2017/000096 RU2017000096W WO2018156043A1 WO 2018156043 A1 WO2018156043 A1 WO 2018156043A1 RU 2017000096 W RU2017000096 W RU 2017000096W WO 2018156043 A1 WO2018156043 A1 WO 2018156043A1
Authority
WO
WIPO (PCT)
Prior art keywords
master data
asset
assets
data
node
Prior art date
Application number
PCT/RU2017/000096
Other languages
English (en)
Russian (ru)
Inventor
Андрей Валентинович СУХОБОКОВ
Артем Андреевич СУХОБОКОВ
Андрей Львович МИХАЙЛОВ
Виктория Игоревна СТРОГОНОВА
Original Assignee
Общество С Ограниченной Ответственностью "Оптимальное Управление"
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 Общество С Ограниченной Ответственностью "Оптимальное Управление" filed Critical Общество С Ограниченной Ответственностью "Оптимальное Управление"
Priority to PCT/RU2017/000096 priority Critical patent/WO2018156043A1/fr
Priority to RU2018130478A priority patent/RU2748741C2/ru
Publication of WO2018156043A1 publication Critical patent/WO2018156043A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management

Definitions

  • the claimed technical solution relates to the field of computer technology used to create and support a single consistent representation of asset master data, which eliminates duplication of asset master data in various modules of the corporate system and individual applications. Elimination of duplication eliminates the inevitable contradictions arising from the simultaneous use of several different representations of the asset master data. In addition to improving the quality of data, this reduces the cost of maintaining the current state of asset master data.
  • master data refers to consistent data describing the main entities involved in the business processes of the enterprise. Master data is available and used by several enterprise-wide applications. The main characteristic features of master data are [1, 2.
  • MDM systems master data management systems
  • the purpose of the use of MDM systems is the formation and support of a consistent, functionally complete and relevant presentation of the main data, reflecting all the nuances of the structure and activities of the enterprise.
  • the presence and support of such a single meaningful presentation of master data is a critical factor for achieving the business goals of the enterprise.
  • MDM systems are tools for supporting enterprise-wide master data management processes based on accepted guidance documents, policies, and standards [7–9]. From the point of view of software products belonging to application or platform software, MDM systems are part of the platform and are an integral part of the complex of enterprise information management systems (Enterprise Information Management) [10].
  • MDM systems began to develop as single-domain systems designed to work with master data of a single category (subject area).
  • the most common data domains are:
  • Multi-domain systems are designed to work with data from several subject areas. They must be able to support all the master data domains that the organization needs.
  • multi-vector MDM systems extends the concept of multi-domain MDM systems. These systems provide an integrated set of tools for ensuring unity, accuracy, strategic management, semantic consistency and accounting for the official total assets of the enterprise master data.
  • the multi-vector MDM system features include comprehensive tools for data modeling, data quality support, data management, data organization, data transfer service and integration of data into the workflow and transactional usage scenarios.
  • Multivector MDM systems also offer higher levels of scalability, availability, manageability and security. In addition to working with different subject areas, multivector MDM systems must be able to work in different industries and different state. authorities, for different use cases (for designing data structures, as an operating or analytical MDM system), for different organizational structures (centralized, federated, localized) and for different scenarios for implementing an MDM system (register, consolidation, in coexistence mode and centralized) [1 1].
  • Hierarchy management is the ability of an MDM system to model and store multiple hierarchies as inside separate domains master data, as well as traversing covered domains, in order to comprehensively classify all the master data entities for various business requirements, as well as for wide functions such as search and reporting.
  • This ability should include support for multiple related or autonomous hierarchies belonging to the same domain or a combination of master data from multiple data domains.
  • bit-temporal modeling should be supported when the same data is displayed in two hierarchies: “as it should be according to documents” and “as it is in fact”. For example, this can be used to form a hierarchy of architectural representation and a hierarchy of commercial use of real estate as part of real estate master data.
  • the MDM system must provide support for balanced, unbalanced and recursive hierarchies, the ability to visualize to facilitate support and presentation of hierarchical data, and the ability to manage hierarchy versions so that you can use the audit log and restore data in the process of creating and maintaining hierarchies.
  • Internal integration of a product complex is the ability of an MDM system to provide, by default, integration between master data presented inside domains, regardless of whether they are stored together or separately from the point of view of, for example, data storage objects, as well as the ability to visualize and spawn this integration. This can be achieved using one product or several products as part of a complex or portfolio of products, as well as through the use of data created by customers or pre-packaged data models (or both modeling styles at the same time). However, if this ability is realized, then support must be provided for both different styles of implementation of the MDM system for each individual master data domain in time and simultaneously for multiple data domains, as well as pre-planned options for migrating domain implementation methods between implementation styles.
  • asset allocation In different application areas where work with assets is carried out, various principles of asset allocation are applied. For example, for accounting purposes, several adjacent units of equipment that have the same depreciation calculation rules can be combined into one fixed asset. For the purposes of repair and maintenance, objects are allocated that have a different order of repair and maintenance. For the purposes of property accounting, objects are distinguished that can be independently sold or leased, for example, one fiber in a bundle of optical fibers or fiber optic cable.
  • many fixed assets can correspond to one fixed asset. But the reverse is also true: many fixed assets can correspond to one object of technical accounting, for example, asphalt road, if its separate sections, which are not technical accounting units, were built (bought) at different prices or at different times.
  • the proposed system architecture consists of a system core, a set of interface modules, and a set of high-level algorithmic modules.
  • the kernel of the system supports the creation / modification and storage in memory of a master asset data model constructed in the form of a set of hierarchically organized views (subject areas) of assets.
  • Interface modules provide unloading from the model and loading into the data model of a separate view the asset master data at the request of some application working with this view of master data.
  • the dialog interface module provides dialogue support for creating and updating master data by the master data administrator.
  • High-level algorithmic modules provide checking the correctness of the completeness of the system of relations between objects in the model, checking the correctness of classifiers, searching for objects by classifiers, generating new views of the master data based on the data of other angles available in the system or based on external data, generating reports on the model data and on the adjustments made in it, as well as other similar operations.
  • the various subject areas are represented by their specific hierarchies of objects. Each subject area has its own system of classes of objects. Classes of objects are built on the principles of polymorphism and inheritance and determine the properties (set of attributes) of an object.
  • the objects present in different hierarchies are combined by linking grids to transition from one representation of the object to another.
  • Structural and functional asset models are used to identify the assets represented in the system.
  • Each structural asset model describes the internal relationships and component composition of specific asset classes.
  • Functional models allow you to check the completeness of the input of asset data or to identify the type of asset depending on the values of the attributes.
  • the link structure will be complete if there are all the necessary links for the transition between different representations of the same asset.
  • the validation of all links has a very simple meaning: from each object, go through the ring of links in one direction, and then in the opposite direction. If for all objects when passing in both directions we return to the original object, then all the links in the selected ring are correct. In order to check the correctness of all relations of one object, it is necessary to bypass all available connection rings in this way.
  • FIG. 1 illustrates an example of the structure of asset master data in existing large company management systems.
  • FIG. 2 illustrates the architecture of an asset master data management system.
  • FIG. 3 illustrates an example of hierarchical construction of an object view.
  • FIG. 4 illustrates an example of a lattice of bonds connecting the same asset from different angles.
  • FIG. 5 illustrates an example of non-hierarchical relationships between objects of the same perspective.
  • FIG. 6 illustrates an algorithm for checking the completeness and correctness of inter-aspect relationships in an asset master data model.
  • FIG. 7 illustrates the use of the stack to traverse objects of the same angle.
  • FIG. 8 illustrates the use of a stack to traverse all rings of a single lattice.
  • FIG. 9 illustrates an example of the grill previously shown in FIG. 3, in which instead of the semantic names of hierarchies their internal numbers are used, assigned to them at the time of their appearance in the data model
  • FIG. 10 illustrates an example of the renumbering of lattice objects.
  • FIG. 11 contains examples of two correctly constructed lattice rings.
  • FIG. 12 contains examples of two incorrectly constructed bond rings in a lattice.
  • FIG. 13 illustrates an algorithm for verifying the correctness of inter-aspect relationships in an asset master data model.
  • FIG. 14 illustrates an algorithm for checking the completeness of inter-aspect relationships in an asset master data model.
  • FIG. 15 illustrates a general diagram of a device that implements the claimed method.
  • FIG. 2. A system architecture including all of the listed components is shown in FIG. 2. and contains:
  • a dialog interface module that provides the creation and adjustment of master data by the administrator in a dialogue mode.
  • the asset master data model includes at least three views corresponding to some view of an existing asset park. Examples of such perspectives include:
  • Each view is organized as a unique hierarchy that displays the ownership of the asset master data (objects in
  • the view of objects for maintenance and repair of equipment is organized in the form of a hierarchy, the top level of which is the MRO objects.
  • the next level there are as many nodes as there are in the company of factories.
  • the next lower level is represented by nodes, each of which corresponds to
  • An even lower level corresponds to the places of installation of equipment in the framework of specific production and technological complexes.
  • the lowest level of the hierarchy corresponds to units of equipment mounted at specific equipment installation locations.
  • An example of a hierarchy of objects of maintenance and repair described in FIG. 3. The given example of a hierarchically constructed perspective is extremely simplified. The complexity of the organizational structure of large companies and the technical complexity of modern equipment are such that real hierarchical structures for presenting master data on assets a particular company can contain any finite number of hierarchy levels.
  • the generic classifier is a hierarchical system of classes built on the basis of the principles of inheritance and encapsulation.
  • the initial objects of class hierarchies are the main classes of the generic model, which at the next hierarchy levels are detailed into groups of types of assets according to their functionality, design features, methods of use, etc. For example:
  • the number of levels of the class hierarchy in the classifier is not limited.
  • Each main and non-main asset class an asset class defines a certain set of attributes (characteristics) of assets of this class. Attributes have names and values. Attribute values can have a wide range of types: integer, real number, logical sign, text, directory value, array, set, dependency, graph, table, diagram, drawing, image, document, etc. Examples of attributes for the laptop class of assets ”Will be: processor type, processor frequency, screen size, RAM size, hard drive capacity, etc.
  • the number of attributes of each class is not limited. If there are a large number of attributes belonging to any of the classes, for convenience, they can be structured into functional groups, while the same attribute can be included in different functional groups. Using the principles of inheritance and encapsulation in constructing classifiers provides the following rules for transferring attributes between hierarchy classes:
  • Attributes of a higher hierarchy class are inherited in all hierarchy classes subordinate to it.
  • Attributes with the same name can be used to describe the same asset, presented from different angles. However the values these attributes may not match.
  • Each class has three required attributes:
  • Lattices are not necessarily complete (that is, they do not necessarily contain all the relationships of each object with each). The presence of connections between 5 different objects depends on the semantics - it is necessary to establish relations between objects of these angles at a given level or not.
  • the gratings at different levels will not necessarily be absolutely parallel.
  • one object can correspond to several objects of another view, located at different levels of the hierarchy, and, then, the lattices of adjacent levels can be connected in separate views.
  • the asset master data model may contain a set of non-hierarchical (network) relationships between assets belonging to this view. These relationships display perspective-specific relationships between assets, such as participation in production chains or transport relationships.
  • An example of non-hierarchical connections between assets belonging to this view may contain a set of non-hierarchical (network) relationships between assets belonging to this view.
  • classes in the relationship classifier have attributes that have names and values. Attribute values can have a wide range of types: integer, real number, logical sign, text, directory value, array, set, dependency, graph, table, diagram, drawing, image, document, etc.
  • Examples of attributes for the transport class route will be: the maximum volume of cargo transported by one vehicle, the capacity of the transport route, the cost of transporting a consignment of cargo by one vehicle, the time of transportation of one consignment of cargo, etc.
  • the number of attributes for each class of relationships is not limited.
  • Each link class has two required attributes:
  • non-hierarchical relationships have another important property: they can be parametric, that is, they can exist between objects in a shaded state and appear only when the values of one or more attributes of the object correspond to certain conditions.
  • the master data model may contain a set of structural asset models specific to that view.
  • Each structural asset model describes the internal relationships and component composition of a particular asset class.
  • a structural model of an asset that belongs to the Boiler Room class includes the required components: a building, a boiler installed in it, and a chimney. Structural models make it possible to verify the completeness of data entry about an asset or to identify the type of asset depending on its structure.
  • an error message is displayed to the user. It can be checked not only the component composition, but also the presence of relations of certain types between components, as well as their topology, if the connections are defined in the structural model. For example, when checking an asset of the “Ring Highway” class, certain sections of this road should be so connected by links to each other that a closed ring is formed. If the sections are open somewhere, then the asset does not correspond to the class “Ring Highway”.
  • the master data model may contain a set of functional models of asset master data specific to this view, which use the values of the attributes of individual assets and / or the attributes of the relationships of this asset and the attributes of the assets that are associated with the data during their execution.
  • Functional models allow you to check the completeness of the input of asset data or to identify the type of asset depending on the values of the attributes.
  • Functional models can be built both on the basis of relatively simple algorithms, and on the basis of complex mathematical models. As an example of a simple algorithm, we give an example of a functional model that verifies the correctness of the input of an asset of the class "Kindergarten Building".
  • a building's attribute has a value of more than two for such a building, then either the asset data is entered incorrectly or the asset is incorrectly classified.
  • a complex functional model of an asset let us give a model that calculates the population of animals in the future by years in a certain natural territory depending on the number of animals living in this territory at the moment. If the simulation shows that after shooting a certain minimum number of individuals, the animal population is likely to start If this area is to be reduced, then the territory cannot be assigned the class of assets “Hunting lands”.
  • Each interface component of the system unloads, upon requests from an external application or 5 ERP modules, the requested fragment of master data about assets related to a particular view of master data with which the requesting external application works.
  • the formats of the uploaded data must fully comply with the data formats that can be downloaded by a specific ERP module or application. Examples of modules and applications with which integration with individual interface modules should be ensured include:
  • RM - a module for managing technical repair and maintenance of equipment as part of SAP ERP
  • Each interface module that can be part of the system can upload not only master data on specific assets to the external application (ERP system module), but also hierarchies, classifiers,
  • Each interface module that is part of the system can not only upload master data on assets (data on specific assets, hierarchies, classifiers, non-hierarchical relationships, structural and functional models related to objects of this view, as well as existing relationships with objects from other angles) to an external application (module of the ERP system), but also by an administrator command received through a dialog interface module, load these objects into a specially designed memory area from an external application (ERP system module) with which this module provides an interface.
  • ERP system module an external application
  • the dialog interface module enables the administrator to create and adjust master data on assets in the dialogue mode, providing the ability to create, modify and delete hierarchies, classifiers, cross-relationship relationships, non-hierarchical relationships, non-hierarchical relationship classifiers, structural and functional models, create, change and delete attributes, assign and change their values, modify the classifier of units of measure and the classifier of file types.
  • the dialog interface module in addition to creating, adjusting, and deleting master data in the dialog mode, can work with master data loaded from the interface modules from outside, make corrections to these data, and make additional connections. After viewing this data and making the necessary adjustments using the dialog interface module, the master data administrator can give the command to transfer this data to the main asset data model with the replacement of the data previously available in the model.
  • the algorithmic modules included in the system provide verification of the correctness and completeness of the system of relationships between objects in the model, validation of classifiers, search for objects by classifiers, the formation of new views of the master data based on other angles available in the system or based on external data, reporting on the data model and on the adjustments made in it, as well as other similar operations.
  • the algorithmic modules have access to the elements necessary for their performance from individual views of the model or master data on assets as a whole.
  • the operation of the algorithmic modules is initiated by the master data manager through the dialog interface module. Examples of more detailed functions performed by algorithmic modules:
  • the Algorithmic module at the first step of its implementation (101) carries out the destruction (cleaning) of all data about the markup links
  • Nnew Nold + M - Noldl + 1 provided: Nold ⁇ Noldl,
  • Nnew is the new hierarchy number, Nold - standard internal hierarchy number,
  • Noldl the standard internal number of the hierarchy, which should receive a new number equal to 1,
  • M is the number of hierarchies in the model.
  • a report is generated on the basis of all generated messages based on all generated messages that indicates broken, missing or unintended connections, or that there are no inter-angle communication violations.
  • Both modules each contain their own specific part of the operations of algorithm (100). They have no operations not represented in algorithm (100).
  • the algorithmic module for checking the completeness of inter-aspect relationships can identify all missing relationships in full only when all the relationships in the data model are correct. This is achieved by the implementation of the algorithmic module for checking the correctness of inter-aspect relationships and the subsequent correction of identified errors in the relationships.
  • FIG. Figure 15 shows an example of a system (200) that is used to support a patented master data model, as well as to perform the functions of an asset master data management system, including operation of interface modules, an interactive module, and system algorithmic modules.
  • the system (200) includes the following components:
  • RAM Random access memory
  • the storage medium (203) in the external memory may be a hard disk drive (HDD), solid state drive
  • SSD solid state drive
  • NAN D-f lash flash memory
  • EEPROM Electrically erasable programmable read-only memory
  • SD flash memory
  • NAN D-f lash flash memory
  • EEPROM Electrically erasable programmable read-only memory
  • SD flash memory
  • NAN D-f lash flash memory
  • EEPROM Electrically erasable programmable read-only memory
  • SD flash memory
  • NAN D-f lash electrically erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Secure Digital etc.
  • CD compact disc
  • DVD Blu Ray
  • mini disk or a combination thereof.
  • I / O interfaces (205) are standard ports and devices for pairing devices and transmitting data, selected based on the required configuration of the system (200), in particular: USB (2.0, 3.0, USB-C, micro , mini), Ethernet, PCI, AGP, COM, LPT, PS / 2, SATA, FireWire, Lightning, etc.
  • ⁇ I / O facilities (206) are also selected from a well-known range of various devices, for example, a keyboard, touchpad, touch display, monitor, projector, mouse, joystick, trackball, light pen, stylus, sound output devices (speakers, headphones, built-in speakers, buzzer), etc.
  • ⁇ Data transmission tools (207) are selected from devices designed to implement the communication process between different devices via wired and / or wireless communication, in particular, such devices can be: GSM modem, Wi-Fi transceiver, Bluetooth or BLE module, GPS module , Glonass module, NFC, Ethernet module, etc. • System components (200) are interfaced via a common data bus (204).
  • system (200) is a server platform that provides the necessary calculations when implementing an asset master data management system.
  • this server platform should be equipped with tools that have the following features:
  • the toolkit must have the capabilities of a graph database [13]. This will provide significant advantages when working with graphs by increasing the speed of development and reducing the amount of code when traversing chains of links, compared to traditional SQL, and will also require less resources for the prototype to work.
  • the toolkit must have the capabilities of graph engines [14] that perform complex algorithms on a large graph as a whole, even if its fragments are stored on different servers that are part of the server cluster.
  • the Forrester Wave TM Master Data Management, Q1 2016 // Forrester / Goetz M., March 16, 2016, 17 p. 13. Robinson I., Webber J., Eifel E. Graph Databases. O'Reilly Media, 2-nd ed., 2015, 238 p.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne une structure de système comprenant un coeur de système, un ensemble de modules d'interface et un ensemble de modules algorithmiques de niveau élevé. Le coeur du système prend en charge la création/modification et la sauvegarde en mémoire d'un modèle de données maîtres sur des actifs, qui est structuré sous forme d'un ensemble de vues (domaines d'objets) d'actifs organisés hiérarchiquement. Les modules d'interface assurent l'extraction depuis le modèle et le chargement dans le modèle de données d'une vue distincte de données maîtres sur des actifs lors de demande d'une quelconque application fonctionnant avec cette vue de données maîtres. Un module d'interface de dialogue prend en charge le dialogue lors de la création et de la correction de données maîtres par un administrateur de données maîtres. Les modules algorithmiques de niveau élevé assurent une vérification de l'exactitude et de l'intégralité du système de liens entre des objets dans le modèle, la vérification de l'exactitude de classificateurs, la recherche d'objets selon des classificateurs, la génération de nouvelles vues de données maîtres sur la base de données existant dans le système sur d'autres vue ou sur la base de données externes, la génération de rapports concernant le modèle de données et les corrections qui y sont apportées, ainsi que d'autres opérations similaires. En ce qui concerne la présente architecture de système, la présente demande décrit un modèle de données utilisé pour la présentation de données maîtres concernant des actifs, ainsi que des modules algorithmiques pour vérifier l'intégralité et l'exactitude des liens inter-raccourcis dans ce modèle.
PCT/RU2017/000096 2017-02-27 2017-02-27 Système de commande de données maîtres sur des actifs WO2018156043A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/RU2017/000096 WO2018156043A1 (fr) 2017-02-27 2017-02-27 Système de commande de données maîtres sur des actifs
RU2018130478A RU2748741C2 (ru) 2017-02-27 2017-02-27 Система управления мастер-данными об активах

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2017/000096 WO2018156043A1 (fr) 2017-02-27 2017-02-27 Système de commande de données maîtres sur des actifs

Publications (1)

Publication Number Publication Date
WO2018156043A1 true WO2018156043A1 (fr) 2018-08-30

Family

ID=63253350

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2017/000096 WO2018156043A1 (fr) 2017-02-27 2017-02-27 Système de commande de données maîtres sur des actifs

Country Status (2)

Country Link
RU (1) RU2748741C2 (fr)
WO (1) WO2018156043A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116527696A (zh) * 2019-09-05 2023-08-01 创新先进技术有限公司 用于在区块链网络中删除节点的系统和方法
US12079240B2 (en) 2021-03-30 2024-09-03 Hcl Technologies Limited Method and system for managing items in warehouses through distributed ledger

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116010376B (zh) * 2022-12-30 2023-07-25 北京三维天地科技股份有限公司 一种基于继承策略的主数据建模方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185569B1 (en) * 1998-06-29 2001-02-06 Microsoft Corporation Linked data structure integrity verification system which verifies actual node information with expected node information stored in a table
US20050080757A1 (en) * 2003-10-08 2005-04-14 Dinesh Sharma Management of hierarchical reference data
US8150803B2 (en) * 2006-01-03 2012-04-03 Informatica Corporation Relationship data management
US20120303692A1 (en) * 2011-05-27 2012-11-29 International Business Machines Corporation Federation of master data management systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185569B1 (en) * 1998-06-29 2001-02-06 Microsoft Corporation Linked data structure integrity verification system which verifies actual node information with expected node information stored in a table
US20050080757A1 (en) * 2003-10-08 2005-04-14 Dinesh Sharma Management of hierarchical reference data
US8150803B2 (en) * 2006-01-03 2012-04-03 Informatica Corporation Relationship data management
US20120303692A1 (en) * 2011-05-27 2012-11-29 International Business Machines Corporation Federation of master data management systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Master Data Services для управления НСИ / Microsoft BUSINESS INTELLIGENCE", INTERNET ARCHIVE WAYBACK MACHINE, 25 July 2015 (2015-07-25), Retrieved from the Internet <URL:https://web.archive.org/web/20150725160507/https://microsoftbi.ru/basics/eim/mds> *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116527696A (zh) * 2019-09-05 2023-08-01 创新先进技术有限公司 用于在区块链网络中删除节点的系统和方法
US12079240B2 (en) 2021-03-30 2024-09-03 Hcl Technologies Limited Method and system for managing items in warehouses through distributed ledger

Also Published As

Publication number Publication date
RU2018130478A (ru) 2021-03-29
RU2748741C2 (ru) 2021-05-31
RU2018130478A3 (fr) 2021-03-29

Similar Documents

Publication Publication Date Title
US20220230131A1 (en) Hierarchical blockchain architecture for global trade management
US20240275790A1 (en) Descendent case role alias
US11222291B2 (en) Method and system for efficient and comprehensive product configuration and searching
US10430413B2 (en) Data information framework
US20160004741A1 (en) Method and apparatus for managing corporate data
KR100903726B1 (ko) 데이터 품질 관리 성숙도 평가 시스템
US12229199B2 (en) Case leaf nodes pointing to business objects or document types
CN103814374B (zh) 信息管理系统及方法
Nogués et al. Business intelligence tools for small companies
EP2610762A1 (fr) Système de gestion de version de base de données
KR102365292B1 (ko) 복잡한 엔지니어링 객체의 수명주기를 관리하는 방법 및 그 구현을 위한 시스템
US20140229223A1 (en) Integrated erp based planning
Jupp et al. BIM-FM and information requirements management: missing links in the AEC and FM interface
RU2748741C2 (ru) Система управления мастер-данными об активах
US20150363711A1 (en) Device for rapid operational visibility and analytics automation
US8291380B2 (en) Methods for configuring software package
Deckler et al. Mastering Microsoft Power BI
Masood-Al-Farooq SQL Server 2014 Development Essentials
KR100792322B1 (ko) 데이터베이스 품질관리 프레임워크
KR100796906B1 (ko) 데이터베이스 품질관리 방법
KR100796905B1 (ko) 데이터베이스 품질관리 시스템
Planting Developing a data repository for the Climate Adaptive City Enschede
Hsu et al. Modelling exchange with blockchain for the collaborative design of a building envelope in BIM
Pulidori Design and Implementation of an application Data Lake to support Repair Process in Baker Hughes
Ma How Does a CTO/CIO Control Digital Transformation?

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17897883

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 11.12.2019)

122 Ep: pct application non-entry in european phase

Ref document number: 17897883

Country of ref document: EP

Kind code of ref document: A1