Databases Reference
In-Depth Information
Master Data Management
Master data is data that is critical to the operation of a business, but which itself is non-
transactional. Master data includes data concerning users, customers, products, sup‐
pliers, departments, geographies, sites, cost centers, and business units. In large organ‐
izations, this data is often held in many different places, with lots of overlap and re‐
dundancy, in many different formats, and with varying degrees of quality and means of
access.
Master Data Management
(MDM) is the practice of identifying, cleaning, stor‐
ing, and, most importantly, governing this data. Its key concerns include managing
change over time as organizational structures change, businesses merge, and business
rules change; incorporating new sources of data; supplementing existing data with ex‐
ternally sourced data; addressing the needs of reporting, compliance, and business in‐
telligence consumers; and versioning data as its values and schemas change.
Graph databases don't provide a full MDM solution; they are, however, ideally applied
to the modeling, storing, and querying of hierarchies, master data metadata, and master
data models. Such models include type definitions, constraints, relationships between
entities, and the mappings between the model and the underlying source systems. A
graph database's structured yet schema-free data model provides for ad hoc, variable,
and exceptional structures—schema anomalies that commonly arise when there are
multiple redundant data sources—while at the same time allowing for the rapid evolu‐
tion of the master data model in line with changing business needs.
Network and Data Center Management
In
Chapter 3
we looked at a simple data center domain model, showing how the physical
and virtual assets inside a data center can be easily modeled with a graph. Communi‐
cations networks are graph structures; graph databases are, therefore, a great fit for
modeling, storing, and querying this kind of domain data. The distinction between
network management of a large communications network versus data center manage‐
ment is largely a matter of which side of the firewall you're working. For all intents and
purposes, these two things are one and the same.
A graph representation of a network enables us to catalogue assets, visualize how they
are deployed, and identify the dependencies between them. The graph's connected
structure, together with a query language like Cypher, enable us to conduct sophisticated
impact analyses, answering questions such as:
• Which parts of the network—which applications, services, virtual machines, phys‐
ical machines, data centers, routers, switches, and fibre—do important customers
depend on? (Top-down analysis)
• Conversely, which applications and services, and ultimately, customers, in the net‐
work will be affected if a particular network element—a router or switch, for ex‐
ample—fails? (Bottom-up analysis)
