Solution Manual for Modern Database Management 13th Edition Heikki Topi, Jeffrey A Hoffer, Ramesh Ve

200

Chapter 1

Instructor's Resource Manual Modern Database Management Thirteenth Edition Jeffrey Hoffer University of Dayton Ramesh Venkataraman Indiana University Heikki Topi Bentley University

ISBN-10: 0134792238 ISBN-13: 9780134792231

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

201

Chapter 1 The Database Environment and Development Process Chapter Overview The purpose of this chapter is to introduce students to the world of data management as a whole, and specifically to the database approach to information systems development, the important concepts and principles of the database approach, and the database development process within the broader context of information systems development. This is an important chapter because it conveys a sense of the central importance of databases and data management in today‘s information systems environment and in all modern enterprises. The idea of an organizational database is intuitively appealing to most students. However, many students will have little or no background or experience with the technical implementation of databases. Others will have had some experience with database management systems intended for personal or workgroup use (such as Microsoft Access). Consequently, they will have a limited perspective concerning an organizational approach to databases.

In this chapter, we introduce the basic concepts and definitions of databases and data management, starting with an organizing framework that is new to this chapter. We contrast data with information, and introduce the notion of metadata and its importance. We also contrast the database approach with older file processing systems, and introduce the Pine Valley Furniture Company case to illustrate these concepts. We describe the range of database applications, from databases with a personal or workgroup scope to enterprise databases, and identify key decisions that must be made for each type of database.

We describe both the potential benefits and typical costs of using the database approach. We also trace the historical evolution of database systems, in order to provide a context for understanding the database approach for data storage and retrieval. The chapter outlines the differences between transactional and informational approaches and highlights the way new, analytics-focused technologies are transforming data management.

The chapter also presents an expanded description of the systems development life cycle (including an introduction to rapid application development methods of prototyping and agile software development)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

202

Chapter 1

and the role of database development within it. The chapter provides an updated description of the wellknown three-schema architecture and uses it to summarize the various deliverables of database development. It concludes with an example of database development situated in the context the Pine Valley Furniture Company case.

Chapter Objectives Specific student learning objectives are included at the beginning of each chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Create a sense of excitement concerning the data and database management field and the types of job opportunities that are available.

2. Acquaint students with the broad spectrum of database applications and how organizations are using database applications for competitive advantage.

3. Introduce the data management framework that organizes the book and the conceptual space of data management, highlighting how relational technologies and non-relational technologies can be seen as part of the same space.

4. Introduce the key terms and definitions that describe the database environment.

5. Describe data models and how they are used to capture the nature and relationships among data.

6. Describe the major components of the database environment and how these components interact with each other.

7. Provide a review of systems development methodologies, particularly the systems development life cycle, prototyping, and agile software development; build an understanding of how database development is aligned with these methodologies.

8. Develop an understanding of the different roles within in a database development team.

9. Make students aware of the three-schema architecture and its benefits for database development and design.

10. Introduce the Pine Valley Furniture Company case, which is used throughout the text to illustrate important concepts.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

203

11. Introduce the Mountain View Community Hospital case, which is included at the end of each chapter as a source for student projects.

Key Terms Agile software development

Database

Conceptual schema Constraint Data

Database application Physical schema Database management system (D B Project MS) Enterprise data modeling Prototyping

Data independence Data model

Enterprise resource planning (E RP) Relational database Entity Repository

Data modeling and design tools Data warehouse

Information Logical schema

Metadata

Systems development life cycle (S DLC) User view

Classroom Ideas 1. Start with a discussion of how students interact with systems built on databases on a daily basis (credit card transactions, shopping cards, telephone calls, cell phone contact lists, downloadable music, etc.). If you teach in a classroom with computers, ask students to find examples of Web sites that appear to be accessing databases.

2. Contrast the terms ―data‖ and ―information.‖ Using Figure 1-1 as a starting point, have the students provide some good examples of data and information from their own experiences. This may well lead to some differences of opinion, and the conclusion that one person‘s data may be another person‘s information.

3. Introduce the concept of metadata using Table 1-1. Ask the students to suggest other metadata that might be appropriate for this example.

4. Discuss file processing systems and their limitations, using Figure 1-2 and Table 1-2. Emphasize that many of these systems are still in use today.

5. Introduce data models using Figure 1-3. Discuss the differences between an enterprise data model

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

204

Chapter 1

and a project data model, using Figures 1-3 (a) and (b).

6. Discuss each of the advantages of the database approach (Table 1-3). Stress that these advantages can only be achieved through strong organizational planning and commitment. Also discuss the costs and risks of the database approach (Table 1-4).

7. Introduce the integrated data management framework presented in Figure 1-5 with a particular focus on the Operational – Informational distinction and the emergence of new technologies (such as No S QL DBMSs and Hadoop) in the Analytical–Big Data category.

8. Introduce the students to the major components of the database environment (Figure 1-6). Stress the interfaces between these components and the fact that a proper selection of the components can ―make or break‖ a database implementation.

9. Introduce the concept of a data warehouse as a type of enterprise database. This topic is described in detail in Chapter 9.

10. Review the evolution of database technologies and the significance of each era (Figure 1-11). Add your own perspective to the directions that this field is likely to take in the future.

11. Your students may have examples from their workplaces to contribute about client/server architectures. You may also provide them with an understanding of where the D BMS software and their data will be stored at your school as an illustration.

12. A quick in-class demo of Microsoft Access or similar product is useful to give the students an initial exposure to a DBMS and demonstrate a prototyping approach to database development. Consider using the PVFC prototyping request as an example.

13. If time permits, have the students answer several problems and exercises in class.

14. Use the project case to reinforce concepts discussed in class. Students can be assigned to work on this case in class if time permits, or it can be used as a homework assignment.

15. If time permits, use the book‘s sample database resources available through pearsonhighered.com/hoffer to demonstrate the structure and contents of a relational database for some of the textbook data sets. Demonstrate, or lead students through, some simple S QL retrieval exercises against the textbook databases.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

205

Answers to Review Questions 1-1.

Define each of the following key terms:

a. Data. Stored representations of objects and events that have meaning and importance in the user‘s environment. b. Information. Data that have been processed in such a way as to increase the knowledge of the person who uses it. c. Metadata. Data that describes the properties or characteristics of end-user data and the context of that data. d. Enterprise resource planning (ERP). A class of systems that integrate all functions of the enterprise, such as manufacturing, sales, finance, marketing, inventory, accounting and human resources. e. Data warehouse. An integrated decision support database whose content is derived from the various operational databases. f. Constraint. A rule that cannot be violated by database users. g. Database. An organized collection of logically related data. h. Entity A person, place, object, event, or concept in the user environment about which the organization wishes to maintain data. i. Database management system. A software system that is used to create, maintain, and provide controlled access to user databases. j. Data lake. A large integrated repository for internal and external data that does not follow a predefined schema. k. Systems development life cycle (S DLC). A traditional methodology used to develop, maintain, and replace information systems. l. Prototyping. An iterative process of systems development in which requirements are converted to a working system that is continually revised through close work between analysts and users.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

206

Chapter 1

m. Enterprise data model. The first step in database development, in which the scope and general contents of organizational databases are specified. n. Conceptual data model. A detailed, technology-independent specification of the overall structure of organizational data. o. Logical data model. The representation of data for a particular data management technology (such as the relational model). In the case of a relational data model, elements include tables, columns, rows, primary and foreign keys, as well as constraints. p. Physical data model. A set of specifications that detail how data from a logical data model (or schema) are stored in a computer‘s secondary memory for a specific database management system. There is one physical data model (or schema) for each logical data model.

1-2.

Match the following terms and definitions:

c

agile software development

b database application l

constraint

g repository f

metadata

m data warehouse a information j

user view

k

database management system

h data independence e entity i

enterprise resource planning (E RP)

r

systems development life cycle (S DLC)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

207

o prototyping d enterprise data model q conceptual schema p internal schema n external schema 1-3.

Contrast the following terms:

a. Data dependence; data independence. With data dependence, data descriptions are included with the application programs that use the data, while with data independence the data descriptions are separated from the application programs. b. Structured data; unstructured data. Structured data refers to facts related to objects and events of importance in the user‘s environment and represent the traditional data that is easily stored and retrieved in traditional databases and data warehouses. Unstructured data refers to multimedia data, such as images, sound and video segments or to unstructured textual data. All these types of data are now stored as part of the user‘s business environment. c. Metadata; data. Metadata is data about data, describing the characteristics of data maintained in a data management environment whereas data itself represents characteritics of objects and events in a real-world environment that is meaningful for the users of the data management environment. d. Repository; database. A repository provides centralized storage for all data definitions, data relationships, and other system components, while a database is an organized collection of logically related data. e. Entity; enterprise data model. An entity is an object or concept that is important to the business, while an enterprise data model is a graphical model that shows the high-level entities for the organization and the relationship among those entities. f. Data warehouse; data lake. Both operate at the enterprise level and are used to store data for analytical purposes, but they are organized in a very different way: a data warehouse has a predefined organizing structure and data is carefully curated before it is loaded into a data

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

208

Chapter 1

warehouse, whereas a data lake is fundamentally an unstructured storage space into which data is collected with the intent that it be structured at the time when it is analyzed. g. Personal databases; multi-tiered databases. A personal database is intended for a single user to manage small amounts of data in an efficient manner, and it resides on a personal computing device (such as a laptop or a smart phone). Multi-tiered databases share multiple (sometimes very large numbers of) users. They house the user interface on client devices and the business logic may be maintained on multiple server layers to accomplish the business transactions requested by client devices. h. Systems development life cycle; prototyping. Both are systems development processes. The S DL C is a methodical, highly structured approach that includes many checks and balances.

Consequently, the S DLC is often criticized for the length of time needed until a working system is produced, which occurs only at the end of the process. Increasingly, organizations use more rapid application development (RAD) processes, which follow an iterative process of rapidly repeating analysis, design, and implementation steps until you converge on the system the user wants.

Prototyping is a widely used method within RAD. In prototyping, a database and its applications are iteratively refined through a close interaction of systems developers and users. i. Enterprise data model; conceptual data model. In an enterprise data model, the range and contents of the organizational databases are set. Generally, the enterprise data model represents all of the entities and relationships. The conceptual data model extends the enterprise data model further by combining all of the various user views and then representing the organizational databases using E R diagrams. j. Prototyping; Agile software development. Prototyping is a rapid application development (R AD) method where a database and its application(s) are iteratively refined through analysis, design, and implementation cycles with systems developers and end users. Agile software development is a method that shares an emphasis on iterative development with the prototyping method yet further emphasizes the people and rapidity of response in its process.

1-4.

Five disadvantages of file processing systems:

a. Program-data dependence b. Duplication of data

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

209

c. Limited data sharing d. Lengthy development times e. Excessive program maintenance 1-5.

Differences between transactional and analytical data management approaches.

The main purpose of transactional data management is to enable organizational systems to capture and maintain data regarding events or objects that are important for the operations of the organization (for example, customers, orders, invoices, payments, etc.). These data are organized in a way that focuses on operational efficiency, correctness, and security. In an analytical approach to data management, the focus shifts to organizing data and making it available in a way that supports the use of data for analytical purposes, that is, interpreting the meaning of the data for the purposes of understanding how an organization has operated, how it is likely to operate in the future, and how it should be changed in light of what we know about it.

1-6.

Differences between data warehousing and big data approaches to analytical data management.

In the data warehousing approach to analytical data management, data are stored in specialized storage systems (data warehouses and data marts), after a careful curation and transformation process, such that the data are structured optimally for reporting and analysis purposes based on what the designers of the data warehouse initially anticipated these purposes to be. This approach is often called schema on write. In the big data approach to analytical data management, the data are often stored in structures that are not pre-designed for specific analytical models; instead, the data include descriptions of their structure at a level of individual concept and the large structures are allowed and expected to emerge during the analytical processes. This approach is often called schema on read.

1-7.

Nine major components in a typical database system environment:

a. CASE tools: automated tools used to design databases and database applications. b. Repository: centralized storehouse of data definitions. c. Database management system (DBMS): commercial software used to define, create, maintain, and provide controlled access to the database and the repository. d. Database: organized collection of logically related data.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

210

Chapter 1

e. Application programs: computer programs that are used to create and maintain the database. f. User interface: languages, menus, and other facilities by which users interact with the various system components. g. Data administrators: persons who are responsible for the overall information resources of an organization. h. System developers: persons such as systems analysts and programmers who design new application programs. i. End users: persons who add, delete, and modify data in the database and who request information from it.

1-8.

Relationships between tables:

Relationships between tables are expressed by identical data values stored in the associated columns of related tables in a relational database.

1-9.

Definition of data independence:

Data independence refers to the separation of data descriptions from the application programs that use the data. It is an important goal because it allows an organization‘s data to change and evolve without changing the application programs that use the data. Additionally, data independence allows changes to application programs without requiring changes in data storage structure.

1-10. 10 Potential benefits: Potential benefits of the database approach are:

a. Program-data independence b. Minimal data redundancy c. Improved data consistency d. Improved data sharing e. Increased development productivity f. Enforcement of standards g. Improved data quality

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

211

h. Improved data accessibility and responsiveness i. Reduced program maintenance, and j. Improved decision support.

1-11. Five costs or risks of the database approach are:

a. New, specialized personnel b. Installation, management cost, and complexity c. Conversion costs d. Need for explicit backup and recovery, and e. Organizational conflict.

1-12. Nine key components of a typical database environment See answer to question 1-7; the question was accidentally repeated.

1-13. Difference between Operational and Informational data management systems

The operational data management systems enable and support organizational systems that are intended to allow the organization to operate effectively and efficiently, whereas informational data management systems focus on activities that organize and interpret data in the systems for analytical purposes (for helping organization understand how it could and should change).

1-14. Four perspectives for exploring transactional systems

Modeling – conceptual data modeling with Enhanced Entity-Relationship modeling Design – logical data modeling using the relational model Infrastructure – physical design of relational databases, database security and ownership of data management technologies (including cloud computing) Access to data – SQL and other data manipulation and design languages 1-15. Possibility of no database on a tier of a multi-tiered database?

Yes, it is possible. The client tier — a PC or a mobile client — typically has presentation logic but no database installed on it.

1-16. Difference between enterprise databases and departmental multi-tiered databases

Enterprise databases have an organization-wide focus and they typically support very large scale systems, such as enterprise resource planning (E RP) systems, data warehousing solutions, or

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

212

Chapter 1

data lakes. Departmental multi-tiered database systems enable organizational applications that are important for a specific group of users within organization but that do not serve the whole organization.

1-17. Potential benefits of data lakes compared to other enterprise databases

The key potential benefit of data lakes is their ability to store vast amounts of unstructured data for analytical purposes that are not pre-planned, allowing exploration of issues and questions that were not anticipated at the time when the systems were designed.

1-18. Five SDLC phases:

a. Planning Purpose: To develop a preliminary understanding of the business situation and how information systems might help solve a problem or make an opportunity possible Deliverable: A written request to study the possible changes to an existing system; the development of a new system that addresses an information systems solution to the business problems or opportunities b. Analysis Purpose: To analyze the business situation thoroughly to determine requirements, to structure those requirements, and to select between competing system features Deliverables: The functional specifications for a system that meets user requirements and is feasible to develop and implement c. Design Purpose: To elicit and structure all information requirements; to develop all technology and organizational specifications Deliverables: Detailed functional specifications of all data, forms, reports, displays, and processing rules; program and database structures, technology purchases, physical site plans, and organizational redesigns d. Implementation Purpose: To write programs, build data files, test and install the new system, train users, and finalize documentation

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

213

Deliverables: Programs that work accurately and according to specifications, documentation, and training materials e. Maintenance Purpose: To monitor the operation and usefulness of a system; to repair and enhance the system Deliverables: Periodic audits of the system to demonstrate whether the system is accurate and still meets needs 1-19. Activities and five phases of SDLC?

Database development activities occur in every phase of the S DLC. Actual database development is most intense in the design, implementation, and maintenance steps of the S DLC. 1-20. The impact of an agile methodology on data management:

There are at least two major ways in which the use of an agile methodology affects data management: first, agile processes do not specify requirements in advance, and thus the operational databases have to be designed in ways that allow for rapid change without a negative impact on the quality of the data management solution. At the same time, it is much easier for agile methodologies to maintain their flexibility if they have a solid data modeling foundation within which changes are made and new capabilities enabled.

1-21. Commonalities of SDLC, prototyping, and agile development methodologies:

Procedures and processes that are common to S DLC, prototyping, and agile methodologies include: o Understanding and analyzing the customer‘s business requirements for the system o Translating the customer‘s requirements into specifications (logical & physical) for systems development o Developing databases and software programs to meet specifications; and o Implementing an operational system.

The methodologies are considered to be different not because of what is done, but because the timing of the methodologies differ. The S DLC methodology is methodical and thorough, which

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

214

Chapter 1

makes it well-suited for systems that populate and revise databases. Prototyping, with its rapidly repeating analysis, design, and implementation phases, is well-suited for systems that retrieve data and for helping to refine a customer‘s requirements for a new system. Agile software development emphasizes quick responses and rests on high-involvement from knowledgeable customers. Agile software development is well-suited to projects with unpredictable and/or rapidly changing requirements and responsible developers (per text citation of Fowler, 2005).

1-22. Differences between conceptual schema, user view, and internal schema:

A conceptual schema defines the whole database without reference to how data are stored in a computer‘s secondary memory. A user view (or external schema) is also independent of database technology, but typically contains a subset of the associated conceptual schema, relevant to a particular user or group of users (e.g., an inventory manager or accounts receivable department). An internal schema consists of both a physical schema and a logical schema. A logical schema consists of a representation of the data for a type of data management technology. For example, if the relational model is the technology used, then the logical schema will consist of tables, columns, rows, primary keys, foreign keys and constraints. A physical schema contains the specifications for how data from a logical schema are stored in a computer‘s secondary memory.

1-23. Three-schema architecture:

a. external schema b. conceptual schema c. internal schema 1-24. Phases and activities of SDLC within textbook scenario:

Student answers may vary depending upon whether or not they read the section closely enough to realize that Chris is following a prototyping methodology approach to developing the database application for PVFC. The prototyping methodology is shown in Figure 1-8, while the traditional development approach is shown in Figure 1-7.

According to Figure 1-8, Chris‘ project activities would map to the following phases of the prototyping database development process: Chris’ activities

Prototype phase (and comments)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

Project Planning

Identify Problem (Conceptual Data Modeling) - To some extent, a separate ―planning‖ phase does not really exist under the prototyping approach as it happens continuously as the prototype evolves. On the other hand, the Identify Problem phase involves sketching a preliminary data model, which is work that Chris clearly completes.

Analyzing Database Requirements

Identify Problem (Conceptual Data Modeling) Develop initial prototype (Logical Database Design) - In this stage of Chris‘ work with Helen, he is still gathering iterations of the kinds of data that Helen needs to do her job. In some ways, Chris is refining the Conceptual Data Model and in other ways Chris is developing the more detailed Logical Database Design.

Designing the Database

Develop initial prototype (Logical Database Design, Physical database design and definition, database implementation) - Chris takes the knowledge he has gained from the initial sessions with Helen and begins to build a functioning example of the database in an agreed-upon relational database management system.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

215

216

Chapter 1

Using the Database

Implement and use prototype; Revise and enhance prototype (Database maintenance) - Chris provided enough of a working sample database that Helen could use it and make suggestions about how to revise it.

Chris could iteratively make changes to improve the solution and move some initial ad-hoc queries into more formal reports.

Administering the database

Convert to operational system (Database maintenance) - Chris and Helen agreed that the prototype was functioning efficiently enough to allow it to become the everyday, operational, ―production‖ system for Helen to use. As requested by Helen, and when time allows, Chris is able to make changes to the operational database to better meet Helen‘s needs and requests.

1-25. Why does PVFC need a data warehouse?

Pine Valley Furniture Company (P VFC) uses a database management system to support its operational functions. This database is not, however, structured in a way that supports timely analysis of trends or historical patterns. P VFC can benefit from a data warehouse that is appropriately structured for questions related to vendor pricing and/or customer order patterns over time. A data warehouse would enable PVFC to summarize data drawn from various operational databases (i.e., department, independent applications, and E RP) into meaningful structures for timely decision-making access.

1-26. Three areas where very large databases are used:

Very large databases are being used to improve customer relationship management (C RM) by creating CR M systems that react to individual customers‘ purchase behavior. For example, such a database could be used to suggest other items that a customer may want to purchase based on

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

217

that customer‘s previous purchases. They are also being used to build a foundation for virtual products and services and to understand online users‘ behavior at a detailed level. Online shopping sites are able to carry a large virtual inventory stored in a database for the customer to peruse.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

218

Chapter 1

Solutions to Problems and Exercises 1-27. Examples of relationships: a. Many-to-Many

STUDENT

COURSE

b. One-to-Many BOOK

BOOK COPY

c. One-to-Many COURSE

SECTION

d. One-to-Many ROOM

SECTION

e. Many-to-Many INSTRUCTOR

COURSE

f. Many-to-Many COURSE

SEMESTER

g. Many-to-Many (and an example of a term with multiple meanings) COURSE

MEAL

1-28. Advanced data types have several special requirements:

a. Storage requirements – multimedia objects (such as images, sound, and video clips) require substantial storage capacity, which needs to be justified. b. Content management – this is the problem of storing, locating, and retrieving the multimedia objects. This process requires specialized software not generally available in a relational DBMS

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

219

or extra effort to create a means to rapidly access multimedia objects (such as keyword indexes). c. Maintenance – while conventional relational data are easily updated, multimedia objects may require maintaining multiple versions of the data. Usually the whole object needs to be restored because it is treated as a whole rather than a set of parts.

1-29. Metadata for Class Roster:

Please note that some columns have been omitted in order to save space. Columns ―Created,‖ ―Updated,‖ and ―Responsible Party‖ were added to the metadata.

Name

Type

Description Source

Created

Updated

Responsible Party

Course

Section

Alphanumeric Course ID

Integer

Academic 5/10/2021 6/1/2021

Registrar

and name

Unit

Section

Registrar

5/10/2021

Registrar

Registrar

5/10/2021

Registrar

Student I

8/07/2021

Student IS

8/07/2020

Student IS

number Semester Alphanumeric Semester and year Name

ID

Major

GPA

Alphanumeric Student

Integer

name

S

Student ID

Student I

(SSN)

S

Alphanumeric Student

Decimal

Student I

8/07/2020 11/15/2020 Student IS

major

S

Student

Academic 8/07/2021 5/10/2021

Department

grade point

Unit

Chair

average

1-30. Why do organizations create multiple databases?

There are several reasons. First, because of resource limitations, organizations fund development of their information systems one application at a time. Second, organizations may acquire some of their information systems from outside vendors. This also results in a proliferation of databases. Third, mergers and acquisitions generally result in multiple databases.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

220

Chapter 1

What organizational and personal factors lead an organization to have multiple, independently managed databases?

Perhaps the most common reason is that end users and user groups develop their own database applications, rather than wait for the central I S organization to develop a centralized database.

Also, the pressures associated with rapid business change result in organizations taking a shortterm, suboptimal approach rather than a careful, long-term strategy.

1-31. Data entities and Enterprise Data Model for student-run newspaper:

This is a good in-class, interactive exercise for individuals or small groups. For individuals, have each student choose a student club, fraternity/sorority, or other organization to illustrate a ―topdown‖ approach to developing an enterprise data model. For small groups, divide the class into groups and have each group work to develop an enterprise data model for a club, fraternity/sorority, or other organization. Reconvene as a large class to compare/contrast each of the small group enterprise data models. Identify the similarities and differences through class discussion.

1-32. Data from the driver’s license bureau:

a. Driver‘s name, address, and birthdate: structured data b. The fact that the driver‘s name is a 30-character field: metadata; fact describing property c. A photo image of the driver: unstructured data d. The fact that birth data is stored in BirthDate: metadata e. An image of the driver‘s fingerprint: unstructured data f. The make and serial number of the scanning device that was used to scan the fingerprint: structured data g. The resolution (in megapixels) of the camera that was used to photograph the driver: metadata; fact describing context h. The fact that the driver‘s birth date must precede today‘s date by at least 16 years: metadata; fact describing context i. A 10-second video clip in which the driver states his or her name: unstructured data

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

221

1-33. Great Lakes Insurance database suggestion:

One suggested approach would be to create an enterprise database to contain all information about customers, policies, etc. The need for an enterprise database is clear, since policy information would need to be accessed not just by the sales team but also by the actuarial department and the claims department. For inside agents, access to the database would be through an intranet, utilizing a browser-based application as the front-end. Each outside agent would have a personal database on his or her notebook computer with only information for his or her territory. The personal database would then be synchronized periodically with the enterprise database through the use of an extranet.

1-34. Record Store data model questions:

a. one-to-many b. one-to-many c. If one is added, it is essential that the designer carefully define what the meaning of the new relationship is. It could, for example, mean that the store intends to carry all albums by a specific artist.

1-35. Questions about Figure 1-12 database:

Some common data elements that may be redundant are: Vendor I D, Vendor Name, Vendor Address, Customer ID, Customer Last Name, Customer First Name, Customer Middle Initial, Purchase Order Number, Purchase Order Date.

This duplication may lead to the problem that payments may not be properly matched to vendor orders, or that customer receipts are improperly matched to customer bills. These potential mismatches could cause issues in collection and payment of financial transactions for the organization, and with relationships with customers and vendors.

At a first glance, these duplications appear to violate the principles of the database approach outlined in this chapter. However, the organization may have procedural or system checks-andbalances that periodically audit or synchronize the apparent data duplication throughout the organization in this three-tier scenario. These checks-and-balances are not apparent on this Figure, but if they exist, they might compensate for the apparent violation of database approach principles.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

222

Chapter 1

1-36. Representation of SDLC:

The representation of the systems development life cycle has changed from the original waterfall metaphor. While it is a more compact representation, there are still some problems. For example, it is not purely linear. Also, it is possible to conduct steps in parallel due to time overlaps. One additional problem of a pure S DLC model is the inability to go back from one step to another without completing the entire five-step process; most practical S DLC implementations allow movement between stages in both directions.

1-37. Three additional entities for PVFC:

EMPLOYEE, SUPPLIER, and SHIPMENT might be good examples since all of them represent major categories of data about the entities managed by the organization 1-38. Consider Business Enterprise example: a. Enterprise Data Model

b. Benefits from a multi-tiered architecture for data management?

Considerations for using a multi-tiered architecture: Since much of the data may be updated from a large number of different functions, network traffic will be an issue of crucial

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

223

importance. Processing close to the source data could reduce network traffic. Client technologies, however, can be mixed (desktops, laptops, smart phones, tablets, network computers, information kiosks, etc.) and yet share common data. In addition, you can change technologies at any tier with limited impact on the system modules on other tiers. All this will allow for data consistency and maintaining academic standards — a critical success factor for the academic unit.

1-39. Contrasting database development during conceptual data modeling and logical database design phases:

It is often said that conceptual data modeling is done in a top-down fashion, driven from a general understanding of the business area, not from specific information processing activities. Logical database design approaches database development from two perspectives. First, the conceptual data model is transformed into a standard notation through normalization, based on relational database theory. Then, as each computer program in the information system is designed — including the program‘s input and output formats — a detailed review of the transactions, reports, displays, and inquiries supported by the database is performed. This bottom-up analysis verifies exactly what data are to be maintained in the database and the nature of those data as needed for each transaction, report, and so forth. During logical database design, you combine or integrate the original conceptual data model (more general information) along with the individual user views (more specific information) into a comprehensive design.

1-40. Location of prototype database:

Department databases are often developed in combination by end users, systems professionals working in business units, and central database professionals. A combination of people is necessary since a wide variety of issues must be balanced in the design of shared databases: processing speed, ease of use, differences in data definitions, and the like. Often, the prototype being developed will be located on a development area server, where those involved with the project will have easy access to the database and no likelihood of interfering with the organization‘s production databases. This answer assumes that the organization maintains separate development and production servers for the databases.

1-41. Enterprise data models and conceptual data models:

Enterprise data modeling results in a total picture or explanation of organizational data, not the design for a particular database. A particular database provides the data for one or more information systems, whereas an enterprise data model, which may encompass many databases,

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

224

Chapter 1

describes the scope of data maintained by the organization. Therefore, the level of abstraction associated with an enterprise data model is higher; conceptual data models are more detailed.

1-42. Iteration between physical and logical database design:

Database development activities occur in each of the S DLC phases, and it is not only possible but quite frequent that feedback received during a later stage causes a project to return to a prior phase. SDLC activities may find missing elements or errors when designing specific transactions, reports, displays, and inquiries. When a missing element is noticed, for example, it is necessary to revisit the logical database design.

1-43. User views of organizational data:

A good approach in developing this problem for a bank might be to carefully select the views to be developed by collecting a transaction slip, monthly statement (representing each type of account), statement of earnings, etc. Examples of data included in each message are customer information, bank information, and transaction data (checks, deposits, service charges, maintenance fees, overdraft protection fees, and so forth). Statement and deposit slip views are given below, as is the combined conceptual data model. Combining the different views could lead to the addition of new attributes or possibly entities and relationships not being shown in the original views.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

Statement view:

Deposit slip view:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

225

226

Chapter 1

Conceptual Data Model:

1-44. Explain Figure 1-15:

The single line connection indicates a one-to-one relationship between the entities. In business terms: each order is billed on exactly one invoice, and each invoice is written for only one order.

In contrast, many payments can be made on one order. Remember to model for the exceptions.

1-45. Questions about Project Data Model in Figure 1-16:

a. A Customer places many orders, yet an Order is placed by one Customer. Each Order is billed on a single Invoice, and an Invoice is related to a single Order. Each Payment is related to a single Invoice, but an Invoice may be paid with one or several Payments. Each Order contains multiple Order Lines but a specific Order Line refers to only one Order and one Product at a time. Each Product may be seen on multiple Order Lines. Each Product belongs to only one Product Line and a Product Line includes multiple Products. For each Customer, P VFC tracks the I D, Name, Type, Zip Code and number of years it has been a P VFC customer. For Orders, we track Order number along with each order‘s placement date, fulfillment date, and number of shipments. For Invoices, we track Invoice number, Order number, and Invoice Date. Each Payment tracks the Invoice Number, Payment Date, and Payment Amount. Each Order Line tracks the specific

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

227

quantity of product for the specific order. For Products, we track its I D, description, finish, standard price, product cost, prior year‘s sale goal, and current year‘s sale goal. Each Product Line tracks its name, prior year‘s sales goal and current year‘s sale goal. b. The aspect of the diagram that is difficult to describe (and may also be difficult to implement and maintain) is the sales goal attributes for the Product Lines and Products. Since it is expressed as Prior Year and Current Year values, this data will need to be maintained with additional programming in the database application, as there is currently no logical design to deal with this time-based data in the proposed design. In my opinion, the reason for this ambiguity is that the prototyping approach did not yet experience the maintenance issues of date-related data in the database, due to the shortened time working with the data and sample reports. As the end user and the analyst work through the database application over time, the need for an adjusted design will become painfully clear.

1-46. SQL statements in Figure 1-18 and 1-19 questions:

a. The field size for the ProductLineName field in the Product table may be 1-40 characters. This size is due to the S QL Create Table definition of ProductLineID field being set to 40 characters, with a VARCHAR datatype. b. The ProductID field is specified as NOT NULL in the S QL statement. ProductID is a required attribute because it is designed as the Primary Key of the table, and in relational design Primary Key fields cannot be empty or missing. c. The FOREIGN KEY clause in the S QL statement tells us that the ProductLineID field in the Product_T table refers back to the ProductLineID primary key that is stored in the ProductLine_T table. This FOREIGN KEY clause is the way that referential integrity in a relational database is enforced in the actual physical database. d. The NOT NULL statement ensures that the ProductID will always have a valid value.

1-47. SQL Query in Figure 1-20:

a. SalesToDate is calculated by multiplying the quantity by the price. b. Eliminating ―Home Office‖ from the Criteria line under ProductLineName would result in all product line names being displayed, not just the Home Office line. c. The first three elements of the WHERE clause are used to connect relevant structural elements of

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

228

Chapter 1

two entities with each other to bring data from two tables together (in a so called relational join) whereas the last element of the WHERE clause limits the rows to be included in the answer set based on a specific value of the ProductLineName column (―Home Office‖).

1-48. Figure 1-16 and new Query specification questions:

a. The following entities will be needed: Payment, Invoice, Order, Order Line, Product, Customer b. All of the above entities will be needed for the S QL query.

1-49. Summary of important properties of data models: Blank

All Entities?

All

Technology

DB MS

Record

Attributes?

Independent? Independent? Layouts?

Enterprise

Y

N

Y

Y

N

Conceptual

Y

Y

Y

Y

N

Logical

Y

Y

N

Y

Y

Physical

Y

Y

N

N

Y

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

229

Suggestions for Field Exercises 1-50.

You can accomplish this exercise either by arranging a field trip for your class (preferred), or by inviting the IS manager (or other key I S person) to visit your class. Following are some of the key steps to perform: a. Select an organization. We suggest a mid-sized manufacturing company or a familiar organization in the service sector such as a hospital or bank. b. Identify several mainstream applications such as human resource management, material requirements planning, and financial accounting. c. Determine whether these applications were predominantly developed internally, or purchased from an outside vendor or vendors. d. Now determine the mix between file processing and database processing for these applications. If a database approach is used, is the data shared among the applications? e. To draw a figure depicting the files and databases, inquire whether the organization has system flowcharts (or similar documentation) that portray much of this information.

1-51.

This exercise is most easily performed as a continuation of Exercise 1. Arrange to interview a database administrator or key designer as part of the same field trip. Discuss whether the organization maintains user-oriented metadata, or only technical metadata. Where is this metadata maintained: within individual applications, in one or more CASE tool repositories, or elsewhere?

1-52.

If the student has selected an established company with a fairly extensive information systems department, they will find that the company is either already very involved in Web-enabling some or many parts of their business, or that they are actively planning to expand the scope of their involvement. You may want to encourage your students to use this question to explore where the company sees itself going with regard to the Internet. Many older companies are struggling very hard to adjust and remain competitive as the Internet dramatically affects business models.

1-53.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

230

Chapter 1

Again, as in the previous field exercise, this exercise will help students to integrate their new textbook knowledge with the realities that organizations must face. Some students will find organizations that are struggling to achieve client/server architecture and also deal with their legacy systems, for example.

1-54.

Students will probably find prototyping being used for smaller database applications. Prototyping is often the systems development methodology of choice where visual programming tools such as Visual Basic, Java, Visual C++, and fourth-generation languages are used because of the ease with which the user-system interface can be modified. Large systems that require a new database are more likely to use the S DLC, requiring a team of information systems professionals, including database designers and programmers. The systems development process for Web applications can be similar, with prototyping being employed. However, students may find that there is a lot more testing involved with Web applications, since one has less control over the client interface.

1-55.

Students are likely to find some of the following roles on the information systems development teams in larger organizations: a. Systems analysts, who analyze the business situation and identify the need for information and information services to meet the problems or opportunities of the business b. Database analysts, who concentrate on determining the requirements and design for the database component of the information system c. Users, who provide assessment of their information needs and monitor appropriateness of the developed system d. Programmers, who design and write computer programs that have embedded in them commands to maintain and access data in the database e. Database and data administrators, who have responsibility for existing and future databases and ensure consistency and integrity across databases; as experts on database technology, they provide consulting and training to other project team members f. Other technical experts, with facility in networking, operating systems, testing, and documentation

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1

231

g. A senior systems or database analyst, who will be assigned to be project leader, who is responsible for creating detailed project plans as well as staffing and supervising the project team; this good project leader will possess leadership, management, customer relations and communications, technical problem solving, conflict management, team building, and risk and change management skills. h. In smaller organizations, students may find that these roles are combined and performed by fewer people because the smaller organizations do not have the additional staff to assign to a diverse team. Thus, fewer people will cover these same functional responsibilities by each person having multiple roles to fulfill. Many employees in small organizations develop deep skill sets in programming, data administration, or technical database administration expertise.

1-56.

Note: See chapter section on ―Managing the people involved in database development‖ for more background on this exercise.

If a CASE tool is being used, a repository stores descriptions of the data entities and the business rules, detailed descriptions of C SFs, and objectives. The information systems department analyzes all of them. Throughout the systems development process, CASE tools are used to develop data models and to maintain (in the repository) the metadata for the database and applications. A repository maintains all of the documentation too. Various people might use the CASE tools and associated repository during a database development project: systems analysts, database analysts, users, programmers, database and data administrators, and other technical specialists. As a significant new portion of a project is completed and entries are made in the repository, a review point occurs so that those working on the project and funding the human and capital resources of the project can assess progress and renew commitment based on incremental achievements.

1-57.

Student answers will vary depending on the organization and the functional area chosen for the interview. As long as students are encouraged to contact individuals in larger or corporate environments, answers should reflect a variety of approaches to retrieving data, kinds of systems accessed for data retrieval, frequencies of data retrieval, levels of satisfaction with data access and retrieval, and challenges experienced. This would be a good exercise to assign for out-ofclass investigation, and then use in-class time for students to meet in small groups to share their

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

232

Chapter 1

results with one another. A subsequent large-group discussion led by the instructor can readily illustrate the different experiences and raise student awareness of the diversity in organizational approaches to data storage, access, and retrieval.

1-58.

Student answers will vary.

Project Questions 1-59. Initial Analysis Memo

a. Approach to addressing the problem There is obviously no one right solution to this question, and it does not make sense to provide a solution that would suggest that there is. The students should, however, discuss the following types of issues: 

FAME does not seem to have any computing-based solutions beyond personal productivity software, and they do not have any specialized I T personnel (and have no appetite to hire anybody). Any solution they will adopt needs to take this into account: heavy infrastructure or support requirements would, in all likelihood, make a specific approach impossible immediately.



It appears that the solution could quite well be designed following an agile, iterative process.

There are a number of elements of the system that can be implemented independently and as long as the data management architecture is (at least tentatively) designed in advance, the independent components can be integrated over time. Thus, suggesting a development model that is based on a set of time-boxed iterations is reasonable.



It is important to discuss the ways in which the development process would interact with ongoing operations of FAME and allow FAME to continue to operate normally while the new system is being developed.



The students should address the question of ownership of the required infrastructure resources. Would it make any sense for FAME to own its own hardware and system software infrastructure? It seems that an Infrastructure as a Service (IaaS) or Platform as a service (PaaS) solution would work well here.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1



233

The memo should address the ―buy v s build‖ question: why should FAME have this system ers u

built instead of buying it from a vendor? The students should do at least initial research on existing systems in this space and their suitability for FAME. b. Accomplishments, organizational goals, and functionality 

The new system would 

Reduce errors in contracts, scheduling, and billing



Make information regarding artist availability centralized and more readily available for everybody, thus allowing faster decisions



Automate processes that have legal implications (such as those related to making tax payments on behalf of artists)



Provide better data regarding the performance of various aspects of the FAME organization and enable more effective planning.



Make it possible to speed up the business processes, at least theoretically, allowing FAME to get the artists paid faster



Make it easier for the artist managers to review recommendations and other information regarding prospective artists.



The system would perform the following functions (at later stages of development): 

Artist scheduling



Performance billing



Accounts receivable



Accounts payable, including artist payments and payments to third parties



Contract creation, management, and renewals



Prospect review and management



Support for marketing systems.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

234

Chapter 1

The system would help FAME serve its event organizer clients better and thus, provide its artists better and more frequent performance opportunities, and increasing FAME‘s commissions. c. Key benefits 

Reduced errors in scheduling



Reduced errors and faster speed of billing



Higher level of accuracy in government payments



Reduced errors in accounts receivable management



Faster payments to the artist



Better management of artists‘ and artist managers‘ expenses



Better negotiation position for FAME in conversations with event organizers



Faster access to high-quality prospects



Reduced risk of lapsed contracts



Direct support for marketing communication systems.

d. Timeline / roadmap 

The answer to this question depends on how the project is framed to the students. Our recommendation is that you frame the project in the context of your semester, using real time constraints.

e. Possible questions for Mr. Forondo 

Are there aspects of the proposed system that are not articulated in the written description?



How would he define the priorities between the various functionalities and potential benefits of the system?



Determine whether or not Mr. Forondo has a reasonable idea of the cost of developing such a system from scratch and if he is willing to pay.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 1



235

Who are the key stakeholders your team should approach during the requirements specification phases? Who are most likely to be against the plans to develop a new system?



What are FAME‘s growth targets and what impact they will have on the system?



Are there any particular risks Mr. Forondo is specifically worried about?

1-60. Enterprise Data Model

Please see the following page for the response to this question.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

200

Chapter 2

Question 1-60 Figure 1 Chapter 2 Modeling Data in the Organization

Chapter Overview The purpose of this chapter is to present a detailed description of the entity-relationship model and the use of this tool within the context of conceptual data modeling. This chapter presents the basic entityrelationship (or E-R) model. Advanced features of conceptual data modeling will follow in Chapter 3.

Chapter Objectives Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

201

Specific student learning objectives are included in the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Emphasize the importance of understanding organizational data and convince your students that unless they can represent data unambiguously at the conceptual level, they cannot implement a database that will effectively serve the needs of various organizational stakeholder groups.

2. Present the E-R model as a conceptual data model that can be used to capture the structure and much, although not all, of the semantics (or meaning) of data.

3. Apply E-R modeling concepts to several practical examples including the Pine Valley Furniture Company case.

Key Terms Associative entity Attribute Binary relationship Business rule Cardinality constraint Composite attribute Composite identifier Degree Derived attribute Entity Entity instance Entity-relationship diagram (E-R diagram)

Entity-relationship model (ER model) Entity type Fact

Relationship type

Identifier Identifying owner Identifying relationship Maximum cardinality Minimum cardinality Multivalued attribute Optional attribute Relationship instance

Strong entity type Term Ternary relationship Time stamp Unary relationship Weak entity type

Blank

Blank

Required attribute Simple (or atomic) attribute

Blank

Blank

Classroom Ideas 1. Review the major steps in the database development process (Figure 1-8) and highlight the importance of data modeling in determining the overall data requirements of information systems.

Lead a discussion regarding the actors within an organization that typically are most heavily involved in each of the steps and how end users may best participate in the process.

2. Introduce the concept of drawing models to represent information in a concise manner by having your students participate in a small active exercise in map-making. Divide the students into teams of

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

202

Chapter 2

three or four students each so that you have an even number of teams in the class. Instruct each team to work together to investigate and develop a map to selected campus locations (you develop the list ahead of time; e.g., from this classroom to the library, from this classroom to a colleague‘s office, etc.). Ask each team to verify the map they draw and then return to the classroom. Pair up each team with a unique location with another team; ask the teams to exchange maps. Instruct each team to then verify the map they received by following it and then returning to the classroom.

Conduct a debriefing discussion about how easy/hard it was to follow the maps, how useful were the symbols used, how easily understood were the symbols, etc. Use this discussion to lead into the use of E-R notation used to represent data models and why standardization is useful to systems development activities.

3. Use the sample E-R diagram shown in Figure 2-1 to introduce the first conceptual model to your students. Ask them to explain the business rules represented in this diagram.

4. Use Figure 2-2 to summarize the basic E-R notation used in this chapter and throughout the remainder of the text.

5. Contrast the terms entity type and entity instance (see Figure 2-3). Discuss other examples: STUDENT with each student in the classroom as an instance, etc. Warn the students that the term ―entity‖ is often used to denote either an entity type or an entity instance; the meaning is intended to come from the context in which it is used.

6. Give examples of common errors in E-R diagramming, including inappropriate entities (see Figure 24). Ask your students for other examples.

7. Compare strong versus weak entities using Figure 2-5. Ask your students for other examples.

8. Discuss the various types of attributes that are commonly encountered (Figures 2-7 through 2-9).

Again, ask your students to think of other examples.

9. Make sure your students understand the difference between relationship types and relationship instances (Figure 2-10).

10. Introduce the notion of an associative entity by using Figure 2-11. Discuss the four reasons (presented in the text) for converting a relationship to an associative entity.

11. Discuss unary, binary, and ternary relationships (Figure 2-12). Have the students brainstorm at least two additional examples for each of these relationship degrees.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

203

12. Discuss the bill-of-materials unary relationship (Figure 2-13). Use a simple and familiar product (such as a toy) to illustrate this essential structure, which is often difficult for students to understand.

13. Introduce the concept and notation of cardinality constraints in relationships (Figures 2-16, 2-17, and 2-18). Emphasize that these constraints are important expressions of business rules.

14. Introduce the problem of representing time dependent data. Use Figures 2-19 and 2-20 to illustrate different means of coping with time dependencies.

15. Discuss examples of multiple relationships between entities (Figure 2-21). Ask your students to suggest other examples.

16. Use the diagram for Pine Valley Furniture Company (Figure 2-22) to illustrate a more comprehensive E-R diagram. Stress that in real-world situations, E-R diagrams are often much more complex than this example.

17. As time permits, have your students work in small teams, two or three students each, to solve some of the E-R diagramming tasks in the Problems and Exercises section of the chapter. We have included a number of new examples for this purpose. Also, you may assign the project case as a homework exercise.

Answers to Review Questions 3 - Define each of the following terms: a. Entity type. A collection of entities that share common properties or characteristics b. Entity-relationship model. A logical representation of the data for an organization or for a business area c. Entity instance. A single occurrence of an entity type d. Attribute. A property or characteristic of an entity type that is of interest to the organization e. Relationship type. A meaningful association between (or among) entity types f. Strong entity type. An entity type that exists independently of other entity types g. Multivalued attribute. An attribute that may take on more than one value for a given entity instance h. Associative entity. An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

204

Chapter 2

i. Cardinality constraint. Specifies the number of instances of one entity that can (or must) be associated with each instance of another entity j. Weak entity. An entity type whose existence depends on some other entity type k. Identifying relationship. The relationship between a weak entity type and its owner l. Derived attribute. An attribute whose values can be calculated from related attribute values m. Business rule. A statement that defines or constrains some aspect of the business 3 - Match the following terms and definitions: i

composite attribute

d

associative entity

b

unary relationship

j

weak entity

h

attribute

m

entity

e

relationship type

c

cardinality constraint

g

degree

a

identifier

f

entity type

k

ternary

l

optional attribute

3 - Contrast the following terms: a. Stored attribute; derived attribute. A stored attribute is one whose values are stored in the database, while a derived attribute is one whose values can be calculated or derived from related stored attributes.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

205

b. Minimum cardinality; maximum cardinality. A minimum cardinality specifies the minimum number of instances of one entity associated with an instance of the related entity (typically zero or one), whereas a maximum cardinality specifies the maximum number of such instances. c. Entity type; relationship type. An entity type is a collection of entity instances that share common properties or characteristics, while a relationship type is a meaningful association between (or among) entity types. d. Strong entity type; weak entity type. A strong entity type is an entity that exists independently of other entity types, while a weak entity type depends on some other entity type. e. Degree; cardinality. The degree (of a relationship) is the number of entity types that participate in that relationship, while cardinality is a constraint on the number of instances of one entity that can (or must) be associated with each instance of another entity. f. Required attribute; optional attribute. A required attribute must have a value for each entity instance, whereas an optional attribute may not have a value for every entity instance. g. Composite attribute; multivalued attribute. A composite attribute has component parts that give meaning, whereas a multivalued attribute may take one or more values for an entity instance. h. Ternary relationship; three binary relationships. A ternary relationship is a simultaneous relationship among the instances of three entity types and often includes attributes unique to that simultaneous relationship.

Three binary relationships reflect the three two-way relationships between two entity types, and do not depict the same meaning as a ternary relationship.

3 - Four reasons underlying the importance of data modeling: a. The characteristics of data captured during data modeling are crucial in the design of databases, programs, and other system components. Facts and rules that are captured during this process are essential in assuring data integrity in an information system. b. Data, rather than processes, are the most important aspects of many modern information systems and hence, require a central role in structuring system requirements. c. Data tend to be more stable than the business processes that use the data. Thus, an information system that is based on a data orientation should have a longer useful life than one based on a process orientation. d. Data modeling facilitates interaction between designers, programmers, and end users.

3 - Four reasons underlying the preference for the business rules approach: a. Business rules are a core concept in an enterprise since they are an expression of business policy, and they

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

206

Chapter 2

guide individual and aggregate behavior. Well-structured business rules can be stated in a natural language for end users and in a data model for system developers. b. Business rules can be expressed in terms that are familiar to end users. Thus, users can define and then maintain their own rules. c. Business rules are highly maintainable: they are stored in a central repository and each rule is expressed only once, then shared throughout the organization. d. Enforcement of business rules can be automated through the use of software that can interpret the rules and enforce them using the integrity mechanisms of the database management system.

3 - Where can you find business rules?

Business rules appear in descriptions of business functions, events, policies, units, stakeholders, and other objects. These descriptions can be found in interview notes from individual and group information systems requirements collection sessions, organizational documents, and other sources. Rules are identified by asking questions about the who, what, when, where, why, and how of the organization.

3 - Six general guidelines: a. Data names should relate to business, not technical characteristics. b. Data names should be meaningful, almost to the point of being self-documenting. c. Data names should be unique from the name used for every other distinct data object. d. Data names should be readable. The names should be structured in a way that is consistent with how the concepts would most naturally be said. e. Data names should be composed of words taken from an approved list. f. Data names should be repeatable, meaning that different people or the same person at different times should develop exactly or almost the same name.

3 - Four criteria: a. Choose an identifier that will not change its value over the life of each instance of the entity type. b. Choose an identifier such that for each instance of the entity the attribute is guaranteed to have valid values and not be null (or unknown).

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

207

c. Avoid the use of so-called intelligent identifiers (or keys), whose structure indicates classifications, locations, and so on. d. Consider substituting single-attribute surrogate identifiers for large composite identifiers.

3 - Why some identifiers must be composite rather than simple?

An identifier attribute is an attribute (or combination of attributes) whose value distinguishes individual instances of an entity type. Often, a simple attribute will not be unique for all instances of an entity type (e.g., FlightNumber for an instance of an airline flight). Rather, a combination of simple attributes will be needed to uniquely identify the entity instance (e.g., Flight ID and FlightDate would make the instance unique).

Please note that you can always create a surrogate key that is guaranteed to have a unique value.

3 - Three conditions for an associative entity type: a. All of the relationships for the participating entity types are ―many‖ relationships. b. The resulting associative entity type has independent meaning to end users, and it preferably can be identified with a single-attribute identifier. c. The associative entity has one or more attributes in addition to the identifier.

3 - Four types of cardinality constraints: a. Optional one:

b. Mandatory one:

c. Optional many:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

208

Chapter 2

d. Mandatory many:

3 - Example of weak entity: Phone Call (see below) is an example of a weak entity because a phone call must be placed by a PERSON and thus, an instance of PHONE CALL cannot exist without an instance of PERSON. In this simple example, PHONE CALL is related to only one other entity type. Thus, it is not necessary to show the identifying relationship; however, if this data model were ever expanded so that PHONE CALL related to other entity types, it is good practice to always indicate the identifying relationship.

3 - Degree of relationship definition & examples: The degree of a relationship is the number of entity types that participate in the relationship. a) Unary (one entity type):

b) Binary (two entity types):

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

209

c) Ternary (three entity types):

3 - Attribute examples: a. Derived – Distance (rate × time); both rate and time could be stored, and then when the data is retrieved from the database (e.g., at run-time) the distance could be calculated from the already-stored data elements b. Multivalued – spoken language; a person can speak more than one language c. Atomic – Social Security Number; this United States National Identification number cannot be broken down into component parts d. Composite – Phone Number; a phone number is often broken down into country code, area code, and the rest of the phone number e. Composite identifier – Flight ID could consist of Flight Number and Flight Date, together forming a unique identifier for an airline flight. f. Optional – Middle Initial; a person‘s middle initial may be optional for identification purposes or also because some people may not have a middle name 3 - Examples of relationships: (a) Ternary

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

210

Chapter 2

The sale of a property is a simultaneous relationship among the PROPERTY, a BUYER, and an OWNER entity types. This ―event‖ cannot be modeled appropriately with three binary relationships; any one of the three binary relationships (PROPERTY-BUYER; BUYER-OWNER; and PROPERTY-OWNER) is missing an essential element of the sale. (b) Unary

In an on-campus dormitory/apartment situation, this diagram shows a recursive/unary relationship among instances of the STUDENT entity type. This notation indicates only the current roommate situation between instances of the STUDENT entity type.

3 - Effective (or effectivity) dates: Effective (or effectivity) dates are used in a data model when the organization wishes to record historical data, rather than just the current instance. A few examples might include the effective date of a product price or service rate. Another example might be the start and end date of an advisor‘s assignment to work with a student at a university (see E-R segment below, which includes a multivalued composite attribute Advisor).

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

211

3 - Rule for moving attribute to another entity type: A data modeler should consider extracting an attribute from one entity type and placing it in another entity type linked by a relationship when the attribute is the identifier or some other characteristic of an entity type in the data model, and multiple entity instances need to share these same attributes.

3 - Special guidelines for naming relationships: o

A relationship name should always be a verb phrase and should state the action taken, as opposed to the result of the action taken.

o

Use descriptive, powerful verb phrases as opposed to vague names.

3 - The relationship definition should also explain the following: a. any optional participation b. the reason for any explicit maximum cardinality c. any mutually exclusive relationships d. any restrictions on participation in the relationship e. the extent of history that is kept in the relationship f. whether an entity instance involved in a relationship instance can transfer participation to another relationship instance 3 - Manages relationship in Figure 2-12a: Presently, the cardinality is one-to-many. One possible scenario is an employee who is supervised by more than one manager. This would make the cardinality many-to-many. Another possibility (although quite rare in practice) is that the employee is supervised by one manager, and the manager only supervises one employee. This would result in a one-to-one cardinality. If we take time/history into consideration, the idea of someone being managed currently versus never being managed could affect the cardinality. As we can

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

212

Chapter 2

see here, you cannot always tell what the business rule is by looking at the ERD. These possible scenarios will need to be discussed with the end user to determine the ―correct‖ modeling representation for the business rules at this organization.

3 - Entity type v s Entity instance: ersu

An entity type can be thought of as a template, defining all of the characteristics of an entity instance. For example, ―student‖ would be an entity type, whereas you are an instance of ―student.‖ 3 - Conversion of ternary relationship into an associative entity: Converting a ternary relationship into an associative entity is recommended for two main reasons: (1) research has shown that participation/cardinality constraints cannot be accurately represented for a ternary relationship with current notation; and (2) most E-R diagramming tools cannot represent ternary relationships. By converting a ternary relationship into an associative entity with three mandatory binary relationships, a data modeler can accurately represent the participation/cardinality constraints although there is a risk that the meaning/semantics of the original ternary relationship will be lost with this solution.

Answers to Problems and Exercises 3 - Cellular Operator Database Figure 2-24 questions: a. Can a customer have an unlimited number of plans?

Yes. A Customer may be responsible for 0, 1, or many Plans. b. Can a customer exist without a plan?

Yes. The minimum cardinality of the Belongs relationship from the Customer to the Plan states that a Customer may exist without a Plan (the minimum cardinality is 0). c. Is it possible to create a plan without knowing who the customer is?

No. The minimum cardinality of both the ―responsible for‖ and ―belongs‖ relationships between Plan and Customer states that at least one Customer must be related to a Plan. d. Does the operator want to limit the types of handsets that can be linked to a specific plan type?

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

213

Yes, the cellular operator requires that a Handset (that is a particular type and a particular operating system) is linked to one Plan (that is a particular type of plan). This business rule is to be implemented in this design by indirectly requiring that a Plan Type has 0:M Plans, and each Plan is associated with certain Handsets, and each Handset is of some Handset Type. A given Plan Type is related to Handset Type through the intermediary entity types in this design.

[Alternative interpretation: No, there is nothing in the current model that creates a condition that would limit – in advance – the handset types that can be related to a specific plan type.] e. Is it possible to maintain data regarding a handset without connecting it to a plan?

Yes. The minimum cardinality of the Includes relationship between Plan and Handset states that a Handset may be included in 0 or 1 plan. The 0 minimum cardinality means that we can track data about the handset even if it is not connected to a plan; the Handset has optional participation in the Includes relationship with Plan. f. Can a handset be associated with multiple plans?

No. The minimum cardinality of the Includes relationship between Plan and Handset states that a Handset may be included in 0 or 1 plan, not multiple plans. g. Assume a handset type exists that can utilize multiple operating systems. Could this situation be accommodated within the model included in Figure 2-24?

No. The current model shows that a handset type is associated with one and only one operating system. h. Is the company able to track a manufacturer without maintaining information about its handsets?

Yes. The minimum cardinality of the relationship between Manufacturer and Handset Type indicates that we can track data about a Manufacturer even if we have no (or zero) Handset Types in our database. i. Can the same operating system be used on multiple handset types?

Yes. The maximum cardinality on the relationship between Operating System and Handset Type indicates that an Operating System may be used on 0, 1, or many Handset types. j. There are two relationships between Customer and Plan. Explain how they differ.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

214

Chapter 2

The Responsible For relationship is an overall 1:M relationship between Customer and Plan. A Customer can be responsible for 0, 1, or many Plans yet any one Plan will be linked to only 1 Customer for responsibility purposes. The Belongs relationship is an overall M:M relationship that permits the linking of multiple customers to a single plan, as in the case of family members being part of a particular plan or different plans. k. Characterize the degree and the cardinalities of the relationship that connects Customer to itself. Explain its meaning.

The ―Family Member‖ relationship that connects Customer to itself has a degree of 1 (unary). It permits the tracking of each family member as a Customer. Any Customer may be a Family Member of 0, 1, or many Customer(s); as a Family Member Customer, the Customer may be linked to 0 or 1 Customer. l. Is it possible to link a handset to a specific customer in a plan with multiple customers?

No, this is not possible according to the current model. However, the current model could be adjusted to create an Associative Entity to track the particular Customer instance with a particular Plan instance that is then associated with a particular Handset. This suggested extension to the current model also permits a design that will easily extend the database‘s ability to track additional data about the particular Customer instance with a particular Plan instance. m. Can the company track a handset without identifying its operating system?

No. The minimum cardinality of the relationship between Handset Type and Operating System is 1 and only 1; the minimum of 1 is a mandatory participation for the Handset Type with the Operating System.

3 - For each of the descriptions below, perform the following tasks: i) Identify the degree and cardinalities of the relationship. ii) Express the relationships in each description graphically with an E-R diagram. a)

A book is identified by its ISBN, and it has a title, a price, and a date of publication. It is published by a publisher, each of which has its own ID number and a name. Each book has exactly one publisher, but one publisher typically publishes multiple books over time. (i)

This relationship is a degree of 2 (binary). This relationship is one-to-many from Publisher to Book.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

215

(ii)

Note: This solution assumes that we have a reason to track a Publisher even if it does not yet have a Book published. b)

A book (see above in (a)) is written by one or multiple authors. Each author is identified by an author number and has a name and date of birth. Each author has either one or multiple books; in addition, occasionally data are needed also regarding prospective authors who have not yet published any books. (i) This relationship is a degree of 2 (binary). This relationship is many-to-many from Author to Book. (ii)

a)

In the context specified above in (a) and (b), better information is needed regarding the relationship between a book and its authors. Specifically, it is important to record the percentage of the royalties that belong to a specific author, whether or not a specific author is a lead author of the book, and each author‟s position in the sequence of the book‟s authors. (i) This relationship is a degree of 2 (binary). This relationship is many-to-many from Author to Book. (ii)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

216

Chapter 2

b)

A book (see (a) above) can be part of a series, which is also identified as a book and has its own ISBN number. One book can belong to several sets and a set consists of at least one but potentially many books. (i) This relationship is a degree of 1 (unary). This relationship is many-to-many. (ii) This solution assumes that “series” and “sets” are synonymous terms. The question does not require that a series have any special attributes or distinguishing features, so it can be represented in the data model like any other Book instance and identified by ISBN.

a. Ebony and Ivory, a piano manufacturer, wants to keep track of all the pianos it makes individually. Each piano has an identifying serial number and a manufacturing completion date. Each instrument represents exactly one piano model, all of which have an identification number and a name. In addition, the company wants to maintain information about the designer of the model. Over time, the company often manufactures thousands of pianos of a certain model, and the model design is specified before any single piano exists. (i) These relationships have a degree of 2 (binary). These relationships are one-to-many. (ii)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

217

b. Ebony and Ivory (see (e) above) employs piano technicians who are responsible for inspecting the instruments before they are shipped to the customers. Each piano is inspected by at least two technicians (identified by their employee number). For each separate inspection, the company needs to record its date and a quality evaluation grade. (i) This relationship is a degree of 2 (binary). This relationship is many-to-many. (ii)

a. The piano technicians (see (f) above) have a hierarchy of reporting relationships: some of them have supervisory responsibilities in addition to their inspection role and have multiple other technicians report to them. The supervisors themselves report to the chief technician of the company. (i) This relationship is a degree of 1 (unary). This relationship is one-to-many. (ii) Because the chief technician is not represented as a separate entity type, that person does not have a supervisor. This, in turn, leads to the 0 minimum cardinality on the 1 side of the unary relationship.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

218

Chapter 2

b. Chiclets Electronics (CE) builds multiple types of tablet computers. Each type has a type identification number and a name. The key specifications for each type include amount of storage space and display type.

The company uses multiple processor types, exactly one of which is used for a specific tablet computer type; obviously, the same processor can be used in multiple types of tablets. Each processor has a manufacturer and a manufacturer‟s unique code that identifies it. (i) This relationship is a degree of 2 (binary). This relationship is many-to-many. (ii)

a. Each individual tablet computer manufactured by CE (see (h) above) is identified by the type identification number and a serial number that is unique within the type identification. The vendor wants to maintain information about when each tablet is shipped to a customer. (i) These relationships are a degree of 2 (binary). These relationships are one-to-many. If, over time, shipment of a tablet computer to multiple customers (e.g., as in a refurbished unit) is possible, the Tablet Computer – Customer relationship would become many-to-many and the Shipping Date attribute would become an attribute of that M:N relationship. (ii)

b. Each of the tablet computer types (see (h) above) has a specific operating system. Each technician the company employs is certified to assemble a specific tablet type – operating system combination. The validity of a certification starts on the day the employee passes a certification examination for the combination, and the certification is valid for a specific period of time that varies depending on tablet type

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

219

– operating system combination. (i) This relationship is a degree of 2 (binary). This relationship is many-to-many. (ii) Based on the limited situation description, it appears that there is no need to model a separate entity type for Operating System. If the situation required additional data about the Operating System and the Technician’s certification for this element, the diagram would need to be revised accordingly.

3 - Each answer refers to Figure 2-22 found in the chapter text. a. Where is a unary relationship, what does it mean, and for what reasons might the cardinalities on it be different in other organizations?

A unary relationship is shown with the EMPLOYEE entity; An EMPLOYEE Supervises 0:M EMPLOYEEs, An EMPLOYEE Is Supervised By 0:1 EMPLOYEE. This relationship tells us that we can determine which employees are supervised by another employee, as well as determine which employees are supervisors in this company.

In other organizations, there may be different policies regarding employee supervision that could cause the data relationships among EMPLOYEE instances to be different. For instance, another company might allow an employee to have multiple supervisors (e.g., in an organization with a matrix structure). b. Why is Includes a one-to-many relationship and why might this ever be different in some other organization?

Includes is a one-to-many (1:M) relationship because of the business rules that PVFC has in place: ―a product line may group any number of products but must group at least one product; and each product must belong to exactly one product line.‖ Another organization may have other business rules that could permit a product being assigned to more than one product line (changing Includes to a M:N relationship).

Alternatively, another organization might also show Includes as a (1:M) overall relationship but might

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

220

Chapter 2

permit the establishment of a PRODUCT LINE without identifying PRODUCTs that belong to this group (e.g., thus permitting an optional minimum cardinality on the PRODUCT side of the Includes relationship). c. Does Includes allow for a product to be represented in the database before it is assigned to a product line (e.g., while the product is in research and development)?

No, Figure 2-22 shows that the PRODUCT must be Included in at least 1 PRODUCT LINE by the mandatory 1 and only 1 cardinality notation near the PRODUCT LINE portion of the Includes relationship line. The cardinality notation would have to be changed to show optional 1 cardinality in order to represent the research and development situation. d. Suppose there is a rating of the competency for each skill an employee possesses, where in the data model would we place this rating?

The Has Skill associative entity, which associates a single instance of a SKILL with a single instance of an EMPLOYEE, would permit the tracking of a competency rating for each skill in which an employee has competence. e. What is the meaning of the DOES BUSINESS IN associative entity and why does each DOES BUSINESS IN instance have to be associated with exactly one TERRITORY and CUSTOMER? The DOES BUSINESS IN associative entity associates a single instance of a TERRITORY with a single instance of a CUSTOMER for the overriding M:N DOES BUSINESS IN relationship between TERRITORY and CUSTOMER. Each DOES BUSINESS IN instance must be related to exactly one TERRITORY and one CUSTOMER because the business rules of PVFC indicate that sales territories have been established for its customers. In particular, the rules are: a TERRITORY has one-to-many CUSTOMERs; and a CUSTOMER may do business in 0:M TERRITORIES. When converting this M:N relationship on the ERD, the cardinalities near the originating entities will always be mandatory one, indicating the exactly one relationship with each entity‘s instances and the associative entity‘s instance. f. In what way might Pine Valley change the way it does business that would cause the Supplies associative entity to be eliminated and the relationships around it to change?

According to current business practice at PVFC, each RAW MATERIAL is provided by 1 or more VENDORs and a VENDOR supplies 0, 1, or many RAW MATERIALs and this is represented by the Supplies associative entity. The PVFC could consider entering into exclusive supplier arrangements with

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

221

particular vendors such that an instance of RAW MATERIAL is supplied by only 1 VENDOR. If that situation should occur, then the overall relationship between RAW MATERIAL and VENDOR would change to 1:M (instead of M:N) and the Supply Unit Price attribute could become part of the RAW MATERIAL entity instance; the Supplies associative entity would no longer need to be on the ERD. 3 - Analysis of Figure 2-22: a. Entities PRODUCT, PRODUCT LINE; relationship Includes b. Entities CUSTOMER, ORDER; relationship Submits c. Entities ORDER, PRODUCT; associative entity ORDER LINE d. Entities CUSTOMER, TERRITORY; associative entity DOES BUSINESS IN e. Entities SALESPERSON, TERRITORY; relationship Serves f. Entities PRODUCT, RAW MATERIAL; relationship Uses g. Entities RAW MATERIAL, VENDOR; relationship Supplies h. Entities WORK CENTER, PRODUCT; associative entity PRODUCED IN i. Entities EMPLOYEE, WORK CENTER; associative entity WORKS IN j. Entity EMPLOYEE; relationship Supervises, Is Supervised By 3 - Use of CASE or drawing tool: Student answers will vary based on the CASE or drawing tool that is used and their personal experiences.

The answers should describe their experiences with the CASE or drawing tool in terms of the requirements of the E-R notation used in the chapter. Expect to see students make reference to noting identifiers, using associative entities, using cardinality constraints properly, indicating required v s optional attributes, and ersu

noting derived/composite/multivalued attributes.

3 - ER diagrams in Figure 2-25: a. The ERD for City B does not (nor does any ERD) tell us why the cardinality is 1:M. The more restrictive cardinality for City B could be due to a business rule that they want to maintain only current volunteers but it could also be due to only tracking the agency for which the volunteer works the most hours of assistance.

More detailed discussions would need to be held with the end users to properly document this business rule;

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

222

Chapter 2

notes should be added to the diagram to depict the appropriate business rule. b. The ERD for City A shows that a volunteer may assist one, none, or several agencies. c. The native notation used in ERDs does not show whether membership in a relationship can change (i.e., whether a volunteer can change agencies or whether an agency can change its volunteers). Some DBMSs can be told whether membership can change or not, and special notation or textual notes can be added to an ERD to state such business rules. The minimum cardinality next to Agency does address whether a Volunteer must always be associated with an Agency to exist in the database, but none of the cardinalities control whether linkages between specific agencies and volunteers can change. More detailed discussions would need to be held with the end users to properly document this business rule; notes should be added to the diagram to depict the appropriate business rule.

Blank

City A

City B Can’t Tell

a. Which city maintains data about only those volunteers who Blank

Blank

currently assist agencies? b. In which city would it be possible for a volunteer to assist more than one agency?

X

Blank

c. In which city would it be possible for a volunteer to change which Blank

agency or agencies she assists?

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Blank

X

Blank

X

Chapter 2

223

3 - ERD for ShinyShoesForAll:

3 - Associative entities v s Weak entities? ersu

A weak entity requires the presence of another entity type; the weak entity does not exist independently from the other entity type and has no business meaning in the ERD without the other entity type. A weak entity will not have its own identifier, but will have a partial identifier attribute that will later be combined with the identifier of its strong entity owner to create a full identifier.

An associative entity is an entity type that associates the instances of one or more entity types and contains attributes specific to the relationship between those entity instances. An associative entity generally has an independent business meaning to end users and can be identified with a single-attribute identifier. If an associative entity meets these conditions, then it would not be considered a weak entity.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

224

Chapter 2

3 - Figure 2-22 associative entities: DOES BUSINESS IN: between TERRITORY and CUSTOMER Although this entity has no attributes and no independent meaning, it is the only way that Visio can represent the M:N relationship between TERRITORY and CUSTOMER. ORDER LINE: between PRODUCT and ORDER This relationship has an attribute: Ordered Quantity that reflects the amount of product on each line of the order by the customer. It has independent meaning on the Customer‘s Order.

USES: between PRODUCT and RAW MATERIAL This relationship has one attribute, Goes Into Quantity. It also may have independent meaning, although there is no obvious independent identifier.

SUPPLIES: between RAW MATERIAL and VENDOR Since there is an attribute on this entity and it can have independent meaning, it might be a good candidate to convert to an associative entity.

PRODUCED IN: between WORK CENTER and PRODUCT Although this entity has no attributes and no independent meaning, it is the only way that Visio can represent the M:N relationship between WORK CENTER and PRODUCT. WORKS IN: between WORK CENTER and EMPLOYEE Although this entity has no attributes and no independent meaning, it is the only way that Visio can represent the M:N relationship between WORK CENTER and EMPLOYEE. HAS SKILL: between EMPLOYEE and SKILL Although this entity has no attributes and no independent meaning, it is the only way that Visio can represent the M:N relationship between SKILL and EMPLOYEE. There are so many associative entities because there are many M:N relationships that have independent meaning and because Visio‘s templates cannot represent M:N relationships.

3 - ERD for Figure 2-26 Grade Report: Student ID was chosen as the identifier for the STUDENT entity type as it is likely unique. Course ID was chosen as the identifier for the COURSE entity type as it is likely unique. Instructor Name was chosen as the identifier for the INSTRUCTOR entity type and it is assumed to be unique—should discussions during analysis work prove otherwise, it may be wise to create either (a) a composite identifier comprised of Instructor Name and Location, or (b) a new attribute Instructor I D that will be a unique number which can serve as an identifier (latter option would, in practice, be the most likely one).

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

225

Note: The addition of the Semester and Year attributes on the Registers For relationship allows this diagram (and resulting database) to reflect multiple semesters of data.

3Note: attributes are omitted from the ERD solutions for this Problem and Exercise in order to save space in the Instructor‘s Manual. a)

Figure 2-5

b)

Figure 2-10a

c)

Figure 2-12 (all parts)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

226

Chapter 2

d)

Figure 2-13c

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

e)

Figure 2-14

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

227

228

Chapter 2

3 - Is Married To relationship (Figure 2-12a) with time variations:

Diagram Notes for (d):

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

229

This solution presumes that Marriage Date is a partial identifier of the MARRIAGE entity; a full composite identifier will include Marriage Date and the two Person IDs involved in the marriage. The solution also assumes that the same two people do not get married, divorced, and re-married on the same date. Adding a Marriage Time attribute (also a part of the identifier) would permit this situation to be covered by this model.

An alternate solution would be to use a surrogate identifier of License No instead of the suggested composite identifier of Marriage Date and the two Person IDs for the MARRIAGE entity. (e): The solution in 2-34d does not place any restrictions on the number of persons to whom any one person is simultaneously married, thus the 2-34d solution is sufficient in representing the lack of legal restrictions regarding the number of marriage partners.

3 - Figure 2-27 Student, Club, School situation:

a. A STUDENT Works For 0:1 SCHOOL; A SCHOOL Employs 0:M STUDENTs b. A STUDENT may belong to a CLUB only when located in the SCHOOL s/he Attends c. Student answers may vary. Alternative solutions include: 

Since the STUDENT may not Work For a SCHOOL (the employment is optional), the Works For relationship is needed in the diagram in order to properly represent this business rule. This solution makes it harder for the database to enforce the business rule that a STUDENT works

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

230

Chapter 2

for the SCHOOL that s/he attends, but opens up the possibility that a STUDENT could Work For a SCHOOL that s/he is not currently attending. 

An alternative design would be to remove the Works For relationship, and add an attribute to STUDENT named Works that would have a binary (Y/N) value to represent whether or not the STUDENT instance is working for the SCHOOL s/he Attends. The advantage of this design is that it would enforce the business rule that a STUDENT can only Work For a SCHOOL that s/he is currently attending.

3 - Figure 2-28 diagrams showing stock price history: Note: Student answers may vary. The crux of the answer relies upon what the purpose of the E-R diagram is for the modeling situation and how end users in the organization ―see‖ the situation. In particular, do people in the organization have a term for stock price and refer to it as its own concept?

If so, solution B may be the ―better‖ way to model this situation. Instructors may also use solution B to demonstrate an issue related to view integration (topic in Chapter 4) where transitive dependencies emerge; solution B makes the model easy to expand so that stock prices may have relationships that do not directly involve the STOCK entity.

Solution A indicates that each STOCK has multiple prices and is well-suited to early discussions with end users about the data needs of a system. Solution B adds the precision of multiple STOCK PRICE entity instances occurring for each STOCK entity instance. Solution B indicates that STOCK PRICE is a weak entity whose instances do not exist independently in the database without a corresponding STOCK entity instance. Solution B presents more precise detail of the data relationships that will likely be developed in the logical design of the database; this model may more closely resemble the relational model implementation of this design. Solution B also makes it easy to expand the model so that stock prices may have relationships with other entities that do not directly involve the STOCK entity.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

3 - Figure 2-11b (Modified):

3a) Salesperson Name (LName, MI, FName), Employee Name (L Name, MI, FName)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

231

232

Chapter 2

b) There could be more than one product finish for a product, which could affect the price.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

233

234

Chapter 2

c) Yes, this would be possible. For example, a customer could have more than one address.

3 - ERD for Employee & Project situation: a)

Yes, the attribute names do generally follow the guidelines for naming attributes. b) ERD for Chemist, Project, Equipment situation: CHEMIST Employee ID Name Phone No

CHEMICAL USE Volume

PROJECT Project ID Start Date

CHEMICAL Compound No Cost

Assignment: All three entities participate in the Chemical Use relationship that is modeled as an associative entity, since the Volume for each CHEMIST‘s use of a chemical in a particular project and equipment item must be tracked. However, CHEMICAL and PROJECT do not need to have any USE instances. All entities can have multiple assignments. c) ERD for Course, Section situation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

235

Diagram Notes for 2-39c: SECTION is modeled as a weak entity. It could have been modeled as a multivalued attribute; however, using a weak entity is better, since SECTION may have a relationship with another entity. A multivalued attribute could not be used to show this relationship. d) ERD for Hospital situation:

Diagram Notes for 2-39d: Both Admits and Treats relationships were created since the patient could be treated by other PHYSICIANs in addition to the admitting PHYSICIAN. Hospital was not included as an entity in this case as there was insufficient information in the scenario write-up to indicate that the data model needed to allow for multiple hospitals (e.g., in the case of a large health-care organization). The current ERD does not allow for the tracking of multiple admissions over time by different physicians. The ERD would need a M:N relationship between PHYSICIAN and PATIENT in order to track that kind of data. If the date of admission needs to be tracked, under the circumstances of tracking multiple admissions over time, the ERD could be revised to show Date Admitted

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

236

Chapter 2

as an attribute of the M:N Admits relationship, just as Treatment Detail is an attribute of the Treats relationship. The ERD could also be revised to show ADMISSION and TREATMENT DETAIL associative entities (with corresponding attributes) instead of the M:N relationships currently discussed. e) First situation: credit check can be used by more than one request.

Using one entity type seems much simpler since the credit check and rating only apply to this credit request. However, Credit Check Date and Credit Rating will have blank values (null) until the credit check is received. f) Starting point diagram:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

237

Situation 1 – Adding Hourly Rate attribute. This could be added to the CONSULTANT entity if the business rule is that a CONSULTANT Works for only one COMPANY at a time.

Situation 2 – Tracking a CONSULTANT‘s contract. Notice that CONTRACT is added as another entity that participates in a binary relationship with COMPANY and a binary relationship with CONSULTANT. We have moved the Hourly Rate attribute to the CONTRACT entity, which permits a CONSULTANT to vary his/her Hourly Rate as a function of the particular CONTRACT for a COMPANY. As only current CONTRACTs are tracked, an alternative solution would be to move the CONSULTANT attributes into the CONTRACT entity and eliminate the CONSULTANT entity from the model. The downside to this alternative solution is that Consultant Name and Consultant Specialty would occur redundantly in the CONTRACT entity instances.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

238

Chapter 2

Situation 3 – Tracking historical CONTRACT information. We can create an associative entity for CONTRACT. We‘ve also added Contract ID as a surrogate identifier that is a unique serial number (not a composite identifier, as shown in Situation 2 above).

g) Parking Garage ERD

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

239

Diagram notes for 2-39g: Please note that the solution assumes one customer instance that is assumed to be the unidentifiable hourly customer. For example, the customer instance with Cust ID of 99999999 could be reserved for this purpose. h) Law Firm ERD

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

240

Chapter 2

Note: This problem and exercise is a good lead-in for Chapter 3 modeling notation for the Enhanced Entity Relationship Diagram (EERD). The P&E offers several chances to provide better representation in the E ERD (with subtyping) than the ERD notation that is provided in Chapter 2. Using E ERD notation, a single LEGAL ENTITY can be shown as a supertype, with subtypes of DEFENDANT and PLAINTIFF. The ‗type‘ (person or Organization) characteristic of both DEFENDANT and PLAINTIFF may also be considered for further subtyping. The solution presented here is a valid answer to the P&E, given the limitations of basic ERD notation and what is currently known about the situation.

This P&E also provides the instructor with an opportunity to discuss how history might be modeled if the business assumption regarding the tracking of Net Worth for both Plaintiff and Defendant was changed from only being concerned with Net Worth at the time of the CASE, to wanting to track the Net Worth over time of each party to the CASE. Refer to the chapter section on ―Modeling Time-Dependent Data‖ and Figure 219 for more information on how this ERD could be revised.

Diagram Notes for 2-39h:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2



241

Def Type and Plaintiff Type are used to denote Person or Organization type of legal entity.



Net Worth of both Plaintiff and Defendant is relevant only at the time of the CASE, thus are modeled as attributes of the M:N relationships between CASE and PLAINTIFF, DEFENDANT.

i) Professional society (CAM)

Diagram notes for 2-39i: 

In this solution, it is assumed that dietary restrictions can be captured sufficiently as instances of DIETARY RESTRICTION TYPE. If further specification is needed a supporting column could be added to PARTICIPANT and/or REGISTRATION.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

242

Chapter 2

3 - Star Hoist

Diagram Note for Problem & Exercise 2-40: Note the difference between Part Number in PART and Part Instance Number in PART INSTANCE. In this case, PART represents a part type and PART INSTANCE the individual parts that all have their own individual identifying number.

3 - Emerging Electric ERD

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

243

Diagram Notes for Problem & Exercise 2-41: 

A RATE may be for one, none, or many LOCATIONs.



A LOCATION may have multiple CUSTOMERs.



A CUSTOMER may own multiple LOCATIONs.

3 - STUDENT and ADVISER ERD SEMESTERREG STUDENT Student ID Student Name Student Major

semReg ID SemReg Date SemReg Time SemReg Semester SemReg Year

COURSEREG Reg Time

Semester Year ADVISER

Assigned

Adviser ID Adviser Name Adviser Dept

COURSE Course ID Course Title Course Credits

3 - Figure 2-4a Revised for Sarbanes-Oxley compliance purposes

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

244

Chapter 2

3 - Virtual Campus a. ERD, First Phase

Note: It is assumed that there is no data about a PERSON until that person registers for an ACCOUNT on some SITE. It is also assumed that a SITE always has at least one ACCOUNT. POSTING is a weak entity because it cannot exist unless associated with some ACCOUNT. b. One person, multiple accounts on the same site Yes, one person can have multiple accounts on the same site. There is nothing in the ER D that would prevent this from happening: a person can have multiple accounts and multiple accounts can be associated with one site. There is no simple way to enforce this requirement in an E RD. Such a rule would have to be shown on the ERD as a note and then enforced in application software. c. Phase 2, additional requirements

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

245

Note: The responses to a POSTING are other postings, represented by the Respond relationship. Each ―response‖ posting will be associated with one ACCOUNT. READ is an associative entity that records when an ACCOUNT reads a particular POSTING (whether it be an initial posting or a response posting). d. Ability to answer questions It is possible to determine the number of postings each person has created for a specific site. Each ACCOUNT is associated with both a person and a site and thus, as long as we remember to take into account that each person can have multiple ACCOUNTs on the same site, we can determine which accounts need to be included in the query and then count the number of POSTINGs on each of these accounts.

The current structure associated each posting with only one account and, consequently, only one site. The business rules specified for Part c make this query invalid.

It is possible to answer this, but the logic is not simple. The process would start with a POSTING and identify the PERSON making that posting. Then search through any response postings for that POSTING to find the first response, and then follow the path from POSTING to ACCOUNT to PERSON to see who made that posting. If it is the same PERSON who made the initial posting, then this is a person who satisfies the query.

It would be straight forward to count the number of POSTINGS per SITE (through the associated ACCOUNT associative entity) and identify any with a count of zero.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

246

Chapter 2

e. Phase three: Complaints added

Note: A COMPLAINT is associated with an ACCOUNT, and then to a PERSON, and a COMPLAINT is associated with a specify POSTING. The Removed Status attribute has been added to the POSTING entity to store hold a logical value for yes/no to remove. The site administrator is an actor using the social network site, but that person is indirectly associated with a COMPLAINT by the attribute in the SITE for the ACCOUNT that make the objectionable POSTING. f. Final phase: Private sites

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

247

Note: GROUP is a weak entity because an instance cannot exist without some PERSON creating it. It is not an associative entity, but rather has a separate M:N relationship with the PERSONs who are in the group, and the groups a person is a member of. A GROUP is associated with exactly one private SITE, but since not all sites are private, some SITEs are not associated with a group. Application software would make sure that the value for Site Administrator for a private site matches the PERSON who created the site.

And, application software would enforce the business rule that only group members can post to their private site.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

248

Chapter 2

3 - Preliminary ERD for Symphony Orchestra

Business Rule: A concert includes the performance of one or more compositions; a composition may be performed at one or more concerts or may not be performed. This business rule is modeled in the ERD above through the use of the COMPOSITION and CONCERT entities, together with the PERFORMANCE Associative Entity.

Note: The use of the Associative Entity PERFORMANCE also permits the independent binary relationship between SOLOIST and PERFORMANCE, which permits the model to support the tracking of derived data, Date Last Performed. Although the diagram appears to represent a ternary relationship among COMPOSITION, CONCERT, SOLOIST and PERFORMANCE, such a ternary relationship would not accurately reflect

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

249

the requirements of the problem. Rather, the needs of the problem state that there is an overall M:N binary relationship between SOLOIST and PERFORMANCE, which permits the tracking of multiple soloists performing any given composition as well as a given soloist performing multiple compositions.

3 - Miami-Dade County court system

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

250

Chapter 2

3 - The Sensing Building Company ERD

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

3 - Stillwater Antiques ERD

3 - A.M. Honka School of Business ERD

3 - Wally‟s Wonderful World of Wallcoverings ERD: a. Part I

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

251

252

Chapter 2

Note: So far, this is a fairly standard order processing database structure. Any reasonable customer demographic attributes and product characteristic attributes, that might be used to identify customer-product affinity, would be fine (e.g., customer address might be used to identify climate or décor related products). b. Explanations for queries 

It is possible to tell which other customers bought the same product(s) as a specific customer had bought: we can first identify the products based on the ORDER, LINE ITEM and PRODUCT entities and after that the customers who had ordered the same product(s) based on these same entities by identifying first all ORDER LINEs in which the product(s) are included and then the ORDERs that include the relevant ORDER LINEs. Each ORDER is, in turn, associated with exactly one PERSON.



Yes, it is also possible to continue the process above and identify other products that the relevant customer set had purchased (using the process described above).



Yes, this is possible: the database includes complete information regarding the customer interests, and it is possible to identify those customers whose interest set has at least three overlapping items with the customer of interest.

c. Part II

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

253

Note: The Similar to M:N relationship represents the subjective assessments of product similarity, if there are any, for each product. Each VIEW entity instance holds the associative entity attributes associated with each product a person views. d. Part III htopi@bentley.edu

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

254

Chapter 2

Note: ADDRESS and REVIEW are weak entities. A PERSON will have one or more ADDRESSes, and each add ADDRESS may be used for multiple ORDERs. Each LINE ITEM on an ORDER may have a review submitted for it, and READ is a typical associative entity linking the PERSONs with the REVIEWs they read. e. Part IV

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2



255

Note: The Address attribute in ADDRESS can be used as a qualifier to find other PERSONs with the same address attribute value (which ever part of Address they want to use).



The attributes added to PRODUCT will make this query possible.



This requirement simply demands a way to sort the results of a query, so this will be possible because the possible sorting attributes are available.

3 - Doctors Information Technology (DocIT): a. Part I

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

256

Chapter 2

Note: APPOINTMENT is a classic associative entity. A patient may not have any allergies, but a staff member must have some credentials. The multi-valued attribute Reason may come from a standard list of reason codes, or may include custom text provided by the patient. b. Part II

Note: The concept of a relationship between PATIENT/CONTACTs is an associate entity, which each relationship pair from one patient/contact to another descripted by the

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

multi-valued attribute Nature of Relationship. This structure is similar to the bill-ofmaterials structure shown in the chapter. c. Phase III

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

257

258

Chapter 2

Note: Each PATIENT (but not CONTACT) may have many POLICY(ies), kept in Sequence, and each POLICY is from one company, so POLICY is an associative entity.

CLAIM is as associative entity between an APPOINTMENT and a POLICY. d. Responses to queries 

This can be calculated by counting the number of CLAIM entity instances with Amount Paid < Amount Claimed.



The count in the first query can be grouped by Company I D following the relationship from CLAIM to POLICY then to INSURANCE COMPANY.



Similar to the prior query, the Amount Claimed can be summed for each group defined by each Staff ID, by following the relationship from CLAIM to APPOINTMENT then from APPOINTMENT to STAFF.



Given the database design in Part c, there is no easy way to determine what are likely different Staff ID and Patient ID values. This could be handled in a different database design in which all persons are in one super entity type (this concept is introduced in Chapter 3).

e. Part IV Note: CLAIM PROCESSING STEP is an associative entity relating STAFF and CLAIM; each CLAIM may be the result of a new submission from a claim processing step, and a claim processing step may cause a new claim to be submitted. See the solution on the next page.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

259

260

Chapter 2

3 - Revision to prior ERD in 2-49

Changes made to prior 2-49 ERD -

Added qualifiers to attribute names in the STUDENT entity

Entities: o Student: A person who attended and graduated from the A.M. Honka School of Business. o Event: School events held around the world. o Contact: The School‘s records of any contact made with a former student and graduate of the School.

Attributes on Student: Student No: A unique identifier for a student when they attended the School. This attribute must be unique and is required.

Student Name: The name of the student when attending the School. This

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

261

attribute is required.

Student Current Name: Current name of the former student.

Student Current Address: Current address of the former student.

Student Country of Birth: Country where the former student was born.

Student Country of Citizenship: Country where the former student holds citizenship.

Student Major: The name of the academic major completed by the former student. A student may have one or two majors. This attribute is required.

Attributes on Event: Event ID: A unique identifier for the event. This attribute is required.

Event Location: The physical location of the event. This data may be made up of the street address, city, state, postal code, and country.

Event Date: The year, month, and day of the event.

Event Type: The type of event (e.g., reception, dinner, or seminar).

Event Title: The title of the event, as used in the press release and communications with the former students. This attribute is required.

Attributes on Contact: Contact Type: The category of contact type made with the former student.

Possible values include mail, email, telephone, and fax. This attribute is required.

Contact Date: The year, month, and day of the contact event with the former student. This attribute is required.

Contact Info: The updated information about the former student that was learned during the contact event. This attribute is required.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

262

Chapter 2

Relationship: Attends: A student attends zero, one, or many events. An event has one or more students in attendance.

Makes: The school makes contact with a specific former student. For each contact with a specific student, the School tracks zero, one, or many instances of contact information.

Attributes on Relationship: Comment: Information that school officials learn from a graduate at a specific event.

Suggestions for Field Exercises 3 - The intent of this exercise is to have your students gain some exposure to standards in the business world. This is a good opportunity for your students to learn the benefits of enforcing naming standards, whether for E-R models or for programming code. If standards do not exist in the organization, have your students come up with some guidelines for naming standards. If standards do exist, your students should ask the database or systems analyst for an opportunity to review these standards to see if they are consistent and uniform.

3 - You may choose to use the same organizations for this field exercise that were used in Chapter 1 Field Exercises, or instead choose different organizations. It is likely that some of your students may have contacts in suitable organizations. The main difference that students are likely to find in a manufacturing company (compared to a service company) is the complexity encountered in modeling a product structure (or bill of materials). This often results in a recursive unary relationship, which is described in this chapter.

3 - This field exercise can be performed in conjunction with Exercise 2-54 above. Most organizations will probably have examples of each of these types of relationships. Be on the alert to discover ternary relationships that are mistakenly modeled as multiple binary

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

263

relationships.

3 - This field exercise can be combined with Exercise 2-55 above. It is quite likely the organization will be using E-R notations that are different from the text, but students should be able to accommodate different notations with some explanation.

3 - We suggest you combine this with Exercise 2-56 (and perhaps Exercise 2-55) above. If timedependent data is apparent in the models, you might ask, for example, how the organization tracks customer sales over time.

3 - Students should build a table to compare features of all products.

Project Questions 3 - Revised Enterprise Data Model Please see page 55 for the revised Enterprise Data model.

3 - E-R diagram for FAME Note: Although the question asks you to base the E-R diagram on Question 1-52, students should also consider the work they did for 2-59.

Please see Page 56 for the E-R model.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

264

Chapter 2

Question 2-59 Figure 1

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2

Question 2-60 Figure 1

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

265

266

Chapter 2

3 - Identify outputs Relevant outputs include, for example, the following items: 

A tentative contract for a specific prospective artist



A final contract for a specific prospective artist



Artist schedule for a specific timeframe



List of revenues by manager within a timeframe



List of FAME fees by manager within a timeframe



List of revenues by artist within a timeframe



List of revenues minus FAME fee by artist within a timeframe



List of artist expenses by artist within a timeframe



An account statement per artist (including previous balance, expenses since previous statement close, revenues (minus FAME fee) since previous statement close, payments to/from an artist, new balance)



List of future performances (including anticipated revenue and FAME fee) within a specific timeframe 

For all artists



For a specific artist



For a specific manager

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 2



Invoices to customers for a specific time period



Accounts receivable reports (list of unpaid invoices categorized by due date)



List of manager expenses by manager within a timeframe



An account statement per manager (including previous balance, expenses since previous statement close, manager‘s

267

share of FAME fees since previous statement close, payments to/from a manager, new balance) 

Data regarding event cancellations



Artist contact information



List of relevant news items per artist



Availability of a specific artist within a time frame



List of all available artists for a specific time frame filtered by specific criteria (instrument, experience level, fee level, etc.)



Artist contracts to be renewed within a specific future timeframe



Expired artist contracts

See page 58 for the revised E-R model.

3 - Questions based on the E-R modeling efforts The questions will vary depending on the students.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

200

Chapter 3

Question 2-61 Figure 1

Chapter 3 The Enhanced E-R Model Chapter Overview The purpose of this chapter is to present some important extensions to the E-R model (which was initially described in Chapter 2) that are useful in capturing additional business meaning. In particular, we describe two types of extensions to the E-R model. First, the enhanced entity-relationship (EER) model

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

201

includes constructs for supertype/subtype relationships. Second, the inclusion of new notation for business rules allows the designer to capture a broader range of constraints on the data model than were previously available.

Chapter Objectives Specific student objectives are included in the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Introduce the concept of supertype/subtype relationships and prepare the students to recognize when to use these relationships in data modeling.

2. Describe the use of specialization (top-down perspective) and generalization (bottom-up perspective) as complementary techniques for defining supertype/subtype relationships.

3. Introduce a notation for specifying both completeness constraints and disjointness constraints when modeling supertype/subtype relationships.

4. Help students gain sufficient perspective so that they recognize when to use (and when not to use) supertype/subtype relationships in realistic business situations.

5. Describe the basic premises of a business rules paradigm.

6. Discuss the concept of a universal data model and its use in packaged data models.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

202

Chapter 3

Key Terms Attribute inheritance

Generalization

Subtype discriminator

Completeness constraint

Overlap rule

Supertype

Disjoint rule

Partial specialization rule

Supertype/subtype hierarchy

Disjointness constraint

Specialization

Total specialization rule

Enhanced entity-

Subtype

Universal data model

relationship (EER) model Entity cluster

Classroom Ideas 1.

Introduce the concept of supertypes and subtypes with a familiar example, such as VEHICLE (subtypes are CAR, TRUCK, S UV, etc.).

2.

Introduce the basic notation for supertype/subtype relationships (Figure 3-1). Use this notation to represent the example you introduced in (1). Introduce your students to all three notation types.

3.

Discuss the EMPLOYEE example with subtypes (Figure 3-2). Use this figure to introduce the concept of attribute inheritance.

4.

Use Figure 3-3 to discuss the two major reasons for introducing supertype/subtype relationships: unique attributes among subtypes, and unique subtype relationships.

5.

Contrast generalization and specialization using Figures 3-4 and 3-5. Have your students suggest other examples that use each of these approaches.

6.

Introduce the completeness constraint using Figure 3-6. Give other examples where either the total specialization rule or the partial specialization rule is more appropriate.

7.

Discuss the disjointness constraint and related notation using Figure 3-7. For reinforcement, have the students work Problem 3-25 or 3-26 (Problems and Exercises) in class.

8.

Introduce notation for a subtype discriminator (Figures 3-8 and 3-9). Discuss why a different notation is required for the two cases shown in these figures.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

9.

Discuss entity clustering and illustrate with Figures 3-13 and 3-14.

10.

Review the extended example of a supertype/subtype hierarchy shown in Figure 3-10. For

203

reinforcement, ask the students to work Problem 3-19 (Problems and Exercises) in class.

11.

Review universal data models and discuss how these are being used more widely today. Consider inviting an industry guest speaker to discuss how these universal data models are utilized in his/her company.

12.

Ask your students for examples of other business situations they have encountered recently in their work, school, or home experience that could be modeled with supertype/subtype hierarchies. See if they can diagram these rules using the notation provided in this chapter.

Answers to Review Questions 3 - Define each of the following terms: a. Supertype. A generic entity type that has a relationship with one or more subtypes b. Subtype. A subgrouping of the entity instances in an entity type that is meaningful to the organization c. Specialization. The process of defining one or more subtypes of the supertype, and forming supertype/subtype relationships d. Entity cluster. A set of one or more entity types and associated relationships grouped into a single abstract entity type e. Completeness constraint. A type of constraint that addresses the question of whether an instance of a supertype must also be a member of at least one subtype. The completeness constraint has two possible rules: total specialization and partial specialization f. Enhanced entity-relationship (EER) model. The model that has resulted from extending the original E-R model with new modeling constructs such as supertypes and subtypes g. Supertype/subtype hierarchy. A hierarchical arrangement of supertypes and subtypes in which each subtype has only one supertype

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

204

Chapter 3

h. Total specialization rule. Specifies that each entity instance of the supertype must be a member of some subtype in the relationship i. Generalization. The process of defining a generalized entity type from a set of more specialized entity types j. Disjoint rule. Specifies that if an entity instance (of the supertype) is a member of one subtype, it cannot simultaneously be a member of two (or more) subtypes k. Overlap rule. Specifies that an entity instance can simultaneously be a member of two (or more) subtypes l. Partial specialization rule. Specifies that an entity instance of the supertype is allowed not to belong to any subtype m. Universal data model. A generic or template data model that can be reused as a starting point for a data modeling project 3 - Match the following terms and definitions: d

supertype

f

entity cluster

a

subtype

e

specialization

g

subtype discriminator

c

attribute inheritance

b

generalization

3 - Contrast the following terms: a. Supertype; subtype. A supertype is a generalized entity type that has one or more subtypes, while a subtype is a subgrouping of the entity instances in a supertype. b. Generalization; specialization. Generalization is the process of defining a generalized entity type

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

205

from a set of more specialized entity types, while specialization is the process of defining one or more subtypes of the supertype. c. Disjoint rule; overlap rule. With the disjoint rule an instance of a supertype must be a member of only one subtype at a given time. With the overlap rule an instance of a supertype may simultaneously be a member of two or more subtypes. d. Total specialization rule; partial specialization rule. With the total specialization rule, each instance of the supertype must be a member of some subtype in the relationship. With the partial specialization rule, an instance of the supertype is allowed not to belong to any subtype. e. PARTY; PARTY ROLE. In a universal data model, PARTY represents persons and organizations independent of the roles they play whereas PARTY ROLE contains information about a party for an associated role. f. Entity; entity cluster. An entity is a person, place, object, event, or concept in the user environment about which the organization wishes to maintain data. An entity cluster is a set of one or more entity types and associated relationships grouped into a single abstract entity type.

3 - Two conditions for using supertype/subtype relationships: a. There are attributes that apply to some (but not all) of the instances of an entity type. b. There are relationships that apply to some (but not all) of the instances of an entity type.

3 - Reasons for using an entity clustering approach: a. Simplifying the presentation of a complex enterprise-wide E-R diagram. b. Enabling a hierarchical decomposition of a macro-level data model into finer and finer views of the data. c. Desiring to focus part of the model on an area of interest to a community of users. d. Creating several different entity cluster segments each with a different focus, such as departments, information system applications, business processes, or corporate divisions.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

206

Chapter 3

3 - An example of a supertype/subtype relationship: The supertype PERSON has many possible subtypes: MALE, FEMALE, INFANT, TEENAGER, etc., assuming these different types of persons have somewhat different attributes or participate in different relationships. In an organizational context, PERSON may have subtypes of EMPLOYEE, CONTRACTOR, CUSTOMER, VENDOR, MANAGER, etc.

3 - Attribute inheritance explanation: Attribute inheritance is a property of the enhanced E R diagram that ensures subtype entity instances inherit the values of all attributes of their supertype. This property is important because it makes it unnecessary to include supertype attributes redundantly with subtypes.

3 - Examples of supertype/subtype relationship where: a. the disjoint rule applies: PERSON has subtypes MALE and FEMALE. b. the overlap rule applies: PERSON has subtypes INSTRUCTOR and STUDENT. 3 - Types of business rules in EER: The types of business rules that are normally captured in an E ER diagram include terms, relationship constraints, and supertype/subtype relationships (see Figure 3-11).

3 - Subtype discriminator purpose: The purpose of a subtype discriminator is to determine the target subtype (or subtypes) for each instance of a supertype.

3 - Usefulness of packaged data model: A packaged data model is most useful when one can easily customize it to the specific business (that is, the organization is very similar to other organizations for the same industry or purpose or the functional area is roughly the same as that functional area in other organizations). As long as the packaged data model is for the type of business or functional area, then it can generally be customized. The amount of customization depends upon the types of specialized business rules in place for the organization.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

207

3 - Starting project with packaged data model v s from scratch: er su

A packaged data model provides the metadata of a standardized, industry-vetted data model usually built with a structured data modeling tool (i.e., ERWin from Computer Associates or Oracle Designer from Oracle Corporation). A data modeling project that starts with a packaged data model is different from one using a model developed from scratch along the following dimensions: a. The project would begin by identifying the parts of the packaged data model that apply to your specific project‘s data modeling situation, rather than beginning to draw model elements. b. The identified data elements from the packaged data model would be renamed to terms local to the organization. c. Data in the packaged data model would be mapped to data in current organization databases, with the intent of developing migration plans for converting organizational data. i.

Some of the data cannot be mapped (e.g., data elements in the package won‘t be in the current systems, and likewise). Determine whether each non-mapped item is essential and unique, as well as if these requirements are necessary now or in the future.

ii.

A purchased data model will have business rules to cover all possible circumstances whereas your specific local situation may need less flexibility and complexity.

iii.

The purchased data model can be used to ―seed‖ questions for coverage with the end users of the new system and database, allowing for earlier and more in-depth participation of system users and managers in the data modeling project.

iv.

The comprehensive nature of the purchased data model will likely force the project to prioritize the staging of systems requirements related to customization of the overall data model.

3 - Data profiling usage: Data profiling is a way to statistically analyze data to uncover hidden patterns and flaws. Profiling can find outliers, see shifts in data distribution over time, and identify other phenomena. Each

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

208

Chapter 3

perturbation of the distribution of data may tell a story, such as showing when major application system changes occurred, or when business rules changed. Often these patterns suggest poorly designed databases (e.g., data for separate entities combined to improve processing speed for a special set of queries but the better structure was never restored). Data profiling can also be used to assess how accurate current data are and anticipate the clean-up effort that will be needed to populate the purchased data model with high-quality data.

3 - Skill needed for packaged data model v s without: ersu

A data modeling project using a packaged data model requires at least the same amount of skill as a project not using a packaged data model. In some cases, it may require more skill. The primary reason is that when a data modeling project uses a packaged data model, the data modeler must customize the packaged data model to meet local organizational needs and constraints. Thus, a successful data modeler using a packaged data model needs advanced skills and knowledge about the organization‘s business rules, complex data modeling formalisms, and the structured data modeling tool used to specify the packaged data model.

3 - Benefit of packaged data model: A packaged data model provides the metadata of a standardized, industry-vetted data model usually built with a structured data modeling tool (such as E RWin from Computer Associates or Oracle Designer from Oracle Corporation). The packaged data model contains a fully populated description of the data model and the structured data modeling tool that permits customization of the data model and printing of several reports from the model. The structured data modeling tool often includes the ability to produce S QL commands for database definition in a variety of database management systems.

3 - Selection between mandatory and optional minimum cardinalities: Because there cannot be a purchased part that does not have a supplier (a part cannot be purchased if nobody sells it to the organization). A supplier, however, can be a supplier even if it does not sell anything to this particular organization (yet).

3 - Supertype/subtype membership: A member of a supertype is always a member of at least one subtype when the rule of total specialization applies to an E ERD.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

209

Solutions to Problems and Exercises 3 - A supertype/subtype example listing follows for a GRADUATE STUDENT: Attribute Name

Data Value

SSN

736-94-1802

Name

Jessica James

Address

25 Lake Dr. Medford OR 95106

Gender

Female

Date_of_Birth

Oct. 23, 1967

Major_Dept

Computer Science

Test_Score

986

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

210

Chapter 3

3 - Figure 3-10 with subtype discriminators

3 - Adding subtype discriminators a. Figure 3-2, revised

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

b. Figure 3-3, revised

c. Figure 3-4b, revised

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

211

212

Chapter 3

d. Figure 3-7a, revised

e. Figure 3-7b, revised

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

213

3 - Sample definitions for Figure 3-2: EMPLOYEE:

a person who has signed an employment agreement or contract with the company

HOURLY EMPLOYEE:

an employee whose pay is based on number of hours worked

SALARIED EMPLOYEE:

an employee who receives a fixed salary each pay period

CONSULTANT:

an employee who has signed a contract to perform certain tasks and whose pay is based on an agreed billing rate

Employee Number:

an employee‘s identification number

Employee Name:

an employee‘s name consisting of first name, middle initial, and last name

Address:

an employee‘s home address, consisting of street address, city, state, and zip code

Date Hired:

the date when an employee signed an employment agreement or contract

Hourly Rate:

the pay rate ($/hour) for an hourly employee

Annual Salary:

the base annual salary for a salaried employee Copyright © 2022, 2019, 2016 Pearson Education, Inc.

214

Chapter 3

Stock Option:

the annual compensation (shares/year) of company stock for a salaried employee

Contract Number:

the number of the contract signed by a consultant

Billing Rate:

the compensation ($/hour or other stated period) on the employment contract signed by a consultant

3 - Sample definitions for Figure 3-3: PATIENT:

a person who has been admitted to the hospital, or to a treatment program administered by the hospital

OUTPATIENT:

a person who has been admitted to a program of treatment administered by the hospital

RESIDENT PATIENT:

a person who has been admitted for a stay in the hospital and assigned to a bed location

RESPONSIBLE PHYSICIAN: a physician who has formally admitted patient to the hospital BED:

a hospital bed located within a room in the hospital

Is Cared For:

the relationship between a physician and a patient admitted to the hospital by that physician

Is Assigned:

the relationship between a resident patient and the hospital bed to which that patient is assigned

Patient ID:

a patient‘s identification number

Patient Name:

a patient‘s first and last name

Admit Date:

the date when a patient was most recently admitted to the hospital or to a treatment program

Checkback Date:

the date when an outpatient is scheduled for a return visit

Date Discharged:

the date when a resident patient was discharged following the most recent stay in the hospital

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

Physician ID:

a unique identification number for an admitting physician

Bed ID:

a unique identification number for each hospital bed

215

3 - Explanation of Figure 3-13b questions a. Because only regular customers (as opposed to national customers) do business in a sales territory, not all instances of the customer entity cluster do business in a selling unit. However, because all sales territories do business with at least one regular customer, then all sales territories do business with at least one instance of a customer entity cluster. b. The attributes of item would be the attributes of PRODUCT and PRODUCT LINE from Figure 222: Product I D, Product Description, Product Finish, Product Standard Price, Product Line I D, and Product Line Name. c. The attributes of material would be the attributes of RAW MATERIAL, SUPPLIES, SUPPLIER, and VENDOR from Figure 2-22: Vendor ID, Vendor Name, Vendor Address, Supply Unit Price, Material ID, Unit Of Measure, Material Name, and Material Standard Cost.

3 - Virtual Campus:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

216

Chapter 3

3 - Library situation analyses and EERD segments a. A holding is exactly one subtype

b. A holding may or may not be a subtype; but only one subtype at a time

c. A holding may or may not be a subtype; but can be more than 1 at a time.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

d. A holding must be a subtype; but can be more than 1 at a time.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

217

218

3-

Chapter 3

Bank situation, standard EER Notation:

Bank situation, Visio Notation:

Bank situation, Subtype in Supertype Notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

219

3 - E-R Diagram for P&E 2-47 with Entity Clusters: There are three entity clusters: Project Detail, Employee Detail, and Dept Detail.

Project Detail contains the set of entities that would be used by one interested in the project without concern for the specific employees on the project. An assumption is that the only concern from the project side is to track employee skills and location, not individual employees.

The Employee Detail cluster would be of most value to the user who was interested in what skills specific employees have as well as location. Other details are available in this cluster, such as marriage. This cluster was chosen since one can then isolate employee information without looking at project information.

The Dept Detail cluster was chosen since one might not be concerned about vendors, but might want to know for what department a given employee works. In the same way, one might want specifics about vendors without needing information about employees or projects.

See diagram on next page.

E-R Diagram from Chapter 2, Problem 23 with Entity Clusters

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

220

Chapter 3

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

3 - E-R Diagram for P&E 3-24f with Entity Clusters:

3 - Non-profit organization.

Please note that the problem does not explicitly state that Skill is a multivalued attribute. Given the fact that examples in the text have skill as a multivalued attribute, we have made this assumption here also.

Nonprofit situation, EER Notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

221

222

Chapter 3

Non-profit organization, Visio Notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

Nonprofit organization, Subtypes inside Supertypes Notation

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

223

224

Chapter 3

3City Transportation, EER Notation: TOLL COLLECTION POINT TCP ID TCP Name TCP Description TCP Type TCP Location TCP Start Date

Toll Amount VEHICLE TYPE VType ID VType Name

HOURLY USE HU ID HU Date HU Hour HU Count HU Amount

TOLL BOOTH TB ID TB Description TB Type

VEHICLE Vehicle License Vehicle Make Vehicle Model

PASSING UNMANNED

Date Time Amount Charged

MANNED

EMPLOYEE Emp ID Emp Name Emp Address Emp Phone Emp Year of Service Emp Type

SUPERVISOR

TOLL COLLECTOR

Superv MCR

TC Perf Evaluation

Supervises

Reports to

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

3 - Technology Company E RD

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

225

226

Chapter 3

3 - RQC EER Diagram CUSTOMER

RENTAL Rental ID Rental Date Rental Time

Customer Nbr Cust LName Cust FName Cust Email Cust Phone Cust Address (City, Zip, State) Cust Type

PAYMENT Payment ID Payment Amount Payment Type

RENTAL ITEM RI Due Date RI Return Date

d

PRIVATE

ORGANIZATION

Pr Cust Title

Org Contact Org Type

ITEM Item ID Item Serial Nbr Item Purchase Date

ITEM TYPE

GAME COPY

Item Type ID Item Manufacturer Item Brand Item Description Item Daily Fee Item Weekly Fee Item Monthly Fee

GC ID GC Medium

d

COMPUTER Comp RAM Comp Drive Comp Processor Comp Type

PRINTER Pr Copies

SCANNER

NETW EQP

Sc Connectivity

NE Port Chars NE Type

GAME Age Rating

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

3 - School of Technology, E ERD notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

227

228

Chapter 3

School of Technology, Visio notation:

School of Technology, Subtype within Supertype notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

3 - Fin and Finicky Security Consultants.

EER Diagram Notes (for all notations): a.

A CONSULTANT is either a Business or Technical consultant, not both.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

229

230

Chapter 3

Consulting Firm, EER Notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

Fin and Finicky Security Consultants, Visio notation:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

231

232

Chapter 3

Fin and Finicky Security Consultants, Subtype within Supertype Notation:

3 - Consulting Firm, P&E 3-34, Selected Sample Definitions CONSULTANT:

a person who has signed an employment agreement or contract with the company, and who is on the company payroll

BUSINESS CONSULTANT:

a consultant who provides an estimate to a customer

TECHNICAL CONSULTANT: a consultant who provides security services to a customer CUSTOMER:

a business that has a need for security services

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

233

LOCATION:

a customer‘s place of business

SERVICE:

a security service that can be performed

ESTIMATE:

a written estimate prepared by a business consultant for a location

SERVICE PERFORMED:

actual services performed by a technical consultant for a location

Emp I D:

a consultant‘s employee identification number

Degree:

a consultant‘s academic degree

Business Experience:

a business consultant‘s business experience

Tech Skills:

a technical consultant‘s technical expertise

Coverage:

how much of an area a service covers for a given location

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

234

Chapter 3

3 - DocIT EERD 3 - Hamilton Falls EER Diagram:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3 RESIDENT

d

GROUP

Rent

PERSON

ITEM

Rent

FACILITY

NON-FACILITY

d

d

TOOL

VEHICLE

APPLIANCE

o

d d

MOTORIZED

TWO WHEEL

POWER

Repair

SERVICE VENDOR

KITCHEN

ENTERTAINMENT

HAND

Repair Repair

Note that the task specified that no attributes are needed.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

235

236

Chapter 3

3 - Revision to Figure 3-16

Diagram Notes for Problem and Exercise 3-38: a. A PERSON, in his/her EMPLOYMENT, may hold multiple POSITIONs or not yet have an assigned POSITION (this is shown with the 0:M cardinality near POSITION from EMPLOYMENT). b. A POSITION might initially be unfilled, or over time, may be filled with multiple EMPLOYMENT instances of PERSONs (this is shown by the 0:M cardinality near EMPLOYMENT from POSITION).

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3

237

Suggestions for Field Exercises 3Common examples of supertype/subtype constructs may be easy for student interviewees to identify. Ask your students to try to find an example of each of the rules described in the chapter: disjoint, overlapping, partial specialization, and total specialization. Also, for each example, have your students identify a candidate subtype discriminator. Ask your students to justify the use of supertype/subtype relationships for each of these examples, using the guidelines stated in the chapter.

3We suggest that you use this exercise as a continuation of Field Exercise 2 in Chapter 2. Ask your students to determine whether supertype/subtype relationships are formally modeled in the corporate E-R diagrams. Also, ask your students to determine how business rules are stated and enforced by each organization.

3We suggest you assign this exercise in conjunction with Field Exercise 4 in Chapter 2.

3Following are several questions that can be used to structure this report: a. How are business rules defined? b. Why are business rules important to an organization? c. What are alternative methods for capturing and expressing business rules? d. What advantages can an organization realize by formally capturing business rules?

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

238

Chapter 3

3The availability of Web sites that provide information on this topic changes rapidly. This might be an excellent exercise to bring in an industry guest speaker to address your students. Possible sites that students may find information about this topic include: o www.universaldatamodels.com (Note: site will point to Embarcadero ER/Win product for more information on what the models include, but the images may not be fully readable) o www.inmoncif.com (Note: under the ―Corporate Information Factory‖ section, there are sample models available to view, however, visitors must register an email address to access the materials)

Project Questions 3 - EER model for FAME See the model on p. 43.

3-

Description of the thought processes that you went through to create the model in 3-44.

Two different types of modifications are included in the E ER model in the response of 3-44: a) those that are based on the need to apply supertype/subtype relationships to the diagram developed in the context of Chapter 2 and b) those that are created based on the new information presented in Chapter 3. a. Subtype/supertype relationships in the existing diagram: 

The recognition that Prospective Artist and Artist are subtypes of a general Artist entity.



The recognition that Artist Expenses and Manager Expenses can be separated into subtypes so that the accuracy of the cardinalities can be improved.

b. New information from the case that requires changes to the diagram: 

Pat Smith identifies a number of possible sources for recommendations for prospective artists.

It seems based on the case that identifying SOURCE as a separate entity is justifiable. There does not, however, appear to be enough differentiation between the source types to justify a subtype/supertype structure.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 3



239

Pat Smith provides useful information regarding the attributes required for ARTIST and RECOMMENDATION. To keep the diagram readable, the solution above leaves the following ARTIST attributes out: Year of Birth, {Instrument}, {University Degree}, Address, Phone Number, E-mail, {Honor}.



Other Pat Smith requirements have been taken care of in the existing diagram or by the changes specified above.



Shannon Howard makes an important contribution to articulating better the various types of time commitments an artist can have: Actual performance events, rehearsal periods, travel time, and personal time off. At least the event related categories and personal time off should be separated from each other, as has been done in the answer to 3-44. Firmness attribute of PERSONAL tells whether or not the personal commitment can be broken if a good enough opportunity emerges, and Category in PERF RELATED separates Performance, Rehearsal, and Travel.



Multivalued attribute {Samples} has been added to Contracted Artist based on Shannon Howard‘s recommendation.



Also based on Shannon Howard‘s recommendation, an attribute for At Source Tax Withheld is added to AGREEMENT.

3 - Identify a revised set of outputs The following outputs can be identified based on Chapter 3 material (in addition to those identified in Chapter 2): o List of recommendations categorized and filtered in a number of ways to support review of prospective artists. o List of prospective artists filtered appropriately together with all artist recommendations from a specific time period. o Travel expense report for artist managers (a subset of a report from Chapter 3). o A more detailed availability report than specified in Chapter 2. o Inclusion of the At Source Tax in the revenue reports.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

240

Chapter 3

These requirements are already taken into account in the model included in 3-44.

3 - Plan for reviewing deliverables with appropriate stakeholders Meeting individually with Mr. Forondo, Pat Smith, and Alex Martin (at the minimum) is recommended to verify the sufficiency of the conceptual data model and the appropriateness of the design decisions. If possible, a group meeting would be useful after the individual discussions in order to consolidate different points of view. In addition to Mr. Forondo‘s sign-off (assuming that he has not delegated that responsibility to somebody else), it is important that those involved in the day-to-day operations of the business also approve the model before moving on.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

200

Question 3-44 Figure 1

Chapter 4 Logical Database Design and the Relational Model Chapter Overview The purpose of this chapter is to describe in depth the major steps in logical database design, with emphasis on the relational model. Logical database design is the process of transforming the conceptual

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

201

Chapter 4

data model (described in Chapters 2 and 3) into a logical data model. First, we provide a concise description of the relational data model, including the properties of relations. Next, we describe and illustrate the various types of integrity constraints associated with the relational model. This section introduces S QL table definitions and the concept of well-structured relations. We then provide a detailed description of the process of transforming E ER diagrams into relations. Next, we define normalization and describe the steps of normalizing relations. The chapter concludes with a discussion of merging relations and techniques for dealing with typical issues that arise during this process.

Chapter Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Show students the position of logical database design within the overall database development process. This is a key chapter in the textbook because students will begin to see the connection between conceptual modeling and the implementation of a functioning database.

2. Help students understand the key distinction between conceptual data modeling that focuses on the real-world problem domain and logical data modeling, which models the relational database structure as part of the solution domain.

3. Provide students with a solid understanding of the relational data model including the general properties of relations, integrity constraints, and the characteristics of well-structured relations.

4. Discuss the principles and detailed steps involved in mapping E ER diagrams to relations. Computerassisted techniques are often used to speed up this process, but students should still understand the principles underlying the process.

5. Provide students with a firm grasp on the principles of functional dependencies, determinants, and related concepts of normalization.

6. Emphasize the reasons why normalization is important to stable database design with the relational model, and then present a concise description of the various normal forms and the normalization process.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

202

7. Discuss some of the anomalies that arise when merging relations and discuss how to apply the principles we have learned to address these anomalies.

Key Terms Alias

Functional dependency

Relation

Anomaly

Homonym

Second normal form (2NF)

Candidate key

Normal form

Surrogate primary key

Composite key

Normalization

Synonyms

Determinant

Null

Third normal form (3NF)

Enterprise key

Partial functional

Transitive dependency

dependency Entity integrity rule

Primary key

First normal form (1NF)

Recursive foreign key

Foreign key

Referential integrity

Well-structured relation Blank

Blank

constraint

Classroom Ideas Note: Enabling the students to achieve a sufficient competency in both E ER→relational conversions and normalization typically requires dedicating at least two weeks for these topics: one week (i.e., two 75-80 minute class meetings or one 150 minute class meeting) for foundations of the relational model and E E R→relational conversion, and another week for normalization.

1. Motivate the need for logical database design. One possibility is to start by showing students the conceptual data model (E-R diagrams) for Pine Valley Furniture Company (Figure 2-22). Emphasize that this E-R diagram must be transformed through logical database design before it can be implemented.

2. Review the position of logical database design in the overall database development process (see Figure 1-11). You might want to discuss who in the organization is usually responsible for this step and what CASE tools might be appropriate.

3. Discuss the relational data model using Figures 4-1 through 4-4 as examples.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

203

Chapter 4

4. Introduce the important integrity constraints in the relational model using Figure 4-5 and Table 4-1.

Emphasize that these constraints will be enforced by the D BMS, but must first be specified by the designer.

5. Introduce SQL table definitions (Figure 4-6). Show how these definitions specify the referential integrity constraints that are diagrammed in Figure 4-5.

6. Illustrate how anomalies can occur when relations are not well structured, using Figures 4-2b and 47. Emphasize the fact that much real-world data (including relational data) are not well structured.

7. Discuss the process of transforming E ER diagrams into relations (Figures 4-8 through 4-21). We suggest you reinforce these concepts by asking your students (in teams of two) to perform Problem & Exercise 4-33a in class immediately following the discussion.

8. Preview the steps of normalization using Figure 4-22. You will want to use this figure again to summarize normalization at the end of your discussion.

9. Discuss the concepts of functional dependencies, determinants, and candidate keys. Start with your own examples on the board, and then have your students give additional examples. Summarize using Figure 4-22.

10. Discuss first through third normal forms, using Figures 4-25 through 4-29. Additional normal forms (B CNF and 4NF) are presented in Appendix B, if time permits.

11. Discuss merging relations and view integration problems.

12. Use Figure 4-31 to discuss enterprise keys and their use.

13. We strongly suggest asking your students to work in small teams on one or more end-of-chapter exercises. (P&E 4-28 and 4-29 work well for this purpose.)

Answers to Review Questions 3 - Define each of the following terms: a. Determinant. The attribute on the left-hand side of the arrow in a functional dependency b. Functional dependency. A constraint between two attributes or two sets of attributes in which the

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

204

value of one attribute is determined by (in practice, known based on) the value of another attribute. c. Transitive dependency. A functional dependency between two (or more) nonkey attributes d. Recursive foreign key. A foreign key in a relation that references the primary key values of that same relation e. Normalization. The process of decomposing relations with anomalies to produce smaller, wellstructured relations f. Composite key. A primary key that consists of more than one attribute g. Candidate key. An attribute, or combination of attributes, that uniquely identifies a row in a relation h. Normal form. A state of a relation that results from applying simple rules regarding functional dependencies (or relationships between attributes) to that relation i. Partial functional dependency. A functional dependency in which one or more non-key attributes (such as Name) are functionally dependent on part (but not all) of the primary key j. Enterprise key. A primary key whose value is unique across all relations k. Surrogate primary key. A serial number or other system assigned non-intelligent primary key for a relation 3 - Match terms to appropriate definitions: f

well-structured relation

e

anomaly

a

functional dependency

j

determinant

g

composite key

d

1NF

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

205

Chapter 4

h

2NF

i

3NF

c

recursive foreign key

k

relation

b

transitive dependency

3 - Contrast the following terms: a. Normal form; normalization. Normal form is a state of a particular relation determined based on the functional dependencies between its primary key attribute(s) and non-key attribute(s), while normalization is the process of decomposing relations with anomalies to produce smaller, wellstructured relations. b. Candidate key; primary key. A primary key is an attribute (or combination of attributes) that uniquely identifies a row in a relation. When a relation has more than one such attribute (or combination of attributes), each is called a candidate key. The primary key is then the one candidate key that is chosen by users to uniquely identify the rows in the relation. c. Partial dependency; transitive dependency. A partial functional dependency exists when a nonkey attribute is functionally dependent on part (but not all) of a composite primary key; a transitive dependency is a functional dependency between two or more non-key attributes. d. Composite key; recursive foreign key. A composite key is a primary key that consists of more than one attribute, while a recursive foreign key is a foreign key in a relation that references the primary key values of that same relation. e. Determinant; candidate key. A determinant is the attribute on the left-hand side of the arrow in a functional dependency (the attribute that determines the values of the other attributes), while a candidate key uniquely identifies a row in a relation. f. Foreign key; primary key. A primary key uniquely identifies each row in a relation, while a foreign key refers to the value of a primary key in another table. g. Natural primary key; surrogate primary key. Natural primary key is a primary key that is used

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

206

operationally by the organization (such as a product code or a customer number) and recognized as identifier in conceptual data modeling. A surrogate primary key is, however, typically invisible for the real-world operation, without any real-world meaning, and generated only for the purpose of serving as a primary key. h. Enterprise key; surrogate key. An enterprise key is a primary key whose value is unique across all relations in the whole database and is likely to hold no business meaning. A surrogate key is a primary key whose value is a serial number or other system assigned value and is unique to the relation.

3 - Conceptual versus Logical data modeling: Conceptual data modeling is about understanding the organization – getting the right requirements built into the database design. Logical data modeling is about creating stable database structures – expressing the organizational requirements correctly in a technical language so that the resulting database operates on a specific type of database technology.

3 - Six important properties of relations: a. Each relation in a database has a unique name. b. An entry at the intersection of each row and column is atomic (indivisible) and single valued. c. Each row is unique. d. Each attribute within a table has a unique name. e. The sequence of columns is insignificant. f. The sequence of rows is insignificant.

3 - Two properties that must be satisfied by candidate keys: a. Unique identification: For every row, the value of the key must uniquely identify that row. b. Non-redundancy: No attribute in the key can be deleted without destroying the property of unique identification.

3 - Three types of anomalies in tables: a. Insertion anomaly: A new row cannot be inserted unless all primary key values are supplied, Copyright © 2022, 2019, 2016 Pearson Education, Inc.

207

Chapter 4

leading to the need to insert unnecessary data to accomplish the original goal. b. Deletion anomaly: Deleting a row results in the loss of important information not stored elsewhere. c. Modification anomaly: A simple update must be applied to multiple rows.

3 - Demonstrate anomaly types with an example.

An insertion anomaly occurs when it is impossible to add an instance of one entity without also adding an instance of another entity (or instances of other entities). For example, if we assume that an ORDER relation includes information regarding all PRODUCTs that are included in the ORDER, it will be impossible to add a new PRODUCT without also adding an ORDER that includes the new PRODUCT. A deletion anomaly is based on the same phenomenon as the insertion anomaly described above, but it refers to the situation where deletion of an instance of one entity will lead to the inadvertent deletion of the instances of another relation. For example, in the ORDER – PRODUCT example above, the deletion of a specific ORDER might lead to the deletion of all information regarding a specific PRODUCT if an instance of the PRODUCT in the ORDER to be deleted was the last one.

A modification anomaly refers to the situation where structural problems require that the same data value is modified in multiple places in the database if the value changes. Using the ORDER – PRODUCT example, if any basic data of PRODUCT changes (such as name or description), it has to be updated in the context of every ORDER in the database separately, leading to an increase of likelihood of errors.

3 - Fill in the blanks: a. second b. third c. first

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

208

3 - Well-structured relations definition and importance: A well-structured relation is one that contains a minimum amount of redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistency. Well-structured relations are important because they are required for database integrity.

3 - Correspondence of ERD relationships to relational data model: Relationships in an E-R diagram are expressed in a corresponding relational data model through the use of foreign keys. For example, in the Pine Valley Furniture Company E ERD (shown in Figure 2-22) there is a relationship between the CUSTOMER and ORDER entities. In the corresponding relational data model, this association between the CUSTOMER and ORDER tables is defined by including the CustomerID attribute (CUSTOMER table primary key) as a foreign key in the ORDER table.

3 - Describe ERD components‟ transformation into relations: a. Regular entity type: Each entity type is transformed into a simple relation. Each simple attribute of the entity type becomes an attribute of the relation. b. Relationship (1:M): A relation is created for each of the two entity types participating in the relationship. The primary key attribute of the entity on the one-side of the relationship becomes a foreign key in the relation on the many-side of the relationship. c. Relationship (M:N): A new relation is created to represent this relationship. The primary key for each of the participating entity types is included in this new relation as a component of the composite primary key of the new relation. Alternatively, the new relation gets a new surrogate key, in which case the keys of the participating entity types are included as foreign keys. d. Relationship (supertype/subtype): A separate relation is created for the supertype and each of its subtypes. The primary key of the supertype is assigned to each subtype, as well as attributes that are unique to the subtype. e. Multivalued attribute: A new relation is created to replace the multivalued attribute. The primary key of this new relation consists of two attributes: the primary key of the original relation, plus the multivalued attribute itself. f. Weak entity: A new relation is created corresponding to the weak entity. The primary key of this

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

209

Chapter 4

relation consists of the primary key of the owner relation, plus the partial identifier of the weak entity type. g. Composite attribute: The simple component attributes of the composite attribute are included in the new relation.

3 - Purpose of normalization. Role of determinants in normalization: The primary purpose of normalization is to develop a way of grouping attributes together in relations that results in the removal of insertion, deletion, and modification anomalies. The rules of the normalization process are based on the identification of determinants and other attributes, the value of which depends on the value of a determinant. Thus, normalization is not possible without a full understanding of the determinants.

3 - Reasons why normalization is useful: Normalization provides a systematic process for determining a well-defined structure for a set of data items. There are many situations in which the database structure is not generated based on a well-defined conceptual model created from scratch but is developed based on existing data items. In this type of a situation, normalization is a very useful process for understanding the implications of the relationships between the data items.

3 - Four typical problems in merging relations: a. Synonyms: Two (or more) attributes have different names but the same meaning.

Solution: Convince users to standardize a single name. b. Homonyms: A single attribute has more than one meaning.

Solution: Create new attribute names that capture the separate meanings. c. Transitive dependency: Merging relations produces transitive dependencies.

Solution: Create 3NF relations by removing the transitive dependency. d. Supertype/subtype: May be implied by content of existing relations.

Solution: Create new relations that explicitly recognize this relationship.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

210

3 - Three conditions that imply a relation is in the second normal form: a. The primary key consists of a simple attribute. b. No nonkey attributes exist in the relation. c. Every nonkey attribute is functionally dependent on the full set of primary key attributes.

3 - Integrity constraints enforced in SQL CREATE TABLE commands: a. Entity integrity: enforced by NOT NULL clause, and by the PRIMARY KEY clause in Oracle (which includes the setting of the NOT NULL constraint in Oracle physical database implementations) b. Referential integrity: enforced by FOREIGN KEY REFERENCES statement 3 - Benefits of design enforced integrity constraints: The major benefit of enforcing the integrity constraints as part of the database design and implementation process is that these constraints will be consistently applied by the database across all applications. Placing integrity constraints within application design is risky due to the need to ensure (and subsequently test) that the constraints are implemented in the application code everywhere the database is used.

3 - Relational model 1:M unary relationship: A 1:M unary relationship is represented by a recursive foreign key whose values reference the primary key values of the same relation.

3 - Relational model M:N ternary relationship: A M:N ternary relationship is represented by a new associative relation whose primary key consists of the primary key attributes of the participating entity types.

3 - Relational model associative entity: A new relation (called the associative relation) is created to represent the associative entity. The default primary key consists of the primary key values from the relations that participate in the association.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

211

Chapter 4

3 - Primary key and functional dependencies: All of the non-key attributes of a relation are functionally dependent on the primary key of that relation.

3 - Foreign key null restriction: A foreign key must not be null when the minimum cardinality of the relationship implied by the foreign key is one.

3 - Avoiding key ripple effects: The only way to eliminate ripple effects is to create an enterprise key from the very beginning of database development.

3 - Difference in 1:M versus M:N unary: A unary 1:M relationship always utilizes a recursive foreign key, whereas an M:N recursive relationship dictates that a second table must be created for the relationship.

3-

The following three conditions are adequate to suggest that a surrogate key should be developed for a relation: a. the presence of a composite primary key b. the natural primary key (the one initially identified by users during conceptual modeling activities) is too long or made up of more than two attributes which will cause performance issues with the implementation c. the natural primary key cannot be guaranteed to be unique over time (e.g., due to duplicates or re-use over time)

3 - Benefits of using an enterprise key: The use of an enterprise key enables the database to evolve better over time because the defining characteristics of all primary key attributes are the same and thus, it is easier to change the structure of the relations (for example, by introducing new supertypes as they are identified).

The use of an enterprise key also makes it easier to achieve the goal of removing redundant or overlapping instances across the organization: the process of specifying an enterprise key

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

212

requires a thorough analysis and removal of overlapping and redundant data. Having an enterprise key will help in the process of avoiding various anomalies in organization-wide data.

Answers to Problems and Exercises Note to Instructors: In this section, we have adopted a number of notational conventions to indicate the primary and foreign keys in the relations. Primary keys are noted with an underlined name. Foreign keys are noted in italics.

3 - Transforming E-R diagrams to relations: a. The derived attribute YearsEmployed is not going to be an actual column, so it is not displayed here; relations from Figure 2-8.

b. Relations from Figure 2-9b

c. Relations from Figure 2-11a

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

213

Chapter 4

d. Relations from Figure 2-11b

e. Relations from Figure 2-15a (relationship version)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

f. Relations from Figure 2-15b (attribute version)

g. Relations from Figure 2-16b

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

214

215

Chapter 4

h. Relations from Figure 2-19

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - Transforming EER diagrams to relations: a. Relations from Figure 3-6b

b. Relations from Figure 3-7a

c. Relations from Figure 3-9

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

216

217

Chapter 4

d. Relations from Figure 3-10

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

e. Relations from Figure 3-11, solution shown on next page.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

218

219

Chapter 4

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - The normal form for the relations are (foreign keys shown in italics): a. 3NF b. 3NF c. 2NF CLASS (CourseNo, SectionNo, Room) ROOM (Room, Capacity) d. 1NF COURSE (CourseNo, CourseName) CLASS (CourseNo, SectionNo, Room) ROOM (Room, Capacity) 3 - EER → relational transformation Note to Instructors: The notation used here is an alternative way of describing the relational schema with referential integrity constraints. The arrows are replaced with ―<ColumnX> references TABLE<ColumnY>‖ statements. Foreign keys are indicated with italics and dashed underlining, when possible. a. Relations for Chemist situation, Ch2, P&E 2-39b CHEMIST(EmployeeID, Name, PhoneNo) PROJECT(ProjectID, StartDate) CHEMICAL(CompoundNo, Cost) CHEMICALUSE(EmployeeID, ProjectID, CompoundNo, Volume) EmployeeID referencs CHEMIST(EmployeeID) ProjectID references PROJECT(ProjectID) CompoundNo references CHEMICAL(CompouneNo) b. Relations for Parking Garage situation, Ch2, P&E 2-39g

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

220

221

Chapter 4

CUSTOMER(CustID, CustLName, CustFName, CustStreet, CustCity, CustState, CustZip, CustEmail, CustPhone) NEGOTIATEDFEE(FeeID, FeeAmount, FeeTimePeriod, FeeStartDate, FeeEndDate, FeeCustomer) FeeCustomer references CUSTOMER(CustID) PARKINGSPOT(ParkingSpotID, ParkingSpotFloor, ParkingSpotNumber, ParkingSpotStatus) PARKINGEVENT(PEventID, PeventStartDateTime, PEventEndDateTime, PEventPlateImage, PEventCustID, PEventParkingSpotID) PEventCustID references CUSTOMER(CustID) PEventParkingSpotID references PARKINGSPOT(ParkingSpotID) c. Relations for Defendant/Plaintiff situation, Ch2, P&E 2-39h DEFENDANT(DefNo, DefName, DefType) PLAINTIFF(PlaintiffNo, PlaintiffName, PlaintiffType) CASE(CaseNo, CaseOpened, CaseClosed, CaseJudgment) CASEDEFENDANT(CaseNo, DefNo, DepNetWorth) CaseNo references CASE(CaseNo) DefNo references DEFENDANT(DefNo) CASEPLAINTIFF(CaseNo, PlaintiffNo, PlaintiffNetWorth) CaseNo references CASE(CaseNo) PlaintiffNo references PLAINTIFF(PlaintiffNo) REQUESTEDJUDGMENT(JudgmentID, JudgmentTitle, JudgmentLabel) CASEPLAINTIFFREQJUDGMENT(JudgmentID, CaseNo, PlaintiffNo) JudgmentID references REQUESTEDJUDGMENT(JudgmentID) CaseNo, PlaintiffNo references CASEPLAINTIFF(CaseNo, PlaintiffNo) d. Relations for Professional society situation, Ch2, P&E 2-39i PARTICIPANT(ParticipantID, ParticipantLname, ParticipantFName, ParticipantCellPhone, ParticipantEmail) CITY(CityID, CityName, CityState) MEETING(MeetingID, MeetingTitle, MeetingHotel, MeetingCity)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

MeetingCity references CITY(CityID) DIETRESTRTYPE(DietaryRestrictionID, DietaryRestrictionLabel) PARTDIETRESTR(ParticipantID, DietaryRestrictionID) ParticipantID references PARTICIPANT(ParticipantID) DietaryRestrictionID references DIETRESTRTYPE(DietaryRestrictionID) REGISTRATION(RegID, RegTravelType, RegArrivalTime, RegDepartureTime, MeetingID, ParticipantID) MeetingID references MEETING(MeetingID) ParticipantID references PARTICIPANT(ParticipantID) REGDIETRESTR(RegistrationID, DietaryRestrictionID) RegistrationID references REGISTRATION(RegID) DietaryRestrictionID references DIETRESTRTYPE(DietaryRestrictionID) e. Relations for Student and Adviser case, Ch2, P&E 2-42 STUDENT(StudentID, StudentName, StudentMajor) COURSE(CourseID, CourseTitle, CourseCredits) ADVISER(AdviserID, AdviserName, AdviserDept) SEMESTERREG(SemRegID, SemRegDate, SemRegTime, SemRegSemester, SemRegYear, SemRegStudent, SemRegAdviser) SemRegStudent references STUDENT(StudentID) SemRegAdviser references ADVISER(AdviserID) COURSEREG (SemRegID, CourseID, RegTime) SemRegID references SEMESTERREG(SemRegID) CourseID references COURSE(CourseID) f. Relations for Miami-Dade County case, Ch2, P&E 2-46 AGENCY(AgencyID, AgencyType, AgencyName, AgencyContact) AgencyContact references PERSON(PersonID) PERSON(PersonID, PersonName, BirthDate, EducationLevel, JobTitle, PermanentAddress, AgencyID) AgencyID references AGENCY(AgencyID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

222

223

Chapter 4

CONTACT(AgencyID, ClientID, ContactDate, EmploymentStatus, AddressAtContact, Reason, AgencyContactPersonID) AgencyID references AGENCY(AgencyID) ClientID references PERSON(PersonID) AgencyContactPersonID references PERSON(PersonID) ILLNESS(IllnessID, IllnessName) DIAGNOSIS(DiagnosisID, DiagnosisDate, Notes, IllnessID, DiagnoserID) IllnessID references ILLNESS(IllnessID) DiagnoserID references PERSON(PersonID) MEDICINETREATMENT(MedicineID, MedicineName, Manufacturer) PRESCRIPTION(MedicineID, DiagnosisID, ClientID) MedicineID references MEDICINETREATMENT(MedicineID) DiagnosisID references DIAGNOSIS(DiagnosisID) ClientID references PERSON(PersonID) ILLNESSMEDICINE(IllnessID, MedicineID) IllnessID references ILLNESS(IllnessID) MedicineID references MEDICINETREATMENT(MedicineID) 3 - 3NF relations for Millennium College are (foreign keys shown in italics): OBJECT(OID, ObjectType) INSTRUCTOR(OID, InstructorName, InstructorLocation) COURSE(OID, CourseNo, CourseTitle, InstuctorName) STUDENT(OID, StudentNo, StudentName, Major) OUTCOME(OID, StudentNo, CourseNo, Grade)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - Transforming an E-R diagram to relations (parts a and b), Figure 4-33

a. Using an enterprise key (foreign keys shown in italics) OBJECT(OID, ObjectType) CUSTOMER(OID, CustomerID, CustName, CustAddress) CARD ACCOUNT(OID, AccountID, ExpDate, CardType, CustomerID) DEBIT CARD(OID, DAccountID, BankNo) CREDIT CARD(OID, CAccountID, CurrBal) CHARGES(OID, MerchID, CAccountID, ChargeDate, ChargeTime, Amount) MERCHANT(OID, MerchID, MerchAddr) 3 - Transforming Table 4-3 to relations: a. PARTSUPPLIER relation PARTSUPPLIER (PartNo, Description, VendorName, Address, UnitCost) Copyright © 2022, 2019, 2016 Pearson Education, Inc.

224

225

Chapter 4

(Illustrated with sample data) PartNo

Description

VendorName

Address

UnitCost

1234

Logic Chip

Fast Chips

Cupertino

10.00

1234

Logic Chip

Smart Chips

Phoenix

8.00

5678

Memory Chip

Fast Chips

Cupertino

3.00

5678

Memory Chip

Quality Chips

Austin

2.00

5678

Memory Chip

Smart Chips

Phoenix

5.00

b. Functional dependencies PartNo VendorName PartNo, VendorName

Description Address UnitCost

Possible (Composite) Candidate Key: PartNo + VendorName c. Anomalies Insert anomaly: We cannot insert a new vendor unless we also include a part number that the supplier provides (and vice-versa).

Delete anomaly: If we delete the last part information for a given supplier, we also lose information about that vendor. (For example, Part 5678 from Quality Chips Vendor) Modification anomaly: If a vendor‘s address changes, we have to modify all records (or rows) for that vendor. d. Functional dependencies PartSupplier

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

e. Which normal form?

1NF f. Normalized relations PART

g. 3NF relations in Visio notation

3 - Developing a relational schema based on Figure 4-34 Note: The details of the notation used here are described in the context of the answer to P&E 4-31.

RTABLE(RTableNbr, RTableNbrOfSeats, RTableRating) SEATING(SeatingID, NbrOfGuests, StartTimeDate, EndTimeDate, ManagerID) ManagerID references MANAGER(EmployeeID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

226

227

Chapter 4

SEATINGTABLES(RTableNbr, SeatingID) RTableNbr references RTABLE(RTableNbr) SeatingID references SEATING(SeatingID) EMPLOYEE(EmployeeID, EmpLName, EmpFName, EmpType) MANAGER(EmployeeID, MonthlySalary) EmployeeID references EMPLOYEE(EmployeeID) WAITER(EmployeeID, HourlyWage, ManagerID) EmployeeID references EMPLOYEE(EmployeeID) Manager ID references MANAGER(EmployeeID) SPECIALTY(SpecialtyID, SpecialtyDesc) WAITERSPECIALTY(EmployeeID, SpecialtyID) EmployeeID references WAITER(EmployeeID) SpecialtyID references SPECIALTY(SpecialtyID) ASSIGNMENT(SeatingID, EmployeeID, StartTimeDate, EndTimeDate, TipsEarned) SeatingID references SEATING(SeatingID) EmployeeID references WAITER(EmployeeID) 3 - Transforming Table 4-4 (GRADE REPORT) to relations: a. Functional dependencies

b. The relation is currently in the first normal form (1N F) because it has no repeating groups and has a name and a valid primary key, but is not in 2N F because it has partial transitive dependencies.

For example, StudentName is dependent on only one of the two components of the primary key (StudentID). c. 3NF relations for GRADE REPORT

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

d. Relational schema with functional dependencies

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

228

229

Chapter 4

e. An ERD to show the final version of the relations

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

230

3 - Transforming Table 4-5 (shipping manifest) to relations: a. Total weight is a derived attribute and can be calculated from weight and quantity. Therefore it is not shown here as part of the relational schema. Relational schema shown below:

b. The relation is currently in the first normal form (1N F) because it has no repeating groups and has a name and a valid primary key, but is not in 2N F because it has partial transitive dependencies.

For example, ShipmentDate is dependent on only one of the two components of the primary key (ShipmentID). c. 3NF relations

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

231

Chapter 4

d. 3NF relations with referential integrity and functional dependencies shown

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

e. Relational schema shown in Visio notation

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

232

233

Chapter 4

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - EER diagram resulting from P&E 4-37 relations:

3 - Transform EER diagrams to relational schemas Note: The details of the notation used here are described in the context of the answer to P&E 4-31. a. City Transportation situation, Ch3 P&E 3-30 EMPLOYEE(EmpID, EmpName, EmpAddress, EmpPhone, EmpYearOfService, EmpType) SUPERVISOR(SEmpID, SupervMCR) SEmpID references EMPLOYEE(EmpID) TOLLCOLLECTOR(TEmpID, TCPerfEvaluation) TEmpID references EMPLOYEE(EmpID) TOLLCOLLECTIONPOINT(TCPID, TCPName, TCPDescription, TCPType, TCPLocation, Copyright © 2022, 2019, 2016 Pearson Education, Inc.

234

235

Chapter 4

TCPStartDate) TOLLBOOTH(TBID, TBDescription, TBType, TCPID) TCPID references TOLLCOLLECTIONPOINT(TCPID) UNMANNED(UTBID) UTBID references TOLLBOOTH(TBID) MANNED(MTBID) MTBID references TOLLBOOTH(TBID) VEHICLETYPE(VTypeID, VtypeName) VEHICLE(VehicleLicense, VehicleMake, VehicleModel, VehicleType) VehicleType references VEHICLETYPE(VTypeID) TCPVEHICLETYPEPRICING(TCPID, VTypeID, TollAmount) TCPID references TOLLCOLLECTIONPOINT(TCPID) VTypeID references VEHICLETYPE(VTypeID) PASSING(VehicleLicense, UTBID, Date, Time, AmountCharged) VehicleLicense references VEHICLE(VehicleLicense) UTBID references UNMANNED(UTBID) HOURLYUSE(HUID, HUDate, HUHour, HUCount, HUAmount, VTypeID, MTBID) VTypeID references VEHICLETYPE(VTypeID) b. RentQualityComputers situation, Ch3 P&E 3-32: CUSTOMER(CustomerNbr, CustLname, CustFname, CustEmail, CustPhone, CustCity, CustZip, CustState) PRIVATE(PCustomerNbr, PrCustTitle) PCustomerNbr references CUSTOMER(CustomerNbr) ORGANIZATION(OCustomerNbr, OrgContact, OrgType) OCustomerNbr references CUSTOMER(CustomerNbr) RENTAL(RentalID, RentalDate, RentalTime, RentalCustomer) RentalCustomer references CUSTOMER(CustomerNbr) PAYMENT(PaymentID, PaymentAmount, PaymentType, PaymentRental) PaymentRental references RENTAL(RentalID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

236

ITEMTYPE(ItemTypeID, ItemManufacturer, ItemBrand, ItemDescription, ItemDailyFee, ItemWeeklyFee, ItemMonthlyFee) ITEM(ItemID, ItemSerialNbr, ItemPurchaseDate, ItemType) ItemType references ITEMTYPE(ItemTypeID) COMPUTER(CItemID, CompRAM, CompDrive, CompProcessor, CompType) CItemID references ITEM(ItemID) PRINTER(PItemID, PrCopies) PItemID references ITEM(ItemID) SCANNER(SItemID, ScConnectivity) SItemID references ITEM(ItemID) NETWEQP(NItemID, NEPortChars, NEType) NItemID references ITEM(ItemID) GAME(GItemID, AgeRating) GitemID references ITEM(ItemID) GAMECOPY(GCID, GCMedium, ItemID, GameID) ItemID references ITEM(ItemID) GameID references GAME(GItemID) RENTALITEM(RentalID, ItemID, RIDueDate, RIReturnDate) RentalID references RENTAL(RentalID) ItemID references ITEM(ItemID) c. Hamilton Falls, Ch3 P&E 3-37 Note that developing a relational model solution for this question requires at least a minimal set of attributes for each of the entities. This solution assumes an identifier, name/label, and a possible subtype discriminator (when appropriate).

RESIDENT(ResidentID, ResidentName, ResidentType) GROUP(GResidentID) GResidentID references RESIDENT(ResidentID) PERSON(PResidentID) PResidentID references RESIDENT(ResidentID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

237

Chapter 4

ITEM(ItemID, ItemName, ItemType) FACILITY(FItemID) FItemID references ITEM(ItemID) GROUPFACILITY(GResidentID, FItemID) GResidentID references GROUP(GResidentID) FItemID references ITEM(ItemID) NONFACILITY(NItemID, NFType) NItemID references ITEM(ItemID) VEHICLE(VNItemID, VehicleType) VNItemID references NONFACILITY(NItemID) MOTORIZED(MVNItemID) MVNItemID references VEHICLE(VNItemID) TWOWHEEL(TVNItemID) TVNItemID references VEHICLE(VNItemID) TOOL(TNItemID, ToolType) TNItemID references NONFACILITY(NItemID) POWERTOOL(PTNItemID) PTNItemID references TOOL(TNItemID) HANDTOOL(HTNItemID) HTNItemID references TOOL(TNItemID) APPLIANCE(ANItemID, ApplianceType) ANItemID references NONFACILITY(NItemID) KITCHENAPPLIANCE(KANItemID) KANItemID references APPLIANCE(ANItemID) ENTERTAINMENTAPPLIANCE(EANItemID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

238

EANItemID references APPLIANCE(ANItemID) SERVICEVENDOR(ServiceVendorID, ServiceVendorName) VEHICLEVENDOR(ServiceVendorID, VNItemID) ServiceVendorID references SERVICEVENDOR(ServiceVendorID) VNItemID references VEHICLE(VNItemID) POWERTOOLVENDOR(ServiceVendorID, PTNItemID) ServiceVendorID references SERVICEVENDOR(ServiceVendorID) PTNItemID references POWERTOOL(TNItemID) APPLIANCEVENDOR(ServiceVendorID, ANItemID) ServiceVendorID references SERVICEVENDOR(ServiceVendorID) ANItemID references APPLIANCE(ANItemID) 3 - Transform Figures 2-15a and 2-15b to 3NF relations Attribute version: EMPLOYEE

EmployeeID

EmployeeName

SKILL

EmployeeID

SkillCode

SkillTitle

SkillType

Relationship version: EMPLOYEE

EmployeeID

EmployeeName

POSSESSES

EmployeeID

SkillCode

SKILL

SkillCode

SkillTitle

SkillType

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

239

Chapter 4

The attribute version of the 3N F relations is similar to Figure 4-10. However, we have a much clearer definition of a primary key in this version. One main advantage of the relationship version is that we do not have to store SkillTitle and SkillType many times. If a skill title was changed or types were reclassified, this would make things much easier since update anomalies are eliminated in the relationship version of relations.

3 - Millennium College Public Safety Parking situation: a. Parking ticket table STID

Lname

FName

PhoneNo

St

LicNo

Ticket#

Date

Code

Fine

BRY

15634

10/17/2021

2

$25

16017

11/13/2021

1

$15

16017

11/13/2021

1

$15

14987

10/05/2021

3

$100

16293

11/18/2021

1

$15

17892

12/13/2021

2

$25

Lic 38249

Brown

Thomas

111-7804

FL

123 38249

Brown

Thomas

111-7804

FL

BRY 123

38249

Brown

Thomas

111-7804

FL

BRY 123

82453

Green

Sally

391-1689

AL

T RE 141

82453

Green

Sally

391-1689

AL

T RE 141

82453

Green

Sally

391-1689

AL

T RE141

The determinants are: S T ID, Ticket#, Code.

b. Dependency diagram

c. Anomalies

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

240

An insertion anomaly would occur if you tried to insert a student who has never had a parking ticket.

A deletion anomaly would occur if you were to delete a record of any student with only one parking ticket since this would lead to the loss of all student information.

A modification anomaly would occur whenever the PhoneNo (or Name, State License, or License Number) data of a student with multiple tickets was updated. d. MillenniumCollege Public Safety Parking, 3N F relations

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

241

Chapter 4

e. Millennium College Public Safety Parking, E ER diagram

3 - PVFC Materials Management situation: a. PVFC Dependency diagram

b. PVFC 3NF relations

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

c. PVFC EER diagram

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

242

243

Chapter 4

3 - Manufacturing Company Shipment situation, Table 4-8 a. Shipment situation, Dependency diagram

b. The relation is currently in the second normal form (2N F). There are no partial functional dependencies but there is a transitive dependency between origin/destination and distance.

Note to Instructor: An interesting discussion point for you to make the students aware of is the issue of symmetry in this problem. By symmetry, we mean: is the distance from A to B the same as from B to A? If it is, then there is an interesting issue about whether the Distances table potentially has redundancy. You may wish to consider assigning an advanced exercise to remove the potential redundancy from the relations under these circumstances. c. Shipment situation, 3NF relations

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

244

Illustration of resulting tables with sample data Shipment

Shipment# 409 618 723 824 629

Origin Seattle Chicago Boston Denver Seattle

Destination Denver Dallas Atlanta Los Angeles Denver

Distances

Origin Seattle Chicago Boston Denver

Destination Denver Dallas Atlanta Los Angeles

Distance 1537 1058 1214 975

Blank

Blank

Blank

3 - Vacation Property Rentals a. 3NF Relations

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

245

Chapter 4

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

b. 3NF Relations, with functional dependencies noted

c. All relations are in third normal form. d. An action assertion could be used such as: A property shall have one and only one rental agreement in force at one time, where ―in force‖ means that a given date falls between BeginDate and EndDate.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

246

247

Chapter 4

3 - Ch3, 3-33; Relational schemas and functional dependencies; all relations are in 3N F.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - Car Racing League; all relations are in 3N F.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

248

249

Chapter 4

3 - Publisher specializing in large edited works Note: The details of this notation are described in the context of the answer to P&E 4-31.

AUTHOR(AuthorID, AuthoLastName, AuthFirstName, AuthMiddleInitial, AuthPhone, AuthEmail) EXPERTISE(ExpertiseID, ExpertisedDescr) AUTHOREXPERTISE(AuthorID, ExpertiseID) AuthorID references AUTHOR(AuthorID) ExpertiseID references EXPERTISE(ExpertiseID) CHAPTER(ChapterID, ChapterNumber, ChapterTitle) AUTHORASSIGNMENT(AuthorID, ChapterID, AuthorPosition, IsLeadAuthor, IsContactAuthor) AuthorID references AUTHOR(AuthorID) ChapterID references CHAPTER(ChapterID) EDITOR(EditorID, EditorLName, EditorFName, EditorInstitution) BOOK(BookNbr, BookISBN, BookTitle, BookPrice, BookMainVolume) BookMainVolume references BOOK(BookNbr) BOOKEDITOR(BookNbr, EditorID, EditorOrder) BookNbr references BOOK(BookNbr) EditorID references EDITOR(EditorID) BOOKCHAPTER(BookNbr, ChapterID) BookNbr references BOOK(BookNbr) ChapterID references CHAPTER(ChapterID) WHOLESALER(CustID, CustName) ORDER(OrderID, OrderDate, OrderDeliveryDate, CustID) CustID references WHOLESALER(CustID) ORDERLINE(OrderlineNbr, BookNbr, OrderID, OLPrice, OLDiscount, OLQuantity) BookNbr references BOOK(BookNbr) OrderID references ORDER(OrderID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - Middle-sized software vendor; all relations are in 3N F.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

250

251

Chapter 4

3 - Law firm Note: For this situation in Figure 4-39, we assume that Client information is stored even if there is not a corresponding instance of Retention with an Attorney and a Case. We also assume that Attorney information is stored even if there is not a corresponding instance of Retention with a Client and a Case.

All relations are in 3NF since there are no partial functional dependencies or transitive dependencies. It could be argued that zip code is determined by city and state (also by address with 9-digit zip codes). This could be a good point to discuss in class.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

252

3 - Pet store Diagram Notes: o Purchase date information refers to a Customer‘s purchase of a pet from the store. o Delivery date information refers to a Store‘s receipt of a shipment of a pet from the pet‘s supplier. o Date of Last Purchase can be determined by viewing the data stored in the delivery date fields.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

253

Chapter 4

o LastCustomerName can be determined by viewing the data stored in the CustomerName fields. o Note to Instructor: The problem states that ―Peter Corona wants to implement a Web-enabled database application‖ for use by his branch stores for entering inventory, ordering, and sales data. This is a good opportunity to discuss with students the issues involved in converting a legacy, flat-file ―system‖ that mixes together inventory, customer purchases, and store purchases into a relational design that will support a Web application and future growth. Stress the importance of re-designing the data structure to support the tracking of all customer purchases and store deliveries, rather than just the four presented in the flat-file. You might also note that there appears to be some data missing from the ―old‖ system that would be useful in managing inventory and sales data at the stores (e.g., quantity sold, quantity purchased, quantity received, etc.). a. Dependency diagram shown on next page.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

254

255

Chapter 4

b. This structure is not a relation nor is it in any normal form due to the presence of DeliveryDate1-4, PurchaseDate1-4, and CustomerName1-4 attributes. These attributes appear to suggest that they are repeating groups. In order to show a relation in 1N F, repeating groups must be removed.

Peter might change his structure to the following 1N F solution, which will result in having more data instances in his structure to store the same data that is currently being stored in his flat-file ―system.‖ The attributes of LastCustomerName, DateLastPurchase, and DateLastDelivery are not stored as part of the proposed 1NF solution as this data can be determined by viewing the stored data in the revised relation below.

c. Normalized data model; Relations and functional dependencies Note: PetID, StoreID, and CustomerID attributes have been added as unique surrogate keys to maintain database integrity.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - Pet store EERD after relations normalized:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

256

257

Chapter 4

3 - Changes to P&E 4-50 and 51?

If a type of fish could be supplied by multiple suppliers, the data model needs adjustment to track this. A SUPPLIER relation has been added to track additional SUPPLIERs, and a relation of SHIPMENT added to track the event between PET and SUPPLIER relations.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

Revised normalized data model:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

258

259

Chapter 4

Pet store modified (Continued) Revised E-R Diagram:

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

3 - Transform Figure 4-40 EERD (University dining service) a and b – relational schema and functional dependencies

c. All relations are in 3NF.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

260

261

Chapter 4

3 - Authors and their books a. Functional dependencies

b. Current normal form The data has repeating groups and the relation does not have a name. Therefore, it is not in any normal form. c. Book 102 has the price $49.95 in one instance and the price $45.00 in another one. Publisher Wall & Vintage has Chicago, I L as its city in one instance and Indianapolis, I N in another.

Publisher Gray Brothers is misspelled as ―Grey Brothers‖ once. Boston, N H associated with the misspelled name is also incorrect.

Moving to 3NF 1NF: fill out the missing data for rows 2, 4, 6, and 7 of the table and give the relation a name.

AUTHORBOOKROYALTY(AID, ALName, AFName, AInst, BNbr, BName, BPublish, PubCity, BPrice, AuthBRoyalty) 2NF: Remove partial functional dependencies by ensuring that all non-key attributes are either directly or indirectly dependent on the entire primary key. AuthBRoyalty is the only attribute that is dependent on both AID and BNbr and thus, it stays with that composite primary key in AUTHORBOOKROYALTY. AUTHOR and BOOK become the other two relations.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

AUTHORBOOKROYALTY(AID, BNbr, AuthBRoyalty) AID references AUTHOR(A ID) BNbr references BOOK(BNbr) AUTHOR(AID, ALName, AFName, AInst) BOOK(BNbr, BName, BPublish, PubCity, BPrice) 3NF: Remove transitive dependencies. The only relation that has a transitive dependency is BOOK, in which PubCity is indirectly dependent on B Nbr. Therefore, we will need to create a separate PUBLISHER relation. After this, the relations are in 3N F. AUTHORBOOKROYALTY(AID, BNbr, AuthBRoyalty) AID references AUTHOR(A ID) BNbr references BOOK(BNbr) AUTHOR(AID, ALName, AFName, AInst) BOOK(BNbr, BName, BPublish, BPrice) BPublish references PUBLISHER(BPublish) PUBLISHER(BPublish, PubCity) 3 - Relation for computers, software, vendors, and users: a. Functional dependencies See next page for the solution.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

262

263

Chapter 4

b. This relation is not in 3NF as there are a number of issues with its structure. There are partial functional dependencies in this relation as the full primary key (from existing attributes) would be comprised of ComputerSerialNbr, SoftwareID, and UserID attributes that individually determine other attributes in the relation. A transitive dependency also exists with VendorID determining vendor information (and possibly VendorSupportID determining Vendor Support information). For the set of relations to be in 3N F, the structural problems caused by these dependencies in the data must be addressed.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

c. Set of relations in 3NF; Primary keys are underlined, foreign keys are in italics. (This solution uses composite keys for tables that link multiple tables.)

VENDOR(VendorID, VendorName, VendorPhone, VendorSupportID) VENDOR SUPPORT(VendorSupportID, VendorSupportName, VendorSupportExtension) COMPUTER(ComputerSerialNbr, PurchasePrice, VendorID) USER(UserID, UserName) SOFTWARE(SoftwareID, SoftwareName, SoftwareVendor) AUTHORIZATION(UserID, ComputerSerialNbr, SoftwareID, UserAuthorizationStarts, UserAuthorizationEnds, UserAuthorizationPassword) LICENSE(SoftwareID, ComputerSerialNbr, SoftwareLicenseExpires, SoftwareLicensePrice) Alternate Solution. Set of relations in 3NF; Primary keys are underlined, foreign keys are in italics. (This solution uses surrogate keys for tables that link multiple tables.)

VENDOR(VendorID, VendorName, VendorPhone, VendorSupportID) VENDOR SUPPORT(VendorSupportID, VendorSupportName, VendorSupportExtension) VENDOR(VendorID, VendorName, VendorPhone) COMPUTER(ComputerSerialNbr, PurchasePrice, VendorID) USER(UserID, UserName) SOFTWARE(SoftwareID, SoftwareName, SoftwareVendor) AUTHORIZATION(AuthID, UserAuthorizationStarts, UserAuthorizationEnds, UserAuthorizationPassword, UserID, ComputerSerialNbr, SoftwareID) LICENSE(LicenseID, SoftwareLicenseExpires, SoftwareLicensePrice, SoftwareID, ComputerSerialNbr) 3 - Online video rental service situation a. Functional dependencies

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

264

265

Chapter 4

b. This relation is not in 3NF as there are a number of issues with its structure. In fact, due to the repeating groups indicated by the sample data (multiple characters listed in the curly bracketed information), this relation is not even in first normal form (1N F). There are partial functional dependencies in this relation as the full primary key (from existing attributes) would be comprised of MovieNbr and MovieLicenseNbr attributes that individually determine other attributes in the relation. Transitive dependencies also exist with DirectorID determining Director information, StudioID determining Studio information, and ActorID determining Actor information. For the set of relations to be in 3NF, these dependencies in the data must be removed. c. Set of relations in 3NF; Primary keys are underlined, foreign keys are in italics.

MOVIE(MovieNbr, Title, DirectorID, StudioID) DIRECTOR(DirectorID, DirectorName)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

STUDIO(StudioID, StudioName, StudioLocation, StudioCEO) ACTOR(ActorID, ActorName) MOVIE CHARACTER(MovieNbr, Character, ActorID) MOVIE LICENSE(MovieNbr, MovieLicenseNbr, MovieLicenseType, LicenseRentalStatus, LicenseReturnDate) MOVIE RENTAL PRICE(MovieNbr, MovieLicenseType, MovieRentalPrice) 3 - On-line personal financial management system a. Functional dependencies See the following page for a diagram describing the functional dependencies.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

266

267

Chapter 4

b. Why not in 3NF? This data is not in 3NF. In fact, it is not in any normal form because the product level transaction data repeats within each transaction (i.e., there are repeating groups). In addition, there is no primary key nor does the relation have a name.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

268

c. Converting the data items into set of 3N F relations 1NF: Transforming the relation to 1N F requires removing the repeating groups (by filling out the missing transaction data for each detail row), identifying the primary key, and giving the relation a name.

TRANSACTIONDETAIL(TransactionID, CustomerID, CustomerName, CustomerEmail, TransactionDate, TransactionTime, TransactionTotalAmount, TransactionTax, ProductID, ProductDescription, ProductCategory, ProductManufacturerID, ManufacturerName, ProductListPrice, ProductPurchasePrice, ProductQuantity, TransactionProductTotal) 2NF: Partial functional dependencies need to be removed to organize the data items into 2N F relations. ProductPurchasePrice, ProductQuantity, and TransactionProductTotal are dependent on the entire primary key of the 1N F relation and thus, they will stay in the TRANSACTIONDETAIL relation. Other attributes will be placed in TRANSACTION and PRODUCT relations, as appropriate.

TRANSACTIONDETAIL(TransactionID, ProductID, ProductPurchasePrice, ProductQuantity, TransactionProductTotal) TransactionID references TRANSACTION(TransactionID) ProductID references PRODUCT(ProductID) TRANSACTION(TransactionID, CustomerID, CustomerName, CustomerEmail, TransactionDate, TransactionTime, TransactionTotalAmount, TransactionTax) PRODUCT(ProductID, ProductDescription, ProductCategory, ProductManufacturerID, ManufacturerName, ProductListPrice) 3NF: This normal form requires that we remove transitive dependencies, that is, make sure that all attributes in a relation are directly dependent on the primary key. This can be done be creating separate CUSTOMER and MANUFACTURER relations so that TRANSACTION and PRODUCT will become 3NF relations. The final relation set is as follows: TRANSACTIONDETAIL(TransactionID, ProductID, ProductPurchasePrice, ProductQuantity, TransactionProductTotal)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

269

Chapter 4

TransactionID references TRANSACTION(TransactionID) ProductID references PRODUCT(ProductID) TRANSACTION(TransactionID, CustomerID, TransactionDate, TransactionTime, TransactionTotalAmount, TransactionTax) CustomerID references CUSTOMER(CustomerID) CUSTOMER(CustomerID, CustomerName, CustomerEmail) PRODUCT(ProductID, ProductDescription, ProductCategory, ProductManufacturerID, ProductListPrice) ProductManufacturerID referencese MANUFACTURER(ProductManufacturerID) MANUFACTURER(ProductManufacturerID, ManufacturerName) d. ER Diagram

3 - Bus company a. Dependency diagram of functional dependencies (on next page) Note: In the current sample data, it appears that that combination of RouteID, ScheduleDate, and ScheduledDepTime act as a multi-attribute determinant of the Driver and Vehicle data. When you

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

270

know the Route (38), ScheduleDate (9/12/2021), ScheduledDepTime (9.30), and ScheduledArrTime (10.12), then you also know that a particular Driver (John Jones) is driving that particular scheduled route, and is certified to drive that particular Vehicle (id=5673, make=GreatTrucks, model=CityCoach). An alternative interpretation might be that the combination of RouteID, ScheduleDate, and DriverID act as a multi-attribute determinant of the remaining Schedule data along with the Vehicle data. Additional information from the bus company would be needed to accurately depict the appropriate functional dependencies, but would normally be acquired by later steps in the design process.

b. This relation is not in 3NF as there are a number of issues with its structure. In fact, due to the repeating groups indicated by the sample data (multiple characters listed in the curly bracketed information), this relation is not even in first normal form (1N F). There are partial functional dependencies in this relation as the full primary key (from existing attributes) would be comprised of RouteID, ScheduleDate, and ScheduledDepTime attributes that individually determine other attributes in the relation. Transitive dependencies also exist with DriverID determining Driver

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

271

Chapter 4

information, VehicleID determining Vehicle information, and the combination of DriverID, VehicleID, and Driver Certification Start Date determining the Certification end date information.

For the set of relations to be in 3NF, these dependencies in the data must be removed. c. A set of relations in 3NF; Primary keys are underlined, foreign keys are in italics.

ROUTE (RouteID, RouteStartPoint, RouteEndPoint, RouteStdDriveTime) SCHEDULE (RouteID, ScheduleDate, ScheduledDepTime, ScheduledArrTime, DriverID, VehicleID) CERTIFICATION (DriverID, VehicleID, DriverCertStartDate, DriverCertEndDate) DRIVER (DriverID, DriverFName, DriverLName, DateDriverJoinedCompany, DriverDOB) VEHICLE (VehicleID, VehicleMake, VehicleModel, VehiclePassengerCapacity) An alternative 3NF solution using non-intelligent and shorter primary keys is shown below. Primary keys are underlined, foreign keys are in italics.

ROUTE (RouteID, RouteStartPoint, RouteEndPoint, RouteStdDriveTime) SCHEDULE (ScheduleID, ScheduleDate, ScheduledDepTime, ScheduledArrTime, RouteID, DriverID, VehicleID) CERTIFICATION (CertID, DriverCertStartDate, DriverCertEndDate, DriverID, VehicleID) DRIVER (DriverID, DriverFName, DriverLName, DateDriverJoinedCompany, DriverDOB) VEHICLE (VehicleID, VehicleMake, VehicleModel, VehiclePassengerCapacity) a. EER diagram of the relations.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

272

b. Areas to expand data model.

Student answers may vary. One possibility is this model could be expanded to track the actual departure and arrival times of each scheduled route‘s operations.

Suggestions for Field Exercises 3For this exercise, we suggest you interview at least two organizations: a manufacturing company and a service sector organization. (You may choose to combine this exercise with Field Exercise 2 in Chapter 3). First, determine what methodology, if any, each uses for conceptual design: E-R diagrams, object diagrams, etc. Then determine how these models are transformed into logical data models (relational schema, object-oriented designs, etc.). To what extent are these activities

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

273

Chapter 4

automated through the use of CASE tools? If the target data model is relational, determine the role of normalization: who is responsible for normalization, to what level is it performed, and how are users involved (if at all) in these activities?

3We suggest you first perform this as an in-class exercise with student participation in the process.

Bring a copy of your own document to class, and ask the students to volunteer a document as well. This provides students with valuable ―hands-on‖ experience in the bottom-up design process.

3(You may choose to combine this exercise with Exercise 4-59 above). Student answers will vary depending on the organizations and the person who is the subject of the interview. We suggest that you use the student interview notes as a means of stimulating class discussion regarding the amount of variation in practice regarding the extent of normalization activities.

3This exercise is really a continuation of Exercise 4-60 above, now possibly applied to a more complex document. Use a report or other document that has detail lines and requires the use of normalization skills.

Project Questions 3 - Relational schema developed based on the EER diagram from 3-44.

ARTIST(ArtistID, LastName, FirstName, Gender, YearofBirth, Address, PhoneNumber, Email, ArtistType) INSTRUMENT(InstrumentID, InstrumentName) ArtistID references ARTIST(ArtistID) ARTISTINSTRUMENT(ArtistID, InstrumentID, PerformanceLevel) DEGREE(DegreeID, DegreeName, University)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

274

ARTISTDEGREE(ArtistID, DegreeID, Year) ArtistID references ARTIST(ArtistID) DegreeID references DEGREE(DegereeID) HONOR(HonorID, HonorDescription) ARTISTHONOR(ArtistID, HonorID) ArtistID references ARTIST(ArtistID) HonorID references HONOR(HonorID) NEWSITEM(NewsItemID, Source, Content) ARTISTNEWS(ArtistID, NewsItemID, Date) ArtistID references ARTIST(ArtistID) NewsItemID references NEWSITEM(NewsItemID) CONTRACTEDARTIST(ArtistID, AManagerID) ArtistID references ARTIST(ArtistID) AManagerID references ARTISTMANAGER(AManagerID) SAMPLE(SampleID, SampleContent, ArtistID) ArtistID references ARTIST(ArtistID) PROSPECTIVEARTIST(ArtistID) ArtistID references ARTIST(ArtistID) RECOMMENDATION(RecommendationID, Summary, QualityEvaluation, Original, ReceivedDate, CreatedDate, ArtistID, SourceID) ArtistID references PROSPECTIVEARTIST(ArtistID) SourceID references SOURCE(SourceID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

275

Chapter 4

SOURCE(SourceID, Name, Type, Quality) ARTISTCOMMITMENT(ACommentmentID, StartDate, StartTime, EndDate, EndTime, ArtistID, CommitmentType) ArtistID references CONTRACTEDARTIST(ArtistID) PERSONALC(ACommitmentID, Firmness) ACommitmentID references ARTCOMMITMENT(ACommitmentID) PERFORMANCERELATEDC(ACommitmentID, Category, EventID) ACommitmentID references ARTCOMMITMENT(ACommitmentID) EventID references EVENT(EventID) CONTRACT(ContractID, StartDate, EndDate, RoyaltyPercentage, Terms, ArtistID) ArtistID references CONTRACTEDARTIST(ArtistID) EXPENSE(ExpenseID, Description, Amount, AccountNbr, ExpenseType) ARTMGREXPENSE(ExpenseID, AManagerID) ExpenseID references EXPENSE(ExpenseID) AManagerID references ARTISTMANAGER(AManagerID) ARTISTEXPENSE(ExpenseID, ArtistID) ExpenseID references EXPENSE(ExpenseID) ArtistID references CONTRACTEDARTIST(ArtistID) ARTISTMANAGER(AManagerID, LastName, FirstName) ADMIN(AdminID, LastName, FirstName, AManagerID) AManagerID references ARTISTMANAGER(AManagerID) ARTISTPAYMENT(APaymentID, Date, Amount, AdminID, ArtistID)

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

276

AdminID references ADMIN(AdminID) ArtistID references CONTRACTEDARTIST(ArtistID) VENUE(VenueID, Name, Address, Country) CUSTOMER(CustomerID, Name, Address) CUSTOMERPAYMENT(CPaymentID, Date, Amount, CustomerID) CustomerID references CUSTOMER(CustomerID) EVENT(EventID, EventDescription, Date, Time, VenueID, CustomerID) VenueID references VENUE(VenueID) CustomerID references CUSTOMER(CustomerID) AGREEMENT(AgreementNbr, Date, GrossAmount, AtSourceTaxWithheld, Terms, EventID, ContractID) EventID references EVENT(EventID) ContractID references CONTRACT(ContractID) INVOICE(InvoiceNbr, Date, Total) INVOICEPAYMENT(InvoiceNbr, PaymentID, Amount) InvoiceNbr references INVOICE(InvoiceNbr) PaymentID references CUSTOMERPAYMENT(CPaymentID) 3 - Analyze and document the functional dependencies in 4-63.

Note: Although the question asks you to base the E-R diagram on Question 1-52, students should also consider the work they did for 2-59.

Answers will depend on each student‘s solution for 4-63.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

277

Chapter 4

3 - Discuss the use of enterprise keys.

Given the scope of the system and the company, it is unlikely that the use of enterprise keys would produce significant benefits.

3 - If necessary, modify the EER diagram.

As an example, please see page 70 for an updated E ER diagram that has been modified by discoveries during the conversation process. This is quite typical, and it is important for the students to realize that there is nothing wrong about these types of discoveries, as long as they will be implemented to improve the quality of the solution.

Copyright © 2022, 2019, 2016 Pearson Education, Inc.

Chapter 4

200

Question 4-66 Figure 1

Chapter 5 Introduction to S QL Chapter Overview This chapter describes in detail what has become the standard query language for relational database management systems, S QL. Although SQL is illustrated in this chapter primarily through a current Oracle version (MySQ L and Microsoft Access S QL are also sometimes displayed), S QL is a widely used language that is available on all classes of computers and with many different D BMS. In addition, it

201

Chapter 4

serves as a foundation for many data manipulation and definition languages in the emerging No SQL category of tools.

This chapter introduces S QL and emphasizes the Data Definition Language (D DL) and Data Manipulation Language (D ML) commands. Single table queries are covered in this chapter, and multiple-table queries are covered in Chapter 6.

Several chapters contain important prerequisite material for this chapter. Chapter 4 introduces the relational model and provides much of the background for this chapter (including an introduction to the Data Definition Language commands). The discussion in Chapter 8 on indexes is also important because choosing primary and secondary key indexes is one of the few, but crucial, internal database design choices for users of relational systems.

Chapter Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Explain SQL and show the basic operators so that the student can anticipate the capabilities of particular SQL-based systems.

2. Provide a historical perspective of the development of S QL and its continuing development. This perspective illustrates the benefits and risks of adopting a standard query language.

3. Show that S QL, although a standard and a high-level language, does have some flaws, and that S Q L must evolve to include additional features.

4. Explain and illustrate the power of relational views for simplifying relational database processing.

5. Demonstrate the basic actions that are required to move from a logical data model to a database implementation, including specification of data types and foundational indexing.

6. Illustrate data definition language (D DL) commands for creating tables and views as well as modifying and dropping tables.

7. Show how to establish referential integrity using S QL.

Chapter 4

202

8. Enable students to gain foundational competencies with data retrieval using simple (single table) S Q L queries.

9. Provide some examples of the use of functions within S QL queries.

10. Illustrate the use of the GROUP BY and ORDER BY clauses.

Key Terms Catalog

Data manipulation language (D ML)

Schema

Data control language (DCL)

Relational DBMS (RDBMS)

Vector aggregate

Data definition language (DDL) Scalar aggregate

Classroom Ideas 1. Depending on how you choose to sequence the chapters of this book, you may want to begin lecturing on this chapter by reviewing normalization principles and discussing why one might want to implement a fully normalized database. The point is to emphasize the difference between logical and physical database designs already here, even though that is fully covered in Chapter 8.

2. The sequencing of foundational coverage of Data Definition Language and Data Manipulation language is a matter of personal preference. We believe that it makes sense to first give the students a preview of the very basic D ML commands, then introduce database creation with D DL, and then move to more sophisticated aspects of DML. The chapter includes a sufficient amount of material on physical database design to build a bridge between logical database design (covered in Chapter 4) and the database implementation process.

3. With the variety of S QL implementations now available, we strongly recommend that you illustrate some SQL system in class and have the students use such a system. The Pine Valley Furniture case in the text provides a rich context in which to develop examples that emphasize those aspects of S Q L the instructor considers most important. We have found that students learn S QL best by seeing and doing many examples and experimentation, so we encourage teaching S QL by example. When teaching S QL, we often spend about 15 minutes giving an overview of the evolution of S QL and providing some basic syntax and terminology. Then we spend between two and six hours in live demonstrations showing simple to complex queries in a well-designed sequence. In a computer-

203

Chapter 4

enabled classroom where an S QL system can be demonstrated to and used by students, this time can be an effective, interactive learning experience.

All the SQL queries in this chapter can be found in a Microsoft Access database available from the publisher; you can show in class how Access SQL varies from standard SQL, and you can show variations on the queries from this chapter. In addition, a set of lab exercise queries are available in the book for use with the Pine Valley Furniture Company case. These queries are designed to work with a database that is close to, but not exactly, the data model in Figure 2-22.

4. Because many S QL systems include other modules (report writers, business graphics routines, screen painters, and so forth), this chapter can be expanded to discuss fourth-generation languages and systems prototyping. Explain that most packages include capabilities and development tools that are more than simply a relational D BMS and query language. If your school has joined the Oracle Academy, it may be possible to demonstrate additional tools such as S QL Developer and/or Designer/2000. Additionally, Oracle provides universal and free access to its Express Edition with a Java-based application development environment, which can easily be used on individually-owned computers.

5. One interesting discussion item is the widespread and continued use of S QL in most types of administrative systems, regardless of the system type and architecture. S QL has been one of the most durable components of corporate computing architectures during the past 20-30 years, and it still does not show signs of aging.

6. It should be emphasized that S QL is still fundamentally a programming language for the professional programmer. That is, SQL is not really a suitable language for end-user system development. This does not diminish its importance because it provides professional programming staff with productivity gains and is used extensively by database administrators. Many of your students are likely to hold these positions during their careers. Other user interface types, such as Query By Example, are more appropriate for end users.

7. The apparent simplicity of the S QL syntax leads some students to become overconfident of their S Q L prowess. It may help to develop some examples to demonstrate that logically and syntactically correct SQL queries can be constructed that do not accomplish the intended data manipulation and may be dangerously incorrect. For example, two tables may be joined using common domains (for instance, positive integers) but non-common roles (for example, two tables can be joined on equal

Chapter 4

204

values of quantity-on-hand of a product and number of employees in a department). Such potential problems arise because the relational data model uses implicit relationships, not explicit ones. Stress the importance of testing a query on a small, tractable set of data before using it in a production environment.

Answers to Review Questions 3 - Define each of the following key terms: a. Data definition language. Those commands used to define a database, including creating, altering, and dropping tables and establishing constraints b. Data manipulation language. Those commands used to maintain and query a database, including updating, inserting, modifying, and querying data. c. Referential integrity constraint. An integrity constraint specifying that the value or existence of an attribute in one relation depends on the value or existence of a primary key in the same or another relation. Referential integrity means that a value in the matching column on the manyside must correspond to a value in the primary key for some row in the table on the one-side, or be null. d. Relational DBMS (RDBMS). A database management system that manages data as a collection of tables in which all data relationships are represented by common values (not links) in related tables e. Schema. A structure that contains descriptions of objects created by a user, such as base tables, views, constraints, and so on, as part of a database 3 - Match the following terms to the appropriate definitions: f

referential integrity constraint

g

SQL:2016

c

null value

h

scalar aggregate

a

vector aggregate

205

Chapter 4

b

catalog

d

schema

e

host language

3 - Contrast the following terms: a. Scalar aggregate; vector aggregate. A scalar aggregate is a term used to denote a single value that an aggregate function returns. If a query including a GROUP BY clause returns a list of values, the result is referred to as a vector aggregate. b. DDL; DML. DDL, or Data Definition Language, refers to the aspects of the S QL language that can be used to define and manage the structure of databases and their components, whereas D ML refers to the elements of S QL that are used to retrieve and modify the content of the database. c. Catalog; schema. Schema is a structure that contains descriptions of objects created by a user, such as base tables, views, constraints, and so on. These objects have been defined for a particular database by a particular user, who owns those objects in the schema. The catalog is a set of schemas, which, when put together, constitute a description of a database. (If more than one user has created objects in the database, combining information about all their schemas will yield information for the entire database.)

3 - History leading up to SQL:2016: a. To provide direction for the development of R DBMS, the American National Standards Institute (A NSI) and the International Organization for Standardization (IOS) approved a standard for the S Q L relational query language functions and syntax proposed originally by the X3H2 Technical Committee on Database (Technical Committee X3H2 Database, 1986; I SO, 1987). This standard is often referred to as SQL/86. The 1986 standards have been extended to include an optional Integrity Enhancement Feature (I EF), often referred to as S QL/89. The ISO and ANSI committees created SQL-92 (Technical Committee X3H2 Database, 1989; I SO, 1989, 1991), which was a more extensive expansion of S QL/86. This standard was ratified in late 1992, and is known as International Standard I SO/IEC 9075:1992, Database Language S QL (or SQL-92).

Later SQL standards include S QL:1999, SQL:2011, and SQL:2016.

Chapter 4

206

b. SQL:2016 provides many enhancements to S QL:1999, including predefined data types, type constructors, scalar, and table expressions. Temporal extensions are an important addition available in S QL:2011. SQL/XML was introduced in S QL:2003, as were columns with autogenerated values (typically used as identity columns). Use of X ML in the SQL context was significantly expanded in S QL:2006. SQL:2016, in turn, provides support for J SON and pattern matching at the row level.

3 - Temporal extensions in SQL:2011 The temporal extensions in S Q L:2011 include mechanisms with which database designers and various types of users of a relational database can explicitly specify, manipulate, and query phenomena related to data values that change over time. Temporal extensions are discussed at a more detailed level in Chapter 6.

3-

Describe a relational D B M S (R D B M S), its underlying data model, data storage structures, and manner of establishing data relationships: a. A relational DBMS (or RDMBS) is a data management system that implements a relational data model. b. Data are stored in a collection of tables, and the data relationships are represented by common values, not links. c. The relational data model assumes that a table is a logical construct rather than a physical construct, so a table need not correspond to a physical file of contiguous records. The same data model may have many different possible physical implementation structures. The storage of the database is dependent on both the hardware and software environment. It is usually the concern of the system administrator. d. The power of the RDBMS is realized through relationships existing between tables. These relationships are established by including a common column(s) in each table where a relationship is needed.

3 - Six potential benefits of achieving a widely accepted S QL standard: a. Reduced training costs. Training in an organization can concentrate on S QL, and a large labor pool of IS professionals trained in a common language reduces retraining when hiring new employees.

207

Chapter 4

b. Productivity. IS professionals can learn S QL thoroughly and become proficient with it from continued use, the organization can afford to invest in tools to help I S professionals become more productive, and programmers can more quickly maintain existing programs because they are familiar with the language in which programs are written. c. Application portability. Applications can be moved from machine to machine when each machine uses SQL. Further, it is economical for the computer software industry to develop off-the-shelf application software when there is a standard language. d. Application longevity. A standard language tends to remain so for a long time, so there will be little pressure to rewrite old applications. Rather, applications will simply be updated as the standard language is enhanced or new versions of D BMS are introduced. e. Reduced dependence on a single vendor. When a nonproprietary language is used, it is easier to use different vendors for the DBMS, training and educational services, application software, and consulting assistance. Further, the market for such vendors will be more competitive, which may lower prices and improve service. f. Cross-system communication. Different DBMS and application programs can more easily communicate and cooperate in managing data and processing user programs.

3 - The components and structure of a typical SQL environment: The S Q L environment includes an instance of an S Q L D B M S along with accessible databases and associated users and programs. Each database is included in a catalog and has a schema that describes the database objects. Information contained in the catalog is maintained by the D B M S itself, rather than by the users of the DBMS. 3-

Distinguish among data definition commands, data manipulation commands, and data control commands: a. The data definition language (D DL) commands of SQL are used to define a database, including its creation and the creation of its tables, indexes, and views. Referential integrity is also established through DDL commands. CREATE/DROP DICTIONARY, CREATE/DROP TABLE, ALTER TABLE, CREATE/DROP INDEX, CREATE/DROP VIEW are examples of D DL commands.

Chapter 4

208

b. The data manipulation (DML) commands of SQL are used to load, update, and query the database through the use of the SELECT command. (START TRANSACTION, COMMIT WORK, ROLLBACK WORK, INSERT, UPDATE, and DELETE are examples of D ML commands.) c. Data control language (DCL) commands are used to establish user access to the database through the GRANT, ADD USER, and REVOKE commands.

3 - The primary data integrity constraints in S QL: The most important mechanism for supporting data integrity in S QL is the REFERENCES statement to enforce referential integrity. In addition, a particular column can be specified as NOT NULL, and it is also possible to use the CHECK statement to verify that input values satisfy specific criteria. In addition, it is possible to specify default values with the DEFAULT statement.

3-

Establishing referential integrity using an SQL:1999 compliant database and the differences among the ON UPDATE RESTRICT, ON UPDATE CASCADE, and ON UPDATE SET NULL clauses, and results of declaring ON DELETE CASCADE: a. The SQL REFERENCES clause is used to establish referential integrity and prevents a foreign key value from being added if it is not already a valid value in the referenced primary key column. b. The ON UPDATE RESTRICT clause allows a row to be deleted in a parent table only if no record in the child table references the primary key value to be deleted in the parent table. The ON UPDATE CASCADE clause will cause a change in a primary key value of a parent table to be passed through and update the foreign key value in the related child table. The ON UPDATE SET NULL option allows the update on the parent table, but changes the involved foreign key value in the child table to NULL. Using the SET NULL option would result in losing the connection between the parent and child tables, not a desired effect. c. With DELETE CASCADE, removing the primary key value in the parent table also removes all associated records from the child table.

209

Chapter 4

3 - Purpose of indexing in database implementation: The main purpose of indexing is to make data retrieval faster and reduce the variance of data retrieval times.

3 - Potential consequences of inappropriate indexing decisions: It is essential to avoid indexing on too many columns because excessive indexing slows down inserting new data and modifying existing data. In addition, every index requires storage space.

3 - Factors to be considered in deciding whether to create an index for a column in S QL: a. A key index on one column or a concatenation of columns enables rapid access to the rows of a table in a sequence or randomly by key value. b. Choosing to index primary and/or secondary keys may increase the speed of row selection, table joining, and row ordering. c. Dropping indexes will increase the speed of table updating.

3 - Qualifying the ownership of a table in SQL: Placing the I D of the owner prior to the table name and attribute name indicates ownership of a table. For example, if the user with the User_ID of ORTEGA owns the CUSTOMER_T table, that ownership would be indicated as ORTEGA.CUSTOMER_T. In order for one user to be allowed to use a table in the database owned by another user, the non-owner user must be granted authorization to use it, usually by the database administrator.

3 - Attribute order and column heading labels in a result table: a. Attributes are displayed in columns in the sequence in which they are listed in the SELECT list unless the SELECT list is *, in which case all attributes from the referenced tables are displayed in the sequence in which they are defined. b. Use AS to specify column heading labels, e.g., SELECT CUST. CustomerName AS NAME will result in a column heading label NAME instead of CustomerName.

3-

COUNT, COUNT DISTINCT, and COUNT(*) in S QL and the results generated when using these: a. COUNT tallies only those rows that contain a value; it ignores all null values. b. COUNT DISTINCT does not return a count on all values; it only tallies once if more than one row has equal values.

Chapter 4

210

c. COUNT (*) counts all rows regardless of whether any of the rows contain null values. d. If we never use NULL values, COUNT and COUNT(*) will return the same results. If our table includes no duplicates in the considered attribute values, COUNT and COUNT DISTINCT will have the same meaning.

3-

Evaluation order for the Boolean operators (AND, OR, NOT) in an S QL command; getting the operators to work in the order that you want: a. If multiple Boolean operators are used in an S QL statement, NOT is evaluated first, then AND, then OR. b. With the use of parentheses around statements using standard mathematical notation, a set of statements may be given a user-chosen specific order of evaluation.

3-

Limitations on attributes that can be selected when an S QL statement contains GROUP BY: Only those columns that have a single value for each group can be included.

3-

HAVING clause usage: The HAVING clause is useful when you need to select results based upon qualifications on an aggregation, such as a characteristic of a group. For example, if we have a table with transactional sales data for salespeople, we may want to sum up the total sales for a given period of time (an aggregate). We may then want to produce a list of only salespeople who sold more than a certain amount, say $1,000. This can be done using the HAVING clause.

3-

IN operator usage: The IN operator is used in conjunction with the WHERE clause. A set of valid selections for the IN operator within parentheses follows the operator [e.g., I N ('W A', 'C A')]. The OR operator can be used to perform the same operation as the I N operator. For example, if part of our WHERE clause is State I N ('M A', 'N H'), this could be substituted with State = 'MA' OR State = 'NH'.

3-

Determining the order in which the rows appear in the S Q L query response set. Options when specifying the order: The ORDER BY clause can be added to an S Q L query to determine the order in which the rows appear in the final response set. The sorting order can be either ascending (ASC) or descending (DESC).

3 - SQL as a set-oriented language S Q L is considered a set-oriented language because it processes sections (or sets) of table data that meet certain criteria (e.g., products that are desks or tables, for instance) with other sections (or sets) of table data that meet other criteria (e.g., products having a standard price above $300). S Q L will ―grab‖ the data that meets the criteria, hold it in a temporary work area(s), then using logical UNION and INTERSECTION

211

Chapter 4

commands find the ―result set‖ that meets all criteria specified by the S Q L statements. A set-oriented language, like S Q L, is presented in contrast to a record-oriented language (such as C, Java, and COBOL) that must process one record/row of a table at a time.

3 - LIKE keyword usage: CREATE TABLE LIKE is a quick way to clone a table.

3 - Identity column definition and usage: The identity column creates a numeric sequence. For example, if we create the following table: CREATE TABLE Test1_T (ID SMALLINT IDENTITY(5,2),…) then the first record added to Test1_T table will have 5 as its value for the I D column. Subsequent record I Ds will be incremented by 2.

This is beneficial because it allows a way to automatically generate a unique number, such as an I D. Please note that this does not work in Oracle; IDENTITY is a SQL Server specific command.

3 - Merge keyword usage: Prior to S Q L:2006 and S Q L:2008, one had to use both insert and update to update and merge data into a table. The Merge command allows one to do this in a single step. A common use for this would be updating the master table from a transaction table where one might want to update records or create new records in the master table based upon what was done in the transaction table. Let‘s take a look at an example: Suppose that we have an item table and a shipment table. The Item table contains all of the items and the Shipment table contains items received by the company.

Item Table ItemNo

Description

Quantity on Hand

342

MacBook Pro

10

345

Lenovo P C

55

346

4GB Memory

100

347

500GB HD

6

Chapter 4

212

Shipment Table ItemNo

Description

Quantity Received

342

MacBook Pro

1

345

Lenovo P C

5

347

500GB HD

3

352

1T B External Drive

4

Notice that there is one additional item in the Shipment table. Now, let‘s write the merge statement to update the Item table. If the record exists in Item, then we will add to the quantity on hand. If it does not, then we will add the record.

MERGE INTO Item_T AS ITM USING (SELECT ItemNo, Description, QuantityReceived FROM Shipment_T) AS SH ON (ITM.ItemNo = SH.ItemNo) WHEN MATCHED THEN UPDATE SET QuantityOnHand = ITM.QuantityOnHand + SH.QuantityReceived WHEN NOT MATCHED THEN INSERT (ItemNo, Description, QuantityOnHand) VALUES (SH.ItemNo, SH.Description, SH.QuantityReceived); 3 - SQL clause processing order: In a SELECT statement, the processing of clauses follows the order shown in Figure 5-10, and reproduced below: o the FROM clause is evaluated first (sources of data) o then: WHERE (criteria to be met, if stated), and/or GROUP BY (organizes rows according to values in stated column(s)), and HAVING (finds groups meeting criteria), and o then SELECT (particular columns to show/display), and o then ORDER BY (sorts rows in result table).

3 - SQL clause & derived table creation: A derived table can be defined in the FROM clause of an SQL statement.

213

Chapter 4

3 - ORDER BY clause & sort order: In an ORDER BY clause, the columns to be sorted can be referred to by: (1) column name from the actual table referenced in the FROM clause, or (2) column position in the SELECT clause list.

3 - CHECK clause usage: In a CREATE TABLE command, the CHECK clause allows for validation rules for values to be inserted into the database, such as only allowing the Product_T table to have rows of products that meet a checklist of certain ProductFinish values (e.g., such as Cherry, Natural Ash, White Ash, Red Oak, Natural Oak, and Walnut).

3 - ALTER command usage: The ALTER command may be used to add new columns, change existing columns (name, data type, length, constraints, and default values), delete columns, add constraints, and delete constraints of a Table. The ALTER command may not be used with Views, nor can the ALTER command change the order of columns within a Table.

3 - Difference between the WHERE and HAVING clauses in an S QL query This difference is relevant for aggregate queries using GROUP BY because that is the context in which HAVING is used. The WHERE clause limits the number of rows that will be considered in the processing specified in the S Q L query, whereas HAVING is used to limit output rows (summarized groups) based on criteria that apply to aggregate function values. For example, let‘s assume that we have products and product lines in a simple database, and we want to know the average product price by product line but limit the results to a) only to those products that cost more than $1,000 and b) to those product lines where the average price is higher than $10,000. The following query achieves that: SELECT ProdLineNbr, AVG(ProdPrice) FROM Product WHERE ProdPrice > 1000 GROUP BY ProdLineNbr HAVING AVG(ProdPrice) > 10000; In this case, WHERE limits the query to consider only those Products that cost more than $1,000 and HAVING limits the output to those Product lines that have an average ProdPrice greater than $10,000.

3 - Usage of both WHERE and HAVING clauses?

Yes, a query may use both the WHERE and HAVING clauses, and many do. The WHERE clause would restrict which rows are included for processing by the query. The HAVING clause (used in conjunction with a GROUP BY clause) determines which summarized groups are included in the result set.

Answers to Problems and Exercises

Chapter 4

214

Note to Instructor: The solutions that include S Q L statements are not intended as the definitive answer to the questions, but as examples of correct solutions. Instructors and students will approach the problems using different SQL capabilities, achieving results that are also correct.

Solutions are presented with S Q L syntax that should work in most Oracle installations (unless noted otherwise; for example, some examples follow the M S Access syntax). Solutions may need to be modified for a particular Oracle installation or if you are using a different relational database management system (e.g., Teradata) to illustrate the use of S Q L commands. The solutions in this chapter and the following chapter use the naming conventions for tables, relations, attributes/columns, and views as shown in the textbook chapters, although Oracle S Q L is not Upper/Lower case sensitive except when querying metadata (e.g., table names).

3 - Database descriptions: Note: A particular S Q L system may restrict the length of column names or may not permit embedded spaces in names. The following answer may not be acceptable to the S Q L system you use; please modify the grammar accordingly.

CREATE TABLE Student (StudentID NUMBER NOT NULL, StudentName VARCHAR2(25), CONSTRAINT Student_PK PRIMARY KEY (StudentID)); CREATE TABLE Faculty (FacultyID NUMBER NOT NULL, FacultyName VARCHAR2(25), CONSTRAINT Faculty_PK PRIMARY KEY (FacultyID)); CREATE TABLE Course (CourseID CHAR(8) NOT NULL, CourseName VARCHAR2(15), CONSTRAINT Course_PK PRIMARY KEY (CourseID)); CREATE TABLE Section (SectionNo NUMBER NOT NULL, Semester CHAR(7) NOT NULL, CourseID CHAR(8), CONSTRAINT Section_PK PRIMARY KEY(SectionNo), CONSTRAINT Section_FK FOREIGN KEY (CourseID) REFERENCES Course (CourseID)); CREATE TABLE Qualified (FacultyID NUMBER NOT NULL, CourseID CHAR(8) NOT NULL, DateQualified CHAR(7), CONSTRAINT IsQualified_PK PRIMARY KEY (FacultyID, CourseID), CONSTRAINT QualifiedFaculty_FK FOREIGN KEY (FacultyID) REFERENCES Faculty (FacultyID), CONSTRAINT QualifiedCourse_FK FOREIGN KEY (CourseID) REFERENCES Course (CourseID)); CREATE TABLE Registration (StudentID NUMBER NOT NULL, SectionNo NUMBER NOT NULL, CONSTRAINT IsRegistered_PK PRIMARY KEY (StudentID, SectionNo),

215

Chapter 4

CONSTRAINT StudentIsRegistered_FK FOREIGN KEY(StudentID) REFERENCES Student(StudentID), CONSTRAINT CourseIsRegistered_FK FOREIGN KEY (SectionNo) REFERENCES Section(SectionNo)); 3 - Normalization status of the database In its current form, the data is fully normalized.

3 - Creating a view CREATE VIEW Student_V AS SELECT StudentID, StudentName FROM Student; 3 - Referential integrity & S QL clause usage in DDL See the SECTION_FK constraint in the DDL for the SECTION table in Problem and Exercise 5-34 above.

3 - SQL Definition commands a.

ALTER TABLE Student ADD Class VARCHAR2(5); b.

DROP TABLE Registration; c. You cannot drop the COURSE table without modifying the SECTION table so that it does not reference the COURSE table with the CourseID foreign key. d.

ALTER TABLE Faculty MODIFY FacultyName VARCHAR2(40); Note: CHANGE instead of MODIFY also usually works.

3 - SQL commands: INSERT, DELETE, UPDATE a.

INSERT INTO Student (StudentID, StudentName) VALUES (65798, 'Lopez'); INSERT INTO Student VALUES (65798, 'Lopez');

Chapter 4

b.

DELETE FROM Student WHERE StudentID = 65798; c.

DELETE FROM Student WHERE StudentName = 'Lopez'; d.

UPDATE Course SET CourseName = 'Introduction to Relational Databases' WHERE CourseID = 'ISM 4212'; 3 - SQL queries a.

SELECT StudentID, StudentName FROM Student WHERE StudentID < 50000; b.

SELECT FacultyName FROM Faculty WHERE FacultyID = 4756; c.

SELECT MIN(SectionID) FROM Registration WHERE Semester = 'I-2021'; 3 - SQL queries a.

SELECT COUNT(*) FROM Registration WHERE Section = 2714 AND Semester = 'I-2021'; b.

SELECT FacultyID FROM Qualified

216

217

Chapter 4

WHERE CourseID = 'ISM 3113'; c.

SELECT FacultyID,CourseID,DateQualified FROM Qualified WHERE DateQualified >= '01-JAN-2014' /* assumes that the DateQualified column is DATE */ SELECT FacultyID,CourseID,DateQualified FROM Qualified WHERE TO_NUMBER(SUBSTR(DateQualified, LENGTH(DateQualified)-4,4)) > 2013; /* assumes that the DateQualified column is CHAR as in the sample data set */ 3 - SQL queries a. We assume all the question wants in the result set are the Student I Ds. The Database course is I SM 4212, which is Section 2714 in the Registration table, and the Networking course is I SM 4930, which is Section 2715 in the Registration table: SELECT FROM WHERE GROUP BY HAVING

StudentID,COUNT(*) Registration SectionNo IN (2714,2715) StudentID COUNT(*) > 1;

b. In answering this question, we assume we are not interested in seeing those instructors who can teach neither course, but rather only those who can teach one but not the other course. To find those instructors who can teach one course or the other requires S QL capabilities introduced in Chapter 6: SELECT FROM WHERE GROUP BY HAVING

FacultyID,COUNT(*) Qualified CourseID IN ('ISM 3113', 'ISM 3112') InstructorID COUNT(*) = 1;

c. Using Chapter 5 S QL tools, a user could use two single table queries over the SECTION table and then manually inspect the results to find the courses that are taught in first semester but not in the second semester. This manual inspection solution works moderately well when there are few rows in the tables. Another possible manual solution is to list all the courses sorted by CourseID and Semester from the SECTION table, and then manually inspect the entries to find

Chapter 4

218

those with only first semester offerings. Again, this approach works moderately well if there are few rows in the tables.

Using some Chapter 6 tools, the following query could be used to find the requested information from the database: SELECT CourseID, Semester FROM Section WHERE Semester = 'I-2021' AND CourseID NOT IN (SELECT CourseID FROM Section WHERE Semester = 'II-2021'); 3 - SQL queries a.

SELECT FROM

DISTINCT CourseID Section;

b.

SELECT StudentName FROM Student ORDER BY StudentName; c.

SELECT FROM WHERE ORDER BY

SectionNo,Semester,StudentID Registration Semester = 'I-2021' SectionNo,Semester,StudentID;

d.

SELECT CourseID,CourseName FROM Course ORDER BY CourseID ASC; 3 - SQL queries a.

SELECT FROM WHERE

SectionNo Section CourseID = 'ISM 3113' AND

219

Chapter 4

Semester = 'I-2021'; b.

SELECT FROM WHERE

CourseID, CourseName Course CourseName LIKE 'Data%';

SELECT FROM WHERE GROUP BY HAVING

FacultyID Qualified CourseID IN ('ISM 3112', 'ISM 3113') FacultyID COUNT(CourseID)>1;

c.

d.

SELECT FROM WHERE

FacultyID, COUNT(CourseID) Qualified CourseID IN ('ISM 3112', 'ISM 3113') AND TO_NUMBER(SUBSTR(DateQualified, LENGTH(DateQualified)-4,4)) > 2014 GROUP BY FacultyID; HAVING COUNT(CourseID)>1; Note: There are no instances of this in the sample data set. e.

This query requires the missing Assignment table and use of data from multiple tables SELECT FacultyID FROM Assignment WHERE Semester = 'II-2021' AND SectionNo IN ( SELECT SectionNo FROM Section WHERE CourseID = 'ISM 4212'); 3 - SQL queries a. 123

b. 123

SELECT FROM GROUP BY SELECT

CourseID, COUNT(FacultyID) Qualified CourseID; SectionNo, COUNT(StudentID)

Chapter 4

220

FROM Registration GROUP BY SectionNo HAVING COUNT(StudentID)>1; c. 123 SELECT FROM WHERE GROUP BY

CourseID, COUNT(SectionNo) Section Semester = 'II-2021' CourseID;

Problems and Exercises 5-46 through 5-56 are based on Figure 5-12, Adult Literacy situation

3a. Query: How many tutors have status of Temp Stop?

SELECT FROM WHERE

COUNT(TutorID) AS NUMTSTOP Tutor Status = 'Temp Stop';

b. Query: Which tutors are active?

SELECT FROM WHERE

TutorID Tutor Status = 'Active';

3 - SQL queries a. Query: What is the average Read score for all students?

SELECT FROM

AVG(Read) Student;

b. Query: What are the minimum and maximum Read scores?

SELECT FROM

MIN(Read), MAX(Read) Student;

3 - Query: List the IDs of the tutors who are currently tutoring more than one student.

SELECT FROM GROUP BY HAVING

TutorID MatchHistory TutorID COUNT(StudentID)>1;

3 - Query: What are TutorIDs for tutors who have not yet tutored anyone?

Using Chapter 6 tools, a user could formulate two single table queries over the database and then manually inspect the query results to find the required information. For instance, a query over the TUTOR table will

221

Chapter 4

provide TutorIDs of all Tutors and a query of DISTINCT TutorIDs from the MATCH_HISTORY table will provide a listing of all currently matched Tutors. By manual inspection of these two query result lists, one can find the ―missing‖ TutorIDs from the MATCH_HISTORY table. For a database such as this one, with a small number of rows, a user could still find the information easily. As tables grow in size, such a multiple step manual inspection process becomes less feasible as a practical matter.

Using Chapter 6 tools, the following query could be used to get the information: SELECT TutorID FROM Tutor WHERE TutorID NOT IN (SELECT TutorID FROM MATCH_HISTORY); 3 - Query: How many students are matched with someone in first five months of year?

SELECT COUNT(StudentID) FROM Match_History WHERE StartDate BETWEEN '01-JAN-2021' AND '31-MAY-2021'; 3 - Query: Which student has highest Read score?

SELECT Read, StudentID FROM Student ORDER BY Read DESC; Note to Instructor: For 5-51 and 5-53, be sure the student realizes that a null value in ENDDATE means that a student is still studying in the program and should be included in the calculation. This is a good opportunity for the student to discover that a calculated field can be quite useful where null values can be expected. You may want to emphasize that this query will not update the base table and these null values will remain until a student leaves the program.

3 - Query: Show the average, maximum, and minimum Read score per student group.

SELECT Group, AVG(Read), Max(Read), Min(Read) FROM Student GROUP BY Group; 3This answer is shown in M S ACCESS S Q L and uses the N Z function, which is not covered in the text, to deal with the null dates. If no date is entered as an end date in the dialog box, today‘s date is inserted automatically for null values. As the N Z function is used here, it will return the number of days the student has studied into the calculated field.

Query: How long had each student studied in the adult literacy program?

SELECT StudentID, StartDate, EndDate, DateDiff(―d‖,[StartDate],NZ([EndDate], NZ [Enter date for blank records], Date()))) AS TotalDays FROM Match_History;

Chapter 4

3-

Query: Which tutors have a Dropped status and have achieved their certification after 4/01/2021?

SELECT FROM WHERE

3-

TutorID Tutor Status = 'Dropped' AND CertDate > '1-APR-2021';

Query: How many courses have an Active status in the database?

SELECT FROM WHERE

3-

222

COUNT(TutorID) TUTOR Status = 'Active';

Query: What is the average length of time a student stayed (or has stayed) in the program?

This query needs to use the TotalDays information calculated in 5-53, but as the average function aggregates all rows, a two-step query will be needed to complete the problem. This problem also demonstrates using a query as the base for another query rather than working from a base table. a. Query (Answer assumes this query is named CH6P56_First Query): SELECT DateDiff('d',[StartDate],NZ([EndDate], NZ [Enter date for blank records], Date()))) AS TotalDays FROM Match_History; b. Query: SELECT AVG(TotalDays) AS [AverageTime] FROM CH6P56_FirstQuery; Queries related to the Pine Valley Furniture Company Note to instructor: Problems and Exercises 5-57 through 5-93 are based on the extended version of the Pine Valley Furniture Company database. (BigP V F C.m d b is the M S Access file version of this database; this is available through pearsonhighered.com/hoffer). Please note that this version of the database has a different structure than that in the textbook version of the database (e.g., the salesperson information is in the extended version but not in the textbook version). Some of the field names may also have changed due to the version of the database you are using due to the reserved words of the D BM S. When you first use the database, check the table definitions to see what the exact field names and table structures are for the D B M S that you are using.

3 - Add attribute to Product_T table ALTER TABLE Product_T ADD QtyOnHand NUMBER(5) CHECK (QtyOnHand >=0);

223

Chapter 4

3 - Enter sample data: Students should answer this exercise using a series of UPDATE commands to SET values for this new field in each existing row of the Product_T table. If using Oracle and the CHECK option, students should receive error messages if they attempt to enter negative values for QtyOnHand values.

3 - Add Order to Order_T table: Students should answer this exercise using INSERT commands to enter new rows into the Order_T and OrderLine_T tables.

3 - PVFC queries: Although the data in this table is sparsely populated and the answers to these questions can be found by simple inspection of the table values, encourage the students to write S QL to derive the results: a. 123 SELECT FROM

COUNT(*) WorkCenter_T;

SELECT FROM

WorkCenterLocation WorkCenter_T;

b. 123

3 - Employees whose name begins with “L”: Query: SELECT FROM WHERE

EmployeeID,EmployeeName Employee_T EmployeeName LIKE 'L%';

3 - Employees hired during 2005: Query: SELECT FROM WHERE

EmployeeName Employee_T EmployeeDateHired BETWEEN '01-JAN-2005' AND '31-DEC-2005';

3 - Customers who live in California or Washington, ordered by descending zip code: Query: SELECT FROM WHERE ORDER BY OR

CustomerID, CustomerName Customer_T CustomerState IN ('WA', 'CA') CustomerPostalCode DESC;

Chapter 4

224

SELECT FROM WHERE

CustomerID, CustomerName Customer_T CustomerState = 'WA' OR CustomerState = 'CA' ORDER BY CustomerPostalCode DESC; 3 - Number of customers per state included in the Customer_T table: SELECT CustomerState, COUNT(CustomerID) FROM Customer_T GROUP BY CustomerState; 3 - All raw materials made of cherry and 12 × 12 dimensions: Note: The query shown here is an M S-Access query. If using Oracle, simply replace the double quotes with single quotes.

Query: SELECT MaterialID, MaterialName FROM RawMaterial_T WHERE Material = ―Cherry‖ AND Thickness =―12‖ AND Width = ―12‖; 3-

Material I D, name, material, standard cost, and thickness for raw materials made of cherry, pine, or walnut. Order the list by material, standard cost, and thickness: Note: The query shown here is an M S-Access query. If using Oracle, simply replace the double quotes with single quotes. Also, an alternative solution is to use the OR operator rather than the I N operator, as in Problem & Exercise 5-63 above.

Query: SELECT MaterialID, MaterialName, Material, MaterialStandardPrice, Thickness FROM RawMaterial_T WHERE Material IN (―Cherry‖, ―Pine‖, ―Walnut‖) ORDER BY Material, MaterialStandardPrice, Thickness;

3 - Display the product line ID and the average standard price for all products in each product line: Query: SELECT ProductLineID, AVG(ProductStandardPrice) FROM Product_T GROUP BY ProductLineID; 3 - Modify query in P&E 5-67 by considering only those products the standard price of which is greater than $200. Include in the answer set only those product lines that have an average standard price of at least $500.

SELECT FROM WHERE GROUP BY HAVING

ProductLineID, AVG(ProductStandardPrice) Product_T ProductStandardPrice > 200 ProductLineID AVG(ProductStandardPrice)>=500;

3 - For every product that has been ordered, display the product I D and the total quantity ordered (label this

225

Chapter 4

result TotalOrdered). List the most popular product first and the least popular last: Query: SELECT FROM GROUP BY ORDER BY

ProductID, SUM(OrderedQuantity) AS TotalOrdered OrderLine_T ProductID SUM(OrderedQuantity) DESC;

3 - For each order, display the order I D, the number of separate products included in the order, and the total number of product units (for all products) ordered.

SELECT OrderID, COUNT(ProductID), SUM(OrderedQuantity) FROM OrderLine_T GROUP BY OrderID; 3 - Customer ID and total number of orders placed: Query: SELECT CustomerID, COUNT(OrderID) AS TotOrders FROM Order_T GROUP BY CustomerID; 3 - Each salesperson‟s list of customers, by ID: Query: SELECT DISTINCT SalespersonID, CustomerID FROM Order_T ORDER BY SalespersonID; 3 - Display the product I D and the number of orders placed for each product. Show the results in decreasing order, and label result column NumOrders: Query: SELECT FROM GROUP BY ORDER BY

ProductID, COUNT(ProductID) AS NumOrders OrderLine_T ProductID COUNT(ProductID) DESC;

3 - For each payment made on or after March 10, 2021, list PaymentID, OrderID, PaymentAmount, and the first 10 characters of PaymentComment.

SELECT FROM WHERE

PaymentID, OrderID, PaymentAmount, SUBSTR(PaymentComment, 1, 10) Payment_T PaymentDate >= '10-MAR-2021';

3 - Customer ID and total orders placed in 2021: In MS-Access, the query would be written as follows:

Chapter 4

226

SELECT

Order_T.CustomerID, COUNT(Order_T.OrderID) AS TotOrders FROM Order_T WHERE (((Order_T.OrderDate) Between #1/1/2021# AND #12/31/2021#)) GROUP BY Order_T.CustomerID; In Oracle, the query would be written as follows: SELECT

CustomerID, COUNT(OrderID) AS TotOrders FROM Order_T WHERE OrderDate Between '01-Jan-2021' AND '31-Dec-2021' GROUP BY CustomerID; 3 - Total number of orders for each salesperson: Query: SELECT SalespersonID,count(OrderID) AS TotalOrders FROM Order_T GROUP BY SalespersonID; 3 - Customer ID and total orders placed if more than two orders were placed: Query: SELECT FROM GROUP BY HAVING

CustomerID, COUNT(OrderID) as TotOrders Order_T CustomerID COUNT(OrderID) > 2;

3 - Assume that for those materials the I D of which starts with a numeric character, the last three letters of the I D represent a wood type. Further, assume that the numeric part of MaterialID (everything except the last three characters) is called material type. For each material type, list the number of vendors who supply it and the average price at which it is supplied.

Note that the required VendorID and SupplyUnitPrice columns are available in the Supplies_T table.

Addressing all requirements of this information request require the use of SUBSTR and LENGTH functions.

SELECT SUBSTR(MaterialID, 1, LENGTH(Materialid)-3) "Material Type", COUNT(VendorID) "Nbr of Vendors", TO_CHAR(AVG(SupplyUnitPrice),'$9,999.99') "Avg Price" FROM Supplies_T WHERE SUBSTR(MaterialID, 1, 1) IN ('1','2','3','4','5','6','7','8','9','0')

227

Chapter 4

GROUP BY SUBSTR(MaterialID, 1, LENGTH(Materialid)-3); 3 - All sales territories that have more than one salesperson: (Note: We also show the number of salespeople for each territory.)

Query: SELECT FROM GROUP BY HAVING

SalesTerritoryID, COUNT(SalespersonName) AS NumSalesPeople Salesperson_T SalesTerritoryID COUNT(SalespersonName) > 1;

3 - ProductID of most frequently ordered product: Note: Because subqueries have not been covered yet, the student should just order the query by the total orders and report on the top ProductID (or ProductIDs if more than one): Query: SELECT

ProductID, COUNT(*) AS NumOrders FROM OrderLine_T GROUP BY ProductID ORDER by COUNT(*) DESC; An alternate approach in S QL-Server or MS-Access is to use the TOP predicate: Query: SELECT TOP 1 ProductID, COUNT(*) AS NumOrders FROM OrderLine_T GROUP BY ProductID; 3 - For employees who live in T N or FL, list the age at which they were hired.

SELECT

FROM WHERE

EmployeeID, EmployeeName, ROUND((EmployeeDateHired - EmployeeBirthDate)/365,0) "Age hired" Employee_T EmployeeState IN ('FL','TN');

3 - Measured by average standard price, what is the least expensive product finish?

Query: SELECT FROM GROUP BY ORDER BY

ProductFinish, AVG(ProductStandardPrice) Product_T ProductFinish AVG(ProductStandardPrice) ASC;

Note: This response includes the average prices for all finishes.

Chapter 4

228

3 - For every territory having more than one salesman, display SalesTerritoryID and the number of salespersons in the territory: Query: SELECT FROM GROUP BY HAVING

SalesTerritoryID, COUNT(*) AS NumSalesPersons Salesperson_T SalesTerritoryID COUNT(*) > 1;

3 - Number of orders for each salesperson except salespersons 3, 5, and 9: Query: SELECT FROM WHERE GROUP BY

SalespersonID, COUNT(*) Order_T SalespersonID NOT IN (3, 5, 9) SalespersonID;

3 - Each salesperson‟s number of orders placed for each month of 2021.

The solution is shown here in both M S-Access and Oracle: MS-Access

SELECT

SalespersonID, month(OrderDate) AS Month, COUNT(OrderID) as TotalOrders FROM Order_t WHERE OrderDate BETWEEN #01/01/2021# and #12/31/2021# GROUP BY SalespersonID, month(OrderDate) ORDER BY SalespersonID, month(OrderDate); Oracle

SELECT

FROM WHERE

SalespersonID, TO_CHAR(OrderDate, 'MON') AS Month, COUNT(OrderID) AS TotalOrders Order_T OrderDate BETWEEN '01-Jan-2021' AND '31-Dec-2021'

GROUP BY SalespersonID,TO_CHAR(OrderDate, 'MON') ORDER BY SalespersonID,TO_CHAR(OrderDate, 'MON'); 3-

Material name, material, and width for raw materials that are not cherry or oak and whose width is greater than 10 inches.

Note: This query is in an Oracle format. If you want to use it with Access, please replace the single quotes with double quotes.

Query: SELECT MaterialName, Material, Width FROM RawMaterial_T

229

Chapter 4

WHERE

Material NOT IN ('Cherry', 'Oak') AND Width > 10;

Suggested Venn Diagram:

3-

ProductID, ProductDescription, ProductFinish, and ProductStandardPrice for oak products with price > 400 or cherry products with price < 300: Query: SELECT FROM WHERE

ProductID, ProductDescription, ProductFinish, ProductStandardPrice Product_T (ProductFinish = 'Oak' AND ProductStandardPrice > 400) OR (ProductFinish = 'Cherry' AND ProductStandardPrice < 300); Although not asked by the Problem and Exercise, an alternative solution might sort the output, as follows: SELECT FROM WHERE

ProductID, ProductDescription, ProductFinish, ProductStandardPrice Product_T (ProductFinish = 'Oak' AND ProductStandardPrice > 400) OR (ProductFinish = 'Cherry' AND ProductStandardPrice < 300) ORDER BY ProductFinish, ProductStandardPrice;

Chapter 4 Suggested Venn Diagram:

3 - OrderID, CustomerID, OrderDate and most recent date among orders: Query: Write the query to find the most recent date among orders: SELECT MAX(OrderDate) AS MostRecent FROM Order_T; Then, use this query as a derived table to access with the FROM clause: SELECT OrderID, CustomerID, OrderDate, (SELECT MAX(OrderDate) AS MostRecent FROM ORDER_T) AS MostRecent FROM Order_T;

230

231

Chapter 4

Suggested Venn Diagram:

3 - CustomerID, number of orders from that customer, total number of orders from all customers combined, and the ratio of that customer‟s orders to all customer orders: Query: /* first, get the total number of orders */ SELECT COUNT(OrderID) AS AllOrders FROM Order_T; /* then, get the count by individual customers */ SELECT CustomerID, COUNT(OrderID) AS CustOrders FROM Order_T GROUP BY CustomerID; /* finally, combine these two queries to get ratio displayed */ SELECT Order_T.CustomerID, COUNT(OrderID) AS OrderCount, AllOrders, COUNT(OrderID)/AllOrders AS RATIO FROM Order_T, (SELECT COUNT(OrderID) AS AllOrders FROM Order_T) GROUP BY Order_T.CustomerID, AllOrders; 3 - List total product unit sales for products 1, 2, and 7 in just one row and three columns (labeled Prod1, Prod2, Prod7): /* queries for each product */ SELECT SUM(OrderedQuantity) AS Prod1 FROM OrderLine_T WHERE ProductID = 1; SELECT SUM(OrderedQuantity) AS Prod2 FROM OrderLine_T WHERE ProductID = 2;

Chapter 4

232

SELECT SUM(OrderedQuantity) AS Prod7 FROM OrderLine_T WHERE ProductID = 7; /* query combining each derived table */ SELECT Prod1, Prod2, Prod7 FROM (SELECT SUM(OrderedQuantity) AS Prod1 FROM OrderLine_T WHERE ProductID = 1), (SELECT SUM(OrderedQuantity) AS Prod2 FROM OrderLine_T WHERE ProductID = 2), (SELECT SUM(OrderedQuantity) AS Prod7 FROM OrderLine_T WHERE ProductID = 7); 3 - List the average number of customers per state: SELECT FROM

AVG(StateCustCount) (SELECT COUNT(CustomerID) AS StateCustCount FROM CUSTOMER_T GROUP BY CustomerState);

3 - Referential integrity constraints in S QL: The Oracle script version of the Big PVFC database has all the referential integrity commands included. However, the A SC files from the MS Access database could be used to develop new tables, and this would be a good exercise for students to use to develop such skills.

3 - Tyler Richardson scenario: Based on the symptoms described in the situation, it would appear that the alarm system company‘s database maintains multiple address fields in the database that are not cross-checked with any potential customer promotions. It would appear that the mass mailing advertising list that is used to produce the mailings for potential customers (and may have been purchased from an outside-of-the-alarm-systemcompany mailing list) is not being cross-checked against a list of the company‘s current customers‘ mailing or physical addresses. Thus, existing customers who have a mailing address that is different from the physical address of the alarm system are receiving ―junk‖ mail (or spam, if delivered electronically by email).

233

Chapter 4

Suggestions for Field Exercises 3Students may need to be advised that most of the work in conducting an interview is completed before the actual meeting. Some of the tips below may help them conduct a successful interview and increase their self-confidence. a. Before the interview: 

Identify the correct person to interview. Job titles do not always denote the same set of responsibilities.

The typical database administrator is responsible for configuring and installing systems, setting up the environment for development and support, performing emergency restoration, and ensuring system security, capacity, and performance. The database administrator is a person having central control over data and programs accessing that data.



Prepare the interview questions carefully. Phrase the questions so that they are open-ended and cannot be answered by a simple ―yes‖ or ―no.‖



Set up the interview several days in advance. Arrange the exact place and time of the interview.



Present yourself professionally, both on the telephone and in person. Explain what topics will be included and specify the length of the interview.

b. During the interview: 

Begin the interview with a brief, non-business conversation to establish rapport. Objects in the person‘s office may offer clues as to the person‘s interests or background (school affiliation, particular sports interest, and so forth) and may be a good basis for opening conversation.



Try to make the interview conversational. Use the prepared questions as a guideline rather than as a script.



Taking notes to review after the interview will help you to get the maximum benefit from the interview.



Encourage the presentation of more detailed information if the person being interviewed is speaking in generalities.



Clarify any statements that you do not quite understand.



At the end of an interview, ask for a contact phone number in case you have further questions.

c. Issues relevant to this particular interview: 

Most companies will need tools to support three general categories of users:

Chapter 4

234

1. Query/Reporting (Q/R) tools support queries and reports against operational data and data warehouses. They are often used by knowledge workers.

2. Online Analytical Processing (O LAP) tools provide the summarized information for middle management and business analysts.

3. Executive Information System (EIS) tools, often implemented by adding a front end to O LA P tools, provide high-level reporting and monitoring capabilities for senior management. 

Applications that use embedded SQL statements to access and manipulate data are developed using different host languages (Ada, COBOL, C, etc.). There are different means for S QL integration into a language, direct embedded support like PowerBuilder, and indirect embedded support through a preprocessor like zTools (an automatic code generation precompiler for SYBASE that automatically creates source code to link the application program to stored procedures on the SYBASE server using DB-Library calls), or database API support. The downside to Application Programming Interface (A PI) support is that it takes many lines of tedious C code to equal each line of embedded S QL. To further complicate the issue, many companies are building intranets—private networks on the World Wide Web—to provide their employees, customers, and partners access to information in corporate data warehouses. Decision support tools need to accommodate these users, too.

3Use the strategies proposed in Exercise 5-94.

Note: With P L/S Q L, you can use S QL statements to manipulate Oracle data and flow-of-control statements to process the data. Moreover, you can declare constants and variables, define subprograms (procedures and functions), and trap runtime errors. Thus, P L/S Q L combines the data manipulating power of S Q L with the data processing power of procedural languages.

3Use the strategies proposed in Exercise 5-94. Student answers will vary based on the company chosen, the background and experience of the interviewee, and the kinds of DBMS that the interviewee has used.

Project Questions 3 - Write SQL statements for creating FAME tables The script for Oracle is available on the book‘s Web site. Other D BMS require minor adjustments.

3 - Identify reports and displays This collection of reports and displays is an integration of similar material from Chapters 2 and 3:

235

Chapter 4

o A tentative contract for a specific prospective artist o A final contract for a specific prospective artist o Artist schedule for a specific timeframe o List of revenues by manager within a timeframe o List of FAME fees by manager within a timeframe o List of revenues by artist within a timeframe o List of revenues minus FAME fee by artist within a timeframe o List of artist expenses by artist within a timeframe o An account statement per artist (including previous balance, expenses since previous statement close, revenues (minus FAME fee) since previous statement close, payments to/from an artist, new balance) o List of future performances (including anticipated revenue and FAME fee) within a specific timeframe 

For all artists



For a specific artist



For a specific manager

o Invoices to customers for a specific time period o Accounts receivable reports (list of unpaid invoices categorized by due date) o List of manager expenses by manager within a timeframe o An account statement per manager (including previous balance, expenses since previous statement close, manager‘s share of FAME fees since previous statement close, payments to/from a manager, new balance) o Data regarding event cancellations o Artist contact information o List of relevant news items per artist

Chapter 4

236

o Availability of a specific artist within a time frame o List of all available artists for a specific time frame filtered by specific criteria (instrument, experience level, fee level, etc.) o Artist contracts to be renewed within a specific future timeframe o Expired artist contracts o List of recommendations categorized and filtered in a number of ways to support review of prospective artists o List of prospective artists filtered appropriately together with all artist recommendations from a specific time period o Travel expense report for artist managers (a subset of a report from Chapter 3) o A more detailed availability report than specified in Chapter 2 o Inclusion of the At Source Tax in the revenue reports 3 - Populate the database with test data A sample script for populating the database is available on the book‘s Web site in the Oracle format.

3 - Write test queries A collection of sample test queries is available on the book‘s Web site.

Chapter 6 Advanced SQL Chapter Overview Chapter 6 is based on the foundation formed in Chapter 5, moving from single-table queries to multitable joins, subqueries (both non-correlated and correlated), establishing referential integrity, and derived tables. Views, triggers, stored procedures, functions, embedded S QL, dynamic S QL, and Persistent Stored Modules are also covered. This chapter also contains a detailed discussion of transaction integrity as well as the S QL:2011 enhancements and extensions to S QL and an overview of data dictionaries. Chapter 5 is a prerequisite for this chapter.

237

Chapter 4

Chapter Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Build the student‘s S QL skills and an appreciation of S QL through many examples of relational queries from S QL; demonstrate capabilities such as multiple-table data retrieval (join and other operators such as difference, union, and intersection), explicit and implicit joining, and built-in functions.

2. Illustrate the differences between the joining and subquery approaches to manipulating multiple tables in SQL. 3. Help the students understand the possibilities views (both dynamic and materialized) offer in database management.

4. Discuss the SQL:2008, SQL:2011, and S QL:2016 enhancements to S QL. 5. Briefly discuss the data dictionary facilities available in Oracle 12c.

6. Discuss triggers and stored procedures and provide examples of how these might be used.

7. Understand the use of user-defined data types in large database installations.

Key Terms Base table Correlated subquery

Join Materialized view

Procedure Trigger

Dynamic view

Natural join

User-defined data type (UDT)

Equi-join

Outer join

Virtual table

Function

Persistent Stored Modules (SQL/PSM)

Chapter 4

238

Classroom Ideas 1. Have students program in a system that supports S QL along with this chapter. The nuances of joining multiple tables, nesting subqueries, properly qualifying built-in functions, and so forth are really only learned by writing a wide variety of non-trivial queries. There are exercises at the end of the chapter that will provide such practice for students.

2. If students have access to Oracle, have them take a look at the various data dictionary views available to them as a user. You may also want to discuss the various D BA views available and show these to the students during your lecture. Remember that Teradata University for Academics, in collaboration with University of Arkansas Walton College Enterprise Systems, provides access to Teradata S QL for classroom use, and that you may set up access for yourself and your students.

The databases from the text are available, as are much larger data sets that you may want to use.

Teradata University‘s home page is https://www.teradata.com/University/Academics.

3. When discussing multiple table queries, always emphasize that there is more than one way to write a query. For example, show the students a query using a join and then the same query using subqueries.

4. Emphasize the cases when a subquery is needed and cannot be substituted with a join. A good example of this would be the case where one needs to find all customers who have never purchased a product (using a subquery with the NOT IN qualifier).

5. The capabilities and benefits of views are not as obvious to students as you might expect. First, many relational systems place limitations on operations that may be performed on views (for example, no or restricted modification). Second, views are not just the relational term for temporary table or for subschemas (from the network model); rather, views provide a capability for simpler query writing for casual users. Finally, views may have negative performance implications compared to temporary, intermediate tables explicitly created by a prewritten procedure. These points should be emphasized in lectures or assignments. Consider having students create both a view and a temporary table (or materialized view) in S QL. In most S QL systems, a temporary table can be created by the use of a SAVE or KEEP clause at the end of a query, or one can use a CREATE TABLE command that has a query (rather than column definitions) as its object. Then, the same query can be run and timed against both the view and temporary tables. As another alternative, have

239

Chapter 4

students derive the view table as part of the FROM clause of a query. One way to estimate the timing of each approach, given small data sets, is to use the EXPLAIN command (or similar command with your RDB MS) on each version of the query to show students how the query would be processed using each approach.

6. Develop an exercise for the students to explore the effects of a trigger. Have them create and populate some tables, then write an insert trigger for one of the tables that might impact other tables.

You could then have the students insert some records and see the results. It is important to show the effects of triggers through examples that the students can try out, followed by problems that they would have to solve by writing triggers. The same can be said for stored procedures.

7. The discussion on S QL/PSM might be a good place to introduce P L/SQL before introducing triggers and stored procedures.

Answers to Review Questions 3-

Define each of the following key terms: a. Dynamic view. A dynamic view is a table-like structure that is not stored physically on a storage medium but is recreated based on existing base tables and a stored specification at the time of use. b. Correlated subquery. This type of subquery is processed outside in, rather than inside out. That is, the inner query is executed for each row in the outer query, and the inner query depends in some way on values from the current row in the outer query. The results of the inner query will, in turn, affect the final results of the outer query. c. Materialized view. Materialized view is, in essence, a copy of data in base tables physically stored based on a view definition. d. Base table. A physically stored table that includes raw data. e. Join. The most frequently used relational operation, which brings together data from two or more related tables into one result table

Chapter 4

240

f. Equi-join. A join in which the joining condition is based on equality between values in the common columns. It produces a table of rows composed of columns from two other tables, where common columns appear (redundantly) in the result table. g. Self join. A join that requires matching rows in a table with other rows in the same table. This is a join that joins a table with itself and often occurs with the presence of a unary relationship in the database, such as a Supervisor or Manager of Employees within an Employee table. h. Outer join. A join in which rows that do not have matching values in common columns are nevertheless included in the result table. Outer joins return all the values in one of the tables included in the join, regardless of whether a match exists in the other table(s) or not. i. Virtualized table (or virtual table). A table that does not exist as a permanent structure on a storage medium but that the DBMS creates as needed.

3-

3-

Match the following terms to the appropriate definitions: b

equi-join

d

derived table

f

natural join

c

correlated subquery

a

outer join

e

trigger

Using an outer join instead of a natural join with examples: Outer joins are often used in database maintenance to find rows that do not have matching values in common columns. Null values appear in columns where there is no match between tables. Another example would be a query that returns all customers—whether they have placed orders in the last four months or not—along with the date of the most recent order placed within the last four months. Customers who have not placed an order would be returned with a null value under most recent order.

For detailed query examples, see, for example, p. 256.

3-

Explain the processing order of a correlated subquery: Correlated subqueries use the result of the outer query to determine the processing of the inner query. Thus, the inner query varies for each row referenced in the outer query.

241

3-

Chapter 4

Purposes for correlated subqueries A typical use of a correlated subquery is related to comparing an attribute value an instance has (such as, for example, Age) to a benchmark value that is specific to a group to which the instance belongs (such as the Average Age within a team).

3-

Relationship between EXISTS and correlated subqueries Subqueries written using the EXISTS keyword are, in practice, correlated subqueries: they also include a reference to the outer query in the inner query and the value the inner query produces depends on the specific row of the outer query being processed.

3-

Explain that any query that can be written using the subquery approach can also be written using the joining approach, but not vice versa: While Oracle allows a subquery to return more than one column, most systems allow pairwise joining of one and only one column in an inner query with one column in an outer query. (An exception to this is when a subquery is used with the EXISTS keyword.) You can display data only from the table(s) referenced in the outer query. If you want to include data from the subquery in the result, then you would have to use the join technique because data from the subquery cannot be included in the results. The joining technique is useful when data from several relations are to be retrieved and displayed, and the relationships are not necessarily nested.

3-

Conditions for using UNION: Use UNION when you want to combine the output from multiple queries together. However, each query involved must output the same number of columns, and the columns must have the same data types.

Chapter 4

3-

242

Purposes for creating views: Views are used to create an additional layer of separation between data stored on a physical storage medium and the structural mechanism that provides access to the data. Views allow DBAs to give users and developers a perspective to the data that fits their specific needs and does not allow them to see data elements beyond those that they need for their specific task. Providing access to the database through views tailored to the needs of a specific user group reduces the risk of errors, security breaches, and violations of privacy. The additional virtual layer also reduces the impact of possible changes to the base tables—in such situations, it might be possible to avoid any externally visible changes by simply changing the way a view is specified in relation to the base tables.

3-

Limiting updates when using a view: When a view is used to update data in the base tables, it is essential to make sure that the view does not create ambiguity in terms of the elements that the update addresses. In practice, only views created with straightforward single table, non-aggregate queries can be used for updates.

3-

Using a view to save reprogramming effort: As discussed above in the context of Review Question 6-9, in the context of a change to the base table(s), a view can still be maintained intact by changing the specification of the view to be aligned with the new base table structure. In essence, the view would serve in these cases as a conversion mechanism between the user‘s perspective of the database (which will be kept intact) and the modified base table structure.

3-

Purpose of the WITH CHECK OPTION in CREATE VIEW: The WITH CHECK OPTION will create a condition the violations of which will prevent a view from being updated.

For example, the following specification of ExpensiveStuff_V would prevent any updates to ExpensiveStuff_V that would change the ProductStandardPrice so that the specific row would not anymore be part of the view (i.e., have price higher than $300).

CREATE VIEW ExpensiveStuff_V AS SELECT ProductID, ProductDescription, ProductStandardPrice FROM Product_T WHERE ProductStandardPrice > 300

243

Chapter 4

WITH CHECK OPTION; 3-

Using derived tables: Derived tables are used to create a temporary table that is treated as if it were an actual table. This table is not persistent in that it goes away after the query in which it was created is run.

3-

Example of derived table usage:

3-

One example of the use of a derived table would be to find all ships that were loaded beyond capacity. In this example, a shipment‘s weight is calculated by computing the sum of the quantity order times the weight. The query follows: SELECT Ship.ShipNo FROM Ship, Shipment, (SELECT ShipmentLine.ShipmentID, SUM(Item.Weight*ShipmentLine.Quantity) AS Tweight FROM ShipmentLine,Item WHERE ShipmentLine.ItemNo = Item.ItemNo GROUP BY ShipmentID) AS ShipWt WHERE Ship.ShipNo = Shipment.ShipNo AND Shipment.ShipmentID = ShipWt.ShipmentID AND Ship.Capacity < ShipWt.Tweight; Data type incompatibility and UNION operation: The simplest way to address this problem is to convert one of the data types. For example, if one data type is a character and the other numeric, you could use a function such as Oracle‘s TO_CHAR to convert the numeric to a character.

3-

Using outer join with more than two tables: The outer join is not easily implemented for more than two tables. The results vary by R D B M S vendor and should be thoroughly tested before implementing.

3-

Hidden triggers: They are hard to see coming until they fail to fire. They may fire without notification. Cascading triggers and endless loop triggers are also possible.

3-

Triggers v s stored procedures: ersu

Both triggers and stored procedures consist of blocks of procedural code. Stored procedures are stored blocks of code that must be directly called upon to operate against the data in the database. Triggers, in contrast, are stored in the database and run automatically whenever a specified database event occurs (e.g., INSERT, UPDATE, DELETE or ALTER TABLE commands).

3-

SQL/PSM (Persistent Stored Modules): The purpose of Persistent Stored Modules (S Q L/P S M) is to make S Q L computationally complete with structures such as IF-THEN, FOR, and WHILE, essentially making available sequence, conditional structures, and iteration (loops).

Chapter 4

3-

244

Advantages of SQL-invoked routines Flexibility: Routines can be used for more purposes than constraints or triggers Efficiency: Routines can be optimized to run more efficiently than generic SQL statements Shareability: Routines can be cached and shared between users.

Applicability: Routines may apply to the entire database and not just one application.

3-

Purpose of temporal extensions in S QL:2011: The primary purpose of the temporal extensions is to allow the creation of relational tables with period definitions, which, in turn, allow a row to specify the time period during which the rest of the attributes are valid. Once this is done, time-related predicates can be used in query operations to allow for sophisticate queries that can take time into account much better than without the temporal extensions.

3-

Key new features of SQL introduced in SQL:2016: The key new features of SQ L:2016 are as follows: 1) more effective processing of time-series data with Row Pattern Recognition; 2) trigonometric and logarithm functions; 3) Java Script Object Notation support; and 4) Polymorphic Table Functions for creating sophisticated custom functions.

3-

Mechanisms for dealing with temporal issues before the extensions were introduced: Even before the temporal extensions, it was not atypical to see specifications of valid time frames included in table structures. For example, there might have been a separate PRODUCTPRICE table that included the following attributes: PRODUCTPRICE(ProductID, PriceValidStartDate, PriceValidEndDate, ProductPrice) With this type of table structure, it was possible to emulate a mechanism for dealing with time-dependent values, but it was much more difficult to use this structure without the language components specifically designed for time.

3-

Data dictionary views for non-Oracle RDBMS: This is left as an exercise for students. The textbook shows examples of different system table names between Oracle and Microsoft S Q L Server, which would be one difference in the data dictionary facilities between vendors. Other differences that might be apparent if students have hands-on access to both vendor D B M S could be what system tables the students/users have access to based on the database authorization and security setup.

Answers to Problems and Exercises Note to Instructor: The solutions, which include S QL statements, are not intended as the definitive answer to the questions; instead, each one of them is an example of one possible correct solution. Instructors and students will approach the problems using different S QL capabilities, achieving results that are also correct.

We illustrate the S Q L statements with capitalized S Q L Reserve Words, and upper/lower case usage for

245

Chapter 4

data names, to be consistent with the textbook treatment of naming conventions. Oracle results, when shown, will display table and column names with all Upper Case letters.

Problems 6-25—6-30 are based on class scheduling relations in Figure 6-15.

3 - Instructors qualified to teach ISM 3113: SELECT FROM WHERE

FacultyID, FacultyName Faculty Faculty.FacultyID = Qualified.FacultyID AND Qualified.CourseID = 'ISM 3113';

3f. Display the course ID and course name for all courses with an ISM prefix: Query: SELECT FROM WHERE

CourseID, CourseName Course CourseID LIKE 'ISM%';

g. Display the numbers and names of all courses for which Professor Berndt has been qualified: Query: SELECT FROM

WHERE

Course.CourseID, Course.CourseName Faculty, Course, Qualified Faculty.FacultyName = 'Berndt' AND Faculty.FacultyID= Qualified.FacultyID AND Course.CourseID=Qualified.CourseID;

Chapter 4

246

h. Display the class roster, including student name, for all students enrolled in section 2714 of I SM 4212: Query: SELECT

Student.StudentID, Student.StudentName, Section.CourseID, Registration.SectionNo FROM Student, Registration, Section WHERE Section.SectionNo= Registration.SectionNo AND Registration.StudentID AND Registration.SectionNo=2714 ORDER BY StudentName;

Student.StudentID=

247

3-

Chapter 4

Is any instructor qualified to teach ISM 3113 and not qualified to teach ISM 4930?

Query: SELECT FROM WHERE MINUS SELECT FROM WHERE AND

Faculty.FacultyID, Faculty.FacultyName Faculty, Qualified Qualified.FacultyID=Faculty.FacultyID AND Qualified.CourseID='ISM 3113' Faculty.FacultyID, Faculty.FacultyName Faculty, Qualified Qualified.FacultyID=Faculty.FacultyID Qualified.CourseID='ISM 4930'

Chapter 4

3-

SQL queries: a. How many students were enrolled in section 2714 during semester I-2021?

SELECT COUNT(StudentID) FROM Section WHERE SectionNo = 2714; b. How many students were enrolled in I SM 3113 during semester I-2021?

SELECT COUNT(StudentID) FROM Section WHERE CourseID = 'ISM 3113';

3-

SQL queries: a. What are the names of the course(s) that student Altvater took during the semester I-2021?

SELECT Course.CourseName FROM Course, Section,Registration, Student

248

249

Chapter 4

WHERE Course.CourseID = Section.CourseID AND Section.SectionNo = Registration.SectionNo AND Registration.StudentID = Student.StudentID AND StudentName = 'Altvater' AND Section.Semester = 'I-2021'; There are no courses that satisfy this condition. Using section 'II-2021' will produce results. b. List names of the students who have taken at least one course that Professor Collins is qualified to teach.

SELECT Student.StudentID, Student.StudentName FROM Registration, Section, Qualified, Faculty, Student WHERE Student.StudentID = Registration.StudentID AND Registration.SectionNo = Section.SectionNo AND Section.CourseID = Qualified.CourseID AND Qualified.FacultyID = Faculty.FacultyID AND Faculty.FacultyName = 'Collins'; c. List the names of the students who took at least one course with ―Syst‖ in its name during the semester I-2021.

SELECT DISTINCT StudentName FROM Student, Registration, Section, Course WHERE Student.StudentID = Registration.StudentID AND Registration.SectionNo = Section.SectionNo AND Section.CourseID = Course.CourseID AND CourseName LIKE '%Syst%'; d. How many students did Professor Collins teach during the semester I-2021?

This query requires the use of the ASSIGNMENT relation mentioned in the introduction to the section.

Let‘s assume ASSIGNMENT has two columns: FacultyID and SectionNo, signifying that a specific faculty member has been assigned to teach a specific section.

SELECT COUNT(StudentID) FROM Student, Registration, Section, Assignment, Faculty WHERE Student.StudentID = Registration.StudentID AND Registration.SectionNo = Section.SectionNo AND Section.SectionNo = Assignment.SectionNo AND Assignment.FacultyID = Faculty.FacultyID AND Faculty.FacultyName = 'Collins' AND Section.Semester = 'I-2021'; e. List the names of the courses that at least two faculty members are qualified to teach.

SELECT CourseName

Chapter 4

250

FROM Course WHERE CourseID IN ( SELECT CourseID FROM Qualified GROUP BY CourseID HAVING Count(FacultyID)>=2); 3a. Which students were not enrolled in any courses during semester I-2021?

Query: SELECT FROM WHERE (

DISTINCT StudentID, StudentNAME Student NOT EXISTS SELECT * FROM Registration, Section WHERE Student.StudentID = Registration.StudentID AND Registration.SectionNo = Section.SectionNo AND Semester= 'I-2021'); b. Which faculty members are not qualified to teach any courses?

SELECT FacultyName FROM Faculty WHERE FacultyID NOT IN (SELECT FacultyID FROM Qualified); With the book data set, the query does not produce any results. You can test this very easily by adding another instructor into the data set.

Problems and Exercises 6-31 – 6-41 Note to Instructor: Problems and Exercises 6-31–6-44 are based on Figure 6-16 and continue a problem set from Chapter 5 (problems 5-46 to 5-56, based on Figure 5-12). Please note that the Chapter 6 problem set alters the design of the database from the earlier design shown in Chapter 5. It may be useful for students to build this small database in a particular D BMS environment and populate the tables with sample data as they work on the requested queries. The S Q L illustrated in this sample solution is based on M S Access SQL. 3-

List primary and foreign keys for all entities in Figure 6-16: Tutor Primary key: TutorID Foreign key: none

251

Chapter 4

Student Primary key: StudentID Foreign key: none MatchHistory Primary key: MatchID Foreign keys: TutorID references Tutor(TutorID) StudentID references Student(StudentID) TutorReport Primary key: MatchID + Month (composite PK) Foreign key: MatchID references MatchHistory(MatchID) 3-

Write SQL to add MathScore to Student table: Query: ALTER TABLE Student ADD COLUMN MathScore NUMBER(2,1);

3-

Write SQL to add Subject to Tutor table: Query: ALTER TABLE Tutor ADD COLUMN Subject VARCHAR(7) CHECK (Subject IN ('Reading', 'Math', 'ESL'));

3-

Suggested solution for tutors who tutor in more than one subject area: One approach is to adjust the database design to allow tutors the ability to declare more than one subject preference for tutoring. Based on the prior specifications (including Problem and Exercise 6-33), the business rule appeared to be that tutors only tutored in one subject, thus the subject could be stored with tutor information. Under this new requirement, the database needs the ability to track more than one subject per tutor. This can be accomplished by adding two tables to the current design (TutorSubject, Subject) and by altering the structure of the MatchHistory table to track the Subject involved in each match of Tutor and Student, as noted in the revised ERD. It is also possible to assume that (1) each tutor is certified only once or (2) that a tutor must be certified in each of the subjects. A second assumption would require that CertDate be moved to the TutorSubject relation. This is a good opportunity to show how making an assumption without interviewing the database user may result in an incorrect data model because the correct business rule has not been uncovered.

After completing Exercise 6-33 (where subject values of ―Reading, Math, and E S L‖ were added to teachers‘ certifications), some students may ask if it is important for the database to track what Subject each Student is studying. This inquiry can be used in class as an example of how an analyst can uncover

Chapter 4

252

additional business rules that have not been initially elicited from the client in interviews. You may expand this question to track student assessment scores for math and E S L in addition to the existing READ score.

This should lead to consideration that, just as tutors may only be certified in one area, students may elect to study in one to three areas, depending on their needs. The data model would need to be expanded further to handle this.

3-

Students matched with a tutor with “Temp Stop” status in 2021: SELECT FROM WHERE

3-

MatchHistory.StudentID MatchHistory, Tutor MatchHistory.TutorID = Tutor.TutorID AND Tutor.Status = ‗Temp Stop‘ AND MatchHistory.StartDate >= #1/1/2021#)

Tutors who have not submitted a report in July: (Answer provided in M S ACCESS S Q L). Students who build a practice database to answer this problem should use a DATE format and may need to add a day-of-month value to the data provided. Note that a left outer join is necessary to pick up tutors who have never submitted a report.

First, a query named CH7P35 returns a list of all reports ever submitted for each currently active student.

The query is sorted by tutor and report dates for that tutor.

SELECT MatchHistory.MatchID, MatchHistory.EndDate, MatchHistory.TutorID, TutorReport.Month FROM MatchHistory LEFT JOIN TutorReport ON MatchHistory.MatchID = TutorReport.MatchID WHERE (((MatchHistory.EndDate) IS NULL)) OR (((MatchHistory.EndDate)>#6/30/2021#) AND ((TutorReport.Month) Is Null))

253

Chapter 4

ORDER BY MatchHistory.MatchID, TutorReport.Month; Next, a query is built to retrieve data from query Ch7P35. This second query returns just those tutors with active students who have not turned in a July report.

Students should be encouraged to modify or add records to the example in the book in order to test their query thoroughly. As given, only Tutor 104 with a new student who started in June has not submitted a report for July. In order to test their query more completely, data should be created for tutors who have active students and who have previously submitted monthly reports but have not submitted one in June.

SELECT CH7P35.TutorID, CH7P35.Month FROM CH7P35 WHERE (((CH7P35.Month) IS NULL)) OR (((CH7P35.Month)>=#6/30/2021# And (CH7P35.Month) NOT BETWEEN #7/1/2021# And #7/31/2021#)); Motivated students may add parameters to this query so it will work for any month.

3-

Table structure for Student and Tutor data: Note: This solution assumes the creation of a PERSON table to store the common contact data for STUDENTs and TUTORs, and the linking of the STUDENT and TUTOR table to the PERSON table.

Individual student answers may vary from this proposed solution due to this assumption.

CREATE TABLE PERSON ( PersonID VARCHAR(5) CONSTRAINT PERPERSID_PK PRIMARY KEY, LastName VARCHAR(15), FirstName VARCHAR(15), MiddleInit VARCHAR(1), PersonStrAddress VARCHAR(20), PersonCity VARCHAR(20), PersonState CHAR(2), PersonZip VARCHAR(10), PersonPhone VARCHAR(14), PersonEMail VARCHAR(25), PersonType CHAR(1)); ALTER TABLE Student ( ADD COLUMN PersonID VARCHAR(5)); ALTER TABLE Student ( ADD CONSTRAINT STPERSONID_FK PersonID REFERENCES Person(PersonID)); ALTER TABLE Tutor ( ADD COLUMN PersonID VARCHAR(5)); ALTER TABLE Tutor ( ADD CONSTRAINT TTUTORID_FK REFERENCES Person(PersonID));

3-

Determine the total number of hours and the total number of lessons Tutor 106 taught in June and July 2021: SELECT FROM

SUM(Hours), SUM(Lessons) MatchHistory, TutorReport

Chapter 4

WHERE

3-

TutorReport.MatchID = MatchHistory.MatchID AND TutorID = 106 AND Month IN ('6/21', '7/21');

List the Read scores of students who were ever taught by tutors whose status is Dropped SELECT FROM WHERE

3-

254

StudentID, Read STUDENT StudentID IN (SELECT StudentID FROM MatchHistory, Tutor WHERE Tutor.TutorID = MatchHistory.TutorID AND Status = 'Dropped‘);

List all active students in June by name, including number of hours tutored and number of lessons completed: Query: SELECT

Student.StudentID, MatchHistory.EndDate, Person.LastName, SUM(TutorReport.Hours) AS TotalHours, SUM(TutorReport.Lessons) AS TotalLessons FROM (Person INNER JOIN Student ON Person.PersonID = Student.StudentID) INNER JOIN (MatchHistory LEFT JOIN TutorReport ON MatchHistory.MatchID = TutorReport.MatchID) ON Student.StudentID = MatchHistory.StudentID GROUP BY Student.StudentID, MatchHistory.EndDate, Person.LastName HAVING (((MatchHistory.EndDate) Is Null)); 3-

Tutors matched with a student group: SELECT FROM WHERE GROUP BY

3-

Student.Group, COUNT(TutorID) Student, MatchHistory Student.StudentID = MatchHistory.StudentID Student.Group;

Total number of lessons taught in 2021 by tutors in each of the three Status categories: Microsoft Access Query: SELECT Tutor.Status, SUM(Lessons) FROM Tutor, MatchHistory, TutorReport WHERE Tutor.TutorID = MatchHistory.TutorID AND MatchHistory.MatchID = TutorReport.MatchID AND DatePart(―yyyy‖,MatchHistory.StartDate) = 2021 GROUP BY Tutor.Status;

3-

Which tutors, by name, are available to tutor?

This answer assumes any active tutor may be available to accept a new student:

255

Chapter 4

Query: SELECT

Person.LastName, Person.FirstName, Tutor.Status FROM Person INNER JOIN Tutor ON Person.PersonID = Tutor.PersonID WHERE (((Tutor.Status)= 'Active')); This answer assumes a tutor is available only if currently unassigned a student: SELECT T.TutorID, Person.LastName, Person.FirstName FROM Person INNER JOIN Tutor AS T ON Person.PersonID = T.PersonID WHERE (((T.TutorID) IN (SELECT MH.TutorID FROM MatchHistory MH WHERE EndDate IS NOT NULL) AND (T.TutorID) NOT IN (SELECT MH.TutorID FROM MatchHistory MH WHERE EndDate IS NULL)) AND ((T.STATUS)= 'Active')); 3-

Which tutor needs to be reminded to turn in reports?

Query: SELECT FROM WHERE

MatchHistory.TutorID MatchHistory MatchHistory.MatchID NOT IN (SELECT DISTINCT TutorReport.MatchID FROM TutorReport);

Chapter 4

256

Queries Based on the P VFC Database Note to Instructor: Problems and Exercises 6-45—6-85 are based on the extended version of the Pine Valley Furniture Company database (BigP V F C.m d b is the M S Access file version of this database; this extended database version is available on pearsonhighered.com/hoffer). Please note that this version of the database has a different structure than that in the textbook version of the database (e.g., the salesperson information is in the extended version but not in the textbook version). Some of the field names may also have changed due to the version of the database you are using due to the reserved words of the D B M S. When you first use the database, check the table definitions to see what the exact field names and table structures are for the D B M S that you are using. Also note that, where possible, solutions are presented in both MS Access and Oracle SQL syntax.

3-

Find customers who have not placed any orders: Microsoft Access Query: SELECT Customer_T.CustomerID FROM Customer_T WHERE Customer_T.CustomerID NOT IN (SELECT CustomerID from Order_T); Oracle Query: SELECT Customer_T.CustomerID

257

Chapter 4

FROM WHERE 3-

Customer_T Customer_T.CustomerID NOT IN (SELECT CustomerID from Order_T);

List product line names and for each product line number of products and average product price.

Microsoft Access Query: SELECT ProductLineName, COUNT(ProductID) AS [NbrOfProducts], AVG(ProductStandardPrice) AS [Avg Price] FROM Productline_T, Product_T WHERE Product_T.ProductLineID = Productline_T.ProductLineID GROUP BY Productline_T.ProductLineID, ProductLineName; Oracle Query: SELECT ProductLineName, COUNT(ProductID), AVG(ProductStandardPrice) FROM Productline_T, Product_T WHERE Product_T.ProductLineID = Productline_T.ProductLineID GROUP BY Productline_T.ProductLineID, ProductLineName;

3-

Modify previous query to include only those product lines the average price of which is higher than $200.

Microsoft Access Query: SELECT ProductLineName, COUNT(ProductID) AS [NbrOfProducts], AVG(ProductStandardPrice) AS [Avg Price] FROM Productline_T, Product_T WHERE Product_T.ProductLineID = Productline_T.ProductLineID GROUP BY Productline_T.ProductLineID, ProductLineName HAVING AVG(ProductStandardPrice)>200; Oracle Query: SELECT ProductLineName, COUNT(ProductID), AVG(ProductStandardPrice) FROM Productline_T, Product_T WHERE Product_T.ProductLineID = Productline_T.ProductLineID GROUP BY Productline_T.ProductLineID, ProductLineName HAVING AVG(ProductStandardPrice)>200;

3-

List the names and number of employees supervised (label this value HeadCount) for all the supervisors who supervise more than two employees: Microsoft Access Query: SELECT S.EmployeeName, COUNT(E.EmployeeID) AS [HeadCount] FROM Employee_T S, Employee_T E

Chapter 4

258

WHERE S.EmployeeID = E.EmployeeSupervisor GROUP BY S.EmployeeName HAVING COUNT(E.EmployeeID) > 2; Oracle Query: SELECT S.EmployeeName, COUNT(E.EmployeeID) AS HeadCount FROM Employee_T S, Employee_T E WHERE S.EmployeeID = E.EmployeeSupervisor GROUP BY S.EmployeeName HAVING COUNT(E.EmployeeID) > 2; Result: EmployeeName

HeadCount

Robert Lewis

3

You can verify this by running a simpler query that computes the number of employees each employee supervises. From this query you would see that there are three supervisors (those who supervise anyone), and the other two supervisors supervise only one employee each.

3-

Names of employees, employee birthdate, manager name, manager‟s birthdate for those employees born before their manager was born; label columns per problem instructions: Microsoft Access and Oracle Query: SELECT E1.EmployeeName, E1.EmployeeBirthdate, E2.EmployeeName AS Manager, E2.EmployeeBirthdate AS ManagerBirth FROM Employee_T E1, Employee_T E2 WHERE E1.EmployeeSupervisor = E2.EmployeeID AND E1.EmployeeBirthdate < E2.EmployeeBirthdate; P&E 6-49 Instance Diagram (with sample data for illustration purposes only; not showing values from PVFC database)

259

3-

Chapter 4

Display order number, customer number, order date and items ordered for some customer (example shows CustomerID=4, students may have chosen another valid customer ID number in their solutions): Microsoft Access Query: SELECT Order_T.OrderID, Order_T.CustomerID, Order_T.OrderDate, OrderLine_T.ProductID, Product_T.ProductDescription, OrderLine_T.OrderedQuantity FROM Product_T INNER JOIN (Order_T INNER JOIN Orderline_T ON Order_T.OrderID = OrderLine_T.OrderID) ON Product_T.ProductID = OrderLine_T.ProductID WHERE Order_T.CustomerID= 4; Oracle Query: SELECT Order_T.OrderID, Order_T.CustomerID, Order_T.OrderDate, OrderLine_T.ProductID, Product_T.ProductDescription, OrderLine_T.OrderedQuantity FROM OrderLine_T, Order_T,

Chapter 4

WHERE

3-

260

Product_T Order_T.OrderID=OrderLine_T.OrderID AND OrderLine_T.ProductID=Product_T.ProductID AND Order_T.CustomerID = 4;

Display each item ordered for order #1, its standard price, and total price for each item ordered: Microsoft Access and Oracle Query: SELECT OrderLine_T.ProductID, Product_T.ProductStandardPrice, OrderLine_T.OrderedQuantity* Product_T.ProductStandardPrice AS LineTotal FROM Product_T,OrderLine_T WHERE Product_T.ProductID = OrderLine_T.ProductID AND OrderLine_T.OrderID = 1;

3-

Total number of employees working at each work center:

3-

Microsoft Access Query: SELECT WorkCenter_T.WorkcenterID, COUNT(Employee_T.EmployeeID) AS [Nbr of Employees] FROM WorkCenter_T, Worksin_T, Employee_T WHERE WorkCenter_T.WorkcenterID = Worksin_T.WorkcenterID AND Worksin_T.EmployeeID = Employee_T.EmployeeID GROUP BY WorkCenter_T.WorkcenterID; Oracle Query: SELECT WorkCenter_T.WorkcenterID, COUNT(Employee_T.EmployeeID) AS "Nbr of Employees" FROM WorkCenter_T, Worksin_T, Employee_T WHERE WorkCenter_T.WorkcenterID = Worksin_T.WorkcenterID AND Worksin_T.EmployeeID = Employee_T.EmployeeID GROUP BY WorkCenter_T.WorkcenterID; List of work centers that employ at least one person who has the skill „QC1‟: Microsoft Access and Oracle Query: SELECT WorkCenter_T.WorkcenterID FROM WorkCenter_T WHERE WorkcenterID IN ( SELECT WorkcenterID FROM Worksin_T, Employee_T, EmployeeSkills_T WHERE WorksIn_T.EmployeeID = Employee_T.EmployeeID AND Employee_T.EmployeeID = EmployeeSkills_T.EmployeeID and EmployeeSkills_T.SkillID = 'QC1');

3-

Total the cost of the order for order #1: Microsoft Access and Oracle Query: SELECT SUM(OrderLine_T.OrderedQuantity* Product_T.ProductStandardPrice) FROM Product_T,OrderLine_T

261

3-

3-

Chapter 4

WHERE Product_T.ProductID = OrderLine_T.ProductID AND OrderLine_T.OrderID = 1; List for each vendor those materials that the vendor supplies the supply unit price of which is at least four times the material standard price: Microsoft Access and Oracle Query: SELECT Vendor_T.VendorID, MaterialName FROM Vendor_T, Supplies_T, Rawmaterial_T WHERE Vendor_T.VendorID = Supplies_T.VendorID AND Supplies_T.MaterialID = Rawmaterial_T.MaterialID AND Supplies_T.Supplyunitprice >= 4*Rawmaterial_T.Materialstandardprice; Calculate the total raw material cost (label TotCost) for each product compared to its standard product price and display product ID, product description, standard price, and the total cost in the result: Microsoft Access and Oracle Query: SELECT P.ProductID, ProductDescription, P.ProductStandardPrice, SUM(U.QuantityRequired*R.ProductStandardPrice) AS FROM Product_T P, Uses_T U, RawMaterial_T P WHERE P.ProductID = U.ProductID AND U.MaterialID = R.MaterialID GROUP BY P.ProductID, ProductDescription, P.ProductStandardPrice;

TotCost

Or here is another interesting approach using a derived table in the SELECT list: SELECT

P.ProductID, P.ProductDescription, P.ProductStandardPrice, TotCost FROM Product_T P, (SELECT P1.ProductID, SUM(P1.ProductStandardPrice*U.QuantityRequired) FROM Uses_T U, RawMaterial_T R, Product_T P1 WHERE U.MaterialID = R.MaterialID AND U.ProductID = P1.ProductID GROUP BY P1.ProductID) Cost_T WHERE P.ProductID = Cost_T.ProductID; 3-

AS TotCost

For every order that has been received, display the order ID, the total dollar amount owed on that order (you‟ll have to calculate this total from attributes in one or more tables; label this result Total_Due), and the amount received in payments on that order (assume there is only one payment made on each order). To make this query a little simpler, you don‟t have to include those orders for which no payment has yet been received. List the results in decreasing order by the difference between total due and amount paid: Query:

Chapter 4

262

Just to help to verify the result, the following shows all 11 rows of the payment table, and as assumed, there is only one payment per order, but not all orders have payments. Note: Dates in this database sometimes change between editions of the associated textbook, so your results may vary in terms of dates: PayID 2 5 7 4 1 9 11 10 3 6 8

OrderID 24 32 39 28 1 51 69 54 26 34 48

DateC 2021-03-10 2021-03-11 2021-03-11 2021-03-10 2021-03-01 2021-03-11 2021-03-11 2021-03-11 2021-03-10 2021-03-11 2021-03-11

TypeC D D D D D D D D D D D

Amount 25 3000 600 25 1000 150 200 2650 222 575 1000

CommentC Cash Cashiers Check chk 1003 Cash chk101 Cash chk3001 Check # 343 Cash Chk1201 chk2301

Now the query In Microsoft Access S QL: SELECT OrderLine_T.OrderID, SUM(OrderedQuantity*ProductStandardPrice) AS TotalDue, PaymentAmount FROM OrderLine_T, Product_T, Payment_T WHERE OrderLine_T.ProductID = Product_T.ProductID AND OrderLine_T.OrderID = Payment_T.OrderID GROUP BY OrderLine_T.OrderID, PaymentAmount ORDER BY SUM(OrderedQuantity*ProductStandardPrice) PaymentAmount DESC; In Oracle SQL: SELECT OrderLine_T.OrderID, SUM(OrderedQuantity*ProductStandardPrice) AS TotalDue, PaymentAmount FROM OrderLine_T, Product_T, Payment_T WHERE OrderLine_T.ProductID = Product_T.ProductID AND OrderLine_T.OrderID = Payment_T.OrderID GROUP BY OrderLine_T.OrderID, PaymentAmount ORDER BY TotalDue - PaymentAmount DESC; 3-

List each customer who has bought computer desks and the number of units bought by each customer: The first solution is a better approach to this request as it will retrieve a result set of computer desks, whether or not the material and description of said desk is ―oak‖ as is currently shown in the P V F C data set. The second solution is an alternative approach that relies upon the only computer desk description found in the current PVFC data set.

263

Chapter 4

Microsoft Access Query: SELECT Customer_T.CustomerID, CustomerName, SUM(OrderedQuantity) as UnitsBought FROM OrderLine_T, Order_T, Product_T, Customer_T WHERE ProductDescription LIKE '*Computer Desk*' AND Order_T.OrderID = OrderLine_T.OrderID AND Product_T.ProductId = OrderLine_T.ProductID AND Customer_T.CustomerID = Order_T.CustomerID GROUP BY Customer_T.CustomerID, CustomerName; Oracle Query: SELECT Customer_T.CustomerID, CustomerName, SUM(OrderedQuantity) as UnitsBought FROM OrderLine_T, Order_T, Product_T, Customer_T WHERE ProductDescription LIKE '%Computer Desk%' AND Order_T.OrderID = OrderLine_T.OrderID AND Product_T.ProductId = OrderLine_T.ProductID AND Customer_T.CustomerID = Order_T.CustomerID GROUP BY Customer_T.CustomerID, CustomerName; 3-

List each customer who bought at least one product that belongs to product line Basic in March 2021. List each customer only once.

Microsoft Access Query: SELECT DISTINCT C.CustomerID, C.CustomerName FROM Customer_T C, Order_T O, OrderLine_T OL, Product_T P, ProductLine_T PL WHERE C.CustomerID = O.CustomerID AND O.OrderID = OL.OrderID AND OL.ProductID = P.ProductID AND P.ProductLineID = PL.ProductLineID AND PL.ProductLineName = 'Basic' AND DatePart("m",OrderDate) = 3 AND DatePart("yyyy", OrderDate) = 2021; Oracle Query: SELECT DISTINCT C.CustomerID, C.CustomerName FROM Customer_T C, Order_T O, OrderLine_T OL, Product_T P,

Chapter 4

WHERE

3-

264

ProductLine_T PL C.CustomerID = O.CustomerID AND O.OrderID = OL.OrderID AND OL.ProductID = P.ProductID AND P.ProductLineID = PL.ProductLineID AND PL.ProductLineName = 'Basic' AND SUBSTR(O.OrderDate,4,6)='MAR-21';

Modify your answer to Problem and Exercise 6-59 so that you include the number of products in product line Basic that the customer ordered in March 2021.

Microsoft Access Query: SELECT DISTINCT C.CustomerID, C.CustomerName, COUNT(P.ProductID) FROM Customer_T C, Order_T O, OrderLine_T OL, Product_T P, ProductLine_T PL WHERE C.CustomerID = O.CustomerID AND O.OrderID = OL.OrderID AND OL.ProductID = P.ProductID AND P.ProductLineID = PL.ProductLineID AND PL.ProductLineName = 'Basic' AND DatePart("m",OrderDate) = 3 and DatePart("yyyy", OrderDate) = 2021 GROUP BY C.CustomerID, C.CustomerName; Oracle Query: SELECT DISTINCT C.CustomerID, C.CustomerName, COUNT(P.ProductID) FROM Customer_T C, Order_T O, OrderLine_T OL, Product_T P, ProductLine_T PL WHERE C.CustomerID = O.CustomerID AND O.OrderID = OL.OrderID AND OL.ProductID = P.ProductID AND P.ProductLineID = PL.ProductLineID AND PL.ProductLineName = 'Basic' AND SUBSTR(O.OrderDate,4,6)='MAR-21' GROUP BY C.CustomerID, C.CustomerName;

3-

Modify your answer to Problem and Exercise 6-60 so that the list includes the number of products each customer bought in each product line in March 2021.

Microsoft Access Query: SELECT DISTINCT C.CustomerID, C.CustomerName, COUNT(P.ProductID) FROM Customer_T C,

265

Chapter 4

Order_T O, OrderLine_T OL, Product_T P, ProductLine_T PL WHERE C.CustomerID = O.CustomerID AND O.OrderID = OL.OrderID AND OL.ProductID = P.ProductID AND P.ProductLineID = PL.ProductLineID AND PL.ProductLineName = 'Basic' AND DatePart("m",OrderDate) = 3 and DatePart("yyyy", OrderDate) = 2021 GROUP BY C.CustomerID, C.CustomerName, PL.ProductLineID, PL.ProductLineName; Oracle Query: SELECT C.CustomerID, C.CustomerName, PL.ProductLineName, COUNT(P.ProductID) FROM Customer_T C, Order_T O, OrderLine_T OL, Product_T P, ProductLine_T PL WHERE C.CustomerID = O.CustomerID AND O.OrderID = OL.OrderID AND OL.ProductID = P.ProductID AND P.ProductLineID = PL.ProductLineID AND SUBSTR(O.OrderDate,4,6)='MAR-21' GROUP BY C.CustomerID, C.CustomerName, PL.ProductLineID, PL.ProductLineName; 3-

List in alphabetical order the names of all employees (managers) who are now managing people with skill I D B S12. List each such manager‟s name only once, even if that manager manages several people with this skill: Microsoft Access and Oracle Query: SELECT DISTINCT M.EmployeeName FROM Employee_T M, Employee_T E, EmployeeSkills_T ES WHERE SkillID = 'BS12' AND ES.EmployeeID = E.EmployeeID AND E.EmployeeSupervisor = M.EmployeeID ORDER BY 1;

3-

Display the salesperson name, product finish, and total quantity sold (label as TotSales) for each finish by

Chapter 4

266

each salesperson: Microsoft Access and Oracle Query: SELECT DISTINCT SalespersonName, ProductFinish, SUM(OrderedQuantity) AS TotSales FROM Salesperson_T, OrderLine_T, Product_T, Order_T WHERE Salesperson_T.SalespersonID = Order_T.SalespersonID AND Order_T.OrderID OrderLine_T.OrderID AND OrderLine_T.ProductID = Product_T.ProductID GROUP BY SalespersonName, ProductFinish; 3-

=

Write a query to list the number of products produced in each work center (label this result „TotalProducts‟). If a work center does not produce any products, display the result with a total of 0: Microsoft Access and Oracle Query: SELECT WorkCenter_T.WorkCenterID, COUNT(ProductID) AS TotalProducts FROM WorkCenter_T LEFT OUTER JOIN ProducedIn_T ON WorkCenter_T.WorkCenterID=ProducedIn_T.WorkCenterID GROUP BY WorkCenter_T.WorkCenterID;

3-

Develop a list of all the P V F C customers by name with the number of vendors in the same state as that customer (label this computed result NumVendors): Microsoft Access and Oracle Query: SELECT CustomerName, COUNT(VendorID) AS NumVendors FROM Customer_T C LEFT OUTER JOIN Vendor_T V ON C.CustomerState = V.VendorState GROUP BY CustomerName;

3-

OrderIDs for customers lacking payment: Microsoft Access Query (Note that Access does not support MINUS): SELECT Order_T.OrderID FROM Order_T LEFT OUTER JOIN Payment_T ON Order_T.OrderID = Payment_T.OrderID WHERE Payment_T.PaymentID IS NULL; Oracle Query: SELECT OrderID FROM Order_T MINUS SELECT OrderID FROM Payment_T;

267

3-

Chapter 4

Names of states where customers reside, but have no salesperson residing in that state: First, a query solution using MINUS operator (does not work with Microsoft Access): SELECT FROM SELECT FROM

CustomerState Customer_T MINUS SalesPersonState Salesperson_T;

Next, a solution using OUTER JOIN operation: SELECT DISTINCT CustomerState FROM Customer_T LEFT OUTER JOIN Salesperson_T ON CustomerState = SalespersonState WHERE Salesperson_T.SalespersonState IS NULL ORDER BY Customer_T.CustomerState; Student answers will vary as to which approach is chosen as the ―most natural,‖ especially based on their experiences or level of comfort with mathematical set manipulations.

3-

Produce a list of all the products (show product description) and the number of times each product has been ordered: This query requires an outer join because some products may not have been ordered. Because many S Q L systems do not have an outer join operator, often this type of query must use the UNION command. The following answer uses this second approach because it will work with almost any system. Also, note that the question wants the number of times a product has been ordered, not the total quantity ordered: Microsoft Access Query: SELECT Product_T.ProductID, ProductDescription, COUNT(*) as TimesOrdered FROM Product_T INNER JOIN OrderLine_T ON Product_T.ProductID = OrderLine_T.ProductID GROUP BY Product_T.ProductID, ProductDescription UNION SELECT ProductID, ProductDescription, 0 FROM Product_T WHERE EXISTS (SELECT * FROM OrderLine_T WHERE (OrderLine_T.ProductID = Product_T.ProductID))=FALSE; Oracle Query: SELECT Product_T.ProductID, ProductDescription, COUNT(*) as TimesOrdered

Chapter 4

FROM WHERE GROUP BY UNION SELECT

FROM WHERE

3-

268

Product_T,OrderLine_T Product_T.ProductID = OrderLine_T.ProductID Product_T.ProductID, ProductDescription ProductID, ProductDescription, 0 Product_T NOT EXISTS (SELECT * FROM OrderLine_T WHERE OrderLine_T.ProductID = Product_T.ProductID);

Display the customer I D, name, and order I D for all customer orders. For those customers who do not have any orders, include them in the display once: Query (Does not work with Access): SELECT c.CustomerID, CustomerName, NVL(OrderID,0) FROM Customer_T c LEFT OUTER JOIN Order_T o ON c.CustomerID = o.CustomerID; OR SELECT CUST.CustomerID, CustomerName, OrderID

269

Chapter 4

FROM

Customer_T CUST LEFT OUTER JOIN Order_T ORD ON CUST.CustomerID = ORD.CustomerID ORDER BY CUST.CustomerID; 3-

Display the Employee I D and Employee Name for those employees who do not possess the skill Router.

Display the results in order by EmployeeName: Microsoft Access and Oracle Query: SELECT EmployeeID, EmployeeName FROM Employee_T WHERE EmployeeID NOT IN (SELECT ES.EmployeeID FROM EmployeeSkills_T ES, Skill_T S WHERE SkillDescription = 'Router' AND ES.SkillID = S.SkillID) ORDER BY EmployeeName;

3-

Name of customer 16, and other customers in same zip code Microsoft Access and Oracle Query: SELECT C1.CustomerName, C2.CustomerName, C1.CustomerPostalCode FROM Customer_T C1, Customer_T C2 WHERE C1.CustomerID = 16 AND C1.CustomerPostalCode = C2.CustomerPostalCode AND C2.CustomerID <> 16;

3-

P&E 6-71 re-written for all customers Microsoft Access and Oracle Query: SELECT C1.CustomerName, C2.CustomerName AS CName2,

Chapter 4

FROM WHERE 3-

270

C1.CustomerPostalCode Customer_T C1, Customer_T C2 C1.CustomerPostalCode = C2.CustomerPostalCode AND C2.CustomerID <> C1.CustomerID;

Display the customer I D, name, and order I D for all customer orders. For those customers who do not have any orders, include them in the display once, with a 0 value for OrderID: Microsoft Access and Oracle Query: SELECT Customer_T.CustomerID, CustomerName, OrderID FROM Customer_T, Order_T WHERE Customer_T.CustomerID = Order_T.CustomerID UNION SELECT CustomerID, CustomerName, 0 FROM Customer_T WHERE NOT EXISTS (SELECT * FROM Order_T WHERE Order_T.CustomerID = Customer_T.CustomerID); Or replace last three lines above with: WHERE

3-

CustomerID NOT IN (SELECT CustomerID FROM Order_T);

Show the customer I D and name for all the customers who have ordered both products with I Ds 3 and 4 on the same order: Microsoft Access and Oracle Query: SELECT C.CustomerID, CustomerName FROM Customer_T C, Order_T O1, OrderLine_T OL1 WHERE C.CustomerID = O1.CustomerID AND O1.OrderID = OL1.OrderID AND OL1.ProductID = 3 AND O1.OrderID IN (SELECT OrderID FROM OrderLine_T OL2 WHERE OL2.ProductID = 4); Or here is another interesting approach using derived tables (color for some parentheses helps to show the nesting of SELECTs):

271

Chapter 4

SELECT FROM WHERE

DISTINCT(CustomerID), CustomerName Customer_T CustomerID IN (SELECT CustomerID FROM (SELECT p3.OrderID FROM (SELECT OrderID FROM OrderLine_T WHERE ProductID = 3) p3, (SELECT OrderID FROM OrderLine_T WHERE ProductID = 4) p4 WHERE p3.OrderID = p4.OrderID) Orders, Order_T WHERE Orders.OrderID = Order_T.OrderID);

3-

Customer names of customers who have ordered (on same or different orders) both products 3 and 4: Microsoft Access Query: SELECT C1.CustomerID, C1.CustomerName FROM Customer_T C1 WHERE (C1.CustomerID IN (SELECT C.CustomerID FROM Customer_T C,Order_T O1, OrderLine_T OL1 WHERE C.CustomerID = O1.CustomerID AND O1.OrderID = OL1.OrderID AND OL1.ProductID = 4)) AND (C1.CustomerID IN (SELECT C.CustomerID FROM Customer_T C,Order_T O1, OrderLine_T OL1 WHERE C.CustomerID = O1.CustomerID AND O1.OrderID = OL1.OrderID AND OL1.ProductID = 3)) Oracle SELECT C.CustomerID, CustomerName FROM Customer_T C, Order_T O1, OrderLine_T OL1 WHERE C.CustomerID = O1.CustomerID AND O1.OrderID = OL1.OrderID AND OL1.ProductID = 3 INTERSECT SELECT C.CustomerID, CustomerName FROM Customer_T C, Order_T O1, OrderLine_T OL1 WHERE C.CustomerID = O1.CustomerID AND

Query:

Chapter 4

272

O1.OrderID = OL1.OrderID AND OL1.ProductID = 4; 3-

List vendor ID, vendor name, material I D, material name, and supply unit price for those materials that are provided by more than one vendor: Microsoft Access and Oracle Query: SELECT v.VendorID, v.VendorName, rm.MaterialID, rm.MaterialName, s.SupplyUnitPrice FROM Vendor_T v, Supplies_T s, Rawmaterial_T rm WHERE v.vendorID = s.VENDORID AND s.materialID = rm.materialID AND s.materialID IN (SELECT MaterialID FROM Supplies_T s2 WHERE s2.MaterialID = rm.MaterialID GROUP BY s2.MaterialID HAVING COUNT(s2.VendorID)>1) ORDER BY rm.MaterialID;

3-

Review first query in Correlated Subqueries section in Chapter: This query will not yield the desired result when there are two or more products that have the same largest standard price. You would need to re-write the query to use the comparison >= operator.

3-

List the IDs and names of all products that cost less than the average product price in their product line.

Microsoft Access and Oracle Query: SELECT P.ProductID, P.ProductDescription FROM Product_T P WHERE ProductStandardPrice < ( SELECT AVG(ProductStandardPrice) FROM Product_T P1 WHERE P1.ProductLineID = P.ProductLineID);

3-

List the I Ds and names of those sales territories that have at least 50 percent more customers as the average number of customers per territory.

Microsoft Access and Oracle Query: SELECT T.TerritoryID, T.TerritoryName, COUNT(D.CustomerID) FROM Territory_T T, DoesBusinessIn_T D WHERE T.TerritoryID = D.TerritoryID GROUP BY T.TerritoryID, T.TerritoryName HAVING COUNT(D.CustomerID) >= 1.5 * ( SELECT AVG(CustCount) FROM (SELECT COUNT(D1.CustomerID) AS CustCount FROM DoesBusinessIn_T D1 GROUP BY D1.TerritoryID));

3-

List the order number, product ID and ordered quantity for all customer orders for which the ordered

273

Chapter 4

quantity is greater than the average ordered quantity of that product: (Hint: This involves a correlated subquery.)

Microsoft Access Query: SELECT Order11.OrderID, Order11.OrderedQuantity, Order11.ProductID FROM PRODUCT_T INNER JOIN OrderLine_T AS Order11 ON PRODUCT_T.ProductID = Order11.ProductID WHERE (((Order11.OrderedQuantity)>( SELECT AVG(OrderedQuantity) FROM OrderLine_T x1 WHERE x1.ProductID = Order11.ProductID)) AND ((PRODUCT_T.ProductID)=[Order11].[ProductID])); Oracle Query: SELECT Order11.OrderID, Order11.OrderedQuantity, Order11.ProductID FROM Product_T,OrderLine_T Order11 WHERE Product_T.ProductID = Order11.ProductID AND Order11.OrderedQuantity > (SELECT AVG(OrderedQuantity) FROM OrderLine_T x1 WHERE x1.ProductID = Order11.ProductID); 3-

List the salesperson that has sold the most computer desks: Microsoft Access Query: It is easiest to create a subquery first. The first query we will call tsales: SELECT Salesperson_T.SalespersonID, SUM( OrderLine_T.OrderedQuantity) AS [TotSales] FROM OrderLine_T, Order_T,Product_T, Salesperson_T, DoesBusinessIn_T WHERE Order_T.OrderID=[OrderLine_T].[OrderID] AND OrderLine_T.ProductID=[Product_T].[ProductID] AND Product_T.ProductDescription="Oak Computer Desk" AND Order_T.CustomerID=[DoesBusinessIn_T].[CustomerID] AND Salesperson_T.SalesTerritoryID= [DoesBusinessIn_T].[TerritoryID] GROUP BY Salesperson_T.SalespersonID; Next, find the SalesPersonID for the salesperson who had the highest sales: SELECT SalespersonID FROM tsales WHERE totsales = (SELECT MAX(totsales) FROM tsales); Oracle Query: SELECT Salesperson_T.SalespersonID, SUM(OrderedQuantity) AS TotSales FROM OrderLine_T,

Chapter 4

274

Order_T, Product_T, DoesBusinessIn_T, Salesperson_T WHERE Order_T.OrderID = OrderLine_T.OrderID AND OrderLine_T.ProductID = Product_T.ProductID AND ProductDescription = 'Oak Computer Desk' AND Order_T.CustomerID = DoesBusinessIn_T.CustomerID AND Salesperson_T.SalesTerritoryID = DoesBusinessIn_T.TerritoryID GROUP BY Salesperson_T.SalespersonID; Save the result as tsales and run to find the salesperson with the most computer desk sales: SELECT Salesperson_ID FROM tsales WHERE totsales = (SELECT MAX(totsales) FROM tsales); 3-

Display in product I D order the product I D and total amount ordered of that product by the customer who has bought the most of that product; use a derived table in a FROM clause to answer this query. Note that the result of this query is a subset (first and last columns) of the prior query result.

Microsoft Access and Oracle Query: SELECT F1.ProductID, MAX(F1.ProdCustTotal) as TotOrdered FROM (SELECT ProductID, CustomerID, SUM(OrderedQuantity) AS ProdCustTotal FROM OrderLine_T OL2, Order_T O2 WHERE OL2.OrderID = O2.OrderID GROUP BY ProductID, CustomerID) F1 GROUP BY F1.ProductID ORDER BY F1.ProductID; Result: ProductID 1 2 3 4 5 6 7 8 10 13 14 17 20

TotOrdered 9 26 12 4 10 4 4 2 9 2 10 5 1

275

3-

Chapter 4

Employee information for all employees in each state who were hired before the most recently hired person in that state: Microsoft Access and Oracle Query: SELECT * FROM Employee_T E1 WHERE EmployeeDateHired < (SELECT MAX(EmployeeDateHired) FROM Employee_T E2 WHERE E1.EmployeeState = E2.EmployeeState);

3-

Marketing Manager cross-selling analyses: a. List the IDs for all the products that have sold in total more than 20 units across all orders: Microsoft Access and Oracle Query for part a.: SELECT X.ProductID FROM OrderLine_T X GROUP BY X.ProductID HAVING SUM(X.OrderedQuantity) > 20; Result for part a.: ProductID 2 3 b. List all the IDs for the orders that include products that satisfy this first query along with the number of products on those orders (see result below for an example). Only orders with three or more products.

Microsoft Access and Oracle Query for part b.: SELECT Y.OrderID, COUNT(Y.ProductID) AS NumProductsOnOrder FROM OrderLine_T Y WHERE Y.OrderID IN (SELECT T.OrderID FROM OrderLine_T T WHERE T.ProductID IN (SELECT X.ProductID FROM OrderLine_T X GROUP BY X.ProductID HAVING SUM(X.OrderedQuantity) > 20)) GROUP BY Y.OrderID

Chapter 4

HAVING

COUNT(Y.ProductID) >= 3;

276

277

Chapter 4

Result for part b.: OrderID NumProductsOnOrder 2

3

4

4

1

3

c. What are the (other) products sold on the orders in the Part b. result: Microsoft Access and Oracle Query for part c.: SELECT DISTINCT P.ProductID, P.ProductDescription FROM OrderLine_T O, Product_T P WHERE P.ProductID = O.ProductID AND O.OrderID IN (SELECT Y.OrderID FROM OrderLine_T Y WHERE Y.OrderID IN (SELECT T.OrderID FROM OrderLine_T T WHERE T.ProductID IN (SELECT X.ProductID FROM OrderLine_T X GROUP BY X.ProductID HAVING SUM(X.OrderedQuantity) > 20)) GROUP BY OrderID HAVING COUNT(Y.ProductID) >= 3) ORDER BY P.ProductID;

Chapter 4

278

Result for part c.: ProductID 2 3 4 5 6 8 10 14 3-

ProductDescription Birch coffee table Oak computer desk Entertainment center Writer‘s desk 8-Drawer dresser 48‖ bookcase 96‖ bookcase Writer‘s Desk

For each product display, in ascending order by product I D, the product I D and description along with the customer I D and name for the customer who has bought the most of that product; also show the total quantity ordered by that customer (who has bought the most of that product). Use a correlated subquery: Microsoft SELECT

Access and P1.ProductID, P1.ProductDescription, C1.CustomerID, C1.CustomerName, SUM(OL1.OrderedQuantity) AS TotOrdered FROM Customer_T C1, Product_T P1, OrderLine_T OL1, Order_T O1 WHERE C1.CustomerID = O1.CustomerID AND O1.OrderID = OL1.OrderID AND OL1.ProductID = P1.ProductID GROUP BY P1.ProductID, ProductDescription, C1.CustomerID, CustomerName HAVING SUM(OL1.OrderedQuantity) >= ALL (SELECT SUM(OL2.OrderedQuantity) FROM OrderLine_T OL2, Order_T O2 WHERE OL2.ProductID = P1.ProductID AND OL2.OrderID = O2.OrderID AND O2.CustomerID <> C1.CustomerID GROUP BY O2.CustomerID) ORDER BY P1.ProductID;

Oracle

Result:

ProductID 1 2 3 4

ProductDescription Cherry end table Birch Coffee table Oak Computer desk Entertainment center

CustomerID 4 4 3 16

CustomerName Eastern Furniture Eastern Furniture Home Furnishings ABC Furniture Co.

TotOrdered 9 26 12 4

Query:

279

Chapter 4

ProductID 5 6 7 8 10 13 14 17 20

ProductDescription Writer‘s desk 8-Drawer dresser 48‖ bookcase 48‖ bookcase 96‖ bookcase Nightstand Writer‘s desk High back leather chair Armoire

CustomerID 15 4 4 3 4 13 15 1 8

CustomerName Janet‘s Collection Eastern Furniture Eastern Furniture Home Furnishings Eastern Furniture Ikards Janet‘s Collection Contemporary Casuals Dunkins Furniture

TotOrdered 10 4 4 2 9 2 10 5 1

Suggestions for Field Exercises 3-

This question is self-explanatory.

3-

Three differences that you may want to help the students discover: o

Primary and foreign keys are specified with the CREATE TABLE or ALTER TABLE commands in S Q L*PLUS. MS Access uses a graphical interface to create tables and to establish primary and foreign keys.

o

MS Access SQL does not include the CREATE VIEW or DROP VIEW commands. Instead, the query that would be used as part of the CREATE VIEW syntax is saved as a query, which can be accessed later through new select statements by simply specifying the query name.

o

MS Access has a keyword, DISTINCTROW, which is not found in other D BMS SQL implementations.

Five similarities between Oracle S QL and MS Access SQL: o

Both use the semicolon to mark the end of a statement and cause it to execute.

o

Basic SQL syntax is very similar, using the keywords SELECT, FROM, WHERE, GROUP BY, ORDER BY, and HAVING in the same fashion.

o

Both use brackets to specify the order of expression evaluation.

o

Subqueries and correlated subqueries can be written in both.

o

Both are insensitive to spacing and line breaks within a statement.

Project Questions

Chapter 4

3-

280

Write and execute queries.

The answers will depend on the students‘ and the instructor‘s choices.

3-

Identify opportunities for using triggers.

The answers will depend on the students‘ and the instructor‘s choices.

3-

Create a strategy for reviewing your database implementation with the appropriate stakeholders.

When reviewing the database implementation, it is essential that the key stakeholders are able to evaluate the database content without the risk of getting confused by the seemingly disjointed structure of a normalized relational database. One possible way to address this is to do ―virtual denormalization‖ by creating views for the data needs that have to be addressed with relational joins. This way, responding to operationally simple data needs can be demonstrated in a simple way, instead of the need to create complex joins throughout the process.

In addition, it is essential that the key stakeholders understand that the database has been designed to be used as a foundation for applications, by experts, or through sophisticated front-end tools that have been configured automatically. You don‘t want to scare people away at this stage of the process.

As discussed in the context of Chapter 5, the review should be done by individuals who are best aware of the technical details of the tasks being affected. It is likely that this varies depending on the section of the database. Thus, for certain tasks Alex Martin is the best person to discuss the detailed data needs and for others, Pat Smith. Overall approval by Mr. Forondo is needed, but only after detailed reviews by the subject area experts.

Chapter 7 Databases in Applications Chapter Overview This chapter describes the fundamentals of the client/server approach to organizing computing resources and discusses the role of databases in this approach. This chapter provides foundational knowledge required for understanding newer approaches to distributed computing, such as web applications covered in this chapter and distributed databases in Chapter 13. This chapter focuses on the impact of client/server systems and how to best take advantage of the resources and choices available. Coverage of three-tier architecture is provided along with specific Java (J SP) and Python code examples for database connections. The chapter also explores web applications and introduces JavaScript Object Notation (JSON).

281

Chapter 4

Chapter Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Provide the student with a comprehensive view of the possibilities of client/server computing and the advantages and disadvantages of different architectural structures.

2. Provide a framework for discussion of three-tiered architectures and the vocabulary that goes along with it.

3. Illustrate the uses of application partitioning across the different segments of the network and the client/server system; form a basis for understanding the decision-making process in implementing various configurations.

4. Provide the student with the conceptual underpinnings of connections to remote databases.

5. Emphasize the problems of database security and impart an understanding of techniques used to enhance database security, particularly in the client/server environment.

6. Emphasize the importance of new and emerging technologies that will carry businesses forward in a constantly evolving environment.

7. Help the students understand the fundamental concepts regarding how clients interact with remote applications and data so that as the technology changes the student can effortlessly transition from one technology to another.

Key Terms Application partitioning

Deadlock resolution

Middleware

Application program

Exclusive lock

Open Database Connectivity

interface (API)

(ODBC)

Client/server system

Fat client

Shared lock

Concurrency control

Inconsistent read problem

Thin client

Database server

Java servlet

Three-tier architecture

Chapter 4

282

Application partitioning

Deadlock resolution

Middleware

Database security

JavaScript Object Notation (J SON)

Transaction boundaries

Deadlock

Locking

Two-phase locking protocol

Deadlock prevention

Locking level (lock granularity)

Versioning

Classroom Ideas 1. Create a network structure of servers and clients. Give students a simulated design of a business with a file server architecture and estimated number of transactions each day. Have the students map out the traffic between pieces of the system and observe the system load in a normal business day. Ask the students to reassess their observations if the business has a 10 percent growth factor.

Now have them follow through the same transactions on a three-tier client/server system. Observe again with the 10 percent growth factor. Ask for their observations for each of the three architectures.

Request a recommendation for the most advantageous approach to use. Students should defend their answers.

2. Use sections of Figure 7-6 as examples of the basic process needed for program code access of databases. Organize students into small groups and assign them Problem and Exercise 7-15; compare group solutions in large classroom discussion.

3. Organize the students into small groups and assign Problem and Exercise 7-14. Have each group report back to the class as a whole. Compare/Contrast the small group findings with one another in discussion with the whole class.

4. Introduce the transaction concept (Figure 7-18) and transaction and concurrency control features of relational DBMS (Figure 7-19).

5. Have the students seek examples of computer security problems or ―white collar‖ crime in the press and bring them to class. Alternatively, bring an example or two yourself. Then discuss various security threats, security procedures, and the procedures‘ relative effectiveness (Figure 7-25).

6. Discuss the problem of lost updates and concurrency control (Figure 7-20). One way to dramatize this process is to conduct a manual demonstration: one student is ―keeper of the data,‖ two others are ―user X‖ and ―user Y.‖

283

Chapter 4

7. Now discuss locks and the problems that can result from their use (Figures 7-21 through 7-23).

Locks are an imperfect (but effective) mechanism for multi-user databases.

8. Discuss versioning and optimistic concurrency control (Figure 7-24). Compare pessimistic and optimistic concurrency control and the conditions under which each is likely to be effective or preferred.

9. Have the students use a simple database application that has not yet been converted to run on the Internet. Divide the students into groups and have each group Web-enable the application in a different way or language. Have each group make a presentation to the class on how they accomplished their goal. Have each group turn in a hard copy of their code. Make these into a handout to distribute to the class in the next meeting.

10. Organize students into small groups and have each group research the use of J SON in a distributed application. Ask each group to report their findings back to the class as a whole.

Answers to Review Questions 3-

Define each of the following key terms: a. Application partitioning. Assigning portions of application code to client or server partitions in order to achieve better performance and interoperability b. Application program interface (A PI). Type of software that allows a specific front-end program development platform to communicate with a particular back-end database server, even when the front end and back end were not built to be compatible c. Client/server system. A common solution for hardware and software organization that implements the idea of distributed computing. Many client/server environments use a local area network (L A N) to support a network of personal computers—each with its own storage—that are also able to share common devices (such as a hard disk or printer) and software (such as a D BMS) attached to the L AN. Several client/server architectures have evolved; they can be distinguished by the distribution of application logic components across clients and servers. d. Middleware. A type of software that allows an application to interoperate with other software without requiring the user to understand and code the low-level operations

Chapter 4

284

e. Locking. Concurrency control mechanisms that deny access to other users in a multi-user environment while an update is completed or aborted f. Versioning. Concurrency control mechanism that doesn‘t use record locking. Each transaction is restricted to a view of the database as of the time that transaction started, and when a transaction modifies a record, the DBMS creates a new record version instead of overwriting the old record. g. Deadlock. An impasse that results when two or more transactions have locked a common resource, and each waits for the other to unlock that resource.

3-

3-

Match terms with appropriate definitions: f

client/server system

d

application program interface (A PI)

a

fat client

e

database server

g

middleware

h

three-tier architecture

b

thin client

i

database security

c

lock granularity

Advantages of client/server architectures: With their ability to accept an open systems approach, client/server architectures have offered businesses opportunities to better fit their computer systems to their needs. Their major advantages are: a. Functionality can be delivered in stages to the end-users, allowing them to benefit from the project faster. b. The GUI interfaces common in client/server environments encourage users to utilize the applications‘ functionality. c. Client/server solutions are flexible and scalable. These system characteristics facilitate business

285

Chapter 4

process re-engineering. d. More processing can be performed close to the source of data being processed, which improves response times and reduces network traffic. e. Client/server architectures allow the development of web-enabled and mobile applications, thus facilitating the ability of organizations to communicate effectively internally and to conduct external business over the Internet.

3-

Contrast the following terms: a. Two-tier architecture; three-tier architecture. Two-tier architecture distributes presentation logic on the client, storage logic on the server, and then places the processing logic either on the client, server, or distributed between the server and client. Three-tier architecture includes another server in addition to the client and database server layers; it allows application code to be stored on the additional server. b. Fat client; thin client. A distinction among client capabilities that is based on processing capabilities, a fat client is responsible for more processing—including presentation logic, extensive application logic, and business rules logic—while a thin client is responsible for much less processing (typically only presentation logic). c. Optimistic concurrency control; pessimistic concurrency control. Pessimistic approaches use record locking procedures, while optimistic approaches use versioning to achieve concurrency control. d. Deadlock prevention; deadlock resolution. When deadlock prevention is employed, user programs must lock all records they will require at the beginning of a transaction, rather than one at a time. Deadlock resolution allows deadlocks to occur, but builds mechanisms into the D BMS for detecting and breaking the deadlocks. e. Shared lock; exclusive lock. Placing a shared lock on a record prevents another user from placing an exclusive lock on that record. Placing an exclusive lock on a record prevents another user from placing any type of lock on that record. f. Two-phase locking protocol; versioning. The two-phase locking protocol relates to the cautious approach of locking the record so that other programs cannot use it. In reality, in most cases

Chapter 4

286

other users will not request the same records, or they may only want to read them, which is not a problem (Celko, 1992). By using versioning, a DBMS assumes that most of the time other users do not want the same record, or if they do, they only want to read (but not update) the record.

With versioning, there is no form of locking.

3-

Some advantages of three-tier and n-tier architectures (Thompson, 1997; see textbook): a. Scalability. Three-tier architectures are more scalable than two-tier architectures. For example, the middle tier can be used to reduce the load on a database server by using a transaction processing monitor to reduce the number of connections to a server. b. Technological flexibility. It is easier to change DBMS engines with a three-tier architecture, though triggers and stored procedures will need to be rewritten. The middle tier can even be moved to a different platform. Simplified presentation services make it easier to implement various desired interfaces such as Web browsers, kiosks, or mobile devices. c. Lower long-term costs. Use of off-the-shelf components or services in the middle tier can reduce costs as can substitution of modules within an application. d. Better match of systems to business needs. New modules can be built to support specific business needs rather than building more general, complete applications. e. Improved customer service. Multiple interfaces can access the same business processes. f. Competitive advantage. The ability to react to business changes quickly (by changing small modules of code rather than entire applications) can be used to gain a competitive advantage. g. Reduced risk. Again, the ability to implement small modules of code quickly and combine them with code purchased from vendors limits the risk assumed with a large-scale development project.

Some disadvantages of three-tier and n-tier architectures: a. High short-term costs. Implementing a three-tier architecture requires that the presentation component be split from the process component. Accomplishing this may require more programming in a 3GL language (such as C) than is required in implementing a two-tier architecture. b. Incompatible standards. There are few proposed standards for T P monitors as yet. There are

287

Chapter 4

several competing standards proposed for distributed objects, but it is not yet clear which standard will prevail.

3-

Common components needed to create a web-based application: There are four main components including a database server (storage logic and D B M S), a web server (functionality to respond to browser clients‘ requests), an application server (software for creating dynamic Web sites), and a client application (web browser; e.g., Firefox, Safari, Chrome).

3-

Six common steps to access databases: a. Identify and register a database driver. b. Open a connection to a database. c. Execute a query against the database. d. Process the results of the query. e. Repeat steps c and d as necessary. f. Close the connection to the database.

3-

Key components to ensuring success with client/server: a. Development of a plan for distribution, including an analysis of how the distributed system will interact with other systems b. Analysis of network performance, including projections of load placed on the system by the client/server application. Once an analysis has been performed, a plan can be implemented to upgrade the network to handle the increased load c. Tuning of the production system once in place d. Implementation of troubleshooting procedures e. Code management during the development phase

3-

Python program components necessary for dynamic Web site: A Python program that enables a dynamic Web site will typically be based on one of the popular Python frameworks, such as Django, which hide some of the complexity. The Python solution will reside on the application server and will consist of Model, View, and Serializer classes. The Django framework

Chapter 4

288

maintains the database connections, issues appropriate SQL queries, and populates the results in to a set of instances of the result class. The database itself resides on a database server.

Answers to Problems and Exercises 3-

Business and technology characteristics to consider when reaching a client/server adoption decision: a. Accurate business problem analysis. Just as is the case with other computing architectures, it is critical to develop a sound application design and architecture for a new client/server system.

Accurately define the scope of the problem and conduct a detailed requirements determination process. Use the results to select the technology. b. Detailed architecture analysis. It is also important to specify the details of the client/server architecture. Building a client/server solution involves connecting many components that may not work together easily. One of the often-touted advantages of client/server computing, the ability to accept an open systems approach, can be very detrimental if the heterogeneous components chosen are difficult to connect. In addition to specifying the client workstations, server(s), network, and DBMS, analysts should also specify network infrastructure, the middleware layer, and the application development tools to be used. At each juncture, analysts should take steps to assure that the tools will connect with the middleware, database, network, and so forth. c. Avoiding tool-driven architectures. As above, project requirements should be determined before software tools are chosen, not the reverse. When a tool is chosen first and then applied to the problem, one runs the risk of a poor fit between problem and tool. Tools used in this manner are more likely to have been chosen based on an emotional appeal rather than on the appropriate functionality of the tool. d. Achieving appropriate scalability. Moving to a multi-tier solution allows client/server systems to scale to any number of users and handle diverse processing loads. However, multi-tiered solutions are significantly more expensive and difficult to build. The tools to develop a multi-tier environment are still limited, too. Architects should avoid moving to a multi-tier solution when it is not really needed. Usually, multi-tier makes sense in environments of more than 100 concurrent users, high-volume OLTP systems, or for real-time processing. Smaller, less intense

289

Chapter 4

environments can frequently run more efficiently on traditional two-tier systems, especially if triggers and procedures are used to manage the processing. e. Appropriate placement of services. Again, a careful analysis of the business problem being addressed is important when making decisions about the placement of processing services. The move toward thin clients and fat servers is not always the appropriate solution. Moving the application logic to a server, thus creating a fat server, can affect capacity as end users all attempt to use the application now located on the server. Sometimes it is possible to achieve better scaling by moving application processing to the client. Fat servers do tend to reduce network load because the processing takes place close to the data, and fat servers do lessen the need for powerful clients. Understanding the business problem intimately should help the architect to distribute the logic appropriately. f. Network analysis. The most common bottleneck in distributed systems is still the network.

Therefore, architects ignore the bandwidth capabilities of the network that the system must use at their peril. If the network cannot handle the amount of information that needs to pass between client and server, response time will suffer badly, and the system is likely to fail. g. Be aware of hidden costs. Client/server implementation problems go beyond the analysis, development, and architecture problems listed previously (Atre, 1995). For example, systems that are intended to use existing hardware, networks, operating systems, and D BMS are often stymied by the complexities of integrating these heterogeneous components together to build the client/server system. Training is a significant and recurring expense that is often overlooked. The complexities of working in a multi-vendor environment can be very costly.

3-

The difference between a static and a dynamic Web site: A static Web page is fixed in time and cannot receive user input. A dynamic page allows the querying of live data and storage of user input. Using dynamic Web pages is important in the facilitation of e-business because it allows the conduction of business to take place quickly and easily, often without the intervention of costly customer support.

3-

Movement to client/server databases systems: Mission-critical systems that were resident on mainframe systems a decade ago have tended to remain on mainframe systems. Less mission-critical—frequently workgroup level—systems have been developed using client/server architectures. However, the popularity of client/server architectures and the strong desire to achieve more effective computing in more distributed environments as business perspectives became broader and more global has led to the deployment of mission-critical systems using client/server

Chapter 4

290

architectures. We expect that each organization will need to achieve a balance between mainframe and client/server platforms, and between centralized and distributed solutions, that are closely tailored to the nature of their data and location of business users of the data. As Hurwitz (1996) suggests, data that do not need to be moved often can be centralized on a mainframe. Data to which users need frequent access, complex graphics, and the user interface should be kept close to the users‘ workstations.

3-

Languages associated with Internet application development: There are scripting or markup languages, such as H T M L, X H T M L, and X M L. These scripting languages are intended for handling layout and display of documents, rather than for programming functions. General purpose, object-oriented languages were brought into use for these activities. Java is an example of one of these. On the server side, Java Server Pages (J S P) are a mixture of Java (for business logic and database access) and H T M L (for user interface). Small Java programs, called Java applets, download from the Web server to the client and run in a Java-compatible Web browser. The chapter also discussed Python as a widely used server-side language the use of which is made significantly easier with frameworks that hide low-level technical details from application developers.

JavaScript is a client-side scripting language based on Java, but it is easier to learn. JavaScript can be used to achieve interoperability and dynamic content. VBScript, based upon Visual Basic but easier to learn, can be used to create interactive Web pages. Cascading style sheets (C S S) have been developed to allow both a developer and a user to create style sheets that can define any Web page. JavaScript Object Notation (J S O N) is used as a language specifying the structures for data that is moved between various components in a multi-tiered solution.

3-

Annotation of dynamic Web site code: Student answers will vary based on the site(s) used for this exercise.

3-

Re-write Figure 7-6 using Python or PHP: Replace the code in Figure 7-6 (a) with the following PHP code <?php // define variables and set to empty values $firstNameErr = ""; $lastNameErr = ""; $emailErr = ""; $userNameErr = ""; $passwordErr = ""; $firstName = ""; $lastName = ""; $email = ""; $userName = "";

291

Chapter 4

$password = "";

//define variables for db connection $servername = "localhost"; $username = "username"; $password = "password"; $dbname = "myDB"; if ($_SERVER["REQUEST_METHOD"] == "POST") { //check for a first name if (empty($_POST["first_name"])) { $firstNameErr = "You forgot to enter your first name!"; } else { $firstName = $_POST["first_name"]; } //check for a last name if (empty($_POST["last_name"])) { $lastNameErr = "You forgot to enter your last name!"; } else { $lastName = $_POST["last_name"]; } //check for an email address if (empty($_POST["email"])) { $emailErr = "You forgot to enter your email address!"; } else { $email = $_POST["email"]; } //check for a user name if (empty($_POST["user_name"])) {

Chapter 4

292

$userNameErr = "You forgot to enter your user name!"; } else { $userName = $_POST["user_name"]; } //check for a password and match against the confirmed password if (empty($_POST["password1"])) { $passwordErr = "You forgot to enter your password!"; } else { if($_POST["password1"]==$_POST["password2"]){ $$password = $_POST["password1"]; } else { $passwordErr = "Your password did not match the confirmed password!"; } } //If everything's OK // Create connection $conn = mysqli_connect($servername, $username, $password, $dbname); // Check connection if (!$conn) { die("Connection failed: " . mysqli_connect_error()); } $sql = "INSERT INTO Users (firstname, lastname, email, username, password) VALUES ('" + $firstName + "', '" + $lastName + "','" + $email + "','" + $userName + "','" + $password + "',)";

if (mysqli_query($conn, $sql)) { echo "New record created successfully"; } else { echo "Error: " . $sql . "<br>" . mysqli_error($conn); }

293

Chapter 4

mysqli_close($conn); } 3-

Re-write Figure 7-10 thru 7-14 using Java: Figure 7-10 remains unchanged. The code in 7-14 through 7-16 should be replaced the two classes below.

Please note that an appropriate database connection setup using J BDC is assumed. package EmployeeAPI; public class Employee { private final String FirstName; private final String LastName; private final String Title; private final int Age; private final String UserName; private final char Status; public Employee(String firstName, String lastName, String title, int age, String userName, char status) { this.FirstName = firstName; this.LastName = lastName; this.Title = title; this.Age = age; this.UserName = userName; this.Status = status; } public String getFirstName() { return FirstName; } public String getLastName() { return LastName; }

Chapter 4

public String getTitle() { return Title; } public int getAge() { return Age; } public String getUserName() { return UserName; } public char getStatus() { return Status; } } package EmployeeAPI; import java.util.concurrent.atomic.AtomicLong; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.sql.*; @RestController public class EmployeeController { private static final String template = "Hello, %s!"; private final AtomicLong counter = new AtomicLong(); private ArrayList<Employee> listEmployees ; @RequestMapping("/employee") public List<Employee> ListAllEmployees() { listEmployees = new ArrayList<Employee>(); ResultSet rawData = GetAllEmployees();

294

295

Chapter 4

while(rawData.hasNext()) { Result row = rawData.next(); listEmployees.add(newEmployee(row.getProperty("FirstName"), row.getProperty("LastName"), row.getProperty("Title"), row.getProperty("Age"), row.getProperty("UserName_id"), row.getProperty("Status"))); } return listEmployees; } public ResultSet getAllEmployees() throws SQLException{ Connection con; Statement stmt; con = DriverManager.getConnection("jdbc:mysql://localhost/test", "admin", "Javar0cks"); stmt = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_READ_ONLY); query = "SELECT * FROM Employees ORDER BY id";

rset = stmt.executeQuery(query); return rset; } } 3-

What is transaction integrity? Why is it important?

A transaction is the identification of the sequence of steps that constitute a well-defined business activity.

Transaction integrity includes those actions taken to enforce the commitment of all of the steps that constitute a transaction. In processing a transaction, we want any changes to the database to be made only if the entire transaction is processed successfully. If the transaction aborts at any point, no changes can be allowed, or else the database will not reflect the data needed to manage the firm.

Chapter 4

3-

296

Sample code in Figure 7-10 – necessary changes?

The only thing that will need to change is the connection string, i.e., the part that identifies the name/address of the database that you connect to. This connection string will be provided to you by the cloud service provider. The connection strings can be found in the textboxes labeled ―connect to the database‖ in the respective figures.

3-

The advantage of optimistic v s pessimistic concurrency control: ersu

The main advantage of versioning (optimistic) over locking (pessimistic) is performance improvement.

Read-only transactions can run concurrently with updating transactions without loss of database consistency.

3-

The difference between shared locks and exclusive locks: Shared locks enable others to read a record that is locked by a given user, but not to update a record until it is unlocked. Exclusive locks cause a record to be unavailable for reading until it is unlocked.

3-

The difference between deadlock prevention and deadlock resolution: Deadlock prevention requires all users to lock all records they will require at the beginning of a transaction as opposed to one at a time. Unfortunately, it is often difficult to predict in advance all records that will be needed at the beginning of a transaction. Deadlock resolution requires D BMS mechanisms that detect and break deadlocks. A matrix of a resource usage is maintained that enables deadlock detection.

3-

Whitlock Department Stores scenario: a. Because the merchandise return credit of $50 processed last, the actual balance after the last transaction was $200. b. Payment of $250 reduces the balance to $0. A purchase on credit increases the balance to $100.

A merchandise return reduces the balance to $50.

3-

Five areas where threats to data security may occur.

Possible areas within which threats to data security may occur include the following: o Human users, who may breach security either intentionally or—increasingly often—unintentionally (such as through phishing) o Communication links between various system components, particularly if they include unsecured external links (such as open wireless networks) o Various system software components, such as operating systems and D BM S

297

Chapter 4

o Physical infrastructure, including servers, data centers, network equipment, and client devices o Application software 3-

Security considerations for environments described in Figures 7-5a and 7-5b.

The environment described in 7-5b includes a significantly more complex set of technical vulnerabilities, including network connections between the web server and the application server and the application server and the database server, potentially exposing the database server to risks from the external environment.

The connections between the servers need to be carefully designed from the security perspective and the software (middleware and drivers) that is used to enable these connections has to be kept up to date. The only user authorized to access the application server should be the web server software (and internal support staff).

The environment in 7-5a is very simple and clearly includes a boundary between the internal environment and the externally facing web server. The question, of course, remains about the usefulness of this model: how is the data provided from the web server kept up to date?

Suggestions for Field Exercises

3Students may be helped when structuring their approach to any of these questions by being encouraged to ask questions that briefly describe the historical trends. This gives the interviewee an idea of the student‘s level of knowledge, and it provides a starting point to discuss the university‘s, department‘s, or organization‘s situation. Those that already own some legacy systems tend to further utilize them because development and implementation costs have been paid. Students may find that each retains its mainframes but moves strategically important applications to front-end distributed systems. Common problems in this process include poor integration of products from multiple vendors, inadequate performance, lack of support for security and database integrity, flawed communications programs, and lack of networkmanagement facilities.

3See 7-25 above.

3Examples of such sites may be those that allow visitors or customers to browse inventory records and place orders. There are questions we could ask in order to evaluate the overall functionality of the site. Some examples of such questions could be: Is the Web site content organized to emphasize specific areas? If so, is there easy access to those areas? How many clicks are necessary to locate the needed information? A

Chapter 4

298

good approach to working on this problem could be to find out which of the answers were highly influenced by the database connectivity level. Also, the site‘s developer may be asked for the results of the site testing. Tests are usually performed with a specially developed tool like Mercury Interactive‘s LoadRunner, a product that can simulate 50 million hits a day or 3,000 simultaneous users. This question allows the instructor to discuss the concept of usability, if he or she wishes.

3-

This answer will vary depending upon the software chosen and the type of network and Web site chosen.

3-

This is left as a student exercise, based upon the type of data access required. Student answers will vary.

3-

This is left as a student exercise. Student answers will vary.

3-

This is left as a student exercise. Student answers will vary.

Project Questions

3 - Documentation of the functionality to be included in the system Meaningful answers to this question will vary significantly depending on the student‘s technical capabilities with the development environment. Providing most functionality will require application development, which will require capabilities beyond those developed in this course.

3 - Documentation of the set of technologies most suitable for FAME This is also a question that will get a rich variety of different answers depending on the students‘ background in programming and application development. In addition, the answer will depend on the students‘ and the instructor‘s preferences related to a cloud-based environment. We would recommend considering a straightforward multi-tiered architecture implemented in an I a a S or P a a S environment. For example, the capabilities required by FAME could be offered in a traditional L AM P (Linux – Apache – My SQL – PHP/Python) architecture offered by one of the cloud infrastructure providers.

3 - Development of the proof of concept The outcomes vary very significantly depending on the students and the course‘s pedagogical objectives.

3 - Testing strategy for the proof of concept The testing strategy itself depends heavily on the choices made in earlier questions. As to the stakeholders who should be involved in this phase, a broad-based approach makes sense even when the focus is on infrastructure options and thus, at least the following groups should be involved: FAME IT management/manager, FAME financial management/project sponsors, user representatives, infrastructure provider representative(s) if appropriate, and developers. FAME‘s IT management should sign off before the process moves onto full-fledged development and deployment.

299

Chapter 4

3 - Deployment / rollout strategy for the system within FAME The deployment/rollout strategy should address at least the following issues: o Whether the deployment should take place gradually or in one transition event (―Big Bang approach‖) o If the deployment is gradual, what is the roadmap for the releases? What is the best sequence for introducing system capabilities? What are the dependencies between capability sets? o What preparation is needed for the deployment? 

Training and other preparation for various FAME user groups



Communication with affected FAME stakeholders (such as artists and event organizers)



Negotiating and signing agreements with various service providers



Final integration testing of system capabilities

o How can the deployment be scheduled so that its negative impact on ongoing operations is minimized? o What support structures and capabilities are needed during ongoing use?

Chapter 8 Physical Database Design and Database Infrastructure Chapter Overview This chapter presents the basic steps that are required to develop an effective physical database design.

Physical database design is very important as it immediately affects factors that are important to the end user and the entire enterprise: data integrity and security, response times, usability and user experience, and so on. First, we present a simple approach to estimating the volume of data in a database, as well as the probable data usage patterns. Next, we discuss issues associated with defining fields, including data type determination, coding and compression techniques, controlling data integrity, and handling missing data. We then discuss designing physical records and include an expanded section on

Chapter 4

300

denormalization. Vertical and horizontal partitioning are covered next. We describe the basic file organizations and the trade-offs that are typically involved in selecting a file organization. We examine the use and types of indexes. File access performance is discussed, including a discussion of query optimization. Overall, the chapter emphasizes the physical design process and the goals of that process.

In this 13th edition, this chapter has been expanded significantly to cover a number of essential issues related to database infrastructure, including data dictionaries and repositories, features of database software used to protect data security, and database backup and recovery. In addition, this chapter includes a new review of cloud-based approaches to database infrastructure.

Chapter Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Present physical database design as a critical element for achieving overall database objectives, rather than as an afterthought.

2. Ensure that students understand the factors that must be considered in distributing data effectively and how a simple model can be used to obtain at least a first-cut distribution.

3. Provide students with a sound understanding of the use of indexes and the trade-offs that must be considered in their use.

4. Ensure students understand that denormalization must be used with great care and for specific reasons.

5. Provide students with a solid overview of key database infrastructure issues, particularly those related to data security and operational continuity.

6. Help students understand the implications of offering database capabilities as cloud-based services.

Key Terms Aborted transaction

Encryption

Platform-as-a-Service

After image

Extent

Pointer

301

Chapter 4

Aborted transaction

Encryption

Platform-as-a-Service

Authorization rule

Field

Recovery manager

Backup facility

File organization

Restore/rerun

Backward recovery

Forward recovery

Secondary key

(rollback)

(rollforward)

Before image

Hash index table

Sequential file organization

Checkpoint facility

Hashed file organization

Smart card

Cloud computing

Hashing algorithm

Software-as-a-Service (SaaS)

Data type

Horizontal partitioning

System catalog

Database-as-a-Service

Index

Tablespace

Database change log

Indexed file organization

Transaction

Database destruction

Information repository

Transaction log

Data dictionary

Infrastructure-as-a-Service

Vertical partitioning

(DBaaS)

(IaaS) Database recovery

Journalizing facility

Denormalization

Physical file

User-defined procedure BLANK

Classroom Ideas 1. Point out to your students that physical database design is the last step in the database design process. Suggest to your students that this step is where the ―rubber meets the road,‖ since regardless of how well previous steps may have been completed, users will not be happy with a sloppy physical design.

2. Discuss data volume and usage analysis, using Figure 8-1.

3. Use an in-class exercise to help students understand the key issues related to data type selection using a specific database management system environment. Table 8-1 includes the most commonly used Oracle 12c data types.

4. Using examples of each type of constraint can bring the importance of data integrity home. For instance, you can encourage the students to think through, on their own or in small groups, situations

Chapter 4

302

where default values will improve data integrity, and situations where using them may decrease data integrity. Range controls, null value controls, and referential integrity can also be addressed this way.

5. Discuss denormalization and the conditions under which this approach may be considered, referring to the discussion in the text and figures 8-3 to 8-5. Be sure to describe the trade-offs in denormalization.

6. Start a discussion of indexes by having the students give common examples (index at the end of their database text, Yellow Pages, card catalog, etc.). Then describe and illustrate the use of each type of index using Figure 8-7.

7. Review the basic types of file organizations. Ask your students to give examples other than those described in the text for each organization.

8. Query optimization is a fascinating subject that is only touched on lightly in the book. Further examples, perhaps taken from the work of Joe Celko (Joe Celko‘s SQL Puzzles and Answers, and so forth), will be interesting to the students if time permits.

9. Referring back to the threat identification in Chapter 7, discuss the key features of database management system software intended to enhance data security (see pp. 361-366 and Figures 8-9 to 8-12).

10. Make sure that students understand the critical importance of database backup and recovery processes from the perspective of business continuity.

11. Review the key types of cloud-based approaches to providing data management services, focusing on the differences between the different types (IaaS, PaaS and SaaS). Discuss the advantages and disadvantages of moving data management software services to the cloud.

Review Questions 3-

Define each of the following terms: a. File organization. A technique for physically arranging the records of a file on secondary storage devices b. Sequential file organization. Records in the file are stored in sequence according to a primary key

303

Chapter 4

value c. Indexed file organization. Records are either stored sequentially or non-sequentially, and an index is created that allows software to locate individual records d. Hashed file organization. The address for each record is determined using a hashing algorithm e. Denormalization. The process of transforming normalized relations into unnormalized physical record specifications f. Composite key. A key made up of more than one column g. Secondary key. One or a combination of fields for which more than one record may have the same combination of values h. Data type. Each unit of a detailed coding scheme recognized by system software, such as a D BM S, for representing organizational data i. Data dictionary. A repository of information about a database, including documentation of data elements of a database j. Transaction log. A record of essential data for each transaction that is processed against the database k. Encryption. Transforming data into a humanly unreadable format 3-

Match the following terms to the appropriate definitions: e

extent

h

hashing algorithm

j

rollback

b

index

f

checkpoint facility

e

physical record

g

pointer

Chapter 4

3-

a

data type

d

physical file

c

database recovery

304

Contrast the following terms: a. Horizontal partitioning; vertical partitioning. Horizontal partitioning separates rows of a logical relation into separate tables. Horizontal partitioning is very similar to creating a supertype/subtype relationship because different types of the entity (where the subtype discriminator is the field used for segregating rows) are involved in different relationships, hence different processing. Vertical partitioning separates the columns of a logical relation into separate tables. Neither horizontal nor vertical partitioning prohibits the ability to treat the original relation as a whole. b. Repository; data dictionary. While data dictionaries are simple data-element documentation tools, information repositories are used by data administrators and other information specialists to manage the total information-processing environment. c. Physical file; tablespace. A physical file is a named portion of secondary memory (magnetic tape, hard disk) allocated for the purpose of storing records. A tablespace is a named set of disk storage elements in which physical files for database tables may be stored. d. Before image; after image. A before-image is simply a copy of a record before it has been modified, and an after-image is a copy of the same record after it has been modified. e. Normalization; denormalization. Normalization is the process of breaking up larger relations with structural problems (i.e., anomalies) into smaller, well-structured relations. Denormalization is the opposite process of normalization, as it takes smaller relations and combines them into bigger relations to produce relations that are processed with less management overhead for queries, reporting, and sometimes data maintenance purposes. f. Range control; Null control. Range controls are upper and lower bound limits on the values that a database field can take. Null control refers to whether or not a database field can have a null (empty) value; another way of saying whether or not the field is required (or not) for entry when an instance is created in the database.

305

Chapter 4

g. Transaction log; database change log. A transaction log captures the key characteristics of the transactions (such as date/time, type of transaction, input parameters, tables and rows accessed, user identification, etc.), whereas the database change log includes before and after images of the database in relation to a specific transaction. h. Secondary key; primary key. A secondary key is one field or a combination of fields for which more than one record may have the same combination of values; the primary key is one or a combination of fields for which every record has a unique value. Hence, the primary key is a unique identifier for a row. i. Rollback; rollforward. In rollback, the DBMS cancels (backs out of) unwanted changes to the database and thus, the database is returned to an earlier state. In rollforward, the D BMS starts with an earlier copy of the database and applies after images to re-implement the changes to the database required by the transactions that had taken place by the rollforward process starting point and the current time.

3-

Three major inputs to physical design: a. Logical database structures developed during logical design b. User processing requirements identified during requirements definition c. Characteristics for the DBMS and other components of the computing technology environment

3-

Key decisions in physical database design: a. Choosing the storage format (called data type) for each attribute from the logical data model: the format is chosen to minimize storage space and to maximize data integrity. b. Grouping attributes from the logical data model into physical records: you will discover that although the columns of a relational table are a natural definition for the contents of a physical record, this is not always the most desirable grouping of attributes. c. Arranging similarly structured records in secondary memory (primarily hard disks) so that individual and groups of records can be stored, retrieved, and updated rapidly (called file organizations); consideration must also be given to protecting data and recovering data after errors are found.

Chapter 4

306

d. Selecting structures for storing and connecting files to make retrieving related data more efficient (called indexes and database architectures). e. Preparing strategies for handling queries against the database that will optimize performance and take advantage of the file organizations and indexes that you have specified: efficient database structures will be of benefit only if queries and the database management systems that handle those queries are tuned to intelligently use those structures.

3-

Developing field specifications: a. Define the data type used to represent values of the field. b. Establish data integrity controls for the field, including default values, ranges, null value controls, and referential integrity. c. Determine how missing values for the field will be handled. d. Other field specifications, such as display format, must be made as part of the total specification of the information system. These specifications are typically handled by applications rather than by the DBMS.

3-

Physical database design and regulatory compliance: More recent international and national regulations (such as S O X and Basel II ) have been enacted to curb instances of fraud and deception in financial reporting of companies. Most companies‘ financial reporting rests on the quality of the data stored in the information systems of the companies. One of the best ways to ensure data quality and integrity of an organization‘s data is to build the basic data integrity controls into the field level specifications of a database, a key step in physical database design. By ensuring field level data integrity controls are present and enforced by the organization‘s database management system (D B M S), a company can show its ready compliance with regulations, guidelines, and rules mandated by society and governments. Additionally, advanced D B M S feature use of triggers, stored procedures, audit trails and activity logs, which can also contribute to a company‘s controls over the data values that are stored in a company‘s database.

3-

These four objectives of selecting a data type for a field/column will have varying relative importance for different applications: a. Improve data integrity b. Represent all possible values c. Support all data manipulations

307

Chapter 4

d. Minimize storage space 3-

More space for a numeric field: More space may need to be allocated for a numeric field if the D B M S uses the field‘s data type specification for the results of any calculations on that field. The chapter example cites the use of a QuantitySold field of two bytes. That is sufficient for the storage of a specific instance, but is insufficient in size for the result of a summing calculation of that field.

3-

Coding or compressing field values: Where attributes have a sparse set of values or a volume so large that considerable storage space will be consumed, possibilities for coding or compressing field values should be considered. Large data fields mean that data are further apart, which yields slower data processing. Where the set of valid values is small, translation into a code that requires less space is a possibility. Data compression techniques also use coding to reduce the storage space required for commonly recurring patterns of data.

3-

Controlling field integrity: a. Specify default values. b. Specify a range or list of permissible values. c. Set null value permissions. d. Establish referential integrity.

3-

Three ways to handle missing field values: a. Substitute an estimate of the missing value: for example, for a missing sales value when computing monthly product sales, use a formula involving the mean of the existing monthly sales values for that product indexed by total sales for that month across all products. Such estimates must be marked so users know that these are not actual values. b. Track missing data so that special reports and other system elements cause people to quickly resolve unknown values. Setting up a trigger in the database can accomplish this. A trigger is a routine that will automatically execute when some event occurs or time period passes. One trigger could log the missing entry to a file when a null or other missing value is stored, and another trigger could run periodically to create a report of the contents of this log file. c. Perform sensitivity testing so that missing data are ignored unless knowing a value might significantly change results. For example, if total monthly sales for a particular salesperson were

Chapter 4

308

almost over a threshold that would make a difference in that person‘s compensation, then attention would be drawn to the missing value. Otherwise, it would be ignored. This is the most complex of the methods mentioned; it requires the most sophisticated processing logic, which is often implemented in application programs.

3-

Effect of normalizing relations on physical record storage: One goal of physical record design is efficient use of storage space. In most cases, the second goal of physical record design—efficient data processing—dominates the design process. Efficient processing of data, just like efficient accessing of books in a library, depends on how close together related data (or books) are. Often, all the attributes that appear within a relation are not used together, and data from different relations are needed together to answer a query or produce a report. Thus, although normalized relations solve structural anomalies, normalized relations, if implemented one for one as physical records, may not yield efficient data processing.

3-

Why does it make sense to first go through normalization and then denormalize?

The process of normalization is a well-known and widely accepted mechanism for creating a sound structural foundation for a relational database. Even if the database is later denormalized for performance reasons, it is very useful to first create a strong basis, which can then later be modified as needed. Knowing that the starting point is solid will create a much better foundation for the changes compared to a random or unknown structure.

3-

Situations that suggest the possibility of denormalization: a. Two entities with a one-to-one relationship: Even if one of the entities is an optional participant, if the matching entity exists most of the time, then it may be wise to combine these two relations into one record definition (especially if the access frequency between these two entity types is high). Figure 8-3 shows student data with optional data from a standard scholarship application a student may complete. In this case, one record could be formed with four fields from the STUDENT and SCHOLARSHIP APPLICATION normalized relations. (Note: In this case, fields from the optional entity must have null values allowed.) b. A many-to-many relationship (associative entity) with nonkey attributes: Rather than joining three files to extract data from the two basic entities in the relationship, it may be advisable to combine attributes from one of the entities into the record representing the many-to-many relationship, thus avoiding one join in many data access modules. Again, this would be most advantageous if this joining occurs frequently. Figure 8-4 shows price quotes for different items from different vendors.

In this case, fields from ITEM and PRICE QUOTE relations might be combined into one record to avoid having to join all three files together. (Note: This may create considerable duplication of

309

Chapter 4

data—in the example, the ITEM fields, such as Description, would repeat for each price quote— and excessive updating if duplicated data changes.) c. Reference data: Reference data exists in an entity on the one-side of a one-to-many relationship, and this entity participates in no other database relationships. You should seriously consider merging the two entities in this situation into one record definition when there are few instances of the entity on the many-side for each entity instance on the one-side. See Figure 8-5 in which several ITEMs have the same STORAGE INSTRUCTIONs, and STORAGE INSTRUCTIONs only relate to ITEMs. In this case, the storage instruction data could be stored in the ITEM record, creating, of course, redundancy and potential for extra data maintenance.

3-

The major reasons critics caution the use of denormalization include: a. It can increase the chance of errors and inconsistencies being introduced into the database by reintroducing anomalies, for example, the unsynchronized updating of data. b. It can cause increased costs for maintenance of systems if business rules change c. It optimizes certain data processing (e.g., data retrieval) at the expense of others (e.g., accurate updating of data), so if the frequency of data retrieval reduces, the benefits of denormalization may disappear. d. It almost always leads to the use of more storage space for raw data, and possibly more space for database overhead (e.g., indexes). e. Some critics contend that the joining of many tables in database processing may not actually slow database processing, thus the argument to denormalize for performance efficiencies may be unfounded. These critics suggest that advanced DBMS features (such as file organizations, clustering, query design, and query optimization) permit other ways to optimize performance rather than using denormalization to create fewer tables for joining purposes.

3-

Partitioning advantages and disadvantages: Advantages of partitioning: a. Efficiency: Data used together are stored close to one another and separate from data not used together.

Chapter 4

310

b. Local optimization: Each partition of data can be stored to optimize performance for its own use. c. Security: Data not relevant to one group of users can be segregated from data they are allowed to use. d. Recovery and uptime: Smaller files will take time to recover, and other files are still accessible if one file is damaged, so the effects of damage are isolated. e. Load balancing: Files can be allocated to different storage areas (disks or other media), which minimize contention for access to the same storage area or even allows for parallel access to the different areas.

Disadvantages of partitioning: a. Inconsistent access speed: Different partitions may yield different access speeds, thus confusing users. Also, when data must be combined across partitions, users may have to deal with significantly slower response times. b. Complexity: Partitioning is usually not transparent to programmers, who will have to write more complex programs due to violations of third normal form. c. Anomalies: Insertion, deletion, and update anomalies are possible, and special programming is required to avoid these problems. d. Extra space and update time: Data may be duplicated across the partitions, taking extra storage space, compared to storing all the data in normalized files. Updates, which affect data in multiple partitions, can take more time than if one file were used.

3-

Seven criteria for selecting a file organization: a. Data retrieval speed b. Data input and maintenance transaction processing throughput rate c. Storage efficiency d. Failure or data loss protection level e. Frequency of data reorganization required

311

Chapter 4

f. Ability to accommodate growth g. Security protection provided 3-

The benefits of a hash index table: Using a hashing algorithm allows for rows stored independently of the address, so that whatever file organization makes sense can be used for storage. Also, because index tables are much smaller than a data table, the index can be more easily designed to reduce the likelihood of key collisions or overflows.

3-

The purpose of clustering data in a file: Some database systems allow physical files to contain records with different structures, e.g., rows from different tables may be stored in the same disk area. This clustering reduces the time to access related records compared to the normal allocation of different files to different areas of a disk. Time is reduced since related records will be closer to each other than if the records are stored in separate files in separate areas of the disk.

3-

The most important physical design mechanism that can be used to impact database performance: In practice, indexing is the most important mechanism in physical database design that the designer can use to make a very significant difference in database performance. Carefully designed and well-tested indexes will contribute positively to database performance whereas poorly designed or missing indexes can have a significant negative impact.

3-

Ten rules of thumb for choosing indexes for relational databases. a. Indexes are more useful on larger tables. b. Specify a unique index for the primary key of each table. c. Indexes are more useful for columns that frequently appear in WHERE clauses of S QL commands, either to qualify the rows to select (e.g., WHERE ProductFinish = ‗Oak‘, for which an index on ProductFinish would speed retrieval) or for linking (joining) tables (e.g., WHERE Product_T.ProductID = OrderLine_T.ProductID, for which a secondary key index on ProductID in the OrderLine_T table and a primary key index on ProductID in the Product_T table would improve retrieval performance). In this second case, the index is on a foreign key in the OrderLine_T table that is used in joining tables. d. Use an index for attributes referenced in ORDER BY (sorting) and GROUP BY (categorizing) clauses. You do have to be careful, though, about these clauses. Be sure that the D BMS will, in fact, use indexes on attributes listed in these clauses (e.g., Oracle uses indexes on attributes in ORDER BY clauses but not GROUP BY clauses).

Chapter 4

312

e. Use an index when there is significant variety in the values of an attribute. Oracle suggests that an index is not useful when there are fewer than 30 different values for an attribute, and an index is clearly useful when there are 100 or more different values for an attribute (leaving a gray area between 30 and 100 different values). Similarly, an index will be helpful only if the results of a query that uses that index do not exceed roughly 20 percent of the total number of records in the file (Schumacher, 1997; see textbook references). f. Before creating an index on a field with long values, consider first creating a compressed version of the values (coding the field with a surrogate key) and then indexing on the coded version (Catterall, 2005; see textbook references). Large indexes, created from long index fields, can be slower to process than small indexes are. g. If the key for the index is going to be used for determining the location where the record will be stored, then the key for this index should be a surrogate key so that the values cause records to be evenly spread across the storage space (Catterall, 2005; see textbook references). Many DBMS create a sequence number so that each new row added to a table is assigned the next number in sequence; this is usually sufficient for creating a surrogate key. h. Check your DBMS for the limit, if any, on the number of indexes allowable per table. Some systems permit no more than 16 indexes and may limit the size of an index key value (e.g., no more than 2000 bytes for each composite value). So, you may have to choose those secondary keys that will most likely lead to improved performance. i. Be careful about indexing attributes that have null values. For many D BMS, rows with a null value will not be referenced in the index (so they cannot be found from an index search of ATTRIBUTE = NULL). Such a search will have to be done by scanning the file.

3-

Why unique indexes for primary key?

A primary key must be a unique identifier of the data instance in the database. By specifying a unique index for each primary key in the database, the designer is ensuring that the D B M S will reject any insertion or updates of data in the database table that would violate the uniqueness constraint. Additionally, a unique index for each primary key in a database would speed retrieval of data instances and subsequent processing of the data.

313

3-

Chapter 4

Why is an index useful only with data value variety?

An index saves processing time by finding data that meet a pre-specified qualification at the expense of the extra storage space and maintenance of the index. An index over an attribute with a variety of values will allow for quicker retrieval of data compared to search and retrieval of the actual variety of values. Hence, the overhead of creating an index is traded-off for the benefit of faster retrieval when there is variety in the actual data values of the attribute in the database. This retrieval benefit is especially apparent in very large databases. A lack of variety in attribute values would result in a small index but would retrieve large chunks of data instances when used, and would not noticeably save time in processing of data retrieval when compared to using actual values in the database.

3-

Why not index every column of every table?

Although indexing can be beneficial, its use is not without its costs. There is a trade-off between improved performance for retrieval operations by using indexes, and degraded performance (due to overhead associated with index maintenance) for inserting, updating, and deleting indexed records in a file. So, if you choose to index every column in a table, you may be creating a very costly database for updating operations. Indexes are best reserved for databases that primarily support data retrieval operations (e.g., decision support and data warehousing), and used with caution for databases that support heavy transaction processing needs.

3-

Role of query optimizer in selecting indexes?

The answer depends on the DBMS used, but with many modern D BMS the query optimizers are able to make specific recommendations regarding the columns that are required for the recommended indices. You are not, of course, forced to use this information but it is worth considering seriously.

3-

Parallel processing and query performance?

Parallel processing can improve query performance by utilizing the advanced features of a particular D B M S that take advantage of symmetric multiprocessor (S M P) technology in database servers. More sophisticated D B M S may achieve better query performance through three possible ways: (1) changing how tables and/or indexes are scanned by the query processor (e.g., changing the physical design to horizontally partition the data); (2) changing how query elements are processed (e.g., how joins of related tables are completed, grouping query results into categories, combining several parts of a query result together, sorting rows, and computing aggregate values); and (3) the query optimizer‘s use of physical database design specifications and characteristics of the data (e.g., a count of the number of different values for a qualified attribute) to determine whether to take advantage of parallel processing capabilities.

3-

Role of data dictionary in management and maintenance of a database: The data dictionary is an invaluable tool for database management and maintenance, because if provides an up-to-date view of the current state of the database. Thus, the data dictionary should be consulted always when changes to the database structure are considered so that the impact of the planned changes can be understood at the level of the database as a whole. The data dictionary can also be a highly valuable tool in

Chapter 4

314

troubleshooting the database.

3-

Uses of a data dictionary and a repository contrasted: Data dictionaries are relatively simple data-element level documentation tools, while information repositories are used by data administrators and other information specialists to manage the total information-processing environment. A repository can include data models at various levels, design solutions for a higher level of abstraction than a data dictionary, justifications for various modeling and design decisions, etc. A typical repository also includes tools for version and configuration management.

Overall, the scope of a repository is much broader than that of a data dictionary.

3-

Five areas where threats to data security may occur: a. Accidental losses, including human error, software, and hardware-caused breaches. Establishing operating procedures – such as user authorization, uniform software installation procedures, and hardware maintenance schedules – may help address threats from accidental losses. As in any effort that involves human beings, some losses are inevitable, but well thought-out policies and procedures should reduce the amount and severity of losses. b. Theft and fraud. These activities are going to be perpetrated by people, quite possibly through electronic means, and may or may not alter data. Attention here should focus on each possible location shown in Figure 12-3. For example, control of physical security, so that unauthorized personnel are not able to gain access to the machine room, should be established. Data access policies that restrict altering data immediately prior to a payroll run will help to secure the data.

Establishment of a firewall to protect against unauthorized access to inappropriate parts of the database through outside communication links is another example of a security procedure that will hamper people who are intent on theft or fraud. c. Loss of privacy or confidentiality. Loss of privacy is usually taken to mean loss of protection of data about individuals, while loss of confidentiality is usually taken to mean loss of protection of critical organizational data that may have strategic value to the organization. Failure to control privacy of information may lead to blackmail, bribery, public embarrassment, or use of user passwords. Failure to control confidentiality may lead to loss of competitiveness. d. Loss of data integrity. When data integrity is compromised, data will be invalid or corrupted.

Unless data integrity can be restored through established backup and recovery procedures, an organization may suffer serious losses or make incorrect and expensive decisions based on the invalid data.

315

Chapter 4

e. Loss of availability. Sabotage of hardware, networks, or applications may cause the data to become unavailable to users, which again may lead to severe operational difficulties.

3-

How creating a view may increase data security, and why not to rely completely on using views to enforce data security: The advantage of a view is that it can be built to present only the data to which the user requires access, thus effectively preventing the user from viewing other data (not produced by the S QL for the view) that may be private or confidential. The user may be granted the right to access the view, but not to access the base tables upon which the view is based. For most views, data may not be updated, thus eliminating the possibility of unauthorized changes to the base data. However, views are not adequate security measures because unauthorized persons may gain knowledge of or access to a particular view. In addition, with highlevel query languages, an unauthorized person may gain access to data through simple experimentation.

Views also do not protect data from access outside the DBMS by hackers. Thus, views provide more convenience than security. See also the answer to Review Question 8-40.

3-

Integrity controls in database security: Integrity controls protect data from unauthorized use and update. Integrity controls limit the values a field may hold, limit the actions that can be performed, or trigger the execution of some procedure (such as placing an entry into a log to record which users have performed which actions on which data). A domain is an example of an integrity constraint that can be used to define a user-defined data type. If this type ever needs to be changed, it can be changed in only one place, and all fields using this domain will be updated automatically. Assertion constraints enforce desirable database conditions and check automatically whenever transactions are run. Triggers can be used for events or conditions, and actions needed to be tracked against a database. Triggers cannot be circumvented.

3-

The difference between an authentication scheme and an authorization scheme: Authorization rules are primarily concerned with protection of the data themselves. They are controls incorporated in the data management system that restrict access to data and also restrict the actions that people may take when they access data. For example, a person who can supply a particular password may be authorized to read any record in a database but cannot necessarily modify any of those records.

Authentication schemes establish operating procedures that positively identify a person attempting to gain access to a computer or its resources. Hence their primary concentration is the user‘s identification. A user may gain access to the database through an authentication procedure, but the actions he or she may undertake later will depend further on the authorization rules.

Chapter 4

3-

316

The key areas of IT covered in a Sarbanes-Oxley audit: a. IT change management b. Logical access to data c. IT operations

3-

Two key types of security policies and procedures: a. Personnel controls: security authorization and authentication procedures for operations systems and databases, selective hiring processes, adequate monitoring of personnel practices and actions, separation of duties, and procedures for employees who leave employment. b. Physical access controls: access to specific parts of the building and sensitive equipment is controlled by management processes and procedures.

3-

Four DBMS facilities that are required for database backup and recovery: a. Backup facilities provide periodic backup copies of the entire database. b. Journalizing facilities maintain an audit trail of transactions and database changes. c. Checkpoint facility allows periodic suspension of all processing and synchronization of a database‘s files and journals. d. Recovery manager allows the DBMS to restore the database to a correct condition and restart processing transactions.

3-

Four common types of database failure: a. Aborted transaction. Aborting a transaction in progress due to some abnormal condition, such as the loss of transmission in a communication link while a transaction is in progress. b. Incorrect data. The database is updated with incorrect, but valid data: for example, an incorrect grade recorded for a student. c. System failure. Some component of the system fails, but the database is not damaged. Causes include power loss, operator failure, loss of communications transmission, or system software failure.

317

Chapter 4

d. Database loss or destruction. The database itself is lost or destroyed or cannot be read.

3-

Two common forms of encryption: a. One key or data encryption standard (D ES). Both the sender and the receiver know the key that is used to scramble the message being transmitted. b. Two key or dual key, public key, or asymmetric encryption. This uses both a private key and a public key. All users will know each other‘s public keys, but only each individual knows their private key.

3-

Four components of a disaster recovery plan: a. Develop a detailed disaster recovery plan. b. Choose and train a multidisciplinary team to carry out the plan. c. Establish a backup data center at an off-site location. d. Send backup copies of the databases to the backup data center on a scheduled basis.

3-

Views for data security?

A view is a dynamic result table that is created at run time from a query run over base tables in the database. A view can be constructed to present only the data a particular user needs to access (e.g., certain rows and/or columns) and the user can be granted access only to that view, rather than the base tables that feed the view. A view can be used as part of a data security approach in an organization, but will not be sufficient to control all access to the data stored in databases. Often, views are shared among persons in the organization, but people may have different levels of authorization over this same view—a few may be able to update the data while others are restricted to read-only access. It may be easy for unauthorized users to gain knowledge of, or access to, a particular view or person who has greater access authority than the unauthorized person. Generally speaking, additional data security measures must be used along with views to provide an appropriate level of protection over organizational data. See also the answer to Review Question 8-31.

3-

Differences between the IaaS, PaaS, and SaaS models of cloud-based database management solutions: In the IaaS model, you are essentially renting database server capacity running on the cloud service provider‘s network (including hardware, operating system, and the DBMS). The service does not provide

Chapter 4

318

services for, for example, backup and recovery, capacity planning, and security. PaaS raises the level of abstraction so that the service provider offers a data management service that hides much of the underlying complexity still involved in the IaaS model (including security and backup/recovery). The database service is typically branded by the cloud service provider, such as Microsoft‘s S QL Database and Amazon‘s Relational Database Service. SaaS goes further than PaaS and integrates data management with other capabilities that the organization needs to satisfy its transactional or informational needs.

3-

Differences between an internal and an external cloud-based database management solution: Typically, when cloud-based services are discussed, we refer to eternal services provided by a third party vendor (such as Amazon, Google, Microsoft, or one of the many more providers). In these cases, the vendor owns the resources needed to provide the cloud-based services and charges a fee for those services. In some cases, a large organization may analyze the situation and come to the conclusion that it makes sense for it to offer cloud-based solutions itself, using its own data centers, networks, and software solutions instead of relying on a third party. This decision might, for example, be based on cost or an organization‘s need for a very high security.

Answers to Problems and Exercises 3-

Millennium College situation questions: a.

StudentID in STUDENT because it is a primary key and the index would enforce uniqueness of the key; also, StudentID in STUDENT and in REGISTRATION is used in a WHERE clause for joining the STUDENT and REGISTRATION tables, so it likely makes sense to create an index on StudentID in REGISTRATION as well.

GPA in STUDENT because it is a nonkey cluster attribute used to qualify record retrieval StudentName in STUDENT because it is a nonkey attribute used to sort records StudentID, CourseID in REGISTRATION because it is a concatenated primary key and the index would enforce uniqueness of the key b.

CREATE UNIQUE INDEX STUPKINDX ON STUDENT (StudentID); CREATE INDEX STUDREGINDX ON REGISTRATION (StudentID); CREATE INDEX CLUST_INDX ON STUDENT (GPA) CLUSTER; CREATE INDEX NAMEINDX ON STUDENT (StudentName); CREATE UNIQUE INDEX REGSPKINDX

319

Chapter 4

ON REGISTRATION (StudentID, CourseID); 3-

Suggested Oracle data types for Figure 8-4b:

3-

VendorID

NUMBER(15,0)

Address

VARCHAR2(40)

ContactName

VARCHAR2(25)

ItemID

NUMBER(15,0)

Description

VARCHAR2(35)

Price

NUMBER(5,2)

Suggested Oracle data types for P&E 4-47 in Chapter 4: Relation

Attribute

Oracle data type

REGION

RegionID

Integer

Blank

RegionName

VARCHAR2(50)

Comments/Notes

Check with client as to maximum Region Names

COUNTRY

CountryID

Integer

CountryName

VARCHAR2(50)

Blank

Check with client as to maximum Country Names

Blank

RegionID

Integer

Must match attribute in Region relation (FK)

EMPLOYEE

EmpID

Integer

EmpName

VARCHAR2(50)

Blank

Ask client if they need this broken into Last, First, MI

Blank

CountryMgr?

VARCHAR2(1)

Y or N

DevelopMgr?

VARCHAR2(1)

Y or N

Developer?

VARCHAR2(1)

Y or N

CMID

Integer

Must match EmpID (FK)

CountryID

Integer

Must match CountryID

Blank

Blank

COUNTRY MGR Blank

Chapter 4

Relation

Attribute

Oracle data type

320

Comments/Notes (FK)

DEVELOP

DMID

Integer

Must match EmpID (FK)

CMID

Integer

Must match CMID (F K)

DevID

Integer

Must match EmpID (FK)

DMID

Integer

Must match DMID (FK)

DeveloperType

VARCHAR2(1)

S, W, or J

SrDev

SrDevID

Integer

Must match DevID (FK)

WizDev

WizID

Integer

Must match DevID (FK)

JrDev

JrDevID

Integer

Must match DevID (FK)

SrDevID

Integer

Must match SrDevID (F

MGR

DEVELOPER Blank

Blank

Blank

K) ASSIGNMENT

PROJECT

AssignID

Integer

Score

Integer

Hours

Integer

Rate

NUMBER(5,2)

DevID

Integer

Must match DevID (F K)

ProjID

Integer

Must match ProjID (F K)

ProjID

Integer

ProjStartDate

DATE

ProjEndDate

DATE

TeamID

Integer

Must match TeamID (F K)

TEAM

TeamID

Integer

TeamName

VARCHAR2(20)

TeamStartDate

DATE

TeamEndDate

DATE

SrDevLead

Integer

Must match SrDevID (F K)

SrDevDeputy

Integer

Must match SrDevID (F

321

Chapter 4

Relation

Attribute

Oracle data type

Comments/Notes K)

MEMBERSHIP MbrshipID

Integer

Joined

DATE

Left

DATE

DevID

Integer

Must match DevID (FK)

TeamID

Integer

Must match TeamID (F K)

3-

What do precision (p) and scale (s) parameters for Oracle NUMBER data type mean?

Precision refers to the length of the number in digits. For example, NUMBER(5) refers to a 5-digit numbers such as 99999. Scale refers to the number of places after the decimal point; a negative value for a scale parameter refers to the number of significant places before the decimal point. For example, NUMBER(5,2) refers to a 5-digit number, with two decimal places, such as 345.50.

3-

How will numeric value 3,456,349.2334 be stored assuming various Oracle data types?

Blank

Oracle data type

Stored Value

a.

NUMBER(11)

3456349

b.

NUMBER(11,1)

3456349.2

c.

NUMBER(11,-2)

3456300

d.

NUMBER(11,6)

Not accepted, too few digits available for the integer part; the INSERT statement will fail

e.

NUMBER(6)

Not accepted, exceeds precision; the INSERT statement will fail

f.

NUMBER

3456349.2334

Chapter 4

322

3 - Default value for age?

The answer to this question will vary for different universities, but common situations are used here. Since the majority of students are accepted in the first year after high school graduation and university attendance is increasing, the average age of students in the first year of college would be a good choice for a default value. Often students are accepted to different schools within the university after the second year.

Therefore, we need to add two years to the first answer if we design the system for a business school, for example. Degree seeking students are generally younger than non-degree seeking students, and the default value for this field might be a higher number for non-degree seeking students. Graduate students have already completed a degree, which usually takes at least four years, so a graduate university would also use a higher default value. The fundamental problem with this field as a regular field is that it would need constant recalculation; it should be specified as a derived field that the system calculates based on the current system date and a date of birth.

3 - Null value for University major?

Since every student who hasn‘t explicitly declared a major of his or her choice would be assigned this value, it can be considered a default value. The null value is an empty value, thus assigning a default value of ―Undecided‖ is not the same as setting the value to null.

3 - Recommendations for denormalization, large retail chain: EMPLOYEE SCHEDULE (DepartmentID, EmployeeID, WhereWork, EmployeeName, EmployeeAddress, Date) A many-to-many relationship (associative entity) with nonkey attributes: Rather than joining three files to extract data from the two basic entities in the relationship, it may be advisable to combine attributes from one of the entities into the record representing the relation in the many-to-many relationship, thus avoiding one join in many data access modules. This approach is advantageous as this joining will occur frequently.

323

Chapter 4

DEPARTMENT

(DepartmentID, ManagerID, SalesGoal, StoreID, Region, ManagerID, SquareFeet) This reference data denormalization option wouldn‘t be recommended since the table STORE is further related to a table MANAGER, and there are probably more than just a few departments in each STORE. 3 - Indexing for mobile service provider a. List of users sorted by zip code → Create an indexed file organization for USER by UserZip b. Access to a specific client → Index ADVERTISERCLIENT by ClientContactID; create a hash index including ContactName, ContactEmail, and ContactPhone for CONTACT c. List of users sorted by interest area and intensity of interest → Index INTEREST by InterestLabel and USERINTERSTAREA by UserInterestIntensity d. List of users within an age range sorted by category and zip code → Index USER by UserYearOfBirth and UserZip and CATEGORY by CategoryName e. Access to a specific user based on their e-mail → Create a hash index based on UserEmail for USER 3 - Denormalization for mobile service provider Some possibilities for denormalization: a. Include ContactName, ContactEmail, and ContactPhone in ADVERTISERCLIENT. b. Include InterestLabel in USERINTERESTAREA. c. Include InterestLabel, UserLName, UserFName, and UserYearOfBirth in USER. 3 - Recommendations for denormalization, sports league: One possibility for denormalization would be the inclusion of SpecialtyDescription attribute in the PLAYER relation. It appears that the PlayerSpecialtyCode refers to the SpecialtyCode in the SPECIALTY relation, using SPECIALTY as reference information for Players. To make the right decision, you would need to know more about Player specialties, in terms of occurrence (can they have more than one, in the future?) and the expected size of the SpecialtyDescription attribute. Denormalizing the relations by adding the SpecialtyDescription data to the PLAYER relation might be adding a lot of redundant information that could take up a great deal of storage.

Chapter 4

324

There might be opportunities for further denormalization in these relations, but the following questions need to be asked before proceeding with any further denormalization: o What are the meaning and the contents of the TeamLocation attribute in the TEAM relation? Is this a code used to reference the LocationID in the LOCATION relation? Or is this a character field storing different information about the Team‘s location? Can a TEAM instance have more than one location? o What are the meaning and the contents of the ManagerTeam attribute in the MANAGER relation?

Does this attribute refer to the TeamID attribute in the TEAM relation? Is a Manager instance also a Player instance?

3 - Vertical partitioning issues: Disadvantages of partitioning: a. Inconsistent access speed: Different partitions may yield different access speeds, which may confuse users. b. Complexity: Partitioning is usually not transparent to programmers, who will have to write more complex programs due to the violations of third normal form. c. Anomalies: The violations of third normal form will lead to anomalies. d. Extra space and update time. Duplication of data across the partitions will use more storage space than data stored in normalized files. Updates may well affect data in multiple partitions.

Conditions that influence the use of partitioning: a. Criticalness of fast and consistent record access times to users b. Sophistication of in-house programming talent c. Storage space availability 3 - Sequential file organization & sequential scanning of data: A sequential file organization arranges the records in physical sequence based on one sorting criterion, so scanning the file in that sequence is possible and efficient. For sequential media (e.g., magnetic tape), the only practical scanning sequence is the sequence in which the records are stored. If the sequential file is, however, stored on a random-access device, then although the storage sequence is still the fastest scanning

325

Chapter 4

sequence, other sequential scans are possible by using physical pointers to link the records according to alternative sequences.

3 - Pointer v s sequential file organization questions: ersu

a. Records can be accessed sequentially in two directions: from start to end and vice versa. As a corollary, it is easy to find the next or prior record in sequence if you know the address of a particular record. b. What is described is a simple, bi-directional pointer—which will allow traversal through the records in two directions forward and backward—but does not allow for different sequences.

However, by adding a pair of bi-directional pointers for each sequence, multiple sequences can be maintained without repeating the data.

3 - Use of indexes in University situation: A row selection qualification clause will be used: WHERE (Major = ―M I S― or Major = ―Computer Science―) And Age > 25 And MaritalStatus = ―single―) Or (Major = ―Computer Engineering― And MaritalStatus = ―single― And HomeZipcode = 45462).

Indexes on these fields can be used to considerable advantage in this situation. Assume that each index qualification (e.g., Major = ―M I S―) produces a list of record numbers for the records satisfying that qualification. Lists can be merged to process OR operators, and lists can be intersected to process AND operators. Indexes may be scanned in main memory, and the list operations also done without accessing secondary memory, thus composing the list of qualified records very quickly. Only then does secondary memory need to be accessed for only those records that satisfy the whole query.

3 - Consider changes to P&E 8-53: a. Identify the foreign keys. [Primary Keys, Foreign Keys] TEAM (TeamID, TeamName, TeamLocation, TeamLeague) PLAYER (PlayerID, PlayerFirstName, PlayerLastName, PlayerDateOfBirth, PlayerSpecialtyCode) SPECIALTY (SpecialtyCode, SpecialtyDescription) CONTRACT (TeamID, PlayerID, StartTime, EndTime, Salary) LOCATION (LocationID, CityName, CityState, CityCountry, CityPopulation) MANAGER (ManagerID, ManagerName, ManagerTeam) LEAGUE (LeagueID, LeagueName, LeagueLocation) b. Recommended indices and explanation: I would recommend indexes on all primary keys (TeamID, PlayerID, SpecialtyCode, LocationID, ManagerID, LeagueID), which many D B M S do automatically. I would also suggest creating a surrogate key of ContractID for the CONTRACT relation, and also creating an index on that primary key. These indexes will assist in quick retrieval of data for the first four database operations on the list.

Chapter 4

326

Additionally, I would recommend that indexes are created to assist in the reporting needs, as follows: TeamID + PlayerID, TeamID + PlayerID + SpecialtyCode, Salary + PlayerID, and TeamID + PlayerID + LocationID. 3 - Consider Figure 8-7b.

When one of the leaves is full and a new record needs to be added to that leaf, the leaf node may be turned into an intermediate parent node. This node would then serve as an index to those records, and an additional leaf node (containing the actual records) will be attached to that intermediate node. The parent node will contain pointers to the records in the leaf node.

3 - Figure 4-35 and P&E 4-44 in Chapter 4: All primary keys in each relation should receive an index. In addition, based on the characteristics of the model, the following indices would be useful: o LastName and FirstName in Renter (assumption: frequently used search criterion) o City and State and Zip in Property (assumption: frequently used sorting and search criterion) o PropertyID in RentalAgreement o RenterID in Rental Agreement o BeginDate in RentalAgreement (assumption: frequently used sorting criterion) o MPropertyID in PropertyActivity o ActivityID in PropertyActivity

327

Chapter 4

3 - Figure 4-38 and P&E 4-48 in Chapter 4: All primary keys in each relation should receive an index. In addition, based on the reporting needs, the following indices could be useful: o DevID and ProjID in Assignment relation o DevID and TeamID in Membership relation o CountryID in Country Mgr relation, C M ID in Develop Mgr relation, DM ID in Developer relation, DevID in Assignment relation, ProjID in Assignment relation o ProjEndDate in Project relation CREATE INDEX ASSIGNDEVINDX ON ASSIGNMENT (DevID); CREATE INDEX ASSIGNPROJINDX ON ASSIGNMENT (ProjID); CREATE INDEX PROJCOMPLETE ON PROJECT (ProjEndDate); 3 - File clustering and populated tables: A cluster is defined by the tables and the column or columns by which the tables are usually joined. The column by which they are joined (foreign key) would need to have the same value in the two tables for the adjacent records. If the tables are populated with data before clustering occurs, this is much harder to achieve. Hence, in Oracle, tables are assigned to a cluster at the time of their creation.

3 - Parallel query processing: In general, the answer depends on the number of processors available. For the general structure mentioned in the problem, each set of conditions within parentheses (called a conjunction) could be given to a separate processor, then the results from each processor would be intersected to obtain the final result. If more processors are available, then each condition within a conjunction could be assigned to its own processor.

As an illustration of what might typically happen, consider the qualification clause from Problem and Exercise 5-41: SELECT StudentID, StudentName FROM STUDENT WHERE (Major = ―MIS― or Major = ―Computer Science―) AND Age > 25 AND MaritalStatus = ―single― OR (Major = ―Computer Engineering― AND MaritalStatus = ―single― AND HomeZipcode = 45462); There are two general approaches for parallel processing of a query: a. To ensure that subsequent scans of this table are performed in parallel using at least three processors, you would first alter the structure of the table with the SQL command:

Chapter 4

328

ALTER TABLE STUDENT PARALLEL 3, and then run the query itself. b. The second option would be to give the DBMS a hint within the query. This will force it to process the query in a certain way. In Oracle: SELECT /*+ FULL(STUDENT) PARALLEL(STUDENT,3) */ COUNT(*) FROM STUDENT WHERE (Major = ―MIS― or Major = ―Computer Science―) AND Age > 25 AND MaritalStatus = ―single― OR (Major = ―Computer Engineering― AND MaritalStatus = ―single― AND HomeZipcode = 45462); would enforce a full scan on the table STUDENT, and its processing in parallel, by three CPUs. Note: In Oracle, parallel processing is possible only when a table is scanned, not when it is accessed through an index.

3 - Analysis of Figure 4-33 a. Usage map

329

Chapter 4

b. Normalized relations CUSTOMER(CustomerID, CustName, CustAddress) CARDACCOUNT(AccountID, ExpDate, CardType, CustomerID) CustomerID references CUSTOMER(CustomerID) DEBITCARD(AccountID, BankNo) AccountID references CARDACCOUNT(AccountID) CREDITCARD(AccountID, CurBal) AccountID references CARDACCOUNT(AccountID) MERCHANT(MerchID, MerchAddr) CHARGES(MerchID, AccountID, ChargeDate, ChargeTime, Amount) MerchID references MERCHANT(MerchID) AccountID references CREDITCARD(AccountID) c. Opportunities for denormalization

Chapter 4

330

There are a few that could be applied in a relatively straightforward way: o Include CustName and CustAddress in CARDACCOUNT o Include MerchAddr in CHARGES o Remove CREDITCARD and DEBITCARD. Include both BankNo and CurBal in CARDACCOUNT. 3 - Figure 4-4 Join Index results CustRowID 10001 10002 10003 10004 …

OrderRowID 30004 30002 30003 30001 …

Cust# C2027 C1062 C1062 C3861 …

Blank

Blank

Blank

3 - Revised Composite Usage Map from Figure 8-1 20,000 7,500

SUPPLIER 150

PART 3,000 25%

7,000

80% o 8,000 (60)

16,000 MANUFACTURED PART 750

PURCHASED PART 2,400 4,000

SUPPLIES 9,000

4,000

8,000

3 - Figure 8-15 analysis for composite usage map, denormalization questions: a.

331

Chapter 4

1,500

ORDER

CUSTOMER 60,000 85%

REGULAR CUSTOMER 51,000

2,500,000

15% o

(30) ORDER LINE

NATIONAL CUSTOMER 9,000

PRODUCT

5,000

It might also be useful to ask your students what type of additional usage data might need to be gathered to make a complete analysis. b. Since only employees are using the system, one possibility might be to eliminate the regular customer and national account customer subtypes and only have one customer type. We might also assume that only national account customers would be serviced by employees. Depending on how much National Account Customer data there is, this and the Order Line entities might be merged.

3 - Analysis of Figure 4-5 design and suggested reports: a. An index on the State field of the customer table would help with grouping and sorting. An index on OrderDate in the order table would help with qualifying to the desired period. If rows are sorted by description within state, it would seem that an index on ProductDescription in the product table might be helpful, but such an index would likely not be used by most D BMSs because the number of rows to sort within each category is so few. b. An index on ProductFinish in the Product table would help to compute the totals by product finish. c. An index on OrderDate would help to quickly find the desired orders, and an index on OrderID in the order line table would speed joining. d. An index on ProductLineID in product would speed grouping, and an index on ProductID in the order line table would speed joining.

Chapter 4

332

3 - PVFC authorization tables Blan k

Read Insert Modify Delete

Inventory

Receivables

Payroll

Customer

Records Y N Y Y

Records N N N N

Records N N N N

Records Y N N N

Authorizations for Inventory Clerks Blan k

Salespersons

A/R Personnel

Inventory Clerks

Carpenters

Read

Y

N

Y

Y

Insert

N

N

N

N

Modify

N

N

Y

N

Delete

N

N

Y

N

Authorizations for Inventory Records 3 - Appropriate recovery techniques: a. Aborted transaction; use backward recovery. Of course, the transaction then needs to be reentered. b. Database destruction; use forward recovery from the backup copy of the database. c. System failure; use forward recovery from most recent checkpoint. d. Incorrect data; several alternatives are possible. First, you could do a selective backward recovery to undo the incorrect transaction, and then reprocess the transaction using the correct amount. If this is not possible, then enter a compensating transaction and notify the student of the error. e. If the system is mirrored, it may be possible to switch to the mirrored data and rebuild the corrupted data on a new disk. If the system is not mirrored, it may not be possible to restart because status information in main memory has been lost or damaged. The safest approach is to restart from the most recent checkpoint before the system failure. Because no database change log is created, the database cannot be rolled forward by applying after-images. Transactions have to be reprocessed manually.

333

Chapter 4

3 - Appropriate security measures: a. Encryption b. Authentication schemes c. Authorization rules d. Authentication schemes 3 - SOX issues: a. Five DBAs have SysAd account: Primarily, this is a logical access to data (personnel) issue but it may also be categorized as an I T change management issue, since it has to do with who has access to production systems and data. b. Changes to DB structure lacked mgmt. approval: Example of IT Change Management issue. c. Users have access after termination: Example of Logical access to data (personnel) issue. d. Databases regularly backed up by automated system: Example of IT Operations issue. e. No logging enabled: Example of IT Operations issue. f. Increase in transaction volume: This does not represent a problem, given that the increases are aligned.

3 - Risks of issues: a. Five DBAs have SysAd account: The risk is that a wide-reaching change can be made by any of the five people, when only one person (the SysAd) should be responsible for such a widereaching change. b. Changes to DB structure lacked mgmt. approval: The risk is that an unauthorized change could be made to the database that would open up possible access for unauthorized people or programs, thus endangering the organization‘s data and activities. c. Users have access after termination: The risk is that the data and processes could be altered by someone who has left the organization (perhaps due to termination). d. Databases regularly backed up by automated system: The risk is that if the automated system

Chapter 4

334

crashes or is compromised by something (or someone), then the organization‘s data assets are vulnerable. e. No logging enabled: Not having logging data available will make it very difficult to troubleshoot any type of anomaly in system use, whether caused by a technical problem or a security challenge. This, in turn, will make it very difficult to address the problems in a timely way, potentially also increasing the company‘s legal exposure. f. Increase in transaction volume: The rapid increase in transaction volume is, of course, desirable, but it might also signify a problem if the company does not have an easily scalable infrastructure in place. If not, it is possible that users‘ experience with the company‘s service will deteriorate and both attracting new customers and retaining existing ones will become more difficult.

3 - Open source v s traditional commercial DBMSs, differences in administration: ersu

In responses to this question, it is likely that the students will find that traditional commercial database products, such as Oracle 12c, have a more sophisticated and mature set of services available for D BAs. The open source DBMS capabilities might be at the same level as the traditional systems, but often their use requires more technical sophistication and work at the operating system level. In their comparison between PostgreSQL and mySQ L, it is likely that most students find the administrative functions of Postgre SQL more intuitive to use and more extensive. The capabilities and user interfaces do, however, change frequently and thus, it is impossible to predict the results of the comparison at a specific point in time.

3 - Cloud Service Providers: The answers will depend on the cloud service providers chosen.

3 - Are cloud databases eliminating the need for data/database administrators: The memo could discuss the following types of issues: o Data administration work (described more closely in Chapter 12) will, in all likelihood, still be performed in-house, regardless of the type of cloud model used. Data administration may, indeed, become more complicated in some cases because of the need to manage the overall relationship with the cloud provider and architect the overall data management infrastructure. o If an IaaS model is used, most of the DBA work still needs to be performed in-house.

335

Chapter 4

o Somebody in the organization has to manage the relationship with the cloud vendor at the technical level o DBAs are still needed to have the ultimate responsiblity for the security and privacy of organizational data. This work might have more policy elements than with the internally managed process, but it is equally important. o It is likely that a company that is running most of its data management solutions in the cloud still runs parts of it (e.g., those involved rare or experimental components) in-house, leading to the need of D BA s.

3 - Use of pricing calculators of cloud-based database service providers: The answers will depend on the cloud service providers selected.

Suggestions for Field Exercises 3A good starting point for the purposes of this assignment would be to identify any D BMS that support complex data types like graphics, video, and sound. Object-oriented databases will stand out for their abilities in this regard. This is the newest D BMS technology and larger organizations are gaining experience with it by selectively using it when complex data or event-driven programming is appropriate for the application.

3Students who investigate this question may become interested in understanding the difference between symmetric multiprocessing (S M P) and massively parallel processing (M P P), topics that are covered in more depth in a later chapter (see index for page reference). In a typical S M P architecture, the machine has up to a few dozen processors, and each processor shares all hardware resources, including memory, disks, and the system bus. Because each processor can see all of the available memory, communicating between processors is straightforward: one processor can easily view the results generated by another processor simply by looking at the appropriate section of memory. M P P machines support multiple nodes that each have their own private memory and that communicate via passing messages over an interconnect. S M P systems seem to be best suited for either mission-critical or O L T P applications, where the application‘s growth rate is slow and steady at less than 20 percent annually and the amount of raw data is in the range of 10 to 100 G B. M P P systems are best suited for either complex analytical or very large decision-support applications.

Chapter 4

336

Students may also discover that several options exist for breaking apart a query into modules that can be processed in parallel. All options are not available with every D B M S, and each D B M S often has unique options due to its underlying design.

3Student answers will vary based on the organization, its standards, and the people they actually contact within the organization. Answers should evidence a belief (fully normalized or denormalized databases) as well as a rationale for the belief.

3In choosing a file organization for a particular file in a database, students should find that database designers consider many of these seven factors: a. Fast data retrieval b. High throughput for processing data input and maintenance transactions c. Efficient use of storage space d. Protection from failures or data loss e. Minimizing need for reorganization f. Accommodating growth g. Security from unauthorized use Secondary key indexes are important for supporting many reporting requirements and for providing rapid ad hoc data retrieval. Indexed sequential in comparison to indexed nonsequential allows more efficient use of space and faster sequential data processing without much, if any, sacrifice in random data record accessing speed. A bitmap is ideal for attributes that have even a few possible values, which is not true for conventional tree indexes. Indexes may be deleted because of storage space constraints or to reduce maintenance overhead.

3This assignment is an alternative to having a D B A or data administrator visit your class. The evaluation will depend on the organization visited but should target issues raised in this chapter.

3This is left as a student exercise. Student answers will vary depending upon which organization is chosen and the depth of student inquiry.

337

Chapter 4

3This assignment is an alternative to having a D B A or data administrator visit your class. The evaluation will depend on the organization visited.

3This assignment is an alternative to having a D B A or data administrator visit your class. The person who is most likely to be in charge of capacity planning is the database administrator. The D B A role has become more specialized lately, evolving into specialties such as distributed database/network capacity planning, and it is possible your students will find a person whose responsibilities are defined in this manner.

3This assignment is an alternative to having a DB A or data administrator visit your class.

3This is a good exercise for students to gain some insight into open-source implementations. Students should particularly make note of how an open-source platform is administered as compared to a traditional platform such as Oracle.

Project Questions 3 - Opportunities for denormalization The primary ones that could be easily implemented are those related to the subtype/supertype structures.

The complexity of the implementation model could be reduced by removing the subtype structures. This would lead to some NULL values, but the resulting physical data model would be somewhat simpler and require fewer joins. Also, the ADMIN table could be incorporated with ARTISTMANAGER and VENUE with EVENT. There is no need to modify the (E)E-R diagram based on these decisions. Denormalization is a decision related to physical database design and not conceptual data modeling.

3 - Data dictionary See page 32. The formatting is slightly different from Table 1-1, but the content is essentially the same.

3 - Physical data model The model can be directly derived from the solution to 8-90. The model solution will not implement any denormalization. Please note that in the implementation: o We will add _T to the names of the relations o We will have to modify the name of the columns marked with an asterisk (*) because they are reserved words in Oracle.

Chapter 4

338

3 - Strategy for reviewing deliverables The most important deliverables to be reviewed with the FAME stakeholders are the final version of the conceptual data model and the data dictionary. At this stage, particularly in the context of the data dictionary, the review should be done by individuals who are best aware of the technical details of the tasks being affected. It is likely that this varies depending on the section of the database. Thus, for certain tasks Alex Martin is the best person to discuss the detailed data needs and for others, Pat Smith. Overall approval

by Mr. Forondo is needed, but only after detailed reviews by the subject area experts.

Data Dictionary

ADMIN Name

Desc

Data type

Format / Ref Table

Allowable

Req

Ind

Y Y Y Y

Y

values BLANK

AdminID LastName FirstName AmanagerID

NUMBER(12) VARCHAR2(25) VARCHAR2(25) NUMBER(12)

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

References ARTISTMANAGER

BLANK

BLANK

Y

AGREEMENT Name

Desc BLANK

AgreementNbr Date* GrossAmount

BLANK

BLANK

Data type

Format / Ref Table

Allowable Req Ind values NUMBER(12) Y Y TIMESTAMP Y NUMBER(12,2) $#,###,###,###.## Y BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

AtSourceTaxWithheld

BLANK

Terms

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Y

Y

Y

Y

NUMBER(12,2) $#,###,###,###.## Qualitative CLOB description of agreement terms BLANK

EventID

BLANK

NUMBER(12) BLANK

ContractID

NUMBER(12)

References EVENT References CONTRACT

BLANK

ARTIST Name

Desc

Data type

BLANK

ArtistID

NUMBER(12)

Format / Ref Table

Allowable values

BLANK

BLANK

Req Ind Y

Y

339

Name

Chapter 4

Desc

Data type

BLANK

LastName FirstName Gender YearOfBirth Address

VARCHAR2(25) VARCHAR2(25) CHAR(1) NUMBER(4)

BLANK

BLANK

BLANK

Format / Ref Table

Allowable values

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

M, F, N <CurrentYear

Full address . T his woul d, i n practice, be di vi ded i nto multipl e c olumns .

Full address . T his woul d, i n practice, be di vi ded i nto multipl e c olumns .

Full address . T his woul d, i n practice, be di vi ded i nto multipl e c olumns .

CHAR(10)

(XXX)XXXXXXX

Y Y

BLANK

BLANK

BLANK

BLANK

BLANK

Full address . T his woul d, i n practice, be di vi ded into multi ple c olumns.

Full address . T his woul d, i n practice, be di vided into multi ple col umns.

Full address.

This would, in practice, be divided into multiple columns.

BLANK

BLANK

PhoneNumber BLANK

Email ArtistType

Req Ind

BLANK

BLANK

VARCHAR2(50) CHAR(1) X

Subtype

BLANK

Y BLANK

Y Y

C, P

BLANK

discriminator ARTISTCOMMITMENT Name

Desc BLANK

AcommitmentID StartDateTime EndDateTime ArtistID

BLANK

BLANK

BLANK

Data type

Format / Ref Table

Allowable Req values NUMBER(12) Y TIMESTAMP Y TIMESTAMP Y NUMBER(12) References Y ARTIST CHAR(1) X PE, PR BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Subtype discriminator

ARTISTDEGREE Name

Desc BLANK

ArtistID BLANK

DegreeID

Data type

Format / Allowable Req Ref Table values NUMBER(12) References Y ARTIST NUMBER(12) References Y DEGREE NUMBER(4) <Current year

Year degree was received

Ind

BLANK

Y

BLANK

BLANK

Year*

Y

BLANK

BLANK

CommitmentType

Ind

BLANK

Y BLANK

Y BLANK

Chapter 4

340

ARTISTEXPENSE Name

Desc Data type

Format / Ref Table

BLANK

ExpenseID ArtistID

Allowable Req values Y Y

Ind

BLANK

NUMBER(12) References EXPENSE NUMBER(12) References CONTRACTEDARTIST

BLANK

Y Y

BLANK

ARTISTHONOR Name

Desc

Data type

Format / Allowable Req Ref Table values NUMBER(12) References Y ARTIST NUMBER(12) References Y HONOR

BLANK

Ind

BLANK

ArtistID BLANK

Y

BLANK

HonorID

Y

ARTISTINSTRUMENT Name

Desc Data type BLANK

ArtistID BLANK

InstrumentID

Format / Ref Allowable Req Table values NUMBER(12) References Y ARTIST NUMBER(12) References Y INSTRUMENT

Ind

BLANK

Y

BLANK

Y

ARTISTMANAGER Name AmanagerID LastName FirstName

Desc Data type

Format / Ref Table

Allowable values

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

NUMBER(12) VARCHAR2(25) VARCHAR2(25)

Req

Ind

Y Y Y

Y BLANK

BLANK

ARTISTNEWS Name

Desc BLANK

ArtistID BLANK

NewsItemID BLANK

Date*

ARTISTPAYMENT

Data type

Format / Allowable Req Ref Table values NUMBER(12) References Y ARTIST NUMBER(12) References Y NEWSITEM TIMESTAMP Y

Ind

BLANK

Y

BLANK

BLANK

BLANK

Y BLANK

341

Name ApaymentID Date Amount AdminID ArtistID

Chapter 4

Desc Data type

Format / Ref Table

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Ind

BLANK

NUMBER(12) TIMESTAMP NUMBER(12,2) $#,###,###,###.## NUMBER(12) References ADMIN NUMBER(12) References CONTRACTEDARTIST

BLANK

Allowable Req values Y Y Y Y Y

Y

BLANK

BLANK

BLANK

BLANK

BLANK

Y Y

BLANK

ARTISTMGREXPENSE Name

Desc Data type BLANK

ExpenseID BLANK

AManagerID

Format / Ref Table NUMBER(12) References EXPENSE NUMBER(12) References

Allowable Req values Y

Ind

BLANK

Y

BLANK

Y

Y

ARTISTMANAGER CONTRACT Name

Desc

Data type

BLANK

ContractID StartDate EndDate RoyaltyPercenta ge Terms ArtistID

NUMBER(12) TIMESTAMP TIMESTAMP NUMBER(3,2 ) CLOB NUMBER(12)

BLANK

BLANK

BLANK

BLANK

BLANK

Format / Ref Table Allowable values BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

<100 BLANK

BLANK

Req

Ind

Y Y Y Y

Y

BLANK

BLANK

Y

Y

BLANK

BLANK

BLANK

BLANK

References CONTRACTDARTI ST

CONTRACTEDARTIST Name

Desc Data type BLANK

ArtistID BLANK

AManagerID

CUSTOMER

Format / Ref Allowable Req Table values NUMBER(12) References Y ARTIST NUMBER(12) Refereces Y ARTISTMANAGER

Ind

BLANK

Y

BLANK

Y

Chapter 4

Name

Desc

Data type

BLANK

CustomerID Name* Address This would, in practice, be divided into multiple columns BLANK

342

Format / Ref Table

Allowable Req values

Ind

BLANK

BLANK

NUMBER(12) VARCHAR2(50)

BLANK

Y Y

Y

BLANK

This woul d, i n prac tice, be di vi ded i nto multipl e c olumns

This woul d, i n prac tice, be di vi ded i nto multipl e c olumns

This woul d, i n prac tice, be di vi ded i nto multipl e c olumns

This woul d, i n prac tice, be di vi ded i nto multipl e c olumns

This woul d, i n prac tice, be di vi ded i nto multipl e c olumns

BLANK

CUSTOMERPAYMENT Name CPaymentID Date* Amount CustomerID

Desc Data type

Format / Ref Table

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Allowable Req values NUMBER(12) Y TIMESTAMP Y NUMBER(12,2) $#,###,###,###.## Y NUMBER(12) References Y CUSTOMER

Ind Y

BLANK

Y

DEGREE Name

Desc

Data type

BLANK

DegreeID DegreeName University

NUMBER(12) VARCHAR(100) VARCHAR(50)

BLANK

BLANK

Format / Ref Table

Allowable Req values

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Ind

Y Y Y

Y BLANK

BLANK

EVENT Name EventID EventDescription DateTime VenueID

Desc Data type

Format / Ref Table

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

CustomerID

EXPENSE

NUMBER(12) VARCHAR(400) TIMESTAMP NUMBER(12) References VENUE NUMBER(12) References CUSTOMER BLANK

BLANK

Allowable Req values Y Y Y Y

Ind

BLANK

Y

BLANK

BLANK

BLANK

BLANK

BLANK

Y

BLANK

Y

Y

343

Chapter 4

Name

Desc

Data type

Format Allowable Req Ind / Ref values Table Y Y Description Y XXXXY XXXXXXXXXXXX A, M Y Y

BLANK

ExpenseID Description Amount AccountNbr

NUMBER(12) VARCHAR2(400) NUMBER(12,2) NUMBER(16)

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

ExpenseType Subtype

CHAR(1)

discriminator HONOR Name

Desc BLANK

HonorID HonorDescription

BLANK

Data type

Format Allowable Req / Ref values Table NUMBER(12) Y VARCHAR2(100) Y BLANK

BLANK

BLANK

BLANK

Ind

Y BLANK

INSTRUMENT Name

Desc BLANK

InstrumentID InstrumentName

BLANK

Data type

Format Allowable Req / Ref values Table NUMBER(12) Y VARCHAR2(50) Y BLANK

BLANK

BLANK

BLANK

Ind

Y BLANK

INVOICE Name

Desc

Data type

BLANK

InvoiceNbr Date Total

NUMBER(12) TIMESTAMP NUMBER(12,2)

BLANK

BLANK

Format / Ref Table

Allowable Req values

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Y Y Y

Ind

Y BLANK

BLANK

INVOICEPAYMENT Name

Desc Data type BLANK

InvoiceNbr

Ind

BLANK

NUMBER(12) BLANK

PaymentID

Format / Allowable Req Ref Table values References Y INVOICE References Y

Y

BLANK

NUMBER(12)

Y

Chapter 4

Name

344

Desc Data type

Format / Ref Table PAYMENT

Allowable Req values

Ind

BLANK

BLANK

BLANK

BLANK

Amount

NUMBER(12,2)

Y

NEWSITEM Name

Desc BLANK

NewsItemID Source* Content* Link to content BLANK

Data type

Format Allowable Req / Ref values Table NUMBER(12) Y VARCHAR2(!00) Y BLOB Y

Ind

Data type

Ind

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Y

NEWSITEM Name

Desc BLANK

NewsItemID Source* Content* Link to content BLANK

Format Allowable Req / Ref values Table NUMBER(12) Y VARCHAR2(!00) Y BLOB Y BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Y

PERSONALC Name

Desc Data type

Format / Ref Table

BLANK

ACommitmentID BLANK

Firmness

Allowable Req values Y

Ind

BLANK

NUMBER(12) References ARTISTCOMMITMENT CHAR(1) F = firm; N = F, N negotiable

Y BLANK

Y

PERFORMANCERELATEDC Name

Desc Data type BLANK

ACommitmentID BLANK

Category* BLANK

EventID PROSPECTIVEARTIST

Format / Ref Table

Allowable Req Ind values Y Y BLANK

NUMBER(12) References ARTISTCOMMITMENT CHAR(1) P=performance, R = P, R, T rehearsal, T = travel NUMBER(12) References EVENT BLANK

BLANK

Y BLANK

Y

345

Chapter 4

Name

Desc Data type

Format Allowable Req / Ref values Table NUMBER(12) Y

BLANK

BLANK

ArtistID

Ind

BLANK

Y

RECOMMENDATION Name RecommendationID Summary QualityEvaluation ReceivedDate CreatedDate ArtistID

Desc Data type

Format / Ref Table

Allowable values

BLANK

BLANK

BLANK

NUMBER(12) VARCHAR2(1000) VARCHAR2(500) TIMESTAMP TIMESTAMP NUMBER(12) References PROSPECTIVEARTIST NUMBER(12) References

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

SourceID

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Req Ind

BLANK

Y Y Y Y Y Y

Y

Y

Y

SAMPLE Desc

Data type

Format / Ref Table

BLANK

BLANK

SampleID SampleContent Link to content ArtistID

NUMBER(12) BLOB

Allowable Req values Y

Ind

BLANK

BLANK

BLANK

Y

Y

BLANK

BLANK

BLANK

Y

BLANK

NUMBER(12) References ARTIST

SOURCE Name

Desc

Data type

BLANK

SourceID Name* Type* Quality VENUE Name

BLANK

BLANK

BLANK

Desc

Format / Ref Table BLANK

NUMBER(12) VARCHAR2(50) VARCHAR2(20) NUMBER(2,0)

BLANK

BLANK

This

Ind

BLANK

BLANK

Y

BLANK

BLANK

BLANK

BLANK

BLANK

1-10

Data type

BLANK

VenueID Name Address

Allowable Req values Y Y Y BLANK

BLANK

NUMBER(12) VARCHAR2(50) Y

Format / Ref Table

Allowable Req values

BLANK

BLANK

BLANK

BLANK

BLANK

BLANK

Y Y Y

BLANK

BLANK

BLANK

Y

BLANK

SOURCE

Name

BLANK

Ind

Y BLANK

BLANK

Chapter 4

Name

Desc

Data type

346

Format / Ref Table

Allowable Req values

Ind

BLANK

BLANK

BLANK

would, in practice, be divided into multiple columns BLANK

Country

VARCHAR2(50)

Y

Chapter 9 Data Warehousing and Data Integration Chapter Overview The purpose of this chapter is to introduce students to the rationale and basic concepts of underlying data warehousing from the perspective of data and database management. Building on the framework introduced in Chapter 1 (Figure 1-5), we contrast operational and informational processing, and we discuss the reasons why so many organizations are seeking to exploit data warehouses for competitive advantage. We discuss alternative data warehouse architectures (especially the database architectures) and techniques for populating a warehouse. In addition to the specifics of data warehousing, we also discuss general principles of data integration and describe the extract-transform-load (ETL) process for data integration. This chapter focuses almost solely on the infrastructure of data warehousing and principles of data integration; other aspects of analytics infrastructure and analytics processes are discussed in Chapters 10 and 11.

Chapter Objectives Specific student objectives are included in the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to:

347

Chapter 4

1. Establish the fact that many organizations today are experiencing an information gap. That is, they are drowning in data but starving for information.

2. Define data warehousing and describe four characteristics of a data warehouse.

3. Describe two major factors that drive the need for data warehousing as well as several advances in the field of information systems that have enabled data warehousing.

4. Build on the framework introduced in Figure 1-5, contrast operational systems and informational systems from the viewpoint of data management.

5. Describe the basic architectures that are most often used with data warehouses.

6. Contrast transient and periodic data, and discuss how data warehouses are used to build a historical record of an organization.

7. Discuss the purposes of populating a data warehouse and the problems of data reconciliation.

8. Contrast data warehouses and data marts.

9. Describe and illustrate the dimensional data model (or star schema) that is often used in data warehouse design.

10. Discuss the general principles underlying data integration and describe the three main types of data integration.

11. Review the E TL process in the context of data warehousing from the data integration perspective.

Key Terms Aggregation

Enterprise data warehouse

Real-time data

(EDW)

warehouse

Changed data capture

Grain

Refresh mode

Conformed dimension

Incremental extract

Reconciled data

Data federation

Independent data mart

Selection

Data mart

Informational system

Snowflake schema

Chapter 4

Aggregation

Enterprise data warehouse

Real-time data

(EDW)

warehouse

Data scrubbing

Joining

Star schema

Data transformation

Logical data mart

Static extract

Data warehouse

Operational data store (O D

Transient data

348

S) Dependent data mart

Operational system

Derived data

Periodic data

Update mode

Classroom Ideas 1. Discuss the importance of data warehousing in organizations today. Over 90 percent of large (Fortune 1000) companies have completed data warehouses or have a warehousing project underway. Ask your students to suggest reasons for this popularity.

2. Discuss job opportunities in data warehousing, business intelligence, and data mining. Numerous websites and newspapers have advertised job listings.

3. Emphasize that a successful data warehousing project requires the integration of everything the students have learned throughout the database course (in fact, everything in the IS curriculum).

4. Discuss the idea of heterogeneous data (use Figure 9-1). Ask your students for reasons why such data are so commonplace and what problems they present.

5. Compare operational and informational systems using Table 9-1. Ask your students for examples of each type of system.

6. Compare the independent data mart (Figure 9-2), dependent data mart and operational data store (Figure 9-3), and logical data mart (Figure 9-4) architectures.

7. Discuss the three-layer data architecture (Figure 9-5). Ask your students why it might be necessary to have both a reconciled data layer and a derived data layer.

349

Chapter 4

8. Compare transient data (Figure 9-7) with periodic data (Figure 9-8). Explain how periodic data provide a historical record of events.

9. Introduce components of a star schema (Figure 9-9) and discuss the example shown in Figures 9-10 and 9-11. Have your students help you diagram another example (university, football team, etc.).

10. Discuss some variations of the star schema (Figure 9-13, 9-14).

11. Discuss conformed dimensions and how these could be used (Figure 9-13).

12. Discuss normalizing dimension tables, highlighting multivalued dimension, hierarchies, and the use of helper tables (Figures 9-14, 9-15, 9-16, and 9-17).

13. Discuss slowly changing dimensions and some ways to handle this. Use Figure 9-18 as an example of one possible solution.

14. Discuss the advantages and disadvantages of consolidation, federation, and propagation as forms of data integration (Table 9-4).

15. Discuss the steps of data reconciliation (Figure 9-21). Emphasize that this is generally considered to be the most complex challenge in data warehousing.

16. Discuss some of the typical data transformation functions (use Figures 9-22 and 9-23). Have your students suggest other practical examples.

Answers to Review Questions 3 - Define each of the following terms: a. Data warehouse. A subject-oriented, integrated, time-variant, non-volatile collection of data used in support of management decision-making processes (Inmon and Hackathorn, 1994) b. Data mart. A data warehouse that is limited in scope, whose data is obtained by selecting and (where appropriate) summarizing data from the enterprise data warehouse c. Reconciled data. Detailed, historical data that are intended to be the single, authoritative source for all decision support applications and not generally intended to be accessed directly by end users

Chapter 4

350

d. Derived data. Data that have been selected, formatted, and aggregated for end-user decision support applications e. Enterprise data warehouse. A centralized, integrated data warehouse for the entire enterprise that provides data to all end users of decision support applications f. Real-time data warehouse. A data warehouse that receives and analyzes (near) real-time data feeds from systems of record (instead of using batch E TL), making data available for very quick responses to business events as they take place g. Star schema. A simple database design in which dimensional data are separated from fact or event data. A dimensional model is another name for star schema h. Snowflake schema. An expanded version of a star schema in which all of the tables are fully normalized i. Grain. The length of time (or other meaning) associated with each record in the table j. Conformed dimension. One-or-more-dimension tables associated with two or more fact tables for which the dimension tables have the same business meaning and primary key with each fact table k. Static extract. A method of capturing a snapshot of the required source data at a point in time l. Incremental extract. A method of capturing only the changes that have occurred in the source data since the last capture m. Refresh mode. An older approach to loading data to a data warehouse, which involves rewriting the data in the data warehouse at regular intervals (with larger and larger amounts of data in data warehouses, this approach has become increasingly rare) 3 - Match the following terms and definitions: b

periodic data

e

data mart

f

star schema

351

Chapter 4

g

data scrubbing

j

data transformation

h

grain

c

reconciled data

i

dependent data mart

l

real-time data warehouse

d

selection

a

transient data

h

snowflake schema

3 - Contrast the following terms: a. Transient data; periodic data. In transient data, changes to existing records are written over previous records, thus destroying the previous data content. In periodic data, the data is never physically altered or deleted once they have been added to the store. b. Data scrubbing; data transformation. Data scrubbing uses pattern recognition and other artificial intelligence to upgrade the quality of raw data before they are transformed and moved to the data warehouse. Data transformation converts data from the format of the source operational systems to the format of the enterprise data warehouse. c. Data warehouse; data mart; operational data store. A data warehouse is an integrated and consistent store of subject-oriented data that are obtained from a variety of sources and formatted into a meaningful context to support decision making in an organization. A data mart is a data warehouse that is limited in scope and whose data are obtained by selecting and (where appropriate) summarizing data from the enterprise data warehouse. An operational data store is much different from a data warehouse or data mart because it is updatable, has a limited amount of historical data, and is available to operational users for use in decision support. d. Reconciled data; derived data. Reconciled data are intended to be the single, authoritative source for all decision-support applications and not generally intended to be accessed by end users;

Chapter 4

352

derived data have been selected, formatted, and aggregated for end-user decision support applications. e. Static extract; incremental extract. A static extract provides a capture of the source data at a point in time, while an incremental extract provides the changes that have occurred in the source data since the last capture. f. Fact table; dimension table. Fact tables contain factual or quantitative data about a business such as units sold, orders booked, and so on. Dimensional tables hold descriptive data about the business. g. Star schema; snowflake schema. A star schema is a simple database design in which dimensional data are separated from fact or event data, while a snowflake schema is an expanded version of a star schema in which all of the tables are fully normalized. h. Independent data mart; dependent data mart; logical data mart. An independent data mart is populated with data extracted from the operational environment without the benefit of a reconciled data layer; a dependent data mart is populated exclusively from the enterprise data warehouse and its reconciled data layer. A logical data mart is created from a relational view of a data warehouse. i. Status data; event data. Status data refers to the status of a business object (such as product and its inventory status or bank account and its balance) at a specific point in time. Event data refers to the transactions that change the status of a business object.

3 - Five major trends that necessitate data warehousing in many organizations today: a. No single system of record b. Multiple systems are not synchronized c. Organizations want to analyze the activities in a balanced way d. Customer relationship management e. Supplier relationship management

353

Chapter 4

3 - Major components of a data warehouse architecture: a. Operational data. Stored in the various operational systems throughout the organization (and sometimes in external systems) b. Reconciled data. The type of data stored in the enterprise data warehouse c. Derived data. The type of data stored in each of the data marts 3 - List three types of metadata; briefly describe the purpose of each type: a. Operational metadata. These are metadata that describe the data in the various operational systems (as well as external data) that feed the enterprise data warehouse. Operational metadata typically exist in a number of different formats, and they are unfortunately, often of poor quality. b. Enterprise data warehouse (E DW) metadata. These metadata are derived from (or at least are consistent with) the enterprise data model. They describe the reconciled data layer. E DW metadata also describe the rules that are used to transform operational data to reconciled data. c. Data mart metadata. These metadata describe the derived data layer. They also describe the rules that are used to transform reconciled data to derived data.

3 - Four characteristics of a data warehouse: a. Subject-oriented. A data warehouse is organized around the key subjects (or high-level entities) of the enterprise. Major subjects may include customers, patients, students, products, time, etc. depending on the real-world domain within which the organization operates. b. Integrated. The data housed in the data warehouse are defined using consistent naming conventions, formats, encoding structures, and related characteristics gathered from several internal systems of record and also often from sources external to the organization. This means that the data warehouse holds the one version of ―the truth.‖ c. Time-variant. Data in the data warehouse contain a time dimension so that they may be used to study trends and changes. d. Non-updatable. Data in the data warehouse are loaded and refreshed from operational systems, but cannot be updated by end users.

Chapter 4

354

3 - Five claimed limitations of independent data marts: a. A separate ETL process has to be developed for each data mart. This can yield costly redundant data and efforts. b. A clear, enterprise-wide view of data may not be provided because data marts may not be consistent with one another. c. Analysis is limited because there is no capability to drill down into greater detail or into related facts in other data marts. d. Scaling costs are excessive as each new application creates a separate data mart, which repeats all the extract and load steps. e. Attempting to make the separate data marts consistent generates a high cost to the organization.

3 - Two claimed benefits of independent data marts: a. Provides the ability to prove the concept of a data warehouse by working on a series of small, fairly independent projects b. A reduction in the amount of time until a benefit from data warehousing is perceived by the organization, so that there is not a delay until all data are centralized 3 - 10 essential rules for dimensional modeling: a. Use atomic facts – users will ultimately want them. b. Create single-process fact tables. c. Include a date (or finer grained time) dimension in every fact table. d. Enforce consistent grain – each measurement has to be related to the same combination of keys e. Disallow null keys in fact tables f. Honor hierarchies – either snowflake or denormalize. g. Decode dimension tables. h. Use surrogate keys to identify dimension table rows.

355

Chapter 4

i. Conform dimensions across multiple fact tables. j. Balance requirements with actual data.

3 - List four objectives of derived data: a. Provide ease of use for decision support applications b. Provide fast response for predefined user queries or requests for information c. Customize data for particular target user groups d. Support ad-hoc queries and data mining and other analytic applications 3 - Star schema v s relational data model? ersu

The star schema is a denormalized implementation of the relational data model. The fact table plays the role of a normalized n-ary associative entity that links together the instances of the various dimensions. Usually, the dimension tables are in second normal form or possibly (but rarely) in third normal form. The dimension tables are denormalized and, because they are neither updated nor joined with one another, provide an optimized user view for specific information needs but could not be used for operational purposes.

3 - Volatility of a data warehouse v s volatility of an operational database: ersu

A major difference between a data warehouse and an operational system is the type of data stored. An operational system most often stores transient data, which are overwritten when changes to the data occur.

Thus, the data in an operational system are very volatile. On the other hand, a data warehouse usually contains periodic data, which are never overwritten once they have been added to the store. A data warehouse contains a history of the varying values for important (dimensional) data.

3 - Pros and cons of logical data marts: Pros: a. New data marts can be created quickly because no physical database or database technology needs to be acquired or created. Also, loading routines do not need to be written. b. Data marts are always up-to-date because data in a view are created when the view is referenced.

Views can be materialized.

Con: a. Logical data marts are only practical for moderate-sized data warehouses or when high performance data warehousing technology is used.

Chapter 4

356

3 - Impact of decrease in the cost of storage space: The decrease in the cost of storage space has a) allowed the creation of alternatives for traditional data warehousing, such as data lakes; and b) changed design quality evaluation criteria so that space use alone is seldom anymore a major design criterion.

3 - Helper table; why used for derived data?

A star schema data mart is comprised of fact and dimension tables. Fact tables are completely normalized because each fact depends on the whole composite primary key and nothing but the composite primary key.

Dimension tables may not be fully normalized. Helper tables in the data warehouse world act as associative entities in the conceptual model world to link instances of data in M:N relationships. The helper table acts as a way to normalize the relationship between the dimension data and the fact data, such as in the case of a multivalued dimension situation explained in Figure 9-15 in the text.

3 - Characteristics of a surrogate key for a data warehouse or data mart: All keys used to join the fact table to the dimension tables should be system-assigned. The key should be simple as compared to the production or composite key. It is best to maintain the same length and format for all surrogate keys across the entire data warehouse, regardless of the business dimensions involved.

3 - Time dimension?

Time is almost always a dimension in a data warehouse or data mart because data marts and data warehouses record facts about dimensions over time. Date and time are almost always included as a dimension table, and a date surrogate key is usually one of the components of the primary key of the fact table. The time dimension is critical to most of the reporting and analysis needs that end users of the data warehouse have. Often, users will want to view how facts (such as sales) have changed over time or may want to compare one time period against another.

3 - Purpose of conformed dimensions?

A conformed dimension includes one or more dimension tables associated with two or more fact tables for which the dimension tables have the same business meaning and primary keys. Thus, conformed dimensions are important when there are multiple fact tables (often because there are multiple data marts) to be able to have consistent results across the marts and to be able to write queries that cut across the different marts.

Conformed dimensions allow users to: a. Share non-key dimension data b. Query across fact tables with consistency c. Work on facts and business subjects for which all users have the same meaning

357

Chapter 4

3 - In what way are dimension tables often not normalized?

Most dimension tables are not normalized so that for a given user group the dimension data are only one join away from associated facts. One example might be multivalued data, in which one could store multiple values by using several different fields. Another example would be the incorporation of data from other tables that are not part of the star schema but might be needed for analysis.

3 - What is a hierarchy as it relates to a dimension table?

A dimension table often has a natural hierarchy among the rows. Some examples might be geographical hierarchies (markets within a state, states within a region) and product hierarchies (products within a product line). These hierarchies can be handled in two ways: a. Include all information for each level of the hierarchy in a single, denormalized table with a helper table (Figure 9-17). b. Normalize the dimension into a nested set of tables (one for each level of the hierarchy) with 1:M relationships between them.

3 - What is the meaning of the phrase “slowly changing dimension”?

Although data warehouses track data over time, the business does not remain static. We need to keep track of the history of values in order to record the history of facts with correct dimensional descriptions when the facts occurred. Dimension data changes slower than transactional data, thus we can consider dimensions to be slowly changing dimensions.

3 - The most common approach used to handle slowly changing dimensions.

Create a new dimension table row (with a new key) each time the dimension object changes and this new row will contain all the dimension characteristics. A fact row is associated with the key whose attributes apply at the time of the fact. This approach allows us to create as many dimensional object changes as necessary. It can become unwieldy if rows change frequently. We may also want to store the surrogate key value for the original object in the dimension row so that we can relate changes back to the original object.

3 - What does it mean that data warehouses are non-updatable?

Non-updatable means that data, once included in the data warehouse, are never changed (except to correct errors related to technology). Instead, new versions of the same data may be stored.

3 - Data staging area v s enterprise data warehouse? ersu

The data staging area contains only current, consolidated data from source systems whereas an enterprise data warehouse (EDW) contains time-stamped history.

3 - The current key trends in data warehousing The current key trends in data warehousing include the following:

Chapter 4

358

o Data warehousing is increasingly seen as part of the portfolio of data management mechanisms that are integrated to address a broad variety of organizational needs seamlessly. o Specifically, data warehousing is used together with technologies and approaches under the ―big data‖ label (that will be discussed in Chapter 11). o Instead of just describing what has happened in the past (descriptive analytics), data warehousing needs to support predictive (forecasting of what is going to happen) and prescriptive (providing guidance towards a specific set of outcomes) analytics. o Volumes of data in data warehouses are going up, data is arriving to the data warehousing systems faster and faster, the content of data warehouses is heterogeneous, and the data is expected to be available to support business decision-making real-time.

3 - Benefits of offering data warehousing services in a cloud-based infrastructure: The potential benefits of using cloud-based infrastructure for data warehousing include the following: o A lower total cost of ownership o No need for expensive capital investments – pay-as-you-go model o Ability to grow data warehouses dynamically when demand increases o More flexibility in terms of selection of technologies; ability to choose the best tool for each purpose 3 - Data federation v s data propagation? ersu

Data federation provides a virtual view of integrated data without actually bringing all of the data into one physical, centralized database. Data propagation duplicates data across databases, usually with near-real time updates of changes throughout the organization.

3 - Six characteristics of reconciled data: Note to instructor: This use of the term reconciled data refers to the result of the extract-transform-load (E T L) process. a. Detailed. The data are at a detailed level. This provides maximum flexibility for various user communities to structure the data to best suit their needs. b. Historical. The data are periodic when they are intended to provide a historical perspective.

359

Chapter 4

c. Normalized. The data are fully normalized. Data that are normalized provide greater flexibility of use than denormalized data. Denormalization is not necessary to improve performance because reconciled data are usually accessed periodically using batch processes. d. Comprehensive. Reconciled data reflect an enterprise-wide perspective whose design conforms to the enterprise data model. e. Timely. Except for real-time data warehousing, data need not be near-real time, however, data must be current enough so that decision making can react in time. f. Quality controlled. Reconciled data must be of unquestioned quality and integrity because they are summarized into the data marts and used for decision making.

3 - Data reconciliation process: The overall steps in the data reconciliation process are as follows: a. Mapping and metadata management. The data needed in the data warehouse are identified and mapped back to the source data to be used to create the data warehouse. b. Capture/extract. The data for the data warehouse are actually obtained from the data sources. c. Cleanse/scrub. The data for the data warehouse are processed to identify errors or problems in the data. Data with errors are rejected from the E T L process and messages/flags are sent to the source systems for fixing of the errors. The cleansing/scrubbing process precedes any transformations of the source data into formats required by the data warehouse. d. Transform. The data for the warehouse are converted from the format of the source operational databases into the format of the enterprise data warehouse. Note: A data warehousing trend is for the transformation process to follow the loading process, thus making the overall process more of an extract-load-transform process rather than extract- transform-load process. e. Load and index. Data for the data warehouse are now loaded into the warehouse and indexed.

3 - Five errors and inconsistencies in operational data: a. Misspelled names and addresses b. Impossible or erroneous dates of birth

Chapter 4

360

c. Fields used for purposes in which they were never intended d. Mismatched addresses and area codes e. Missing data 3 - “Extract, transform, and load” v s data reconciliation process: ersu

Reconciled data are the result of the extract, transform, and load process. The process results in a single source for data that supports decision making within the organization. The data layer of the warehouse that results from this process is ideally detailed, historical, normalized, comprehensive, and timely. In addition, all of the data are quality controlled through the extract, transform, and load process.

3 - Common tasks during data cleansing: a. Decoding data to make them understandable for data warehousing applications b. Reformatting and changing data types and performing other functions to put data from each source into the standard data warehouse format ready for transformation c. Adding time stamps to distinguish values for the same attributes over time d. Converting between different units of measure e. Generating primary keys for each row of a table f. Matching or merging separate extractions into one table or file g. Logging errors detected, fixing those errors, and reprocessing corrected data without creating duplicate entries h. Finding missing data to complete the batch of data necessary for subsequent loading 3 - Field-level and record-level data transformations for ETL process: Field-level transformations are conversions of data from a source record format to a different format in a target record. Field-level transformations can be single-field or multi-field. An example of a single-field transformation is the conversion of an English measurement (e.g., inches) to a metric representation (e.g., centimeters). An example of a multi-field transformation is the conversion of a single product code into its two components of product and brand code.

Record-level functions include selection, joining, normalization, and aggregation. Selection, also known as subsetting, refers to getting a subset of the source data into the warehouse according to pre-set criteria, such as a date. Joining brings together data from various sources into a single table or view. Normalization refers to restructuring relations to remove problems with adding, deleting, or updating instances of data.

361

Chapter 4

Aggregation focuses on summarizing data at the detailed level into meaningful combinations for decision making (e.g., monthly sales total by store).

Answers to Problems and Exercises Note: In this Instructor‘s Manual section, all table and attribute names in schema graphics follow the naming conventions modeled in textbook Figure 9-20b. Table names are listed in ALL CAPS and attribute/column names are shown in TitleCase.

3 - Figure 9-1 analysis: A possible field list for the new table could be: StudentNo, LastName, FirstName, M I, Address, Telephone, Status, Dept, Hours, Insurance.

3a.

Chapter 4

362

Transient (06/21) Key

Name

Major

001

Amy

Music

002

Tom

Business

003

Sue

Art

004

Joe

Art

006

Jim

Phys Ed

Transient (06/22) Key

Name

Major

001

Amy

Music

002

Tom

Business

003

Sue

Psychology

004

Joe

Art

006

Jim

Bskt Weav

007

Pat

Music

Transient (06/23) Key

Name

Major

001

Amy

Art

002

Tom

Business

003

Sue

Psychology

004

Joe

Art

006

Jim

Bskt Weav

007

Pat

Music

b. It should be noted that the actual P K of the rows of this table is a combination of the original Key and the Date fields.

363

Chapter 4

c. Periodic (06/21)

Key

Date

Name

Major

Action

001

06/20

Amy

Music

C

002

06/20

Tom

Business

C

003

06/20

Sue

Art

C

004

06/20

Joe

Math

C

004

06/21

Joe

Art

U

005

06/20

Ann

Engineering C

005

06/21

Ann

Engineering D

006

06/21

Jim

Phys Ed

C

d. e. Periodic (06/22)

Key

Date

Name

Major

Action

001

06/20

Amy

Music

C

002

06/20

Tom

Business

C

003

06/20

Sue

Art

C

003

06/22

Sue

Psychology

U

004

06/20

Joe

Math

C

004

06/21

Joe

Art

U

005

06/20

Ann

Engineering C

005

06/21

Ann

Engineering D

006

06/21

Jim

Phys Ed

C

006

06/22

Jim

Bskt Weav

U

007

06/22

Pat

Music

C

f. g. Periodic (06/23)

Chapter 4

Key

Date

Name

Major

Action

001

06/20

Amy

Music

C

001

06/30

Amy

Art

U

002

06/20

Tom

Business

C

003

06/22

Sue

Psychology

U

004

06/20

Joe

Math

C

004

06/21

Joe

Art

U

005

06/20

Ann

Engineering C

005

06/21

Ann

Engineering D

006

06/21

Jim

Phys Ed

C

006

06/22

Jim

Bskt Weav

U

007

06/22

Pat

Music

C

3 - Millennium College a. Star Schema

364

365

Chapter 4

b. 500 course sections × 40 students per section × 30 periods (i.e., 3 semesters per year) = 600,000 rows (assuming 1 professor per course section) c. 600,000 rows * 5 fields per row * 15 bytes per field = 45,000,000 bytes d. There are several possible options that can be considered if a star schema is not mandated. The following suggestions are all aimed at creating a more normalized data model: 

Professor does not have to relate directly to the fact table. Professor could snowflake off of the Course Section (who are the professors teaching a particular section?). Then, there would be no Professor P K in the fact table.



Course information could snowflake off of Course Section (put Course I D, Course Name, and Units in a separate table related to Section). This would normalize Course and Section data.



Similarly, Department information (Department I D and Department Name) could be snowflaked off of Professor.

e. Dimensional segmentation is recommended. The student, section, and professor dimensions would be divided into two segments each, one for constant attributes and one for attributes that change. For example, the room might change frequently for the section. This approach would eliminate a large number of rows in the dimension tables if the changing attributes were to change each semester 3 - Snowflake schema for Millennium College

Chapter 4

366

This schema will have no impact on the size of the fact table, which remains the same as for the star schema.

3 - Simplified Automobile Insurance Company a. Star schema:

367

Chapter 4

b. To correctly estimate the number of rows, we must make some additional assumptions regarding the fiscal periods and the frequency of changes to policies. We assume the following: 1. The length of a fiscal period is one month 2. The data mart will contain five years of historical data 3. Approximately 5 percent of the policies experience some type of change each month Therefore, the expected number of rows is: .05 × 1,000,000 × 10 coverage items × 2 insured parties × 5 years × 12 months per year = 60,000,000 rows c. Total size of fact table: 60,000,000 rows × 8 fields × 10 bytes = 4,800,000,000 bytes (2.4 Gigabytes) 3 - Simplified Automobile Insurance Company, revised: a. An initial version of the extended star schema:

Chapter 4

368

b. Unfortunately, the policy fact table in this schema has a design issue because premium and deductible are not dependent on CLAIM. This would result in two different ―grains‖ or levels of detail in the same table, which is not permitted. A good solution is to create a separate star schema for claim facts (in this case, only ClaimTotal) with all six dimension tables, along with the original star schema. We can then calculate the number of rows in the claims fact table as follows: 60 months × 2,000 claims per month = 120,000 rows in this additional fact table

369

Chapter 4

3 - Millennium College, revision of P&E 9-28

Another dimension table was added with the department information. This will create a snowflake schema.

The rationale for doing this is that users may also eventually want similar information for the Professor dimension. If we added the department information only to the Course Section dimension, then this information would need to be replicated in the Professor dimension later.

3 - Merits of independent v s dependent, normalized v s denormalized data marts ersu

er su

While Ralph Kimball advocates for a dimensional model to solve all of the decision support needs of an organization, Inmon and Armstrong advocate for the creation of one central data warehouse and dependent data marts built from this. Kimball‘s position is that a dimensional model, with fact tables and denormalized dimension tables, can be created to meet the needs of an entire organization; this model is far better than the traditional E R model. The opposing view holds that normalized tables are the way to build a data warehouse, because these tables can then be used to feed many different data marts tailored to individual users. Inmon states that building a dimensional model for an enterprise-wide application will result in much duplication of data and inconsistent data. While the dimensional model could be built for a data mart, the data mart must be dependent upon a data warehouse as a central repository.

3 - Food Manufacturing Company Data mart situation In the initial solution, we assume that the customer is purchasing from a storage location. We also assume that there could be internal transfers both between plants and from plants to storage. Because not all

Chapter 4

370

dimensions are used in every movement event, the best solution for this exercise is a multiple fact-table star schema. a. Initial solution:

CUSTOMER CustomerID LocationType Name City State

ORDER FACTS

STORAGE

CustomerID StorageID DateKey VolumeMoved MovementCost Revenue

StorageID LocationType Name City State

STORE FACTS PlantID StorageID DateKey VolumeMoved MovementCost Revenue

PLANT PlantID LocationType Name City State

PERIOD DateKey FiscalPeriod TRANSFER FACTS PlantID1 PlantID2 DateKey VolumeMoved MovementCost Revenue VENDOR VendorID LocationType Name City State

PURCHASE FACTS PlantID VendorID DateKey VolumeMoved MovementCost Revenue

b. Using generalization to simplify solution: We could simplify this star schema substantially by re-designing the fact table to act more generically.

Essentially, the re-designed fact table contains an origin key and a destination key. For example, if a customer was to purchase some items, the origin key would be a Storage I D and the destination key would be the Customer ID. OriginRole and DestinationRole will be the name of the role for each fact related to the

371

Chapter 4

Location Object I D (e.g., customer, vendor, plant). TxnType will label the type of transaction that occurred (e.g., sale, return, etc.). Also, note the use of an Object ID as the surrogate key for the Location dimension.

LOCATION ObjectID ObjectType Name City State

3-

ORDER FACTS OriginKey (FK) DestKey (FK) DateKey (FK) OriginRole DestinationRole TxnType DollarVolume MovementCost Revenue

PERIOD DateKey FiscalPeriod

Answers to problems 9-37, 9-39, 9-40 and 9-43 using dimensional modeling tool available on erdplus.com:

Problem 9-37 STUDENT

COURSE SECTION CrsSecID (PK) CourseID SectionNumber CourseNumber CourseName Units RoomID RoomCapacity

StudentID (PK) StudentName Major

COURSE F ACTS f act table CrsSecID (F K) Prof essorID (F K) StudentID (F K) PeriodID (F K) CourseGrade

PROF ESSOR ProfessorID (PK) Prof Name Title DepartmentID DeptName

Problem 9-39

PERIOD PeriodID (PK) SemesterID Y ear

Chapter 4

372 POLICY

INSURED PARTY

PolicyID (PK) Ty pe

InsPartyID (PK) InsParty Name

POLICY F ACTS f act table COVERAGE ITEM Cov erageKey (PK) Description

InsParty ID (F K) Cov erageKey (F K) AgentID (F K) Policy ID (F K) DateKey (F K) Policy Premium Deductible NoOf Trans

AGENT

PERIOD

AgentID (PK) AgentName

DateKey (PK) F iscalPeriod

Problem 9-40 POLICY

INSURED PARTY

PolicyID (PK) Ty pe

InsPartyID (PK) InsParty Name

POLICY F ACTS f act table COVERAGE ITEM Cov erageKey (PK) Description

AGENT AgentID (PK) AgentName

Problem 9-43 – initial solution

InsParty ID (F K) Cov erageKey (F K) AgentID (F K) Policy ID (F K) DateKey (F K) ClaimID (F K) Policy Premium Deductible ClaimTotal

CLAIM ClaimID (PK) ClaimDesc ClaimTy pe

PERIOD DateKey (PK) F iscalPeriod

373

Chapter 4 PeriodDimension

DateKey (PK) F iscalPeriod

CustomerDimension CustomerID (PK) LocationTy pe Name City State

ORDER F ACTS f act table DateKey (F K) CustomerID (F K) StorageID (F K) VolumeMov ed Mov ementCost Rev enue

StorageDimension StorageID (PK) LocationTy pe Name City State

STORE f act table DateKey (F K) PlantID1 (F K) StorageID (F K) VolumeMov ed Mov ementCost Rev enue

Plant2Dimension PlantID2 (PK) Location_Ty pe Name City State

TRANSF ER f act table

VendorDimension VendorID (PK) Location_Ty pe Name City State

DateKey (F K) PlantID1 (F K) PlantID2 (F K) VolumeMov ed Mov ementCost Rev enue

Plant1Dimension PlantID1 (PK) LocationTy pe Name City State

PURCHASE f act table DateKey (F K) VendorID (F K) PlantID1 (F K) VolumeMov ed Mov ementCost Rev enue

Problem 9-43 – simplified solution LocationDimension Obj ectID (PK) ObjectTy pe Name City State

ORDER F ACTS f act table ObjectID (F K) DateKey (F K) Rev enue Mov ementCost DollarVolume TxnTy pe DestinationRole OriginRole DestKey (PK,F K) OriginKey (PK,F K)

PeriodDimension DateKey (PK) F iscalPeriod

Usefulness of the ERDPlus dimensional modeling tool: Student answers will vary due to differences in experience, use of other tools, and personal preferences. A sample answer is presented below.

This modeling tool is useful and easy to use; it is very intuitive. There is a simple Help file that explains the interface and functions of the program. There were a few issues encountered that could not be surmounted: (1) Only one relationship between a dimension table and the fact table can be drawn; the tool will not permit multiple relationships. (2) There did not appear to be a way to adjust the size of the tables so that longer names could be used for table names; the tool just cuts off the display of longer named tables. (3) Attribute names were automatically placed in alphabetical order; there did not appear to be a way to place them in a designer-preferred order. Drawing tools for other diagrams (e.g., Visio, Smart Draw) now seem to

Chapter 4

374

come loaded with many sample or standard templates; it would be nice if this tool could also have standard templates for such schemas.

3 - PVFC data mart a. Multidimensional schema: Because location is a hierarchy on Customer, it is best to snowflake Location off Customer with a helper table, though Location itself is a hierarchy (location within location). The approach in Figure 9-16 is not sufficient and a solution similar to that shown in Figure 9-17a is necessary.

PERIOD DayID FullDate WeekdayFlag LastDayOfMonthFlag

CUSTOMER CustomerID CustomerName CustomerSize City State

SALESPERSON

SALES FACTS DayID SalespersonID CustomerID ProductID LocationID DollarSales

SalespersonID YearsWithPVFC SalespersonName SupervisorRating

PRODUCT ProductID Category Weight YrReleasedMkt

Helper Table

LOCATION

LocationID CustomerID Depth from parent Lowest flag Topmost flag

LocationID AverageIncome PopSize NbrRetailers

b. In order to keep the history of the changes in Customer information, the model must be adjusted to store date elements in the Customer, helper (even the hierarchy could change over time), and location tables.

The chapter covers several methods for handling slowly changing dimensions. The preferred approach is to expand the P K of the Customer and Location dimension tables, and probably add one non-key attribute.

The new P K would become the original surrogate key plus the Date/Time Stamp for when the change reflected by the values in the row of the dimension table occurred. The new non-key could be the date when the row is no longer true (end date). End date would be null or some very large value for the current row.

The fact table still has just the original surrogate keys. The Period P K in the fact table is used to figure out

375

Chapter 4

which row of the Customer (or Location) table is relevant for that fact (i.e., the Period falls between the start and end dates of the relevant associated Customer row). The new date key in Customer would serve the same purpose as part of the foreign key in Location for linking a customer to changes in characteristics of its location.

PERIOD DayID FullDate WeekdayFlag LastDayOfMonthFlag

CUSTOMER CustomerID StartDateTime EndDateTime CustomerName CustomerSize City State

SALESPERSON

SALES FACTS DayID SalespersonID CustomerID ProductID LocationID DollarSales

SalespersonID YearsWithPVFC SalespersonName SupervisorRating

PRODUCT ProductID Category Weight YrReleasedMkt

Helper Table

LOCATION

LocationID CustomerID StartDateTime EndDateTime Depth from parent Lowest flag Topmost flag

LocationID StartDateTime EndDateTime AverageIncome PopSize NbrRetailers

c. Two possible solutions are provided for the additional requirement of hierarchies of Categories.

The first possible solution is non-standard for a dimensional model though somewhat simpler in design.

However, this design will cause more complex SQL coding for management requested summaries.

Chapter 4

PERIOD DayID FullDate WeekdayFlag LastDayOfMonthFlag

CUSTOMER CustomerID StartDateTime EndDateTime CustomerName CustomerSize City State

Helper Table LocationID CustomerID StartDateTime EndDateTime Depth from parent Lowest flag Topmost flag

376

SALESPERSON

SALES FACTS DayID SalespersonID CustomerID ProductID LocationID CategoryID DollarSales

LOCATION LocationID StartDateTime EndDateTime AverageIncome PopSize NbrRetailers

SalespersonID YearsWithPVFC SalespersonName SupervisorRating

PRODUCT ProductID CategoryID Weight YrReleasedMkt

CATEGORY CategoryID

377

Chapter 4

The second possible solution is based upon the helper table concept shown in Figure 9-17 in the chapter. This design is the normal dimensional model approach.

PERIOD DayID FullDate WeekdayFlag LastDayOfMonthFlag

CUSTOMER CustomerID StartDateTime EndDateTime CustomerName CustomerSize City State

SALESPERSON

SALES FACTS DayID SalespersonID CustomerID ProductID LocationID CategoryID DollarSales

SalespersonID YearsWithPVFC SalespersonName SupervisorRating

PRODUCT ProductID CategoryID Weight YrReleasedMkt

Helper/Bridge Table Helper Table LocationID CustomerID StartDateTime EndDateTime Depth from parent Lowest flag Topmost flag

LOCATION LocationID StartDateTime EndDateTime AverageIncome PopSize NbrRetailers

ProductID CategoryID Depth from parent Lowest flag Topmost flag

CATEGORY CategoryID

3 - Star schema for Fitchwood Insurance: a. The time dimension is handled with the Date Dimension table, which includes a surrogate key, and attributes of DayOfWeek, Day, Month, Year, Qtr, and WeekdayFlag. b. The multivalued attribute of customer address is handled in this schema with a slowly changing dimension (SCD) element of a start date as part of the surrogate key for the customer dimension table.

Chapter 4

378

c. Territory is snowflaked off of Agent. d. TransactionID indicates whether the transaction is initial commission, monthly commission, write policy, or discontinue policy.

DATE

SALES FACT

DateKey DayOfWeek Day Month Year Qtr WeekdayFlag

DateKey AgentID CustomerID PolicyID TransactionID CommissionValue

TRANSACTION TransactionID TransactionDescription

AGENT CUSTOMER CustomerID StartDate EndDate CustomerName Street City State ZipCode

AgentID AgentName DateOfHire TerritoryID

POLICY PolicyID Type FaceValue InitComm InForce EffectiveDate

TERRITORY TerritoryID LastRedistrict

ZIPCODE TerritoryID ZipCode

3 - Is further snowflaking required for the Fitchwood solution in question 9-46?

The answer to question 9-46 handles the changing customer address as a slowly changing dimension (SCD), thus there is no reason to snowflake to normalize further for the slowly changing dimension.

379

3-

Chapter 4

Revision of Exercise 9-45 and 9-46 to address the issue of agents changing territories over time.

The solution uses a start date as part of the surrogate key for the agent dimension table to design for this slowly changing dimension (S CD).

DATE

SALES FACT

DateKey DayOfWeek Day Month Year Qtr WeekdayFlag

DateKey AgentID CustomerID PolicyID TransactionID CommissionValue

TRANSACTION TransactionID TransactionDescription

AGENT AgentID AgentName DateOfHire TerritoryID

CUSTOMER CustomerID StartDate EndDate CustomerName Street City State ZipCode

POLICY PolicyID Type FaceValue InitComm InForce EffectiveDate

TERRITORY TerritoryID LastRedistrict

ZIPCODE TerritoryID ZipCode

3-

Revision of Exercise 9-48 to address the issue of customers having relationships with other customers (e.g., spouse, etc.).

The solution uses a helper table as shown in Figure 9-17 to accommodate the relationships in the new design.

Chapter 4

DATE

SALES FACT

DateKey DayOfWeek Day Month Year Qtr WeekdayFlag

DateKey AgentID CustomerID PolicyID TransactionID CommissionValue

380

TRANSACTION TransactionID TransactionDescription

AGENT AgentID StartDate EndDate AgentName DateOfHire TerritoryID

CustHierarchy Helper ParentCustKey (PK,FK) SubCustKey (PK,FK) DepthFromParent LowestFlag TopmostFlag

POLICY PolicyID Type FaceValue InitComm InForce EffectiveDate

TERRITORY TerritoryID LastRedistrict

CUSTOMER CustomerID StartDate EndDate CustomerName Street City State ZipCode

ZIPCODE TerritoryID ZipCode

3 - Fitchwood extraction process: Based upon the description of the case study, the extraction would have to be done on a weekly basis. The extraction would be done after the backup of the system on Friday nights. Essentially, the flat files would be exported to comma-delimited A S C II files containing only the information needed for the E R D in Figure 9-21. These A S C I I files then would be transferred via F T P to the Unix system. Once this is done, they could then be used to load an initial set of tables using S Q L Loader. From this set of tables, the star schema could be populated. Regarding incremental versus static extract, it is difficult to determine without knowing the volume of data. However, based on my experience with legacy systems and the inconsistencies in such a system, it might be best to perform a static extract each weekend because data that you would not expect to change might.

3 - Data pollution/cleansing problems in the Fitchwood OLTP system data?

Most of the data pollution problems mentioned in the chapter could occur with this data set. The most likely concerns are missing and duplicate data as well as inconsistencies (For example, different P Ks for the same policies or different hire dates for different agents that might be legitimate because they were ―hired‖ on different dates to work in different product lines). It is also possible that different systems have different

381

Chapter 4

rules for creating computed values (for example, different insurance products might have different rules for using face value and commissions to calculate the amount paid agents). Territories might have different geographical boundaries across the source systems. Even more issues are possible.

3 - Recommended data scrubbing tool for Fitchwood?

Students will want to perform a search using a search engine such as Google to obtain information about tools. Websites for organizations such as the Data Warehousing Institute and journals such as D M Review and Intelligent Enterprise also often have materials about vendors related to the topics addressed by these organizations.

3 - Data transformations for Fitchwood?

Record-level selection functions would have to be performed as part of the extraction process. Most of the aggregation would be done through queries to the star schema. If Fitchwood operates in several countries, language and currency conversions will be necessary; currency conversions are necessary to transform all currency values into one monetary unit. Some of the data pollution issues raised in Problem and Exercise 2 suggest some transformations that are needed, for example, to get all agents into a consistent view of territories. Some attributes, like LastRedistrict, may have to be computed from raw transactional data in the source systems.

3 - Possible change to extraction process?

This new information would change the way that we extract and load data only if we use an incremental extract. In this case, we might want to perform a complete extract when the policy table changes yearly. If commission is treated as a dimensional value (not a fact-table value), then it will have to be managed as a slowly changing dimension (SCD) using one of the schemes outlined in the chapter on data warehousing.

Note: For questions 9-55—9-62, make sure that you and your students use the db_samwh database through the Teradata S QL Assistant service available at University of Arkansas Walton College Enterprise Systems, which can be accessed through Teradata University for Academics.

Note: As of this writing, it appears to be likely that the db_samwh database will not anymore be available through Walton Enterprise Systems in the near future. Before assigning these questions, please verify the availability of the database.

3 - Teradata University Sales Analysis Data Mart Module: Modeling hierarchies?

The d b_samwh appears to model hierarchies by nesting the dimensions, as described in the chapter. The metadata description in the user manual (and the logical and physical schema diagrams) and the SHOW TABLE commands on selected tables evidence the presence of foreign keys that point back to separate dimension tables in the data. Some of the hierarchies that are evident include: Account (Account – Company – Industry), Product (Product – Product Group), and Sales Organization (Sales Rep – District – Region).

Chapter 4

382

3 - Teradata University Sales Analysis Data Mart Module: Dimension Data?

Based on a review of the metadata description in the user manual, and selected queries upon physical tables, it appears that dimension data are maintained for the Opportunity section of the data mart/data warehouse by the presence of Open, Close dates for Opportunity. It appears that this slowly changing dimension data is being maintained as described in the chapter.

3-

Teradata University Sales Analysis Data Mart Module: Dimension tables conformed?

Based on a review of the metadata description in the user manual, and selected queries upon physical tables, it appears that the dimension table data is conformed as the same surrogate primary keys are used throughout the schema.

3-

Teradata University Sales Analysis Data Mart Module: Screen scraping the SQL? Most B I software generates S Q L to retrieve the data from a database to do the analysis requested in the report or graph. S Q L may not have the output formatting commands to display the results in a most usable manner, so the B I software does this. Sometimes S Q L isn‘t capable of doing some analysis, so the B I software takes the S Q L result and manipulates it further before formatting the output. This is the typical scenario for MicroStrategy.

In other cases, when you can‘t get the B I software to produce exactly the analysis you want, you can use the generated S Q L as a starting point. You can develop a report from the B I software that is close to what you desire, ―scrape‖ the generated S Q L, modify the S Q L code with O L A P extensions, and then manually run the modified code using an S Q L engine against the same data to get the desired analysis.

To demonstrate this scenario, run the following MicroStrategy report: Shared Reports → Sales Performance Analysis → Quarterly Revenue Trend by Sales Region → 2005 → Run Report

383

Chapter 4

Save the resultant screen display to a Word file, and then ―scrape‖ the query MicroStrategy generated to produce this report (include this scraped query also in the Word file); you can scrape the query with the report result on the screen by using the File menu as follows: File → Report Details SELECT

a13.SALES_REGN_ID SALES_REGN_ID, max(a13.SALES_REGN_DESC) SALES_REGN_DESC, a12.QTR_ID QTR_ID, max(a14.QTR_DESC) QTR_DESC, sum(a11.ORDER_AMT) WJXBFS1 FROM F_ORDER a11 join L_CAL_DATE a12 on (a11.ORDER_DATE = a12.DATE_ID) join L_SALES_REP a13 on (a11.SALES_REP_ID = a13.SALES_REP_ID) join L_CAL_QTR a14 on (a12.QTR_ID = a14.QTR_ID) WHERE a12.YEAR_ID in (2005) GROUP BY a13.SALES_REGN_ID, a12.QTR_ID; 3Cut and paste the query you scraped in Question 9-45 above into the query pane and then run the scraped query on S QL Assistant (implicating using the db_samwh database). The database you are using is the same one that MicroStrategy used for the Sales Force Analysis Module.

Save your query and Answer Set to the Word file.

SALES_REGN_ID

SALES_REGN_DESC

QTR_ID

QTR_DESC

W JXBFS1

3.00

Europe

20051.00

2005 Q1

650000.00

2.00

Canada

20051.00

2005 Q1

1475000.00

1.00

United States

20051.00

2005 Q1

925000.00

Then, rewrite the query to show only the United States region grouped by each quarter, not just for 2005 but for all years available, in order by quarter (you should get 6 rows in the Answer Set).

Chapter 4

384

Label the total orders by quarter with the heading TOTAL and the region id simply as I D in the display. Save your query and Answer Set to the Word file.

SELECT

a13.SALES_REGN_ID ID, max(a13.SALES_REGN_DESC) SALES_REGN_DESC, a12.QTR_ID QTR_ID, max(a14.QTR_DESC) QTR_DESC, sum(a11.ORDER_AMT) TOTAL FROM F_ORDER a11 join L_CAL_DATE a12 on (a11.ORDER_DATE = a12.DATE_ID) join L_SALES_REP a13 on (a11.SALES_REP_ID = a13.SALES_REP_ID) join L_CAL_QTR a14 on (a12.QTR_ID = a14.QTR_ID) WHERE a13.SALES_REGN_ID in (1) GROUP BY a13.SALES_REGN_ID, a12.QTR_ID ORDER BY a12.QTR_ID; ID SALES_REGN_DESC QTR_ID QTR_DESC TOTAL 1.00 United States 20034.00 2003 Q4 2150000.00 1.00 United States 20041.00 2004 Q1 2325000.00 1.00 United States 20042.00 2004 Q2 2525000.00 1.00 United States 20043.00 2004 Q3 2725000.00 1.00 United States 20044.00 2004 Q4 2925000.00 1.00 United States 20051.00 2005 Q1 925000.00 3-

Using the MDIFF “ordered analytical function” in Teradata SQL (see Functions and Operators manual) show the differences (label the difference CHANGE) in TOTAL from quarter to quarter.

Hint: you will likely create a derived table based on your query above, similar to what is shown in examples in the Functions and Operators manual; when you do so you will need to give the derived table an alias name and then use that alias name in the outer select statement when you ask to display the results of the query. Save your query and Answer Set to the Word file.

By the way, M DIFF is not standard S QL; this is an analytical function peculiar to Teradata. Every DBMS that supports B I/OLAP actions will have some proprietary S QL extensions. In addition to MDIFF, Teradata has analytical functions such as cumulative frequency (C SUM), identifying position in a sequence (RANK), moving average (MAVG), and identifying the n-tile (e.g., percentile, decile, quartile, etc.) position (QUANTILE); some of these functions are proprietary to Teradata, but some are now standard S QL (e.g., RANK).

SELECT

T1.ID, T1.SALES_REGN_DESC, T1.QTR_ID, T1.QTR_DESC,

385

Chapter 4

T1.TOTAL, MDIFF(T1.TOTAL,1,T1.QTR_ID) CHANGE FROM (SELECT a13.SALES_REGN_ID ID, max(a13.SALES_REGN_DESC) SALES_REGN_DESC, a12.QTR_ID QTR_ID, max(a14.QTR_DESC) QTR_DESC, sum(a11.ORDER_AMT) TOTAL FROM F_ORDER a11 join L_CAL_DATE a12 on (a11.ORDER_DATE = a12.DATE_ID) join L_SALES_REP a13 on (a11.SALES_REP_ID = a13.SALES_REP_ID) join L_CAL_QTR a14 on (a12.QTR_ID = a14.QTR_ID) WHERE a13.SALES_REGN_ID in (1) GROUP BY a13.SALES_REGN_ID, a12.QTR_ID) as T1 ORDER BY T1.QTR_ID; ID SALES_REGN_DESC QTR_ID QTR_DESC TOTAL CHANGE 1.00 United States 20034.00 2003 Q4 2150000.00 ?

1.00 United States 20041.00 2004 Q1 2325000.00 175000.00 1.00 United States 20042.00 2004 Q2 2525000.00 200000.00 1.00 United States 20043.00 2004 Q3 2725000.00 200000.00 1.00 United States 20044.00 2004 Q4 2925000.00 200000.00 1.00 United States 20051.00 2005 Q1 925000.00 −2000000.00 3For this question, you‘ll need to refer to the Data Manipulation Statements S Q L Assistant manual and the db_samwh metadata manual from MicroStrategy that you downloaded earlier.

There are many OLAP clauses now in standard S QL, and in this question you are asked to use two of these, the SAMPLE and ROLLUP clauses. SAMPLE is often used to create an extract table (flat file) of data, and then to save this sample for some further analysis (e.g., as a market research test group, as input to an analytical tool that does not support S QL, or simply to reduce the analysis time when a sample is sufficient for some [statistical] analysis). ROLLUP is used to see data summarized at different levels in a hierarchy. Most analytical databases have factual data that can be summarized along various geographical, time, product group, or other hierarchies, and along combinations of hierarchical levels. Starting on p. 124 of the db_samwh pdf document file, you‘ll see an explanation of the hierarchies present in this database, and see p.

123 for an entity-relationship diagram of the database. You can find explanations of SAMPLE and ROLLUP in the Data Manipulation Statements document you downloaded.

Chapter 4

386

Using SQL Assistant, create a sample of orders from 2004; put a randomized allocation of 10% of the rows into the sample. Include in the sample results the order id, prod id, sales rep region id, month description, and order amount. Show results in sequence by month. Run the query two times to check that the sample is actually random. Put your query and Answer Set into the Word file.

SELECT order_id, prod_id, sales_regn_id, mnth_desc, order_amt FROM f_order, l_sales_rep, l_cal_date, l_cal_mnth WHERE l_cal_date.year_id = 2004 AND f_order.order_date = l_cal_date.date_id AND l_cal_date.mnth_id = l_cal_mnth.mnth_id AND f_order.sales_rep_id = l_sales_rep.sales_rep_id SAMPLE RANDOMIZED ALLOCATION .10 ORDER BY mnth_desc; First few rows of 45 from first pass: ORDER_ID PROD_ID

SALES_REGN_ID

MNTH_DESC

ORDER_AMT

78.00

12.00

1.00

Apr 2004

75000.00

82.00

8.00

2.00

Apr 2004

75000.00

74.00

4.00

1.00

Apr 2004

40000.00

75.00

2.00

1.00

Apr 2004

125000.00

76.00

5.00

1.00

Apr 2004

50000.00

85.00

10.00

3.00

Apr 2004

25000.00

84.00

1.00

2.00

Apr 2004

150000.00

129.00

2.00

1.00

Aug 2004

50000.00

126.00

5.00

3.00

Aug 2004

40000.00

127.00

1.00

1.00

Aug 2004

125000.00

130.00

5.00

1.00

Aug 2004

75000.00

Other executions of query did produce different results.

3Now, using the raw data, not the sample, do a rollup to get total order amounts by product, sales region, and month, and all combinations including a grand total. Display the results sorted by product, region, and

387

Chapter 4

month. Put your query and the first portion of the Answer Set including all of product 1 and a few rows for product 2 into the Word file.

SELECT prod_id, sales_regn_id, mnth_desc, SUM(order_amt) FROM f_order, l_sales_rep, l_cal_date, l_cal_mnth WHERE l_cal_date.year_id = 2004 AND f_order.order_date = l_cal_date.date_id AND l_cal_date.mnth_id = l_cal_mnth.mnth_id AND f_order.sales_rep_id = l_sales_rep.sales_rep_id GROUP BY rollup (prod_id, sales_regn_id, mnth_desc) ORDER BY prod_id, sales_regn_id, mnth_desc; Partial result: PROD_ID

SALES_REGN_I D

MNTH_DESC

Sum(ORDER_AMT)

?

?

?

28270000.00

1.00

?

?

7360000.00

1.00

1.00

?

2610000.00

1.00

1.00

Apr 2004

430000.00

1.00

1.00

Aug 2004

375000.00

1.00

1.00

Feb 2004

75000.00

1.00

1.00

Jan 2004

375000.00

1.00

1.00

Jul 2004

540000.00

1.00

1.00

Jun 2004

250000.00

1.00

1.00

Mar 2004

40000.00

1.00

1.00

May 2004

95000.00

1.00

1.00

Nov 2004

200000.00

1.00

1.00

Oct 2004

230000.00

1.00

2.00

?

2320000.00

1.00

2.00

Apr 2004

275000.00

1.00

2.00

Aug 2004

225000.00

1.00

2.00

Dec 2004

440000.00

1.00

2.00

Feb 2004

325000.00

1.00

2.00

Jan 2004

95000.00

1.00

2.00

Jul 2004

175000.00

1.00

2.00

May 2004

200000.00

Chapter 4

388

PROD_ID

SALES_REGN_I D

MNTH_DESC

Sum(ORDER_AMT)

1.00

2.00

Nov 2004

30000.00

1.00

2.00

Oct 2004

405000.00

1.00

2.00

Sep 2004

150000.00

1.00

3.00

?

2430000.00

1.00

3.00

Apr 2004

250000.00

1.00

3.00

Aug 2004

155000.00

1.00

3.00

Dec 2004

200000.00

1.00

3.00

Feb 2004

200000.00

1.00

3.00

Jan 2004

150000.00

1.00

3.00

Jul 2004

100000.00

1.00

3.00

Jun 2004

250000.00

1.00

3.00

Mar 2004

200000.00

1.00

3.00

May 2004

100000.00

1.00

3.00

Nov 2004

375000.00

1.00

3.00

Oct 2004

150000.00

1.00

3.00

Sep 2004

300000.00

2.00

?

?

2120000.00

2.00

1.00

?

965000.00

2.00

1.00

Apr 2004

175000.00

Answers to Field Exercises 3-

One of two approaches can be used for this exercise: a. Arrange a field trip and interview several persons to obtain answers to the questions stated. This is the preferred approach because it enables students to obtain different perspectives concerning these questions. b. Invite one of the key participants to visit your class and make a short presentation, followed by student questions. The author used this approach in a recent class and found it reasonably effective, although the answers represented the perspective of only the one person.

389

3-

Chapter 4

These websites contain a wealth of information concerning data warehousing. You can focus the search around the following issues: a. What are some of the key data warehouse implementation issues today, and what advice do the data warehouse gurus give concerning these issues? b. What jobs have been spawned by data warehousing, and what are typical salary ranges for these jobs? c. What types of software are available to support data warehouse design, implementation, and maintenance? d. Cite several case examples of data warehouse implementations and document the following: benefits obtained, lessons learned, and pitfalls to avoid.

3-

The answers vary depending on the tools students select and the comparison criteria they use.

Chapter 10 Big Data Technologies Chapter Overview The purpose of this chapter is to give the students an introduction to the most important technologies enabling big data, with hands-on examples of Mongo DB, Pig, and Hive. We first illustrate the progression from focus on transactional data to analytics based on data warehouses and then to big data analytics, which has radically increased the volume, variety, and velocity of data to be processed.

We illustrate four types of No SQL and Hadoop as core big data technologies and discuss the differences between ―schema on write‖ and ―schema on read.‖

Chapter Objectives Specific learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: b. Provide the students with an overview of the technologies that are currently used to implement big data analytics solutions, with a specific focus on Hadoop and No SQL solutions.

Chapter 4

390

c. Establish the importance of the very close linkages between data management and analytics. d. Illustrate the difference and dependencies between traditional structured data management and the big data technologies. e. Demonstrate the opportunities created by the integration of data management and analytics technologies under the same conceptual architecture. f. Describe the four main types of No SQL technologies. g. Provide hands-on introduction to Mongo DB as an example of a No SQL technology. h. Describe the core ideas underlying MapReduce and its implementation in Hadoop. i.

Describe the key elements of the Hadoop architecture.

j.

Provide hands-on introduction to Pig and Hive as important tools in the Hadoop ecosystem.

Key Terms Analytics Big data Data lake Hadoop

HDFS Hive Internet of Things MapReduce

NoSQL Pig Blank

Blank

Classroom Ideas 1. Discuss the importance of big data through company success stories such as those described in Laskowski, 2014 (see the reference list in the book). A key point to make is that big data is not just about more data, but qualitatively different uses of data.

2. Use Table 11-1 to describe the Five Vs of Big Data. Emphasize that this is not the only way to define big data but one that is widely used and provides a useful working definition. Discuss the limitations of the Five Vs, particularly from the perspective of how this definition, in practice, changes constantly.

Point out that value and veracity are different in nature than volume, velocity, and variety in that the first two are critically important characteristics of any data management environment.

391

Chapter 4

3. Describe the philosophical difference between ―schema on write‖ (Chapters 2-9) and ―schema on read‖ (p. 449; Figure 10-2), and discuss ―schema on read‖ as one of the key elements in the use of data lakes.

4. Identify NoSQL and Hadoop as two major categories of big data technologies.

5. Based on Figure 10-3 and Table 10-2, discuss the four main types of No SQL database management systems and their primary uses. Section ―No SQL Example‖ provides examples of the most popular specific products (Redis, Mongo DB, Apache Cassandra, and Neo4j). Use the Web sites of these products to provide the students with use examples. This could also be done as an in-class exercise.

6. Use Figures 10-4 and 10-5 to illustrate the nature of Mongo DB documents and collections.

7. Demonstrate MongoDB queries using the example illustrated in Figures 10-6 to 10-12.

8. An important point to make is that No SQL technologies can be seen as an exciting opportunity for database professionals, as discussed on p. 458.

9. Use Figures 10-13 and 10-14 as a foundation to discuss the overall goals and architecture of Hadoop. It is essential that the students understand the breadth of technologies that need to be brought together to make Hadoop genuinely useful.

10. Use P&E 10-23 as an in-class exercise to illustrate the way Hadoop works.

11. Bring the technology discussion to a close using the Teradata unified data architecture example (Figure 10-33).

Answers to Review Questions 3 - Define the following key terms: a. Hadoop. An open source implementation fromework of the MapReduce algorithm. b. MapReduce. An algorithm for massively parallel processing of various computing tasks published by two Google employees, Dean and Ghemawat, in 2004. c. HDFS. Hadoop Distributed File System. A file system designed for managing a large number of potentially very large files in a distributed environment.

Chapter 4

392

d. NoSQL (Not Only SQL). A set of recently introduced data storage, management, and retrieval technologies that are not based on the relational model. e. Pig. A tool that integrates a scripting language and an execution environment intended to simplify the use of MapReduce.

3 - Match terms to appropriate definitions. c

Hive

a

big data

d

data lake

b

Pig

e

analytics

3 - Compare and contrast the following terms: a. Data lake; data warehouse. Data lake is an unstructured collection of heterogeneous data that has been stored to wait for possible future use, whereas a data warehouse is a well-designed, carefully structured collection of typically alphanumeric data that is designed for specific data retrieval and analysis tasks. b. Pig; Hive. Pig and Hive are both technologies intended to make the use of MapReduce easier.

Pig uses its own scripting language (PigLatin) that allow users to describe task execution sequences at a higher level of abstraction than directly coding the tasks in Java and MapReduce libraries. Hive allows the management and querying of large data sets using an S QL-like language (HiveQL) that provides a declarative interface for managing data stored in Hadoop. c. Volume; Velocity Volume refers to the total amount of data that need to be managed in a storage ecosystem whereas velocity denotes the speed at which to-be-processed data arrives into the system. If the system does not store most of the data that arrives to be processed, or aggregates it immediately, a system can have high velocity without high storage volumes. On the other hand, even if a system receives data at a comparatively slow rate, it can still over time accumulate very high volumes. d. NoSQL;SQL. NoSQL and SQL are not directly comparable. S QL is a declarative data

393

Chapter 4

manipulation and definition language, whereas No SQL refers to a number of non-relational data management and storage technologies (typically in the big data context).

3 - The five Vs of big data: a. Volume b. Velocity c. Variety d. Veracity e. Value 3 - A major problem in defining big data with the five V s ersu

Particularly high volume and high velocity are relative concepts: today‘s high volume and high velocity will be average tomorrow and trivial soon afterwards. This is a problem related to the big data concept, too: technology develops so fast that quantity-related specifications are very quickly obsolete.

3 - Two main categories of technologies used to implement big data solutions: The two main categories of technologies used to implement big data solutions are a) No S Q L database management systems and b) approaches based on Hadoop and related algorithms.

3 - “Schema on write” v s “schema on read” ersu

―Schema on write‖ refers to data management approaches in which data is organized using a predefined structure (schema) that is based on expected uses of the data. ―Schema on read‖ does not, however, involve a predefined schema, but rather the structure is discovered at the time of the use of the data.

3 - Four main types of NoSQL database management systems a. Key-value stores. These are systems that are based on a simple idea of storing data using a set of key values that provide access to a specific collection of data. These systems do not have any understanding of the internal structure of the data that is retrieved. b. Document stores. These systems have an internal structure (often specified with the J SON language) that specifies a label and an attribute value for each of the components of collection of data (document) associated with a key. c. Wide-column stores. Also called extensible record stores, they store data in rows and columns, allowing each row to have a different column structure (there is no shared schema).

Chapter 4

394

d. Graph-oriented databases. They have been designed for environments in which it is very important to maintain information regarding the relationships between the data items. Data is stored in nodes, which are connected to each other; these connections represent relationships between real-world instances.

3 - Primary difference between key-value stores and document stores The primary difference between key-value stores and document stores is that document stores specify an internal structure for the material being stored using a language such as J S O N, whereas in key-value stores there is no database level specification of internal structure of the data.

3 - Primary role of JSON The primary role of J S O N is to provide a succinct mechanism for specifying an internal structure for a collection of data items. J S O N makes it possible for a system to store metadata together with the data itself and allow internal structures of the collections vary.

3 - Capabilities of NoSQL beyond those of SQL No S Q L solutions enable the use of commodity hardware to store highly heterogeneous data that has not been structured based on a predefined schema.

3 - The relationship between Hadoop and MapReduce MapReduce is an algorithm for enabling massively parallel processing of heterogeneous data. Hadoop and related technologies provide an open source implementation of MapReduce.

3 - Importance of massively parallel processing for big data Massively parallel processing (M P P) implemented with commodity hardware enables (at a reasonable price point) many of the core characteristics of systems that enable big data: high volumes, heterogeneity of data, and the fast speed at which the data needs to be processed.

3 - Main components of the Hadoop architecture The main components of the Hadoop architecture are H D F S (Hadoop Distributed File System), Y A R N (Yet Another Resource Allocator), and the MapReduce algorithm.

3 - The role of HDFS in the Hadoop architecture H D F S (Hadoop File System) is the foundation of the data management infrastructure of Hadoop. It breaks data into small chunks called blocks and stores them at various nodes across the Hadoop cluster.

3 - Core principle of the MapReduce algorithm The MapReduce algorithm is to divide the computing task so that multiple nodes of a computing cluster can work on the same problem at the same time. Each node works on its own data, requiring only the requests and responses to be transmitted over the network.

395

Chapter 4

3 - The common purpose of Pig and Hive The common purpose of Pig and Hive is to simplify the specification of MapReduce tasks, providing a higher level language instead of having to code the MapReduce tasks directly in Java and MapReduce libraries.

Answers to Problems and Exercises 3 - Comparison of JSON and XML J S ON is a significantly more compact representation of essentially the same content and thus, in contexts in which the amount used for data storage matters, J S O N is clearly better. In addition, processing J S O N is somewhat faster in certain contexts.

3 - NoSQL data formats Blank

Data values Key-value store Document store Wide-column store

Prod_1; 1; Zoom X; 10 Prod_1; 1; Zoom X; 10.00 Prod_1; 1; Zoom X; 10

Graph database

Prod_1; 1; Zoom X; 10; Prodline_1

Data labels (metadata embedded in data) number; name; price number; name; price Desc; number; name; Value; price number; name; price; member of

3 - Removing awards from query: Change the subset of fields box to the following: {―_id‖:0, ―contribs‖: 0, ―awards‖:0} 3 - Changing order of display of results: Change the sort order box to the following: {―name.last‖:-1} 3 - Identifying a weakness in a Hadoop architecture There is only one copy of Job Tracker and Name Node, both forming a single point of failure. In the latest versions of Hadoop this has been addressed by replication.

3 - MapReduce algorithm a. Input → Input‘ divides the computing task into multiple components that can be performed simultaneously.

Chapter 4

396

b. Shuffle collects values associated with a specific key from all the separate tasks and brings them all together. c. Reduce performs the mathematical operations that are needed to integrate the results from the multiple simultaneous computational operations performed earlier.

3 - Selecting suitable NoSQL technology See answers to Review Question 11-8 to see the justification. a. Wide-column (or extensible record) store b. Key-value store c. Graph database d. Document store 3 - Storing output in tab-delimited format: Change the last line to the following: STORE data1 INTO ‗/user/Group1/MDMSample1‘ USING PigStorage(‗\t‘); 3 - Changing the fields included in the answer set: Change the last but line as follows: projected_filtered_data1 = FOREACH filtered_data1 GENERATE age, income; 3 - Writing a Hive script: SELECT age, AVG(salary) as avgincome FROM customer GROUP BY age;

Chapter 11 Analytics and Its Implications Chapter Overview

397

Chapter 4

The purpose of this chapter is to give the students an introduction to analytics and the most important categories of technologies enabling modern analytics. The chapter also provides an overview of the opportunities, implications, and potential consequences of analytics driven by data warehousing and big data. The description of analytics is structured around the distinction between descriptive, prescriptive, and predictive analytics and the different technologies and methodologies that are used to support each of these subtypes of analytics. The chapter ends with a discussion on the areas of human life that widespread use of analytics is affecting and the implications and potential consequences of big data and analytics.

Chapter Objectives Specific learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: k. Discuss the differences and dependencies between descriptive, predictive, and prescriptive analytics. l.

Help the students understand the concept of online analytical processing (O LAP) and its various forms.

m. Illustrate the importance of data visualization and dashboards to enable effective use of data. n. Describe the role of data mining in predictive analytics and demonstrate how integrated tools such as Knime have made predictive analytics easier to access and use. o. Describe four tool environments that expert analysts use for analytics tasks: Analytical and O LAP functions of SQL, R, Python, and Apache Spark. p. Illustrate the widespread impact big data and analytics are having on individuals, organizations, and the society as a whole. q. Emphasize the importance of understanding the implications and potential consequences of the use of analytical technologies and their integration with business systems.

Key Terms

Chapter 4

Analytics Apache Spark Business intelligence Data mining Descriptive analytics

Multidimensional OLAP (MOLAP) Online analytical processing (OLAP) Predictive analytics Prescriptive analytics

398

Python R Relational OLAP (ROLAP) Text mining

Classroom Ideas 1. Discuss analytics as one of the most important reasons why a solid data management architecture (including transactional databases, data warehouses, and big data solutions) is needed. Highlight the transformation of analytics from D SS through business intelligence to current analytics. The Chen et al. (2012) categorization of difference generations of business intelligence and analytics (pp. 476 and Figure 11-2) is also a good basis for a conversation.

2. Focus on the differences between descriptive, predictive, and prescriptive analytics (Table 11-1 and p. 475-476).

3. This is a topic area that offers excellent opportunities for the use of various tools and case studies. Of the tools, we would recommend exploring the possibilities offered, for example, by Tableau, MicroStrategy, and S AS Visual Analytics. Both offer academic versions and example material directly on the product sites and through various repositories.

4. Depending on your own preference, available time, and your selected priorities regarding technology use, you can either use the resources discussed above for in-class demonstrations or as student inclass exercises.

5. In the same way but at a level requiring higher technical sophistication, R (see https://cran.rproject.org) and Python (see, for example, Comprehensive learning path for Data Science in Python at Analytics Vidhya; https://www.analyticsvidhya.com), with their libraries, offer plenty of opportunities for demonstrations of the power of these sophisticated language ecosystems with analytical libraries.

If you are familiar with these environments from other contexts, they are certainly worth including in your plans for the class.

6. https://spark.apache.org/examples.html offers simple examples of the use of the Apache Spark environment that can be used for demonstration purposes.

399

Chapter 4

7. Include a structured conversation regarding the impact of big data and analytics, both in terms of areas of life affected and implications and potential consequences. This is an excellent place to cover many of the moral and ethical issues that emerge from the widespread use of analytics-driven technologies.

Answers to Review Questions 3-

Define the following key terms: a. Data mining refers to knowledge discovery using a sophisticated blend of techniques from traditional statistics, artificial intelligence, and computer graphics. b. Online analytical processing or OLAP refers to the use of a set of graphical tools that provides users with multidimensional views of their data and allows them to analyze the data using simple windowing techniques. c. Business intelligence. A set of methodologies, processes, architectures, and technologies that transform raw data into meaningful and useful information. d. Predictive analytics. Applies statistical and computational methods and models to data regarding past and current events to predict what might happen in the future. e. Apache Spark. A comprehensive, open source analytics environment for large and highly heterogeneous data sets that provides capabilities from analytics to the maintenance of broadly distributed data storage systems.

3-

Match terms to appropriate definitions. b

text mining

a

data mining

f

descriptive analytics

d

analytics

c

predictive analytics

e

prescriptive analytics

Chapter 4

3-

400

Compare and contrast the following terms: a. Data mining; text mining. Data mining refers to the overall category of approaches that allow knowledge discovery from large quantities of (potentially heterogeneous) data using methods of statistics, mathematics, and computer science. Text mining is specifically related to knowledge discovery based on qualitative textual data. b. ROLAP; MOLAP. ROLAP and MOLAP are both categories of Online analytical processing (O LA P). The difference between them is that R OLAP (Relational OLAP) views the data storage system as a traditional relational database whereas M OLAP (Multidimensional O LAP) tools load data into an intermediate structure, usually a three- or higher-dimensional array. c. R;Python. Both R and Python are open source programming languages and software environments that are widely used as the foundation for an analytics toolkit. The foundation of R is in the world of statistics, and it is often seen primarily as a statistical package, but it is also an interpreted programming language. R would not be your first choice as a general-purpose language. Python, however, has been designed to be and is commonly used as a generalpurpose language. Its widespread use for statistics and analytics is a later development, based on Python‘s highly extensible design that has allowed the development of numerous analytics libraries providing both statistical and mathematical capabilities (such as Pandas, Statsmodels, Mlpy, and NumPy).

3-

Moving from DSS to analytics The first category of software solutions that was explicitly designed to support specific decision tasks consisted of Decision Support Systems, systems that utilized data provided to them by transaction processing systems and management information systems to support structured business decisions. From D S S grew business intelligence, a much broader concept that covers all the methodologies, processes, architectures, and technologies that transform raw data into meaningful and useful information. In the business intelligence context, analytics referred specifically to the process of analyzing data. Gradually, analytics became the new umbrella term, including everything that business intelligence was and adding to that, both in breadth and depth. For example, analytics at this point typically includes descriptive, predictive, and prescriptive analytics based on highly heterogeneous sets of data.

3-

Differences between descriptive, predictive, and prescriptive analytics The focus of descriptive analytics is in the past – descriptive analytics provides a picture (sometimes created with highly sophisticated tools) of past behavior, whereas both predictive and prescriptive analytics deal with the future. As its name states, predictive analytics provides forecasts regarding the future based on

401

Chapter 4

analysis of past behavior. Prescriptive analytics provides task-specific guidance that, if implemented as decisions, will take the organization towards specific goals.

3-

The impact of Internet of Things on big data and analytics The total amount of data generated by devices connected to the Internet and other networks will increase significantly once a very large number of devices and machinery equipped with various sensors will be connected to these networks. This data is, however, useless by itself – it becomes useful only when it is processed and analyzed in its proper context, and often the data is the more useful the faster it can be analyzed after it has been generated. Thus, modern analytics environments and their data processing capabilities are essential enablers of the benefits of IoT.

3-

OLAP and descriptive analytics O L A P (Online Analytic Processing) is a specific form of descriptive analytics that offers a multidimensional view of data and drill-down capabilities that allow a focused look at specific details when necessary.

3-

Three types of operations that can be performed with OLAP tools a. Slicing a data cube to produce a simple two-dimensional view of data b. Drilling down to a lower level of abstraction c. Data visualization.

Chapter 4

3-

402

Compare and contrast R and Python The key difference between R and Python is reflected in their origins: R can, in many ways, be seen as an implementation of S, a statistical computing language originally designed at Bell Laboratories, and it has clearly been designed primarily with the statistical community in mind. Python, however, was designed as a general-purpose language with its roots in the Dutch ABC language. R has more statistical capabilities built into the core language whereas Python‘s analytics-related capabilities are primarily based on several extensive extension libraries. (See also the answer to 11-3 c).

3-

Differences between Apache Spark and Hadoop: Both Apache Spark and Hadoop are software environments for dealing with very large data sets, but they serve different purposes: Hadoop provides an infrastructure for managing highly distributed data using inexpensive commodity servers (Hadoop Distributed File System or H DFS) and an implementation of the MapReduce algorithm, but Spark focuses on very fast processing distributed collections of data. Both could be used independently but they work very well together, with Spark providing very fast in-memory data processing capabilities for various Hadoop workloads.

3-

Role of dashboards in descriptive analytics Dashboards provide high-level summaries that are particularly good for non-operationally focused, organizationally high-level users. For example, a high-level dashboard could include indicators for operational efficiency, sales performance, profitability at the level of high-level product categories, core financial measures, etc.

3-

Skills required for predictive modeling Performing high-level predictive modeling requires a broad variety of skills, including an in-depth understanding of the organizational domain to be modeled, excellent communication skills for interaction with the key organizational actors whose needs are being addressed, strong statistical and computational skills for specifying and implementing the models, and general analytical skills for interpreting the results.

3-

Commonly used data mining techniques 1. Affinity 2. Case-based reasoning 3. Clustering and signal processing 4. Decision-tree induction

403

Chapter 4

5. Fractals 6. Neural nets 7. Regression 8. Rule discovery 9. Sequence association 3-

Purposes of data mining Data mining can be used for a variety of purposes, which can be divided into three main categories: o Explanatory – for explaining a phenomenon that is easy to observe but difficult to understand without further analysis. o Confirmatory – for confirming a hypothesis regarding an important phenomenon. o Exploratory – finding relationships and associations in the data that were not known earlier.

3-

Ways in which prescriptive analytics is dependent on descriptive and predictive analytics Prescriptive analytics cannot be performed without the historical perspective that descriptive analytics provides and the understanding of the dependencies between key variables that is provided through predictive analysis.

3-

In-memory database management systems In-memory database management systems are D B M S that maintain the data they operate on entirely in the primary memory of the database server. This architecture allows significantly faster processing speeds, particularly in applications that require random (instead of sequential) access.

3-

In-database analytics In-database analytics involves the integration of analytical tools with the data management infrastructure (e.g., in form of analytical functions built into a D B M S) in a way that takes away the need to move data to a separate system/systems for analytics.

3-

Categories of human activity affected by big data and analytics a. Business b. Government and politics c. Science and technology

Chapter 4

404

d. Smart health and well-being e. Security and public safety 3-

Implications of big data analytics and decision making a. Personal privacy v s collective benefits ersu

b. Ownership and access c. Quality and reuse of data and algorithms d. Transparency and validation e. Changing nature of work f. Demands for workforce capabilities and education

Answers to Problems and Exercises 3-

Selecting the proper type of analytics a. Prescriptive analytics. The key phrase here is ―automated support‖ – prescriptive analytics provides results that are guiding an organization‘s (or individual‘s) actions in a specific way. b. Descriptive analytics. This is a typical historical analysis situation. c. Predictive analytics. Here the focus is on the future and the task is predictive in nature. d. Descriptive analytics. This is historical data provided using typical analytical tools.

3-

Components of an integrated data architecture a. Integrated discovery platform. The discovery platform allows the type of exploration specified in the task description. b. Data platform. The data platform provides a set of mechanisms for storing data for future needs (that might not be very well known or understood).

405

Chapter 4

c. Integrated data warehouse. d. Data platform.

3-

Fitchwood: Drill-down online reporting The use of an O L A P tool is recommended. The O L A P cube could be built from the existing star schema.

Specific scripts would have to be written in order to build the cube to accommodate drill-down capabilities.

It would also be necessary to store aggregate data.

3-

Fitchwood: Visualization There are number of options for visualization that could be immediately useful. Many of them are related to representing data in the geographic context. For example, graphical representations could be used to show any of the following data points of interest: o Number of agents per territory o Number of policies sold per territory o Total revenue from policies sold per territory o The amount of commission earned per territory o The number of customers per territory o The number of customers per city / zip code These visualizations become more interesting and more useful if a time dimension is added to them, either in the form of a visualized time series or comparisons over specific time periods.

Obviously, this could be developed towards much more sophisticated analyses that would require a deeper understanding of the business and its essential questions. For example, we could use visualization to understand the phenomena leading to customer churn (customers leaving Fitchwood and buying insurance from other companies).

3-

Fitchwood: Dashboard prototype Student responses will vary significantly.

3-

Fitchwood: Data mining There is a vast amount of data mining that could be done using this case study. For example, what age groups purchase which policies? What age group of customers is most likely to keep a policy in force?

What states have the best sales of policies, and how does this compare with the age demographics for the customers in that state?

The exercise of researching data-mining tools is left to the student; answers will vary depending on depth of research and searching expertise of individual students.

Chapter 4

3-

406

Fitchwood: Text mining One possible area for text mining in an insurance context could be fraud detection based on an analysis of insurance claims and specifically any qualitative descriptions of the losses associated with them. Also, text mining could be used to understand conditions at company contexts that are particularly accident-prone (related to commercial insurance), based on written descriptions to the context for which specific policies have been written.

This area is discussed more extensively at http://www.meaningcloud.com/blog/text_mining_insurance_industry/.

3-

Fitchwood: Big data technologies Fitchwood might want to start to store data that they don‘t currently keep and use a Hadoop architecture for maintaining a data lake. For example, they might want to record and automatically transcribe all phone interactions with customers and use that material to identify customers whom they are at risk of losing.

They might also want to consider capturing and keeping all data regarding their customers‘ interaction with the company‘s Web site. This material could be very useful for future user experience analyses and improvements.

3-

Telematics in car insurance If Fitchwood implemented either a Pay-As-You-Drive or Pay-How-You-Drive model for their auto insurance business, they would need to determine how they would be able to deal with the very large amounts of data the required telematics applications create. In addition, they would need to select between competing technologies in an area that has not yet matured enough to focus on a standardized technology set. It would also be essential for them to have a very solid data communications infrastructure to ensure that the data collected from the vehicles is received reliably without problems. They need to implement an analytics solution that is well integrated with the data infrastructure, allowing (near) real-time analysis of the collected telematics data. They would also benefit from the capability to provide telematics-based feedback to their customers. One fundamental question is whether they want to implement all this on their own infrastructure or use a cloud-based solution.

Note: Questions 11-29 and 11-30 are erroneously referring to Teradata University Network. The environment is now called Teradata University for Academics (best link for the site is https://www.teradata.com/University/Academics).

3-

SAS Visual Analytics Best way to access S A S Visual Analytics is at https://www.sas.com/en_us/software/on-demand-foracademics.html .

There is no one specific right answer to this question and student responses will vary significantly.

3-

Tableau v s SAS Visual Analytics ersu

Best way to access Tableau is at https://www.tableau.com/academic .

There is no one specific right answer to this question and student responses will vary significantly.

407

Chapter 4

Chapter 12 Data and Database Administration with Focus on Data Quality Chapter Overview The purpose of this chapter is to introduce students to the principles and tools for the administration of data. Data and database administration assume even greater importance as organizations distribute their data and processing across the enterprise. This chapter is primarily descriptive and awarenessfocused in nature; the material related to technical database management skills is primarily located in Chapters 7 – 10 (and particularly Chapters 7 and 8).

This chapter emphasizes the changing roles and approaches of data and database administration. It continues to focus on the critical importance of data and database management in managing data as a corporate asset, with a specific and strong focus on data quality and its management. The chapter also discusses mechanisms for improving data quality, including data stewardship and master data management.

Chapter Objectives Specific learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Ensure that the students understand the importance of data administration and its relationship to information resource management.

2. Help the students understand the differences between data administration and database administration.

3. Develop an understanding of the changes that are occurring in the data administrator and database administrator roles.

Chapter 4

408

4. Demonstrate the role of data governance in data management and show how it is linked to efforts to maintain data quality.

5. Strengthen the students‘ understanding of and appreciation of the importance of data quality as a fundamental bedrock for users‘ trust in any data management / analytics solution. Help students see why errors in data will quickly affect the users‘ willingness to rely on information systems and the analytical tools that rely on them.

6. Highlight the role of Master Data Management in ensuring the consistency and correctness of data across sources.

Key Terms Chief Data Officer

Data steward

Open source DBMS

Data administration

Database administration

Data governance

Master Data Management (MDM)

Blank

Blank

Classroom Ideas 1. If possible, schedule a classroom visit by a data administrator or database administrator from a local company or organization. Discuss the agenda in advance, and allow plenty of time for questions.

2. Discuss the functions of data administration and database administration (Figure 12-1). Indicate that these are interesting career opportunities that require both behavioral and technical skills. If possible, bring a few job announcements in the database field to class. Show salary data using sources such as Glassdoor or PayScale (although it is essential to be careful about the consistency of the terminology; particularly data administrator is used to describe a variety of roles, some of them much less demanding than the roles we are using the term for). Discuss the current situation for outsourcing of database administration and the difficulty of outsourcing data administration.

3. Discuss the selection of a data administrator and the placement of the data administration function.

Discuss changing expectations of data administrators and alternative organization placements of data administration responsibilities.

409

Chapter 4

4. Inexperienced students are likely to underestimate the problems associated with establishing adequate data quality. A discussion of the various areas that must be considered, along with examples, should be conducted. Examine through discussion how these instances of poor data quality might have been prevented with more attention to data quality in the organization(s) or what some of the contributing factors were to good data quality in this situation.

5. Everyone has likely seen poor quality data. Ask students to bring examples to class (e.g., redundant credit card application mailings, possibly with inaccurate name spellings; downloaded sports statistics with obvious, spurious values; personal databases, spreadsheets, etc.). In class, with the permission of a student, you might do a simple data profiling (distribution, end points, descriptive statistics) of some attributes to help find poor quality data.

6. Discuss the role Master Data Management can serve in improving and maintaining data quality and the challenges MDM efforts are often facing, some of which are political and organizational in nature.

Describe the importance of executive buy-in for addressing these challenges.

7. Review the role an organization-wide tool (see, for example, https://www.informatica.com/products/master-data-management ) can serve in the process of establishing a strong Master Data Management program, still emphasizing the fact that M DM is never a purely technical process.

8. Access the ICCP or DAMA International Web sites and discuss with them the D BA certification exam these organizations sponsor. Talk with your local D AMA chapter to solicit a guest speaker to discuss the value of these vendor-neutral certifications.

Answers to Review Questions 3 - Define the following key terms: a. Database administration. A technical function that is responsible for physical database design and for dealing with technical issues such as security enforcement, database performance, and backup and recovery b. Data administration. A high-level function that is responsible for the overall management of data resources in an organization, including maintaining corporate-wide definitions and standards

Chapter 4

410

c. Chief data officer. An executive-level position accountable for all data-related activities in the enterprise d. Master data management. The disciplines, technologies, and methods used to ensure currency, meaning, and quality of reference data within and across various subject areas e. Open source DBMS. A database management system that has been developed using the open source principles, which typically make the source code of the product freely available for anybody to review and modify (the specific conditions vary depending on the licensing model) 3 - Match terms to appropriate definitions. d

data administration

c

database administration

e

master data management

a

data steward

b

open source DBMS

3 - Compare and contrast the following terms: a. Chief data officer; database administrator. These roles are at opposite ends of the data management spectrum. CDO is a high-level organizational administrator that is responsible for development, maintenance and utilization of data as an organizational asset, whereas a database administrator is a technical role the holders of which are responsible primarily for physical database design and supporting the operating tasks related to continued maintenance of the organization‘s database resources. b. Data administration; database administration. Data administration is the overall management of data resources. The second function, that of database administration, is responsible for physical database design and for dealing with the technical issues – such as security enforcement, database performance, backup, and recovery – associated with managing a database. c. Open source DBMS; commercial D BMS. A commercial DBMS is a database management

411

Chapter 4

system that has been developed and the intellectual property of which is fully owned by an enterprise (typically commercial), such as Oracle Corporation (Oracle) or Microsoft Corporation (S QL Server). An open source D BMS, however, is a DBMS that has been developed and is maintained by a community of developers (including commercial companies) who are making the product and its source code available for free to both users and other developers, typically on the condition that all modifications will have to be made available to the community, too. A variety of different licensing agreements are used for open source products. d. ETL; master data management. ETL is the extract-transform-load process used by most data warehouse technologies to consolidate many data sources into a single, consolidated data warehouse. Master data management (M DM) refers to the disciplines, technologies, and methods to ensure the currency, meaning, and quality of reference data within and across various subject areas. MDM determines the best source for each piece of reference data, and then affords access to this ―golden record‖ to the applications that need to use it. M DM uses a subset of integrated data while E TL usually provides much more integrated data in a data warehouse.

3 - Data or Database Administrator role? a. Managing the data repository – data administrator b. Installing and upgrading the D BMS – database administrator c. Conceptual data modeling – data administrator d. Managing data security and privacy – database administrator e. Database planning – data administrator f. Tuning database performance – database administrator g. Database backup and recovery – database administrator h. Running heartbeat queries – database administrator 3 - The changing roles of the data administrator and database administrator: Data administration is a high-level function that is responsible for the overall management of data resources in an organization, including maintaining corporate-wide data definitions and standards. Typically, the role of database administration is taken to be a more hands-on, physical involvement with the management of a database or databases. Database administration is a technical function that is responsible for physical

Chapter 4

412

database design and for dealing with technical issues such as security enforcement, database performance, and backup and recovery. As business practices change, the roles are also changing within organizations.

There are, however, a core set of database administration functions, which must be met in every organization, regardless of the database administration chosen. On one hand, these functions may be spread across data administrators and database administrators. At the other extreme, all of these functions may be handled by a single DBA. 3 - Four common problems of ineffective data administration: a. Multiple definitions of the same data entity and/or inconsistent representations of the same data elements b. Missing key data elements, whose loss eliminates the value of existing data c. Low data quality levels due to inappropriate sources of data or timing of data transfers from one system to another, thus reducing the reliability of the data d. Inadequate familiarity with existing data, including awareness of data location and meaning of stored data, thus reducing the capability to use the data to make effective strategic or planning decisions 3 - Four job skills necessary for data administrators: a. Communication skills. Must interact with top management, users, and computer applications specialists b. Decisiveness. Must play a significant role in deciding where data will be stored and managed c. Flexibility. To be capable of resolving differences that normally arise when a significant change is introduced into an organization d. Managerial and technical skills. Capable of managing a technical staff and dealing with technical issues Four job skills necessary for database administrators: a. A sound understanding of current hardware architectures and capabilities. b. A solid understanding of data processing and database development life cycle, including traditional and prototyping approaches.

413

Chapter 4

c. Strong design and data modeling skills are essential at the conceptual, logical, and physical levels. d. Managerial skills are also critical.

3 - Briefly describe four new database administration trends that are emerging today: a. Procedural logic. A modern DBA has to be able to be responsible for ensuring that all stored procedures, triggers, and Persistent Stored Modules are effectively planned, tested, implemented, shared, and reused. b. Operating in a web-enabled environment. Managing databases that support and enable webaccessible databases is a natural part of any D BAs work currently. c. Supporting mobile devices. The use of various types of mobile devices (smartphones, tablets, watches, etc.) has become a very important role of any organizational data management environment. A DBA has to be able to deal with the issues related to the heterogeneous and highly distributed data generation and use environment related to the use of multitude of mobile apps. d. Use of cloud-based infrastructure solutions. Increasingly, many DBAs are supporting and enabling database solutions that are either fully or partially using resources offered by third-party providers and available through the Internet. These environments create their own challenges for database management, including intensified security requirements, the need to manage vendors and vendor relationships, enforcement of service level agreements, ensuring that vendors fulfill regulatory requirements, etc.

3-

Changes in data administration procedures that will decrease development and implementation time: a. Database planning. Improve technology selection through selective evaluation of possible products: Consider each technology‘s fit with the enterprise data model, reducing time required in later stages by effective selection of technology at the database planning stage. b. Database analysis. Work on physical design in parallel with development of the logical and physical models: Prototyping the application now may well lead to changes in the logical and physical data models earlier in the development process. c. Database design. Prioritize application transactions by volume, importance, and complexity:

Chapter 4

414

These transactions are going to be most critical to the application, and specifications for them should be reviewed as quickly as the transactions are developed. Logical data modeling, physical database modeling, and prototyping may occur in parallel. D BAs should strive to provide adequate control of the database environment while allowing the developers space and opportunity to experiment. d. Database implementation. Institute database change control procedures so that development and implementation are supported rather than slowed: Wherever possible, segment the model into modules that can be analyzed and implemented more quickly. Find ways to test the system more quickly without compromising quality. Testing may be moved earlier in the development; use testing and change control tools to build and manage the test and production environments. e. Operation and maintenance. Review all timesaving measures that have been taken to ensure that database quality has not been compromised: Consider using third-party tools and utilities wherever possible to save work; other tools, such as Lotus Notes, may reduce the need for meetings, thus saving time.

3 - Four threats to high availability: a. Hardware failure. Any component of a system, such as memory or a disk drive, can become a point of failure. The usual solution is to provide some measure of redundancy. One example might be having the workload spread across several servers. If one server fails, the others can take over its workload. b. Loss or corruption of data. Data can be lost or become corrupt for many reasons, including hardware and network issues. The best solution to prevent this from interrupting service is to have a backup database with an exact copy of the data. Also, appropriate backup and recovery procedures must be in place. c. Maintenance downtime. Before systems were needed 24/7, there could be planned downtime for maintenance tasks. Generally, this can no longer be done for many systems. Nondisruptive utilities are available which allow routine maintenance to be done on a database without having to take the system offline. d. Network-related problems. Both internal networks as well as the Internet can cause problems for availability. Organizations should employ the latest in firewalls and other network technologies as

415

Chapter 4

well as have a response plan in place for any large spikes in activity.

3 - Key Activities: The key activities that are often the focus of enterprise data management initiatives are data governance, data quality, master data management, data integration, and data security.

3 - Key components of a data governance program: a. Sponsorship from both senior management and business units b. A data steward manager to support, train, and coordinate the data stewards c. Data stewards for different business units, data subjects, source systems, or combinations of these elements d. A governance committee, headed by one person, but composed of data steward managers, executives, and senior vice presidents, IT leadership, and other business leaders to set strategic goals, coordinate activities, and provide guidelines and standards for all data management activities How does data stewardship relate to data governance?

Data governance refers to high-level organizational groups and processes that oversee data stewardship across the organization. Data governance guides data quality initiatives, data architecture, data integration and master data management, data warehousing and business intelligence, and other data-related matters.

Data stewardship refers to the role of individuals in the organization who are responsible for ensuring that organizational applications properly support the organization‘s enterprise goals for data quality. Data stewards are held accountable for the quality of the data for which they are responsible. Thus, data stewardship is central to the success of data governance within an organization as data stewards are the actual ―front-line‖ people who see that the data governance processes are undertaken on a daily basis.

Alternate Solution Data governance is a comprehensive program in organizations that usually guides data quality initiatives, data architecture, data integration and master data management, data warehousing, business intelligence, and other data-related matters. Data governance oversees data stewardship in an organization. Data stewardship is a specialized task, whereas data governance exerts guidance over activities to develop a unified management of data across the enterprise and is participated in by enterprise decision makers.

3 - Importance of data quality: According to Informatica (2005; see textbook references), data quality is important to: a. Minimize IT project risk b. Make timely business decisions

Chapter 4

416

c. Ensure regulatory compliance d. Expand the customer base 3-

The effect of Sarbanes-Oxley Act on the need for organizations to improve data quality: In a nutshell, the Sarbanes-Oxley Act (S O X) requires organizations to be accountable to their stakeholders regarding their operations and financial decisions; at the present time, this applies mainly to publicly-traded organizations. As some experts have indicated, information technologies and systems provide a means for organizations to comply with the various regulatory sections of S O X. Data are the heart and lifeblood of most information systems. In particular, various sections of the S O X Act yield requirements for organizations to measure and improve metadata quality; ensure data security; measure and improve data accessibility and ease of use; measure and improve data availability, timeliness, and relevance; measure and improve accuracy, completeness, and understandability of general ledger data; and identify and eliminate duplicates and data inconsistencies. The S O X Act could provide motivation for many organization executives to treat data quality as an important strategic and operational goal.

3 - Characteristics of quality data: a. Uniqueness. Each entity exists no more than once within the database and there is a key that can be used to uniquely access each entity. b. Accuracy. The degree to which any datum correctly represents the real-life object it models. c. Consistency. Values for data in one data set (database) are in agreement with the values for related data in another data set (database). d. Completeness. All data that must have a value do have an assigned value. e. Timeliness Meeting the expectation for the time between when data are expected and when they are readily available for use. f. Currency. The degree to which data is recent enough to be useful. g. Conformance. Whether the data is stored, exchanged, or presented in a format that is as specified by its metadata. h. Referential integrity. Data referring to other data are unique and satisfy requirements to exist (that is, satisfies any mandatory one or optional one cardinalities).

3 - Four reasons for poor data quality in organizations: a. External data sources. Organizations continue to rely on many outside sources for data—Web

417

Chapter 4

forms, XML channels from business-to-business sources, and databases from external organizations (e.g., mailing lists, census data, etc.). Organizations have little to no control over the completeness, accuracy, timeliness, or compatibility of this data with their internal data. Thus, organizations experience issues with data quality in their internal systems when this external data is brought into the organization without some form of data quality audit or control. b. Redundant data storage and inconsistent metadata. Often, organizations have data stored in many different formats across the organization: spreadsheets, desktop databases, legacy databases, data marts, data warehouses, and other data repositories. This varied data may be redundant, inconsistent, and incompatible. If the metadata are wrong (for example, a bad algorithm or formula in a spreadsheet), the data will be wrong as well. c. Data Entry. Organizations have not always taken advantage of placing integrity controls, valid value controls, and other data quality controls within the database definitions. Thus, the control for data integrity has typically fallen to the user interface of various applications, which may or may not take advantage of automatically filling in stored data or using drop-down selection boxes. d. Lack of organizational commitment. Organizations have failed to recognize the importance of data quality or doubt that there will be a positive return on investment if efforts to improve data quality are undertaken. Thus, organizations have not made the commitment or invested resources to address data quality in organizational systems.

3 - Key steps to improve data quality: a. Get the business buy-in b. Conduct a data quality audit c. Establish a data stewardship program d. Improve data capture processes e. Apply modern data management principles and technology f. Apply T QM principles and practices

Chapter 4

418

3 - Data profiling and role in data quality?

A data profile is a statistical profile of the data values for each field in each table in the database. The statistical profile will allow people to view the patterns of data values (for example, distribution, outliers, frequencies) and to analyze them to see if the distribution makes sense. Data values can also be reviewed for obscure or extreme values. Data values can also be reviewed against known (and supposedly, operating) business rules as a check against data entry and processing routines.

Data profiling is one step of a data quality audit and a data quality program in an organization. Specialized tools (such as Informatica‘s Power Center) are available to permit periodic data profiling of an organization‘s database and applications. Data profiling serves the role of a check against organizational process controls over data entry and maintenance activities.

3 - Four dimensions of poor data quality a. Increased costs b. Decreased revenues c. Decreased confidence d. Increased risk 3 - Data capture processes and data quality?

According to Inmon (2004; see textbook references), there are several actions that can be taken at the original data capture step: a. Enter as much of the data as possible via automatic, not human, means (e.g., retrieval from card swipe, current records, etc.). b. Data that must be entered manually should be selected from preset options (e.g., drop-down boxes, etc.). c. Create consistent screen layouts, easy to follow navigation paths, clear data entry masks and formats, and minimally use obscure codes in the user interface. d. Entered data should immediately be checked for quality against data in the existing database. If there are issues, immediate and understandable feedback should be given to the human operator.

419

Chapter 4

3 - Importance of MDM? Master data management (M D M) refers to the disciplines, technologies, and methods used to ensure the currency, meaning, and quality of reference data within and across various subject areas within an organization. M DM allows an organization‘s business units to have a current and accurate ―single source of truth‖ they can use to support business processes.

3 - Three approaches to MDM? a. Identity registry: master data remain in source systems, and applications refer to the registry to determine where the most current data resides (similar to federation style of data integration). b. Integration hub: data changes are broadcast through a central service to all subscribing databases (similar to propagation style of data integration) c. Persistent: One consolidated record is maintained, and all applications draw upon that ―golden record‖ for the common data (a pure consolidated data integration approach for master data) 3 - MDM v s other forms of data integration? er su

A distinguishing feature of master data management (M D M) is that it focuses on only the key reference data that are commonly referenced more frequently than other data in the organization. In essence, M D M operates on only a subset of the data in an organization.

Answers to Problems and Exercises 3-

Data Governance Program Application:

Chapter 4

420

People (“who”)

Process (“how”)

Technology (“what”)

Upper Management (CEO,

Data administration

Databases

Enterprise data

Data warehouses

CFO, CIO) Data steward manager

management (data

External data sources

Business information

quality, master data

Redundant data storage

advisory committee (data

management, data

(e.g., spreadsheets,

stewards)

integration –

desktop databases,

consolidation,

datamarts, data

federation, propagation)

warehouses)

421

3-

Chapter 4

Categorize Table 12-2 activities.

Step Get the business buy-in

Motivation Show the value of data quality management to executives Conduct a data quality audit Understand the extent and nature of data quality problems Establish a data Achieve organizational stewardship program commitment and involvement Improve data capture Overcome the ―garbage in, processes garbage out‖ phenomenon Apply modern data Use proven methods and management principles and techniques to make more technology thorough data quality activities easier to execute Apply T QM principles and Follow best practices to practices deal with all aspects of data quality management 3-

Activity category People

Process

People and process

Technology People, process, and technology

People, process, and technology

PVFC Data Profile Exercise Note to Instructor: Specific student answers will vary depending on the database used as a basis of this exercise, however the basic elements of each answer will be similar to the sample solution below. The sample solution is based on the small Pine Valley Furniture Company database produced in M S Access. a. Develop a plan for performing a data profile analysis on this database. Base your plan on the eight characteristics of quality data, on other concepts introduced in the chapter, and on a set of business rules you will need to create for this database. Justify your plan.

Plan for data profile analysis on P VFC Database (small) consisting of four steps, as specified below: 1.

Review the characteristics of quality data and compare the implemented database against each characteristic. Document results of this review and be sure to highlight any management concerns or issues.

Uniqueness. Does each entity exist only once? Does each entity have a unique key? If an entity exists more than once, is there system or design documentation that explains why and how the data is synchronized between the multiple instances?

Chapter 4

422

Accuracy. Are order sales values accurate according to accounting records? Does the assignment of salespeople to territories reflect current human-resource assignments?

Are employee records current with human-resource and payroll records? Are vendor records accurate according to accounting records?

Consistency. Are the supervisory relationships between employees properly noted in the database and are the employee characteristics consistent between instances of the records? Does the Product Finish value in the Product table map consistently to the proper Product Line in the Product Line table?

Completeness. All data that must have a value does have an assigned value. Have the raw materials for each product been identified and accurately entered in the database?

Are all employee supervisors noted in the Employee table? Are employee skills current in the database? Do the skills noted in the skills table completely reflect the H R needs of PVFC? Timeliness. How quickly are orders posted to the database? What span of order dates are in the current database? How often are order records archived for historical storage (or used in the data mart or data warehouse)?

Currency. When were customer and vendor addresses last checked for currency? How frequently is the standard cost of Raw Materials reviewed? How do raw-materials standard costs compare to product standard prices and vendor-supply unit prices?

Conformance. Does the data presented in the reports, queries, and screens, match the format specified by its metadata? Are currency values within acceptable ranges? Are quantity values within acceptable ranges? Are state codes representative of valid state values?

Referential integrity. Does the data in each associative entity table properly correspond to the tables on either side of it? Does a table with a foreign key properly refer back to an existing record in its reference table? For example, does each order line properly refer to existing products in the product table and orders in the order table? The following tables should also be reviewed for referential integrity: ProducedIn_T (WorkCenter_T, Product_T), WorksIn_T (WorkCenter_T, Employee_T), HasSkill_T (Employee_T,

423

Chapter 4

Skill_T), DoesBusinessIn_T (Customer_T, SalesTerritory_T), Supplies_T (Vendor_T, RawMaterial_T), Uses_T (Product_T, RawMaterial_T), Product_T (ProductLine_T), Salesperson_T (SalesTerritory_T).

2.

Inspect the database tables for valid values for fields. If possible, utilize software to perform statistical profiling of the data values so that patterns may be analyzed for issues in the data (e.g., extreme values, missing values, outliers, etc.). Document results of inspection and software analysis. Highlight issues for management review.

3.

Review business rules of P VFC and compare the data found in the database to the business rules (Refer to Chapters 2, 3, and 4 for documented business rules of this database. One example is that each employee has one supervisor, except for managers, who have no supervisor). Document results of review and highlight issues for management review.

4.

Render an assessment of the state of data quality in this database. List and briefly explain the data quality concerns for management action in terms of highest risk to lowest risk.

Again, note that #1 - #4 above are part of the plan that 12-26a asked the students to develop.

Justification for data profile analysis plan on P VFC Database (small): This data quality audit plan provides a comprehensive review of the quality of the data in the P VFC database (see above). Guidance is provided regarding the expectations of data quality in the database and a clear framework is provided for comparing the data contents against the data quality expectations. At each step of the plan, documentation of the results of the audit is produced for management review. Additionally, at the end of the audit, an assessment of the data quality is provided along with a management action list. b. Perform your data quality audit plan for one of the tables in the database (pick the table you think might be the most vulnerable to data quality issues). Develop an audit report on the quality of data in this table.

Table in PVFC Database (small): Product i.

Characteristics of quality data:

Chapter 4

424

Characteristic

Comments

Characteristic

Uniqueness

Product table exists only once in

Uniqueness

database; it has unique P K. Accuracy

Product standard price is accurate

Accuracy

according to accounting department audit of purchase invoices.

Description of Product I D 2 appears to be misspelled (coffe table rather than coffee table?)

Consistency

Existing product finish values match

Consistency

the product finish expectations for the Product Line assigned to each product. Current records are consistent, but there are no entry controls to maintain consistency in future.

Completeness

Current records are complete but

Completeness

there are no entry controls to require fields to be entered other than ProductID. Timeliness

Ok

Timeliness

Currency

Ok

Currency

Conformance

Ok

Conformance

Referential

Current products in the Product table

Referential

Integrity

are properly referenced in the

Integrity

ProductLine, ProducedIn, and OrderLine tables. As there are no records in the RawMaterials table, there are no records to match products to in the Uses table.

Referential integrity controls appear

425

Chapter 4

Characteristic

Comments

Characteristic

to be functioning properly.

A review of the Product table against the characteristics of quality data shows that the data is of fairly high quality at the moment. P VFC management should pay attention to instituting some data entry controls to ensure complete entry of information beyond the primary key field for each record in this table. Address values should be reviewed periodically for currency and accuracy, as these can often change over time and may lead to inconsistent data throughout the organization. Additionally, P VFC may wish to automate some form of spell-checking on product description values or schedule a regular review process for this field to ensure errors are caught early in the process. ii.

Inspection of data values of Product table: Data values for the product table appear to be within acceptable ranges of values, with the exception of the spelling error for the Product I D 2 item.

iii.

Review of business rules: The Product table appears to be operating in conformance with known P VFC business rules.

iv.

Assessment of data quality in Product table: The data quality of the current Product table is good to very good. There are some areas of concern regarding completeness and accuracy that need attention to ensure that future data in this table (and the database) will maintain such a good level of data quality.

Following is a brief list of action items for P VFC management: 

Institute required entry of fields in the product table beyond the primary key field. The assignment of price should use a default value if a standard price is not known at the time of entering a new product item.



Consider automating the description of products along agreed upon dimensions. For example, if you know you only produce desks, tables, and entertainment centers, you

Chapter 4

426

may wish to break up the product description field into smaller subsets, like, type=desk, kind=computer, that can be selected from a drop-down list (or other automated selection mechanism) so that errors in data entry may be eliminated or at least mitigated. c. Execute your data profile plan for a set of three or four related tables. Develop an audit report on the quality of data in these tables.

Tables in PVFC Database (small): Product, ProductLine, Uses, RawMaterials v.

Characteristics of quality data: Characteristic Comments Uniqueness

Each table exists only once in database; each

+ or − +

table has unique P K. Accuracy

Data appear to be accurate, but low in volume.

−

Consistency

Current records are consistent, but there are no

−

entry controls to maintain consistency in future.

Completeness

Current records are complete but there are no

−

entry controls to require fields to be entered other than primary keys. RawMaterials and Uses tables are not filled with much data.

Timeliness

Ok

+

Currency

RawMaterials and Uses tables do not appear to

−

be filled with current data.

Conformance

Ok

+

Referential

Referential integrity appears to be in force.

+

Integrity

The data quality of these four related tables appears to be below average. In particular, the missing data in the RawMaterials and the Uses tables is troubling and hard to interpret. PV FC management should pay attention to instituting some data entry controls to ensure complete entry of information beyond the primary key field for each record in all tables, in

427

Chapter 4

order to maintain consistency and completeness. vi.

Inspection of data values of related tables: The current data values for these related tables appear to be within acceptable ranges of value, with the exception of issues raised earlier in the review of the Product table.

vii.

Review of business rules: The tables appear to be operating in conformance with known P VFC business rules.

viii.

Assessment of data quality in related tables: The data quality of these four tables is below average. There are some areas of concern regarding completeness, accuracy, consistency, and currency that need management attention. Following is a brief list of action items for PVFC management: 

Investigate why the RawMaterials and Uses tables are under-populated. Was data entered and deleted? Was data never entered originally? Are we not capturing this data in the application systems?



Institute required entry of fields in all tables beyond the primary key field. The assignment of price should use a default value if a standard price is not known at the time of entering a new product item.



Consider automating the description of products along agreed upon dimensions. For example, if you know you only produce desks, tables, and entertainment centers you may wish to break up the product description field into smaller subsets (like type=desk, kind=computer), that can be selected from a drop-down list (or other automated selection mechanism) so that errors in data entry may be eliminated or at least mitigated.

d. Based on the potential errors you discover in the data from the previous two exercises (assuming you find some potential errors), recommend some ways the capture of the erroneous data could be improved to prevent errors in future data entry for this type of data.

Please see final assessment and action item listing of each of the prior exercises for details on addressing future data entry errors.

Chapter 4

428

e. Evaluate the E RD for the database. You may have to reverse engineer the E RD if one is not available with the database. Is this a high-quality data model? If not, how should it be changed to make it a high-quality data model?

Yes, the ERD for the database appears to be a high-quality data model. It might be improved with a bit more attention to the design of fields (for example, the product description example in prior exercises) and the use of single field surrogate primary keys for the associative entity tables, but it essentially follows all the guidelines for a high-quality data model according to Hay (2005). f. Assuming you are working with a Pine Valley Furniture Company database in this exercise, consider both the large and small P VFC databases as two different source systems within P VFC. What type of approach would you recommend (consolidation, federation, propagation, master data management), and why, for data integration across these two databases? Presume that you do not know a specific list of queries or reports that need the integrated database and design your data integration approach to support any requirements against any data from these databases.

A consolidation approach for the data integration of the large and small P VFC databases is recommended. Based on a current review of the structure of both databases, there are enough structural differences that the federation, propagation or master data management approaches would not work. The consolidation approach could foster organizational agreement on standard understandings of the data in the organization, and may result in a unified view of data for decision making. The consolidation approach may enable PVFC to make revisions in the small database version such that in the future a federation, propagation, or master data management approach may work.

Perform a search of companies and products that are available to help with data reconciliation and integration. Document your results by filling in the table below. We have provided an example: Product Name

Company

Data Integration Steps Supported

Data Bridger

Taurus Software

Extract, transform, load, and index

429

Chapter 4

Student answers will vary depending on depth of research and availability of sound materials discovered during the online search.

3-

Impact of poor data on business As the example context we are using a retailer of high-end clothing that is emphasizing strongly the need to create a personal relationship between the company and its customers. a. Increased costs. For example, a marketing program might end up targeting unintended (prospective) customers with an expensive campaign because of poor quality data, leading to unnecessary marketing expenses and wasted materials. b. Decreased revenues. Following the example above, the same marketing program might not reach a subset of high-quality prospects because of poor data quality, thus leading to the potential lost revenue. c. Decreased confidence. Examples of poor data quality might lead to a situation where decision makers will become hesitant to use the centralized data resources at all. For example, in our example, a marketing manager might not use internal resources at all after a poor experience but might resort to the use of purchased external databases. d.

Increased risk. Poor data quality increases the risk of a number of types of business problems, including those related to product/service quality. In the case of our example, the retailer‘s quest for building a close relationship with their customers is at risk to fail if poor data quality prevents them from demonstrating to customers that the company understands their needs and is able to adapt its behavior (such as marketing communication) appropriately.

3-

Metro Marketers, Inc. Data Administrator Candidates: This is a discussion question with no one correct answer. One solution is given below, but the ranking of the first two candidates is the most difficult and could lead to a rousing class discussion.

1. Jim Reedy’s professional background shows a combination of both managerial and technical skills, a key requirement for the position of the data administrator. As a well-respected insider, he is likely to be capable of enlisting cooperation from users. Jim Reedy is very familiar with Metro‘s

Chapter 4

430

current systems environment, and this fact will be a plus in managing the technical staff and dealing with technical issues.

2. Gerald Bruester ranks second. Data administration is a high-level function that is responsible for the overall management of data resource. Gerald Bruester is a senior database administrator, but he also has knowledge related to data warehousing—a fact that gives him a competitive advantage over Monica Lopez. Also, he has managed a marketing-oriented database, which will be a most preferred experience for a warehouse storing customer information for marketing purposes, rather than financial information (as in the case with Monica Lopez).

3. Marie Weber ranks third because her expertise includes management of a similar data warehouse implementation, which stores customer information. Overall management of data resources has already been one of her responsibilities.

4. Monica Lopez’s management of a financial database for a global banking firm for five years in a constantly changing contemporary environment is great proof of professionalism. Despite her expertise as a senior database administrator, however, Monica Lopez has been involved in a different type of business—a major disadvantage over the other candidates.

3-

Metro Marketers, Inc. Data Warehouse Administrator Candidates: This is a discussion question with no one correct answer. One solution is given below: 1. Marie Weber would be the preferred candidate because her expertise includes management of a similar data warehouse implementation, which stores customer information. Her experience with a Red Brick-based application would be a strong asset in the process of building the new data warehouse.

2. Gerald Bruester would be the second preferred candidate. He has managed a marketingoriented database, which will be a most preferred experience for a warehouse storing customer information for marketing purposes, rather than financial information (as in the case with Monica Lopez).

3. Jim Reedy is very familiar with Metro‘s current systems environment, and this fact will be a plus in managing the technical staff and dealing with technical issues.

431

Chapter 4

4. Monica Lopez (as in Problem 5), despite her expertise as a senior database administrator, Monica Lopez has been involved in a different type of business—a major disadvantage over the other candidates.

3-

Metro Marketers, Inc. Database Administrator Candidates: This is a discussion question with no one correct answer. One answer is given below.

1. Gerald Bruester would be the preferred candidate. Gerald Bruester is a senior database administrator. His managerial and technical experience with a marketing-oriented database will be very suitable for a company involved in storing customer information for marketing purposes.

2. Jim Reedy has technical expertise and in addition is very familiar with Metro‘s current systems environment. This fact will be a substantial plus for him.

3. Monica Lopez has managed a financial database for five years, probably in a dynamic environment. This expertise gives her a competitive advantage over Marie Weber.

4. Marie Weber would be the least preferred candidate, as she has no experience as a database administrator.

3-

Concerns for database administrator?

There are no established security procedures and policies, or the implementation and enforcement of those procedures and policies is lacking. As a result, there are three major concerns: a. Loss of privacy or confidentiality. Failure to control privacy of information may lead to blackmail, bribery, public embarrassment, or use of user passwords. Failure to control confidentiality may lead to loss of competitiveness. b. Theft and fraud. These activities are going to be perpetrated by people able to gain access to the machines to alter or obtain data without authorization. c. Increased legal and regulatory risks. The organization might be exposed to significant legal and regulatory risks because of lack of proper security practices based on S OX, HIPAA, Basel, etc.

3-

Globally distributed database; improve processing of monthly sales reports?

Optimal solutions to this situation will depend on a more detailed understanding of the exact situation and the RDBMS being used, but here are some possibilities based on typical Oracle environments:

Chapter 4

432

a. Replicate the data on the corporate machine, taking advantage of Oracle‘s data caching capabilities. The data will then become a part of the local corporate instance, allowing additional processing of the data beyond producing the regional monthly sales report if desired, without incurring additional loads on the network. If necessary, the snapshot of the data can be refreshed at predetermined intervals. Snapshots can be scheduled at off-peak load times. b. Create summary tables at each regional site that contain the summarized data necessary to prepare the monthly regional sales reports at corporate headquarters. This approach would greatly diminish the network load, as only the summary tables would need to be transmitted. This option does not necessarily provide the flexibility for using the data for other processing that is possible from the previous approach. c. Because the reports are regional, move the processing of the reports out to the regional offices.

This approach would eliminate any network load problems occurring as a result of the existing procedures. However, this approach will raise software management issues unless the company can manage the software used to produce the reports centrally. d. Moving to a three-tier client/server architecture might also be a possibility. Then the reporting software could reside on the middle tier and the software management issues inherent in the previous approach might be greatly reduced.

3-

E-business high-volume catalog center: a. According to the text, the average cost per hour of downtime is at least $100,000. According to Table 12-4, a system that has 99.5 percent availability has approximately 43.8 hours downtime per year. So, the annual cost of downtime is at least $4,380,000. b. According to Table 12-4, 99.99 percent downtime is equivalent to 0.88 hours a year. Therefore, the total annual cost of downtime would be $88,000. The net realized savings would be $4,292,000. The cost of the vendor‘s proposal would be $300,000 per year. The company would realize a total net savings of almost $4,000,000. This would be justifiable because it is a significant cost savings.

3-

Retail brokerage firm data availability:

433

Chapter 4

For the retail brokerage firm, the expected annual cost of downtime for 99% availability is $6.45 * 87.6 = $565.02 million. For 99.5 percent availability it is $282.51 million. Neither of these levels would be acceptable.

3-

Mail order firm (P&E 12-33) cost of poor data quality: The estimated loss would be 1,000,000 * .12 * $6.00 = $720,000.

3-

Mail order firm (P&E 12-33, 12-35) increased revenue?

The average increase in revenue will be $5 million (100 * 0.05 * 1,000,000).

3-

Available data quality software?

Left as an exercise for students. This question can be answered, in part, by review of the material in Chapter 12.

3-

Database administration for open source v s commercial products? ersu

Student answers will vary depending upon the site used, and student understanding of chapter material.

3-

Table comparing major concepts from chapter to features of cloud database providers.

Student answers will vary depending upon the site used, and student understanding of chapter material. The following solution is presented as a sample, based on the cloud.oracle.com material.

Concepts from Chapter

Services listed on cloud database provider site

Data administration

Not available; these functions would still need to be performed by the organization.

Database administration

Operations and Maintenance functions (see Figure 1) appear to be provided by cloud services. Design and implementation functions may still need to be performed by the organization.

Data warehouse administration

Not apparent that this functionality is available in the cloud environment.

Data/Database Security

Oracle Cloud keeps your data completely isolated from that of other companies. Oracle Cloud services also offer market-leading

Chapter 4

Concepts from Chapter

Services listed on cloud database provider site security features, including encryption, virus scan and whitelist support. Oracle data centers offer embassy-grade physical and logical security. The services employ management controls, operational controls, and technical controls within the security framework of ISO (International Organization for Standardization) and I EC (International Electrotechnical Commission), specifically I S O/IEC 27002:2005, Code of Practice for Information Security Management and I SO/IE C 27001:2005 standards.

Data Privacy

Oracle's Services Privacy Policy is compliant with the laws of the European Union Data Privacy Directive, and T RUSTe Certification.

Database software data security

As a subset of DBA security tasks, these

(views, integrity controls,

would still need to be performed within the

authorization rules, user-defined

organization, though the cloud services would

procedures, encryption,

appear to implement the selected or chosen

authentication schemes)

features for the organization database hosted in the cloud.

Database Backup and Recovery

Oracle Cloud services utilize a combination of disk and tape backups to help protect against the loss of Customer production data. Oracle periodically makes backups of Oracle Cloud production environment data using dedicated backup servers and tape libraries. By default, the systems used to support Customer's production environments are backed up

434

435

Chapter 4

Concepts from Chapter

Services listed on cloud database provider site periodically to, and can be restored from, disk or tape media.

Database performance tuning

May be available with additional services through Oracle sales representative.

Data availability

To facilitate business continuity in the event of an incident affecting Oracle Cloud Services, Oracle deploys the services in a manner that focuses on resiliency of computing infrastructure. Oracle's production data centers have component and power redundancy with backup generators in place to help maintain availability of data center resources in the event of crisis.

3-

Memo about cloud database usage: Student answers will vary depending upon the service provider used, and a student‘s understanding of chapter material. Key points that might be mentioned in support of the statement include: cloud solution(s) may reduce the number of D B A personnel (though will not eliminate entirely) and that cloud solution(s) may reduce the costs of having in-house technologies for hosting the particular database software and technology. Key points that might be mentioned against the statement include: increasing risks that company data may be hacked or destroyed; changing the staffing needs for information technology in terms of needing staff who can work with cloud vendor/cloud technologies as well as internal organizational staff; shifting organizational knowledge and competencies outside of organizational control.

Answers to Field Exercises 3This assignment is an alternative to having a D B A or data administrator visit your class. The evaluation will depend on the organization visited but should target issues raised in this chapter.

3Student answers will vary based upon the outside resources consulted.

Chapter 4

436

3Student answers will vary based upon the outside resources consulted.

3Student answers will vary based upon the outside resources consulted. If you assign the interview options (questions 12-44 and 12-45), you may wish to provide students with the guides to interviewing that were provided in earlier chapters in the Instructor‘s Manual.

3This assignment is an alternative to having a DB A or data administrator visit your class.

3This assignment will vary depending upon the selected organization.

3This is a good exercise for students to gain some insight into open-source implementations. Students should particularly make note of how an open-source platform is administered as compared to a traditional platform such as Oracle or DB2.

Chapter 13 Distributed Databases Chapter Overview Please note that the material for this chapter is based upon the Web version of Chapter 13. The purpose of this chapter is to discuss distributed database management. The trend toward distributed databases is being driven by the continued evolution of distributed database management systems software, the increasing importance of workgroup computing, and the globalization of commerce. This chapter, along with Chapter 8 on physical database design and database infrastructure and Chapter 12 on data and database administration, provides thorough coverage of database concurrent access controls.

Chapter Objectives

437

Chapter 4

Specific student learning objectives are included at the beginning of each chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Discuss the various options that are available for distributing data in organizations.

2. Discuss the potential advantages and risks associated with distributed databases.

3. Enable the student to compare distributed database design strategies with respect to reliability, expandability, communications overhead costs, manageability, and data consistency.

4. Discuss the four types of transparency: location, replication, failure, and concurrency.

5. Consider both the need for and the accomplishment of query optimization.

Key Terms Asynchronous distributed database Commit protocol

Global transaction

Semijoin

Local autonomy

Synchronous distributed database

Concurrency transparency

Local transaction

Synchronous distributed database

Decentralized database Distributed database

Location transparency Replication transparency

Timestamping Transaction manager

Failure transparency

Replication transparency

Two-phase commit

Classroom Ideas

Chapter 4

438

1. Assign your students the task of looking for examples of distributed database applications in the press. Discuss the issues in these examples based on material in the text.

2. Discuss the major options for distributing databases. Ask your students to help build a list of the advantages and disadvantages for each of these approaches.

3. Discuss the architecture of a distributed D BMS (Figures 13-2 and 13-3). Walk through the steps for both a local and remote database request.

4. Conduct a discussion of the four types of transparency: location, replication, failure, and concurrency.

Relate this discussion to the database shown in Figure 13-10. Comment on what support (if any) is provided for each type of transparency by the DBMS your students are using in the course.

5. Explain locking, deadlock, and timestamping in a distributed database environment.

6. Discuss the problem of query optimization in a distributed database environment using Table 13-2.

This table shows the dramatic differences in query processing times depending on the strategy used.

7. Emphasize that the concepts illustrated in this chapter are not necessarily established in distributed database architectures. A review of current database magazines may produce comparisons of distributed database products, which you can use to make students aware of current capabilities.

8. Discuss how simple distributed databases are created using middleware. For example, show how M S Access and Oracle can be linked via ODBC drivers, and an Access database can actually contain tables on both the local device running Access and a remote device running Oracle. Discuss the distributed database issues for this environment and how they should be managed.

Answers to Review Questions 3 - Define each of the following terms: a. Distributed database. A single logical database that is spread physically across computers in multiple locations that are connected by a data communications link b. Location transparency. A design goal for a distributed database that says that a user (or a user program) using data need not know the location of the data c. Two-phase commit. An algorithm for coordinating updates in a distributed database

439

Chapter 4

d. Global transaction. A transaction that requires reference to data at one or more nonlocal sites to satisfy the request e. Local autonomy. A design goal for a distributed database which says that a site can independently administer and operate its database when connections to other nodes have failed f. Timestamping. A concurrency control mechanism that assigns a globally unique timestamp (date and time) to each transaction; timestamping is an alternative to the use of locks in distributed databases g. Transaction manager. A software module that maintains a log of all transactions and maintains an appropriate concurrency control scheme 3 - Match terms to definitions: c

replication transparency

e

unit of work

d

global transaction

b

concurrency transparency

f

replication

a

failure transparency

3 - Contrast the following terms: a. Distributed database; decentralized database. Both distributed and decentralized databases are stored on computers at multiple locations. In a decentralized database, however, a network does not interconnect the computers; users at various sites cannot share data. Thus, it is best regarded as a collection of independent databases rather than having the geographical distribution of a single database. b. Homogeneous distributed database; heterogeneous distributed database. In a homogeneous distributed database, the same DBMS is used at each node; in a heterogeneous distributed database potentially different DBMSs are used at each node. It is difficult in most organizations to force a homogeneous environment, yet heterogeneous environments are much more difficult to

Chapter 4

440

manage. c. Location transparency; local autonomy. In a distributed database, the network must allow users to share the data as transparently as possible (location transparency), yet it must allow each node to operate autonomously (local autonomy) when network linkages are broken or specific nodes fail. d. Asynchronous distributed database; synchronous distributed database. Synchronous technology ensures data integrity and minimizes the complexity of knowing where the most recent copy of data is located. Synchronous technology may result in unsatisfactorily slow response time because the distributed DBMS is spending considerable time in checking that an update is accurately and completely propagated across the network. Asynchronous technology tends to have acceptable response times because updates happen locally and data replicas are synchronized in batches at predetermined intervals. It may be more complex to plan and design to ensure exactly the right level of data integrity and consistency across the nodes. e. Horizontal partition; vertical partition. The advantages and disadvantages of both techniques are similar with the exception that combining data across vertical partitions is more difficult than across horizontal partitions. This difficulty arises from the need to match primary keys or other qualifications to join rows across partitions. Horizontal partitions support an organizational design in which functions are replicated, often on a regional basis; while vertical partitions are typically applied across organizational functions with reasonably separate data requirements. f. Full refresh; differential refresh. In full refresh, a snapshot of the replicated portion of the database is sent to each site that carries a copy of the replicated database. In differential refresh, only those pages that have changed since the last snapshot are sent to each site that carries a copy of the replicated database. In this case, a snapshot log for each replicated table is joined with the associated base to form a set of changed rows to be sent to the replicated sites. g. Push replication; pull replication. With push replication, the central master site decides when a local site is updated. Examples include snapshot replication and near real-time replication. With pull replication, the target, not the source node, controls when a local database is updated. The local database determines when it needs to be refreshed and requests a snapshot or the emptying of an update message queue. Pull strategies have the advantage that the local site controls when it needs and can handle updates. Thus synchronization is less disruptive and

441

Chapter 4

occurs when needed by each site. h. Local transaction; global transaction. A local transaction requires reference only to data that are stored at the site where the transaction originates, while a global transaction needs a reference to data at one or more nonlocal sites to satisfy the request.

3 - Six business conditions that encourage using distributed databases: a. Distributed and autonomous business units. Divisions, departments, and business units in modern organizations are often geographically (and possibly internationally) distributed. Often each unit has the autonomy to create its own information systems, and often these units want local data over which they can have controls. b. Need for data sharing. Even moderately complex business decisions require sharing data over business units, so it must be convenient to consolidate data across local databases on demand. c. Need to contain data communications costs and reliability. The cost to ship large quantities of data across a communications network or to handle a large volume of transactions from remote sources can be high. Also, dependencies on data communications can be risky; keeping local copies or fragments of data can be a reliable way to support the need for a rapid access to data across the organizations. d. Multiple application vendor environments. Today, many organizations purchase packaged application software from several different vendors. Each ―best in breed‖ package is designed to work with its own database and possibly with different database management systems. A distributed database can possibly be defined to provide functionality that cuts across the separate applications. e. Database recovery. Replicating data on separate computers is one strategy for insuring that a damaged database can be quickly recovered and users can have access to data while the primary site is being restored. Replicating data across multiple computer sites is one natural form of a distributed database. f. Satisfying both transaction and analytical processing. The requirements for database management vary across O LTP and OLAP applications. Yet, the same data are in common between the two databases supporting each type of application. Distributed database technology

Chapter 4

442

can be helpful in synchronizing data across O LTP and OLAP platforms.

3 - Two types of homogeneous distributed databases: a. Autonomous. Each DBMS works independently, passing messages back and forth to share data updates. b. Nonautonomous. A central, or master, DBMS coordinates database accesses and updates across the network.

3 - Five characteristics of homogeneous distributed databases: a. Data are distributed across all the nodes. b. The same DBMS is used at each location. c. All data are managed by the distributed D BMS (so there is no exclusively local data). d. All users access the database through one exclusive schema or database definition. e. The global schema is simply the union of all the local database schemas.

3 - Four characteristics of heterogeneous distributed databases: a. Data are distributed across all the nodes. b. Different DBMS is used at each location. c. Some users require only local access to databases, which can be accomplished using only the local DBMS and schema. d. A global schema exists, which allows local users to access remote data.

3 - Five advantages of distributed databases vs. centralized databases: a. Increased availability and reliability. When a centralized system fails, the database is unavailable to all users. A distributed system will continue to function at some reduced level however, even when a component fails. b. Local control. Distributing the data encourages local groups to exercise greater control over ―their‖ data, which promotes improved data integrity and administration. At the same time, users can access nonlocal data if necessary.

443

Chapter 4

c. Modular growth. Suppose that an organization expands to a new location or adds a new work group. It is often easier and more economical to add a local computer and its associated data to the distributed network than to expand a large central computer. Also, there is less chance of disruption to existing users than in the case of a central system. d. Lower communication costs. With a distributed database, data can be located closer to point of use. This can reduce communication costs, compared to a central system. e. Faster response. Depending on how data are distributed, most requests for data by the local users can be satisfied by data stored at the local site. This speeds up query processing because communication and central computer delays are minimized.

3 - Four costs and disadvantages of distributed databases: a. Software cost and complexity. More complex software (especially the D BMS) is required for a distributed database. b. Higher processing overhead. The various sites must exchange messages and perform additional calculations to ensure proper coordination among data at the different sites. c. Data integrity maintenance. A by-product of the increased complexity and need for coordination is the additional exposure to improper updating and other problems of data integrity. d. Slow response. If the data are not distributed properly according to their usage, or if queries are not formulated correctly, response to requests for data can be extremely slow.

3 - Five advantages of the data replication form of distributed databases: a. Reliability. If one of the sites containing a relation (or the database) fails, a copy can always be found at another site without network traffic delays. Also, available copies can all be updated as soon as possible when transactions occur, and unavailable nodes will be updated once they return to service. b. Fast response. Each site that has a full copy can process queries locally so queries can be processed rapidly. c. Possible avoidance of complicated distributed transaction integrity routines. Replicated databases are usually refreshed at scheduled intervals, so most forms of replication are used when some

Chapter 4

444

relaxing of synchronization across the database copies is acceptable. d. Node decoupling. Each transaction may proceed without coordination across the network. Thus, if nodes are down, busy, or disconnected (e.g., in the case of mobile personal computers), a transaction is handled when the user desires. In the place of real-time synchronization of updates, a behind-the-scenes process coordinates all data copies. e. Reduced network traffic at prime time. Often, updating data happens during prime business hours, when network traffic is highest and the demands for rapid response greatest. Replication, with delayed updating of copies of data, moves network traffic for sending updates to other nodes to non-prime-time hours.

3 - Two disadvantages of the data replication form of distributed databases: a. Storage requirements. Each site that has a full copy must have the same storage capacity that would be required if data were stored centrally. Each copy requires storage space, and processing time is required to update each copy on each node. b. Complexity and cost of updating. Whenever a relation is updated, it must eventually be updated at each site that holds a copy. Synchronizing these updates near real-time requires careful coordination.

3 - Snapshot replication strategy: A snapshot replication strategy works best when the environment has a single updater. In this case, effects of the multiple updates are effectively batched for the read-only sites. Product catalogs, price lists, and other reference data for a mobile sales force are likely to be appropriate for the snapshot replication approach.

3 - Near real-time replication: A near real-time replication works best when the environment has multiple updaters. Each database update event can be handled individually with the use of triggers.

3 - Five factors that influence the viability of data replication: a. Data timeliness. Applications that can tolerate out-of-date data (whether this be for a few seconds or a few hours) are better candidates for replication. b. DBMS capabilities. An important DBMS capability is whether it will support a query that

445

Chapter 4

references data from more than one node. If not, then replication is a better candidate than partitioning schemes. c. Performance implications. Replication means that each node is periodically refreshed. When this refreshing occurs, the distributed node may be very busy handling a large volume of updates. If the refreshing occurs by event triggers (for example, when a certain volume of changes accumulates), refreshing could occur at a time when the remote node is busy doing local work. d. Heterogeneity in the network. Replication can be complicated if different nodes use different operating systems, DBMS, or more commonly, different database designs. Mapping changes from one site to n other sites could mean n different routines to translate the changes from the originating node into the scheme for processing at the other nodes. e. Communications network capabilities. Transmission speeds and capacity in a data communications network may prohibit frequent, complete refreshing of very large tables.

Replication does not require a dedicated communications collection, however, so less expensive, shared networks could be used for database snapshot transmission.

3 - Advantages and disadvantages of horizontal partitioning: Advantages: o Efficiency. Data are stored close to where they are used and separate from other data used by other users or applications. o Local optimization. Data can be stored to optimize performance for local access. o Security. Data not relevant to usage at a particular site are made unavailable. o Ease of querying. Combining data across horizontal partitions is easy because rows are simply merged by unions across the partitions.

Disadvantages: o Inconsistent access speed. When data from several partitions are required, the access time can be significantly different from local-only data access.

Chapter 4

446

o Backup vulnerability. Because data are not replicated, when data at one site become inaccessible or damaged, usage cannot switch to another site where a copy exists; data may be lost if proper backup is not performed at each site.

3 - Advantages and disadvantages of vertical partitioning: The advantages and disadvantages of vertical partitioning are identical to those of horizontal partitioning, with the exception that combining data across vertical partitions is more difficult than across horizontal partitions. This difficulty arises from the need to match primary keys or other qualifications to join rows across partitions.

3 - Five factors that influence the selection of a distributed database design strategy: a. Organizational forces. Funding availability, autonomy of organizational units, and the need for security b. Frequency and location or clustering of reference to data. In general, data should be located close to the applications that use those data. c. Need for growth and expansion. The availability of processors on the network will influence where data may be located and applications may be run; this may indicate the need for expansion of the network. d. Technological capabilities. Capabilities at each node and for D BMS coupled with the costs for acquiring and managing technology must be considered. Storage costs tend to be low, but the costs for managing complex technology can be great. e. Need for reliable service. Mission-critical applications and very frequently required data encourage replication schemes.

3 - Six unique functions of a distributed DBMS: a. Keep track of where data are located in a distributed dictionary. b. Determine the location from which to retrieve requested data and the location at which to process each part of a distributed query. c. If necessary, translate the request at one node using a local D BMS into the proper request to another node using a different DBMS and data model; return data to the requesting node in the format accepted for that node.

447

Chapter 4

d. Provide data management functions such as security, concurrency and deadlock control, query optimization, and failure recovery. e. Provide consistency among copies of data across the remote sites. f. Present a single logical database that is physically distributed.

3 - Effect of location transparency: With location transparency, the user of an ad hoc data query need not be aware that required data exist at various sites, and therefore, that this is a global (rather than local) transaction.

3 - Effect of replication transparency: With replication transparency, the user of an ad hoc data query need not be aware that identical data are stored at other sites. If a read request originates at a site that does not contain the requested data, the user need not be aware that the request has to be routed to another site, resulting in a global, rather than local, transaction.

3 - Two-phase commit issue: If a transaction fails during the commit phase as it attempts to commit at the involved remote sites, the transaction will be in limbo; this may result in an inconsistent database, as some commits have occurred, but not all.

3 - Three improvements to the two-phase commit: a. Read-only commit optimization. This approach identifies read-only portions of a transaction and eliminates the need for confirmation messages on these portions. For example, a transaction might include checking an inventory balance before entering a new order. The reading of the inventory balance within the transaction boundaries can occur without the callback confirmation. b. Lazy commit optimization. This approach allows those sites which can update to proceed with updating, and other sites which cannot immediately update are allowed to ―catch up‖ later. c. Linear commit optimization. This approach permits each part of a transaction to be committed in sequence rather than hold up a whole transaction when subtraction parts are delayed from being processed.

3 - Three steps in distributed query processing: a. Query decomposition. In this step, the query is simplified and rewritten into a structured, relational algebra form.

Chapter 4

448

b. Data localization. Here, the query is transformed from a query referencing data across the network as if the database were in one location, into one or more fragments that each explicitly reference data at only one site. c. Global optimization. In this final step, decisions are made about the order in which to execute query fragments, where to move data between sites, and where parts of the query will be executed.

3 - Conditions that suggest faster distributed query processing by using a semijoin: In a semijoin, only the joining attribute is sent from one site to another, and then only the required rows are returned. If only a small percentage of the rows participate in the join, then the amount of data being transferred is minimal. Clearly, the semijoin saves network traffic, which can be a major contributing factor to the overall time to respond to a user‘s query.

Answers to Problems and Exercises 3-

Figure 13-9 types of transparency a. Concurrency transparency b. Replication transparency c. Failure transparency d. Location transparency

3-

Figure 13-9 Standard Price List questions a.

UPDATE SET WHERE

Part_T UnitPrice = UnitPrice * 1.10 PartNumber = 56789;

b. i.

Not acceptable. The remote unit of work allows updates at a single remote computer. Thus, updates cannot be made simultaneously at more than one location—three in the case of Figure 13-9.

449

Chapter 4

ii.

Not acceptable. The distributed unit of work allows various statements within a unit of work to refer to multiple remote locations. Updates however, cannot be made simultaneously at more than one location because all tables in a single SQL statement must be at the same location.

iii.

Acceptable. A distributed request allows a single SQL statement to refer to tables at more than one remote DBMS.

3-

Figure 13-9 Parts databases questions a.

UPDATE SET WHERE UPDATE SET WHERE

Part_T Balance = Balance * 1.20 PartNumber = 98765 AND Location = "Tulsa"; Part_T Balance = Balance * .8 PartNumber = 12345 AND Location = "New York";

b. i.

Not acceptable. The transaction in 3a. is essentially a sequence of S QL statements that originated at one location, but attempted to be executed by multiple remote D BMS. The remote unit of work protocol would support only transactions attempted to be executed at a single remote location, and in addition, the same DBMS has to run on the remote computer.

ii.

Acceptable. The distributed unit of work protocol does support protected updates involving multiple sites, provided that each SQL statement refers to table(s) at one site only.

iii.

3-

Cannot determine. The distributed request protocol may or may not support failure transparency.

Heterogeneous database realistic?

Heterogeneous distributed databases are very difficult database environments because of the necessity to maintain communication, data integrity, efficiency, optimization, and security. Databases at different locations may be based on different models, perhaps relational and network. Products that make it possible to communicate among mixed DBM S and data models are just beginning to be available. It is a challenging task to optimize a database that runs on one platform; optimizing one across platforms can be a nightmare.

The goals of developing open systems without such barriers continue to be elusive. Building and maintaining a production database in a heterogeneous environment is one of the most challenging information systems tasks in businesses now.

3-

Table 13-2 differing results?

The drastically different results of the queries shown in Table 13-2 come primarily from the way each query results in data being moved in order to be processed. In general, it is often advisable to break a query in a distributed database environment into components that are isolated at different sites. Then determine

Chapter 4

450

which site has the potential to yield the fewest qualified records, and move these results to another site where additional work is performed.

3-

Table 13-2 use of semijoin?

The fifth strategy in Table 13-2 utilizes a semijoin. The joining attribute in this case is represented by a composite primary key and is sent to the remote location (Chicago). The Detroit computer however, would not yield the fewest qualified records for this particular query (Table 13-2). (The 1 million SHIPMENT records in Detroit, joined with the 10,000 supplier records, would yield more qualified records than the 1 million records stored in Chicago.) A large percentage of the returned rows participate in this join.

3-

Query optimization scenario a.

SELECT FROM WHERE

Part_T.PartNumber, Color Part_T, Supplier_T, Shipment_T Supplier_T.City <> "Chicago" AND Shipment_T.PartNumber = Part_T.PartNumber;

b.

1. Move PART relation to Detroit and process the whole query at the Detroit computer.

2. Join the SUPPLIER and SHIPMENT at the Detroit computer, PROJECT these down to suppliers not from Columbus, and move the result to Chicago for matching with PARTS. 3. Join the SUPPLIER and SHIPMENT at the Detroit computer, PROJECT just SupplierNumber and PartNumber for suppliers not from Columbus, and move this qualified projection to Chicago for matching with PARTs. c.

1. 100,000 records in PART *100 char = 10,000,000 char to be transferred. 10,000,000char / 10,000 char/sec= 1,000 seconds=16.7 min.

2. After the JOIN operation is completed, the result table will have a total of 1,000,000 records.

Each of those records will be essentially the SHIPMENT relation‘s record, extended with more information about its supplier, i.e., CITY. The join operation is a theta join over the Cartesian product of the two relations, where the qualifying expression is equality. Another way to look at it is to consider it a selection over the Cartesian product, where the expression is an equality

451

Chapter 4

between Supplier_T.SupplierNumber and Shipment_T.SupplierNumber. The worst case is the maximum number of tuples in Shipment_T. We have to exclude tuples with Supplier_T.City<> Columbus (which we assume are 100,000). Each record will be 150 char each because there will be three attributes in the table: SupplierNumber, PartNumber, and City.

(1,000,000 − 100,000) records × 150char = 135,000,000char.

135,000,000char / 10,000 char/sec= 13,500 seconds=225 min= 3.75 hrs.

3. After the JOIN operation‘s completion, the result table will have 1,000,000 records. We have to exclude tuples with Supplier_T.City <> Columbus (which we assume are 100,000).

Each record will be 100 char each because there will be only two attributes in the table: SupplierNumber, PartNumber, and City.

(1,000,000 − 100,000) records *100 char = 90,000,000 char.

90,000,000 char / 10,000 char/sec = 9,000 seconds = 150 min = 2.5 hrs.

Method

Time

1. Move PART relation to Detroit, and process the

16.7 minutes

whole query at the Detroit computer.

2. Join the SUPPLIER and SHIPMENT at the Detroit computer, PROJECT these down to suppliers not

3.75 hours*

from Columbus, and move the result to Chicago for matching with PARTS. Join the SUPPLIER and SHIPMENT at the Detroit

2.5 hours*

computer, PROJECT just SupplierNumber and PartNumber for suppliers not from Columbus, and move this qualified projection to Chicago for matching with PARTs.

* We assume a history of 100,000 shipments from Columbus. d. Because SHIPMENTS from Cleveland are 100,000, SHIPMENTS from Columbus could not

Chapter 4

452

exceed the number of 900,000. Or, to view the problem from another perspective, all PART records will always be less as a volume than SHIPMENTS not from Columbus. Hence, the first strategy is the optimal solution. Because the least number of records need to be transferred, the timing is the best among the three alternatives. e. Data replication. Each site that will have a full copy of the database can process the queries locally, so they can be processed rapidly.

Horizontal partitioning. Would allow isolation at multiple sites for SUPPLIERS according to their location. Hence, we wouldn‘t have to scan all records in the SUPPLIER table in order to select those that are not Columbus-located SUPPLIERS. Combining those records would be easy because they could be merged by unions across the partitions.

Vertical partitioning. Would be impossible because all the tables in the example consist of records of two attributes only.

3-

Large retail store chain database scenario a. The distributed database solution will have several advantages compared to a centralized system. When a centralized system fails, the database is unavailable to all users, regardless of their location. A distributed system will continue to function at some reduced level, however, even when a component fails. For a large retail chain with a large number of stores and store departments, availability is a serious consideration. The distributed database solution makes it easier to add a new location to the distributed network because it would be more economical to add a new local computer than to expand the existing central machine. There is less chance of disruption to existing users too. Slow response time, however, will still be a concern because schedule updates at each store are made five times per hour. A decentralized solution would not provide an opportunity for the corporation to control the information at the various locations because the local databases will not be connected in a corporate network. b. Partially or totally replicated across geographically distributed sites, with each copy periodically updated with snapshots.

3-

Fitchwood data mart access frequency recommendation: Because the data is only updated weekly, a distributed database is recommended. We don‘t have information on the telecommunications cost associated with connecting to systems in Florida; however, we can assume that it would be less expensive to send data weekly to Florida than have users constantly access a central database in the main office.

453

3-

Chapter 4

Fitchwood data distribution strategy?

The best data replication strategy for this scenario would be snapshot replication. Because the entire data mart is refreshed every weekend, we would need to perform a full refresh of the replicated database.

Depending upon the time and cost to do this, we may need to rethink how we refresh the data mart. An incremental refresh of the data mart might be more efficient because an incremental refresh could also be done of the replicated database.

3-

Fitchwood data mart weekly update?

Because data is static at all sites, the data mart would be refreshed weekly at the central location. If we assume that a full refresh is performed (from Chapter 9), then the replicated database would also need a full refresh. As mentioned in the answer for Problems and Exercises 10, if the data mart‘s method for loading data was changed to an incremental refresh, then the replicated database could also be incrementally refreshed.

3-

Fitchwood data distribution strategy Sales & Marketing?

Because there are ten different sites, changing the data mart refresh policy to employ an incremental refresh on a weekly basis is recommended. This would enable the distributed database to utilize snapshot replication with incremental refresh.

3-

Fitchwood data distribution strategy for own data?

Horizontal partitioning could be used. Each office would receive only a copy of records relevant to the agents employed by that office. This would be accomplished by partitioning the fact table as well as the dimension tables of the Fitchwood star schema (see Problems and Exercises in Chapter 9).

3-

Fitchwood data distribution strategy for OLTP data?

Depending upon the volume of transactions, snapshot replication would generally not be the best approach because there could be some delays in updating. The best approach would be to utilize synchronized replication if some delays could be tolerated. If the system could not tolerate delays, then a centralized system may need to be implemented.

3-

Web services & distributed databases?

Student answers will vary based on experience, understanding of chapter material, and depth of research.

3-

PVFC database recommendation?

A distributed database employing synchronized replication is recommended. Because order fulfillment could tolerate some delays, this approach would work well. A centralized approach would be more cost prohibitive because both facilities would always have to be connected.

Chapter 4

3-

454

PVFC centralized database approach?

If a centralized approach was used, there would be no delay in updating such data as inventory levels. Also, there would not be a need for replicating data across the distributed D B M S. However, depending upon the distance between facilities and the volume of data transmitted, there could be substantial telecommunication costs. Also, the replicated approach provides some level of redundancy should there be a hardware or database failure at one site.

3-

PVFC distributed database; recommended data distribution strategy A synchronized replication approach is recommended. This approach is applicable because a small amount of delay between updates could be tolerated, particularly if updates to inventory levels were timed to correspond to when actual orders were fulfilled.

3-

PVFC data distribution strategy?

Horizontal partitioning is recommended. The remote order processing facility would still be replicated, but only with data on items available to customers west of the Mississippi.

3-

PVFC data distribution strategy?

An additional table, ShipOrigin_T, should be added which contains information about the warehouse as well as the manufacturing facility, including a unique I D for both. The ProductOnHand column from the PRODUCT_T table must be removed. A new column, BuildType, must be added to PRODUCT_T. This column will indicate whether the item is custom built or a specialty item. A new table, ProductQuantity_T, which contains the ProductID, ShipOriginID, and QuantityOnHand, will be needed. This table will keep track of the quantity of products on-hand at both the warehouse and the manufacturing facility. Regarding distribution strategies, the order processing facility as well as the warehouse should have replicated copies of the database utilizing horizontal partitioning of the Customer_T table to exclude international and East Coast customers. The best strategy for replication would be synchronized replication.

3-

PVFC data distribution strategy?

Due to the additional geographic and time zone differences from the west of the Mississippi River office, P V F C should also consider the cost of telecommunications and data volume transfer. However, the suggestion to use a synchronized replication approach is still recommended due to the benefits of redundancy should there be a hardware or database failure at one site.

3-

PVFC data distribution strategy?

If unlimited, error-free bandwidth between all the locations from which the data have to be accessed was possible, then P V F C might consider a centralized approach to gain the no delay in inventory updates through this option. However, a replication strategy would still provide some measure of protection if there is a hardware or database failure at the main centralized site.

455

3-

Chapter 4

Telecommuting and data distribution strategy?

An organization with a high number of telecommuters would likely wish to preserve reliability (uptime) yet also have a measure of redundancy for possible outages. Replication via snapshots or synchronized replication would still seem to be a better solution for this scenario.

Answers to Field Exercises 3-

Organization with distributed database environment a. In order for the database to be considered distributed, the D BMS at each site must perform the following functions in addition to managing the local database: 1. Keep track of where data are located in a distributed dictionary.

2. Determine the location from which to retrieve requested data and the location at which to process each part of a distributed query.

3. If necessary, translate the request at one node using a local DBMS into the proper request to another node using a different DBMS and data model, and return data to the requesting node in the format accepted for that node.

4. Provide data management functions such as security, concurrency and deadlock control, query optimization, and failure recovery.

5. Provide consistency among copies of data across the remote sites.

b. The answer to this question depends largely on the organization visited. c. Following you, will find a detailed description of some problems related to each of the terms. A good approach to preparing the questions to be asked, is to put an emphasis on those aspects.

Location transparency. In general, it is easier to update data on one remote site than having to update data stored at multiple sites. To achieve location transparency, the distributed D BMS must have access to a current data dictionary that indicates the location(s) of all data across the network.

Replication transparency. Problems arise when one or more users attempt to update replicated data. The updates will have to be accomplished accurately and concurrently at all the sites holding a replicated copy.

Chapter 4

456

Failure transparency. It is achieved by overcoming failure problems, including system failures such as erroneous data, disk head crash, etc. Communications link failures are also a problem.

Concurrency control. Three basic approaches in achieving concurrency transparency are locking, versioning, and time-stamping. d. Query optimization. Both the user‘s formulation and the intelligence of the D BMS to develop a sensible plan for processing affect query processing. Current releases of D BMS do not provide all of the known features of distributed database products. For example, some products provide location transparency for read-only transactions, but they do not yet support global updates. e. The following factors determine the choice of a data distribution strategy: 1. Organizational forces. Funding availability, autonomy of organizational units, and the need for security.

2. Frequency and locality, or clustering of reference to data. In general, data should be located close to the applications that use those data.

3. Need for growth and expansion. The availability of processors on the network will influence where data may be located and when applications may be run and may indicate the need for expansion of the network.

4. Technological capabilities. Capabilities at each node and for DBMS coupled with the costs for acquiring and managing technology must be considered. Storage costs tend to be low, but the costs for managing complex technology can be great.

5. Need for reliable service. Mission-critical applications and very frequently required data encourage replication schemes.

3-

Distributed database features of a major database product This exercise will stimulate various research strategies, and answers received will depend on the current state of the products that students investigate.

3-

Organization with client/server database environment a. In client/server environments, it is easy to define a database with tables on several nodes in a local or wide area network. Once a user program establishes a linkage with each remote site and suitable database middleware is loaded, full location transparency is achieved. So, in client/server

457

Chapter 4

database form, distributed databases are readily available to any information systems developer, and heterogeneity of DBMS is possible. b. The following benefits of distributed systems have to be considered: 

Increased availability and reliability



Local control



Modular growth



Lower communication cost



Faster response

Student answers will vary depending upon the organization visited. Consider inviting a guest speaker to your class, if students cannot visit organizations on their own.

3-

This exercise will stimulate various research strategies, and answers received will depend on the current state of the products that students investigate.

Chapter 14 ObjectOriented Data Modeling Chapter Overview Please note that the material for this chapter is based upon the Web version of Chapter 14.

The purpose of this chapter is to introduce object-oriented modeling concepts. This chapter presents the UML notation and defines the key terms associated with object-oriented modeling. Most of the concepts learned in Chapters 2 and 3 correspond to concepts in object-oriented modeling, but as this chapter presents, the object-oriented modeling approach builds upon and extends the E ER model.

Chapter Objectives Specific student learning objectives are included in the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Explore the similarities between the major steps in database development and relevant elements in the object-oriented development process.

Chapter 4

458

2. Present the object-oriented model technique using the U ML notation to model real-world situations.

3. Emphasize the importance of building a model and thinking in abstract terms rather than worrying about implementation details in the analysis phase. Focus on describing what the intended system must do, rather than how it will be done.

4. Introduce the terminology associated with object-oriented modeling and recognize when to use generalization, aggregation, and composition relationships to more accurately represent real-world systems.

459

Chapter 4

Key Terms Abstract class Abstract operation Aggregation Association Association class Association role Behavior Class Class diagram

Class-scope attribute Class-scope operation Composition Concrete class Constructor operation Encapsulation Method Multiple classification Multiplicity

Object Object diagram Operation Overriding Polymorphism Query operation State Update operation Blank

Classroom Ideas 1. Review the major phases in the object-oriented development life cycle (Figure 14-1).

2. Use the sample object-oriented diagram shown in Figure 14-2 to ―jump-start‖ your students‘ understanding.

3. Use Figure 14-18 to demonstrate how complex business systems can be represented using the object-oriented notation.

4. Present the object-oriented concept of encapsulation.

5. Discuss the use of generalization and its role in simplifying complex systems. Reference Figure 14-9.

Also discuss how this object-oriented feature should facilitate easier maintenance of the system.

6. Discuss the use of overriding and the difference between overriding for extension versus restriction.

7. Discuss the use of aggregation versus association.

8. If your students are familiar with some object-oriented development environment, you can have them investigate (or you can show them in class) the various tools available in the environment to do the type of data modeling illustrated in this chapter.

Answers to Review Questions

Chapter 4

3-

Define each of the following key terms: a. Class. An entity that has a well-defined role in the application domain about which the organization wishes to maintain state, behavior, and identity b. State. Encompasses an object‘s properties (attributes and relationships) and the values those properties have c. Behavior. Represents how an object acts and reacts d. Encapsulation. The technique of hiding the internal implementation details of an object from its external view e. Operation. A function or a service that is provided by all the instances of a class f. Method. The implementation of an operation g. Constructor operation. An operation that creates a new instance of a class h. Query operation. An operation that accesses the state of an object but does not alter the state i. Update operation. An operation that alters the state of an object j. Abstract class. A class that has no direct instances, but whose descendants may have direct instances k. Concrete class. A class that can have direct instances l. Abstract operation Defines the form or protocol of the operation, but not its implementation m. Multiplicity. Indicates how many objects participate in a given relationship n. Class-scope attribute. An attribute of a class that specifies a value common to an entire class rather than a specific value of an instance o. Association class. An association that has attributes or operations of its own or participates in relationships with other classes p. Polymorphism. The same operation may apply to two or more classes in different ways q. Overriding. The process of replacing a method inherited from a superclass by a more specific

460

461

Chapter 4

implementation of that method in a subclass r. Multiple classification. An object is an instance of more than one class s. Composition. A part object which belongs to only one whole object and which lives and dies with the whole object t. Recursive aggregation. A part-of relationship between a component object and itself, treating itself as the aggregate object 3-

3-

Match the following terms to the appropriate definitions: c

method

b

abstract operation

f

aggregation

e

overriding

a

object

h

association class

d

composition

g

class

Contrast the following terms: a. Class; object. Class refers to the structure of an object, whereas an object refers to the individual instances. b. Attribute; operation. Attribute refers to an object‘s data; operation refers to a function or a service that is provided by all the instances of a class. c. State; behavior. State refers to an object‘s properties and is characterized by its attributes; behavior refers to how an object acts and reacts. d. Operation; method. An operation refers to an object‘s functions or services that are provided by all the instances of a class. A method refers to how these functions or services are implemented.

Chapter 4

462

e. Query operation; update operation. Both are operations, but the update operation alters the state of an object. f. Abstract class; concrete class. Instances of objects can be created from concrete classes; they cannot be created from abstract classes. g. Class diagram; object diagram. A class diagram shows the static structure of an object-oriented model, whereas the object diagram depicts instances of objects. h. Class-scope operation; class-scope attribute. Both class-scope operation and class-scope attribute are concepts that apply to the entire class instead of a specific instance of a class, but operation refers to class-level behavior and attribute to class-level characteristics. i. Composition; association. Composition is a specific form of an association, a named relationship between classes. Composition is a strong form of a whole-part association, one that specifies that a particular part can only be associated with a specific instance of a whole. For example, if composition specifies an association between a building (whole) and a room (part), it means that a specific room always belongs to a specific building and cannot be reconfigured to be part of another building. j. Generalization; aggregation. Generalization relates object classes through the process of abstracting common attributes, operations, and relationships of a set of object classes; whereas aggregation relates distinct object classes with a part-of association. k. Aggregation; composition. Aggregation relates the part-of relationship between objects that may or may not exist. A composition refers to objects that live and die with the whole object. l. Overriding for extension; overriding for restriction. Both types of overriding reference the overridden method. Overriding for extension adds new processing to the existing method, whereas overriding for restriction adds new restrictions that must be met in order to process the existing method.

3-

Activities involved in the object-oriented development life cycle phases: a. Object-oriented analysis. Develop a model of the real-world application showing its important properties

463

Chapter 4

b. Object-oriented design. Define how the application-oriented analysis model will be realized in the implementation environment c. Object-oriented implementation. Implement the design using a programming language and/or a database management system 3-

Compare and contrast the object-oriented model with the EER model: An object-oriented model is built around classes of objects, just as the E-R model is built around entity types. However, an object encapsulates both data and behavior, implying that we can use the objectoriented approach not only for data modeling, but also for process and event modeling.

3-

Why and when is it beneficial to use UML class diagrams rather than EER model: Unified Modeling Language (U M L) is a set of graphical notations backed by a common metamodel that is widely used both for business modeling and for specifying, designing, and implementing software system artifacts. A class diagram modeled with industry-standard tools (such as Visio) tends to have model elements that work together consistently with other underlying model elements of other U M L graphical diagrams (e.g., use-case, state, sequence, component, etc.).

Additionally, the use of U M L notation permits the modeling of complex object-oriented analysis and design models by developers. U M L notation can specify system requirements and also capture design decisions, as well as promote communication amongst other system designers, domain experts, users, and other stakeholders. U M L can represent multiple perspectives of a system through its different diagrams, yet can also support the synthesis of these varying perspectives into a single, consistent conceptual model for the designed and implemented system.

Thus, the use of U M L v s E E R notation is a decision that should be made in the context of the type of system under analysis and design. If the particular system is small, simple, and may only be used in a limited basis then E E R notation may be appropriate. If a particular system is larger, more complex, a clear object-oriented implementation, and likely to be used in a larger corporate setting among many developers, then using U M L could be a wiser choice as it will coordinate nicely with other elements of the larger system. ersu

3-

When to model an association relationship as an association class: When an association itself has attributes or operations of its own or when it participates in relationships with other classes, it is useful to model the association as an association class. Using an association class allows us to capture the behaviors/operations related to the association, rather than the participating classes.

Chapter 4

464

3-

Class diagrams of unary, binary, and ternary relationships, specifying multiplicities:

3-

Difference between the name of the association relationship and the role names linked to an association: The name of the association relationship refers to the association between or among instances of object classes. The role names linked to an association refer to the role played by the class attached to the end of the association near which the name appears.

3-

Role names for Review Question 14-8 association relationships:

465

3-

Chapter 4

Add operations to some of the classes you identified in Review Question 14-8:

Chapter 4

3-

466

An example of generalization: The discriminator is empType. The purpose of the discriminator is to show which property of an object class is being abstracted by a particular generalization relationship.

467

3-

Chapter 4

Extension of Review Question 14-12 adding at least one abstract class with at least one abstract operation, and indicating which features of a class are inherited by other classes:

Chapter 4

3-

468

Extension of Review Question 14-12, giving an example of polymorphism. The specific details of the implementation of the method computePay() depend on the subclass even though they all receive the same message from the classes that request the computePay() service.

469

Chapter 4

3-

Aggregation example:

3-

Usefulness of the O-O approach: The concepts of encapsulation, inheritance, and polymorphism make object-oriented modeling a powerful tool for developing complex systems.

3-

Instance of Vehicle in Figure 14-19: Because Vehicle is an abstract class, it cannot have any direct instances.

3-

UML types of diagrams?

In order to effectively model a complex system, it is necessary to have a small set of independent views illustrating the problem from multiple perspectives. The U M L provides many different types of diagrams in order to provide these different perspectives.

3-

Figure 14-20 Assignment Class?

The assignment class is an association class.

3-

Unary relationship as Association Class?

A unary relationship would have to be represented as an association class if the relationship has attributes, such as quantity or begin and end dates.

3 - Figure 14-21 elements: /availBalance is a derived attribute. /purchases is a derived relationship. /availBalance can be computed from the values for creditLine and balance. /purchases can be determined by examining the association between customers and items.

3 - Figure 14-22 elements: checkFee and monthlyFee are examples of class-scope attributes. calcFee is an abstract operation.

Chapter 4

470

3 - Class diagram in Figure 14-23 The class diagram shown in Figure 14-23 is an example of multiple inheritance.

3 - Class diagram in Figure 14-24 The class diagram shown in Figure 14-24 is an example of composition, a strong form of aggregation.

Although faculty could be represented as an aggregate of department, there really is not a need to do this because there will not be operations on department that will carry through to faculty. Also, faculty has independent relationships with other objects, such as courses.

Answers to Problems and Exercises 3 - Sample class diagram with at least four association roles:

3 - Student, University, Activity class diagram:

471

Chapter 4

3a. Middle-sized software vendor class diagram:

b. The class diagram allows us to capture the calcScore operation that underlies the problem domain.

3-

Class diagrams: a. Employee, Project class diagram

Chapter 4

b. University course catalog class diagram

c. Chemist, Project, Equipment class diagram

472

473

Chapter 4

d. Course, Section class diagram Note: Because primary keys are not included on class diagrams, there is no need to consider weak classes in this solution.

e. Physician, Patient class diagram

Chapter 4

474

475

3 - Student, Advisor class diagram:

Student, Advisor data model:

Chapter 4

Chapter 4

3 - Virtual Campus: Note: This is essentially the same task as in P&E 2-44. a. Phase I

476

477

Chapter 4

SITE -siteID -siteName -sitePurpose -siteAdministrator -siteCreationDate Is Associated With

1

0..*

POSTING

Is Made By

1

1..*

PERSON

ACCOUNT -accountID -userName -password -dateCreated -dateTerminated -dateTimeLastUsed

-postingDateTime -content -invisibleDate -removedStatus

1..* Is Owned By 1

0..* 0..*

b. The answer to question 2-44b applies here, too. c. Phase II

SITE

Is Associated With

-siteID -siteName -sitePurpose -siteAdministrator -siteCreationDate

Is a Response To

1

POSTING -postingDateTime -content -invisibleDate -removedStatus

0..* 0..*

Is Made By

0..*

1

1..*

0..*

-accountID -userName -password -dateCreated -dateTerminated -dateTimeLastUsed

1..* Is Owned By 1

0..* 0..*

READ -readDateTime

d. Phase III

PERSON

ACCOUNT

1

-personID -nickName <<Multivalued>>status -dateJoined -personName -twitterHandle -facebookPageLink -SMSContactNumber

-personID -nickName <<Multivalued>>status -dateJoined -personName -twitterHandle -facebookPageLink -SMSContactNumber

Chapter 4

478

SITE

Is Associated With

-siteID -siteName -sitePurpose -siteAdministrator -siteCreationDate

Is a Response To

1

POSTING -postingDateTime -content -invisibleDate -removedStatus

0..* 0..*

Is Made By

1..*

0..*

-accountID -userName -password -dateCreated -dateTerminated -dateTimeLastUsed

1..* Is Owned By 1

0..* 0..*

READ -readDateTime

COMPLAINT -complaintID -complaintDateTimePosted -complaintContent -resolutionCode -resolutionDate

e. Phase IV

PERSON

ACCOUNT

1

0..*

1

-personID -nickName <<Multivalued>>status -dateJoined -personName -twitterHandle -facebookPageLink -SMSContactNumber

Chapter 4

SITE

GROUP

Is a Response To

1

POSTING -postingDateTime -content -invisibleDate -removedStatus

0..* 0..*

Is Made By

COMPLAINT -complaintID -complaintDateTimePosted -complaintContent -resolutionCode -resolutionDate

0..*

1 1..*

0..*

-accountID -userName -password -dateCreated -dateTerminated -dateTimeLastUsed

PERSON

1..* Is Owned By 1

0..*

-readDateTime

-groupID -groupName -groupDateCreated -groupDateTerminated -purpose +countNumberOfMembers

1

0..*

READ

0..1 Is Limited To

ACCOUNT

1

0..*

1

Creates

Is Associated With

-siteID -siteName -sitePurpose -siteAdministrator -siteCreationDate

-personID -nickName <<Multivalued>>status -dateJoined -personName -twitterHandle -facebookPageLink -SMSContactNumber

Is Included In

479

0..* 0..* 1..*

Chapter 4

3 - Stillwater Antiques class diagram:

480

481

3 - Bottled Water distributor class diagram:

Chapter 4

Chapter 4

3 - Frequent Flyer class diagram, alternative A:

Frequent Flyer class diagram, alternative B:

482

483

Chapter 4

3 - Library This is a simple library solution; more classes could be added such as author, categories, etc. itemType includes Paperback, Hardback, audiobook C D, audiobook tape, audio C D, audio tape, video D V D, video Blu-Ray, and videotape; this could also be set up as reference data to the itemType in Item class. Based on reading the problem description, there do not appear to be special attributes or relationships based on the itemType thus no subclasses for itemType are presented in this solution.

Chapter 4

3 - Nonprofit organization class diagram

484

485

3 - Consulting firm class diagram:

Chapter 4

Chapter 4

3 - Landscaping & Snow Removal class diagram:

486

487

3 - See A Leopard Tours class diagram:

Chapter 4

Chapter 4

3 - Bank Accounts class diagram:

3 - Figure 14-9b revision class diagram

3 - Registration and Title System class diagram a.

488

489

Chapter 4

b.

Chapter 4

490

491

Chapter 4

3 - Emerging Electric class diagram: Please note for this exercise that the composite attribute of Address could be a class also, because both customer and location have common address attributes.

Chapter 4

492

493

Chapter 4

3 - Wonderful World of Wallcoverings class diagram

3 - DocIT Please note that this is essentially the same task as in P&E 2-XX. a. Phase I

Chapter 4

494 PATIENT/CONTACT 1

STAFF

1

1

APPOINTMENT

isResponsibleFor 0..*

-appointmentID -dateScheduled -timeScheduled 0..* -dateMade -timeMade -<<Multivalued>>reason

has

-staffID -jobTitle -staffGender -staffFirstName -staffLastName -staffMI -staffAddress -<<Multivalued>>credentials

-pcID -pcGender -pcDateOfBirth -pcFirstName -pcMI -pcLastName -pcAddress -<<Multivalued>>allergy

b. Phase II

Relationship

0..*

-natureOfRelationship 1 0..*

PATIENT/CONTACT 1

STAFF

c. Phase III

1

1

APPOINTMENT

isResponsibleFor 0..*

-appointmentID -dateScheduled -timeScheduled 0..* -dateMade -timeMade -<<Multivalued>>reason

has

-staffID -jobTitle -staffGender -staffFirstName -staffLastName -staffMI -staffAddress -<<Multivalued>>credentials

1

-pcID -pcGender -pcDateOfBirth -pcFirstName -pcMI -pcLastName -pcAddress -<<Multivalued>>allergy

495

Chapter 4

Relationship

0..*

-natureOfRelationship 1 0..*

PATIENT/CONTACT 1

STAFF

1

1

APPOINTMENT

isResponsibleFor 0..*

has

-staffID -jobTitle -staffGender -staffFirstName -staffLastName -staffMI -staffAddress -<<Multivalued>>credentials

1

-appointmentID -dateScheduled -timeScheduled 0..* -dateMade -timeMade -<<Multivalued>>reason

-pcID -pcGender -pcDateOfBirth -pcFirstName -pcMI -pcLastName -pcAddress -<<Multivalued>>allergy 1 has

1 isBasedOn

0..*

POLICY

CLAIM -claimID -action -dateOfAction -dateFiled -amountClaimed -amountPaid -datePaid -reasonCode

isAssociatedWith

0..*

0..*

1

-policyNumber -groupCode -sequence -typeOfCoverage 0..* underwrites

0..*

1

INSURANCECOMPANY -companyID -companyName -mailingAddress -IPAddress -companyContactPerson

d. Phase IV

Chapter 4

496

Relationship

0..*

-natureOfRelationship 1 0..*

PATIENT/CONTACT 1

STAFF

1

1

APPOINTMENT

1 has

-staffID -jobTitle -staffGender -staffFirstName -staffLastName -staffMI -staffAddress -<<Multivalued>>credentials

-appointmentID 0..* -dateScheduled -timeScheduled -dateMade -timeMade -<<Multivalued>>Reason

isResponsibleFor 0..*

1

-pcID -pcGender -pcDateOfBirth -pcFirstName -pcMI -pcLastName -pcAddress -<<Multivalued>>allergy 1 has

1

0..*

isBasedOn

POLICY

0..*

-claimID -action -dateOfAction -dateFiled -amountClaimed -amountPaid -datePaid -reasonCode

CLAIMPROCSTEP -claimProcStepID -dateProcessed -disputeCode -dateStageEnds -disputeStatus

0..*

1

-policyNumber -groupCode -sequence -typeOfCoverage 0..*

0..*

1 isAssociatedWith

1 0..*

isAssociatedWith

0..*

underwrites

isResponsibleFor

CLAIM

INSURANCECOMPANY -companyID -companyName -mailingAddress -IPAddress -companyContactPerson

497

Chapter 4

3 - Class scheduling System Class diagram

3 - Fin and Finicky Security Consultants: Please note in this solution that Estimates and ServicesPerformed both are related to location rather than customer. Although not explicitly stated as a business rule, it is assumed that an estimate or service performed would be for only one location, even if a customer owned multiple locations. Please see the following page for a solution.

Chapter 4

498

499

Chapter 4

3 - Fitchwood ER diagram converted to class diagram

3 - Facilities Management class diagram: This solution assumes that a single issue might have several ―history instances‖ associated with each issue.

Chapter 4

500

501

Chapter 4

3 - PVFC product components class diagram segment

3 - PVFC payment methods changes to class diagram.

Note: This solution refers to Figure 14-18 in the text. For this solution, the receivePaymt method has been overloaded for cases where an electronic payment is needed.

Chapter 4

502

3 - PVFC class diagram changes, derived associations: There are several derived associations (Customer purchases Product, Salesperson sells Product, Union Employee produces Product, Supplier supplies_for Product), although there are more to be found.

503

Chapter 4

Answers to Field Exercises

Chapter 4

504

3An example of a superclass/subclass relationship is with equity securities. Equity securities represent ownership shares in a corporation. Equity securities have attributes such as name, symbol, exchange, and price. A particular type of equity security is common stock. Preferred stock is another type of equity security that offers the holders fixed dividends each year. An attribute for preferred stock would be dividend rate.

3Examples of superclass/subclass relationships should be available in both service and manufacturing businesses. In the service business you will find several classes of employees, ranging from part-time to full-time with benefits. In the manufacturing business you might find several types of engineers (electrical, mechanical). Numerous operational business rules can be found in both types of businesses. In manufacturing, rules exist regarding quality standards and how overhead should be allocated to jobs. In the service industry, rules related to processes, such as how an item is purchased, represent sequences in the object-oriented models.

3The translation of the E E R (or E-R) diagram should map the entity types and attributes into classes. E E R diagrams can represent generalizations that also map to class diagrams. E E R and E-R notation are different than U M L. Association relationships remain the same. E-R diagrams usually show keys. Keys can be represented with class attribute names followed by the {key} notation.

3The main differences will most likely be in the notation used to describe the model. Students may find systems analysts using Booch, O M T, or their own custom notation. Students should see if the notations in use by systems analysis can represent use cases and class diagrams as shown in the chapter.

Appendix A Data Modeling Tools and Notation Appendix Overview The purpose of this appendix is to allow students to become familiar with some of the most popular tools used for developing conceptual data models with the E-R grammar. This appendix will assist in

505

Chapter 4

comparing the notation used in the text with the notation used in four commonly used packages: C A ER Win Data Modeler r9.7, Oracle S QL Developer Data Modeler 4.2, Sybase PowerDesigner 16.6, and Microsoft Visio Professional 2016.

Appendix Objectives From an instructor’s point of view, the objectives of this appendix are to: 1. Expose students to the look and feel of different modeling tools.

2. Illustrate the differences in notation of various modeling tools.

3. Review the entity symbols and relationships available with different modeling tools.

4. Discuss/review relationship and cardinality types: a. 1:1 b. 1:M c. M:N d. Optional participation e. Mandatory participation

5. Discuss and review types: a. Supertype b. Subtype 6. Discuss and review attributes: a. Key and nonkey attributes b. Null and not null definitions

7. Discuss and review keys: a. Candidate keys

Chapter 4

506

b. Primary keys c. Foreign keys d. Secondary keys

Classroom Ideas 1. Many of the products shown in this appendix have limited time trial versions. Visit the product Web sites to find the trial versions, which can then be used in class for illustrations or by students to explore the capabilities of these tools.

2. Be sure to review the definitions of entities; entity types; entity instances; relationship structures; cardinality and participation constraints; primary, secondary, and foreign keys; and ways of modeling business rules and constraints.

3. Students always learn best by seeing examples. Provide numerous examples using familiar situations: students, courses, and instructors; customers, orders, and products; waiters, meals, and bills. Show each situation with several different data modeling tools. If there are capabilities one product has that another does not have, point out these differences.

4. Emphasize the importance of this model as a tool, both to help the designer understand the system, and to show the users that the system is all-encompassing.

5. Divide the class into teams and have each team take the Pine Valley model for one tool and develop comments/observations about the data model produced using that tool.

6. Divide the class into teams and have each team develop a data model for a case study using different tools. Have the teams then compare their results and briefly discuss the strengths and weaknesses of each tool used.

7. You may have other tools that you want students to use other than those illustrated in this appendix or students may know of other tools available for data modeling. Use this appendix as a ―jumping-off‖ point for an exploration session of available tools and a discussion of how students might evaluate such options for an employer looking for a recommendation on what package to use in the ―real world.‖

507

Chapter 4

8. This appendix is a good opportunity to prepare students for the ―real world.‖ By pointing out the differences in the tools they may have at their disposal at work, the instructor can demonstrate the importance of understanding general database concepts and developing flexibility in how they will be able to accomplish the tasks they are assigned at work.

9. Use the web to find other tools that might approximate the drawing templates needed to represent conceptual data models. In particular, with the rise of tablet computing, explore some of the ―draw by hand‖ applications that would support ad-hoc modeling during a quick meeting with a client or enduser. Coordinate an in-class (or online) discussion about the pros/cons of various tools that a data analyst may have at hand to capture data needs.

Appendix B Advanced Normal Forms Appendix Overview The purpose of this appendix is to introduce normalized forms beyond third normal form (3N F). 3NF is adequate for most practical applications, but some exposure to higher forms is advantageous. When anomalies in the 3NF model are encountered, students need to know how to approach and solve these issues. The higher forms covered in this appendix are Boyce-Codd Normal Form (BCNF)—a stronger 3NF—and fourth normal form (4N F). Interested readers are pointed to additional sources for background on Domain-key Normal Form (DKNF) and fifth normal form (5N F).

Appendix Objectives From an instructor’s point of view, the objectives of this appendix are to: 1. Expose students to the definitions of higher forms.

2. Explain what circumstances require the use of a higher normal form.

3. Illustrate these circumstances with concrete examples.

4. Define what a multivalued dependency is.

Chapter 4

508

Key Terms 

Boyce-Codd Normal Form (BCNF)



Fourth normal form (4NF)



Multivalued dependency

Classroom Ideas 1. Be sure to review the definitions of anomalies and why they cause problems in the relational model.

2. Define/review all the terms used in normalization: primary, secondary, and foreign keys; full functional dependency, transitive dependency, partial-key dependencies, and multivalued dependencies.

3. Discuss and review the first three normal forms for context.

4. Emphasize the importance of testing proposed databases for anomalies in 3NF, i.e., populating tables to identify problems in the data set. Use a variety of record instances.

5. Students learn best by example. Do several examples in class using familiar scenarios: students, courses, and instructors; students, advisors, and majors; students‘ food and drink preferences.

6. Separate the class into groups. Have each group try to come up with an example of all or one assigned advanced normal form. Have each group present the problem, define the anomaly, and present and defend the solution.

7. Either in-class, or as an out-of-class assignment, review the textbook suggested Web site that reviews a simple guide to first through fifth normal forms. Ask the students to find other web resources related to normalization and normal forms that help students to understand and practice these skills.

Appendix C Data Structures

509

Chapter 4

Appendix Overview The purpose of this appendix is to discuss basic data structures. Students who have had a data structures course or covered data structures in a programming course will find this appendix to be a good review. Those who have not had any exposure to data structures can use this appendix to gain a basic understanding of data structures. The appendix begins with a discussion of pointers and the three types of pointers that are generally used. Next, the building blocks of data structures are discussed. A discussion of linear data structures is followed by a discussion of trees.

Appendix Objectives From an instructor’s point of view, the objectives of this appendix are to: 1. Review pointers and the three different types of pointers.

2. Discuss the building blocks of data structures.

3. Discuss/review linear data structures: a. stacks b. queues c. sorted lists d. multilists

4. Discuss the hazards of chain structures.

5. Discuss trees, particularly balanced trees.

Classroom Ideas 1. If your students have had exposure to data structures in another course (possibly a programming course), review pointers, particularly in light of their uses within a database management system.

2. Students always learn best by examples. Provide several examples of pointers in a language that students are familiar with, such as C++ or C.

Chapter 4

510

3. Discuss the differences between the three types of pointers, using Figure C-1. Discuss the various characteristics described in Table C-1.

4. Emphasize that all data structures are built around building blocks. Contrast address sequential with pointer sequential connection methods. Compare data direct placement with data indirect placement.

Once again, showing students with actual examples will reinforce the concepts.

5. Review and/or discuss stacks, queues, sorted lists, and linked lists. Show some examples in a language familiar to the students.

6. If your students have had a course in data structures, for a review divide the class into teams. Have each team design a small database using one type of data structure. You might include linked lists, double linked lists, sorted lists, and stacks. The students should write code for basic functionality, such as the ability to add a record, delete a record, lookup a record and modify a record. Have each team present their mini-projects and then discuss the merits of each approach.

7. Discuss problems that can occur when using chain structures.

8. Discuss trees and how they can be used for database management systems.

9. Have the students discuss in class (or write a brief paper on) why it is important for a database administrator to know about data structures. Ask them for what tasks performed by a D BA would it be helpful to know about the data structures shown in this appendix. Ask them specifically about whether issues of database security, integrity, and recoverability relate to this appendix.

Pine Valley Furniture Company Databases The Modern Database Management web sites for both instructors and students contain two versions (called ‘Book’ and ‘Expanded’) of Pine Valley Furniture Company (PVFC), based on Figure 2-22 of the textbook. This figure shows a subset of the attributes available in the databases.

The files for the book version, covered here, contains the tables of Figure 2-22, along with much of the sample data used in Chapter 1, 5, and 6. The tables and data are stored in five ways.

1. There is an MS Access version. Use of this version requires that MS Access or later be loaded and operational on a computer. Copy the file PVFC_MDM_13e.mdb to the hard drive and open the file. This version also includes the MS Access queries that match most of the SQL queries demonstrated in Chapters 5 and 6. You may convert the file to the current version of Access you are using.

2. There is an Oracle 13c version. An SQL script to create the tables and populate them in Oracle 13c is also included. Use of this script assumes access to Oracle 11g and SQL*Plus 3.3 (or later, or a recent version of Oracle’s SQL Developer), and authorization to create tables. Move the CREATEPVFC_MDM_13e.sql script to the hard drive. After entering SQL*Plus, at the SQL prompt type Start X:\CREATEPVFC_MDM_13e.sql, where X indicates the location of the SQL script. Pressing enter should cause the script to run, creating the tables and populating them. If you have SQL Server Management Studio or SQL Server Management Studio Express installed, this file, with its .sql extension, may be identified as a SQL Server file. However, it will not run under SQL server, because it uses Oracle syntax.

3. There is a SQL Server 2005 version. The CREATE and INSERT scripts are zipped in a file named PVFScripts_MDM_13e.zip. The database can be created with a script called PVFDB_MDM_13e.sql. Please make sure that you update the CREATE DATABASE command so that it refers to the correct location in your local environment.

4. There is a comma-delimited, flat-file, ASCII version in one zipped file, PVFC-ASC_MDM_13e.ZIP. These flat files are provided for use with other database management systems. They may also be imported into MS Excel.

5. The database is also available on Teradata University Network (www.teradatauniversitynetwork.com) for faculty and students.

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 1

This textbook version of PVFC implements the data model depicted in Figure 2-22. The data contained in the tables are only that data used in the examples in Chapters 1, 5, and 6 to demonstrate SQL. Thus, the student may set up the database(s) and use them to compare MS Access SQL, SQL Server 2008 SQL and Oracle 12c SQL to the ANSI SQL examples of the text. Many of the queries demonstrated in Chapters 5 and 6 have been created in the MS Access version and are available in PVFC_MDM_13e.mdb (the query names end with the page number to help you find where the query is presented in the text).

This database is intended to provide students with an understanding of the implementation of the data model developed in Chapter 2 in a relational database management system. It should also allow them to explore basic query syntax in either Oracle 12c or MS Access.

Both versions of the PVFC database are also available on Teradata University Network (www.teradatauniversitynetwork.com for faculty and students). Faculty must define on Teradata University Network which databases students can use because our databases are not the only ones available on TUN. See instructions on TUN for creating a course environment for students.

The following documentation provides a more detailed explanation of the data in the Book version of the PVFC database – the version illustrated in the textbook.

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 2

Book Pine Valley Furniture Company (PVFC) Datasets The following ASC files are provided for this database (in folder PVFCASC_MDM_13e): Customer_T.asc CustomerID, CustomerName, CustomerAddress, CustomerCity, CustomerState, CustomerPostalCode 1, 'Contemporary Casuals', '1355 S Hines Blvd', 'Gainesville', 'FL', '32601-2871' 2, 'Value Furniture', '15145 S.W. 17th St.', 'Plano', 'TX', '75094-7743' 3, 'Home Furnishings', '1900 Allard Ave.', 'Albany', 'NY', '12209-1125' 4, 'Eastern Furniture', '1925 Beltline Rd.', 'Carteret', 'NJ', '07008-3188' 5, 'Impressions', '5585 Westcott Ct.', 'Sacramento', 'CA', '94206-4056' 6, 'Furniture Gallery', '325 Flatiron Dr.', 'Boulder', 'CO', '80514-4432' 7, 'Period Furniture', '394 Rainbow Dr.', 'Seattle', 'WA', '97954-5589' 8, 'California Classics', '816 Peach Rd.', 'Santa Clara', 'CA', '96915-7754' 9, 'M and H Casual Furniture', '3709 First Street', 'Clearwater', 'FL', '34620-2314' 10, 'Seminole Interiors', '2400 Rocky Point Dr.', 'Seminole', 'FL', '34646-4423' 11, 'American Euro Lifestyles', '2424 Missouri Ave N.', 'Prospect Park', 'NJ', '07508-5621' 12, 'Battle Creek Furniture', '345 Capitol Ave. SW', 'Battle Creek', 'MI', '49015-3401' 13, 'Heritage Furnishings', '66789 College Ave.', 'Carlisle', 'PA', '17013-8834' 14, 'Kaneohe Homes', '112 Kiowai St.', 'Kaneohe', 'HI', '96744-2537' 15, 'Mountain Scenes', '4132 Main Street', 'Ogden', 'UT', '84403-4432'

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 3

Territory_T.asc TerritoryID, TerritoryName 1, 'SouthEast' 2, 'SouthWest' 3, 'NorthEast' 4, 'NorthWest' 5, 'Central'

DoesBusinessIn_T.asc CustomerID, TerritoryID 1, 1 1, 2 2, 2 3, 3 4, 3 5, 2 6, 5

Salesperson_T.asc SalespersonID, SalespersonName, SalespersonPhone, SalespersonFax, TerritoryID 1, 'Doug Henny', '8134445555', '', 1 2, 'Robert Lewis', '8139264006', '', 2 3, 'William Strong', '5053821212', '', 3 4, 'Julie Dawson', '4355346677', '', 4 5, 'Jacob Winslow', '2238973498', '', 5

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 4

Employee_T.asc EmployeeID, EmployeeName, EmployeeAddress, EmployeeCity, EmployeeState, EmployeeZipCode, EmployeeDateHired, EmployeeSupervisor '123-44-345', 'Jim Jason', '2134 Hilltop Rd', '', 'TN', '', '12/Jun/99', '454-56-768' '454-56-768', 'Robert Lewis', '17834 Deerfield Ln', 'Nashville', 'TN', '', '01/Jan/99', ''

Skill_T.asc SkillID, SkillDescription 'BS12', '12in Band Saw' 'QC1', 'Quality Control' 'RT1', 'Router' 'SO1', 'Sander-Orbital' 'SB1', 'Sander-Belt' 'TS10', '10in Table Saw' 'TS12', '12in Table Saw' 'UC1', 'Upholstery Cutter' 'US1', 'Upholstery Sewer' 'UT1', 'Upholstery Tacker'

EmployeeSkills_T.asc EmployeeID, SkillID '123-44-345', 'BS12' '123-44-345', 'RT1' '454-56-768', 'BS12'

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 5

Order_T.asc OrderID, OrderDate, CustomerID 1001, '21/Oct/18', 1 1002, '21/Oct/18', 8 1003, '22/Oct/18', 15 1004, '22/Oct/18', 5 1005, '24/Oct/18', 3 1006, '24/Oct/18', 2 1007, '27/Oct/18', 11 1008, '30/Oct/18', 12 1009, '05/Nov/18', 4 1010, '05/Nov/18', 1

ProductLine_T.asc ProductLineID, ProductLineName 1, 'Cherry Tree' 2, 'Scandinavia' 3, 'Country Look'

Product_T.asc ProductID, ProductDescription, ProductFinish, ProductStandardPrice, ProductLineID 1, 'End Table', 'Cherry', 175, 1 2, 'Coffee Table', 'Natural Ash', 200, 2 3, 'Computer Desk', 'Natural Ash', 375, 2 4, 'Entertainment Center', 'Natural Maple', 650, 3 5, 'Writers Desk', 'Cherry', 325, 1 6, '8-Drawer Desk', 'White Ash', 750, 2 7, 'Dining Table', 'Natural Ash', 800, 2 8, 'Computer Desk', 'Walnut', 250, 3 PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 6

OrderLine_T.asc OrderID, ProductID, OrderedQuantity 1001, 1, 2 1001, 2, 2 1001, 4, 1 1002, 3, 5 1003, 3, 3 1004, 6, 2 1004, 8, 2 1005, 4, 4 1006, 4, 1 1006, 5, 2 1006, 7, 2 1007, 1, 3 1007, 2, 2 1008, 3, 3 1008, 8, 3 1009, 4, 2 1009, 7, 3 1010, 8, 10

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 7

ProducedIn_T.asc ProductID, WorkCenterID

RawMaterial_T.asc MaterialID, MaterialName, UnitOfMeasure, MaterialStandardCost

Supplies_T.asc VendorID, MaterialID, SuppliesUnitPrice

Vendor_T.asc VendorID, VendorName, VendorAddress, VendorCity, VendorState, VendorZipcode

General Notes on ASC and Other Versions of the PVFC Book Datasets: 1. There may be several misspellings of data values so students can deal with data quality issues.

2. There are several examples of missing data so students can deal with this issue (some data are actually missing, some simply represents null FKs for an optional cardinality).

3. The ProducedIn_T table is included, but it includes a FK of WorkCenterID, and WorkCenter_T is not included; there is no data in ProducedIn_T, but there still is an unresolved FK constraint reference for students to deal with.

4. Four tables are not populated with data (see above), but ASC files are provided with the column names; these tables can be used for exercises with INSERT and other commands.

5. Three tables (Uses_T, WorksIn_T, and WorkCenter_T) are not included; these can be used for DDL exercises and students can determine from the text what columns should be included in each table.

6. There are purposeful differences between this ASC dataset and other versions of this data: a. Oracle: All DDL and data creation statements are in one compressed file, CREATEPVFC_MDM_13e.sql: i. Employee_T includes an EmployeeBirthDate column ii. There are additional columns in Vendor_T iii. Two rows for WorkCenter_T and one row for WorksIn_T are provided iv. Uses_T is defined but no data are provided

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 8

b. SQL Server: Three files are in compressed folder PVFCScripts_MDM_13e – PVTableInsertsALL_MDM_13e.sql , PVTablesALL_MDM_13e.sql, and PVFDB_MDM_13e.sql: i. There are no data for the RawMaterials_T, Vendor_T, Supplies_T, ProducedIn_T, and Uses_T, although all are defined in the database. ii. PKs are auto created on insert for many of the tables, so PKs may not agree with those in the other data files; Order_T does include the OrderID column with data as in the other versions of this table. iii. Two rows are provided for WorkCenter_T and one row for WorksIn_T. c. Access Database: File PVFC_MDM_13e.mdb i. There are no data for the RawMaterials_T, Vendor_T, Supplies_T (actually contains one bad row with data in only one nonPK column), ProducedIn_T, and Uses_T, although all are defined in the database. ii. Some columns have captions, so the column heading may not be exactly the column name. iii. Two rows are provided for WorkCenter_T and one row for WorksIn_T The following table summarizes the differences between the various versions of the PVFC Book database version:

Table

Figure 2-22

ASCII

Customer_T

TUN CustomerPostalCode is VARCHAR(10)

Called Has Skill

No data

Product_T ProductLine_T RawMaterial_T

MS SQL

Has EmployeeBirthDate attribute that is not in ASCII version

Order_T OrderLine_T ProducedIn_T

MS Access

CutomerPostalCode is VARCHAR2(10)

DoesBusinessIn_T Employee_T

EmployeeSkills_T

Oracle

ProductID is NUMBER(11,0) No data

No data

No data

No data

No data

No data

No data; UnitofMeasure is MaterialUnitofMeasure

ProductLineID is NUMBER(11,0) No data

No data

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Page 9

Salesperson_T Skill_T Supplies_T

No data

No data

No data

No data

No data

Territory_T Vendor_T

No data

No data; Has VendorFax, VendorPhone, VendorContact, VendorTaxID attributes that are not in ASCII version No data

No Data

No data

No data

Has two data rows

Has two data rows

Has one data row

Has one data row

No data Has two data rows Has one data row

No data; Has VendorFax, VendorPhone, VendorContact, VendorTaxID attributes that are not in ASCII version Not included

Uses_T WorkCenter_T

WorksIn_T

Not included Not included

Not included

Database overall

PVFC Book Version Database Documentation Modern Database Management, 13th Edition

Not all PK and FK constraints and required attributes specified; Relationships diagram does not show all relationships

Not included

Not included

Database is named db_pvfc_mdm_13_std; FK constraints are not specified; datatypes are sometimes slightly different, but the data are the same

Page 10

FAME The Modern Database Management 13e web site for instructors contains four files related to the new Forondo Artist Management Excellence (FAME) case: •

Create_tables_FAME.sql includes an Oracle 13c script for creating the tables.

•

Populate_tables_FAME.sql includes an Oracle 13c script for populating the tables.

•

FAME_queries_Chapter5.sql and FAME_queries_Chapter6.sql include sample queries for Chapter 5 and Chapter 6, respectively.

FAME Database Documentation

Modern Database Management, 12th Edition

Page 1

SQL Server Documentation Installing the SQL Server Tables for Pine Valley Furniture.

Run Scripts to create the database and tables in SQL Server using SQL Server Management Studio (normal version or express version).

1. Download the PVFScripts_MDM_13e.zip and PVFDB_MDM_13e.sql files, and

unzip to extract the two files from PVFScripts_MDM_13e.zip.

2. Using SQL Server Management Studio, open the file below to run it. This script should use the master database to create the PVF database.

PVFDB_MDM_13e.sql – Creates the SQL Server database. If you already have a database set up, you do not need to run this. If you do not have a database set up, then you can use this script to create an SQL Server database. Before running, edit the Create Database statement to specify the drive and directories where you want your database stored.

[Note: Instead of running the PVFDB_MDM_13e.sql script, you can create the database manually by right-clicking on the Databases folder in the Object Explorer window, and choose “New Database”, then create the PVF database by filling in the form.]

3. After creating the PVF database, make sure that after opening the other two scripts, you have selected the PVF database before running (or they might be created in the master database by mistake).

PVFTablesALL_MDM_13e.sql – Creates the PVF Tables in whatever database the scripts are run in.

PVFTableInsertsALL_MDM_13e.sql – runs a batch of insert statements to load data into the PVF tables.

Note: There are no insert statements for the following tables (similar to the MS Access version): • Raw_Material_t • Vendor_t • Supplies_t • Produced_in_t • Uses