CN100353313C - Collaborative Master Data Management - Google Patents

Abstract

Methods and apparatus, including computer program products, for sharing data. The technique includes receiving data in a central system from one or more client systems, performing a matching process on objects of data in the central system to determine if there are similar objects in the central system, mapping object identifications of similar objects to each other if there are similar objects in the central module, and providing the object mapping information to a process.

Description

Collaborative Master Data Management

Background technique

The present invention relates to data processing and data management systems.

An information technology ("IT") environment may consist of many different systems that perform processing, such as business processing, on common master data. Different systems may be part of the same entity or different entities such as vendors or contractors. Master data for processing may be stored in many different locations, systems, and/or in incompatible formats. A company's branch offices can work largely independently, selected companies can import new software solutions to a group of affiliated companies, and systems from different vendors can be linked. Different master data models can make it difficult to integrate business processes in these scenarios.

Master data can be captured and stored in different systems. Master data that is not unified throughout the IT environment can lead to data redundancy or incorrect information. For example, if two local branches of an international company both have the same local branch of a second international company as a business partner, each international business partner may be maintained twice, and in the two "Business Partner" master data objects There is no correlation between them. This can lead to high costs for multiple content maintenance for redundancy. Furthermore, business analysis with redundant or outdated information can lead to bad business decisions. In the above example, the company-wide analysis process may fail to detect the correlation between the "two" partners, and would lose the potential for identifying these business partners as international business partners of two local branches. business value.

Summary of invention

The present invention provides methods and apparatus, including computer program products, for sharing data.

In general, in one aspect of the invention, the invention provides methods and apparatus, including computer program products, for sharing data. This technique includes: receiving data from one or more client systems in a central system; performing a matching process on objects of the data in the central system to determine whether similar objects exist in the central system; If similar objects exist in the central module, the object identifications of the similar objects are mapped to each other; and object mapping information is provided to a process.

The invention can be implemented to include one or more of the following beneficial features. A request may be received from a client system to create the data object. A matching process may be performed on the data objects in the central system to determine whether the same (identical) data object or a similar data object exists in said central system, and if the same data object exists in the central system, then to the same Object IDs of objects are mapped to each other.

Data can be sanitized to standardize the content of the data. Providing the object mapping information to the process may include providing the object mapping information to a data warehouse for system-wide reporting. Analysis can be performed based on mapping information. It can be determined whether the same object is a duplicated object from the same client system, and the duplicated object can be removed from at least one of the central system and the client system from which the duplicated object was received.

Performing the matching process may include identifying attributes of the objects in the central system, and comparing the attributes of the objects to determine if the objects are identical. Object information may be stored in a central system, where the object information includes global attributes of objects and object mapping information for each object. Object information can be based on received data or created in a central system. Object mapping information can be used to publish objects to one or more client systems. Matching processing can be continuously performed on object information stored in the central system. Object information stored in the central system may be continuously updated based on data received from one or more client systems.

Continuously updating object information may include updating mapping information for each object. Objects can be created in the central system to include the object's global properties. Publishing objects may include publishing global attributes for each object, and techniques of the present disclosure may further include completing object information for at least one object in one of the one or more client systems.

Data objects can be mapped according to industry-specific standards. A framework for configuring client system software to receive data objects from said central system can be issued.

In general, in one aspect of the invention, the invention provides a system for sharing data. The system includes one or more client systems storing master data used in various processes performed in the client systems, and a central module configured to receive, in the central system, data from the Master data of one or more client systems, perform matching processing on master data in the central system to determine whether the same or similar objects exist in the central system, and if the same object exists in the central module, then the same The object IDs of the objects are mapped to each other, and if similar objects exist in the central module, the object IDs of the similar objects are mapped to each other, and the object mapping information is provided to one process.

The invention can be implemented to include one or more of the following beneficial features. The central module may also be configured to remove replicated objects from the one or more client systems, and/or provide object mapping information to a data repository for use in the processing. The system may also include a data repository configured to receive object mapping information for use in the processing.

The invention can be implemented to realize one or more of the following advantages. Collaborative master data management of master data allows for centralized management of master data. Mapping between identical and similar objects allows for improved cross-group reporting. Identifying duplicates avoids data redundancy. A collaborative master data management system enables consistent business processing by distributing master data and mapping information to all customers. Also, with cross-company reporting enabled, resources associated with maintenance of data can be reduced and master data can be located across systems and companies.

The details of one or more implementations of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will be apparent from the description, drawings and claims.

Brief description of the drawings

1A and 1B are block diagrams illustrating a collaborative master data management system.

Figure 2 is a block diagram illustrating a content consolidation implementation of a collaborative master data management system.

Figure 3 is a flowchart illustrating a method of merging data;

Figure 4 is a block diagram illustrating a master data conformity implementation of a collaborative master data management system.

5A and 5B are flowcharts illustrating a master data unification method.

Figure 6 is a block diagram illustrating a central master data management implementation of a collaborative master data management system.

Figure 7 is a flowchart illustrating a method for central master data management.

Fig. 8 is a block diagram illustrating a collaborative master data management module.

Similar reference numbers and symbol designations in different drawings indicate similar elements.

A detailed description

As shown in FIG. 1A , a collaborative master data management (“cMDM”) system includes a central module 100 and one or more client modules 110 . Each client module 110 is linked to the central module 100 .

The central module 100 may comprise a central system representing centralized control for data management of an entity, such as a business or an organization. Client module 110 may comprise a system or group for performing processing on master data. For example, client modules 110 may include systems and/or groups involved in the product creation process. In this example, client modules 110 may include a legacy module, an e-procurement module, an e-sales module, a sourcing module, a collaborative engineering module, a manufacturing module, and enterprise resource planning (" ERP") module.

Master data may be stored in the client module 110, in the central module 100, or both, depending on the implementation. The central module 100 enables master data used by each client 110 to include master data shared by all clients 110 . Traditionally, client modules 110 will communicate directly with each other in a point-to-point configuration. For example, in addition to sharing data with other modules, the manufacturing module may need to share master data with the e-procurement module, e-sales module, and collaborative engineering module. In conventional systems, manufacturing modules will receive data from or send data to the appropriate modules, which can lead to inconsistencies in the data or use of stale data if the data is not updated in the modules that send the data to share. In the system described with reference to FIGS. 1A and 1B , data is managed through a central module 100 . The central module 100 ensures consistent master data and distribution of master data.

As shown in FIG. 1B , a cMDM system may be implemented for use on multiple entities 120 , 130 . Central module 100 may be part of base entity 120 . The client module 110 may be part of the base entity 120 or part of the external entity 130 . For example, base entity 120 may include an enterprise that includes client modules 110 for ERP, traditional, e-procurement, and e-sales. Basic entities may be divided into units 140 , where each unit may include one or more clients 110 . External entities 130 may include contractors, including clients 110 for manufacturing, and providers, including clients 110 for collaborative engineering and sourcing.

In another example, primary entity 120 may include a customer service entity, while external entity 130 may include a business. Client information, which may typically be spread across multiple client modules 110 , may be consolidated by the central module 100 .

Centrally managed master data can be used for processing such as cross-group reporting, data integration for consolidation and procurement, reducing component diversity, supporting product maintenance, simplifying customer management and supporting catalogs, such as by merging catalog content and Bundle purchases to a smaller number of sellers. The cMDM system can also support versioning and change management. When a version is created or a change is made, the versioned data or changed data can be managed by the central module 100 as described below.

Before data is exchanged between the cMDM system and the client module 110, the setup of the cMDM system may be performed. Identifying attributes are specified for master data objects and rules for matching are established. The establishment of rules and attributes for matching can be performed for entities using cMDM, or for general object requirements. A matching process performed on the master data objects received from the client module can be used to manage the master data objects.

Specifying attributes may include matching different objects from different client applications or different client modules 110 . Specifying attributes can also include linking together elements of the matched structure so that master data objects received from different client systems can be compared.

The specified attributes may also be ranked during setup. Hierarchy of attributes can be used during the matching process to determine whether two master data objects are identical. That way, if there is a mismatch between two objects with a higher-ranked attribute, it is more likely that the two objects are not the same or similar than if a lower-ranked attribute in the list doesn't match.

As described with reference to Figures 2 to 7, a cMDM system can be implemented in at least 3 different scenarios. These scenarios can be implemented individually, or introduced in an evolutionary manner: starting with the content consolidation scenario and moving into the master data consistency scenario, or from the master data consistency scenario into the central data management scenario. Different scenarios can also be used together. For example, central master data management can be used for certain object types, while master data consistency is used for the remaining types. A mix of these scenarios is discussed in more detail below.

content merge

Figure 2 is a block diagram illustrating a content consolidation scenario for a cMDM system. The central module 100 may include a loading module 210 , a staging module 220 , a matching module 230 and an ID mapping module 240 . Merged content resulting from processes performed in the central module 100 may be used in processes 250, such as business analysis (eg, global spend analysis), or creation of a central catalog (eg, supplier product catalog).

At the load module 210 the master data object is received into the central module 100 . Master data objects are uploaded into the central module 100 in the form they are maintained in their local application (client module 110). At the staging module 220, the user at the central module 100 can determine whether the master data object was loaded correctly. For example, a user may verify the content of the master data object loaded in the loading module 210 to ensure that the content of the master data object is correct. In the staging module 220, the master data object may be sanitized to normalize the content of the master data object. For example, if the standard form for the abbreviation New York is "NY" and one of the master data objects entered has an abbreviation like "N.Y", by removing the period between "N" and "Y", the entered The content of the master data object can be changed to "NY". Data cleansing can also include removing errors and inconsistencies to make the data more accurate.

The staging module 220 may also be used as an intermediate repository for received master data objects for master data clients. The intermediate repository may be used when processing the matching and mapping routines described below with respect to matching module 230 and mapping module 240, respectively. The intermediate repository may also be used during a separate user interaction prior to uploading the master data objects.

Matching processing can also be done in the staging module 220 . The master data objects are forwarded to the matching module 230 . If the matching module 230 does not automatically match the master data object based on the identified attributes, the master data object may be returned to the staging module for manual determination of whether the master data object matches.

In the matching module 230, a matching process may be performed on the uploaded master data to identify identical or similar data objects. Identical data objects are primary data objects that are semantically identical and received from different client modules 110 . The same data object can have two different object IDs. A replicated data object is a semantically identical primary data object within the same system, eg, client module 110 . Possible duplicates are automatically identified and reported. One or more replicated data objects may be removed from the client system.

The matching process involves identifying similarities between master data objects. The matching process may include identifying attributes of the data objects, and comparing the attributes. Attributes that are compared may include attributes that are valid at the entity scope for the master data object type, so that identical and similar data objects can be identified, although the content of the attributes may vary from system to system. In this way, different data formats and structures can be maintained in different systems.

If the amount of matching between two master data objects is within a certain range, the result of the matching process may be considered pending. For example, if two primary data objects match 50-80%, the result of the matching process may be considered pending. For example, if a master data object to be matched is a business partner, and four out of five attributes match another business partner master data object, then the amount of matching will be 80%. In this way, the question of whether two objects match can be considered open. The master data object can be returned to the staging module for the user to manually determine whether the master data object matches another master data object.

The mapping module 240 receives the results of the matching process from the matching module 230 . At mapping module 240, similar or identical objects may be mapped to each other. For example, an object identification ("ID") of an object may be mapped to an object ID of a similar or identical object. The mapping information may be updated each time a change is made to the data object. The mapping can be performed automatically according to the rules established during the establishment of the master data management system. Mappings can be stored in a mapping table. Depending on changes made to the master data object, the mapping information can change. For example, if "N.Y" in master data object A is changed to "NY", the master data objects that were not mapped to master data object A can now be considered the same as master data object A, and are mapped to master data Object A's master data object will need to be changed. In this way, by mapping the information and making the mapping information available to the client module 110 to update the mapping information, changes can be managed. Similarly, when a new version of a set of data objects is defined, mapping information and updates to the mapping information can be used to manage the version.

The mapping information may be provided to the processing module 250 . Processing module 250 may include a data warehouse, such as a business information warehouse, for system-wide reporting. The processing performed in the processing module 250 may include generating central directories or company-wide analyzes and reports, such as global spend analysis or mergers and acquisitions.

FIG. 3 is a flowchart illustrating a method for merging data. Data is received from one or more client modules 110 to the central module 100 (step 310). If the content of the received data is not consistent with the content of the central system in the central module 100, the received data may be sanitized.

In the central system, a matching process is performed on the data objects to determine whether the same or similar objects exist in the central system (step 320). The matching process can include comparing identifying attributes of the objects. Matching can also include identifying copies. If two or more objects are found to be duplicated objects, input of one or more duplicated objects into the central module can be avoided. The replicated master data objects may be transferred to the staging module 220 where one of the replicated master data objects is removed from the central module 100 . The cMDM may also support removal of one or more replicated master data objects from the system from which the replicated master data objects were received.

If the same or similar objects are found, the central module can perform the mapping process (step 330). Object IDs of the same object can be mapped to each other, and object IDs of similar objects can be mapped to each other. Object mapping information may be provided to the process flow (step 340). As discussed above, providing mapping information to a process flow may include providing mapping information to a data warehouse, such as a business information warehouse, for use in system-wide analysis and reporting. Mapping information may also be provided to client module 110 .

Master Data Consistency

Figure 4 is a block diagram illustrating a second scenario of cMDM. The second scenario includes the implementation of master data conformity. This scenario can be implemented by adding the master data repository to the content merge implementation. This scenario can be used to enable maintenance and consistent distribution of global attributes of master data. The consistent content resulting from the processing performed in the central module 100 can be distributed to the client module 110 and the processing module 240 for use in, for example, business partner management, central provisioning of sales items, definition and management of non-variable components used in the application.

In the central module 100, the central generation module 410, or in the client module 110, master data objects may be generated. The master data objects generated in the client module 110 are received in the staging module 420 . Parts of master data objects and mappings between master data objects may be stored in the central module 100 . The stored portion of the master data object may include global attributes of the master data object.

The master data objects generated in the central generation module 410 may be generated to include only the global attributes of the master data objects. Global properties can include identification properties. Which attributes are maintained for each object type may depend on the information requirements and system shape. Frameworks can be added to cMDM to extend the object model without any modification to the software used to generate master data objects in the local system. Frameworks can handle new questions and new fields. For example, the object description (the data model of the object) can be adapted to the central instance. For example, a field can exist in one system's data model but not in another system's data model. The framework may also support updating user interfaces of client systems that receive master data objects with different attribute fields. After the object is distributed, as discussed below, in the client module 100, additional attribute values may be provided to the distributed object.

Locally created master data objects may be created using a native application of the client machine 110 . Client module 110 may distribute locally created master data objects to staging module 420 . Before the master data object is created in the client module 110, it can be searched across the system. If no similar master data object exists, it is created. If a similar master data object exists, the central module 100 makes the similar master data object available to the user at the client module 110 . For example, the central module 100 may make this similar master data object available to users at the client module 110 via a server. In this way, this similar master data object can be transferred to the server in the central module 100 and then transferred to the client system at the client module 110 .

Users can subscribe to this similar master data object, and the mapping information can be updated to include the new local system. After creating the data object, the created master data object can be transferred to another target system if no similar object is found.

A continuous matching process may be performed in the matching and mapping module 430 . For example, the mapping may be performed in response to a request to create a master data object in the central creation module 410 . A continuous matching process can be used to identify identical and similar data objects. Identical and similar data objects can be mapped to each other as described above.

The creation of duplicated objects identified by the matching process in the local system can be avoided. For example, if the local system requests a master data object for a new business partner, a user at the central module 100 can check to see if the business partner master data object already exists in the central module 100 . If the business partner master data object exists in the central module, the master data object can be distributed to client systems requesting the new master data object. If the user finds that an existing business partner master data object already exists in the target system, the creation of a replicated master data object is avoided. Mapping information may be provided to processing module 240 for processing such as enterprise-wide analysis.

The global attributes of the master data object, including mapping information, can be distributed to various client modules 110 through the distribution module 440 . In this way, after distribution, the same global properties are provided to all systems, and business processes can be handled safely. Objects that logically belong the same can be changed and distributed together. For example, when master data includes master data for a product, objects belonging to that product, such as product structures and documents, can be collected together in information packages and then, in a context, distributed to recipient client modules 110. A package may include a set of individual objects, such as those in a product structure, linked by relationships including dependencies. The information packets may be collected according to the information requirements of the recipient client module 110, and the information packets may be transferred in a certain order.

For example, if the BOM changes, or is to be distributed to the target system, rules associated with certain specified system mappings may indicate that the product master data for the material must be transferred to the specified system prior to the BOM in order for the specified system to A product ID that identifies the material. In this way, the ordering of the objects to be distributed can be made to conform to the semantics and requirements of the target system.

The client module 110 can complete the master data information for the received master data objects in the local environment. Changes to master data can also be managed centrally in the central module 100 . Changes can be received, approved, and then distributed to client modules 110 .

The master data created in the central module 100 may be created in response to a request from the client module 110 . For example, a business user using the client system at the client module 110 can fill out a new product master data request form and transmit the form to a user at the central system in the central module 100 . Forms can be checked to ensure they are filled out correctly. For example, tables can be checked semantically, or units of measure can be checked to ensure that the correct units are used. Users at the central system can see and receive requests. The user at the central system then checks for copies, completes the given information, and then creates and distributes new product master data.

5A and 5B are flowcharts illustrating a method for master data unification. Referring to FIGS. 1A , 1B , 4 and 5A , master data consistency may include: creating master data objects in the central module 100 and the client module 110 . (step 510)

In master data consistency, master data objects can be created in three ways. Master data objects can be created directly in the central module 100 , or new master data objects can be created in the central module 100 in response to a request from the client module 110 . Master data objects can also be created locally in the client machine 110 and transferred to the staging module 420 . Master data objects created locally in the client module 110 may be uploaded to the central module 100 .

The created objects may be stored in the central module 100 . The master data objects stored in the central module 100 may include global attributes of the master data objects.

On the stored master data objects, a continuous matching process can be performed. (Step 520) A continuous matching process may be used to identify duplicate, identical and similar data objects. Duplicate objects found can be removed, and the object IDs of identical and similar objects can be mapped.

Master data object information, including global attributes and mapping information of the master data object, may be distributed to client modules 110 (step 530). The master data information of the master data object received in the client system may be completed in the client module 110 . (step 540)

Figure 5B illustrates a method of master data reconciliation, where master data is created locally, as discussed above. Master data objects are created locally. (step 550). Master data objects created locally are staged. (step 560).

Central Master Data Management

Figure 6 is a block diagram illustrating a central master data management implementation of a cMDM system. In a central master data management scenario, master data is fully controlled in a central module. In this implementation, all master data information resides centrally in the central module 100 . This implementation can be used in applications such as a central product data pool that provides product data to multiple locations for production, assembly, sales and distribution.

In the central creation module 610, master data objects can be created. The created master data object may include complete object information including complete object definition, object mapping information and object dependencies. A master data object may be created in response to a request from the client module 110 . Matching processing may be performed in response to the request, and mapping information may be included in data object information stored in the central module 100 . If the same object exists in the central module 100, the requesting client module 110 may be notified that the same object exists, and a new master data object is not created or mapped to an existing object. Mapping information can be updated.

In the distribution module 620, centrally maintained master data information can be distributed as individual objects as they are defined in the client module 110. Objects can be distributed in packets. Objects belonging to the same can be changed or distributed together. If master data includes product model master data, belonging to the same objects, such as product, BOM (bills of material, BOM), and documents, are collected together in consistent information packages and distributed together. Objects may be collected according to information requirements of the recipient client module 110 . For example, objects can be collected with reference to a specific view of a product. Views can include product-related attributes, such as purchase dates. In this way, a group of objects can be linked based on usage or location. For example, a sales view may include content or properties of objects related to or used by a sales department.

As discussed above, these scenarios can be used together. For example, central master data management can be used for business partner master data objects, wherein all business partner master data object information is maintained in the central module 100 . The central module 100 may only store global attributes for the remaining data objects, for example product master data objects.

Figure 7 is a process diagram illustrating a method for central master data management. Central master data management processes can be performed in a homogeneous environment. Referring to FIG. 1A , FIG. 1B and FIG. 6 , at least one data object is created in the central module 100 (step 710 ). The central module 100 may comprise a central system for a cMDM system. The central module 100 can store complete data object information, which can be distributed to the client modules 110 . In this way, the created data object may include complete object information, including complete object definition, mapping information for mapping data objects to each other, and dependencies on other objects.

The data object may be created in response to receiving a request from the client module 110 to create a data object. A matching process may be performed for a request to determine whether a similar or identical data object exists in the central system. If a similar or identical data object is found, the same data object will be distributed to the requesting system, and the distributed object will be automatically mapped.

Data objects from the central system may be distributed to one or more client modules 110 (step 720). Distributing the data object may include distributing the data object to the client module 110 . Data objects can be distributed in the form of packets. The information package may be defined in the central module 100 according to the requirement information received from the recipient client module 110 .

The method of central master data management may also include performing changes to data objects, and updating the data objects stored in the central module 100 according to the received changes. The updated data objects may be distributed to client modules 110 .

master data management system

FIG. 8 is a block diagram showing a simplified structure of the central module 100 . The central module 100 may include an exchange infrastructure (exchange infrastructure, “XI”) 810, a content integrator (contentintegrator, “CI”) 820, and a master data server (master data server, “MDS”) 830. The XI 810 may be used to communicate between the client module 110 and the central module 100.

The master data to be distributed is received in the XI 810. Distribution can be performed in three different ways, including subscription-based distribution, historical distribution, and content-based distribution. A routing model (not shown) stores information about which systems are interested in master data. The master data is then sent from the XI 810 to the relevant system. Queuing may be used to ensure consistent message delivery through the XI 810. Messages can be sent between systems in XML (extensible markup language, XML) format.

By defining identification attributes for each object, CI 820 can correlate master data from different systems. Identification attributes are fed to the CI 820 from various systems in the client module 110 and scanned for similarities according to predefined rules. The CI 820 maintains object IDs for objects in the system shape, regardless of which system they belong to, or which data model they are governed by. The master data objects stored in the client module 110 retain the identities defined in the respective client systems storing the master data objects. The CI 820 knows that each instance refers to some other object in the system (using a mapping function). In this way, the CI 820 performs the matching process and preparation for the final ID mapping.

In one example, the mapping can be done using industry-specific standards. Different industries, such as chemical industry, Consumer Products ("CP")/retail, etc., define standards for how objects should be described for their needs. In one industry, for example, in CP, it may be sufficient to describe the product name, description and category (eg, "SWEETS"), whereas in the chemical industry category alone is not sufficient. In this way, attributes and their values are used to adequately describe the chemical industry. In this way, attributes can be like the language of the industry. Therefore, the mapping of the MDM standard xml format to industry-specific standards is supported. For example, industry-specific standards include CIDEX, Pidx, RosettaNet, Pricat.

CI 820 uses mapping as a double check process for creating objects. The central module 100 receives requests to create master data objects. CI 820 checks the request, looking for the same object. If no match is found, the central module generates a new object. CI 820 then performs a test on the new object. If no match is found, the central module stores a new master data object. In this way, even if the first check is incomplete according to the instructions provided by the client module 110, a match can be found when the object is fully created.

Merge strategies can be used to combine two or more objects that are found to be similar or identical. For example, if a master data object for a bump is generated in a purchase system, a sales system, and a creation system, one object can be created in the central module 100 by merging these three master data objects. For example, a new object may be created where different systems have authorization for different parts of the object. In this way, the purchasing system can maintain purchasing information for this master data object. Although the purchasing system can see the sales and production information, the purchasing system may only be given authorization to maintain the purchasing information.

MDS 830 may include a central data repository for storing data objects. The MDS 830 can perform object creation and change processing. MDS 830 can also provide services for change management, such as unified version control and status management. Grouping changed objects into packets for distribution is also performed in MDS 830.

The invention can be implemented in digital electronic circuitry or in computer hardware, firmware, software or a combination thereof. The present invention can be implemented as a computer program product, that is, a computer program tangibly recorded in an information carrier, such as a machine-readable storage device, or a computer program in a propagated signal, executed by a data processing device, or controlling a data processing device For the work, the data processing device is, for example, a programmable processor, a computer or multiple computers. A computer program can be written in any form of programming language, including assembly and interpreted languages, and it can be organized in any form, including as a stand-alone program or as a module, component, subroutine or other suitable for use in a computing environment unit. A computer program can be scheduled to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites, interconnected by a communication network.

Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. The method steps can also be performed by a special purpose logic circuit, the logic circuit is for example FPGA (field programmable gate array, field programmable gate array, FPGA) or ASIC (application-specific integrated circuit, application-specific integrated circuit, ASIC), and the present invention Means may be implemented as these circuits.

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively connected to receive data from, transfer data to, or both, one or more mass storage devices for storing data, mass storage Devices are, for example: magnetic disks, magneto-optical disks or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory including, by way of example, semiconductor memory devices such as EPROM, EEPROM and flash memory devices, magnetic disks such as built-in hard disks and removable disks, Magneto-optical disks and CD-ROM and DVD-ROM disks. The processor and memory can be supplemented by, or included in, special purpose logic circuitry.

In order to provide interaction with the user, the present invention may be implemented on a computer having a display device and a keyboard and a pointing device, such as a CRT (Cathode Ray Tube, CRT) or LCD (Liquid Crystal Display, LCD) monitor for Information is displayed to the user. A pointing device (pointing device) is, for example, a mouse or a trackball. The user can provide input to the computer by using the pointing device. Other types of devices can also be used to provide interaction with the user. For example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback or tactile feedback, and the input from the user can be used as Receive in any form, including sound, speech, or tactile input.

The present invention may be implemented in a computing system including back-end components such as data servers and intermediate components such as application A server, a front-end component such as a client computer with a graphical user interface, or a web browser through which a user can interact with an implementation of the present invention. The system components can be interconnected by any form or medium of digital data communication, such as a communication network. Examples of communication networks include: local area network ("LAN"), wide area network ("WAN"), and the Internet (Internet).

A computing system can include clients and servers. A client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server occurs by virtue of computer programs running on their respective computers and having a client-server relationship to each other.

The invention has been described using specific embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results.

Claims (19)

1. the method for a shared data comprises:

In center system, receive data from one or more client machine systems;

Object to the data in the described center system is carried out matching treatment, to determine whether there is similar object in the described center system;

If there is similar object in the described central module, then the object identity to similar object carries out mutual mapping; And

Provide object map information to a processing.

2. method according to claim 1 also comprises:

Object to the data in the described center system is carried out matching treatment, to determine whether there is identical object in the described center system; And

If there is identical object in central module, then the object identity to identical object carries out mutual mapping.

3. method according to claim 1 also comprises:

Data are purified, with the content of standardized data.

4. method according to claim 1 wherein, provides object map information to comprise to processing: provide described object map information to a data warehouse, to carry out the report in the system scope.

5. method according to claim 1 also comprises:

Analyze according to map information.

6. method according to claim 1 also comprises:

Determine that whether identical object is the object that duplicates from same client machine system; And

Remove the object that duplicates in from received center system of the described object that duplicates and client machine system at least one.

7. method according to claim 1, wherein, carry out matching treatment and comprise: discern the attribute of the object in the described center system, and the attribute of comparison other, to determine whether object is identical.

8. method according to claim 1 also comprises:

Object information is stored in the described center system, and this object information comprises the global property of object and the object map information of each object, and object information is based on the data that received, or create in center system; And

Utilize object map information that object is published to one or more client machine systems.

9. method according to claim 8 also comprises:

Carry out matching treatment continuously for the object information that is stored in the center system.

10. method according to claim 8 also comprises:

According to from the data that one or more client machine system received, update stored in the object information in the center system continuously.

11. method according to claim 10, wherein, upgating object information comprises continuously: upgrade the map information that is used for each object.

12. method according to claim 8 also comprises:

In center system, create object, to comprise the global property of object.

13. method according to claim 8, wherein, the issue object comprises: issue is used for the global property of each object, and this method also comprises:

For at least one object in one of described one or more client machine systems, finish object information.

14. method according to claim 1 also comprises:

According to industry specific criteria mapping (enum) data object.

15. method according to claim 1 also comprises:

The framework of a Configure Client system software of issue is to receive data object from described center system.

16. the system of a shared data comprises:

The client machine system of one or more storage master datas, these master datas are used in each performed in client machine system processing; And

A central module, it is configured in described center system to receive master data from described one or more client machine systems, carries out matching treatment for the master data in center system, to determine whether there is identical or similar object in the center system, if in central module, there is identical object, then the object identity to identical object carries out mutual mapping, if in central module, there is similar object, then the object identity to similar object carries out mutual mapping, and object map information is provided in a processing.

17. system according to claim 16, wherein, described central module also is configured to remove the object that duplicates from described one or more client machine systems.

18. system according to claim 16, wherein, described central module also is configured to provide the object map that is used in described processing information to a data warehouse.

19. system according to claim 16 also comprises a data warehouse, this data warehouse is configured to receive the object map information that is used in the described processing.

Images