UML and Data Modeling: A Reconciliation

242 Pages·2011·4.53 MB·English

by  David C. Hay

UML & Data
Modeling:

A Reconciliation

David C. Hay

Foreword by Sridhar Iyengar
Published by:
Technics Publications, LLC
966 Woodmere Drive
Westfield, NJ 07090 U.S.A.
www.technicspub.com
Edited by Carol Lehn
Cover design by Mark Brye

Cover Origami:
Designed by Tomako Fusé
Folded by David C. Hay
Photographed by Włodzimersz Kurniewicz

All rights reserved. No part of this book may be reproduced or
transmitted in any form or by any means, electronic or mechanical,
including photocopying, recording or by any information storage and
retrieval system, without written permission from the publisher, except
for the inclusion of brief quotations in a review.
The author and publisher have taken care in the preparation of this book,
but make no expressed or implied warranty of any kind and assume no
responsibility for errors or omissions. No liability is assumed for
incidental or consequential damages in connection with or arising out of
the use of the information or programs contained herein.
All trade and product names are trademarks, registered trademarks, or
service marks of their respective companies, and are the property of their
respective holders and should be treated as such.
This book is printed on acid-free paper.
Copyright © 2011 by David C. Hay
ISBN, print ed. 978-1-9355041-9-1
Printing ( 4 5 6 7 8 9)
Library of Congress Control Number: 2011938560
ATTENTION SCHOOLS AND BUSINESSES: Technics Publications
books are available at quantity discounts with bulk purchase for
educational, business, or sales promotional use. For information, please
write to Technics Publications, 966 Woodmere Drive, Westfield, NJ
07090, or email Steve Hoberman, President of Technics Publications, at
[email protected].
Dedicated in memory of my college roommate and

life-long friend:

Mark Rumsey MacHogan
1947-2010

Table of Contents
Foreword 1
Preface 3
Acknowledgements 7
Chapter 1: Introductions 9
The Structure of the Book 9
Observations 10
Introduction for Data Modelers 10
Introduction for UML Modelers 15
Combined Introduction 18
Historical Threads 18
Architectural Framework 19
Views of the Business 20
Views of Technology 20
Business Owner’s View 22
Architect’s View 23
Designer’s View 24
Summary 24
Chapter 2: UML and Essential Data Models 27
Impedance Mismatch 27
Architecture vs. Object-oriented Design 31
Limiting Objects to Business Objects 31
Behavior 32
Relationships and Associations 34
Entity/Relationship Predicates 36
Specifying Role Names in UML 39
A Fundamental Change to UML 41
One Solution: Stereotypes 46
Second Solution: Conversion 46
Domains, Data Types, and Enumerations 48
Namespaces 52
Object Oriented Design vs. Relational Database Design 52
Persistent Data 52
Inheritance 53
Security 54
Summary 55
Chapter 3: How to Draw an Essential Data Model in UML 57
Summary of the Approach 57
1. Show Domain-Specific Entity Cases Only 59
2. Use Symbols Selectively 60
Use Appropriate Symbols 60
Class (Entity Class) 60
Attribute 62
Association (Relationship) 63
Cardinality 65
Exclusive or (XOR) Constraint 67
Use Some UML-specific Symbols with Care 68
Entity Class Sup-types and Relationship Sub-types 69
<<Enumeration>> 71
Derived Attributes 72
Package 74
Add One Symbol 75
Do Not Use Any Other Symbols 79
3. Define Domains 82
4. Understand “Namespaces” 84
5. Follow Display Conventions 85
Name Formats 85
Role Positions 85
“Exclusive or” Relationship Constraint 86
Cardinality Display 86
Summary 86
Chapter 4: Aesthetic guidelines and Best Practices 89
Introduction – Aesthetic Considerations 89
Place Sub-types Inside Super-types 91
Condensed Entity/Relationship Approach 91
The UML (and that of some entity/relationship notations) Approach 92
One Problem 95
Solution 95
Constraints 95
Categories 97
Eliminate Bent Lines 98
Orient “Many” End of Relationships to Top and Left 101
Presentation 102
Summary 104
Chapter 5: An Example: Party 107
Parties 109
Party Relationships 111
Party Identifiers and Names 113
Constraints 120
Summary 123
Appendix A: A Brief Summary of The Approach 125
Appendix B: A History of Modeling Objects and Data 127
Data Processing 128
Early Programming Languages 129
Object-oriented Programming Languages 130
Structured Techniques 131
Structured Programming 131
Structured Design 132
Data Architecture 133
Early Data Modeling 133
CODASYL 133
Dr. Edward Codd (1970) 134
Early Relational Databases 135
Three Schema Architecture (1972) 136
Dr. Peter Chen (1976) 138
Business Analysis 141
Structured Analysis 141
Business Process Reengineering 142
Later Data Modeling 144
Richard Barker and Harry Ellis (1980) 148
IDEF1X 149
Object-Role Modeling (ORM) 150
About Discipline in Data Modeling 151
Data Model Patterns 151
David Hay (1995) 151
Len Silverston, Kent Graziano, Bill Inmon (1997) 152
Architecture Frameworks 152
John Zachman (1979) 152
David Hay (2003, 2006) 153
Business Rules 154
Ron Ross (1987) 155
Business Rule Group (1995) 155
Object Management Group (2008) 156
Data Management 156
Object-oriented Development 157
Early Object Modeling 157
Shlaer & Mellor (1988) 157
Coad and Yourdon (1990) 159
Rumbaugh, et. al. (1991) 161
Embley/Kurtz/Woodfield (1992) 164
Booch (1994) 166
Object Patterns 167
Design Patterns 167
Martin Fowler – Analysis Patterns 167
UML 168
The Internet and the Semantic Web 169
Computer Time-sharing 170
ARPANET 171
The Internet 174
The World Wide Web 177
The Semantic Web 182
Summary – The “Reconciliation” 187
Glossary 191
Bibliography 223
Index 231
Foreword
By Sridhar Iyengar

I had the interesting experience of initially meeting David Hay in the late
1990s a couple of years after Unified Modeling Language (UML) became
an Object Management Group (OMG) standard. I was giving a talk at
the DAMA Data Warehouse Conference on the topic of modeling and
metadata management using UML and a related standard at OMG called
the Meta Object Facility (MOF). The audience was interested to learn
about UML but somewhat skeptical because the use of Peter Chen’s E/R
modeling notation was well known and established in the data modeling
community. There was one particular attendee (you guessed right - it
was David!) who was a little more vocal than the rest and challenged me
when I asserted that UML and its notation was not just for object
modelers but could also help data modelers. I thoroughly enjoyed the
debate but confess I was a bit irritated because the flow of my talk was
interrupted a bit!
What followed back and forth at this conference and again in a couple of
follow on conferences was an indication of how widespread the
‘impedance mismatch’ was that existed between the community of data
modelers/data architects and object modelers/object architects. There
were several debates during talks and also after talks during cocktails on
this clash of data/object modelers and I challenged the audience to be
more open minded about UML in part because there was a lot more to
UML than just simple structural modeling of objects.
I was extremely pleased to see David join the effort at OMG in
establishing a new Information modeling and Metadata Management
standard. David was determined to do something that others had tried
but given up too soon. He really wanted to bridge the data modeling and
object/UML modeling community not just by using the UML notation in
a superficial manner, but also by addressing concerns that data architects
and data modelers actually faced in their daily work – concerns about
structure and semantics, as well as notation and methodology familiar to
data modelers. I have followed the debates on OMG mailing lists where
David over the years has earned the respect of his object modeling
colleagues (he clearly already did this in the data modeling community
1