Data Model Patterns: A Metadata Map

East Coast DAMA 2006 David C. Hay

May-June, 2006

Essential Strategies, Inc.

13 Hilshire Grove Lane, Houston, TX 77055 (713) 464-8316 dch@essentialstrategies.com www.essentialstrategies.com

There once was a fellow named Corey Whose career was not covered in glory He had a bad day When he just couldnt say Metadata Repository.

Introduction

Essential Strategies, Inc.

13 Hilshire Grove Lane, Houston, TX 77055 (713) 464-8316 dch@essentialstrategies.com www.essentialstrategies.com

About Metadata . . .

This Book (Metametadata)

Elements of metadata (metadata model) Data about a database (a data model)

Objects: Entity Class, Attribute

Objects: Entity Class Attribute Role

Objects: Table Column

Object: Program module, Language

Data Management (Metadata)

Entity class: Customer Attributes: Name Birthdate

Entity classes: Branch, Employee Attributes: Employee.Address Employee.Name Role: Each Branch must be managed by exactly one Employee Branch Address: 111 Wall Street Branch Manager: Sam Sneed

Table: CHECKING_ ACCOUNT Columns: Account_number Monthly_charge

Program module: ATM Controller Language: Java

IT Operations (Instance Data)

Data about real world things (a database)

Customer Name: Julia Roberts; Customer Birthdate: 10/28/67

CHECKING_ ACCOUNT. Account_number: = 09743569 CHECKING_ ACCOUNT. Monthly_charge: $4.50 Checking account #09743569

ATM Controller: Java code

Real world things

Julia Roberts

Wall Street branch

ATM Withdrawal

3 Copyright 2005, Essential Strategies, Inc.

The Architecture Framework . . .

Data (What) Objectives / Scope (Planner's view)
List of things important to the enterprise
- Term 1 - Term 2 - Term 3 ...

Activities (How)
List of processes the enterprise performs
- Function 1 - Function 2 - Function 3 ...

Locations (Where)
List of enterprise locations

People (Who)
Organization approaches

Time (When)
Business master schedule

Motivation (Why)
Business vision and mission

- Vision ... - Mission ...

Enterprise model (Business Owners' Views) Model of Fundamental Concepts (Architect's View) Technology Model (Designer's View)

Language, divergent data model

Business process model

Logistics network

Organization chart

State / transition diagram

Business strategies, tactics, policies, rules

Objectives Strategies Tactics Constraints

Convergent e/r model

Essential data flow diagram

Locations of roles

The viable system, use cases

Entity Life History

Business rule model

Data base design

System design, program structure

Hardware, software distribution

User interface, security design

Control structure

Business rule design

Mainframe

1 Mid-range server Work Station

Detailed Representation (Builder's VIew)

Physical storage design

Detailed program design

Network architecture, protocols

Screens, security coding

Timing definitions

Rule specification program logic

IP: 137.39.65.798

IP: 324.33.56.765

IP: 234.21.43.111

Functioning System

(Working System)
Converted data Executable programs Communications facilities Trained people Business events Enforced rules

4 Copyright 2005, Essential Strategies, Inc.

The Rows . . .
Planners View: Scope, Vision, Mission Business Owners View: The people who do the work Architects View: Looking for a single, integrated view Designers View: Using technology to solve problems Builders View: The nuts and bolts of programming, database administration The Functioning System: Systems as they exist

5 Copyright 2005, Essential Strategies, Inc.

The Columns . . .
Data: What does the enterprise works with? Activities: How does the enterprise do its job? Locations: Where does the enterprise work? People and organizations: Who is involved? Events and timing: When do things happen? Motivation: Why does the enterprise do what it does?

6 Copyright 2005, Essential Strategies, Inc.

A typical data (object) model . . .

LineItem
Order Number [1..1] integer Order Date [1..1] date Order Taker [0..1] string part of 0..* 1..1 composed of

SalesOrder
Order Number [1..1] integer Order Date [1..1] date Order Taker [0..1] string from 0..* 1..1 the buyer in

Customer
Name [1..1] string Shipping Address [1..1] string Billing Address [1..1] string

0..*

for

sold via

1..1

ProductType
Product Number [1..1] string Product Name [1..1] string Description [0..1] string Unit Cost [0..1] real number

7 Copyright 2005, Essential Strategies, Inc.

Our first metamodel . . .

Attribute
Name [1]:string Data Type [0..1]:string Maximum Length [0..1]:number Average Length [0..1]:number Decimal [0..1]:number Optionality [1]:string

ObjectClass
about 0..* 1 described by
Name [1] : string

Object Classes Name Object Class (Name)

ObjectClass Attribute Attribute Attribute Attribute

Attributes Name Data Type Max. Length

. . .

ObjectClass Attribute

Name Name Data Type Maximum Length ...

String String String Number

15 15 10 3

8 Copyright 2005, Essential Strategies, Inc.

Add Roles . . .

connected to 1

Role
connected to Name [1]:string Cardinality [1]:string Optionality [1]:boolean 0..* 1 connected via

Object Class Name [1]:string

1 connected from

a super-type of 0..1

0..2..* a sub-type of

Attribute
Name [1]:string Data Type [0..1]:string Maximum Length [0..1]:number Average Length [0..1]:number Decimal [0..1]:number Optionality [1]:number about 0..* 1 described by

9 Copyright 2005, Essential Strategies, Inc.

What about an entity / relationship model, instead . . .

connected to
1

RelationshipEnd
0..* 1..1 Name [1]:string Cardinality [1]:string Optionality [1] boolean

Entity Type
Name [1]:string

connected from

connected to

connected via a super-type of

0..1

0..2..*

a sub-type of

Attribute
Name [1]:string Data Type [0..1]:string Maximum Length [0..1]:number Average Length [0..1]:number Decimal [0..1]:number 0..* about 1..1 described by

StrangeIt looks just the same

10 Copyright 2005, Essential Strategies, Inc.

Another approach . . .
connected to connected from ENTITY CLASS
# NAME

RELATIONSHIP ROLE
played by # NAME * CARDINALITY INDICATOR * DEFAULT OPTIONALITY INDICATOR player of

Each <entity class 1> Must be (or) May be (<relationship name>

a sub- type of

ATTRIBUTE
# o * o o o o o * NAME DEFAULT VALUE FORMAT MAX LENGTH AVG LENGTH DECIMAL FORMULA TEXT CARDINALITY INDCTR DEFAULT OPTIONALITY INDCTR

a supertype of (2+)

One and only one (or) One or more <entity class 2> .

about described by

For example:

Each ENTITY CLASS may be player of one or more RELATIONSHIP ROLES. Each RELATIONSHIP ROLE must be played by one and only one ENTITY CLASS.

11 Copyright 2005, Essential Strategies, Inc.

On to the METADATA MODEL . . .

12 Copyright 2005, Essential Strategies, Inc.