数据模型模式：思维规范指南

4星 · 超过85%的资源需积分: 12 136 浏览量更新于2024-07-20 2 收藏 17.11MB PDF 举报

《数据模型模式：思维规范》是一本由David C. Hay撰写的专著，它深入探讨了在实际商业环境中有效应用数据建模技术的技巧和洞察。这本书不仅仅关注基础的数据建模（实体关系建模）学习，而是强调了如何将这些理论转化为能够揭示组织本质的实用模型。作者通过分析会计、物料需求计划、流程制造、合同、实验室和文档等业务领域中的常见结构，引导读者理解企业运作的核心。书中的每一章都以具体业务场景为基础，提供了高层次的数据模型示例。首先，读者会了解到企业的整体框架（The Enterprise and Its World），然后深入探讨企业的实体和对象（The Things of the Enterprise），以及与之相关的操作和活动（Procedures and Activities）。接下来，书中涵盖了合同管理（Contracts）、会计系统（Accounting）、实验室操作（The Laboratory）、物料需求计划（Material Requirements Planning）、流程制造流程（Process Manufacturing）以及文档管理（Documents）。作者特别强调了"低层次的规范"（Lower-Level Conventions），即在设计数据模型时需要遵循的底层规则和最佳实践，这些可以帮助分析师们在处理复杂业务逻辑和数据结构时保持一致性。书中还提及了几个知名的企业方法论和商标，如Microsoft的商标、CASE*Method by Oracle Corporation以及IBM和ThinkPad等，这些都是在实践中可能用到的技术和产品标识。值得注意的是，书中部分内容摘自Richard D. Irwin公司的会计章节，并得到了版权许可。此外，书中的一些模型先前已在Oracle的其他出版物中展示过。《数据模型模式：思维规范》是一本极具实践价值的指南，对于希望提升数据建模技能并深入了解企业运营内部逻辑的IT分析师来说，它不仅提供了理论框架，还提供了丰富的实战案例和实践经验，有助于读者在真实商业环境中构建出更为精准和有效的数据模型。

PREFACE

~ earning the basics of a modeling technique is not the same as learn-

ing how to use and apply it. Data modeling is particularly complex

to learn, because it requires the modeler to gain insights into an

organization's nature that do not come easily, For example, an ana-

lyst may be expected to come into an organization and immediately under-

stand subtleties about its structure that may ha\'e evaded people who have

worked there for years,

This book is intended to help those analvsb \,'ho ha\e learned the basics oi

data modeling, but who are looking for help lI\ dlsco\'<c'rins subtleties and

obtaining the insights required to prepare a good model of a real business,

Moreover, the book is intended to help analysts produce models that are easier

to read, by virtue of standards of diagram structure and organization.

The book is based on the assumption that the underlying stnlctures of

enterprises are similar, or at least that they have similar components. Under-

standing those similarities gives an analyst a starting model, which can then be

massaged and adjusted as necessary to match the specific circumstances of a

particular company. This is not to say that all companies' models will look the

same. Quite the opposite is true. In your author's experience, no two organi-

zations' models have been identical. On the other hand, widely differing orga-

nizations, from government health protection agencies to oil refineries, have

many similar components.

An analyst who has these components in his intellectual tool kit is in a

good position to grasp quickly what is unique about an enterprise and to draw

a data model that both embodies universal truths and specificall)'~ represents

the business at hand.

This book has a second audience as well: As a child of the Sixties, I got into

the business world only reluctantly. Among the problems I faced ',vas under-

standing just how business works. Even in business school, I was never able to

find an introductory-level course that described how it \vorks as a whole. Each

course analyzed a specific area in detail, but none really pro\'ided the overview

I sought. It was only as I saw the patterns expressed in the structure of busi-

ness information that a business uses, that 1 began to come to grips with the

issues involved. Perhaps this book can be usdul to a similarly disadvantilged

student trying to understand the nature of the buslness world.

April 1995

Houston, Texas

XIX

D,C.H

Daveha y@essenhalstrategies,com

DATA MODEL PATTERNS

ness will not affect them. Moreover, data models promise to be useful as the

basis for discussions among all three sets of players (users, analysts, and

designers) about the future of information systems development in the organi-

zation. A data model can show, for example, the effect that a change to the

organization will have on its information systems.

Alas, data modeling has not always kept these promises. If it is not used

effectively, the technique neither improves communication nor imposes disci-

pline.

Data modeling as currently practiced suffers from two problems:

•

..•

Diagrams are often difficult to read .

Diagrams do not represent the fundamental nature of the organi-

zations they are supposed to describe .

Herein lies the purpose of this book. It describes an approach to data modeling

that can restore those promises by producing models that are both clearer than

those produced without using this approach, and more likely to address funda-

mental issues.

Clarity

As typically produced, data model diagrams can be less than inviting. While

the use of graphics is supposed to make the ideas presented more accessible,

the use of graphics without regard to aesthetic principles has the opposite

effect. A mass of boxes and lines with no identifiable shape or organization

aids in neither the understanding of an organization nor the planning of its

future systems development efforts. A common reaction to the typical data

model is: There are so many symbols! Where do I start? What is really going

on here? How can I use this?

Defining a set of symbols to represent data structures is not enough. It is

necessary to add a method for

organizing those symbols, so that the reader of

the model can deal with the drawing as a whole. It is also necessary to apply

some aesthetic standards, in order to ensure that meaning encoded in the sym-

bols can be accessible to the viewer.

Fundamentals of the Business

If you choose to build a new system, you want it to reflect the true require-

ments of your business-not simply to reproduce the techniques and technolo-

gy now in use. The reason for making the investment in the first place is that

you want to change

the way things are done, without necessarily changing the

nature of your enterprise.

A data model can help change the way things are done without affecting

the nature of your business if it presents what is unchanging in an organization.

It is intended to portray the things of significance, about which the company

INTRODUCTION

wishes to hold information. If the model succeeds, the things represented are

unlikely to change significantly, either with the application of new technology

(computer or other) or with the making of routine changes to the business of

the organization. Technology whose architecture is based on what is fundamen-

tal will improve the operational aspects of an organization while remaining

robust, stable, and flexible.

Unfortunately, what most people see in the course of their work (and conse-

quently tell systems analysts about) is not this unchanging nature at all, but

merely examples of it. They see only today's problems, and the particular tech-

nology they must use to do their jobs-to the point that the technology

becomes their job. Since the information an analyst gathers, therefore, is usually

expressed in terms of current practices, distinguishing between what is essen-

tial to a business and what is merely an accident of current technology is not

always easy. The essential facts are the things that "go without saying"-so

they don't get said. These facts don't get described or explained-or reflected

in new systems. Instead, new systems are often built on superficial views of

today's problems.

A plant that makes carbon black for printing ink and tires spent many

weeks discussing the best ways to determine production rates and yields. The

discussions concerned the best ways of predicting yield from the grade of nat-

ural gas that was used, but clearly something was not getting across. Finally,

the manager let slip the fact that yield is also a function of the production unit

used. The yield varies from unit to unit. This was obvious to him, so he didn't

mention it. Because it was not so obvious to the analyst, the original database

design had not taken this into account and had to be substantially redone.

The elements of a business that are typically portrayed in data models

reflect this difficulty. Instead of these essential facts about a business, model

diagrams are often dominated by references to the objects that represent the

particular way things are done now. A careless analyst may interpret transient

things to be things of importance. The resulting model will reflect only those

things that are important to wrrent business practices.

A purchasing agent, for example, might describe the company's purchas-

ing system, giving special emphasis to its shortcomings (such as the fact that

there may not be enough room on a purchase order for notes), while neglecting

to describe the essential facts about a purchase order (such as the fact that

"terms of sale" must appear). To build a new system based solely on the struc-

ture (and failings) of an existing system is to fail to take advantage of techno-

logical opportunities. Suppose, for example, purchasing were to do away with

paper forms altogether and dial directly into vendors' computers. What would

remain essential to the transaction?

How Standards Can Help

Both communications and discipline can be improved. Moreover, we can make

better use of each other's work. What is needed is standardization of our

DATA MODEL PATTERNS

approach to the modeling process. This does not mean simply using a common

system of notation, although that would certainly help. What it means, rather,

is using a common approach to

the way we think about business situations, and

to the way we organize our presentations of them. This book is about these

"conventions of thought." It identifies common situations that are present in a

variety of businesses and government agencies, and which can be modeled in a

standardized way. This standardization can make models both easier to read

and more descriptive of what is fundamental to an enterprise.

The modeling conventions presented here are an attempt to establish that

common approach to modeling. They do not represent the final models of any

real company or agency. Rather, they are starting points, showing ways of

looking at a business situation that should allow an analyst quickly to come to

terms with the most important aspects of it. Having done so, the analyst is

expected to apply creativity and imagination to adapt technology to those

aspects.

Each chapter of the book presents concepts fundamental to a topic. It

describes a typical business situation, provides basic models for portraying the

situation, and enumerates variations that can be expected across different orga-

nizations.

ABOUT MODELING CONVENTIONS

Using standard approaches-"conventions"-in the way we approach our

work greatly improves communication among analysts, and it makes the ana-

lytical work easier. Because conventions establish a framework, entire cate-

gories of decisions do not have to be made. Until now, the data modeling field

has not yet been mature enough to have established a complete set of standard

practices. While much has been written about the syntax and grammar of data

modeling, precious little has been written about the other elements that make

up good modeling standards. In fact, three levels of convention apply to data

modeling:

• Syntactic conventions are at the most basic level of defining models.

These conventions dictate the symbols to be used. The symbols por-

tray the things of significance to the enterprise (entities), and the rela-

tionships among them. Relationship symbols include those for

cardi-

nality

(the "one" and "many" in a "one-to-many" relationship) and

optionality (whether or not an occurrence of one entity must be relat-

ed to an occurrence of the other entity). Many notation schemes also

include symbols for describing how occurrences of entities are iden-

tified, enn to the point of specifying the primary keys that would be

used in relational database implementations of the models. Syntac-

tic conventions may also include rules for the structure of phrases

剩余276页未读，继续阅读

hychieftain

粉丝: 318
资源: 242

数据模型模式：思维规范指南

data-model-patterns:为数据库设计中的常见问题提供解决方案的数据模型集合

MK.Data.Model.Patterns.A.Metadata.Map

DATA MODEL PATTERNS-A Metadata Map

Design Patterns:Elements of Reusable Object-Oriented Software

设计模式 Design Patterns:Elements of Reusable Object-Oriented software

设计模式：可复用面向对象软件的基础（中文）Design Patterns：Elements of Reusable Object-Oriented software

设计模式可复用面向对象软件的基础（Design Patterns:Elements of Reusable Object-Oriented software）

ist的matlab代码-opendata-antipatterns:OpenData环境中功能异常模式的集合

design patterns: elements of reusable object-oriented software pdf csdn

Patterns: Model-Driven Development Using IBM Rational Software Architect

最新资源