World Library  
Flag as Inappropriate
Email this Article

Holistic Data Management

Article Id: WHEBN0017377283
Reproduction Date:

Title: Holistic Data Management  
Author: World Heritage Encyclopedia
Language: English
Subject: Business intelligence, Information technology management, Data management
Collection: Business Intelligence, Data Management, Data Warehousing Products, Information Technology Management
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Holistic Data Management

Holistic Data Management (HDM) framework is AHISDATA indigenous standard for implementing software implementations within an organization network. This framework extends the existing data management solutions such as data quality, data governance, data integration, data processing, master data management and data validation solutions.

The HDM framework specifies that:

  • All data objects must exist as a child data object or a parent data object.
  • Only one unique parent data object must exist within a data network scope (DNS).
  • All child data objects must have a data-mapping link defined within a data network scope.
  • A data object relationship must exist at least in one of the following four data management modules:

Data mapping, data validation, data integration,data processing

Contents

  • HDM framework 1
  • Implementing the HDM framework 2
  • See also 3
  • External links 4

HDM framework

The following entities are specified in the HDM framework.

  • Data network scope (DNS)

The data network scope (DNS) is the logical boundary that a software application database system of record (SOR) exists within an enterprise network. There can be multiple DNS within an enterprise network.

  • Data network domain (DND)

The data network domain (DND) is the logical boundary representing a collection of multiple data network scope (DNS). There can be multiple DND within an enterprise network.

  • System of record (SOR)

A system of record applies to the master or principal database system that a parent data objects resides on. There can only be one SOR within a data network scope.

  • Parent data object (PDO)

A parent data object (PDO) is the system of record schema object name. Only one unique parent data object must exist within a data network scope.

  • Child data object (CDO)

A child data object (CDO) is a schema object name that derives its data from one or more parent data object(s).

  • Data-mapping link (DML)

A data-mapping link (DML) is the data requirement specification applied to the relationship between multiple database schema objects where one data object derives its data from one or more data objects. DML is only applicable for a data-mapping data management module.

  • Data–object relationship (DOR)

The data–object relationship (DOR) is the data requirement, business rule, program function that applies to one or multiple data objects. DOR can be applied on data-mapping links for each data management modules. Only one DOR can exist on a DML within a data management module.

  • Data management modules (DMM)

Data management modules are the common user interface (UI) programs that defines and manage the data object relationship(s) within a data network scope.

There are four data management modules:

Data mapping – This is the base data management user interface module. The data-mapping module provide the functionalities for managing data-mapping links and data object relationships for all database schemas within a data network scope. A data network scope must have at least one data-mapping design defined.

Data validation – This user interface module provides the functionalities for defining and managing validation events on data object relationships. Validation events include auditing, reporting, scheduler, logger, triggers and DNS health check. Data validation events requires a data-mapping design defined within a data network scope.

Data integration – This user interface module provides the functionalities for defining and managing interface configurations on data object relationships. The interface configurations include scheduler, transmission mode, listener, interface API and reporting. The interface APIs would allow third-party systems to transfer data using the data object relationship defined within a data network scope. Data Integration interface configuration requires a Data Mapping design defined within a data network scope.

Data processing – This user interface module provides the functionalities for defining and managing interface configurations and batch runtime engines on data object relationships. The interface configurations include scheduler, transmission mode, multi-batch transmission, user-defined DOR API and reporting. Data Processing interface configuration requires a data-mapping design defined within a data network scope.

Implementing the HDM framework

The HDM framework presents a standard for software implementations within an organization. The objective is to shed visibility, increase efficiency and centralized management of all other software implementations within an organization.

The HDM framework should be implemented as a major organization project that is supervised by the project management office. This would require a project charter developed and a project manager assigned for managing the implementation process. There are several phases involve in implementing the HDM framework:

  • Choose a data management module (DMM) – This exercise requires the acquisition of a data management module software application to be used for implementing the rest of the HDM framework. AHISDATA iNTEGRITY software is an integrated solution that provides DMM functionalities.
  • Scrub (inventory of existing applications and data sources) – This exercise identifies all applications within an organization and the data sources that they are connected to.
  • Formation (applications and data schema relation) – This exercise is to align all applications in relation to the data schemas within the data sources. The applications are grouped in the order of the data schemas that they access.
  • First axe (applications eligible for decommission) – This exercise is to identify all applications that are rogue, obsolete and completely redundant. These applications are eligible for removal.
  • Second axe (application eligible for consolidation) – This exercise is to identify all applications that have some functional similarities and some uniqueness in the data requirement. These applications are eligible for consolidation. The functionalities that are similar are left intact on one application and turned off or disabled on the other(s).
  • Define data network domain (DND) – This exercise is to define the data network domain for all the approved applications within the enterprise network.
  • Define Data Network Scope (DNS) – This exercise is to define the data network scope(s) required for each DND.
  • Define system of records (SOR) – This exercise is to define the SOR for each DNS.
  • Define parent data objects (PDO) – This exercise is to define all PDOs in each DNS.
  • Define child data objects (CDO) – This exercise is to define all CDOs in each DNS.
  • Define data mapping links (DML) – This exercise is to define all data-mapping links and object relationship in all DNS.
  • Define data object relationships (DOR) – This exercise is to define the DOR requirement for each data management module implemented.

See also

External links

  • AHISDATA HDM WhitePaper
  • The What, Why, and How of Master Data Management
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.