Database Systems - Chapter 02.pdf - po ang - Januszek66

C6545_02 6/6/2007 9:18:3 Page 30

DATA MODELS

In this chapter, you will learn:

About data modeling and why data models are important

About the basic data-modeling building blocks

What business rules are and how they influence database design

How the major data models evolved

How data models can be classified by level of abstraction

This chapter examines data modeling. Data modeling is the first step in the database design

journey, serving as a bridge between real-world objects and the database that resides in the

computer.

P review

One of the most vexing problems of database design is that designers, programmers, and

end users see data in different ways. Consequently, different views of the same data can lead

to database designs that do not reflect an organization’s actual operation, failing to meet

end-user needs and data efficiency requirements. To avoid such failures, database designers

must obtain a precise description of the nature of the data and of the many uses of that data

within the organization. Communication among database designers, programmers, and end

users should be frequent and clear. Data modeling clarifies such communication by reducing

the complexities of database design to more easily understood abstractions that define

entities and the relations among them.

First, you will learn what some of the basic data-modeling concepts are and how current

data models developed from earlier models. Tracing the development of those database

models will help you understand the database design and implementation issues that are

addressed in the rest of this book. Second, you will be introduced to the Entity Relationship

Diagram (ERD) as a data modeling tool. ER diagrams can be drawn using a variety of

notations.Within this chapter you will be introduced to the traditional Chen notation, the

more current Crows’ Foot notation, and the newer class diagram notation, which is part of

the Unified Modeling Language (UML). Finally, you will learn how various degrees of data

abstraction help reconcile varying views of the same data.

C6545_02 6/6/2007 8:54:29 Page 31

DATA MODELS

2.1 DATA MODELING AND DATA MODELS

Database design focuses on how the database structure will be used to store and manage end-user data. Data modeling,

the first step in designing a database, refers to the process of creating a specific data model for a determined problem

domain. (A problem domain is a clearly defined area within the real world environment, with well defined scope and

boundaries, that is to be systematically addressed.) A data model is a relatively simple representation, usually

graphical, of more complex real-world data structures. In general terms, a model is an abstraction of a more complex

real-world object or event. A model’s main function is to help you understand the complexities of the real-world

environment. Within the database environment, a data model represents data structures and their characteristics,

relations, constraints, transformations, and other constructs with the purpose of supporting a specific problem domain.

NOTE

The terms

data model

and

database model

are often used interchangeably. In this book, the term

database

model

is used to refer to the implementation of a

data model

in a specific database system.

Data modeling is an iterative, progressive process. You start with a simple understanding of the problem domain, and

as your understanding of the problem domain increases, so does the level of detail of the data model. Done properly,

the final data model is in effect a “blueprint” containing all the instructions to build a database that will meet all end-user

requirements. This blueprint is narrative and graphical in nature, meaning that it contains both text descriptions in

plain, unambiguous language and clear, useful diagrams depicting the main data elements.

NOTE

An implementation-ready data model should contain at least the following components:

• A description of the data structure that will store the end-user data.

• A set of enforceable rules to guarantee the integrity of the data.

• A data manipulation methodology to support the real-world data transformations.

Traditionally, database designers relied on good judgment to help them develop a good data model. Unfortunately,

good judgment is often in the eye of the beholder, and it often develops after much trial and error. For example, if each

of the students in this class has to create a data model for a video store, it’s very likely that each of them will come

up with a different model. Which one would be the correct one? The simple answer is “the one that meets all the

end-user requirements,” and there may be more than one correct solution! Fortunately, database designers make use

of existing data modeling constructs and powerful database design tools that substantially diminish the potential for

errors in database modeling. In the following sections you will learn how existing data models are used to represent

real world data and how the different degrees of data abstraction facilitate data modeling. But first, you must

understand the importance of data models and their basic constructs.

2.2 THE IMPORTANCE OF DATA MODELS

Data models can facilitate interaction among the designer, the applications programmer, and the end user. A

well-developed data model can even foster improved understanding of the organization for which the database design

is developed. In short, data models are a communication tool. This important aspect of data modeling was summed

up neatly by a client whose reaction was as follows: “I created this business, I worked with this business for years, and

this is the first time I’ve really understood how all the pieces really fit together.”

C6545_02 6/6/2007 8:55:2 Page 32

CHAPTER 2

The importance of data modeling cannot be overstated. Data constitute the most basic information units employed by

a system. Applications are created to manage data and to help transform data into information. But data are viewed

in different ways by different people. For example, contrast the (data) view of a company manager with that of a

company clerk. Although the manager and the clerk both work for the same company, the manager is more likely to

have an enterprise-wide view of company data than the clerk.

Even different managers view data differently. For example, a company president is likely to take a universal view of

the data because he or she must be able to tie the company’s divisions to a common (database) vision. A purchasing

manager in the same company is likely to have a more restricted view of the data, as is the company’s inventory

manager. In effect, each department manager works with a subset of the company’s data. The inventory manager is

more concerned about inventory levels, while the purchasing manager is more concerned about the cost of items and

about personal/business relationships with the suppliers of those items.

Applications programmers have yet another view of data, being more concerned with data location, formatting, and

specific reporting requirements. Basically, applications programmers translate company policies and procedures from

a variety of sources into appropriate interfaces, reports, and query screens.

The different users and producers of data and information often reflect the “blind people and the elephant” analogy:

the blind person who felt the elephant’s trunk had quite a different view of the elephant from the one who felt the

elephant’s leg or tail. What is needed is a view of the whole elephant. Similarly, a house is not a random collection

of rooms; if someone is going to build a house, he or she should first have the overall view that is provided by

blueprints. Likewise, a sound data environment requires an overall database blueprint based on an appropriate

data model.

When a good database blueprint is available, it does not matter that an applications programmer’s view of the data is

different from that of the manager and/or the end user. Conversely, when a good database blueprint is not available,

problems are likely to ensue. For instance, an inventory management program or an order entry system may use

conflicting product numbering schemes, thereby costing the company thousands (or even millions) of dollars.

Keep in mind that a house blueprint is an abstraction; you cannot live in the blueprint. Similarly, the data model is an

abstraction; you cannot draw the required data out of the data model. Just as you are not likely to build a good house

without a blueprint, you are equally unlikely to create a good database without first creating an appropriate data model.

2.3 DATA MODEL BASIC BUILDING BLOCKS

The basic building blocks of all data models are entities, attributes, relationships, and constraints. An entity is anything

(a person, a place, a thing, or an event) about which data are to be collected and stored. An entity represents a

particular type of object in the real world. Because an entity represents a particular type of object, entities are

“distinguishable” that is, each entity occurrence is unique and distinct. For example, a CUSTOMER entity would have

many distinguishable customer occurrences, such as John Smith, Pedro Dinamita, Tom Strickland, etc. Entities may

be physical objects, such as customers or products, but entities may also be abstractions, such as flight routes or musical

concerts.

An attribute is a characteristic of an entity. For example, a CUSTOMER entity would be described by attributes such

as customer last name, customer first name, customer phone, customer address, and customer credit limit. Attributes

are the equivalent of fields in file systems.

A relationship describes an association among entities. For example, a relationship exists between customers and

agents that can be described as follows: an agent can serve many customers, and each customer may be served by one

agent. Data models use three types of relationships: one-to-many, many-to-many, and one-to-one. Database designers

usually use the shorthand notations 1:M or 1..*, M:N or *..*, and 1:1 or 1..1, respectively. (Although the M:N notation

C6545_02 6/4/2007 15:32:25 Page 33

DATA MODELS

is a standard label for the many-to-many relationship, the label M:M may also be used.) The following examples

illustrate the distinctions among the three.

One-to-many (1:M or 1..*) relationship . A painter paints many different paintings, but each one of them

is painted by only one painter. Thus, the painter (the “one”) is related to the paintings (the “many”). Therefore,

database designers label the relationship “PAINTER paints PAINTING” as 1:M. (Note that entity names are

often capitalized as a convention so they are easily identified.) Similarly, a customer (the “one”) may generate

many invoices, but each invoice (the “many”) is generated by only a single customer. The “CUSTOMER

generates INVOICE” relationship would also be labeled 1:M.

Many-to-many (M:N or *..*) relationship . An employee may learn many job skills, and each job skill may

be learned by many employees. Database designers label the relationship “EMPLOYEE learns SKILL” as M:N.

Similarly, a student can take many classes and each class can be taken by many students, thus yielding the M:N

relationship label for the relationship expressed by “STUDENT takes CLASS.”

One-to-one (1:1 or 1..1) relationship . A retail company’s management structure may require that each of

its stores be managed by a single employee. In turn, each store manager, who is an employee, manages only

a single store. Therefore, the relationship “EMPLOYEE manages STORE” is labeled 1:1.

The preceding discussion identified each relationship in both directions; that is, relationships are bidirectional:

One CUSTOMER can generate many INVOICEs.

Each of the many INVOICEs is generated by only one CUSTOMER.

A constraint is a restriction placed on the data. Constraints are important because they help to ensure data integrity.

Constraints are normally expressed in the form of rules. For example:

An employee’s salary must have values that are between 6,000 and 350,000.

A student’s GPA must be between 0.00 and 4.00.

Each class must have one and only one teacher.

How do you properly identify entities, attributes, relationships, and constraints? The first step is to clearly identify the

business rules for the problem domain you are modeling.

2.4 BUSINESS RULES

When database designers go about selecting or determining the entities, attributes, and relationships that will be used

to build a data model, they might start by gaining a thorough understanding of what types of data are in an

organization, how the data are used, and in what time frames they are used. But such data and information do not,

by themselves, yield the required understanding of the total business. From a database point of view, the collection of

data becomes meaningful only when it reflects properly defined business rules .A business rule is a brief, precise,

and unambiguous description of a policy, procedure, or principle within a specific organization. In a sense, business

rules are misnamed: they apply to any organization, large or small—a business, a government unit, a religious group,

or a research laboratory—that stores and uses data to generate information.

Business rules, derived from a detailed description of an organization’s operations, help to create and enforce actions

within that organization’s environment. Business rules must be rendered in writing and updated to reflect any change

in the organization’s operational environment.

Properly written business rules are used to define entities, attributes, relationships, and constraints. Any time you see

relationship statements such as “an agent can serve many customers, and each customer can be served by only one

agent , ” you are seeing business rules at work. You will see the application of business rules throughout this book,

especially in the chapters devoted to data modeling and database design.

C6545_02 6/4/2007 14:5:26 Page 34

CHAPTER 2

To be effective, business rules must be easy to understand and widely disseminated to ensure that every person in the

organization shares a common interpretation of the rules. Business rules describe, in simple language, the main and

distinguishing characteristics of the data as viewed by the company . Examples of business rules are as follows:

A customer may generate many invoices.

An invoice is generated by only one customer.

A training session cannot be scheduled for fewer than 10 employees or for more than 30 employees.

Note that those business rules establish entities, relationships, and constraints. For example, the first two business rules

establish two entities (CUSTOMER and INVOICE) and a 1:M relationship between those two entities. The third

business rule establishes a constraint (no fewer than 10 people and no more than 30 people), two entities (EMPLOYEE

and TRAINING), and a relationship between EMPLOYEE and TRAINING.

2.4.1 DISCOVERING BUSINESS RULES

The main sources of business rules are company managers, policy makers, department managers, and written

documentation such as a company’s procedures, standards, or operations manuals. A faster and more direct source

of business rules is direct interviews with end users. Unfortunately, because perceptions differ, end users sometimes are

a less reliable source when it comes to specifying business rules. For example, a maintenance department mechanic

might believe that any mechanic can initiate a maintenance procedure, when actually only mechanics with inspection

authorization can perform such a task. Such a distinction might seem trivial, but it can have major legal consequences.

Although end users are crucial contributors to the development of business rules, it pays to verify end-user

perceptions . Too often, interviews with several people who perform the same job yield very different perceptions of

what the job components are. While such a discovery may point to “management problems,” that general diagnosis

does not help the database designer. The database designer’s job is to reconcile such differences and verify the results

of the reconciliation to ensure that the business rules are appropriate and accurate.

The process of identifying and documenting business rules is essential to database design for several reasons:

They help standardize the company’s view of data.

They can be a communications tool between users and designers.

They allow the designer to understand the nature, role, and scope of the data.

They allow the designer to understand business processes.

They allow the designer to develop appropriate relationship participation rules and constraints and to create

an accurate data model.

Of course, not all business rules can be modeled. For example, a business rule that specifies that “no pilot can fly more

than 10 hours within any 24-hour period” cannot be modeled. However, such a business rule can be enforced by

application software.

2.4.2 TRANSLATING BUSINESS RULES INTO DATA MODEL COMPONENTS

Business rules set the stage for the proper identification of entities, attributes, relationships, and constraints. In the real

world, names are used to identify objects. If the business environment wants to keep track of the objects, there will be

specific business rules for them. As a general rule, a noun in a business rule will translate into an entity in the model,

and a verb (active or passive) associating nouns will translate into a relationship among the entities. For example, the

business rule “a customer may generate many invoices” contains two nouns ( customer and invoices ) and a verb

( generate ) that associates the nouns. From this business rule, you could deduct that:

Customer and invoice are objects of interest for the environment and should be represented by their respective

entities.

There is a “generate” relationship between customer and invoice.

Database Systems - Chapter 02.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: