This webinar originally aired on Tuesday, September 11, 2012. It is part of Data Blueprint's ongoing webinar series on data management with Dr. Aiken.
Sign up for future sessions at http://www.datablueprint.com/webinar-schedule.
Abstract:
Commonly described as metadata management, properly implemented metadata practices incorporate data structures into more abstract processing. By using data about the data to enhance its value, its understandability, ease of use and many other options, organizations have developed sophisticated ways to enhance their data management and especially their data quality engineering efforts. Join us to learn more about specific metadata benefits and how to leverage it to achieve success within your organization.
5. Let’s Talk Metadata:
Strategies and
Successes
Let’s Talk Metadata: Strategies and Successes
DATA BLUEPRINT 10124-C W. BROAD ST, GLEN ALLEN, VA
23060
EDUCATION
From Data Model Patterns: A Metadata Map By the way (yes, I know this is a losing battle, but I have to speak up…) data are plural. One of them is a datum.
Need distinction at least between “Business metadata” and “technical metadata”. Business people need descriptions of what is there and (in their terms) where to find it. A significant part of this is “provenance”—where did they come from? Technicians need database structures, search paths, etc. These are two very different things.
CSM? (Actually, CWM is a failure. Unfortunately, IMM is not going well. A combination of all of us getting tired and a couple of fundamental errors of premises.)
I am skeptical that there are any products supporting CWM. I ’d like to think that my book (2006) established the standards, but not enough people have read it. I believe that not enough people really understand what its structure should look like. Until they do, the thrashing will continue.
Correct answer: B
What you say here is (mostly) true. By the way, the premises that won ’t work in IMM are: All transformation between languages should go through a “core model” The problem is that there is 1) too much information loss, and 2) manual work for each translation (e.g., e/r to relational design.) The design models don ’t include a metamodel of the design components of UML. Their premise is that, since we are using UML to represent it, we don’t have to acknowledge it as a language for representing design. Meanwhile there is a lot of packaging going on.
I have no idea what this category is. In my book, I did distinguish across the 6 dimensions of the Zachman Framework, but in each column, I went from business owners through designers. Still distinguishing between business and technical metadata. In row two you have functions and business processes (current physical DFD). In row three you have “essential” data flow diagrams, without mechanisms and organized by events. In row three, you have programs. Data stores are “views” in the data column. Process dependencies are in the “where” column. Government and regulatory bodies are in the people and organizations column, and business rules are in the motivation column.
The definition of business metadata is: Data required for a businessperson to understand what is available and how to get it.
Ok, this is a major problem I have with the DMBOK. I go back to the original ANSI Standard. External schema is the view that any one worker has of the data. This is particular, concrete, and in terms of his language. This is John Z ’s row two and here things like OWL, SBVR and other attempts to capture language live. To me this is one half of the conceptual model. It may also be described in terms of entities, attributes, and relationships. The conceptual schema is the integrated view that encompasses all of the external schemas. I actually like to call it the architectural model, because I have renamed row three of the Zachman Fmwk the “architect’s view”. But this is the second half of the conceptual schema. This is in terms of entities, attributes, and relationships. The third ANSI schema they call the “internal schema”. This is the one that describes how data are actually stored on the computer. I believe that this is of two flavors: The Logical model describes the world in terms of a particular data management technology. This can be relational tables and columns, object oriented classes, or XML tags. (In 1975, the issue was network or hierarchy). This is not physical. The physical “model” is how the data are actually arranged on physical computers. This is about tablespaces, partitions, CPUs, etc. I believe that the DMBOK completely screwed this up, and I welcome the opportunity to contribute again. (My first contribution was completely ignored, by the way…)
For each model topic: - Blue outputs describe models - Reference to profile is to collections of “stereotypes” in UML to allow model to be represented in UML. (It took me a VERY long time to understand what was going on here. After all, the point of the different models is that they look different! It ’s going to be a while before this is ready for public consumption. (One of the problems is that we haven ’t had any vendors participating. Nobody owns it.)