QUESTIONS-

M o dern D

atabase M anagem

ent H

o ffer • R

am esh • To

pi T

H IR

T E

E N

T H

E

D IT

IO N

GLOBAL EDITION

GLOBAL EDITION

This is a special edition of an established title widely used by colleges and universities throughout the world. Pearson published this exclusive edition for the benefit of students outside the United States and Canada. If you purchased this book within the United States or Canada, you should be aware that it has been imported without the approval of the Publisher or Author.

G L O

B A

L E

D IT

IO N

The thirteenth edition of Modern Database Management expands and improves its coverage of the latest principles, concepts, and technologies. With a strong focus on business systems development, the book explores the foundational knowledge and skills that database developers need for professional success. This edition is also designed to be more accessible to readers and includes a new framework to better understand data management from a broader per- spective.

This text offers the following features and resources to help students under- stand the role of databases in organizations:

• Review questions test students’ knowledge on various topics and have been up- dated to support new and enhanced chapter material.

• Problems and Exercises give students the opportunity to use the data sets pro- vided for the text and apply the concepts covered in each chapter to answer the questions.

• Field Exercises are “hands-on” mini-cases that range from directed field trips to Internet searches.

• A Case spread across the first three chapters and involved in many other chapters gives hands-on experience with the concepts and tools covered in the chapter.

• Each chapter has Project Assignments linked to the case studies discussed in the chapter that can be completed individually or in small project teams.

Jeffrey A. Hoffer V. Ramesh

Heikki Topi

Modern Database

Management THIRTEENTH EDITION

Hoffer_13_1292263350_Final.indd 1 03/04/19 7:18 PM

MODERN DATABASE MANAGEMENT Jeffrey A. Hoffer University of Dayton

V. Ramesh Indiana University

Heikki Topi Bentley University

T H I R T E E N T H E D I T I O N

G L O B A L E D I T I O N

Harlow, England • London • New York • Boston • San Francisco • Toronto • Sydney • Dubai • Singapore • Hong Kong Tokyo • Seoul • Taipei • New Delhi • Cape Town • Sao Paulo • Mexico City • Madrid • Amsterdam • Munich • Paris • Milan

A01_HOFF3359_13_GE_FM.indd 1 12/04/19 11:44 AM

Vice President, IT & Careers: Andrew Gilfillan Senior Portfolio Manager: Samantha Lewis Managing Producer: Laura Burgess Associate Content Producer: Stephany Harrington Content Producer, Global Edition: Sonam Arora Assistant Acquisitions Editor, Global Edition: Rosemary Iles Senior Project Editor, Global Edition: Daniel Luiz Manager, Media Production, Global Edition: Gargi Banerjee Manufacturing Controller, Production, Global Edition: Kay Holman Portfolio Management Assistant: Madeline Houpt Director of Product Marketing: Brad Parkins Product Marketing Manager: Heather Taylor

Product Marketing Assistant: Jesika Bethea Field Marketing Manager: Molly Schmidt Field Marketing Assistant: Kelli Fisher Cover Image: mistery/Shutterstock Vice President, Product Model Management: Jason Fournier Senior Product Model Manager: Eric Hakanson Lead, Production and Digital Studio: Heather Darby Digital Studio Course Producer: Jaimie Noy Program Monitor: Danica Monzor, SPi Global Full-Service Project Management: Neha Bhargava, Cenveo® Publisher Services Composition: Cenveo Publisher Services

Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook appear on the appropriate page within text.

Microsoft and/or its respective suppliers make no representations about the suitability of the information contained in the documents and related graphics published as part of the services for any purpose. All such documents and related graphics are provided “as is” without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all warranties and conditions of merchantability, whether express, implied or statutory, fitness for a particular purpose, title and noninfringement. In no event shall Microsoft and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from the services.

The documents and related graphics contained herein could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Microsoft and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time. Partial screen shots may be viewed in full within the software version specified.

Trademarks Microsoft® Windows®, and Microsoft Office® are registered trademarks of the Microsoft Corporation in the U.S.A. and other countries. This book is not sponsored or endorsed by or affiliated with the Microsoft Corporation.

Pearson Education Limited

KAO Two KAO Park Harlow CM17 9NA United Kingdom

and Associated Companies throughout the world

Visit us on the World Wide Web at: www.pearsonglobaleditions.com

© Pearson Education Limited 2020

The rights of Jeffrey A. Hoffer, V. Ramesh, and Heikki Topi to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.

Authorized adaptation from the United States edition, entitled Modern Database Management, 13th edition, ISBN 978-0-13-477365-0, by Jeffrey A. Hoffer, V. Ramesh, and Heikki Topi, published by Pearson Education © 2019.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior written permission of the publisher or a license permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, Saffron House, 6–10 Kirby Street, London EC1N 8TS.

All trademarks used herein are the property of their respective owners. The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners.

ISBN 10: 1-292-26335-0

ISBN 13: 978-1-292-26335-9

eBook ISBN: 978-1-292-26341-0 British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library.

10 9 8 7 6 5 4 3 2 1 Typeset in Palatino LT Pro by Cenveo® Publisher Services

To Patty, for her sacrifices, encouragement, and support for more than 35 years of being a textbook author widow. To my students and colleagues, for being

receptive and critical and for challenging me to be a better teacher.

—J.A.H.

To Gayathri, for her sacrifices and patience these past 25 years. To my parents, for letting me make the journey abroad, and to my cat, Raju, who was a part of our

family for more than 20 years.

—V.R.

To Anne-Louise, for her loving support, encouragement, and patience. To Leila and Saara, whose laughter and joy of life continue to teach me about what is

truly important. To my teachers, colleagues, and students, from whom I continue to learn every day.

—H.T.

A01_HOFF3359_13_GE_FM.indd 3 12/04/19 11:44 AM

A01_HOFF3359_13_GE_FM.indd 4 12/04/19 11:44 AM

This page intentionally left blank

BRIEF CONTENTS

Part I The Context of Database Management 35

Chapter 1 The Database Environment and Development Process 37

Part II Database Analysis and Logical Design 87

Chapter 2 Modeling Data in the Organization 89 Chapter 3 The Enhanced E-R Model 149 Chapter 4 Logical Database Design and the Relational Model 187

Part III Database Implementation and Use 239

Chapter 5 Introduction to SQL 241 Chapter 6 Advanced SQL 285 Chapter 7 Databases in Applications 331 Chapter 8 Physical Database Design and Database Infrastructure 367

Part IV Advanced Database Topics 419

Chapter 9 Data Warehousing and Data Integration 421 Chapter 10 Big Data Technologies 478 Chapter 11 Analytics and Its Implications 508 Chapter 12 Data and Database Administration with Focus

on Data Quality 537 Glossary of Acronyms 563 Glossary of Terms 565 Index 573

Available Online at www.pearsonglobaleditions.com

Chapter 13 Distributed Databases 13-1 Chapter 14 Object-Oriented Data Modeling 14-1

Appendices

Appendix A Data Modeling Tools and Notation A-1 Appendix B Advanced Normal Forms B-1 Appendix C Data Structures C-1

5

A01_HOFF3359_13_GE_FM.indd 5 12/04/19 11:44 AM

A01_HOFF3359_13_GE_FM.indd 6 12/04/19 11:44 AM

This page intentionally left blank

CONTENTS

Preface 23

Part I The Context of Database Management 35 An Overview of Part I 35

Chapter 1 The Database Environment and Development Process 37 Learning Objectives 37 Data Matter! 38 Introduction 39 Basic Concepts and Definitions 40

Data 40 Data versus Information 41 Metadata 42

Traditional File Processing Systems 43 File Processing Systems at Pine Valley Furniture Company 43 Disadvantages of File Processing Systems 44

Program-Data DePenDence 44 DuPlication of Data 44 limiteD Data Sharing 44 lengthy DeveloPment timeS 44 exceSSive Program maintenance 45

The Database Approach 45 Data Models 45

entitieS 45 relationShiPS 45

Relational Databases 46 Database Management Systems 47 Advantages of the Database Approach 47

Program-Data inDePenDence 47 PlanneD Data reDunDancy 48 imProveD Data conSiStency 48 imProveD Data Sharing 48 increaSeD ProDuctivity of aPPlication DeveloPment 48 enforcement of StanDarDS 49 imProveD Data Quality 49 imProveD Data acceSSibility anD reSPonSiveneSS 49 reDuceD Program maintenance 50 imProveD DeciSion SuPPort 50 cautionS about DatabaSe benefitS 50 coStS anD riSkS of the DatabaSe aPProach 50 new, SPecializeD PerSonnel 50 inStallation anD management coSt anD comPlexity 51 converSion coStS 51 neeD for exPlicit backuP anD recovery 51 organizational conflict 51

Integrated Data Management Framework 51 Components of the Database Environment 52

7

A01_HOFF3359_13_GE_FM.indd 7 12/04/19 11:44 AM

8 Contents

The Database Development Process 54 Systems Development Life Cycle 55

Planning—enterPriSe moDeling 55 Planning—concePtual Data moDeling 55 analySiS—concePtual Data moDeling 56 DeSign—logical DatabaSe DeSign 57 DeSign—PhySical DatabaSe DeSign anD Definition 57 imPlementation—DatabaSe imPlementation 57 maintenance—DatabaSe maintenance 58

Alternative Information Systems Development Approaches 58 Three-Schema Architecture for Database Development 59 Managing the People Involved in Database Development 61

Evolution of Database Systems 61 1960s 63 1970s 63 1980s 63 1990s 64 2000 and Beyond 64

The Range of Database Applications 64 Personal Databases 65 Departmental Multi-Tiered Client/Server Databases 65 Enterprise Applications 66

enterPriSe SyStemS 66 Data warehouSeS 67 Data lake 68

Developing a Database Application for Pine Valley Furniture Company 69

Database Evolution at Pine Valley Furniture Company 70 Project Planning 70 Analyzing Database Requirements 71 Designing the Database 74 Using the Database 76 Administering the Database 77 Future of Databases at Pine Valley 77

Summary 78 • Key Terms 79 • Review Questions 79 • Problems and Exercises 80 • Field Exercises 82 • References 83 • Further Reading 83 • Web Resources 84

CASE: Forondo Artist Management Excellence Inc. 85

Part II Database Analysis and Logical Design 87 An Overview of Part II 87

Chapter 2 Modeling Data in the Organization 89 Learning Objectives 89 Introduction 89 The E-R Model: An Overview 92

Sample E-R Diagram 92 E-R Model Notation 94

Modeling the Rules of the Organization 95

A01_HOFF3359_13_GE_FM.indd 8 12/04/19 11:44 AM

Contents 9

Overview of Business Rules 96 the buSineSS ruleS ParaDigm 96

Scope of Business Rules 97 gooD buSineSS ruleS 97 gathering buSineSS ruleS 98

Data Names and Definitions 98 Data nameS 98 Data DefinitionS 99 gooD Data DefinitionS 99

Modeling Entities and Attributes 101 Entities 101

entity tyPe verSuS entity inStance 101 entity tyPe verSuS SyStem inPut, outPut, or uSer 101 Strong verSuS weak entity tyPeS 102 naming anD Defining entity tyPeS 103

Attributes 105 reQuireD verSuS oPtional attributeS 105 SimPle verSuS comPoSite attributeS 106 Single-valueD verSuS multivalueD attributeS 106 StoreD verSuS DeriveD attributeS 107 iDentifier attribute 107 naming anD Defining attributeS 108

Modeling Relationships 110 Basic Concepts and Definitions in Relationships 111

attributeS on relationShiPS 112 aSSociative entitieS 112

Degree of a Relationship 114 unary relationShiP 115 binary relationShiP 116 ternary relationShiP 116

Attributes or Entity? 117 Cardinality Constraints 119

minimum carDinality 119 maximum carDinality 120

Some Examples of Relationships and Their Cardinalities 120 a ternary relationShiP 121

Modeling Time-Dependent Data 122 Modeling Multiple Relationships Between Entity Types 124 Naming and Defining Relationships 126

E-R Modeling Example: Pine Valley Furniture Company 127 Database Processing At Pine Valley Furniture 130

Showing Product Information 130 Showing Product Line Information 130 Showing Customer Order Status 131 Showing Product Sales 132

Summary 133 • Key Terms 134 • Review Questions 134 • Problems and Exercises 135 • Field Exercises 145 • References 146 • Further Reading 146 • Web Resources 146

CASE: Forondo Artist Management Excellence Inc. 147

A01_HOFF3359_13_GE_FM.indd 9 12/04/19 11:44 AM

10 Contents

Chapter 3 The Enhanced E-R Model 149 Learning Objectives 149 Introduction 149 Representing Supertypes and Subtypes 150

Basic Concepts and Notation 151 an examPle of a SuPertyPe/SubtyPe relationShiP 152 attribute inheritance 153 when to uSe SuPertyPe/SubtyPe relationShiPS 153

Representing Specialization and Generalization 154 generalization 154 SPecialization 155 combining SPecialization anD generalization 156

Specifying Constraints in Supertype/Subtype Relationships 157 Specifying Completeness Constraints 157

total SPecialization rule 157 Partial SPecialization rule 157

Specifying Disjointness Constraints 158 DiSjoint rule 158 overlaP rule 159

Defining Subtype Discriminators 159 DiSjoint SubtyPeS 159 overlaPPing SubtyPeS 160

Defining Supertype/Subtype Hierarchies 161 an examPle of a SuPertyPe/SubtyPe hierarchy 162 Summary of SuPertyPe/SubtyPe hierarchieS 162

EER Modeling Example: Pine Valley Furniture Company 162 Entity Clustering 166 Packaged Data Models 169

A Revised Data Modeling Process with Packaged Data Models 171 Packaged Data Model Examples 173

Summary 178 • Key Terms 179 • Review Questions 179 • Problems and Exercises 180 • Field Exercises 182 • References 183 • Further Reading 183 • Web Resources 183

CASE: Forondo Artist Management Excellence Inc. 185

Chapter 4 Logical Database Design and the Relational Model 187 Learning Objectives 187 Introduction 187 The Relational Data Model 188

Basic Definitions 188 relational Data Structure 189 relational keyS 189 ProPertieS of relationS 190 removing multivalueD attributeS from tableS 190

Sample Database 191 Integrity Constraints 192

Domain Constraints 192 Entity Integrity 192 Referential Integrity 194

A01_HOFF3359_13_GE_FM.indd 10 12/04/19 11:44 AM

Contents 11

Creating Relational Tables 195 Well-Structured Relations 196

Transforming EER Diagrams into Relations 197 Step 1: Map Regular Entities 198

comPoSite attributeS 198 multivalueD attributeS 199

Step 2: Map Weak Entities 199 when to create a Surrogate key 200

Step 3: Map Binary Relationships 201 maP binary one-to-many relationShiPS 201 maP binary many-to-many relationShiPS 202 maP binary one-to-one relationShiPS 202

Step 4: Map Associative Entities 203 iDentifier not aSSigneD 203 iDentifier aSSigneD 204

Step 5: Map Unary Relationships 205 unary one-to-many relationShiPS 205 unary many-to-many relationShiPS 206

Step 6: Map Ternary (and n-ary) Relationships 207 Step 7: Map Supertype/Subtype Relationships 208 Summary of EER-to-Relational Transformations 210

Introduction to Normalization 210 Steps in Normalization 211 Functional Dependencies and Keys 211

DeterminantS 213 canDiDate keyS 213

Normalization Example: Pine Valley Furniture Company 214 Step 0: Represent the View in Tabular Form 214 Step 1: Convert to First Normal Form 215

remove rePeating grouPS 215 Select the Primary key 216 anomalieS in 1nf 216

Step 2: Convert to Second Normal Form 217 Step 3: Convert to Third Normal Form 218

removing tranSitive DePenDencieS 218

Determinants and Normalization 219 Step 4: Further Normalization 219

Merging Relations 220 An Example 220 View Integration Problems 220

SynonymS 221 homonymS 221 tranSitive DePenDencieS 221 SuPertyPe/SubtyPe relationShiPS 222

A Final Step for Defining Relational Keys 222 Summary 225 • Key Terms 225 • Review Questions 225 • Problems and Exercises 226 • Field Exercises 235 • References 235 • Further Reading 236 • Web Resources 236

CASE: Forondo Artist Management Excellence Inc. 237

A01_HOFF3359_13_GE_FM.indd 11 12/04/19 11:44 AM

12 Contents

Part III Database Implementation and Use 239 An Overview of Part III 239

Chapter 5 Introduction to SQL 241 Learning Objectives 241 Introduction 241 Origins of the SQL Standard 243 The SQL Environment 245

SQL Data Types 247 Defining A Database in SQL 250

Generating SQL Database Definitions 250 Creating Tables 251 Creating Data Integrity Controls 254 Changing Table Definitions 255 Removing Tables 255

Inserting, Updating, and Deleting Data 256 Batch Input 257 Deleting Database Contents 257 Updating Database Contents 258

Internal Schema Definition in RDBMSS 259 Creating Indexes 259

Processing Single Tables 260 Clauses of the SELECT Statement 260 Using Expressions 262 Using Functions 263 Using Wildcards 266 Using Comparison Operators 266 Using Null Values 267 Using Boolean Operators 267 Using Ranges for Qualification 270 Using Distinct Values 270 Using IN and NOT IN with Lists 272 Sorting Results: The ORDER BY Clause 273 Categorizing Results: The GROUP BY Clause 274 Qualifying Results by Categories: The HAVING Clause 275

Summary 277 • Key Terms 277 • Review Questions 277 • Problems and Exercises 278 • Field Exercises 282 • References 282 • Further Reading 283 • Web Resources 283

CASE: Forondo Artist Management Excellence Inc. 284

Chapter 6 Advanced SQL 285 Learning Objectives 285 Introduction 285 Processing Multiple Tables 286

Equi-Join 287 Natural Join 288 Outer Join 289 Sample Join Involving Four Tables 291

A01_HOFF3359_13_GE_FM.indd 12 12/04/19 11:44 AM

Contents 13

Self-Join 292 Subqueries 294 Correlated Subqueries 299 Using Derived Tables 301 Combinings Queries 301 Conditional Expressions 303 More Complicated SQL Queries 304

Tips for Developing Queries 306 Guidelines for Better Query Design 308

Using and Defining Views 309 Materialized Views 313

Triggers and Routines 313 Triggers 314 Routines and Other Programming Extensions 316 Example Routine in Oracle’s PL/SQL 318

Data Dictionary Facilities 319 Recent Enhancements and Extensions to SQL 321

Analytical and OLAP Functions 321 New Temporal Features in SQL 322 Other Enhancements 322

Summary 323 • Key Terms 324 • Review Questions 324 • Problems and Exercises 325 • Field Exercises 328 • References 328 • Further Reading 329 • Web Resources 329

CASE: Forondo Artist Management Excellence Inc. 330

Chapter 7 Databases in Applications 331 Learning Objectives 331 Location, Location, Location! 331 Introduction 332 Client/Server Architectures 332 Databases in Three-Tier Applications 336

A Java Web Application 337 A Python Web Application 341

Key Considerations in Three-Tier Applications 347 Stored Procedures 347 Transactions 347 Database Connections 349 Key Benefits of Three-Tier Applications 349

Transaction Integrity 350 Controlling Concurrent Access 352

The Problem of Lost Updates 352 Serializability 353 Locking Mechanisms 353

locking level 353 tyPeS of lockS 354 DeaDlock 355 managing DeaDlock 355

Versioning 356

A01_HOFF3359_13_GE_FM.indd 13 12/04/19 11:44 AM

14 Contents

Managing Data Security in an Application Context 358 Threats to Data Security 358 Establishing Client/Server Security 359

Server Security 360 network Security 360

Application Security Issues in Three-Tier Client/Server Environments 360

Data Privacy 361 Summary 363 • Key Terms 363 • Review Questions 363 • Problems and Exercises 364 • Field Exercises 364 • References 365 • Further Reading 365 • Web Resources 365

CASE: Forondo Artist Management Excellence Inc. 366

Chapter 8 Physical Database Design and Database Infrastructure 367 Learning Objectives 367 Introduction 368 The Physical Database Design Process 369

Who Is Responsible for Physical Database Design? 369 Physical Database Design as a Basis for Regulatory Compliance 370 SOX and Databases 371

iT change management 371 logical acceSS to Data 371 iT oPerationS 372

Data Volume and Usage Analysis 372 Designing Fields 374

Choosing Data Types 374 coDing techniQueS 375 controlling Data integrity 376 hanDling miSSing Data 377

Denormalizing and Partitioning Data 377 Denormalization 377

oPPortunitieS for anD tyPeS of Denormalization 378 Denormalize with caution 379

Partitioning 381 Designing Physical Database Files 382

File Organizations 384 heaP file organization 384 SeQuential file organizationS 384 inDexeD file organizationS 386 haSheD file organizationS 387

Clustering Files 387 Designing Controls for Files 388

Using and Selecting Indexes 388 Creating a Unique Key Index 388 Creating a Secondary (Nonunique) Key Index 389 When to Use Indexes 389

Designing a Database for Optimal Query Performance 390 Parallel Query Processing 391 Overriding Automatic Query Optimization 392

Data Dictionaries and Repositories 392

A01_HOFF3359_13_GE_FM.indd 14 12/04/19 11:44 AM

Contents 15

Data Dictionary 393 Repositories 393

Database Software Data Security Features 395 Views 395 Integrity Controls 396 Authorization Rules 397 User-Defined Procedures 399 Encryption 399 Authentication Schemes 399

PaSSworDS 400 Strong authentication 400

Database Backup and Recovery 401 Basic Recovery Facilities 401

backuP facilitieS 401 journalizing facilitieS 402 checkPoint facility 402 recovery manager 403

Recovery and Restart Procedures 403 DiSk mirroring 403 reStore/rerun 404 backwarD recovery 404 forwarD recovery 405

Types of Database Failure 405 aborteD tranSactionS 406 incorrect Data 406 SyStem failure 406 DatabaSe DeStruction 406

Disaster Recovery 407 Cloud-Based Database Infrastructure 407

Cloud-Based Models for Providing Data Management Services 407 Benefits and Downsides of Using Cloud-Based Data Management Services 408

Summary 409 • Key Terms 410 • Review Questions 411 • Problems and Exercises 412 • Field Exercises 416 • References 417 • Further Reading 417 • Web Resources 417

CASE: Forondo Artist Management Excellence Inc. 418

Part IV Advanced Database Topics 419 An Overview of Part IV 419

Chapter 9 Data Warehousing and Data Integration 421 Learning Objectives 421 Introduction 421 Basic Concepts of Data Warehousing 424

A Brief History of Data Warehousing 424 The Need for Data Warehousing 424

neeD for a comPany-wiDe view 424 neeD to SeParate oPerational anD informational SyStemS 427

Data Warehouse Architectures 427 Independent Data Mart Data Warehousing Environment 428

A01_HOFF3359_13_GE_FM.indd 15 12/04/19 11:44 AM

16 Contents

Dependent Data Mart and Operational Data Store Architecture: A Three-Level Approach 429 Logical Data Mart and Real-Time Data Warehouse Architecture 431 Three-Layer Data Architecture 434

role of the enterPriSe Data moDel 434 role of metaData 434

Some Characteristics of Data Warehouse Data 435 Status versus Event Data 435 Transient versus Periodic Data 436 An Example of Transient and Periodic Data 436

tranSient Data 438 PerioDic Data 438 other Data warehouSe changeS 438

The Derived Data Layer 439 Characteristics of Derived Data 439 The Star Schema 440

fact tableS anD DimenSion tableS 440 examPle Star Schema 441 Surrogate key 442 grain of the fact table 443 Duration of the DatabaSe 444 Size of the fact table 444 moDeling Date anD time 445

Variations of the Star Schema 446 multiPle fact tableS 446 factleSS fact tableS 447

Normalizing Dimension Tables 448 multivalueD DimenSionS 448 hierarchieS 449

Slowly Changing Dimensions 451 Determining Dimensions and Facts 454

Data Integration: An Overview 456 General Approaches to Data Integration 456

Data feDeration 457 Data ProPagation 457

Data Integration for Data Warehousing: The Reconciled Data Layer 458

Characteristics of Data after ETL 458 The ETL Process 459

maPPing anD metaData management 459 extract 460 cleanSe 461 loaD anD inDex 463

Data Transformation 464 Data Transformation Functions 465

recorD-level functionS 465 fielD-level functionS 466

Data Warehouse Administration 468

A01_HOFF3359_13_GE_FM.indd 16 12/04/19 11:44 AM

Contents 17

The Future of Data Warehousing: Integration with Other Forms of Data Management and Analytics 468

Speed of Processing 469 Moving the Data Warehouse into the Cloud 469 Dealing with Unstructured Data 470

Summary 470 • Key Terms 471 • Review Questions 471 • Problems and Exercises 472 • Field Exercises 476 • References 476 • Further Reading 477 • Web Resources 477

Chapter 10 Big Data Technologies 478 Learning Objectives 478 Introduction 478 Moving Beyond Transactional and Data Warehousing Databases 480 Big Data 480

NoSQL 482 Classification of NoSQL DBMSs 484

key-value StoreS 484 Document StoreS 485 wiDe-column StoreS 485 graPh-orienteD DatabaSeS 485

NoSQL Examples 485 reDiS 486 mongoDb 486 aPache caSSanDra 486 neo4j 486

A NoSQL Example: MongoDB 486 DocumentS 486 collectionS 488 relationShiPS 488 Querying mongoDb 488

Impact of NoSQL on Database Professionals 492 Hadoop 492 Components of Hadoop 492

the haDooP DiStributeD file SyStem (hDfS) 493 maPreDuce 493 Pig 495 hive 495 hbaSe 496

A Practical Introduction to Pig 496 loaDing Data 496 tranSforming Data 497

A Practical Introduction to Hive 499 creating a table 499 loaDing Data into the table 499 ProceSSing the Data 500

Integrated Analytics and Data Science Platforms 502 hP hAVEn 502 teraData aSter 502 ibm big Data Platform 503

A01_HOFF3359_13_GE_FM.indd 17 12/04/19 11:44 AM

18 Contents

Putting It All Together: Integrated Data Architecture 503 Summary 505 • Key Terms 505 • Review Questions 505 • Problems and Exercises 506 • References 506 • Further Reading 507 • Web Resources 507

Chapter 11 Analytics and Its Implications 508 Learning Objectives 508 Introduction 508 Analytics 509

Types of Analytics 509 Use of Descriptive Analytics 511

SQl olaP Querying 512 olaP toolS 514 Data viSualization 516 buSineSS Performance management anD DaShboarDS 517

Use of Predictive Analytics 518 Data mining toolS 519 examPleS of PreDictive analyticS 520

Use of Prescriptive Analytics 521 Key User Tools for Analytics 522

analytical anD olaP functionS 523 r 524 Python 525 aPache SPark 526

Data Management Infrastructure for Analytics 526 Impact of Big Data and Analytics 529

Applications of Big Data and Analytics 529 buSineSS 530 e-government anD PoliticS 530 Science anD technology 530 Smart health anD well-being 531 Security anD Public Safety 531

Implications of Big Data Analytics and Decision Making 531 PerSonal Privacy verSuS collective benefitS 532 ownerShiP anD acceSS 532 Quality anD reuSe of Data anD algorithmS 532 tranSParency anD valiDation 532 changing nature of work 533 DemanDS for workforce caPabilitieS anD eDucation 533 Summary 533 • Key Terms 534 • Review Questions 534 • Problems and Exercises 534 • References 535 • Further Reading 536

Chapter 12 Data and Database Administration with Focus on Data Quality 537 Learning Objectives 537 Introduction 537 Overview of Data and Database Administration 539

Data Administration 539 Database Administration 540

A01_HOFF3359_13_GE_FM.indd 18 12/04/19 11:44 AM

Contents 19

traDitional DatabaSe aDminiStration 540 trenDS in DatabaSe aDminiStration 542

Evolving Data Administration Roles 544 The Open Source Movement and Database Management 545 Data Governance 546 Managing Data Quality 547

Characteristics of Quality Data 548 external Data SourceS 549 reDunDant Data Storage anD inconSiStent metaData 550 Data entry ProblemS 550 lack of organizational commitment 550

Data Quality Improvement 550 get the buSineSS buy-in 550 conDuct a Data Quality auDit 551 eStabliSh a Data StewarDShiP Program 552 imProve Data caPture ProceSSeS 552 aPPly moDern Data management PrinciPleS anD technology 553 aPPly tQm PrinciPleS anD PracticeS 553

Summary of Data Quality 553 Data Availability 554

Costs of Downtime 554 Measures to Ensure Availability 555

harDware failureS 555 loSS or corruPtion of Data 555 human error 555 maintenance Downtime 555 network-relateD ProblemS 555

Master Data Management 555 Summary 557 • Key Terms 557 • Review Questions 558 • Problems and Exercises 558 • Field Exercises 560 • References 560 • Further Reading 561 • Web Resources 561

Glossary of Acronyms 563

Glossary of Terms 565

Index 573

A01_HOFF3359_13_GE_FM.indd 19 12/04/19 11:44 AM

20 Online Chapters

ONLINE CHAPTERS

Chapter 13 Distributed Databases 13-1 Learning Objectives 13-1 Introduction 13-1

Objectives and Trade-Offs 13-4 Options for Distributing a Database 13-6

Data Replication 13-6 SnaPShot rePlication 13-7 near-real-time rePlication 13-8 Pull rePlication 13-8 DatabaSe integrity with rePlication 13-8 when to uSe rePlication 13-9

Horizontal Partitioning 13-9 Vertical Partitioning 13-10 Combinations of Operations 13-11 Selecting the Right Data Distribution Strategy 13-12

Distributed DBMS 13-13 Location Transparency 13-15 Replication Transparency 13-16 Failure Transparency 13-17 Commit Protocol 13-17 Concurrency Transparency 13-18

time StamPing 13-19

Query Optimization 13-19 Evolution of Distributed DBMSs 13-22

remote unit of work 13-22 DiStributeD unit of work 13-22 DiStributeD reQueSt 13-23 Summary 13-23 • Key Terms 13-24 • Review Questions 13-24 • Problems and Exercises 13-25 • Field Exercises 13-27 • References 13-27 • Further Reading 13-27 • Web Resources 13-27

Chapter 14 Object-Oriented Data Modeling 14-1 Learning Objectives 14-1 Introduction 14-1 Unified Modeling Language 14-3 Object-Oriented Data Modeling 14-4

Representing Objects and Classes 14-4 Types of Operations 14-7 Representing Associations 14-7 Representing Association Classes 14-11 Representing Derived Attributes, Derived Associations, and Derived Roles 14-12 Representing Generalization 14-13 Interpreting Inheritance and Overriding 14-18

A01_HOFF3359_13_GE_FM.indd 20 12/04/19 11:44 AM

Online Chapters 21

Representing Multiple Inheritance 14-19 Representing Aggregation 14-19

Business Rules 14-22 Object Modeling Example: Pine Valley Furniture Company 14-23

Summary 14-25 • Key Terms 14-26 • Review Questions 14-26 • Problems and Exercises 14-30 • Field Exercises 14-37 • References 14-37 • Further Reading 14-38 • Web Resources 14-38

Appendix A Data Modeling Tools and Notation A-1 Comparing E-R Modeling Conventions A-1

Visio Professional 2016 Notation A-1 entitieS a-5 relationShiPS a-5

CA ERwin Data Modeler 9.7 Notation A-5 entitieS a-5 relationShiPS a-5

SAP Sybase PowerDesigner 16.6 Notation A-7 entitieS a-8 relationShiPS a-8

Oracle Designer Notation A-8 entitieS a-8 relationShiPS a-8

Comparison of Tool Interfaces and E-R Diagrams A-8

Appendix B Advanced Normal Forms B-1 Boyce-Codd Normal Form B-1

Anomalies in Student Advisor B-1 Definition of Boyce-Codd Normal Form (BCNF) B-2 Converting a Relation to BCNF B-2

Fourth Normal Form B-3 Multivalued Dependencies B-5

Higher Normal Forms B-5 Key Terms B-6 • References B-6 • Web Resources B-6

Appendix C Data Structures C-1 Pointers C-1 Data Structure Building Blocks C-2 Linear Data Structures C-4

Stacks C-5 Queues C-5 Sorted Lists C-6 Multilists C-8

Hazards of Chain Structures C-8 Trees C-9

Balanced Trees C-9 References C-12

A01_HOFF3359_13_GE_FM.indd 21 12/04/19 11:44 AM

A01_HOFF3359_13_GE_FM.indd 22 12/04/19 11:44 AM

This page intentionally left blank

PREFACE

This text is designed for introductory courses in database management. Such a course is usually required as part of an information systems curriculum in business schools, computer technology programs, and applied computer science departments. The Association for Information Systems (AIS), the Association for Computing Machinery (ACM), and the International Federation of Information Processing Societies (IFIPS) curriculum guidelines (e.g., IS 2010 and MSIS 2016) all outline this type of database management course or the competencies a student completing the course is expected to have. Previous editions of this text have been used successfully for more than 35 years at both the undergraduate and graduate levels as well as in management and professional development programs.

WHAT’S NEW IN THIS EDITION?

This 13th edition of Modern Database Management updates and expands materials in areas undergoing rapid change as a result of improved managerial practices, database design tools and methodologies, and database technology. Later, we detail changes to each chapter. The themes of this 13th edition reflect the major trends in the information systems field and the skills required of modern information systems graduates. The most important changes are as follows:

• The book has been restructured in several important ways. Chapter 7 on databases in applications now also includes segments on transaction integ- rity, designing multi-user solutions, and application level security, bringing these important perspectives together with their context. The revised chap- ter on physical database design and database infrastructure (new Chapter 8) includes also coverage of database security, backup and recovery, cloud-based database solutions, and other essential database infrastructure topics. This new comprehensive structure on physical design and infrastructure is now placed after the SQL chapters. The new version of Chapter 9 integrates mate- rial on data warehousing and data integrity in a conceptually natural pair- ing. Recognizing the way in which analytics capabilities rely on all types of data management solutions, Chapter 11, on analytics and implications, is now separate from Chapter 10, on big data. Finally, Chapter 12 brings together data and database administration with data quality, emphasizing the essential connections between the three.

• The part structure of the book has been redesigned to be fully aligned with the new chapter structure.

• We have introduced a new overarching framework (Figure 1-5), which gives our readers a clearer overview of structure of the book and its core topic areas. The framework communicates clearly the increasing importance of informational systems (divided into Analytics–Data Warehousing and Analytics–Big Data) in addition to this book’s traditional strength of transactional systems.

• Given the continued and still increasing interest in big data and analytics, we have continued to expand content in this area. The book has now separate chapters on big data technologies (Chapter 10) and analytics (Chapter 11). In addition to general coverage of NoSQL and Hadoop technologies, Chapter 10 provides also detailed examples of MongoDB, Pig, and Hive. Chapter 11 includes extended coverage of R, Python, and Apache Spark—all essential technologies for analytics professionals that allow a link between analytics and data management architectures.

• We emphasize the increasing importance of cloud-based database solutions, mobile technologies, and agile development throughout the book.

• Chapter 1 now better recognizes the broad range of enterprise level applications data management solutions enable and support, including enterprise systems, data warehouses, and data lakes.

23

A01_HOFF3359_13_GE_FM.indd 23 12/04/19 11:44 AM

• Chapter 7 on databases in applications now includes an extensive example dem- onstrating the use of Python in the context of database-driven applications.

• The instructor’s manual will have more material to support the case Forondo Artist Management Excellence that was introduced in the 12th edition.

In addition to the new topics covered, specific improvements to the textbook have been made in the following areas:

• Every chapter went through significant edits to streamline coverage to ensure rel- evance with current technologies and eliminate redundancies.

• The entire book has been edited so that its language clearly reflects its focus on the readers as learners instead of authors as teachers

• End-of-chapter material (review questions, problems and exercises, and/or field exercises) in every chapter has been revised with new and modified questions and exercises.

• We continued to update the figures in several chapters to reflect the changing landscape of technologies that are being used in modern organizations.

• The Web Resources section in each chapter was updated to ensure that students have information on the latest database trends and expanded background details on important topics covered in the text.

• The book continues to be available through VitalSource, an innovative e-book delivery system, and as an electronic book in the Kindle format.

Also, we continue to provide on the student Companion Web site several custom-developed short videos that address key concepts and skills from different sections of the book. These videos, produced by the textbook authors, help students learn difficult material by using both the printed text and a mini-lecture or tutorial. Videos have been developed to support Chapters 1 (introduction to database), 2 and 3 (conceptual data modeling), 4 (normalization), and 6 and 7 (SQL). Look for special icons on the opening page of these chapters to call attention to these videos, and go to www.pearsonglobaleditions.com to find these videos.

FOR THOSE NEW TO MODERN DATABASE MANAGEMENT

Modern Database Management has been a leading text since its first edition in 1983. In spite of this market leadership position, some instructors have used other good data- base management texts. Why might you want to switch at this time? There are several good reasons:

• One of our goals, in every edition, has been to lead other books in coverage of the latest principles, concepts, and technologies. See what we have added for the 13th edition in “What’s New in This Edition?” In the past, we have led in coverage of object-oriented data modeling and UML, Internet databases, data warehous- ing, and the use of CASE tools in support of data modeling. For the 13th edition, we continue this tradition by continuing to expand and improve coverage of big data and analytics, focusing on what every database student needs to understand about these topics.

• While remaining current, this text focuses on what leading practitioners say is most important for database developers. We work with many practitioners, including the professionals of the Data Management Association (DAMA) and The Data Warehousing Institute (TDWI), leading consultants, technology leaders, and authors of articles in the most widely read professional publications. We draw on these experts to ensure that what the book includes is important and covers not only important entry-level knowledge and skills but also those fundamentals and mind-sets that lead to long-term career success.

• In the 13th edition of this highly successful book, material is presented in a way that has been viewed as very accessible to students. Our methods have been refined through continuous market feedback for more than 35 years as well as through our own teaching. Overall, the pedagogy of the book is sound, and we believe that the new framework that we introduced in Chapter 1 will further strengthen our students’

24 Preface

A01_HOFF3359_13_GE_FM.indd 24 12/04/19 11:44 AM

Preface 25

understanding of the big picture of data management. We use many illustrations that help make important concepts and techniques clear. We use the most modern nota- tions. The organization of the book is flexible, so you can use chapters in whatever sequence makes sense for your students. We supplement the book with data sets to facilitate hands-on, practical learning and with new media resources to make some of the more challenging topics more engaging.

• Our text can accommodate structural flexibility. For example, you may have partic- ular interest in introducing SQL early in your course. Our text makes this possible. First, we cover SQL in depth, devoting two full chapters to this core technology of the database field. Second, we include many SQL examples in early chapters. Third, many instructors have successfully used the two SQL chapters early in their course. Although logically appearing in the life cycle of systems development as Chapters 5 and 6, part of the implementation section of the text, many instructors have used these chapters immediately after Chapter 1 or in parallel with other early chapters. Finally, we use SQL throughout the book, for example, to illustrate Web application connections to relational databases in Chapter 7 and online ana- lytical processing in Chapter 11.

• We have the latest in supplements and Web site support for the text. See the sup- plement package for details on all the resources available to you and your students.

• This text is written to be part of a modern information systems curriculum with a strong business systems development focus. Topics are included and addressed so as to reinforce principles from other typical courses, such as systems analysis and design, networking, Web site design and development, MIS principles, and appli- cation development. Emphasis is on the development of the database component of modern information systems and on the management of the data resource. Thus, the text is practical, supports projects and other hands-on class activities, and encourages linking database concepts to concepts being learned throughout the curriculum the student is taking.

SUMMARY OF ENHANCEMENTS TO EACH CHAPTER

The following sections present a chapter-by-chapter description of the major changes in this edition. Each chapter description presents a statement of the purpose of that chapter, followed by a description of the changes and revisions that have been made for the 13th edition. Each paragraph concludes with a description of the strengths that have been retained from prior editions.

PART I: THE CONTEXT OF DATABASE MANAGEMENT

Chapter 1: The Database Environment and Development Process This chapter discusses the role of databases in organizations and previews the major topics in the remainder of the text. The primary change to this chapter has been the introduction of a new integrated data management framework (Figure 1-5) and sup- porting text accompanying it. This framework recognizes the increasing importance of the informational systems in addition to the traditional focus of this book on transac- tional systems. After presenting a brief introduction to the basic terminology associated with storing and retrieving data, the chapter presents a well-organized comparison of traditional file processing systems and modern database technology. The chapter then introduces the core components of a database environment. It then goes on to explain the process of database development in the context of structured life cycle, prototyp- ing, and agile methodologies. The chapter also discusses important issues in data- base development, including management of the diverse group of people involved in database development and frameworks for understanding database architectures and technologies (e.g., the three-schema architecture). Reviewers frequently note the compatibility of this chapter with what students learn in systems analysis and design classes. A brief history of the evolution of database technology, from pre-database files to modern object-relational technologies, is presented. The chapter also provides

Preface 25

A01_HOFF3359_13_GE_FM.indd 25 12/04/19 11:44 AM

26 Preface

an overview of the range of database applications that are currently in use within organizations—personal, multi-tier, and enterprise applications. The explanation of enterprise databases includes databases that are part of enterprise resource planning systems and data warehouses. The chapter concludes with a description of the process of developing a database in a fictitious company, Pine Valley Furniture. This descrip- tion closely mirrors the steps in database development described earlier in the chapter. The first chapter provides an introduction to the FAME case, which then continues through the book until Chapter 8.

PART II: DATABASE ANALYSIS AND LOGICAL DESIGN

Chapter 2: Modeling Data in the Organization This chapter presents a thorough introduction to conceptual data modeling with the entity-relationship (E-R) model. The chapter title emphasizes the reason for the E-R model: to unambiguously document the rules of the business that influence database design. Specific subsections explain in detail how to name and define elements of a data model, which are essential in developing an unambiguous E-R diagram. The chapter continues to proceed from simple to more complex examples, and it concludes with a comprehensive E-R diagram for the Pine Valley Furniture Company. In the 13th edition, we have provided six new problems and exercises; these new exercises present some more modern situations, such as Internet of Things applications for databases. A variety of other problems and exercises as well as review questions have been changed to emphasize important topics of the chapter. Appendix A provides information on dif- ferent data modeling tools and notations.

Chapter 3: The Enhanced E-R Model This chapter presents a discussion of several advanced E-R data model constructs, pri- marily supertype/subtype relationships. As in Chapter 2, problems and exercises have been revised, with three new exercises and several building on or extending the new exer- cises from Chapter 2. The third part of the new FAME case is presented in this chapter. The chapter continues to present thorough coverage of supertype/subtype relationships and includes a comprehensive example of an extended E-R data model for the Pine Valley Furniture Company.

Chapter 4: Logical Database Design and the Relational Model This chapter describes the process of converting a conceptual data model to the relational data model, as well as how to merge new relations into an existing normalized database. It provides a conceptually sound and practically relevant introduction to normalization, emphasizing the importance of the use of functional dependencies and determinants as the basis for normalization. Concepts of normalization and normal forms are extended in Appendix B. The chapter features a discussion of the characteristics of foreign keys and introduces the important concept of a nonintelligent enterprise key. Enterprise keys (also called surrogate keys for data warehouses) are emphasized as some concepts of object- orientation have migrated into the relational technology world. New problems and exer- cises are included that draw upon the new problems and exercises from Chapters 2 and 3 for relational modeling and normalization. The chapter continues to emphasize the basic concepts of the relational data model and the role of the database designer in the logical design process.

PART III: DATABASE IMPLEMENTATION AND USE

Chapter 5: Introduction to SQL This chapter (Chapter 6 in 12th edition) presents a thorough introduction to the SQL used by most DBMSs (SQL:1999) and introduces the changes that are included in the latest standards (SQL: 2011 and SQL:2016). This edition adds coverage of the new features of SQL:2016, including row pattern recognition, JSON support, and extended analytical

A01_HOFF3359_13_GE_FM.indd 26 12/04/19 11:44 AM

Preface 27

capabilities. The new edition also clarifies coverage of SQL data types and, overall, makes it easier to move from relational design in Chapter 4 directly to database implementation without the material on physical database design (now in Chapter 8). The coverage of SQL is extensive and divided between this chapter and Chapter 6. This chapter includes exam- ples of SQL code, using mostly SQL:1999 and SQL:2016 syntax, as well as some Oracle 12c and Microsoft SQL Server syntax. Some unique features of MySQL are mentioned. In this edition, coverage of views has been moved to Chapter 6. Chapter 5 explains the SQL commands needed to create and maintain a database and to program single-table queries. Five review questions and 13 problems and exercises have been added to the chapter or modified extensively. The chapter continues to use the Pine Valley Furniture Company case to illustrate a wide variety of practical queries and query results.

Chapter 6: Advanced SQL This chapter (Chapter 7 in 12th edition) continues the description of SQL, with a care- ful explanation of multiple-table queries, transaction integrity, data dictionaries, dynamic and materialized views, triggers and stored procedures (the differences between them are now more clearly explained), and embedding SQL in other programming language programs. All forms of the OUTER JOIN command are covered. Standard SQL (with an updated focus on SQL:2016) is also used. The revised version of the chapter includes now thorough coverage of views and the purposes for which they are used, including their role in enabling security and privacy solutions. This chapter illustrates how to store the results of a query in a derived table, the CAST command to convert data between different data types, and the CASE command for doing conditional processing in SQL. Emphasis continues on the set-processing style of SQL compared with the record processing of pro- gramming languages with which the student may be familiar. The section on routines has been revised to provide clarified, expanded, and more current coverage of this topic. The material of transaction integrity, has, however been moved to Chapter 7, where it most naturally belongs. The chapter continues to contain a clear explanation of subqueries and correlated subqueries, two of the most complex and powerful constructs in SQL. At the end, the chapter discusses material that is new to this chapter: data dictionary facilities (in practice, using SQL to understand the structure of the database) and recent extensions and enhancements to SQL. Chapter review material has been updated with 13 new problems and exercises and three new review questions.

Chapter 7: Databases in Applications This chapter (Chapter 8 in 12th edition) provides a modern discussion of the concepts of client/server architecture and applications, middleware, and database access in contemporary database environments. The chapter has been structurally significantly modified to provide additional clarity, including the integration of material on a two- tiered architecture into the section on three-tiered architecture. In addition to a revised example of writing a Java web application, there is an entire new section—including an extensive and detailed example—on writing Web applications with Python, a widely used general purpose programming language that has become very popular in ana- lytics. Sections on transaction integrity, concurrent access, and application level data security have been revised and moved to this chapter to provide additional conceptual clarity. Material on cloud computing has been moved to Chapter 8 on database infra- structure. Review questions and problems and exercises have been updated.

Chapter 8: Physical Database Design and Database Infrastructure This chapter (Chapter 5 in the 12th edition) describes the steps that are essential in achiev- ing an efficient database design, with a strong focus on those aspects of database design and implementation that are typically within the control of a database professional in a modern database environment. In addition, several new topics on database infrastruc- ture have been integrated into this chapter to improve the structural clarity of the book, including data dictionaries and repositories, general database software security features, and database backup and recovery. A revised and extended section on cloud-based database infrastructure completes the chapter. Overall, the chapter emphasizes ways to

A01_HOFF3359_13_GE_FM.indd 27 12/04/19 11:44 AM

28 Preface

improve database performance, with references to specific techniques available in Oracle and other DBMSs to achieve this goal. The discussion of indexes includes descriptions of the types of indexes that are widely available in database technologies as techniques to improve query processing speed. Appendix C provides excellent background on funda- mental data structures for programs of study that need coverage of this topic. The chapter continues to emphasize the physical design process and the goals of that process. Review questions and problems and exercises have been updated and extended based on the new structure and content of the chapter.

PART IV: ADVANCED DATABASE TOPICS

Chapter 9: Data Warehousing and Data Integration This chapter describes the basic concepts of data warehousing, the reasons data ware- housing is regarded as critical to competitive advantage in many organizations, and the database design activities and structures unique to data warehousing. The most important change of this chapter is the integration of material on data integration (formerly in Chapter 10 in the 12th edition) into it. This change strengthens the read- ers’ ability to understand the essential role of data integration in data warehousing (particularly in ETL and other aspects of data preparation), and it clarifies the struc- ture of the book. Topics covered in this chapter include alternative data warehouse architectures and the dimensional data model (or star schema) for data warehouses. In this edition, additional attention is given to cloud-based implementation of data warehouses. Throughout the chapter, several details have been updated to ensure technical correctness. Operational data store and independent, dependent, and logi- cal data marts are defined. The chapter includes multiple new and revised review questions and problems and exercises.

Chapter 10: Big Data Technologies This chapter incorporates big data infrastructure material from Chapter 11 in the 12th edition, significantly expanding it and making it more directly applicable with sub- stantial detailed descriptive examples of MongoDB (the most popular NoSQL data- base) and Pig (scripting language and task automation environment for Hadoop) and Hive (an SQL-like declarative language for querying data stored in Hadoop). This new version of the material gives the students a much more practical, hands-on sense of the purposes for which these well-known tools can be used and how they can serve the goals of big data management. The chapter also includes several new problems and exercises based on these environments. Overall, the chapter helps the readers understand how big data technologies have expanded the possibilities for analytics-driven innovation through advanced informational systems that are pushing boundaries further in terms of volume, velocity, and variety of data while paying continuous attention to value and veracity of big data.

Chapter 11: Analytics and its Implications Chapter 11 offers integrated coverage of analytics, including descriptive, predictive, and prescriptive analytics. It is based on material on analytics in the big data and analytics chapter in the 12th edition, expanding it with comprehensive new sections on R, Python, and Apache Spark and bringing in material on analytical functions in SQL. The discussion on analytics is linked not only to the coverage of big data but also the material on data warehousing in Chapter 9 and the general discussion on data management in Chapter 1 (as indicated in the new framework in Chapter 1). The chapter also covers approaches and technologies used by analytics profession- als, such as on-line analytical processing, data visualization, business performance management and dashboards, data mining, and text mining. Finally, the chapter integrates the coverage of big data and analytics technologies to the individual, orga- nizational, and societal implications of these capabilities. Review questions on the new material have been added.

A01_HOFF3359_13_GE_FM.indd 28 12/04/19 11:44 AM

Preface 29

Chapter 12: Data and Database Administration with Focus on Data Quality This chapter presents a thorough discussion of the importance and roles of data and database administration and describes a number of the key issues that arise when these functions are performed. This chapter emphasizes the changing roles and approaches of data and database administration, with a renewed and strength- ened emphasis on data quality. The chapter both discusses essential characteristics of high-quality data and the mechanisms that organizations need to put in place to enable data quality improvement. Data governance, data availability, and master data management are also covered. The chapter continues to emphasize the criti- cal importance of data and database management in managing data as a corporate asset.

Chapter 13: Distributed Databases This chapter—available on the book’s Web site—reviews the role, technologies, and unique database design opportunities of distributed databases. The objectives and trade-offs for distributed databases, data replication alternatives, factors in selecting a data distribution strategy, and distributed database vendors and products are covered. This chapter provides thorough coverage of database concurrency access controls. Many reviewers have indicated that they are seldom able to cover this chapter in an introductory course, but having the material available is critical for advanced students or special topics.

Chapter 14: Object-Oriented Data Modeling This chapter presents an introduction to object-oriented modeling using Object Management Group’s Unified Modeling Language (UML). This chapter has been care- fully reviewed to ensure consistency with the latest UML notation and best industry practices. UML provides an industry-standard notation for representing classes and objects. The chapter continues to emphasize basic object-oriented concepts, such as inheritance, encapsulation, composition, and polymorphism. As with Chapter 13, Chapter 14 is available on the textbook’s Web site.

APPENDICES

In the 13th edition three appendices are available on the book’s Web site and are intended for those who wish to explore certain topics in greater depth.

Appendix A: Data Modeling Tools and Notation This appendix addresses a need raised by many readers—how to translate the E-R notation in the text into the form used by the CASE tool or the DBMS used in class. Specifically, this appendix compares the notations of CA ERwin Data Modeler r9.7, Oracle SQL Data Modeler 4.2, SAP Sybase PowerDesigner 16.6, and Microsoft Visio Professional 2016. Tables and illustrations show the notations used for the same constructs in each of these popular software packages.

Appendix B: Advanced Normal Forms This appendix presents a description (with examples) of Boyce-Codd and fourth normal forms, including an example of BCNF to show how to handle overlapping candidate keys. Other normal forms are briefly introduced. The Web Resources section includes a reference for information on many advanced normal form topics.

Appendix C: Data Structures This appendix describes several data structures that often underlie database imple- mentations. Topics include the use of pointers, stacks, queues, sorted lists, inverted lists, and trees.

A01_HOFF3359_13_GE_FM.indd 29 12/04/19 11:44 AM

30 Preface

PEDAGOGY

A number of additions and improvements have been made to end-of-chapter materials to provide a wider and richer range of choices for the user. The most important of these improvements are the following:

1. Review Questions Questions have been updated to support new and enhanced chapter material.

2. Problems and Exercises This section has been reviewed in every chapter, and many chapters contain new problems and exercises to support updated chapter material. Of special interest are questions in many chapters that give students opportunities to use the data sets provided for the text. Problems and exercises are presented in roughly increasing order of difficulty, which should help instructors and students find exercises appropriate for what they want to accomplish.

3. Field Exercises This section provides a set of “hands-on” mini-cases that can be assigned to individual students or to small teams of students. Field exercises range from directed field trips to Internet searches and other types of research exercises.

4. Case The 13th edition of this book includes the same mini-case that was introduced in the 12th edition: Forondo Artist Management Excellence Inc. (FAME). In the first three chapters, the case begins with a description provided in the “voice” of one or more stakeholders, revealing a new dimension of requirements to the reader. Each chapter has project assignments intended to provide guidance on the types of deliv- erables instructors could expect from students, some of which tie together issues and activities across chapters. These project assignments can be completed by individual students or by small project teams. This case provides an excellent means for stu- dents to gain hands-on experience with the concepts and tools they have studied. The instructor’s manual will include new materials to support the use of the case.

5. Web Resources Each chapter contains a list of updated and validated URLs for Web sites that contain information that supplements the chapter. These Web sites cover online publication archives, vendors, electronic publications, industry stan- dards organizations, and many other sources. These sites allow students and instructors to find updated product information, innovations that have appeared since the printing of the book, background information to explore topics in greater depth, and resources for writing research papers.

We continue to provide several pedagogical features that help make the 13th edi- tion widely accessible to instructors and students. These features include the following:

1. Learning objectives appear at the beginning of each chapter, as a preview of the major concepts and skills students will learn from that chapter. The learning objectives— carefully updated to be aligned with the new chapter structure—also provide a great study review aid for students as they prepare for assignments and examinations.

2. Chapter introductions and summaries both encapsulate the main concepts of each chapter and link material to related chapters, providing students with a compre- hensive conceptual framework for the course.

3. The chapter review includes the Review Questions, Problems and Exercises, and Field Exercises discussed earlier and also contains a Key Terms list to test the stu- dent’s grasp of important concepts, basic facts, and significant issues.

4. A running glossary defines key terms in the page margins as they are discussed in the text. These terms are also defined at the end of the text, in the Glossary of Terms. Also included is the end-of-book Glossary of Acronyms for abbreviations commonly used in database management.

ORGANIZATION

We encourage instructors to customize their use of this book to meet the needs of both their curriculum and student career paths. The modular nature of the text, its broad cov- erage, its extensive illustrations, and its inclusion of advanced topics and emerging issues make customization easy. The many references to current publications and Web sites

A01_HOFF3359_13_GE_FM.indd 30 12/04/19 11:44 AM

Preface 31

can help instructors develop supplemental reading lists or expand classroom discussion beyond material presented in the text. The use of appendices for several advanced topics allows instructors to easily include or omit these topics.

The modular nature of the text allows the instructor to omit certain chapters or to cover chapters in a different sequence. For example, an instructor who wishes to emphasize data modeling may cover Chapter 14 (available on the book’s Web site) on object-oriented data modeling along with or instead of Chapters 2 and 3. An instructor who wishes to cover only basic entity-relationship concepts (but not the enhanced E-R model) may skip Chapter 3 or cover it after Chapter 4 on the relational model.

We have contacted many adopters of Modern Database Management and asked them to share with us their syllabi. Most adopters cover the chapters in sequence, but several alternative sequences have also been successful. These alternatives include the following:

• Some instructors cover Chapter 12 on data and database administration immediately after Chapter 8 on physical database design and the relational model.

• To introduce SQL as early as possible, many instructors have effectively covered 12th edition Chapters 6 and 7 (SQL) immediately after Chapter 4; therefore, we have now placed them as Chapters 5 and 6. Some have even covered the new Chapter 5 immediately after Chapter 1, which the book makes possible.

• Many instructors have students read appendices along with chapters, such as reading Appendix on data modeling notations with Chapter 2 or Chapter 3 on E-R modeling, Appendix B on advanced normal forms with Chapter 4 on the relational model, and Appendix C on data structures with Chapter 8.

THE SUPPLEMENT PACKAGE: WWW.PEARSONGLOBALEDITIONS.COM

A comprehensive and flexible technology support package is available to enhance the teaching and learning experience. All instructor and student supplements are available on the text Web site: www.pearsonglobaleditions.com.

For Students The following online resources are available to students:

• Complete chapters on distributed databases and object-oriented data modeling as well as appendices focusing on data modeling notations, advanced normal forms, and data structures allow you to learn in depth about topics that are not covered in the textbook.

• Accompanying databases are also provided. Two versions of the Pine Valley Furniture Company case have been created and populated for the 13th edition. One version is scoped to match the textbook examples. A second version is fleshed out with more data and tables. This version is not complete, however, so that students can create missing tables and additional forms, reports, and modules. Databases are provided in several formats (ASCII tables, Oracle script, and Microsoft Access), but formats vary for the two versions. Some documentation of the databases is also provided. Both versions of the PVFC database are also provided on Teradata University Network.

• Several custom-developed short videos that address key concepts and skills from different sections of the book help students learn material that may be more difficult to under- stand by using both the printed text and a mini lecture.

For Instructors The following online resources are available to instructors:

• The Instructor’s Resource Manual by Heikki Topi, Bentley University, provides chapter-by-chapter instructor objectives, classroom ideas, and answers to Review Questions, Problems and Exercises, Field Exercises, and Project Case Questions.

A01_HOFF3359_13_GE_FM.indd 31 12/04/19 11:44 AM

32 Preface

The Instructor’s Resource Manual is available for download on the instructor area of the text’s Web site.

• The Test Bank and TestGen, by John Russo, Wentworth Institute of Technology, includes a comprehensive set of test questions in multiple-choice, true/false, and short-answer format, ranked according to level of difficulty and referenced with page numbers and topic headings from the text. The Test Bank is available in Microsoft Word and as the computerized TestGen. TestGen is a comprehensive suite of tools for testing and assessment. It allows instructors to easily create and distrib- ute tests for their courses, either by printing and distributing through traditional methods or by online delivery via a local area network (LAN) server. Test Manager features Screen Wizards to assist you as you move through the program, and the software is backed with full technical support.

• PowerPoint presentation slides, by Michel Mitri, James Madison University, feature lecture notes that highlight key terms and concepts. Instructors can customize the presentation by adding their own slides or editing existing ones.

• The Image Library is a collection of the text art organized by chapter. It includes all figures, tables, and screenshots (as permission allows) and can be used to enhance class lectures and PowerPoint slides.

• Accompanying databases are also provided. Two versions of the Pine Valley Furniture Company case have been created and populated for the 13th edition. One version is scoped to match the textbook examples. A second version is fleshed out with more data and tables. This version is not complete, however, so that students can create missing tables and additional forms, reports, and modules. Databases are provided in several formats (ASCII tables, Oracle script, and Microsoft Access), but formats vary for the two versions. Some documentation of the databases is also provided. Both versions of the PVFC database are also available on Teradata University Network.

VITALSOURCE eTEXTBOOK

VitalSource eTextbooks were developed for students looking to save on required or recommended textbooks. Students simply select their eText by title or author and pur- chase immediate access to the content for the duration of the course using any major credit card. With a VitalSource eText, students can search for specific key words or page numbers, take notes online, print out reading assignments that incorporate lecture notes, and bookmark important passages for later review. For more information or to purchase a VitalSource eTextbook, visit www.vitalsource.com.

ACKNOWLEDGMENTS

We are grateful to numerous individuals who contributed to the preparation of Modern Database Management, 13th edition. First, we wish to thank our reviewers for their detailed suggestions and insights, characteristic of their thoughtful teaching style. As always, analysis of topics and depth of coverage provided by the reviewers were crucial. Our reviewers and others who gave us many useful comments to improve the text include Tamara Babaian, Bentley University; Subhajyoti Bandyopadhyay, University of Florida; Gary Baram, Temple University; Bijoy Bordoloi, Southern Illinois University, Edwardsville; Timothy Bridges, University of Central Oklahoma; Traci Carte, University of Oklahoma; Laurie Crawford, Franklin University; Wingyan Chung, Santa Clara University; Jagdish Gangolly, State University of New York at Albany; Jon Gant, Syracuse University; Jinzhu Gao, University of the Pacific; Monica Garfield, Bentley University; Rick Gibson, American University; Joy Godin, Georgia College & State University; Jian Guan, University of Louisville; Chengqi Guo, James Madison University; Connie Hecker, Missouri Western State University; William H. Hochstettler III, Franklin University; Dinakar Jayarajan, Illinois Institute of Technology; Michael Johnson, Christopher Newport University; Weiling Ke, Clarkson University; Dongwon Lee, Pennsylvania State University; Ingyu Lee, Troy University; Linda

A01_HOFF3359_13_GE_FM.indd 32 12/04/19 11:44 AM

Preface 33

LeSage, Davenport University; Chang-Yang Lin, Eastern Kentucky University; Brian Mennecke, Iowa State University; Kazuo Nakatani, Florida Gulf Coast University; Dat-Dao Nguyen, California State University, Northridge; Fred Niederman, Saint Louis University; Selwyn Piramuthu, University of Florida; Lara Preiser-Houy, California State Polytechnic University, Pomona; John Russo, Wentworth Institute of Technology; Becky Rutherfoord, Kennesaw State University; Ioulia Rytikova, George Mason University; Richard Segall, Arkansas State University; Sharlene Smith, Gaston College; John Snyder, Colorado Mesa University; Josephine Stanley-Brown, Norfolk State University; Chelley Vician, University of St. Thomas; Ruth Weldon, University of St. Francis; and Daniel S. Weaver, Messiah College; Zuopeng Zhang, State University of New York Plattsburgh; Dana Zhu, Iowa State University; Songhua Zu, New Jersey Institute of Technology.

We received excellent input from experts in industry, including Steve Williams (President, DecisionPath Consulting), Tom Victory (DecisionPath Consulting), Todd Walter, Carrie Ballinger, Rob Armstrong, and David Schoeff (all of Teradata Corp); Chad Gronbach and Philip DesAutels (Microsoft Corp.); Peter Gauvin (Ball Aerospace); and Michael Alexander (Open Access Technology, International).

We are very thankful to Ge Yan, Indiana University, for his contributions to some of the technical material in Chapter 7. We also want to thank Heikki Topi, Bentley University, for his role as author of the Instructor’s Resource Manual. In addition to his duties as author, Heikki took on this additional task and has been diligent in preparing the Instructor’s Resource Manual; in the process he has helped us clarify and fix vari- ous parts of the text. We also want to recognize the important role played by Chelley Vician of the University of St. Thomas, the author of several previous editions of the Instructor’s Resource Manual; her work added great value to this book. We also thank Sven Aelterman, Troy University, for his many excellent suggestions for improvements and clarifications throughout the text.

We are also grateful to the staff and associates of Pearson for their support and guidance throughout this project. In particular, we wish to thank Senior Portfolio Manager Samantha Lewis for her support through this revision process; Program Monitor Danica Monzor (SPi Global), and Associate Project Manager Neha Bhargava (Cenveo), who kept us on track and made sure everything was complete; and Associate Content Producer Stephany Harrington.

While finalizing this edition of Modern Database Management, we pause to remem- ber with deep gratitude the contributions of Dr. Fred McFadden and Dr. Mary Prescott, coauthors of previous editions of this text. Fred and Mary are not with us anymore, but their contributions to MDBM, both content and spirit, continue to be directly and indirectly included in this book.

Finally, we give immeasurable thanks to our spouses, who endured many eve- nings and weekends of solitude for the thrill of seeing a book cover hang on a den wall. In particular, we marvel at the commitment of Patty Hoffer, who has lived the lonely life of a textbook author ’s spouse through 13 editions over more than 35 years of late-night and weekend writing. We also want to sincerely thank Anne-Louise Klaus for being willing to continue her wholehearted support for Heikki’s involve- ment in the project. Although the book project was no longer new for Gayathri Mani, her continued support and understanding are very much appreciated. Much of the value of this text is due to their patience, encouragement, and love, but we alone bear the responsibility for any errors or omissions between the covers.

Jeffrey A. Hoffer

V. Ramesh

Heikki Topi

A01_HOFF3359_13_GE_FM.indd 33 12/04/19 11:44 AM

34 Preface

GLOBAL EDITION ACKNOWLEDGMENTS

Pearson would like to thank the following people for their work on the Global Edition:

Contributors Imran Medi, Asia Pacific University of Technology and Innovation Sahil Raj, Punjabi University Shamikh Siddiqui, Jumeira University, Dubai

Reviewers Thomas Chesney, University of Nottingham Kamran Munir, University of the West of England Liyana Shuib, University of Malaya Shaomin Wu, The University of Kent

A01_HOFF3359_13_GE_FM.indd 34 12/04/19 11:44 AM

35

The Context of Database Management

AN OVERVIEW OF PART I

In this chapter and opening part of the book, we set the context and provide basic database concepts and definitions used throughout the text. In this part, you will understand database management as an exciting, challenging, and growing field that provides numerous career opportunities for information systems students. Databases continue to become a more common part of everyday living and a more central component of business operations. From the database that stores contact information in your smartphone or tablet to the very large databases that support enterprise-wide information systems and provide important insights for organizational decision makers, databases have become the central points of data storage that were originally envisioned decades ago. Customer relationship management and Internet shopping are examples of two database-dependent activities that have developed in recent years. The development of data warehouses and “big data” repositories that provide managers the opportunity for deeper and broader historical analysis of data and specific guidance for future actions also continues to take on more importance.

We begin by providing basic definitions of data, database, metadata, database management system, data warehouse, and other terms associated with this environment. We compare databases with the older file management systems they replaced and describe several important advantages that are enabled by the carefully planned use of databases. You will see a framework that provides an integrated perspective to both transactional and analytic use of various data management technologies to be used throughout this book and in your career.

The chapter also describes the general steps followed in the analysis, design, implementation, and administration of databases. Further, this chapter also illustrates how the database development process fits into the overall information systems development process. Database development for both structured life cycle and prototyping methodologies is explained. We introduce enterprise data modeling, which sets the range and general contents of organizational databases. This is often the first step in database development. You will learn about the concept of schemas and the three-schema architecture, which is the dominant approach in modern database systems. We describe the major components of the database environment and the types of applications as well as multi-tier and enterprise databases. Enterprise databases include those that are used to support enterprise resource planning systems and data

PART I

Chapter 1 The Database Environment and Development Process

M01A_HOFF3359_13_GE_P01.indd 35 22/02/19 10:30 AM

36 Part I • The Context of Database Management

warehouses. Finally, we describe the roles in which you might be involved as part of a database development project. The Pine Valley Furniture Company case is introduced and used to illustrate many of the principles and concepts of database management. This case is used throughout the text as a continuing example of the use of database management systems.

M01A_HOFF3359_13_GE_P01.indd 36 22/02/19 10:30 AM

37

LEARNING OBJECTIVES After studying this chapter, you should be able to:

■■ Concisely define each of the following key terms: database, data, information, metadata, database application, data model, entity, relational database, database management system (DBMS), data independence, user view, constraint, data modeling and design tools, repository, enterprise data modeling, systems development life cycle (SDLC), conceptual schema, logical schema, physical schema, prototyping, agile software development, project, enterprise resource planning (ERP) system, data warehouse, and data lake.

■■ Name several limitations of conventional file processing systems. ■■ Explain at least 10 advantages of the database approach compared to traditional file processing.

■■ Identify several costs and risks of the database approach. ■■ Distinguish between operational (transactional) and informational (data warehousing and big data) data management approaches and related technologies.

■■ List and briefly describe nine components of a typical database environment. ■■ Identify four categories of applications that use databases and their key characteristics.

■■ Describe the life cycle of a systems development project, with an emphasis on the purpose of database analysis, design, and implementation activities.

■■ Explain the prototyping and agile-development approaches to database and application development.

■■ Explain the roles of individuals who design, implement, use, and administer databases.

■■ Explain the differences between personal, multi-tiered, and enterprise-level data management solutions.

■■ Explain the differences among external, conceptual, and internal schemas and the reasons for the use of a three-schema architecture for databases.

Visit www.pearsonglobaleditions .com to view the accompanying video for this chapter.

The Database Environment and Development Process

1

M01B_HOFF3359_13_GE_C01.indd 37 10/04/19 2:24 PM

38 Part I • The Context of Database Management

DATA MATTER!

The amount of data being generated, stored, and processed is growing by leaps and bounds. According to a McKinsey Global Institute Report (Manyika et al., 2011), it is estimated that in 2010 alone, global enterprises stored more than 7 exabytes of data (an exabyte is a billion gigabytes), while consumers stored more than 6 exabytes of new data on devices such as personal computers, smartphones, tablets, and notebooks. That is a lot of data! As more and more of the world becomes digital and the products we use every day, such as watches, refrigerators, and so forth, become smarter, the amount of data that needs to be generated, stored, and processed will only continue to grow.

The availability of all of these data is also opening up unparalleled opportunities for companies to leverage data for various purposes. A recent study by IBM (IBM, 2011) shows that one of the top priorities for CEOs in the coming years is the ability to use insights and intelligence that can be gleaned from data for competitive advantage. The McKinsey Global Institute Report (Manyika et al., 2011) estimates that by appropriately leveraging the data available to them, the U.S. retail industry can see up to a 60 percent increase in net margin, and manufacturing can realize up to a 50 percent reduction in product development costs.

The availability of large amounts of data is also fueling innovation in companies and allowing them to think differently and creatively about various aspects of their businesses. Below you will find some examples from a variety of domains:

1. The Memorial Sloan-Kettering Cancer center is using IBM Watson (do you remember Watson beating Ken Jennings in Jeopardy?) to help ana- lyze the information from medical literature, research, past case histories, and best practices to help provide oncologists with evidence-based recom- mendations (www-935.ibm.com/services/multimedia/MSK_Case_Study_ IMC14794.pdf).

2. Continental Airlines (now United) invested in a real-time business intelli- gence capability and was able to dramatically improve its customer service and operations. For example, it can now track whether a high-value customer is experiencing a delay in a trip, where and when the customer will arrive at the airport, and the gate the customer must go to make the next connection (Anderson-Lehman et al., 2004).

3. A leading fast-food chain uses video information from its fast-food lane to determine what food products to display on its (digital) menu board. If the lines are long, the menu displays items that can be served quickly. If the lines are short, the menu displays higher-margin but slower-to-prepare items ( Laskowski, 2014).

4. Nagoya Railroad analyzes data about its customers’ travel habits along with their shopping and dining habits to better understand its customers. For example, it was able to identify that young women who used a particular train station for their commute also tended to eat at a particular type of res- taurant and buy from certain types of stores. This information allows Nagoya Railroad to create a targeted marketing campaign (http://public.dhe.ibm .com/common/ssi/ecm/en/ytc03707usen/YTC03707USEN.PDF).

5. Kroger, a fast-growing grocery store chain, was able to increase the return rates of its direct mail campaigns to a very high level of 70 percent by per- sonalizing the offers based on the data the company had collected regarding their customer’s purchasing behavior (Groenfeldt, 2013).

At the heart of all the above examples is the ability to collect, organize, and manage data. This is precisely the focus of this textbook. This understanding will give you the power to support any business strategy and the deep satisfaction that comes from knowing how to organize data so that financial, marketing, or customer service questions can be answered almost as soon as they are asked. Enjoy!

M01B_HOFF3359_13_GE_C01.indd 38 15/03/19 10:23 AM

1 • The Database Environment and Development Process 39

INTRODUCTION

Over the past two decades, data have become strategic assets for most organizations. Databases store, manipulate, and retrieve data in nearly every type of organization, including business, health care, education, government, libraries, and many scientific fields. Individuals with various personal devices and employees using enterprise- wide distributed applications depend on database technology. Customers and other remote users access databases through diverse technologies, such as automated teller machines, Web browsers, smartphones, and intelligent living and office environments. Most Web-based applications depend on a database foundation.

Following this period of rapid growth, will the demand for databases and database technology level off? Very likely not! In the highly competitive environment of today, there is every indication that database technology will assume even greater importance. Managers seek to use knowledge derived from databases for competitive advantage. For example, detailed sales databases can be mined to determine customer buying patterns as a basis for advertising and marketing campaigns. Organizations embed procedures called alerts in databases to warn of unusual conditions, such as impending stock shortages or opportunities to sell additional products, and to trigger appropriate actions. Analytics in its various forms—including big data analytics—depends on databases and other data management technologies.

Although the future of databases is assured, much work remains to be done. Many organizations have a proliferation of incompatible databases that were developed to meet immediate needs rather than based on a planned strategy or a well-managed evolution. Enormous amounts of data are trapped in older, “legacy” systems, and the data are often of poor quality. New skills are required to design and manage data warehouses and other repositories of data and to fully leverage all the data that are being captured in the organization. There is a shortage of skills in areas such as database analysis, database design, database application development, and business analytics. You will learn about these and other important issues in this textbook to equip you for the jobs of the future.

A course in database management has emerged as one of the most important courses in the information systems curriculum today. Further, many schools have added additional elective courses in data warehousing, data mining, and other aspects of business analytics to provide in-depth coverage of these important topics. As information systems professionals, you must be prepared to analyze database requirements and design and to implement databases within the context of information systems development. You also must be prepared to consult with end users and show them how they can use databases (or data warehouses) to build decision models and systems for competitive advantage. The widespread use of databases attached to Web sites that return dynamic information to users of these sites requires that you understand not only how to link databases to the Web- based applications but also how to secure those databases so that their contents can be viewed but not compromised by outside users.

In this chapter, you will learn about the basic concepts of databases and database management systems (DBMSs). You will review traditional file management systems and some of their shortcomings that led to the database approach. Next, you will consider the benefits, costs, and risks of using the database approach. We review the range of technologies used to build, use, and manage databases; describe the types of applications that use databases (personal, multi-tier, and enterprise); and describe how databases have evolved over the past five decades. The chapter also presents a framework that will help you understand traditional and emerging data management approaches and technologies in a joint context.

Because a database is one part of an information system, this chapter also examines how the database development process fits into the overall information systems development process. The chapter emphasizes the need to coordinate database development with all the other activities in the development of a complete

M01B_HOFF3359_13_GE_C01.indd 39 15/03/19 10:23 AM

40 Part I • The Context of Database Management

information system. It includes highlights from a hypothetical database development process at Pine Valley Furniture Company. Using this example, the chapter introduces tools for developing databases on personal computers and the process of extracting data from enterprise databases for use in stand-alone applications.

There are several reasons for discussing database development at this point. First, although you may have used the basic capabilities of a database management system, such as Microsoft Access, you may not yet have developed an understanding of how these databases were developed. Using simple examples, this chapter briefly illustrates what you will be able to do after you complete a database course using this text. Thus, this chapter helps you develop a vision and context for each topic developed in detail in subsequent chapters.

Second, many students learn best from a text full of concrete examples. Although all of the chapters in this text contain numerous examples, illustrations, and actual database designs and code, each chapter concentrates on a specific aspect of database management. This chapter will help you understand, with minimal technical details, how all of these individual aspects of database management are related and how database development tasks and skills relate to what you are learning in other information systems courses.

Finally, many instructors want you to begin the initial steps of a database development group or individual project early in your database course. This chapter gives you an idea of how to structure a database development project sufficient to begin a course exercise. Obviously, because this is only the first chapter, many of the examples and notations you will encounter in this chapter are much simpler than those required for your project, for other course assignments, or in a real organization.

One note of caution: You will not learn how to design or develop databases just from this chapter. Sorry! You will discover that the content of this chapter is introductory and simplified. Many of the notations used in this chapter are not exactly like the ones you will learn in subsequent chapters. Our purpose in this chapter is to give you a general understanding of the key steps and types of skills, not to teach you specific techniques. You will, however, learn fundamental concepts and definitions and develop an intuition and motivation for the skills and knowledge presented in later chapters.

BASIC CONCEPTS AND DEFINITIONS

A database is an organized collection of logically related data. Not many words in the definition, but have you looked at the size of this book? There is a lot to do to fulfill this definition.

A database may be of any size and complexity. For example, a salesperson may maintain a small database of customer contacts—consisting of a few megabytes of data—on her laptop computer. A large corporation may build a large database con- sisting of several terabytes of data (a terabyte is a trillion bytes) on a large mainframe computer that is used for decision support applications. Very large data warehouses contain more than a petabyte of data. (A petabyte is a quadrillion bytes.) The assumption throughout the text is that all databases are computer based.

Data

Historically, the term data referred to facts concerning objects and events that could be recorded and stored on computer media. For example, in a salesperson’s database, the data would include facts such as customer name, address, and telephone number. This type of data is called structured data. The most important structured data types are numeric, character, and dates. Structured data are stored in tabular form (in tables, rela- tions, arrays, spreadsheets, and so forth) and are most commonly found in traditional databases and data warehouses.

The traditional definition of data now needs to be expanded to reflect a new reality: Databases today are used to store objects such as documents, e-mails, tweets, Facebook

Database

An organized collection of logically related data.

M01B_HOFF3359_13_GE_C01.indd 40 15/03/19 10:23 AM

1 • The Database Environment and Development Process 41

posts, GPS information, maps, photographic images, sound, and video segments in addition to structured data. For example, the salesperson’s database might include a photo image of the customer contact. It might also include a sound recording or video clip about the most recent product. This type of data is referred to as unstructured data, or as multimedia data. Today, structured and unstructured data are often combined in the same database to create a true multimedia environment. For example, an automo- bile repair shop can combine structured data (describing customers and automobiles) with multimedia data (photo images of the damaged autos and scanned images of insurance claim forms). One of the defining elements of “big data” technologies, which will also be covered later in this book, is that they provide capabilities to deal with highly heterogeneous data.

An expanded definition of data that includes structured and unstructured types is “a stored representation of objects and events that have meaning and importance in the user’s environment.”

Data versus Information

The terms data and information are closely related and in fact are often used interchange- ably. However, it is useful to distinguish between data and information. Information is data that have been processed in such a way that the knowledge of the person who uses the data is increased. For example, consider the following list of facts:

1 Baker, Kenneth D. 324917628 2 Doyle, Joan E. 476193248 3 Finkle, Clive R. 548429344 4 Lewis, John C. 551742186 5 McFerran, Debra R. 409723145

These facts satisfy our definition of data, but most people would agree that the data are useless in their present form. Even if you guessed that this is a list of people’s names paired with their Social Security numbers, the data remain useless because you would have no idea what the entries mean. Notice what happens when you see the same data in a context, as shown in Figure 1-1a.

By adding a few additional data items and providing some structure, you are able to recognize a class roster for a particular course. This is useful information to some users, such as the course instructor and the registrar’s office. Of course, as general awareness of the importance of strong data security has increased, few organizations use Social Security numbers as identifiers any longer. Instead, most organizations use an internally generated number for identification purposes.

Another way to convert data into information is to summarize them or otherwise process and present them for human interpretation. For example, Figure 1-1b shows

Data

Stored representations of objects and events that have meaning and importance in the user’s environment.

Information

Data that have been processed in such a way as to increase the knowledge of the person who uses the data.

Class Roster

Semester: Spring 2018Course: MGT 500 Business Policy

2Section:

Baker, Kenneth D. Doyle, Joan E. Finkle, Clive R. Lewis, John C. McFerran, Debra R. Sisneros, Michael

Name ID 324917628 476193248 548429344 551742186 409723145 392416582

Major MGT MKT PRM MGT IS ACCT

GPA 2.9 3.4 2.8 3.7 2.9 3.3

FIGURE 1-1 Converting data to information

(a) Data in context

M01B_HOFF3359_13_GE_C01.indd 41 15/03/19 10:23 AM

42 Part I • The Context of Database Management

summarized student enrollment data presented as graphical information. This informa- tion could be used as a basis for deciding whether to add new courses or to hire new faculty members.

In practice, according to our definitions, databases today may contain data, information, or both. For example, a database may contain an image of the class roster document shown in Figure 1-1a. Also, data are often preprocessed and stored in sum- marized form in databases that are used for decision support. Throughout this text, we use the term database without distinguishing its contents as data or information.

Metadata

As discussed earlier, data become useful only when placed in some context. The primary mechanism for providing context for data is metadata. Metadata are data that describe the properties or characteristics of end-user data and the context of that data. Some of the properties that are typically described include data names, definitions, length (or size), and allowable values. Metadata describing data context include the source of the data, where the data are stored, ownership (or stewardship), and usage. Although it may seem circular, many people think of metadata as “data about data.”

Some sample metadata for the Class Roster (Figure 1-1a) are listed in Table 1-1. For each data item that appears in the Class Roster, the metadata show the data item name, the data type, length, minimum and maximum allowable values (where appropriate), a brief description of each data item, and the source of the data (sometimes called the system of record). Notice the distinction between data and metadata. Metadata are once removed from data. That is, metadata describe the properties of data but are separate from that data. Thus, the metadata shown in Table 1-1 do not include any sample data from the Class Roster of Figure 1-1a. Metadata enable database designers and users to under- stand what data exist, what the data mean, and how to distinguish between data items

Metadata

Data that describe the properties or characteristics of end-user data and the context of those data.

TABLE 1-1 Example Metadata for Class Roster

Data Item Metadata

Name Type Length Min Max Description Source

Course Alphanumeric 30 Course ID and name Academic Unit

Section Integer 1 1 9 Section number Registrar

Semester Alphanumeric 10 Semester and year Registrar

Name Alphanumeric 30 Student name Student IS

ID Integer 9 Student ID (SSN) Student IS

Major Alphanumeric 4 Student major Student IS

GPA Decimal 3 0.0 4.0 Student grade point average Academic Unit

MKT (15%)

MGT (20%)

ACCT (25%)IS

(15%)

OTHER (15%)

FIN (10%)

Percent Enrollment by Major (2018) Year

Enrollment Projections

N u m

b er

o f

S tu

d en

ts

300

5 actual 5 estimated

200

100

2013 2014 2015 2016 2017 2018

(b) Summarized data

FIGURE 1-1 (continued)

M01B_HOFF3359_13_GE_C01.indd 42 15/03/19 10:23 AM

1 • The Database Environment and Development Process 43

that at first glance look similar. Managing metadata is at least as crucial as managing the associated data because data without clear meaning can be confusing, misinterpreted, or erroneous. Typically, much of the metadata are stored as part of the database and may be retrieved using the same approaches that are used to retrieve data or information.

Data can be stored in files (think Excel sheets) or in databases. In the following sections, you will learn about the progression from file processing systems to databases and the advantages and disadvantages of each.

TRADITIONAL FILE PROCESSING SYSTEMS

When computer-based data processing was first available, there were no databases. To be useful for business applications, computers had to store, manipulate, and retrieve large files of data. Computer file processing systems were developed for this purpose. Although these systems have evolved over time, their basic structure and purpose have changed little over several decades.

As business applications became more complex, it became evident that traditional file processing systems had a number of shortcomings and limitations (described next). As a result, these systems have been replaced by database processing systems in most business applications today. Nevertheless, you should have at least some familiarity with file processing systems since understanding the problems and limitations inherent in file processing systems can help you avoid these same problems when designing database systems. It should be noted that Excel files, in general, fall into the same category as file systems and suffer from the same drawbacks listed below. Informal use of Excel for management of data is believed to continue to be quite widespread, although valid research results regarding this are difficult to find.

File Processing Systems at Pine Valley Furniture Company

Early computer applications at Pine Valley Furniture used the traditional file processing approach. This approach to information systems design met the data processing needs of individual departments rather than the overall information needs of the organization. The information systems group typically responded to users’ requests for new systems by developing (or acquiring) new computer programs for individual applications, such as inventory control, accounts receivable, or human resource management. No overall map, plan, or model guided application growth.

Three of the computer applications based on the file processing approach are shown in Figure 1-2. The systems illustrated are Order Filling, Invoicing, and Payroll.

FIGURE 1-2 Old file processing systems at Pine Valley Furniture Company

Program BProgram A Program AProgram C Program B Program A Program B

Inventory Master

File

Back Order File

Employee Master

File

Customer Master

File

Orders Department Accounting Department Payroll Department

Order Filling System

Invoicing System

Payroll System

Inventory Pricing

File

Customer Master

File

M01B_HOFF3359_13_GE_C01.indd 43 15/03/19 10:23 AM

44 Part I • The Context of Database Management

The figure also shows the major data files associated with each application. A file is a collection of related records. For example, the Order Filling System has three files: Customer Master, Inventory Master, and Back Order. Notice that there is duplication of some of the files used by the three applications, which is typical of file processing systems.

Disadvantages of File Processing Systems

Several disadvantages associated with conventional file processing systems are listed in Table 1-2 and described briefly next. It is important to understand these issues because if you do not follow the database management practices described in this book, some of these disadvantages can also become issues for databases as well.

PROGRAM-DATA DEPENDENCE File descriptions are stored within each database application program that accesses a given file. For example, in the Invoicing System in Figure 1-2, Program A accesses the Inventory Pricing File and the Customer Master File. Because the program contains a detailed file description for these files, any change to a file structure requires changes to the file descriptions for all programs that access the file.

Notice in Figure 1-2 that the Customer Master File is used in the Order Filling System and the Invoicing System. Suppose it is decided to change the customer address field length in the records in this file from 30 to 40 characters. The file descriptions in each program that is affected (up to five programs) would have to be modified. It is often difficult even to locate all programs affected by such changes. Worse, errors are often introduced when making such changes.

DUPLICATION OF DATA Because applications are often developed independently in file processing systems, unplanned duplicate data files are the rule rather than the exception. For example, in Figure 1-2, the Order Filling System contains an Inventory Master File, whereas the Invoicing System contains an Inventory Pricing File. These files contain data describing Pine Valley Furniture Company’s products, such as prod- uct description, unit price, and quantity on hand. This duplication is wasteful because it requires additional storage space and increased effort to keep all files up to date. Data formats may be inconsistent, data values may not agree, or both. Reliable metadata are very difficult to establish in file processing systems. For example, the same data item may have different names in different files, or, conversely, the same name may be used for different data items in different files.

LIMITED DATA SHARING With the traditional file processing approach, each applica- tion has its own private files, and users have little opportunity to share data outside their own applications. Notice in Figure 1-2, for example, that users in the Accounting Department have access to the Invoicing System and its files, but they probably do not have access to the Order Filling System or to the Payroll System and their files. Man- agers often find that a requested report requires a major programming effort because data must be drawn from several incompatible files in separate systems. When different organizational units own these different files, additional management barriers must be overcome.

LENGTHY DEVELOPMENT TIMES With traditional file processing systems, each new application requires that the developer essentially start from scratch by designing

Database application

An application program (or set of related programs) that is used to perform a series of database activities (create, read, update, and delete) on behalf of database users.

TABLE 1-2 Disadvantages of File Processing Systems

Program-data dependence

Duplication of data

Limited data sharing

Lengthy development times

Excessive program maintenance

M01B_HOFF3359_13_GE_C01.indd 44 15/03/19 10:23 AM

1 • The Database Environment and Development Process 45

new file formats and descriptions and then writing the file access logic for each new program. The lengthy development times required are inconsistent with today’s fast- paced business environment, in which time to market (or time to production for an information system) is a key business success factor.

EXCESSIVE PROGRAM MAINTENANCE The preceding factors all combined to cre- ate a heavy program maintenance load in organizations that relied on traditional file processing systems. In fact, as much as 80 percent of the total information system’s development budget might be devoted to program maintenance in such organizations. This, in turn, means that resources (time, people, and money) are not being spent on developing new applications.

As discussed above, these disadvantages are true also in situations when individ- uals and organizational units maintain important organizational data in Excel spread- sheets. Further, it is important to note that many of the disadvantages of file processing you have learned about can also be limitations of databases if an organization does not properly apply the database approach. For example, if an organization develops many separately managed databases (say, one for each division or business function) with little or no coordination of the metadata, uncontrolled data duplication, limited data sharing, lengthy development time, and excessive program maintenance can occur. Thus, the database approach, which is explained in the next section, is as much a way to manage organizational data as it is a set of technologies for defining, creating, maintain- ing, and using these data.

THE DATABASE APPROACH

So, how do you overcome the flaws of file processing? No, you do not call Ghostbusters, but you can do something better: You should follow the database approach. You will first learn some core concepts that are fundamental in understanding the database approach to managing data. You will then discover how the database approach can overcome the limitations of the file processing approach.

Data Models

Designing a database properly is fundamental to establishing a database that meets the needs of the users. Data models capture the nature of and relationships among data and are used at different levels of abstraction as a database is conceptualized and designed. The effectiveness and efficiency of a database is directly associated with the structure of the database. Various graphical systems exist that convey this structure and are used to produce data models that can be understood by end users, systems analysts, and database designers. Chapters 2 and 3 are devoted to developing your understand- ing of data modeling, as is Chapter 14, on the book’s Web site, which addresses a differ- ent approach using object-oriented data modeling. A typical data model is made up of entities, attributes, and relationships, and the most common data modeling representa- tion is the entity-relationship model. A brief description is presented next. More details will be forthcoming in Chapters 2 and 3.

ENTITIES Customers and orders are objects about which a business maintains infor- mation. They are referred to as “entities.” An entity is like a noun in that it describes a person, a place, an object, an event, or a concept in the business environment for which information must be recorded and retained. CUSTOMER and ORDER are entities in Figure 1-3a. The data you are interested in capturing about the entity (e.g., Customer Name) is called an attribute. Data are recorded for many customers. Each customer’s information is referred to as an instance of CUSTOMER.

RELATIONSHIPS A well-structured database establishes the relationships between entities that exist in organizational data so that desired information can be retrieved. Most relationships are one-to-many (1:M) or many-to-many (M:N). A customer can place (the Places relationship) more than one order with a company. However, each

Data model

Graphical systems used to capture the nature and relationships among data.

Entity

A person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data.

M01B_HOFF3359_13_GE_C01.indd 45 15/03/19 10:23 AM

46 Part I • The Context of Database Management

is included in the file (or relation) that holds customer information such as name, address, and so forth. Every time the customer places an order, the customer identification number is also included in the relation that holds order information. Relational databases use the identification number to establish the relationship between customer and order.

Database Management Systems

A database management system (DBMS) is a software system that enables the use of a database approach. The primary purpose of a DBMS is to provide a systematic method of creating, updating, storing, and retrieving the data stored in a database. It enables end users and application programmers to share data, and it enables data to be shared among multiple applications rather than propagated and stored in new files for every new application (Mullins, 2002). A DBMS also provides facilities for controlling data access, enforcing data integrity, managing concurrency control, and restoring a database. You will learn about these DBMS features in detail in Chapters 7 and 8.

Now that you understand the basic elements of a database approach, you are in a good position to try to understand the differences between a database approach and a file-based approach. Let us begin by comparing Figures 1-2 and 1-4. Figure 1-4 depicts a representation (entities) of how the data can be considered to be stored in the database. Notice that unlike Figure 1-2, in Figure 1-4, there is only one place where the CUSTOMER information is stored rather than the two Customer Master Files. Both the Order Filling System and the Invoicing System will access the data contained in the single CUSTOMER entity. Further, what CUSTOMER information is stored, how it is stored, and how it is accessed are likely not closely tied to either of the two systems. All of this enables you to achieve the advantages listed in the next section. Of course, it is important to note that a real-life database will likely include thousands of entities and relationships among them.

Advantages of the Database Approach

The primary advantages of a database approach, enabled by DBMSs, are summarized in Table 1-3 and described next.

PROGRAM-DATA INDEPENDENCE The separation of data descriptions (metadata) from the application programs that use the data is called data independence. With the database approach, data descriptions are stored in a central location called the repository.

Relational database

A database that represents data as a collection of tables in which all data relationships are represented by common values in related tables.

Database management system (DBMS)

A software system that is used to create, maintain, and provide controlled access to user databases.

Data independence

The separation of data descriptions from the application programs that use the data.

Is Placed By

Contains

Is Contained In

Places

CUSTOMER

ORDER

PRODUCT

FIGURE 1-3 Comparison of enterprise- and project-level data models

Is Contained In

Places

Is Placed By

Contains

CUSTOMER Customer ID Customer Name

ORDER Order ID Customer ID Order Date

Has

Is For

PRODUCT Product ID Standard Price

ORDER LINE Quantity

(a) Segment of an enterprise data model

(b) Segment of a project data model

order is usually associated with (the Is Placed By relationship) a particular customer. Figure  1-3a shows the 1:M relationship of customers who may place one or more orders; the 1:M nature of the relationship is marked by the crow’s foot attached to the rectangle (entity) labeled ORDER. This relationship appears to be the same in Figures 1-3a and 1-3b. However, the relationship between orders and products is M:N. An order may be for one or more products, and a product may be included on more than one order. It is worthwhile noting that Figure 1-3a is an enterprise-level model, where it is necessary to include only the higher-level relationships of customers, orders, and products. The project-level diagram shown in Figure 1-3b includes additional levels of details, such as the further details of an order.

Relational Databases

Relational databases establish the relationships between entities by means of common fields included in a file, called a relation. The relationship between a customer and the customer’s order depicted in the data models in Figure 1-3 is established by including the customer’s number with the customer’s order. Thus, a customer’s identification number

M01B_HOFF3359_13_GE_C01.indd 46 15/03/19 10:23 AM

1 • The Database Environment and Development Process 47

is included in the file (or relation) that holds customer information such as name, address, and so forth. Every time the customer places an order, the customer identification number is also included in the relation that holds order information. Relational databases use the identification number to establish the relationship between customer and order.

Database Management Systems

A database management system (DBMS) is a software system that enables the use of a database approach. The primary purpose of a DBMS is to provide a systematic method of creating, updating, storing, and retrieving the data stored in a database. It enables end users and application programmers to share data, and it enables data to be shared among multiple applications rather than propagated and stored in new files for every new application (Mullins, 2002). A DBMS also provides facilities for controlling data access, enforcing data integrity, managing concurrency control, and restoring a database. You will learn about these DBMS features in detail in Chapters 7 and 8.

Now that you understand the basic elements of a database approach, you are in a good position to try to understand the differences between a database approach and a file-based approach. Let us begin by comparing Figures 1-2 and 1-4. Figure 1-4 depicts a representation (entities) of how the data can be considered to be stored in the database. Notice that unlike Figure 1-2, in Figure 1-4, there is only one place where the CUSTOMER information is stored rather than the two Customer Master Files. Both the Order Filling System and the Invoicing System will access the data contained in the single CUSTOMER entity. Further, what CUSTOMER information is stored, how it is stored, and how it is accessed are likely not closely tied to either of the two systems. All of this enables you to achieve the advantages listed in the next section. Of course, it is important to note that a real-life database will likely include thousands of entities and relationships among them.

Advantages of the Database Approach

The primary advantages of a database approach, enabled by DBMSs, are summarized in Table 1-3 and described next.

PROGRAM-DATA INDEPENDENCE The separation of data descriptions (metadata) from the application programs that use the data is called data independence. With the database approach, data descriptions are stored in a central location called the repository.

Relational database

A database that represents data as a collection of tables in which all data relationships are represented by common values in related tables.

Database management system (DBMS)

A software system that is used to create, maintain, and provide controlled access to user databases.

Data independence

The separation of data descriptions from the application programs that use the data.

FIGURE 1-4 Enterprise model for Figure 1-3 segments

CUSTOMER

Places

Is Placed By

Contains

Contains

Is Contained In

Is Contained In

Keeps Price Changes For

Has Price Changes Of

Generates

Completes

ORDER INVENTORY EMPLOYEE

BACKORDER

INVENTORY PRICING HISTORY

M01B_HOFF3359_13_GE_C01.indd 47 15/03/19 10:23 AM

48 Part I • The Context of Database Management

This property of database systems allows an organization’s data to change and evolve (within limits) without changing the application programs that process the data.

PLANNED DATA REDUNDANCY Good database design attempts to integrate previously separate (and redundant) data files into a single, logical structure. Ideally, each primary fact is recorded in only one place in the database. For example, facts about a product, such as the Pine Valley oak computer desk, its finish, price, and so forth, are recorded together in one place in the Product table, which contains data about each of Pine Val- ley’s products. The database approach does not eliminate redundancy entirely, but it enables the designer to control the type and amount of redundancy. At other times, it may be desirable to include some limited redundancy to improve database perfor- mance, as you will see in later chapters.

IMPROVED DATA CONSISTENCY By eliminating or controlling data redundancy, you can greatly reduce the opportunities for inconsistency. For example, if a customer’s address is stored only once, we cannot disagree about the customer’s address. When the customer’s address changes, recording the new address is greatly simplified because the address is stored in a single place. Finally, you avoid wasting storage space that results from redundant data storage.

IMPROVED DATA SHARING A database is designed as a shared corporate resource. Authorized internal and external users are granted permission to use the database, and each user (or group of users) is provided one or more user views into the database to facilitate this use. A user view is a logical description of some portion of the database that is required by a user to perform some task. A user view is often developed by identifying a form or report that the user needs on a regular basis. For example, an employee working in human resources will need access to confidential employee data; a customer needs access to the product catalog available on Pine Valley’s Web site. The views for the human resources employee and the customer are drawn from completely different areas of one unified database.

INCREASED PRODUCTIVITY OF APPLICATION DEVELOPMENT A major advantage of the database approach is that it greatly reduces the cost and time for developing new business applications. There are three important reasons that database applications can often be developed much more rapidly than conventional file applications:

1. Assuming that the database and the related data capture and maintenance appli- cations have already been designed and implemented, the application developer can concentrate on the specific functions required for the new application without having to worry about file design or low-level implementation details.

2. The database management system provides a number of high-level productivity tools, such as forms and report generators, and high-level languages that automate

User view

A logical description of some portion of the database that is required by a user to perform some task.

TABLE 1-3 Advantages of the Database Approach

Program-data independence

Planned data redundancy

Improved data consistency

Improved data sharing

Increased productivity of application development

Enforcement of standards

Improved data quality

Improved data accessibility and responsiveness

Reduced program maintenance

Improved decision support

M01B_HOFF3359_13_GE_C01.indd 48 15/03/19 10:23 AM

1 • The Database Environment and Development Process 49

some of the activities of database design and implementation. You will learn about many of these tools in subsequent chapters.

3. Significant improvement in application developer productivity, estimated to be as high as 60 percent (Long, 2005), is currently being realized through the use of Web services based on the use of standard Internet protocols and a universally accepted data format (XML).

ENFORCEMENT OF STANDARDS When the database approach is implemented with full management support, the database administration function should be granted single-point authority and responsibility for establishing and enforcing data standards. These standards will include naming conventions, data quality standards, and uniform procedures for accessing, updating, and protecting data. The data repository provides database administrators with a powerful set of tools for developing and enforcing these standards. Unfortunately, the failure to implement a strong database administration function is perhaps the most common source of database failures in organizations. You will learn about the database administration (and related data administration) func- tions in Chapter 12.

IMPROVED DATA QUALITY Concern with poor quality data is a common theme in strategic planning and database administration today. In 2011 alone, poor data qual- ity is estimated to have cost the U.S. economy almost $3 trillion, almost twice the size of the federal deficit (http://hollistibbetts.sys-con.com/node/1975126). The database approach provides a number of tools and processes to improve data quality. Two of the more important are the following:

1. Database designers can specify integrity constraints that are enforced by the DBMS. A constraint is a rule that cannot be violated by database users. We describe numerous types of constraints (also called “business rules”) in Chapters 2 and 3. If a customer places an order, the constraint that ensures that the customer and the order remain associated is called a “relational integrity constraint,” and it pre- vents an order from being entered without specifying who placed the order.

2. One of the objectives of a data warehouse environment is to clean up (or “scrub”) operational data before they are placed in the data warehouse (Jordan, 1996). Do you ever receive multiple copies of a catalog? The company that sends you three copies of each of its mailings could recognize significant postage and printing savings if its data were scrubbed, and its understanding of its customers would also be enhanced if it could determine a more accurate count of existing customers. You will learn about data warehouses and data integration in Chapter 9 and the potential for improving data quality in Chapter 12.

IMPROVED DATA ACCESSIBILITY AND RESPONSIVENESS With a relational database, end users without programming experience can often retrieve and display data, even when they cross traditional departmental boundaries. For example, an employee can display information about computer desks at Pine Valley Furniture Company with the following query:

SELECT *

FROM Product_T

WHERE ProductDescription = “Computer Desk”;

The language used in this query is called Structured Query Language, or SQL. (You will study this language in detail in Chapters 5 and 6.) Although the queries constructed can be much more complex, the basic structure of the query is easy for even novice, non- programmers to grasp. If they understand the structure and names of the data that fit within their view of the database, they soon gain the ability to retrieve answers to new questions without having to rely on a professional application developer. This can be dangerous; queries should be thoroughly tested to be sure they are returning accurate data before relying on their results, and novices may not understand that challenge.

Constraint

A rule that cannot be violated by database users.

M01B_HOFF3359_13_GE_C01.indd 49 15/03/19 10:23 AM

50 Part I • The Context of Database Management

REDUCED PROGRAM MAINTENANCE Stored data must be changed frequently for a variety of reasons: New data item types are added, data formats are changed, and so forth. A celebrated example of this problem was the well-known “year 2000” problem, in which common two-digit year fields were extended to four digits to accommodate the rollover from the year 1999 to the year 2000.

In a file processing environment, the data descriptions and the logic for accessing data are built into individual application programs (this is the program-data depen- dence issue described earlier). As a result, changes to data formats and access methods inevitably result in the need to modify application programs. In a database environment, data are more independent of the application programs that use them. Within limits, you can change either the data or the application programs that use the data without necessitating a change in the other factor. As a result, program maintenance can be sig- nificantly reduced in a modern database environment.

IMPROVED DECISION SUPPORT Some databases are designed expressly for decision support applications. For example, some databases are designed to support customer relationship management, whereas others are designed to support financial analysis or supply chain management. You will study how databases are tailored for different decision support applications and analytical styles in Chapters 9 through 11.

Cautions about Database Benefits

The previous section identified 10 major potential benefits of the database approach. However, we must caution you that many organizations have been frustrated in attempting to realize some of these benefits. For example, the goal of data indepen- dence (and, therefore, reduced program maintenance) has proven elusive due to the limitations of older data models and database management software. Fortunately, the relational model and the newer object-oriented model provide a significantly better environment for achieving these benefits. Another reason for failure to achieve the intended benefits is poor organizational planning and database implementation; even the best data management software cannot overcome such deficiencies. For this reason, you will learn about the importance of database planning and design throughout this text.

Costs and Risks of the Database Approach

A database is not a silver bullet, and it does not have the magic power of Harry Potter. As with any other business decision, the database approach entails some additional costs and risks that must be recognized and managed when it is implemented (see Table 1-4).

NEW, SPECIALIZED PERSONNEL Frequently, organizations that adopt the database approach need to hire or train individuals to design and implement databases, provide database administration services, and manage a staff of new people. Further, because of the rapid changes in technology, these new people will have to be retrained or upgraded on a regular basis. This personnel increase may be more than offset by other productivity gains, but an organization should recognize the need for these specialized skills, which are required to obtain the most from the potential benefits. You will learn about the staff requirements for database management in Chapter 12.

TABLE 1-4 Costs and Risks of the Database Approach

New, specialized personnel

Installation and management cost and complexity

Conversion costs

Need for explicit backup and recovery

Organizational conflict

M01B_HOFF3359_13_GE_C01.indd 50 15/03/19 10:23 AM

1 • The Database Environment and Development Process 51

INSTALLATION AND MANAGEMENT COST AND COMPLEXITY A multi-user database management system is a large and complex suite of software that has a high initial cost, requires a staff of trained personnel to install and operate, and has substantial annual maintenance and support costs. Installing such a system may also require upgrades to the hardware and data communications systems in the organization. Substantial training is normally required on an ongoing basis to keep up with new releases and upgrades. Additional or more sophisticated and costly database soft- ware may be needed to provide security and to ensure proper concurrent updating of shared data.

CONVERSION COSTS The term legacy system is widely used to refer to older applications in an organization that are based on file processing and/or older database technology. The cost of converting these older systems to modern database technology—measured in terms of dollars, time, and organizational commitment—may often seem prohibi- tive to an organization. The use of data warehouses is one strategy for continuing to use older systems while at the same time exploiting modern database technology and techniques (Ritter, 1999).

NEED FOR EXPLICIT BACKUP AND RECOVERY A shared corporate database must be accurate and available at all times. This requires that comprehensive procedures be developed and used for providing backup copies of data and for restoring a database when damage occurs. These considerations have acquired increased urgency in today’s security-conscious environment. A modern database management system normally automates many more of the backup and recovery tasks than a file system. You will learn about procedures for security, backup, and recovery in Chapter 8.

ORGANIZATIONAL CONFLICT A shared database requires a consensus on data defi- nitions and ownership as well as responsibilities for accurate data maintenance. Experience has shown that conflicts on data definitions, data formats and coding, rights to update shared data, and associated issues are frequent and often difficult to resolve. Handling these issues requires organizational commitment to the database approach, organizationally astute database administrators, and a sound evolutionary approach to database development.

If strong top management support of and commitment to the database approach are lacking, end-user development of stand-alone databases is likely to proliferate. These databases do not follow the general database approach that we have described, and they are unlikely to provide the benefits described earlier. In the extreme, they may lead to a pattern of inferior decision making that threatens the well-being or existence of an organization.

INTEGRATED DATA MANAGEMENT FRAMEWORK

The database approach described above is associated with relational database technologies and used primarily as a foundation for the design and implementation of transaction processing systems (operational systems). Data management technologies are also increasingly often used as informational systems, as a foundation for analytics, or the systematic analysis and interpretation of data to improve our understanding of a real-world domain. Transactional systems are still the core of this book with a focus on relational databases and the SQL language. These technologies continue, in practice, to be a fundamental source of data for all areas of data management, and no other technology is as widely used. They form the foundation on which business activities of modern organizations are built because they enable the way in which organizations interact and do business with their stakeholders.

This book does, however, also cover data management technologies intended primarily for enabling and supporting analytics. They can be divided into two major categories: data warehousing and big data. Data warehousing has existed as a concept since late 1980s, and, as you will learn in Chapter 9, both conceptual approaches and implementation technologies for data warehousing are already well developed and

M01B_HOFF3359_13_GE_C01.indd 51 15/03/19 10:23 AM

52 Part I • The Context of Database Management

mature. Indeed, most traditional data warehouses are implemented using the same relational technologies as transactional systems. Big data technologies have emerged as another category of informational systems since the early 2010s. They are charac- terized by their ability to deal with large volumes of data with a variety of data types arriving to the organizational systems with high velocity (the so-called three Vs of big data). A major difference between big data systems compared to both data warehousing and operational, transaction-focused systems is that structures of the latter are typically expected to be carefully designed before data are stored in them (“schema on write”), whereas many of the big data analytics technologies are intended to be used in the “schema on read” mode. In the latter approach, the structure of the data and the rela- tionships between the data elements will be determined later, either right before or at the time of the use of the data.

Figure 1-5 presents a framework that illustrates the structure and the contents of this book based three key categories: Transactional (an operational category), Analytical– Data Warehousing, and Analytical–Big Data (informational categories). As the frame- work demonstrates, the book explores data management in the operational context at a more detailed level than the informational one, dedicating Chapters 2 through 8 to transactional systems and separating the coverage of modeling, design, access, and infrastructure into different chapters. The framework also shows the following:

• This book recognizes the growing importance of informational uses of data man- agement processes and technologies and presents them in the same broader context with operational uses. You will learn about the informational use of data management from two different analytical perspectives: data warehousing ( Chapter 9) and big data (Chapter 10). Both of these chapters deal with questions regarding modeling, design, access, and infrastructure in an integrated way.

• In many areas, such as analytics (Chapter 11), and data management, governance, and quality (Chapter 12), the concerns and key questions are shared between the operational and informational perspectives.

COMPONENTS OF THE DATABASE ENVIRONMENT

Now that you have seen the advantages and risks of using the database approach to managing data, let us examine the major components of a typical database environment and their relationships (see Figure 1-6). You have already been introduced to some (but not all) of these components in previous sections. Following is a brief description of the nine components shown in Figure 1-6:

FIGURE 1-5 Integrated data management framework Operational Informational

Transactional Analytical– Data Warehousing

Analytical– Big Data

Technology Relational Relational Non-relational

Modeling Conceptual data modeling with (E)ER (Chapters 2 and 3)

Data warehousing and data integration (Chapter 9)

Big data technologies,

Design Logical data modeling with the relational model; Normalization (Chapter 4)

Infrastructure Physical design of relational databases; Security; Cloud computing (Chapter 8)

Access SQL (Chapters 5 and 6)

Applications with SQL (Chapter 7)

Data analysis Analytics and its implications (Chapter 11)

Governance and data management

Lifecycle (Chapter 1) Governance, data quality, and master data management (Chapter 12)

including Hadoop & NoSQL (Chapter 10)

M01B_HOFF3359_13_GE_C01.indd 52 15/03/19 10:23 AM

1 • The Database Environment and Development Process 53

1. Data modeling and design tools Data modeling and design tools are automated tools used to design databases and application programs. These tools help with creation of data models and in some cases can also help automatically generate the “code” needed to create the database. You will learn more about the use of automated tools for database design and development throughout the text, par- ticularly in Chapters 4 and 8.

2. Repository A repository is a centralized knowledge base for all data definitions, data relationships, screen and report formats, and other system components. A repository contains an extended set of metadata important for managing databases as well as other components of an information system. We describe the repository in Chapter 9.

3. DBMS A DBMS is a software system that is used to create, maintain, and provide controlled access to user databases. You will learn about many of the technical functions of a DBMS in Chapter 8.

4. Database A database is an organized collection of logically related data, usually designed to meet the information needs of multiple users in an organization. It is important to distinguish between the database and the repository. The reposi- tory contains definitions of data, whereas the database contains occurrences of data. You will explore the activities of database design and implementation in Chapters 4 through 8.

5. Application programs Computer-based application programs are used to create and maintain the database and provide information to users. Key database-related application programming skills are described in Chapters 5 through 10.

6. User interface The user interface includes languages, menus, and other facilities by which users interact with various system components, such as data modeling and design tools, application programs, the DBMS, and the repository. User inter- faces are illustrated throughout this text, with a particular focus in Chapters  5, 6, 8, and 11.

7. Data and database administrators Data administrators are persons who are responsible for the overall management of data resources in an organization. Database administrators are responsible for physical database design and for managing technical issues in the database environment. You will learn about these functions in detail in Chapters 8 and 12.

Data modeling and design tools

Software tools that provide automated support for creating data models.

Repository

A centralized knowledge base of all data definitions, data relationships, screen and report formats, and other system components.

Data and database administrators

System developers

End users

User interface

Application programs

Data modeling and design

tools

DatabaseRepository DBMS

FIGURE 1-6 Components of the database environment

M01B_HOFF3359_13_GE_C01.indd 53 15/03/19 10:23 AM

54 Part I • The Context of Database Management

8. System developers System developers are persons, such as systems analysts and programmers, who design new application programs. The content of all chapters of this book is useful for system developers, but Chapters 2 through 8 are likely to be particularly valuable because of their focus on transactional systems.

9. End users End users are persons throughout the organization who add, delete, and modify data in the database and who request or receive information from it. All user interactions with the database must be routed through the DBMS. This text is targeted primarily to students striving to become data management and systems development professionals, but advanced end users can benefit from many of the skills covered in it (particularly conceptual data modeling in Chapters 2 to 3, SQL in Chapters 5 to 6, and Analytics in Chapter 11).

In summary, the database operational environment shown in Figure 1-6 is an inte- grated system of hardware, software, and people, designed to facilitate the storage, retrieval, and control of the information resource and to improve the productivity of the organization.

THE DATABASE DEVELOPMENT PROCESS

How do organizations start developing a database? In many organizations, database development begins with enterprise data modeling, which establishes the range and general contents of organizational databases. Its purpose is to create an overall 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, describes the scope of data maintained by the organization. In enterprise data modeling, you review current systems, analyze the nature of the business areas to be supported, describe the data needed at a very high level of abstraction, and plan one or more database development projects.

Figure 1-3a showed a segment of an enterprise data model for Pine Valley Furni- ture Company, using a simplified version of the notation you will learn in Chapters 2 and 3. Besides such a graphical depiction of the entity types, a thorough enterprise data model would also include business-oriented descriptions of each entity type and a com- pendium of various statements about how the business operates, called business rules, which govern the validity of data. Relationships between business objects (business functions, units, applications, and so forth) and data are often captured using matrixes and complement the information captured in the enterprise data model. Figure 1-7 shows an example of such a matrix.

Enterprise data modeling

The first step in database development, in which the scope and general contents of organizational databases are specified.

FIGURE 1-7 Example business function-to-data entity matrix

XXXXBusiness Planning

Product Development X X X X

Materials Management X X X X X X

Order Fulfillment X X X X X X X

Order Shipment X X X X X X

Sales Summarization X X X X X

Production Operations X X X X X X X

Finance and Accounting X X X X X

X X

X X X

X 5 data entity is used within business function

C u st

o m

er

P ro

d u ct

R aw

M at

er ia

l

O rd

er

W o

rk C

en te

r

W o

rk O

rd er

In vo

ic e

E q

u ip

m en

t

E m

p lo

ye e

Data Entity Types

Business Functions

M01B_HOFF3359_13_GE_C01.indd 54 15/03/19 10:23 AM

1 • The Database Environment and Development Process 55

Enterprise data modeling as a component of a top-down approach to information systems planning and development represents one source of database projects. Such projects often develop new databases to meet strategic organizational goals, such as improved customer support, better production and inventory management, or more accurate sales forecasting. Many database projects arise, however, in a more bottom-up fashion. In this case, projects are requested by information systems users who need cer- tain information to do their jobs or by other information systems professionals who see a need to improve data management in the organization.

A typical bottom-up database development project usually focuses on the creation of one database. Some database projects concentrate only on defining, designing, and implementing a database as a foundation for subsequent information systems develop- ment. In most cases, however, a database and the associated information processing functions are developed together as part of a comprehensive information systems development project.

Systems Development Life Cycle

As you may know from other information systems courses you’ve taken, a traditional process for conducting an information systems development project is called the systems development life cycle (SDLC). The SDLC is a complete set of steps that a team of information systems professionals, including database designers and program- mers, follow in an organization to specify, develop, maintain, and replace information systems. Textbooks and organizations use many variations on the life cycle and may identify anywhere from 3 to 20 different phases.

The various steps in the SDLC and their associated purpose are depicted in Figure  1-8 (Valacich and George, 2016). The process appears to be circular and is intended to convey the iterative nature of systems development projects. The steps may overlap in time, they may be conducted in parallel, and it is possible to backtrack to pre- vious steps when prior decisions need to be reconsidered. Some believe that the most common path through the development process is to cycle through the steps depicted in Figure 1-8 but at more detailed levels on each pass as the requirements of the system become more concrete.

Figure 1-8 also provides an outline of the database development activities typi- cally included in each phase of the SDLC. Note that there is not always a one-to-one correspondence between SDLC phases and database development steps. For example, conceptual data modeling occurs in both the Planning and the Analysis phase. We will briefly illustrate each of these database development steps for Pine Valley Furniture Company later in this chapter.

PLANNING—ENTERPRISE MODELING The database development process begins with a review of the enterprise modeling components that were developed during the infor- mation systems planning process. During this step, analysts review current databases and information systems, analyze the nature of the business area that is the subject of the development project, and describe, in general terms, the data needed for each information system under consideration for development. They determine what data are already available in existing databases and what new data will need to be added to support the proposed new project. Only selected projects move into the next phase based on the projected value of each project to the organization.

PLANNING—CONCEPTUAL DATA MODELING For an information systems project that is initiated, the overall data requirements of the proposed information system must be analyzed. This is done in two stages. First, during the Planning phase, the analyst develops a diagram similar to Figure 1-3a, as well as other documentation, to out- line the scope of data involved in this particular development project without consid- eration of what databases already exist. Only high-level categories of data (entities) and major relationships are included at this point. This step in the SDLC is critical for improving the chances of a successful development process. The better the definition of the specific needs of the organization, the closer the conceptual model should come

Systems development life cycle (SDLC)

The traditional methodology used to develop, maintain, and replace information systems.

M01B_HOFF3359_13_GE_C01.indd 55 15/03/19 10:23 AM

56 Part I • The Context of Database Management

Enterprise modeling • Analyze current data processing • Analyze the general business functions and their

database needs • Justify need for new data and databases in support of

business

Conceptual data modeling • Identify scope of database requirements for proposed

information system • Analyze overall data requirements for business

function(s) supported by database

Conceptual data modeling, cont’d. • Develop preliminary conceptual data

model, including entities and relationships

• Compare preliminary conceptual data model with enterprise data model

• Develop detailed conceptual data model, including all entities, relationships, attributes, and business rules

• Make conceptual data model consistent with other models of information system

• Populate repository with all conceptual database specifications

Logical database design • Analyze in detail the transactions, forms, displays, and inquiries

(database views) required by the business functions supported by the database

• Integrate database views into conceptual data model • Identify data integrity and security requirements, and populate repository

Physical database design and definition • Define database to DBMS (often generated from repository) • Decide on physical organization of data • Design database processing programs

Database maintenance • Analyze database and

database applications to ensure that evolving information requirements are met

• Tune database for improved performance

• Fix errors in database and database applications and recover database when it is contaminated

Database implementation • Code and test database

processing programs • Complete database

documentation and training materials

• Install database and convert data from prior systems

Planning

Maintenance Analysis

Implementation Design Purpose: To write programs, build databases, test and install the new system, train users, and finalize documentation

Purpose: To elicit and structure all information requirements; to develop all technology and organizational specifications

Purpose: To monitor the operation and usefulness of the system, and to repair and enhance the system

Purpose: To develop a preliminary understanding of a business situation and how information systems might help solve a problem or make an opportunity possible

Purpose: To analyze the business situation thoro- ughly to determine requirements, to structure those requirements, and to select among competing system features

FIGURE 1-8 Database development activities during the systems development life cycle (SDLC)

to meeting the needs of the organization and the less recycling back through the SDLC should be needed.

ANALYSIS—CONCEPTUAL DATA MODELING During the Analysis phase of the SDLC, the analyst produces a detailed data model that identifies all the organizational data that must be managed for this information system. Every data attribute is defined, all categories of data are listed, every business relationship between data entities is represented, and every rule that dictates the integrity of the data is specified. It is also during the Analysis phase that the conceptual data model is checked for consistency with other types of models developed to explain other dimensions of the target informa- tion system, such as processing steps, rules for handling data, and the timing of events. However, even this detailed conceptual data model is preliminary because subsequent SDLC activities may find missing elements or errors when designing specific transac- tions, reports, displays, and inquiries. With experience, the database developer gains mental models of common business functions, such as sales or financial record keeping,

M01B_HOFF3359_13_GE_C01.indd 56 15/03/19 10:23 AM

1 • The Database Environment and Development Process 57

but must always remain alert for the exceptions to common practices followed by an organization. The output of the conceptual modeling phase is a conceptual schema.

DESIGN—LOGICAL DATABASE DESIGN Logical database design approaches database development from two perspectives. First, the conceptual schema must be transformed into a logical schema, which describes the data in terms of the data management technology that will be used to implement the database. For example, if relational technology will be used, the conceptual data model is transformed and represented using elements of the relational model, which include tables, columns, rows, primary keys, foreign keys, and constraints. (You will learn how to conduct this important process in Chapter 4.) This representation is referred to as the logical schema.

Then, as each application in the information system is designed, including the program’s input and output formats, the analyst performs a detailed review of the transactions, reports, displays, and inquiries supported by the database. During this so- called bottom-up analysis, the analyst 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. It may be necessary to refine the conceptual data model as each report, business transaction, and other user view is analyzed. In this case, one must combine, or integrate, the original conceptual data model along with these individual user views into a comprehensive design during logical database design. It is also possible that additional information processing requirements will be identified during logical infor- mation systems design, in which case these new requirements must be integrated into the previously identified logical database design.

The final step in logical database design is to transform the combined and recon- ciled data specifications into basic, or atomic, elements following well-established rules for well-structured data specifications. For most databases today, these rules come from relational database theory and a process called normalization, which you will learn about in detail in Chapter 4. The result is a complete picture of the database without any refer- ence to a particular database management system for managing these data. With a final logical database design in place, the analyst begins to specify the logic of the particular computer programs and queries needed to maintain and report the database contents.

DESIGN—PHYSICAL DATABASE DESIGN AND DEFINITION A physical schema is a set of specifications that describe how data from a logical schema are stored in a com- puter’s secondary memory by a specific database management system. There is one physical schema for each logical schema. Physical database design requires knowledge of the specific DBMS that will be used to implement the database. In physical data- base design and definition, an analyst decides on the organization of physical records, the choice of file organizations, the use of indexes, and so forth. To do this, a database designer needs to outline the programs to process transactions and to generate antici- pated management information and decision support reports. The goal is to design a database that will efficiently and securely handle all data processing against it. Thus, physical database design is done in close coordination with the design of all other aspects of the physical information system: programs, computer hardware, operating systems, and data communications networks.

IMPLEMENTATION—DATABASE IMPLEMENTATION In database implementation, a designer writes, tests, and installs the programs/scripts that access, create, or modify the database. The designer might do this using standard programming languages (e.g., Java, C#, or Visual Basic.NET) or in special database processing languages (e.g., SQL) or use special-purpose nonprocedural languages to produce stylized reports and displays, possibly including graphs. Also, during implementation, the designer will finalize all database documentation, train users, and put procedures into place for the ongoing support of the information system (and database) users. The last step is to load data from existing information sources (files and databases from legacy applications plus new data now needed). Loading is often done by first unloading data from existing files and databases into a neutral format (such as binary or text files) and then loading these data into the new database. Finally, the database and its associated applications

Conceptual schema

A detailed, technology- independent specification of the overall structure of organizational data.

Logical schema

The representation of a database for a particular data management technology.

Physical schema

Specifications for how data from a logical schema are stored in a computer’s secondary memory by a database management system.

M01B_HOFF3359_13_GE_C01.indd 57 15/03/19 10:23 AM

58 Part I • The Context of Database Management

prototyping process. This figure includes annotations to indicate roughly which database development activities occur in each prototyping phase. Typically, you make only a very cursory attempt at conceptual data modeling when the information system problem is identified. During the development of the initial prototype, you simultaneously design the displays and reports the user wants while understanding any new database require- ments and defining a database to be used by the prototype. This is typically a new data- base, which is a copy of portions of existing databases, possibly with new content. If new content is required, it will usually come from external data sources, such as market research data, general economic indicators, or industry standards.

Database implementation and maintenance activities are repeated as new ver- sions of the prototype are produced. Often, security and integrity controls are minimal because the emphasis is on getting working prototype versions ready as quickly as possible. Also, documentation tends to be delayed until the end of the project, and user training occurs from hands-on use. Finally, after an accepted prototype is created, the developer and the user decide whether the final prototype and its database can be put into production as is. If the system, including the database, is too inefficient, the system and database might need to be reprogrammed and reorganized to meet performance expectations. Inefficiencies, however, have to be weighed against violating the core principles behind sound database design.

With the increasing popularity of visual programming tools (such as Visual Basic, Java, or C#) that make it easy to modify the interface between user and system, prototyping is becoming the systems development methodology of choice to develop new applications internally. With prototyping, it is relatively easy to change the content and layout of user reports and displays.

The benefits from iterative approaches to systems development demonstrated by RAD and prototyping approaches have resulted in further efforts to create ever more responsive development approaches. In February 2001, a group of 17 individuals interested in supporting these approaches created “The Manifesto for Agile Software Development.” For them, agile software development practices include valuing (www .agilemanifesto.org) the following:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Emphasis on the importance of people, both software developers and customers, is evident in their phrasing. This is in response to the turbulent environment within which software development occurs as compared to the more staid environment of most engineering development projects from which the earlier software development methodologies came. The importance of the practices established in the SDLC continues to be recognized and accepted by software developers, including the creators of “The Manifesto for Agile Software Development.” However, it is impractical to allow these practices to stifle quick reactions to changes in the environment that change project requirements.

The use of agile or adaptive processes should be considered when a project involves unpredictable and/or changing requirements, responsible and collaborative developers, and involved customers who understand and can contribute to the process (Fowler, 2005). If you are interested in learning more about agile software development, investigate agile methodologies, such as eXtreme Programming, Scrum, the DSDM Consortium, and feature-driven development.

Three-Schema Architecture for Database Development

The explanation earlier in this chapter of the database development process referred to several different but related models of databases developed on a systems develop- ment project. These data models and the primary phase of the SDLC in which they are developed are summarized here:

• Enterprise data model (during the Information Systems Planning phase). • External schema or user view (during the Analysis and Logical Design phases).

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.

Agile software development

An approach to database and software development that emphasizes “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and response to change over following a plan.”

are put into production for data maintenance and retrieval by the actual users. During production, the database should be periodically backed up and recovered in case of contamination or destruction.

MAINTENANCE—DATABASE MAINTENANCE The database evolves during database maintenance. In this step, the designer adds, deletes, or changes characteristics of the structure of a database in order to meet changing business conditions, to correct errors in database design, or to improve the processing speed of database applications. The designer might also need to rebuild a database if it becomes contaminated or destroyed due to a program or computer system malfunction. This is typically the longest step of database development because it lasts throughout the life of the database and its associated applications. Each time the database evolves, view it as an abbreviated database development process in which conceptual data modeling, logical and physical database design, and database implementation occur to deal with proposed changes.

Alternative Information Systems Development Approaches

The systems development life cycle or slight variations on it are often used to guide the development of information systems and databases. The SDLC is a methodical, highly structured approach that includes many checks and balances to ensure that each step produces accurate results and that the new or replacement information system is con- sistent with existing systems with which it must communicate or for which there needs to be consistent data definitions. Whew! That’s a lot of work! Consequently, the SDLC is often criticized for the length of time needed until a working system is produced, which occurs only at the end of the process. Instead, organizations increasingly use rapid application development (RAD) methods, which follow an iterative process of rapidly repeating analysis, design, and implementation steps until they converge on the system the user wants. These RAD methods work best when most of the necessary database structures already exist and hence for systems that primarily retrieve data rather than for those that populate and revise databases.

One of the most popular RAD methods is prototyping, which is 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. Figure 1-9 shows the

Identify problem

Convert to operational

system

Revise and enhance prototype

Problems

Working prototype

Next version

Develop initial

prototype

Initial requirements

If prototype is ine�cient

Conceptual data modeling Analyze requirements Develop preliminary

data model

Database maintenance Tune database for

improved performance Fix errors in database

Logical database design Analyze requirements in detail Integrate database views into

conceptual data model

Physical database design and definition

Define new database contents to DBMS

Decide on physical organization for new data

Design database processing programs

Database maintenance Analyze database to ensure it

meets application needs Fix errors in database

Implement and use prototype

New requirements

Database implementation Code database processing Install new database

contents, usually from existing data sources

FIGURE 1-9 The prototyping methodology and database development process

M01B_HOFF3359_13_GE_C01.indd 58 15/03/19 10:23 AM

1 • The Database Environment and Development Process 59

prototyping process. This figure includes annotations to indicate roughly which database development activities occur in each prototyping phase. Typically, you make only a very cursory attempt at conceptual data modeling when the information system problem is identified. During the development of the initial prototype, you simultaneously design the displays and reports the user wants while understanding any new database require- ments and defining a database to be used by the prototype. This is typically a new data- base, which is a copy of portions of existing databases, possibly with new content. If new content is required, it will usually come from external data sources, such as market research data, general economic indicators, or industry standards.

Database implementation and maintenance activities are repeated as new ver- sions of the prototype are produced. Often, security and integrity controls are minimal because the emphasis is on getting working prototype versions ready as quickly as possible. Also, documentation tends to be delayed until the end of the project, and user training occurs from hands-on use. Finally, after an accepted prototype is created, the developer and the user decide whether the final prototype and its database can be put into production as is. If the system, including the database, is too inefficient, the system and database might need to be reprogrammed and reorganized to meet performance expectations. Inefficiencies, however, have to be weighed against violating the core principles behind sound database design.

With the increasing popularity of visual programming tools (such as Visual Basic, Java, or C#) that make it easy to modify the interface between user and system, prototyping is becoming the systems development methodology of choice to develop new applications internally. With prototyping, it is relatively easy to change the content and layout of user reports and displays.

The benefits from iterative approaches to systems development demonstrated by RAD and prototyping approaches have resulted in further efforts to create ever more responsive development approaches. In February 2001, a group of 17 individuals interested in supporting these approaches created “The Manifesto for Agile Software Development.” For them, agile software development practices include valuing (www .agilemanifesto.org) the following:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Emphasis on the importance of people, both software developers and customers, is evident in their phrasing. This is in response to the turbulent environment within which software development occurs as compared to the more staid environment of most engineering development projects from which the earlier software development methodologies came. The importance of the practices established in the SDLC continues to be recognized and accepted by software developers, including the creators of “The Manifesto for Agile Software Development.” However, it is impractical to allow these practices to stifle quick reactions to changes in the environment that change project requirements.

The use of agile or adaptive processes should be considered when a project involves unpredictable and/or changing requirements, responsible and collaborative developers, and involved customers who understand and can contribute to the process (Fowler, 2005). If you are interested in learning more about agile software development, investigate agile methodologies, such as eXtreme Programming, Scrum, the DSDM Consortium, and feature-driven development.

Three-Schema Architecture for Database Development

The explanation earlier in this chapter of the database development process referred to several different but related models of databases developed on a systems develop- ment project. These data models and the primary phase of the SDLC in which they are developed are summarized here:

• Enterprise data model (during the Information Systems Planning phase). • External schema or user view (during the Analysis and Logical Design phases).

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.

Agile software development

An approach to database and software development that emphasizes “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and response to change over following a plan.”

M01B_HOFF3359_13_GE_C01.indd 59 15/03/19 10:23 AM

60 Part I • The Context of Database Management

• Conceptual schema (during the Analysis phase). • Logical schema (during the Logical Design phase). • Physical schema (during the Physical Design phase).

In 1978, an industry committee commonly known as ANSI/SPARC published an important document that described three-schema architecture—external, concep- tual, and internal schemas—for describing the structure of data. Figure 1-10 shows the relationship between the various schemas developed during the SDLC and the ANSI three-schema architecture. It is important to keep in mind that all these schemas are just different ways of visualizing the structure of the same database by different stakeholders.

The three schemas as defined by ANSI (depicted down the center of Figure 1-10) are as follows:

1. External schema This is the view (or views) of managers and other employees who are the database users. As shown in Figure 1-10, the external schema can be represented as a combination of the enterprise data model (a top-down view) and a collection of detailed (or bottom-up) user views.

2. Conceptual schema This schema combines the different external views into a single, coherent, and comprehensive definition of the enterprise’s data. The conceptual schema represents the view of the data architect or data administrator.

3. Internal schema As shown in Figure 1-10, an internal schema today really con- sists of two separate schemas: a logical schema and a physical schema. The logical schema is the representation of data for a type of data management technology (e.g., relational). The physical schema describes how data are to be represented and stored in secondary storage using a particular DBMS (e.g., Oracle).

Enterprise Data Model

External Schema

Conceptual Schema

Internal Schema

User View 1 (report)

User View 2 (screen display)

User View n (order form)

Database 1 (Order Processing)

Database 2 (Supply Chain)

Database m (Customer Service)

Physical Schema 1

Logical Schemas Physical Schemas

Physical Schema 2

Physical Schema m

FIGURE 1-10 Three-schema architecture

M01B_HOFF3359_13_GE_C01.indd 60 15/03/19 10:23 AM

1 • The Database Environment and Development Process 61

Managing the People Involved in Database Development

Isn’t it always ultimately about people working together? As implied in Figure 1-8, a database is developed as part of a project. A project is a planned undertaking of related activities to reach an objective that has a beginning and an end. A project begins with the first steps of the Project Initiation and Planning phase and ends with the last steps of the Implementation phase. A senior systems or database analyst will be assigned to be project leader. This person is responsible for creating detailed project plans as well as staffing and supervising the project team.

A project is initiated and planned in the Planning phase; executed during Analy- sis, Logical Design, Physical Design, and Implementation phases; and closed down at the end of implementation. During initiation, the project team is formed. A systems or database development team can include one or more of the following:

• Business analysts These individuals work with both management and users to analyze the business situation and develop detailed system and program specifications for projects.

• Systems analysts These individuals may perform business analyst activities but also specify computer systems requirements and typically have a stronger systems development background than business analysts.

• Database analysts and data modelers These individuals concentrate on determining the requirements and design for the database component of the information system.

• Users Users provide assessments of their information needs and monitor that the developed system meets their needs.

• Programmers These individuals design and write computer programs that have commands to maintain and access data in the database embedded in them.

• Database architects These individuals establish standards for data in business units, striving to attain optimum data location, currency, and quality.

• Data administrators These individuals have responsibility for existing and future databases and ensure consistency and integrity across databases, and as experts on database technology, they provide consulting and training to other project team members.

• Project managers Project managers oversee assigned projects, including team composition, analysis, design, implementation, and support of projects.

• Other technical experts Other individuals are needed in areas such as network- ing, operating systems, testing, data warehousing, and documentation.

It is the responsibility of the project leader to select and manage all of these people as an effective team. See Valacich and George (2016) for details on how to manage a systems development project team and Henderson et al. (2005) for a more detailed description of career paths and roles in data management. The emphasis on people rather than roles when agile development processes are adopted means that team mem- bers will be less likely to be constrained to a particular role. They will be expected to contribute and collaborate across these roles, thus using their particular skills, interests, and capabilities more completely.

EVOLUTION OF DATABASE SYSTEMS

Database management systems were first introduced during the 1960s and have continued to evolve during subsequent decades. Figure 1-11a sketches this evolution by highlighting the database technology (or technologies) that was dominant during each decade. In most cases, the period of introduction was quite long, and the technology was first introduced during the decade preceding the one shown in the figure. For example, the relational model was first defined by E. F. Codd, an IBM research fellow, in a paper published in 1970 (Codd, 1970). However, the relational model did not realize widespread commercial success until the 1980s. For example, the challenge of the 1970s when programmers needed to write complex programs to access data was addressed by the introduction of SQL in the 1980s.

Project

A planned undertaking of related activities to reach an objective that has a beginning and an end.

M01B_HOFF3359_13_GE_C01.indd 61 15/03/19 10:23 AM

62 Part I • The Context of Database Management

1960 1970 1980 1990 2010

Flat files Hierarchical Network Relational Object-oriented Object-relational Analytics – Data Warehousing Analytics – Big data

Under active development Legacy systems still used

2000

Hierarchical database model Network database model

Relational database model Object-oriented database model

Object Class 1

Methods

Attributes

Methods

Attributes

Object Class 3

Object Class 2

Attributes

Methods

Multidimensional database model — star-schema view

Key characteristics of big data – no predefined data model

Dimension 4

Dimension 5

Dimension 6

Dimensions

Fact Table

Facts

Dimension 1

Dimension 2

Dimension 3

RELATION 1 (PRIMARY KEY, ATTRIBUTES...)

RELATION 2 (PRIMARY KEY, FOREIGN KEY, ATTRIBUTES...)

Veracity Variety

Velocity

Volume

Value Big

Data

FIGURE 1-11 The range of database technologies: past and present

(a) Evolution of database technologies

(b) Database architectures

M01B_HOFF3359_13_GE_C01.indd 62 15/03/19 10:23 AM

1 • The Database Environment and Development Process 63

Figure 1-11b shows a visual depiction of the organizing principle underlying each of the major database technologies. For example, in the hierarchical model, files are organized in a top-down structure that resembles a tree or genealogy chart, whereas in the network model, each file can be associated with an arbitrary number of other files. The relational model (the primary focus of this book) organizes data in the form of tables and relationships among them. The object-oriented model (discussed in Chapter 14 on the book’s Web site) is based on object classes and relationships among them. As shown in Figure 1-11b, an object class encapsulates attributes and methods. Object-relational databases are a hybrid between object-oriented and relational databases. Multidimen- sional databases, which form the basis for data warehouses, allow us to view data in the form of cubes or a star schema; you will learn more about this in Chapter 9. The final element of the diagram illustrates the main characteristics of the big data approach to data management (to be covered in Chapter 10), intentionally leaving a specific model- ing approach (there is no single data model for big data).

Database management systems were developed to overcome the limitations of file processing systems, described in a previous section. To summarize, some of the following four objectives generally drove the development and evolution of database technology:

1. The need to provide greater independence between programs and data, thereby reducing maintenance costs.

2. The desire to manage increasingly complex data types and structures. 3. The desire to provide easier and faster access to data for users who have neither a

background in programming languages nor a detailed understanding of how data are stored in databases.

4. The need to provide ever more powerful platforms for decision support applications.

1960s

File processing systems were still dominant during the 1960s. However, the first database management systems were introduced during this decade and were used pri- marily for large and complex ventures, such as the Apollo moon-landing project. We can regard this as an experimental “proof-of-concept” period in which the feasibility of managing vast amounts of data with a DBMS was demonstrated. Also, the first efforts at standardization were taken with the formation of the Data Base Task Group in the late 1960s.

1970s

During this decade, the use of database management systems became a commercial reality. The hierarchical and network database management systems were developed, largely to cope with increasingly complex data structures, such as manufacturing bills of materials that were extremely difficult to manage with conventional file processing methods. The hierarchical and network models are generally regarded as first- generation DBMS. Both approaches were widely used, and in fact many of these systems continue to be used today. However, they suffered from the same key disadvantages as file processing systems: limited data independence and lengthy development times for application development.

1980s

To overcome these limitations, E. F. Codd and others developed the relational data model during the 1970s. This model, considered second-generation DBMS, received widespread commercial acceptance and diffused throughout the business world dur- ing the 1980s. With the relational model, all data are represented in the form of tables. Typically, SQL is used for data retrieval. Thus, the relational model provides ease of access for nonprogrammers, overcoming one of the major objections to first-generation systems. The relational model has also proven well-suited to client/server computing, parallel processing, and graphical user interfaces (Gray, 1996).

M01B_HOFF3359_13_GE_C01.indd 63 15/03/19 10:23 AM

64 Part I • The Context of Database Management

1990s

The 1990s ushered in a new era of computing, first with client/server computing and then with data warehousing and Internet applications becoming increasingly impor- tant. Whereas the data managed by a DBMS during the 1980s were largely structured (such as accounting data), multimedia data (including graphics, sound, images, and video) became increasingly common during the 1990s. To cope with these increasingly complex data, object-oriented databases (considered third generation) were introduced during the late 1980s (Grimes, 1998); however, these never reached the popularity they were predicted to gain. Instead, new types of data management technologies were developed in 2000s and 2010s.

2000 and Beyond

Currently, relational databases are still the most widely used database technology. Because organizations must manage a vast amount of structured and unstructured data and because both the amounts and the variety of data are increasing rapidly, the need for new technologies has rapidly become clear. Since early 2000s, various nonre- lational technologies have become increasingly popular, as you already learned earlier in this chapter in the context of the framework presented in Figure 1-5. One of the ele- ments of this trend is the emergence of NoSQL (Not Only SQL) databases. NoSQL is an umbrella term that refers to a set of database technologies that is specifically designed to address large (structured and unstructured) data that are potentially stored across various locations. Popular examples of NoSQL databases are MongoDB and Apache Cassandra (http://cassandra.apache.org). In addition, Hadoop is an example of a nonrelational technology that is designed to handle the processing of large amounts of data. This search for nonrelational database technologies is fueled by the needs of social networking applications, such as blogs, wikis, and social networking sites (Facebook, Twitter, LinkedIn, and so forth); the ease of generating unstructured data, such as pictures and images, from devices, such as smartphones, tablets, and so forth; and the data needs and opportunities of the Internet of Things. Developing effective database practices to deal with these diverse types of data continues to be of prime importance. As larger computer memory chips become less expensive, new database technologies to manage in-memory databases are emerging. This trend opens up new possibilities for even faster database processing. You will find more about some of these new trends in Chapter 11.

Recent regulations such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act, and the Basel Convention have highlighted the importance of good data management practices, and the ability to reconstruct historical positions has gained prominence. This has led to developments in computer forensics with increased emphasis and expectations around discovery of electronic evidence. The importance of good database administration capabilities also continues to rise because effective disas- ter recovery and adequate security are mandated by these regulations.

An emerging trend that is making it more convenient to use database technolo- gies (and to tackle some of the regulatory challenges identified here) is that of cloud computing. One popular technology available in the cloud is databases. Databases, relational and nonrelational, can now be created, deployed, and managed through the use of technologies owned and managed by a service provider. You will examine issues surrounding cloud databases in Chapters 7 and 8.

THE RANGE OF DATABASE APPLICATIONS

What can databases help us do? Recall that Figure 1-6 showed that there are several methods for people to interact with the data in the database. First, users can interact directly with the database using the user interface provided by the DBMS. In this manner, users can issue commands (called queries) against the database and examine the results or potentially even store them inside a Microsoft Excel spreadsheet or Word document. This method of interaction with the database is referred to as ad hoc query- ing and requires a level of understanding the query language on the part of the user.

M01B_HOFF3359_13_GE_C01.indd 64 15/03/19 10:23 AM

1 • The Database Environment and Development Process 65

Because most business users do not possess this level of knowledge, the second and more common mechanism for accessing the database is using application pro- grams. An application program consists of two key components. A graphical user interface accepts the users’ request (e.g., to input, delete, or modify data) and/or pro- vides a mechanism for displaying the data retrieved from the database. The business logic contains the programming logic necessary to act on the users’ commands. The machine that runs the user interface (and sometimes the business logic) is referred to as the client. The machine that runs the DBMS and contains the database is referred to as the database server.

It is important to understand that the applications and the database need not reside on the same computer (and, in most cases, they don’t). In order to better understand the range of database applications, we divide them into three categories based on the loca- tion of the client (application) and the database software itself: personal, multi-tier, and enterprise databases. We introduce each category with a typical example, followed by some issues that generally arise within that category of use.

Personal Databases

Personal databases are designed to support one user. Personal databases have long resided on personal computers, including laptops, and now increasingly reside on smartphones, tablets, phablets, and so forth. The purpose of these databases is to provide the user with the ability to manage (store, update, delete, and retrieve) small amounts of data in an efficient manner. Simple database applications that store cus- tomer information and the details of contacts with each customer can be used from a personal computer and easily transferred from one device to the other for backup and work purposes. For example, consider a company that has a number of salespersons who call on actual or prospective customers. A database of customers and a pricing application can enable the salesperson to determine the best combination of quantity and type of items for the customer to order.

Personal databases are widely used because they can often improve personal productivity. However, they entail a risk: The data cannot easily be shared with other users. For example, suppose the sales manager wants a consolidated view of customer contacts. This cannot be quickly or easily provided from an individual salesperson’s databases. This illustrates a common problem: If data are of interest to one person, they probably are or will soon become of interest to others as well. For this reason, personal databases should be limited to those rather special situations (e.g., in a very small orga- nization) where the need to share the data among users of the personal database is unlikely to arise.

Departmental Multi-Tiered Client/Server Databases

As noted earlier, the utility of a personal (single-user) database is quite limited. Often, what starts off as a single-user database evolves into something that needs to be shared among several users.

To overcome these limitations, most modern applications that need to support a large number of users are built using the concept of multi-tiered architecture. In most organizations, these applications are intended to support a department (such as mar- keting or accounting) or a division (such as a line of business), which is generally larger than a work group (typically between 25 and 100 persons).

An example of a company that has several multi-tiered applications is shown in Figure 1-12. In a multi-tiered architecture, the user interface is accessible on the individ- ual users’ computers. This user interface may be either Web browser based or written using programming languages such as Visual Basic.NET, Visual C#, or Java. The appli- cation layer/Web server layer contains the business logic required to accomplish the business transactions requested by the users. This layer in turn talks to the database server. The most significant implication for database development from the use of multi-tiered client/server architectures is the ease of separating the development of the database and the modules that maintain the data from the information systems mod- ules that focus on business logic and/or presentation logic. In addition, this architecture

M01B_HOFF3359_13_GE_C01.indd 65 15/03/19 10:23 AM

66 Part I • The Context of Database Management

allows us to improve performance and maintainability of the application and database. We will consider both two and multi-tiered client/server architectures in more detail in Chapter 7.

Enterprise Applications

An enterprise (that’s small “e,” not capital “E,” as in Starship) application/database is one whose scope is the entire organization or enterprise (or, at least, many differ- ent departments). Such databases are intended to support organization-wide opera- tions and decision making in organizations for which departmental solutions are not sufficient. Note that an organization may have several enterprise databases, so such a database is not inclusive of all organizational data. A single operational enterprise database is impractical for many medium-size to large organizations due to difficul- ties in performance for very large databases, diverse needs of different users, and the complexity of achieving a single definition of data (metadata) for all database users. An enterprise database does, however, support information needs of many departments and divisions. It is possible that enterprise databases are architected using a multi- tiered approach described above.

The evolution of enterprise databases has resulted in three major developments:

1. Large-scale enterprise systems, such as enterprise resource planning and customer relationship management.

2. Data warehousing implementations providing a centralized perspective on enter- prise data.

3. Most recently data lakes, which provide a less structured and less costly way to collect large amounts of heterogeneous data without a clear advance knowledge regarding their use.

ENTERPRISE SYSTEMS These make up the backbone for virtually every modern organization because they form the foundation for the processes that control and execute basic business tasks. They are the systems that keep an organization running, whether

Client tier

Application/Web tier

Enterprise tier

Transaction databases containing all organizational data or summaries of data on department servers

Enterprise server with DBMS

A/P, A/R, order processing, inventory control, and so forth; access and connectivity to DBMS. Dynamic Web pages; management of session

Database of vendors, purchase orders, vendor invoices

Accounts payable processing Cash flow analyst

Database of customer receipts and our payments to vendors

Browser Browser Browser

Customer service representative

No local database

Application/Web server

FIGURE 1-12 Multi-tiered client/server database architecture

M01B_HOFF3359_13_GE_C01.indd 66 15/03/19 10:23 AM

1 • The Database Environment and Development Process 67

it is a neighborhood grocery store with a few employees or a multinational corporation with dozens of divisions around the world and tens of thousands of employees. The focus of these applications is on capturing the data surrounding the “transactions,” that is, the hundreds or millions (depending on the size of the organization and the nature of the business) of events that take place in an organization every day and define how a business is conducted. For example, when you registered for your database course, you engaged in a transaction that captured data about your registration. Similarly, when you go to a store to buy a candy bar, a transaction takes place between you and the store, and data are captured about your purchase. When Wal-Mart pays its hundreds of thousands of hourly employees, data regarding these transactions are captured in Wal-Mart’s systems.

It is very typical these days that organizations use packaged systems offered by outside vendors for their transaction processing needs. Examples of these types of systems include enterprise resource planning (ERP), customer relationship manage- ment, supply chain management, human resource management, and payroll. All these systems are heavily dependent on databases for storing the data.

DATA WAREHOUSES Whereas ERP systems work with the current operational data of the enterprise, data warehouses collect content from the various operational databases, including personal, work group, department, and ERP databases. Data warehouses provide users with the opportunity to work with historical data to identify patterns and trends and answers to strategic business questions. Figure 1-13 presents an example of what an output from a data warehouse might look like. You will learn about data ware- houses at a detailed level in Chapter 9.

Enterprise resource planning (ERP)

A business management system that integrates all functions of the enterprise, such as manufacturing, sales, finance, marketing, inventory, accounting, and human resources. ERP systems are software applications that provide the data necessary for the enterprise to examine and manage its activities.

Data warehouse

An integrated decision support database whose content is derived from the various operational databases.

FIGURE 1-13 An example of an executive dashboard

(http://public.tableausoftware.com/profile/mirandali#!/vizhome/Executive-Dashboard_7/ExecutiveDashboard) Courtesy Tableau Software

M01B_HOFF3359_13_GE_C01.indd 67 15/03/19 10:23 AM

68 Part I • The Context of Database Management

DATA LAKE This is a relatively new enterprise-level concept introduced in the big data context. In the same way as a data warehouse, it is an integrated repository of data from a variety of sources, but data lakes have several characteristics that differ- entiate them from traditional data warehouses. First, they typically are not based on a predefined data model or schema (as we discussed above, they are often build fol- lowing the “schema on read” principle). As you will find out in Chapter 10, organiza- tions using data lakes often collect “everything,” that is, store data from a rich variety of sources without knowing in advance when and for what purpose the stored data will be needed. Unless confidentiality requirements prevent it, data lakes are intended to be used for a variety of purposes and by multiple users. Because of the lack of the predefined structure, data lakes are particularly good for identifying new and creative connections between data items. Data lakes are by definition designed to be highly scal- able, and they often are built on a technical foundation that uses low-cost commodity hardware (such as Hadoop).

Finally, one change that has dramatically affected the database environment is the ubiquity of the Internet and the subsequent development of applications that are used by the masses. Acceptance of the Internet by businesses has resulted in impor- tant changes in long-established business models. Even extremely successful compa- nies have been shaken by competition from new businesses that have employed the Internet to provide improved customer information and service, to eliminate tradi- tional marketing and distribution channels, and to implement employee relationship management. For example, customers configure and order their personal computers directly from the computer manufacturers. Bids are accepted for airline tickets and col- lectibles within seconds of submission, sometimes resulting in substantial savings for the end consumer. Information about open positions and company activities is readily available within many companies. Each of these Web-based applications use databases extensively.

In the previous examples, the Internet is used to facilitate interaction between the business and the customer (B2C) because the customers are necessarily external to the business. However, for other types of applications, the customers of the businesses are other businesses. Those interactions are commonly referred to as B2B relationships and are enabled by extranets. An extranet uses Internet technology, but access to the extranet is not universal, as is the case with an Internet application. Rather, access is restricted to business suppliers and customers with whom an agreement has been reached about legitimate access and use of one another ’s data and information. Finally, an intranet is used by employees of the firm to access applications and databases within the company.

Allowing such access to a business’s database raises data security and integrity issues that are new to the management of information systems, whereby data have traditionally been closely guarded and secured within each company. These issues become even more complex as companies take advantage of the cloud. Now data are stored on servers that are not within the control of the company that is generating the data. You will learn about database security and cloud-based databases in more detail in Chapters 7 and 8.

Table 1-5 presents a brief summary of the types of databases outlined in this section.

Data lake

A large integrated repository for internal and external data that does not follow a predefined schema.

TABLE 1-5 Summary of Database Applications

Type of Database/Application Typical Number of Users Typical Size of Database

Personal 1 Megabytes

Multi-tiered client/server 2–1,000 Gigabytes

Enterprise resource planning >100 Gigabytes–terabytes

Data warehousing >100 Terabytes–petabytes

Data lake >100 Terabytes–petabytes

M01B_HOFF3359_13_GE_C01.indd 68 15/03/19 10:23 AM

1 • The Database Environment and Development Process 69

DEVELOPING A DATABASE APPLICATION FOR PINE VALLEY FURNITURE COMPANY

Pine Valley Furniture Company was introduced earlier in this chapter. By the late 1990s, competition in furniture manufacturing had intensified, and competitors seemed to respond more rapidly than Pine Valley Furniture to new business oppor- tunities. While there were many reasons for this trend, managers believed that the computer information systems they had been using (based on traditional file process- ing) had become outdated. After attending an executive development session led by Heikki Topi and Jeff Hoffer (we wish!), the company started a development effort that eventually led to adopting a database approach for the company. Data previously stored in separate files have been integrated into a single database structure. Also, the metadata that describe these data reside in the same structure. The DBMS provides the interface between the various database applications for organizational users and the database (or databases). The DBMS allows users to share the data and to query, access, and update the stored data.

To facilitate the sharing of data and information, Pine Valley Furniture Company uses a local area network that links employee workstations in the various departments to a database server, as shown in Figure 1-14. During the early 2000s, the company mounted a two-phase effort to introduce Internet technology. First, to improve intra- company communication and decision making, an intranet was installed that allows employees fast Web-based access to company information, including phone directories, furniture design specifications, e-mail, and so forth. In addition, Pine Valley Furniture Company also added a Web interface to some of its business applications, such as order entry, so that employees could conduct more internal business activities that require

Database

Accounting

Database Server

Sales

Customer

Internet

Purchasing

Web/Application Server

Web to Database Middleware

FIGURE 1-14 Computer System for Pine Valley Furniture Company

M01B_HOFF3359_13_GE_C01.indd 69 15/03/19 10:23 AM

70 Part I • The Context of Database Management

access to data in the database server through its intranet. However, most applications that use the database server still do not have a Web interface and require that the appli- cation itself be stored on employees’ workstations.

Database Evolution at Pine Valley Furniture Company

A trait of a good database is that it does and can evolve! Helen Jarvis, product manager for home office furniture at Pine Valley Furniture Company, knows that competition has become fierce in this growing product line. Thus, it is increasingly important to Pine Valley Furniture that Helen be able to analyze sales of her products more thoroughly. Often these analyses are ad hoc, driven by rapidly changing and unanticipated business conditions, comments from furniture store managers, trade industry gossip, or personal experience. Helen has requested that she be given direct access to sales data with an easy-to-use inter- face so that she can search for answers to the various marketing questions she will generate.

Chris Martin is a systems analyst in Pine Valley Furniture’s information systems development area. Chris has worked at Pine Valley Furniture for five years and has experience with information systems from several business areas within Pine Valley. With this experience, his information systems education at Western Florida University, and the extensive training Pine Valley has given him, he has become one of Pine Val- ley’s best systems developers. Chris is skilled in data modeling and is familiar with several relational database management systems used within the firm. Because of his experience, expertise, and availability, the head of information systems has assigned Chris to work with Helen on her request for a marketing support system.

Because Pine Valley Furniture has been careful in the development of its systems, especially since adopting the database approach, the company already has databases that support its operational business functions. Thus, it is likely that Chris will be able to extract the data Helen needs from existing databases. Pine Valley’s information sys- tems architecture calls for systems such as the one Helen is requesting to be built as stand-alone databases so that the unstructured and unpredictable use of data will not interfere with the access to the operational databases needed to support efficient trans- action processing systems.

Further, because Helen’s needs are for data analysis, not creation and mainte- nance, and are personal, not institutional, Chris decides to follow a combination of pro- totyping and life cycle approaches in developing the system Helen has requested. This means that Chris will follow all the life cycle steps but focus his energy on the steps that are integral to prototyping. Thus, he will quickly address project planning and then use an iterative cycle of analysis, design, and implementation to work closely with Helen to develop a working prototype of the system she needs. Because the system will be per- sonal and likely will require a database with limited scope, Chris hopes the prototype will end up being the actual system Helen will use. Chris has chosen to develop the sys- tem using Microsoft Access, Pine Valley’s preferred technology for personal databases.

Project Planning

Chris begins the project by interviewing Helen. Chris asks Helen about her business area, taking notes about business area objectives, business functions, data entity types, and other business objects with which she deals. At this point, Chris listens more than he talks so that he can concentrate on understanding Helen’s business area; he interjects questions and makes sure that Helen does not try to jump ahead to talk about what she thinks she needs with regard to computer screens and reports from the information sys- tem. Chris asks general questions, using business and marketing terminology as much as possible. For example, Chris asks Helen what issues she faces managing the home office products; what people, places, and things are of interest to her in her job; how far back in time she needs data to go to do her analyses; and what events occur in the busi- ness that are of interest to her. Chris pays particular attention to Helen’s objectives as well as the data entities that she is interested in.

Chris does two quick analyses before talking with Helen again. First, he identifies all of the databases that contain data associated with the data entities Helen mentioned.

M01B_HOFF3359_13_GE_C01.indd 70 15/03/19 10:23 AM

1 • The Database Environment and Development Process 71

From these databases, Chris makes a list of all of the data attributes from these data entities that he thinks might be of interest to Helen in her analyses of the home office furniture market. Chris’s previous involvement in projects that developed Pine Valley’s standard sales tracking and forecasting system and cost accounting system helps him speculate on the kinds of data Helen might want. For example, the objective to exceed sales goals for each product finish category of office furniture suggests that Helen wants product annual sales goals in her system; also, the objective of achieving at least an eight percent annual sales growth means that the prior year’s orders for each product need to be included. He also concludes that Helen’s database must include all products, not just those in the office furniture line, because she wants to compare her line to others. However, he is able to eliminate many of the data attributes kept on each data entity. For example, Helen does not appear to need various customer data, such as address, phone number, contact person, store size, and salesperson. Chris does, though, include a few additional attributes, customer type and zip code, which he believes might be important in a sales forecasting system.

Second, from this list, Chris draws a conceptual data model (Figure 1-15) that rep- resents the data entities with the associated data attributes as well as the major relation- ships among these data entities. The data model is represented using a notation called the entity-relationship model. You will learn more about this notation in Chapters 2 and 3. The data attributes of each entity Chris thinks Helen wants for the system are listed in Table 1-6. Chris lists in Table 1-6 only basic data attributes from existing data- bases because Helen will likely want to combine these data in various ways for the analyses she will want to do.

Analyzing Database Requirements

Prior to their next meeting, Chris sends Helen a rough project schedule outlining the steps he plans to follow and the estimated length of time each step will take. Because prototyping is a user-driven process in which the user says when to stop iterating on the new prototype versions, Chris can provide only rough estimates of the duration of certain project steps.

Chris does more of the talking at this second meeting, but he pays close attention to Helen’s reactions to his initial ideas for the database application. He methodically walks through each data entity in Figure 1-15, explaining what it means and what busi- ness policies and procedures are represented by each line between entities.

CUSTOMER

ORDER

INVOICE PAYMENT

PRODUCT LINE

PRODUCT

Places

Contains Has

Includes

Is Paid On

Is Billed On

ORDER LINE

FIGURE 1-15 Preliminary data model for Home Office product line marketing support system

M01B_HOFF3359_13_GE_C01.indd 71 15/03/19 10:23 AM

72 Part I • The Context of Database Management

A few of the rules he summarizes are listed here:

1. Each CUSTOMER Places any number of ORDERs. Conversely, each ORDER Is Placed By exactly one CUSTOMER.

2. Each ORDER Contains any number of ORDER LINEs. Conversely, each ORDER LINE Is Contained In exactly one ORDER.

3. Each PRODUCT Has any number of ORDER LINEs. Conversely, each ORDER LINE Is For exactly one PRODUCT.

4. Each ORDER Is Billed On one INVOICE and each INVOICE Is a Bill for exactly one ORDER.

Places, Contains, and Has are called one-to-many relationships because, for exam- ple, one customer places potentially many orders and one order is placed by exactly one customer.

In addition to the relationships, Chris also presents Helen with some detail on the data attributes captured in Table 1-6. For example, Order Number uniquely identifies each order. Other data about an order that Chris thinks Helen might want to know include the date when the order was placed and the date when the order was filled. (This would be the latest shipment date for the products on the order.) Chris also explains that the Payment Date attribute represents the most recent date when the customer made any payments, in full or partial, for the order.

TABLE 1-6 Data Attributes for Entities in the Preliminary Data Model (Pine Valley Furniture Company)

Entity Type Attribute

Customer Customer Identifier

Customer Name

Customer Type

Customer Zip Code

Product Product Identifier

Product Description

Product Finish

Product Price

Product Cost

Product Annual Sales Goal

Product Line Name

Product Line Product Line Name

Product Line Annual Sales Goal

Order Order Number

Order Placement Date

Order Fulfillment Date

Customer Identifier

Ordered Product Order Number

Product Identifier

Order Quantity

Invoice Invoice Number

Order Number

Invoice Date

Payment Invoice Number

Payment Date

Payment Amount

M01B_HOFF3359_13_GE_C01.indd 72 15/03/19 10:23 AM

1 • The Database Environment and Development Process 73

Maybe because Chris was so well prepared or so enthusiastic, Helen is excited about the possibilities, and this excitement leads her to tell Chris about some additional data she wants (the number of years a customer has purchased products from Pine Valley Furniture Company and the number of shipments necessary to fill each order). Helen also notes that Chris has only one year of sales goals indicated for a product line. She reminds him that she wants these data for both the past and current years. As she reacts to the data model, Chris asks her how she intends to use the data she wants. Chris does not try to be thorough at this point because he knows that Helen has not worked with an information set like the one being developed; thus, she may not yet be positive about what data she wants or what she wants to do with those data. Rather, Chris’s objective is to understand a few ways in which Helen intends to use the data so that he can develop an initial prototype, including the database and several computer displays or reports. The final list of attributes that Helen agrees she needs appears in Table 1-7.

TABLE 1-7 Data Attributes for Entities in Final Data Model (Pine Valley Furniture Company)

Entity Type Attribute

Customer Customer Identifier

Customer Name

Customer Type

Customer Zip Code

Customer Years

Product Product Identifier

Product Description

Product Finish

Product Price

Product Cost

Product Prior Year Sales Goal

Product Current Year Sales Goal

Product Line Name

Product Line Product Line Name

Product Line Prior Year Sales Goal

Product Line Current Year Sales Goal

Order Order Number

Order Placement Date

Order Fulfillment Date

Order Number of Shipments

Customer Identifier

Ordered Product Order Number

Product Identifier

Order Quantity

Invoice Invoice Number

Order Number

Invoice Date

Payment Invoice Number

Payment Date

Payment Amount

*Changes from preliminary list of attributes appear in italics.

M01B_HOFF3359_13_GE_C01.indd 73 15/03/19 10:23 AM

74 Part I • The Context of Database Management

Designing the Database

Because Chris is following a prototyping methodology and the first two sessions with Helen quickly identified the data Helen might need, Chris is now ready to build a pro- totype. His first step is to create a project data model like the one shown in Figure 1-16. Notice the following characteristics of the project data model:

1. It is a model of the organization that provides valuable information about how the organization functions as well as important constraints.

2. The project data model focuses on entities, relationships, and business rules. It also includes attribute labels for each piece of data that will be stored in each entity.

Second, Chris translates the data model into a set of tables for which the col- umns are data attributes and the rows are different sets of values for those attributes. Tables are the basic building blocks of a relational database (you will learn about this in Chapter 4), which is the database style for Microsoft Access. Figure 1-17 shows four tables with sample data: Customer, Product, Order, and OrderLine. Notice that these tables represent the four entities shown in the project data model (Figure 1-16). Each column of a table represents an attribute (or characteristic) of an entity. For example, the attributes shown for Customer are CustomerID and CustomerName. Each row of a table represents an instance (or occurrence) of the entity. The design of the database also required Chris to specify the format, or properties, for each attribute (MS Access calls attributes fields). These design decisions were easy in this case because most of the attributes were already specified in the corporate data dictionary.

The tables shown in Figure 1-17 were created using SQL (you will learn about this in Chapters 5 and 6). Figures 1-18 and 1-19 show the SQL statements that Chris would have likely used to create the structure of the ProductLine and Product tables. It is cus- tomary to add the suffix _T to a table name. Also note that because Access does not allow for spaces between names, the individual words in the attributes from the data model have now been concatenated. Hence, Product Description in the data model has become ProductDescription in the table. Chris did this translation so that each table had

Places

Includes

Is billed on

HasContains

Is paid on

CUSTOMER Customer ID Customer Name Customer Type Customer Zip Code Customer Years

ORDER Order Number Order Placement Date Order Fulfillment Date Order Number of Shipments

INVOICE Invoice Number Order Number Invoice Date

PAYMENT Invoice Number Payment Date Payment Amount

PRODUCT Product ID Product Description Product Finish Product Standard Price Product Cost PR Prior Years Sales Goal PR Current Year Sales Goal

ORDER LINE Order Number Product ID Order Quantity

PRODUCT LINE Product Line Name PL Prior Years Sales Goal PL Current Years Sales Goal

FIGURE 1-16 Project data model for Home Office product line marketing support system

M01B_HOFF3359_13_GE_C01.indd 74 15/03/19 10:23 AM

1 • The Database Environment and Development Process 75

CREATE TABLE ProductLine_T

(ProductLineID VARCHAR (40) NOT NULL PRIMARY KEY,

PlPriorYearGoal DECIMAL,

PlCurrentYearGoal DECIMAL);

FIGURE 1-17 Four relations (Pine Valley Furniture Company)

FIGURE 1-18 SQL definition of ProductLine_T table

CREATE TABLE Product_T

(ProductID NUMBER(11,0) NOT NULL PRIMARY KEY

ProductDescription VARCHAR (50),

ProductFinish VARCHAR (20),

ProductStandardPrice DECIMAL(6,2),

ProductCost DECIMAL,

ProductPriorYearGoal DECIMAL,

ProductCurrentYearGoal DECIMAL,

ProductLineID VARCHAR (40),

FOREIGN KEY (ProductLineID) REFERENCES ProductLine_T (ProductLineID));

FIGURE 1-19 SQL definition of Product_T table

(a) Order and Order Line Tables

(b) Customer table

(c) Product table

M01B_HOFF3359_13_GE_C01.indd 75 15/03/19 10:23 AM

76 Part I • The Context of Database Management

an attribute, called the table’s “primary key,” which will be distinct for each row in the table. The other major properties of each table are that there is only one value for each attribute in each row; if you know the value of the identifier, there can be only one value for each of the other attributes. For example, for any product line, there can be only one value for the current year’s sales goal.

A final key characteristic of the relational model is that it represents relation- ships between entities by values stored in the columns of the corresponding tables. For example, notice that CustomerID is an attribute of both the Customer table and the Order table. As a result, you can easily link an order to its associated customer. For example, you can determine that OrderID 1003 is associated with CustomerID 1. Can you determine which ProductIDs are associated with OrderID 1004? In Chapters 5 and 6, you will also learn how to retrieve data from these tables by using SQL, which exploits these linkages. The other major decision Chris has to make about database design is how to physically organize the database to respond as fast as possible to the queries Helen will write. Because the database will be used for decision support, neither Chris nor Helen can anticipate all of the queries that will arise; thus, Chris must make the physical design choices from experience rather than precise knowl- edge of the way the database will be used. The key physical database design decision that SQL allows a database designer to make is on which attributes to create indexes. All primary key attributes (such as OrderNumber for the Order_T table)—those with unique values across the rows of the table—are indexed. In addition to this, Chris uses a general rule of thumb: Create an index for any attribute that has more than 10 differ- ent values and that Helen might use to segment the database. For example, Helen indi- cated that one of the ways she wants to use the database is to look at sales by product finish. Thus, it might make sense to create an index on the Product_T table using the Product Finish attribute.

However, Pine Valley uses only six product finishes, or types of wood, so this is not a useful index candidate. On the other hand, OrderPlacementDate (called a second- ary key because there may be more than one row in the Order_T table with the same value of this attribute), which Helen also wants to use to analyze sales in different time periods, is a good index candidate.

Using the Database

Helen will use the database Chris has built mainly for ad hoc questions, so Chris will train her so that she can access the database and build queries to answer her ad hoc questions. Helen has indicated a few standard questions she expects to ask periodically. Chris will develop several types of prewritten routines (forms, reports, and queries) that can make it easier for Helen to answer these standard questions (so she does not have to program these questions from scratch).

During the prototyping development process, Chris may develop many exam- ples of each of these routines as Helen communicates more clearly what she wants the system to be able to do. At this early stage of development, however, Chris wants to develop one routine to create the first prototype. One of the standard sets of information Helen says she wants is a list of each of the products in the Home Office product line showing each product’s total sales to date compared with its current-year sales goal. Helen may want the results of this query to be displayed in a more stylized fashion—an opportunity to use a report—but for now Chris will present this feature to Helen only as a query.

The query to produce this list of products appears in Figure 1-20, with sample output in Figure 1-21. The query in Figure 1-20 uses SQL. You can see three of the six standard SQL clauses in this query: SELECT, FROM, and WHERE. SELECT indicates which attributes will be shown in the result. One calculation is also included and given the label “Sales to Date.” FROM indicates which tables must be accessed to retrieve data. WHERE defines the links between the tables and indicates that results from only the Home Office product line are to be included. Only limited data are included for this example, so the Total Sales results in Figure 1-21 are fairly small, but the format is the result of the query in Figure 1-20.

M01B_HOFF3359_13_GE_C01.indd 76 15/03/19 10:23 AM

1 • The Database Environment and Development Process 77

SELECT Product.ProductID, Product.ProductDescription, Product.PRCurrentYearSalesGoal,

(OrderQuantity * ProductPrice) AS SalesToDate

FROM Order.OrderLine, Product.ProductLine

WHERE Order.OrderNumber = OrderLine.OrderNumber

AND Product.ProductID = OrderedProduct.ProductID

AND Product.ProductID = ProductLine.ProductID

AND Product.ProductLineName = ‘Home O�ce’;

FIGURE 1-20 SQL query for Home Office sales-to-goal comparison

Home O�ce Sales to Date : Select QueryHome O�ce Sales to Date : Select Query

3 Computer Desk $23,500.00 5625

4400

650

3750

2250

3900

$22,500.00

$26,500.00

$23,500.00

$17,000.00

$26,500.00

96" Bookcase

48" Bookcase

Writer’s Desk

Writer’s Desk

Computer Desk

10

5

3

7

5

Product ID Product Description PR Current Year Sales Goal Sales to Date

FIGURE 1-21 Home Office product line sales comparison

Chris is now ready to meet with Helen again to see if the prototype is beginning to meet her needs. Chris shows Helen the system. As Helen makes suggestions, Chris is able to make a few changes online, but many of Helen’s observations will have to wait for more careful work at his desk.

Space does not permit us to review the whole project to develop the Home Office marketing support system. Chris and Helen ended up meeting about a dozen times before Helen was satisfied that all the attributes she needed were in the database; that the standard queries, forms, and reports Chris wrote were of use to her; and that she knew how to write queries for unanticipated questions. Chris will be available to Helen at any time to provide consulting support when she has trouble with the system, includ- ing writing more complex queries, forms, or reports. One final decision that Chris and Helen made was that the performance of the final prototype was efficient enough that the prototype did not have to be rewritten or redesigned. Helen was now ready to use the system.

Administering the Database

The administration of the Home Office marketing support system is fairly simple. Helen decided that she could live with weekly downloads of new data from Pine Valley’s operational databases into her MS Access database. Chris wrote a C# program with SQL commands embedded in it to perform the necessary extracts from the corporate data- bases and wrote an MS Access program in Visual Basic to rebuild the Access tables from these extracts; he scheduled these jobs to run every Sunday evening. Chris also updated the corporate information systems architecture model to include the Home Office mar- keting support system. This step was important so that when changes occurred to formats for data included in Helen’s system, the corporate data modeling and design tools could alert Chris that changes might also have to be made in her system.

Future of Databases at Pine Valley

Although the databases currently in existence at Pine Valley adequately support the daily operations of the company, requests such as the one made by Helen have highlighted

M01B_HOFF3359_13_GE_C01.indd 77 15/03/19 10:23 AM

78 Part I • The Context of Database Management

that the current databases are often inadequate for decision support applications. For example, following are some types of questions that cannot be easily answered:

1. What is the pattern of furniture sales this year compared with the same period last year?

2. Who are our 10 largest customers, and what are their buying patterns? 3. Why can’t we easily obtain a consolidated view of any customer who orders

through different sales channels rather than viewing each contact as representing a separate customer?

To answer these and other questions, an organization often needs to build a sepa- rate database that contains historical and summarized information. Such a database is usually called a data warehouse or, in some cases, a data mart. Also, analysts need special- ized decision support tools to query and analyze the database. One class of tools used for this purpose is called online analytical processing tools. You will learn more about data warehouses, data marts, data lakes, and related decision support tools in Chapters 9 through 11. There, you will learn of the interest in building a data warehouse that is now growing within Pine Valley Furniture Company. Who knows, maybe at some point in the near future the company will develop its own data lake for big data analysis.

Summary Over the past two decades, there has been enormous growth in the number and importance of database applications. Databases are used to store, manipulate, and retrieve data in every type of organization. In the highly competitive environment of today, there is every indica- tion that database technology will assume even greater importance. A course in modern database management is one of the most important courses in the information systems curriculum.

A database is an organized collection of logically related data. We define data as stored representations of objects and events that have meaning and importance in the user’s environment. Information is data that have been processed in such a way that the knowledge of the person who uses the data increases. Both data and infor- mation may be stored in a database.

Metadata are data that describe the properties or characteristics of end-user data and the context of that data. A database management system (DBMS) is a soft- ware system that is used to create, maintain, and provide controlled access to user databases. A DBMS stores meta- data in a repository, which is a central storehouse for all data definitions, data relationships, screen and report for- mats, and other system components. In addition to the databases enabling and supporting operational (transac- tional) systems, it is increasingly common that organiza- tions maintain databases that are used for informational purposes (analytics) using either the data warehousing approach or the big data approach.

Computer file processing systems were devel- oped early in the computer era so that computers could store, manipulate, and retrieve large files of data. These systems (still in use today) have a number of impor- tant limitations such as dependence between programs and data, data duplication, limited data sharing, and

lengthy development times. The database approach was developed to overcome these limitations. This approach emphasizes the integration and sharing of data across the organization. Advantages of this approach include program-data independence, improved data sharing, minimal data redundancy, and improved productivity of application development.

Database development for transactional systems begins with enterprise data modeling, during which the range and general contents of organizational data- bases are established. In addition to the relationships among the data entities themselves, their relationship to other organizational planning objects, such as organiza- tional units, locations, business functions, and informa- tion systems, also need to be established. Relationships between data entities and the other organizational plan- ning objects can be represented at a high level by plan- ning matrixes, which can be manipulated to understand patterns of relationships. Once the need for a database is identified, either from a planning exercise or from a specific request (such as the one from Helen Jarvis for a Home Office products marketing support system), a proj- ect team is formed to develop all elements. The project team follows a systems development process, such as the systems development life cycle or prototyping. The sys- tems development life cycle can be represented by five methodical steps: (1) planning, (2) analysis, (3) design, (4) implementation, and (5) maintenance. Database develop- ment activities occur in each of these overlapping phases, and feedback may occur that causes a project to return to a prior phase. In prototyping, a database and its appli- cations are iteratively refined through a close interaction of systems developers and users. Prototyping works best when the database application is small and stand-alone and a small number of users exist.

M01B_HOFF3359_13_GE_C01.indd 78 15/03/19 10:23 AM

1 • The Database Environment and Development Process 79

Those working on a database development proj- ect deal with three views, or schemas, for a database: (1) a conceptual schema, which provides a complete, technology-independent picture of the database; (2) an internal schema, which specifies the complete database as it will be stored in computer secondary memory in terms of a logical schema and a physical schema; and (3) an external schema or user view, which describes the database relevant to a specific set of users in terms of a set of user views combined with the enterprise data model.

Database applications can be arranged into the following categories: personal databases, multi-tiered databases, and enterprise databases. Enterprise data- bases include transactional databases supporting enter- prise systems, data warehouses and integrated decision support databases whose content is derived from the various operational databases, and data lakes for stor- ing large quantities of heterogeneous data for purposes that are often not predefined. Enterprise systems, such as enterprise resource planning (ERP) and customer relationship management rely heavily on enterprise databases. A modern database and the applications that use it may be located on multiple computers. Although

any number of tiers may exist (from one to many), three tiers of computers relate to the client/server architec- ture for database processing: (1) the client tier, where database contents are presented to the user; (2) the application/Web server tier, where analyses on data- base contents are made and user sessions are managed; and (3) the enterprise server tier, where the data from across the organization are merged into an organiza- tional asset.

We closed the chapter with the review of a hypo- thetical database development project at Pine Valley Furniture Company. This system to support marketing a Home Office furniture product line illustrated the use of a personal database management system and SQL coding for developing a retrieval-only database. The database in this application contained data extracted from the enter- prise databases and then stored in a separate database on the client tier. Prototyping was used to develop this database application because the user, Helen Jarvis, had rather unstructured needs that could best be discovered through an iterative process of developing and refining the system. Also, her interest and ability to work closely with Chris was limited.

Key Terms

Agile software development 59

Conceptual schema 57 Constraint 49 Data 41 Data independence 47 Data lake 68 Data model 45

Data modeling and design tools 53

Data warehouse 67 Database 40 Database

application 44 Database management

system (DBMS) 47

Enterprise data modeling 54

Enterprise resource planning (ERP) 67

Entity 45 Information 41 Logical schema 57 Metadata 42

Physical schema 57 Project 61 Prototyping 58 Relational database 46 Repository 53 Systems development life

cycle (SDLC) 55 User view 48

Chapter Review

Review Questions 1-1. Define each of the following terms:

a. data b. information c. metadata d. enterprise resource planning e. data warehouse f. constraint g. database h. entity i. database management system j. data lake k. systems development life cycle l. prototyping m. enterprise data model n. conceptual data model o. logical data model p. physical data model

1-2. Match the following terms and definitions:            agile software

development

           database application

           constraint

           repository

           metadata

           data warehouse

a. data placed in context or summarized

b. application program(s) c. iterative, focused on work-

ing software and customer collaboration

d. a graphical model that shows the high-level entities for the orga- nization and the relationships among those entities

e. a real-world person or object about which the organization wishes to maintain data

f. includes data definitions and constraints

M01B_HOFF3359_13_GE_C01.indd 79 15/03/19 10:23 AM

80 Part I • The Context of Database Management

           information

           user view

           database management system

           data independence

           entity

           enterprise resource planning

           systems development life cycle

           prototyping

           enterprise data model

           conceptual schema

           internal schema

           external schema

g. centralized storehouse for all data definitions

h. separation of data description from programs

i. a business management system that integrates all functions of the enterprise

j. logical description of portion of database

k. a software application that is used to create, maintain, and provide controlled access to user databases

l. a rule that cannot be violated by database users

m. integrated decision support data- base

n. consist of the enterprise data model and multiple user views

o. a rapid approach to systems development

p. consists of two data models: a logical model and a physical model

q. a comprehensive description of business data

r. a structured, step-by-step approach to systems development

1-3. Contrast the following terms: a. data dependence; data independence b. structured data; unstructured data c. metadata; data d. repository; database e. entity; enterprise data model f. data warehouse; data lake g. personal databases; multi-tiered databases h. systems development life cycle; prototyping i. enterprise data model; conceptual data model j. prototyping; agile software development

1-4. What problems may be encountered when developing new programs without designing a database management system?

1-5. Contrast transactional and analytical data management approaches.

1-6. What are the key differences between data warehousing and big data approaches to analytical data management?

1-7. List the nine major components in a database system envi- ronment.

1-8. Using a table, differentiate between how data is repre- sented in a file processing environment and how it is rep- resented in a relational database.

1-9. Consider Figure 1-5. What are the two common methods by which users interact with data in a database? Which one is more convenient to users if they do not have an understanding of query language? Why?

1-10. List 10 potential benefits of the database approach over conventional file systems.

1-11. List five costs or risks associated with the database approach. 1-12. A database is referred to as “an organized collection of

logically related data.” What does “related data” mean? Why must data be related?

1-13. Figure 1-5 specifies categories for Operational and Infor- mational data management systems. Describe the main difference between these two categories.

1-14. Based on Figure 1-5, what are the four perspectives from which you will explore transactional systems in this book? What are the main competencies associated with each of these perspectives?

1-15. A relationship is established between any pair of entities in an enterprise data model. Explain why a relationship is necessary.

1-16. Specify the difference between database solutions sup- porting enterprise databases and departmental multi- tiered databases.

1-17. What differentiates data lakes from traditional data ware- houses?

1-18. Name the five phases of the traditional systems develop- ment life cycle and explain the purpose and deliverables of each phase.

1-19. In which of the five phases of the SDLC do database development activities occur?

1-20. How does the use of an agile methodology affect deci- sions regarding data management?

1-21. Explain why certain business environments favor spe- cific database development methodologies. Highlight the pros and cons of each methodology and the differences in the approaches to database development. Do those differ- ences have any impact on the design process?

1-22. Explain the differences between user views, a conceptual schema, and an internal schema as different perspectives of the same database.

1-23. In the three-schema architecture: a. The view of a manager or other type of user is called

the           schema. b. The view of the data architect or data administrator is

called the           schema. c. The view of the database administrator is called

the           schema. 1-24. Revisit the section titled “Developing a Database Applica-

tion for Pine Valley Furniture Company.” What phase(s) of the database development process (Figure 1-9) do the activities that Chris performs in the following subsections correspond to: a. Project planning b. Analyzing database requirements c. Designing the database d. Using the database e. Administering the database

1-25. Why might Pine Valley Furniture Company need a data warehouse?

1-26. Explain some of the advantages of large databases that organizations can benefit from considering how the amount of data processed and stored in databases will increase in the future.

Problems and Exercises 1-27. For each of the following pairs of related entities, indicate

whether (under typical circumstances) there is a one-to- many or a many-to-many relationship. Then, using the shorthand notation introduced in the text, draw a diagram for each of the relationships.

a. STUDENT and COURSE (students register for courses)

b. BOOK and BOOK COPY (books have copies) c. COURSE and SECTION (courses have sections)

M01B_HOFF3359_13_GE_C01.indd 80 15/03/19 10:23 AM

1 • The Database Environment and Development Process 81

d. SECTION and ROOM (sections are scheduled in rooms)

e. INSTRUCTOR and COURSE f. COURSE and SEMESTER g. MEAL and COURSE

1-28. You are the manager of a department in a small logistics company. The current database system being used is hier- archical, and you have been tasked to formulate a team that can create a plan to develop a more efficient database system that is consistent with modern database theory. Devise a plan detailing how you would form such a team and what specific capabilities would be needed for it to develop a transition plan to a newer database model.

1-29. Table 1-1 shows example metadata for a set of data items. Identify three other columns for these data (i.e., three other metadata characteristics for the listed attributes) and complete the entries of the table in Table 1-1 for these three additional columns.

1-30. In the section “Disadvantages of File Processing Sys- tems,” the statement is made that the disadvantages of file processing systems can also be limitations of data- bases, depending on how an organization manages its databases. First, why do organizations create multiple databases, not just one all-inclusive database supporting all data processing needs? Second, what organizational and personal factors are at work that might lead an orga- nization to have multiple, independently managed data- bases (and, hence, not completely follow the database approach)?

1-31. Consider the data needs of a small accounting depart- ment at a tax services firm. What would some of the data entities be in this setting? List and explain their relevance. Develop a project data model for this firm applying the database design concepts you have learned in the chapter. Explain how you came up with the various relationships between the different entities.

1-32. Think of an organizational database in which some of the fields in the CUSTOMER table must have the following data types. Explain what they mean and how they are used. a. Customer ID (auto-numeric field) b. Customer Name (text field) c. Fee Paid (logical field) d. Pay Date (date field)

1-33. Consider a book rental system in a comic store. When a customer borrows or returns a comic book, the shop- keeper needs to note down the transaction or update the corresponding record on the transaction book. a. Draw an enterprise data model for this book rental

system. b. Identify the type of relationship between the tables. c. Design some attributes for these two tables.

1-34. Figure 1-22 shows an enterprise data model for a music store. a. What is the relationship between Album and Store

(one-to-one, many-to-many, or one-to-many)? b. What is the relationship between Artist and Album? c. Do you think there should be a relationship between

Artist and Store? Describe at least one possible sce- nario that could justify such a relationship.

1-35. Consider Figure 1-12, which depicts a hypothetical multi-tiered database architecture. Identify potential duplications of data across all the databases listed on this figure. What problems might arise because of this duplication? Does this duplication violate the principles of the database approach outlined in this chapter? Why or why not?

1-36. Review the example in Figure 1-2 and 1-4 regarding the differences between the file-based approach and the cur- rent database approach. Explain how these differences would impact the relationships between the different enti- ties in the database.

1-37. List three additional entities that might appear in an enterprise data model for Pine Valley Furniture Company ( Figure 1-3a).

1-38. Consider the following statement and translate it into SQL: Show me the “First Name,” “Last Name,” and “Company Name” fields from the “Contacts” table where the “City” field contains “Kansas City” and the “First Name” field starts with “R.”

1-39. Consider Figure 1-15. While designing the attributes for the Customer table, is it necessary to designate an attri- bute, such as Customer ID, as a key field? Can we use an ordinary attribute, such as Customer Name, to determine the existence of a customer record? Why?

1-40. There are various development approaches in organiza- tions, and the traditional ones have now been comple- mented by the more innovative system development methods. Much has been said about the prototyping methodology and its radical features in the development cycle. Critically review the prototyping methodology in the database development process and explain how some of the unique aspects of this development approach may be beneficial or detrimental in certain situations or for organizations.

1-41. What is the purpose of designing an enterprise data model? How is it different from the design of a particular database?

1-42. Prototyping is an iterative process of system develop- ment in which requirements are converted into a working system that is continually revised by analysts and users. What are the circumstances under which prototyping should be used?

1-43. Consider the SQL example in Figure 1-19. a. What is the name of the table that is referred to when

the SELECT statement is executed? b. How many tables are accessed when the FROM state-

ment is executed?

ALBUM ARTIST

STORE

Has

Produced By Produces

Sold By

FIGURE 1-22 Data model for Problem and Exercise 1-34

M01B_HOFF3359_13_GE_C01.indd 81 15/03/19 10:23 AM

82 Part I • The Context of Database Management

c. How many conditions are evaluated and met in order to display the details shown in Figure 1-20?

1-44. Consider Figure 1-15. Explain the meaning of the line that connects CUSTOMER to ORDER and the line that connects ORDER to INVOICE. What does this say about how Pine Val- ley Furniture Company does business with its customers?

1-45. Consider the project data model shown in Figure 1-16. a. Create a textual description of the diagrammatic repre-

sentation shown in the figure. Ensure that the description captures the rules/constraints conveyed by the model.

b. In arriving at the requirements document, what aspect of the diagram did you find was the most difficult to describe? Which parts of the requirements do you still consider to be a little ambiguous? In your opinion, what is the underlying reason for this ambiguity?

1-46. Answer the following questions concerning Figures 1-18 and 1-19: a. What will be the field size for the ProductLineName

field in the Product table? Why? b. In Figure 1-19, how is the ProductID field in the Prod-

uct table specified to be required? Why is it a required attribute?

c. In Figure 1-19, explain the function of the FOREIGN KEY definition.

d. In Figure 1-19, explain the purpose of the NOT NULL specification associated with ProductID.

1-47. Consider the SQL query in Figure 1-20. a. How is Sales to Date calculated? b. How would the query have to change if Helen Jarvis

wanted to see the results for all of the product lines, not just the Home Office product line?

c. The part of the query starting with WHERE (the so called WHERE clause) has two different types of conditions—the last one is clearly different from the first three. Explain how.

1-48. Consider Figure 1-15. a. What is the purpose of introducing an attribute

called Product ID to the Product table? What is its data type?

b. If the company wants to keep track of the total outstand- ing balances of customers, an attribute called “Customer Balances” should be introduced to which table?

1-49. In this chapter, we described four important data models and their properties: enterprise, conceptual, logical, and physical. In the following table, summarize the important properties of these data models by entering a Y (for yes) or an N (for no) in each cell of the table.

Table for Problem and Exercise 1-49

All Entities? All Attributes? Technology Independent? DBMS Independent? Record Layouts?

Enterprise

Conceptual

Logical

Physical

Field Exercises

For Questions 1-50 through 1-58, choose an organization with a fairly extensive information systems department and set of information sys- tem applications. You should choose one with which you are familiar, possibly your employer, your university, or an organization where a friend works. Use the same organization for each question.

1-50. Investigate whether the organization follows more of a traditional file processing approach or the database approach to organizing data. How many different data- bases does the organization have? Try to draw a figure, similar to Figure 1-2, to depict some or all of the files and databases in this organization.

1-51. Talk with a database administrator or designer from the organization. What type of metadata does this orga- nization maintain about its databases? Why did the organization choose to keep track of these and not other metadata? What tools are used to maintain these meta- data?

1-52. Determine the company’s use of intranet, extranet, or other Web-enabled business processes. For each type of pro- cess, determine its purpose and the database management

system that is being used in conjunction with the net- works. Ask what the company’s plans are for the next year with regard to using intranets, extranets, or the Web in its business activities. Ask what new skills the company is looking for in order to implement these plans.

1-53. Consider a major database in this organization, such as one supporting customer interactions, accounting, or manufacturing. What is the architecture for this data- base? Is the organization using some form of client/server architecture? Interview information systems managers in this organization to find out why they chose the architec- ture for this database.

1-54. Interview systems and database analysts at this organi- zation. Ask them to describe their systems development process. Which does it resemble more: the systems devel- opment life cycle or prototyping? Do they use method- ologies similar to both? When do they use their different methodologies? Explore the methodology used for devel- oping applications to be used through the Web. How have they adapted their methodology to fit this new systems development process?

M01B_HOFF3359_13_GE_C01.indd 82 15/03/19 10:23 AM

1 • The Database Environment and Development Process 83

1-55. Interview a systems analyst or database analyst and ask questions about the typical composition of an information systems development team. Specifically, what role does a database analyst play in project teams? Is a database ana- lyst used throughout the systems development process, or is the database analyst used only at selected points?

1-56. Interview a systems analyst or database analyst and ask questions about how that organization uses data model- ing and design tools in the systems development process. Concentrate your questions on how data modeling and design tools are used to support data modeling and data- base design and how the data modeling and design tool’s repository maintains the information collected about data, data characteristics, and data usage. If multiple data modeling and design tools are used on one or many projects, ask how the organization attempts to integrate data models and data definitions. Finally, inquire how satisfied the systems and database analysts are with data modeling and design tool support for data modeling and database design.

1-57. Interview one person from a key business function, such as finance, human resources, or marketing. Concentrate

your questions on the following items: How does he or she retrieve data needed to make business decisions? From what kind of system (personal database, enterprise system, or data warehouse) are the data retrieved? How often are these data accessed? Is this person satisfied with the data available for decision making? If not, what are the main challenges in getting access to the right data?

1-58. You may want to keep a personal journal of ideas and observations about database management while you are studying this book. Use this journal to record comments you hear, summaries of news stories or professional articles you read, original ideas or hypotheses you cre- ate, uniform resource locators (URLs) for and comments about Web sites related to databases, and questions that require further analysis. Keep your eyes and ears open for anything related to database management. Your instruc- tor may ask you to turn in a copy of your journal from time to time in order to provide feedback and reactions. The journal is an unstructured set of personal notes that will supplement your class notes and can stimulate you to think beyond the topics covered within the time limita- tions of most courses.

References

Anderson-Lehman, R., H. J. Watson, B. Wixom, and J. A. Hoffer. 2004. “Continental Airlines Flies High with Real-Time Business Intelligence.” MIS Quarterly Executive 3,4 ( December).

Codd, E. F. 1970. “A Relational Model of Data for Large Shared Data Banks.” Communications of the ACM 13,6 (June): 377–87.

Fowler, M. 2005. “The New Methodology.” Available at www .martinfowler.com/articles/newMethodology.html.

Gray, J. 1996. “Data Management: Past, Present, and Future.” IEEE Computer 29,10: 38–46.

Grimes, S. 1998. “Object/Relational Reality Check.” Database Programming & Design 11,7 (July): 26–33.

Groenfeldt, Tom. 2013. “Kroger Knows Your Shopping Patterns Better Than You Do.” Forbes Online. Available at www. forbes.com/sites/tomgroenfeldt/2013/10/28/kroger-knows- your-shopping-patterns-better-than-you-do.

Henderson, D., B. Champlin, D. Coleman, P. Cupoli, J. Hoffer, L. Howarth, et al. 2005. “Model Curriculum Framework for Post Secondary Education Programs in Data Resource Man- agement.” Data Management Association International Foun- dation Committee on the Advancement of Data Management in Post Secondary Institutions Sub Committee on Curriculum Framework Development, DAMA International Foundation.

IBM. 2011. “The Essential CIO: Insights from the 2011 IBM Global CIO Study.” Available at https://www-935.ibm.com/ services/c-suite/cio/study.

Jordan, A. 1996. “Data Warehouse Integrity: How Long and Bumpy the Road?” Data Management Review 6,3 (March): 35–37.

Laskowski, N. (2014). “Ten Big Data Case Studies in a Nutshell.” Available at http://searchcio.techtarget.com/ opinion/Ten-big-data-case-studies-in-a-nutshell.

Long, D. 2005. “.Net Overview.” Tampa Bay Technology Leadership Association, May 19.

Manyika, J., M. Chui, B. Brown, J. Bughin, R. Dobbs, C.  Roxburgh, and A. H. Byers. 2011. “Big Data: The Next Frontier for Innovation, Competition and Productivity.” McKinsey Global Institute, May.

Mullins, C. S. 2002. Database Administration: The Complete Guide to Practices and Procedures. New York: Addison-Wesley.

Ritter, D. 1999. “Don’t Neglect Your Legacy.” Intelligent Enterprise 2,5 (March 30): 70–72.

Valacich, J. S., and J. F. George. 2016. Modern Systems Analy- sis and Design. 8th ed. Upper Saddle River, NJ: Prentice Hall.

Further Reading

Ballou, D. P., and G. K. Tayi. 1999. “Enhancing Data Quality in Data Warehouse Environments.” Communications of the ACM 42,1 (January): 73–78.

Date, C. J. 1998. “The Birth of the Relational Model, Part 3.” Intelligent Enterprise 1,4 (December 10): 45–48.

Kimball, R., and M. Ross. 2002. The Data Warehouse Toolkit: The Complete Guide to Dimensional Data Modeling. 2nd ed. New York: Wiley.

Ritter, D. 1999. “The Long View.” Intelligent Enterprise 2,12 (August 24): 58–67.

Silverston, L. 2001a. The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises. New York: Wiley.

Silverston, L. 2001b. The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries. New York: Wiley.

M01B_HOFF3359_13_GE_C01.indd 83 15/03/19 10:23 AM

84 Part I • The Context of Database Management

Web Resources

www.webopedia.com An online dictionary and search engine for computer terms and Internet technology.

www.techrepublic.com A portal site for information technology professionals that users can customize to their own particular interests.

www.zdnet.com A portal site where users can review recent articles on information technology subjects.

www.information-management.com DM Review magazine Web site, with the tagline “Covering Business Intelligence, Integration and Analytics.” Provides a comprehensive list of links to relevant resource portals in addition to providing many of the magazine articles online.

www.dbta.com Data Base Trends and Applications magazine Web site. Addresses enterprise-level information issues.

http://databases.about.com A comprehensive site with many feature articles, links, interactive forum, chat rooms, and so forth.

http://groups.google.com/group/comp.software-eng? lnk=gsch&hl=en The software engineering archives for

a Google group that focuses on software engineering and related topics. This site contains many links that you may want to explore.

www.acinet.org/acinet America’s Career InfoNet, which provides information about careers, outlook, requirements, and so forth.

www.collegegrad.com/salaries/index.shtml A site for finding recent salary information for a wide range of careers, including database-related careers.

www.essentialstrategies.com/publications/methodology/ zachman.htm David Hay’s Web site, which has considerable information on universal data models as well as how database development fits into the Zachman information systems architecture.

www.inmondatasystems.com Web site for one of the pioneers of data warehousing.

www.agilemanifesto.org Web site that explains the viewpoints of those who created “The Manifesto for Agile Software Development.”

M01B_HOFF3359_13_GE_C01.indd 84 15/03/19 10:23 AM

1 • The Database Environment and Development Process 85

technical help for us. At this moment we have about 500 dif- ferent artists and every one of them is very special for us. We have about 20 artist managers who are responsible for different numbers of artists; some of them have only 10, but some man- age as many as 30 artists. The artist managers really keep this business going, and each of them has the ultimate responsibil- ity for the artists for whom they work. Every manager has an administrative assistant to help him or her with daily routine work—the managers are focusing on relationship building and finding new talent for our company. The managers report to me but they are very independent in their work, and I am very pleased that I only very seldom have to deal with operational issues related to the managers’ work. By the way, I also have my own artists (only a few but, of course, the very best within the company, if I may say so).

As I said, we find performance opportunities for the artists and, in practice, we organize their entire professional lives—of course, in agreement with them. Our main source of revenue consists of the royalties we get when we are successful in finding a performance opportunity for an artist: We get up to 30 percent of the fee paid to an artist (this is agreed sepa- rately with every artist and is a central part of our contract with the artist). Of course, we get the money only after the artist has successfully completed the performance; thus, if an artist has to cancel the performance, for example, because of illness, we will not get anything. Within the company the policy is very clear: A manager gets 50 percent of the royalties we earn based on the work of the artists he or she manages, and the remaining 50 percent will be used to cover administrative costs (including the administrative assistants’ salaries), rent, electricity, computer systems, accounting services, and, of course, my modest profits. Each manager pays their own travel expenses from their 50 per- cent. Keeping track of the revenues by manager and by artist is one of the most important issues in running this business. Right now, we take care of it manually, which occasionally leads to unfortunate mistakes and a lot of extra work trying to figure out what the problem is. It is amazing how difficult simple things can sometimes become.

When thinking about the relationship between us and an artist whom we represent, it is important to remember that the artists are ultimately responsible for a lot of the direct expenses we pay when working for them, such as flyers, photos, prints of photos, advertisements, and publicity mailings. We don’t, how- ever, charge for phone calls made on behalf of a certain artist, but rather this is part of the general overhead. We would like to settle the accounts with each of the artists once per month so that either we pay them what we owe after our expenses are deducted from their portion of the fee or they pay us, if the expenses are higher than a particular month’s fees. The artists take care of their own travel expenses, meals, etc.

From my perspective, the most important benefit of a new system would be an improved ability to know real-time how my managers are serving their artists. Are they finding opportunities for them and how good are the opportunities, what are the fees that their artists have earned and what are they projected to be, etc. Furthermore, the better the system

Case Description

FAME (Forondo Artist Management Excellence) Inc. is an art- ist management company that represents classical music art- ists (only soloists) both nationally and internationally. FAME has more than 500 artists under its management and wants to replace its spreadsheet-based system with a new state-of-the-art computerized information system.

Their core business idea is simple: FAME finds paid per- formance opportunities for the artists whom it represents and receives a 10 to 30 percent royalty for all the fees the artists earn (the royalties vary by artist and are based on a contract between FAME and each artist). To accomplish this objective, FAME needs technology support for several tasks. For exam- ple, it needs to keep track of prospective artists. FAME receives information regarding possible new artists both from promis- ing young artists themselves and as recommendations from current artists and a network of music critics. FAME employees collect information regarding promising prospects and main- tain that information in the system. When FAME management decides to propose a contract to a prospect, it first sends the artist a tentative contract, and if the response is positive, a final contract is mailed to the prospect. New contracts are issued annually to all artists.

FAME markets its artists to opera houses and concert halls (customers); in this process, a customer normally requests a specific artist for a specific date. FAME maintains the artists’ calendars and responds back based on the requested artist’s availability. After the performance, FAME sends an invoice to the customer, who sends a payment to FAME (note that FAME requires a security deposit, but you do not need to capture that aspect in your system). Finally, FAME pays the artist after deducting its own fee.

Currently, FAME has no IT staff. Its technology infrastruc- ture consists of a variety of desktops, printers, laptops, tablets, and smartphones all connected with a simple wired and wire- less network. A local company manages this infrastructure and provides the required support.

Martin Forondo, the owner of FAME, has commissioned your team to design and develop a database application. In his e-mail soliciting your help, he provides the following information:

E-mail from Martin Forondo, Owner

My name is Martin Forondo, and I am the owner and founder of FAME. I have built this business over the past 30 years together with my wonderful staff and I am very proud of my company. We are in the business of creating bridges between the fin- est classical musicians and the best concert venues and opera houses of the world and finding the best possible opportunities for the musicians we represent. It is very important for us to provide the best possible service to the artists we represent.

It used to be possible to run our business without any technology, particularly when the number of the artists we rep- resented was much smaller than it currently is. The situation is, however, changing, and we seem to have a need to get some

CASE Forondo Artist Management Excellence Inc.

M01B_HOFF3359_13_GE_C01.indd 85 15/03/19 10:23 AM

86 Part I • The Context of Database Management

could predict the future revenues of the company, the better for me. Whatever we could do with the system to better cultivate new relationships between promising young artists, it would be great. I am not very computer savvy; thus, it is essential that the system will be easy to use.

Project Questions

1-59. Create a memo describing your initial analysis of the situation at FAME as it relates to the design of the data- base application. Write this as though you are writing a memo to Martin Forondo. Ensure that your memo addresses the following points: a. Your approach to addressing the problem at hand

(e.g., specify the systems development life cycle or whatever approach you plan on taking).

b. What will the new system accomplish? What func- tions will it perform? Which organizational goals will it support?

c. What will be the benefits of using the new system? Use concrete examples to illustrate this. Outline general categories of costs and resources needed for the project and implementation of the ultimate system.

d. A time line/road map for the project. e. Questions, if any, you have for Mr. Forondo for which

you need answers before you would be willing to begin the project.

1-60. Create an enterprise data model that captures the data needs of FAME. Use a notation similar to the one shown in Figure 1-4.

M01B_HOFF3359_13_GE_C01.indd 86 15/03/19 10:23 AM

87

Database Analysis and Logical Design

AN OVERVIEW OF PART II

The first step in database development is database analysis, in which you determine user requirements for data and develop data models to represent those requirements. The first two chapters in Part II describe in depth the de facto standard for conceptual data modeling—entity-relationship (E-R) diagramming. A conceptual data model represents data from the viewpoint of the organization, independent of any technology that will be used to implement the model.

In Chapter 2 (“Modeling Data in the Organization”) you will learn how to identify and document business rules, which are the policies and rules about the operation of a business that a data model represents. Characteristics of good business rules are described, and the process you will follow for gathering business rules is discussed. General guidelines for naming and defining elements of a data model are presented within the context of business rules.

Chapter 2 introduces the notations and main constructs of this modeling technique, including entities, relationships, and attributes; for each construct, you will see specific guidelines for naming and defining these elements of a data model. You will learn how to distinguish between strong and weak entity types and the use of identifying relationships. You will also learn about different types of attributes, including required versus optional attributes, simple versus composite attributes, single-valued versus multivalued attributes, derived attributes, and identifiers. You will contrast relationship types and instances and understand associative entities. You will study relationships of various degrees, including unary, binary, and ternary relationships. You will learn how to model the various relationship cardinalities that arise in modeling situations. You will study the common problem of how to model time-dependent data. Finally, you will see how multiple relationships can be defined between a given set of entities. The E-R modeling concepts are illustrated with an extended example for Pine Valley Furniture Company. This final example, as well as a few other examples throughout the chapter, is presented using Microsoft Visio, which shows how many data modeling tools represent data models.

Chapter 3 (“The Enhanced E-R Model”) presents advanced concepts in E-R modeling; you will often need these additional modeling features to cope with the increasingly complex business environment encountered in organizations today.

The most important modeling construct incorporated in the enhanced entity- relationship (EER) diagram is supertype/subtype relationships. This facility allows you to model a general entity type (called a supertype) and then subdivide it into several specialized entity types called subtypes. For example, sports cars and

PART II

Chapter 2 Modeling Data in the Organization

Chapter 3 The Enhanced E-R Model

Chapter 4 Logical Database Design and the Relational Model

M02A_HOFF3359_13_GE_P02.indd 87 22/02/19 11:00 AM

88 Part II • Database Analysis and Logical Design

sedans are subtypes of automobiles. You will learn to use a simple notation for representing supertype/subtype relationships and several refinements. You will study generalization and specialization as two contrasting techniques for identifying supertype/subtype relationships. Supertype/subtype notation is necessary for the increasingly popular universal data model, which is motivated and explained in Chapter 3. The comprehensiveness of a well-documented relationship can be overwhelming, so we introduce a technique called entity clustering for simplifying the presentation of an E-R diagram to meet the needs of a given audience.

The concept of patterns has become a central element of many information systems development methodologies. The notion is that there are reusable component designs that you can combine and tailor to meet new information system requests. In the database world, these patterns are called universal data models, prepackaged data models, or logical data models. These patterns can be purchased or may be inherent in a commercial off-the-shelf package, such as an ERP or CRM application. Increasingly, it is from these patterns that new databases are designed. In Chapter 3, we describe the usefulness of such patterns and outline a modification of the database development process when such patterns are the starting point. Universal industry or business function data models extensively use the extended E-R diagramming notations introduced in this chapter.

There is another, alternative notation for data modeling: the Unified Modeling Language class diagrams for systems developed using object-oriented technologies. This technique is presented in a supplement found on this book’s Web site. It is possible to read this supplement immediately after Chapter 3 if you want to compare these alternative, but conceptually similar, approaches.

Before you can implement a database, you must map the conceptual data model into a data model that is compatible with the database management system to be used. The activities of database design transform the requirements for data storage developed during database analysis into specifications to guide database implementation. There are two forms of specifications:

1. Logical specifications, which map the conceptual requirements into the data model associated with a specific database management system.

2. Physical specifications, which indicate all the parameters for data storage. Because database implementation often proceeds before these parameters can be finalized, we will delay discussing physical database design until later in this text.

In Chapter 4 (“Logical Database Design and the Relational Model”), you will study logical database design, with special emphasis on the relational data model. Logical database design is the process of transforming the conceptual data model (described in Chapters 2 and 3) into a logical data model. Most database management systems in use today are based on the relational data model, so this data model is the basis for our discussion of logical database design.

In Chapter 4, you will learn the important terms and concepts for this model, including relation, primary key and surrogate primary key, foreign key, anomaly, normal form, normalization, functional dependency, partial functional dependency, and transitive dependency. You next study the process of transforming an E-R model to the relational model. Many modeling tools support this transformation; however, it is important that you understand the underlying principles and procedures. You then will see in detail the important concepts of normalization (the process of designing well- structured relations). Appendix B, on the book’s Web site, includes further discussion of normalization. Finally, you will learn how to merge relations from separate logical design activities (e.g., different groups within a large project team) while avoiding common pitfalls that may occur in this process. Finally, you will study enterprise keys, which make relational keys distinct across relations.

The conceptual and logical data modeling concepts presented in the three chapters in Part II provide the foundation for your career in database analysis and design. As a database analyst, you will be expected to apply the E-R notation and relational normalization in modeling user requirements for data and information.

M02A_HOFF3359_13_GE_P02.indd 88 22/02/19 11:00 AM

Modeling Data in the Organization LEARNING OBJECTIVES After studying this chapter, you should be able to:

■■ Concisely define each of the following key terms: business rule, term, fact, entity- relationship model (E-R model), entity-relationship diagram (E-R diagram), entity, entity type, entity instance, strong entity type, weak entity type, identifying owner, identifying relationship, attribute, required attribute, optional attribute, composite attribute, simple attribute, multivalued attribute, derived attribute, identifier, composite identifier, relationship type, relationship instance, associative entity, degree, unary relationship, binary relationship, ternary relationship, cardinality constraint, minimum cardinality, maximum cardinality, and time stamp.

■■ State reasons why many system developers and business leaders believe that data modeling is the most important part of the systems development process with a high return on investment.

■■ Write good names and definitions for entities, relationships, and attributes. ■■ Distinguish unary, binary, and ternary relationships and give a common example of each.

■■ Model each of the following constructs in an E-R diagram: composite attribute, multivalued attribute, derived attribute, associative entity, identifying relationship, and minimum and maximum cardinality constraints.

■■ Draw an E-R diagram to represent common business situations. ■■ Convert a many-to-many relationship to an associative entity type. ■■ Model simple time-dependent data using time stamps and relationships in an E-R diagram.

INTRODUCTION

You have already been introduced to modeling data and the entity-relationship (E-R) data model through simplified examples in Chapter 1. (You may want to review, for example, the E-R models in Figures 1-3 and 1-4.) In this chapter, we formalize data modeling based on the powerful concept of business rules and describe the E-R data model in detail. This chapter begins your journey of learning how to design and use databases. It is exciting to create information systems that run organizations and help people do their jobs well.

Your excitement can, of course, lead to mistakes if you are not careful to follow best practices. Embarcadero Technologies, a leader in database design tools and processes, has identified “seven deadly sins” that are the culprits underlying the failure to follow best practices of database design (Embarcadero Technologies, 2014):

Visit www.pearsonglobaleditions .com to view the accompanying video for this chapter.

2

89

M02B_HOFF3359_13_GE_C02.indd 89 12/04/19 12:08 PM

90 Part II • Database Analysis and Logical Design

1. Poor or missing documentation for database(s) in production (this will be ad- dressed in Chapters 2 and 3 via the topics of business rules and data modeling with entity relationship diagramming)

2. Little or no normalization (this will be a central topic of Chapter 4 on the relational data model)

3. Not treating the data model like a living, breathing organism (we encourage you through exercises and projects to develop database designs in phases and to realize that requirements evolve and emerge over time; in other words, de- sign for change)

4. Improper storage of reference data (we will address this briefly in subsequent chapters in Parts II and III of this text)

5. Not using foreign keys or check constraints (this will be a significant topic in Chapters 4 and 8)

6. Not using domains and naming standards (we emphasize naming standards in Chapter 2 and provide guidelines on good standards to adopt in your practice)

7. Not choosing primary keys (we emphasize entity identifiers in Chapter 2 and address considerations in choosing primary keys in Chapters 4 and 8)

A specific quote from the referenced Embarcadero report that we believe sets the tone for the importance of what we present in this and subsequent chapters is “In the data management arena, you may constantly hear from data professionals that if you don’t get the data right, nothing else matters. However, the business focus on applications often overshadows the priority for a well-organized database design. The database just comes along for the ride as the application grows in scope and functionality.” That is, often in practice there is an emphasis on functionality over architecture and engineering. If the architecture and engineering are bad, you can never achieve the functionality the organization requires. So, let’s begin at the beginning for the architecture and engineering of a database with business rules.

Business rules, the foundation of data models, are derived from policies, procedures, events, functions, and other business objects, and they state constraints on the organization. Business rules represent the language and fundamental structure of an organization (Hay, 2003). Business rules formalize the understanding of the organization by organization owners, managers, and leaders with that of information systems architects.

Business rules are important in data modeling because they govern how data are handled and stored. Examples of basic business rules are data names and definitions. This chapter explains guidelines you can follow for the clear naming and definition of data objects in a business. In terms of conceptual data modeling, you must provide names and definitions for the main data objects: entity types (e.g., Customer), attributes (e.g., Customer Name), and relationships (e.g., Customer Places Orders). Other business rules may state constraints on these data objects. These constraints can be captured in a data model, such as an E-R diagram, and associated documentation. Additional business rules govern the people, places, events, processes, networks, and objectives of the organization, which are all linked to the data requirements through other system documentation.

After decades of use, the E-R model remains the mainstream approach for conceptual data modeling. Its popularity stems from factors such as relative ease of use, widespread computer-aided software engineering (CASE) tool support, and the belief that entities and relationships are natural modeling concepts in the real world.

The E-R model is most used as a tool for communications between database designers (that is, you!) and end users during the analysis phase of database development (described in Chapter 1). The E-R model is used to construct a conceptual data model, which is a representation of the structure and constraints of a database that is independent of software (such as a database management system).

Some database professionals introduce terms and concepts peculiar to the relational data model when discussing E-R modeling; the relational data model is

M02B_HOFF3359_13_GE_C02.indd 90 12/04/19 12:08 PM

2 • Modeling Data in the Organization 91

the basis for most database management systems in use today. In particular, they recommend that the E-R model be completely normalized, with full resolution of primary and foreign keys. However, we believe that this forces a premature commitment to the relational data model. In today’s database environment, the database may be implemented with a mixture of relational and nonrelational technology. Therefore, we defer discussion of normalization concepts to Chapter 4.

The E-R model was introduced in a key article by Chen (1976), in which he described the main constructs of the E-R model—entities and relationships—and their associated attributes. The model has subsequently been extended to include additional constructs by Chen and others; for example, see Teorey et al. (1986) and Storey (1991). The E-R model continues to evolve, but unfortunately there is not yet a standard notation for E-R modeling. Because data modeling software tools are now commonly used by professional data modelers, we adopt for use in this text a variation of the notation used in professional modeling tools. Appendix A, found on this book’s Web site, will help you translate between our notation and other popular E-R diagramming notations.

As said in a once-popular travel service TV commercial, “we are doing important stuff here.” Many systems developers believe that data modeling is the most important part of the systems development process for the following reasons (Valacich & George, 2016):

1. The characteristics of data captured during data modeling are crucial in the design of databases, programs, and other system components. The facts and rules captured during the process of data modeling are essential in assuring data integrity in an information system.

2. Data rather than processes are the most complex aspect of many modern infor- mation systems and hence require a central role in structuring system require- ments. Often the goal is to provide a rich data resource that might support any type of information inquiry, analysis, and summary.

3. Data tend to be more stable than the business processes that use that data. Thus, an information system design that is based on a data orientation should have a longer useful life than one based on a process orientation.

Of course, we are all eager to build something new, so data modeling may still seem like a costly and unnecessary activity that simply delays getting to “the real work.” If the above reasons for why data modeling is important are not enough to convince you, the following reasons are derived from what one industry leader demonstrates with examples are the benefits from and return on investment for data modeling (Haughey, 2010):

• Data modeling facilitates interaction/communication between designer, application programmer, and end user, thus reducing misunderstandings and improving the thoroughness of resultant systems; this is accomplished, in part, by providing a simplified (visual) understanding of data (data model) with agreed upon supporting documentation (metadata).

• Data modeling can foster understanding of the organization (rules) for which the data model is being developed; consistency and completeness of rules can be verified; otherwise, it is possible to create systems that are incorrect or inconsistent and unable to accommodate changes in user requirements (such as processing certain transactions or producing specific reports).

• The value of data modeling can be demonstrated as an overall savings in maintenance or development costs by determining the right requirements before the more costly steps of software development and hardware acqui- sition; further, data models can be reused in whole or in part on multiple projects, which can result in significant savings to any organization by reducing the costs for building redundant systems or complex interfaces between systems.

• Data modeling results in improved data quality because of consistent business data definitions (metadata) and hence greater accuracy of reporting and

M02B_HOFF3359_13_GE_C02.indd 91 12/04/19 12:08 PM

92 Part II • Database Analysis and Logical Design

consistency across systems and less organizational confusion; data modeling across the organization results in everyone having the same understanding of the same data.

• Data modeling reduces the significant costs of moving and translating data from one system to another; decisions can be made about the efficacy of sharing or having redundant data because data modeling creates a consistent enterprise-wide understanding of data; and when data must be transferred to achieve efficiencies, they do not have to be collected (possibly with inconsis- tencies) in multiple systems or from multiple sources.

To state it as simply as possible, the value of data modeling can be summarized by the phrase “measure twice, cut once.”

In an actual work environment, you may not have to develop a data model from scratch. Because of the increased acceptance of packaged software (e.g., enterprise resource planning with a predefined data model) and purchased business area or industry data models (which we discuss in Chapter 3), your job of data modeling has a jump start. This is good because such components and patterns give you a starting point based on generally accepted practices. However, your job is not done for several reasons:

1. There are still many times when a new, custom-built application is being developed along with the associated database. The business rules for the business area supported by this application need to be modeled.

2. Purchased applications and data models need to be customized for your particular setting. Predefined data models tend to be very extensive and com- plex; hence, they require significant data modeling skill to tailor the models to be effective and efficient in a given organization. Although this effort can be much faster, thorough, and accurate than starting from scratch, the ability to understand a particular organization to match the data model to its busi- ness rules is an essential task.

In this chapter, you will learn the main features of E-R modeling, using common notation and conventions. We begin with a sample E-R diagram, including the basic constructs of the E-R model—entities, attributes, and relationships—and then we introduce the concept of business rules, which is the foundation for all the data modeling constructs. We define three types of entities that are common in E-R modeling: strong entities, weak entities, and associative entities; a few more entity types are defined in Chapter 3. We also define several important types of attributes, including required and optional attributes, single- and multivalued attributes, derived attributes, and composite attributes. We then introduce three important concepts associated with relationships: the degree of a relationship, the cardinality of a relationship, and participation constraints in a relationship. We conclude with an extended example of an E-R diagram for Pine Valley Furniture Company.

THE E-R MODEL: AN OVERVIEW

An entity-relationship model (E-R model) is a detailed, logical representation of the data for an organization or for a business area. The E-R model is expressed in terms of entities in the business environment, the relationships (or associations) among those entities, and the attributes (or properties) of both the entities and their relationships. An E-R model is normally expressed as an entity-relationship diagram (E-R diagram, or ERD), which is a graphical representation of an E-R model.

Sample E-R Diagram

To jump-start your understanding of E-R diagrams, Figure 2-1 presents a simplified E-R diagram for a small furniture manufacturing company, Pine Valley Furniture Company. (This figure, which does not include attributes, is often called an enterprise data model, which we introduced in Chapter 1; we use cartoon caption-like bubbles here and in sub- sequent figures to help you understand the meaning of symbols used in E-R diagrams.)

Entity-relationship model (E-R model)

A logical representation of the data for an organization or for a business area, using entities for categories of data and relationships for associations between entities.

Entity-relationship diagram (E-R diagram, or ERD)

A graphical representation of an entity-relationship model.

M02B_HOFF3359_13_GE_C02.indd 92 12/04/19 12:08 PM

2 • Modeling Data in the Organization 93

A number of suppliers supply and ship different items to Pine Valley Furniture. The items are assembled into products that are sold to customers who order the products. Each customer order may include one or more lines corresponding to the products appearing on that order.

The diagram in Figure 2-1 shows the entities and relationships for this company. (Attributes are omitted to simplify the diagram for now.) Entities (the objects of the organization) are represented by the rectangle symbol, whereas relationships between entities are represented by lines connecting the related entities. The entities in Figure 2-1 include the following:

CUSTOMER A person or an organization that has ordered or might order products. Example: L. L. Fish Furniture.

PRODUCT A type of furniture made by Pine Valley Furniture that may be ordered by customers. Note that a product is not a specific bookcase because individual bookcases do not need to be tracked. Example: A 6-foot, 5-shelf, oak bookcase called O600.

ORDER The transaction associated with the sale of one or more products to a customer and identified by a transaction number from sales or accounting. Example: The event of L. L. Fish buying one product O600 and four products O623 on September 10, 2018.

ITEM A type of component that goes into making one or more products and can be supplied by one or more suppliers. Example: A 4-inch ball-bearing caster called I-27–4375.

SUPPLIER Another company that may provide items to Pine Valley Furniture. Example: Sure Fasteners, Inc.

SHIPMENT The transaction associated with items received in the same package by Pine Valley Furniture from a supplier. All items in a shipment appear on one bill- of-lading document. Example: The receipt of 300 I-27-4375 and 200 I-27- 4380 items from Sure Fasteners, Inc., on September 9, 2018.

FIGURE 2-1 Sample E-R diagram

SUPPLIER ORDER

PRODUCTSHIPMENT

ENTITY TYPE

CUSTOMER

ITEM

Relationship

Key

Sends

Supplies Submits

Submitted By

Requests

Requested On

Used In

Uses

Sent By

Supplied By

Includes

Included On

Cardinalities

Mandatory One Optional One

Mandatory Many Optional Many

many

is/must

may

M02B_HOFF3359_13_GE_C02.indd 93 12/04/19 12:08 PM

94 Part II • Database Analysis and Logical Design

Note that it is important to clearly define, as metadata, each entity. For example, it is important to know that the CUSTOMER entity includes persons or organizations that have not yet purchased products from Pine Valley Furniture. It is common for different departments in an organization to have different meanings for the same term (homonyms). For example, Accounting may designate as customers only those persons or organizations that have ever made a purchase, thus excluding potential custom- ers, whereas Marketing designates as customers anyone they have contacted or who has purchased from Pine Valley Furniture or any known competitor. An accurate and thorough ERD without clear metadata may be interpreted in different ways by different people. We outline good naming and definition conventions as we formally introduce E-R modeling throughout this chapter.

The symbols at the end of each line on an ERD specify relationship cardinalities, which represent how many entities of one kind relate to how many entities of another kind. On examining Figure 2-1, we can see that these cardinality symbols express the following business rules:

1. A SUPPLIER may supply many ITEMs (by “may supply,” we mean the supplier may not supply any items). Each ITEM is supplied by any number of SUPPLIERs (by “is supplied,” we mean that the item must be supplied by at least one sup- plier). See annotations in Figure 2-1 that correspond to underlined words.

2. Each ITEM must be used in the assembly of at least one PRODUCT and may be used in many products. Conversely, each PRODUCT must use one or more ITEMs.

3. A SUPPLIER may send many SHIPMENTs. However, each shipment must be sent by exactly one SUPPLIER. Notice that sends and supplies are separate concepts. A SUPPLIER may be able to supply an item but may not yet have sent any ship- ments of that item.

4. A SHIPMENT must include one (or more) ITEMs. An ITEM may be included on several SHIPMENTs.

5. A CUSTOMER may submit any number of ORDERs. However, each ORDER must be submitted by exactly one CUSTOMER. Given that a CUSTOMER may not have submitted any ORDERs, some CUSTOMERs must be potential, inactive, or some other customer possibly without any related ORDERs.

6. An ORDER must request one (or more) PRODUCTs. A given PRODUCT may not be requested on any ORDER or may be requested on one or more orders.

There are actually two business rules for each relationship, one for each direction from one entity to the other. Note that each of these business rules roughly follows a certain grammar:

<entity> <minimum cardinality> <relationship> <maximum cardinality> <entity>

For example, rule 5 is

<CUSTOMER> <may> <Submit> <any number> <ORDER>

This grammar gives you a standard way to put each relationship into a natural English business rule statement.

E-R Model Notation

The notation we use for E-R diagrams is shown in Figure 2-2. As indicated in the previous section, there is no industry-standard notation (in fact, you saw a slightly sim- pler notation in Chapter 1). The notation in Figure 2-2 combines most of the desirable features of the different notations that are commonly used in E-R drawing tools today and also allows us to model accurately most situations that are encountered in practice. You will learn additional notation for enhanced E-R models (including class-subclass relationships) in Chapter 3.

M02B_HOFF3359_13_GE_C02.indd 94 12/04/19 12:08 PM

2 • Modeling Data in the Organization 95

In many situations, however, a simpler E-R notation is sufficient. Most drawing tools, either stand-alone ones such as Microsoft Visio or SmartDraw (which we use in the video associated with this chapter) or those in CASE tools such as Oracle Designer, ERwin, or SAP PowerDesigner, do not show all the entity and attribute types we use. It is important to note that any notation requires special annotations, not always pres- ent in a diagramming tool, to show all the business rules of the organizational situation you are modeling. We will use the Visio notation for a few examples throughout the chapter and at the end of the chapter so that you can see the differences. Appendix A, found on this book’s Web site, illustrates the E-R notation from several commonly used guidelines and diagramming tools. This appendix may help you translate between the notations in the text and the notations you use in classes.

MODELING THE RULES OF THE ORGANIZATION

Now that you have an example of a data model in mind, let’s step back and consider more generally what a data model is representing. You will see in this and the next chapter how to use data models, in particular the E-R notation, to document rules and policies of an organization. In fact, documenting rules and policies of an organization that govern data is exactly what data modeling is all about. Business rules and policies govern creating, updating, and removing data in an information processing and storage sys- tem; thus, they must be described along with the data to which they are related. For example, the policy “every student in the university must have a faculty adviser” forces data (in a database) about each student to be associated with data about some student adviser. Also, the statement “a student is any person who has applied for admission or taken a course or training program from any credit or noncredit unit of the university” not only defines the concept of “student” for a particular university but also states a policy of that university (e.g., implicitly, alumni are students, and a high school student

Mandatory one Mandatory many Optional one Optional many

Identifier Partial identifier

ENTITY NAME Strong

Associative

Entity types

Relationship degrees

Relationship cardinality

Unary Binary

Weak

Attributes

Ternary

Optional [Derived] {Multivalued} Composite( , , )

FIGURE 2-2 Basic E-R notation

M02B_HOFF3359_13_GE_C02.indd 95 12/04/19 12:08 PM

96 Part II • Database Analysis and Logical Design

who attended a college fair but has not applied is not a student, assuming the college fair is not a noncredit training program).

Business rules and policies are not universal; for example, different universities may have different policies for student advising and may include different types of people as students. Also, the rules and policies of an organization may change (usually slowly) over time; a university may decide that a student does not have to be assigned a faculty adviser until the student chooses a major.

Your job as a database analyst is to:

• Identify and understand those rules that govern data. • Represent those rules so that they can be unambiguously understood by informa-

tion systems developers and users. • Implement those rules in database technology.

Data modeling is an important tool in this process. Because the purpose of data modeling is to document business rules about data, we introduce the discussion of data modeling and the E-R notation with an overview of business rules. Data models cannot represent all business rules (and do not need to, because not all business rules govern data); data models along with associated documentation and other types of information system models (e.g., models that document the processing of data) represent all busi- ness rules that must be enforced through information systems.

Overview of Business Rules

A business rule is “a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business … rules prevent, cause, or suggest things to happen” (GUIDE Business Rules Project, 1997). For example, the following two statements are common expressions of business rules that affect data processing and storage:

• “A student may register for a section of a course only if he or she has successfully completed the prerequisites for that course.”

• “A preferred customer qualifies for a 10 percent discount, unless he has an over- due account balance.”

Most organizations (and their employees) today are guided by thousands of combinations of such rules. In the aggregate, these rules influence behavior and deter- mine how the organization responds to its environment (Gottesdiener, 1997; von Halle, 1997). Capturing and documenting business rules is an important, complex task. Thoroughly capturing and structuring business rules, then enforcing them through database technologies, helps ensure that information systems work right and that users of the information understand what they enter and see.

THE BUSINESS RULES PARADIGM The concept of business rules has been used in infor- mation systems for some time. There are many software products that help organizations manage their business rules (e.g., IBM WebSphere ILOG JRules). In the database world, it has been more common to use the related term integrity constraint when referring to such rules. The intent of this term is somewhat more limited in scope, usually referring to maintaining valid data values and relationships in the database.

A business rules approach is based on the following premises:

• Business rules are a core concept in an enterprise because they are an expression of business policy and guide individual and aggregate behavior. Well-structured business rules can be stated in natural language for end users and in a data model for systems developers.

• Business rules can be expressed in terms that are familiar to end users. Thus, users can define and then maintain their own rules.

• Business rules are highly maintainable. They are stored in a central repository, and each rule is expressed only once, then shared throughout the organization. Each rule is discovered and documented only once, to be applied in all systems devel- opment projects.

Business rule

A statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.

M02B_HOFF3359_13_GE_C02.indd 96 12/04/19 12:08 PM

2 • Modeling Data in the Organization 97

• 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 (Moriarty, 2000).

Although much progress has been made, the industry has not realized all of these objectives to date (Owen, 2004). Possibly the premise with greatest potential benefit is “Business rules are highly maintainable.” The ability to specify and main- tain the requirements for information systems as a set of rules has considerable power when coupled with an ability to generate automatically information systems from a repository of rules. Automatic generation and maintenance of systems will not only simplify the systems development process but also will improve the quality of systems.

Scope of Business Rules

In this chapter and the next, we are concerned with business rules that impact only an organization’s databases. Most organizations have a host of rules and/or policies that fall outside this definition. For example, the rule “Friday is business casual dress day” may be an important policy statement, but it has no immediate impact on databases. In contrast, the rule “A student may register for a section of a course only if he or she has successfully completed the prerequisites for that course” is within our scope because it constrains the transactions that may be processed against the database. In particular, it causes any transaction that attempts to register a student who does not have the neces- sary prerequisites to be rejected. Some business rules cannot be represented in common data modeling notation; those rules that cannot be represented in a variation of an E-R diagram are stated in natural language, and some can be represented in the relational data model, which we describe in Chapter 4.

GOOD BUSINESS RULES Whether stated in natural language, a structured data model, or other information systems documentation, a business rule will have certain charac- teristics if it is to be consistent with the premises outlined previously. These characteris- tics are summarized in Table 2-1. These characteristics will have a better chance of being satisfied if a business rule is defined, approved, and owned by business, not technical, people. Businesspeople become stewards of the business rules. You, as the database analyst, facilitate the surfacing of the rules and the transformation of ill-stated rules into ones that satisfy the desired characteristics.

TABLE 2-1 Characteristics of a Good Business Rule

Characteristic Explanation

Declarative A business rule is a statement of policy, not how policy is enforced or conducted; the rule does not describe a process or implementation but rather describes what a process validates.

Precise With the related organization, the rule must have only one interpretation among all interested people, and its meaning must be clear.

Atomic A business rule marks one statement, not several; no part of the rule can stand on its own as a rule (i.e., the rule is indivisible, yet sufficient).

Consistent A business rule must be internally consistent (i.e., not containing conflicting statements) and must be consistent with (and not contradict) other rules.

Expressible A business rule must be able to be stated in natural language, but it will be stated in a structured natural language so that there is no misinterpretation.

Distinct Business rules are not redundant, but a business rule may refer to other rules (especially to definitions).

Business-oriented A business rule is stated in terms businesspeople can understand, and because it is a statement of business policy, only businesspeople can modify or invalidate a rule; thus, a business rule is owned by the business.

Source: Based on Gottesdiener (1999) and Plotkin (1999).

M02B_HOFF3359_13_GE_C02.indd 97 12/04/19 12:08 PM

98 Part II • Database Analysis and Logical Design

GATHERING BUSINESS RULES Business rules appear (possibly implicitly) in descrip- tions of business functions, events, policies, units, stakeholders, and other objects. You can find these descriptions in interview notes from individual and group infor- mation systems requirements collection sessions, organizational documents (e.g., personnel manuals, policies, contracts, marketing brochures, and technical instruc- tions), and other sources. Rules are identified by asking questions about the who, what, when, where, why, and how of the organization. Usually, a data analyst has to be persistent in clarifying initial statements of rules because initial statements may be vague or imprecise (what some people have called “business ramblings”). Thus, precise rules are formulated from an iterative inquiry process. You should be prepared to ask such questions as “Is this always true?” “Are there special circum- stances when an alternative occurs?” “Are there distinct kinds of that person?” “Is there only one of those or are there many?” and “Is there a need to keep a history of those, or is the current data all that is useful?” Such questions can be useful for sur- facing rules for each type of data modeling construct we introduce in this chapter and the next.

Data Names and Definitions

Fundamental to understanding and modeling data are naming and defining data objects. Data objects must be named and defined before they can be used unambig- uously in a model of organizational data. In the E-R notation you will learn in this chapter, you have to give entities, relationships, and attributes clear and distinct names and definitions.

DATA NAMES We will provide specific guidelines for naming entities, relationships, and attributes as we develop the entity-relationship data model, but there are some general guidelines about naming any data object. Data names should (Salin, 1990):

• Relate to business, not technical (hardware or software), characteristics; so, Customer is a good name, but File10, Bit7, and Payroll Report Sort Key are not good names.

• Be meaningful, almost to the point of being self-documenting (i.e., the definition will refine and explain the name without having to state the essence of the object’s meaning); you should avoid using generic words such as has, is, person, or it.

• Be unique from the name used for every other distinct data object; words should be included in a data name if they distinguish the data object from other similar data objects (e.g., Home Address versus Campus Address).

• Be readable, so that the name is structured as the concept would most naturally be said (e.g., Grade Point Average is a good name, whereas Average Grade Rela- tive To A, although possibly accurate, is an awkward name).

• Be composed of words taken from an approved list; each organization often chooses a vocabulary from which significant words in data names must be chosen (e.g., maximum is preferred, never upper limit, ceiling, or highest); alternative, or alias names, also can be used as can approved abbreviations (e.g., CUST for CUSTOMER), and you may be encouraged to use the abbreviations so that data names are short enough to meet maximum length limits of database technology.

• Be repeatable, meaning that different people or the same person at different times should develop exactly or almost the same name; this often means that there is a standard hierarchy or pattern for names (e.g., the birth date of a student would be Student Birth Date and the birth date of an employee would be Employee Birth Date).

• Follow a standard syntax, meaning that the parts of the name should follow a standard arrangement adopted by the organization.

Salin (1990) suggests that you develop data names by:

1. Preparing a definition of the data. (We talk about definitions next.) 2. Removing insignificant or illegal words (words not on the approved list for

names); note that the presence of AND and OR in the definition may imply that

M02B_HOFF3359_13_GE_C02.indd 98 12/04/19 12:08 PM

2 • Modeling Data in the Organization 99

two or more data objects are combined, and you may want to separate the objects and assign different names.

3. Arranging the words in a meaningful, repeatable way. 4. Assigning a standard abbreviation for each word. 5. Determining whether the name already exists and, if so, adding other qualifiers

that make the name unique.

You will see examples of good data names as we develop a data modeling nota- tion in this chapter.

DATA DEFINITIONS A definition (sometimes called a structural assertion) is considered a type of business rule (GUIDE Business Rules Project, 1997). A definition is an expla- nation of a term or a fact. A term is a word or phrase that has a specific meaning for the business. Examples of terms are course, section, rental car, f light, reservation, and pas- senger. Terms are often the keywords used to form data names. Terms must be defined carefully and concisely. However, there is no need to define common terms such as day, month, person, or television, because these terms are understood without ambiguity by most persons.

A fact is an association between two or more terms. A fact is documented as a simple declarative statement that relates terms. Examples of facts that are definitions are the following (the defined terms are underlined):

• “A course is a module of instruction in a particular subject area.” This definition associates two terms: module of instruction and subject area. We assume that these are common terms that do not need to be further defined.

• “A customer may request a model of car from a rental branch on a particular date.” This fact, which is a definition of model rental request, associates the four underlined terms (GUIDE Business Rules Project, 1997). Three of these terms are business-specific terms that would need to be defined individually (date is a common term).

A fact statement places no constraints on instances of the fact. For example, it is inappropriate in the second fact statement to add that a customer may not request two different car models on the same date. Such constraints are separate business rules.

GOOD DATA DEFINITIONS We will illustrate good definitions for entities, relationships, and attributes as we develop the E-R notation in this and the next chapters. There are, however, some general guidelines to follow (Aranow, 1989):

• Definitions (and all other types of business rules) are gathered from the same sources as all requirements for information systems. Thus, systems and data ana- lysts should be looking for data objects and their definitions as these sources of information systems requirements are studied.

• Definitions will usually be accompanied by diagrams, such as E-R diagrams. The definition does not need to repeat what is shown on the diagram but rather sup- plement the diagram.

• Definitions will be stated in the singular and explain what the data element is, not what it is not. A definition will use commonly understood terms and abbrevia- tions and stand alone in its meaning and not embed other definitions within it. It should be concise and concentrate on the essential meaning of the data, but it may also state such characteristics of a data object as: • Subtleties. • Special or exceptional conditions. • Examples. • Where, when, and how the data are created or calculated in the organization. • Whether the data are static or change over time. • Whether the data are singular or plural in their atomic form. • Who determines the value for the data. • Who owns the data (i.e., who controls the definition and usage).

Term

A word or phrase that has a specific meaning for the business.

Fact

An association between two or more terms.

M02B_HOFF3359_13_GE_C02.indd 99 12/04/19 12:08 PM

100 Part II • Database Analysis and Logical Design

• Whether the data are optional or whether empty (what we will call null) values are allowed.

• Whether the data can be broken down into more atomic parts or are often com- bined with other data into some more composite or aggregate form.

If not included in a data definition, these characteristics need to be documented elsewhere, where other metadata are stored.

• A data object should not be added to a data model, such as an E-R diagram, until after it has been carefully defined (and named) and there is agreement on this definition. But expect the definition of the data to change once you place the object on the diagram because the process of developing a data model tests your understanding of the meaning of data. (In other words, modeling data is an iterative process.)

There is an unattributed phrase in data modeling that highlights the importance of good data definitions: “The person who controls the meaning of data controls the data.” It might seem that obtaining concurrence in an organization on the definitions to be used for the various terms and facts should be relatively easy. However, this is usu- ally far from the case. In fact, it is likely to be one of the most difficult challenges you will face in data modeling or, for that matter, in any other endeavor. It is not unusual for an organization to have multiple definitions (perhaps a dozen or more) for common terms such as customer or order.

To illustrate the problems inherent in developing definitions, consider a data object of Student found in a typical university. A sample definition for Student is “a per- son who has been admitted to the school and who has registered for at least one course during the past year.” This definition is certain to be challenged because it is probably too narrow. A person who is a student typically proceeds through several stages in rela- tionship with the school, such as the following:

1. Prospect—some formal contact, indicating an interest in the school. 2. Applicant—applies for admission. 3. Admitted applicant—admitted to the school and perhaps to a degree program. 4. Matriculated student—registers for at least one course. 5. Continuing student—registers for courses on an ongoing basis (no substantial

gaps). 6. Former student—fails to register for courses during some stipulated period (now

may reapply). 7. Graduate—satisfactorily completes some degree program (now may apply for

another program).

Imagine the difficulty of obtaining consensus on a single definition in this situa- tion! It would seem you might consider three alternatives:

1. Use multiple definitions to cover the various situations. This is likely to be highly confusing if there is only one entity type, so this approach is not recom- mended (multiple definitions are not good definitions). It might be possible to create multiple entity types, one for each student situation. However, because there is likely considerable similarity across the entity types, the fine distinctions between the entity types may be confusing, and the data model will show many constructs.

2. Use a very general definition that will cover most situations. This approach may necessitate adding additional data about students to record a given student’s actual status. For example, data for a student’s status, with values of prospect, applicant, and so forth, might be sufficient. On the other hand, if the same student could hold multiple statuses (e.g., prospect for one degree and matriculated for another degree), this might not work.

3. Consider using multiple, related data objects for Student. For example, we could create a general entity type for Student and then other specific entity types for kinds of students with unique characteristics. We describe the conditions that suggest this approach in Chapter 3.

M02B_HOFF3359_13_GE_C02.indd 100 12/04/19 12:08 PM

2 • Modeling Data in the Organization 101

MODELING ENTITIES AND ATTRIBUTES

The basic constructs of the E-R model are entities, relationships, and attributes. As shown in Figure 2-2, the model allows numerous variations for each of these constructs. The richness of the E-R model allows designers to model real-world situations accu- rately and expressively, which helps account for the popularity of the model.

Entities

An entity is a person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data. Thus, an entity has a singular noun name. Some examples of each of these kinds of entities follow:

Person: EMPLOYEE, STUDENT, PATIENT Place: STORE, WAREHOUSE, STATE Object: MACHINE, BUILDING, AUTOMOBILE Event: SALE, REGISTRATION, RENEWAL Concept: ACCOUNT, COURSE, WORK CENTER

ENTITY TYPE VERSUS ENTITY INSTANCE There is an important distinction between entity types and entity instances. An entity type is a collection of entities that share common properties or characteristics. Each entity type in an E-R model is given a name. Because the name represents a collection (or set) of items, it is always singular. We use capital letters for names of entity type(s). In an E-R diagram, the entity name is placed inside the box representing the entity type (see Figure 2-1).

An entity instance is a single occurrence of an entity type. Figure 2-3 illustrates the distinction between an entity type and two of its instances. An entity type is described just once (using metadata) in a database, whereas many instances of that entity type may be represented by data stored in the database. For example, there is one EMPLOYEE entity type in most organizations, but there may be hundreds (or even thousands) of instances of this entity type stored in the database. We often use the single term entity rather than entity instance when the meaning is clear from the context of our discussion.

ENTITY TYPE VERSUS SYSTEM INPUT, OUTPUT, OR USER A common mistake people make when they are learning to draw E-R diagrams, especially if they are already famil- iar with data process modeling (such as data flow diagramming), is to confuse data entities with other elements of an overall information systems model. A simple rule to avoid such confusion is that a true data entity will have many possible instances, each with a distinguishing characteristic, as well as one or more other descriptive pieces of data.

Entity

A person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data.

Entity type

A collection of entities that share common properties or characteristics.

Entity instance

A single occurrence of an entity type.

Entity type: EMPLOYEE

Attributes Attribute Data Type Example Instance Example Instance

Employee Number CHAR (10) 64217836 53410197

Name CHAR (25) Michelle Brady David Johnson

Address CHAR (30) 100 Pacific Avenue 450 Redwood Drive

City CHAR (20) San Francisco Redwood City

State CHAR (2) CA CA

Zip Code CHAR (9) 98173 97142

Date Hired DATE 03-21-1992 08-16-1994

Birth Date DATE 06-19-1968 09-04-1975

FIGURE 2-3 Entity type EMPLOYEE with two instances

M02B_HOFF3359_13_GE_C02.indd 101 12/04/19 12:08 PM

102 Part II • Database Analysis and Logical Design

Consider Figure 2-4a, which might be drawn to represent a database needed for a college sorority’s expense system. (For simplicity in this and some other figures, we show only one name for a relationship.) In this situation, the sorority treasurer manages accounts, receives expense reports, and records expense transactions against each account. However, do we need to keep track of data about the Treasurer (the TREASURER entity type) and her supervision of accounts (the Manages relationship) and receipt of reports (the Receives relationship)? The Treasurer is the person entering data about accounts and expenses and receiving expense reports. That is, she is a user of the database. Because there is only one Treasurer, TREASURER data do not need to be kept. Further, is the EXPENSE REPORT entity necessary? Because an expense report is computed from expense trans- actions and account balances, it is the result of extracting data from the database and received by the Treasurer. Even though there will be multiple instances of expense reports given to the Treasurer over time, data needed to compute the report contents each time are already represented by the ACCOUNT and EXPENSE entity types.

Another key to understanding why the ERD in Figure 2-4a might be in error is the nature of the relationship names, Receives and Summarizes. These relationship names refer to business activities that transfer or translate data, not to simply the association of one kind of data with another kind of data. The simple E-R diagram in Figure 2-4b shows entities and a relationship that would be sufficient to handle the sorority expense system as described here. See Problem and Exercise 2-43 for a variation on this situation.

STRONG VERSUS WEAK ENTITY TYPES Most of the basic entity types to identify in an organization are classified as strong entity types. A strong entity type is one that exists independently of other entity types. (Some data modeling software, in fact, use the term independent entity.) Examples include STUDENT, EMPLOYEE, AUTOMOBILE, and COURSE. Instances of a strong entity type always have a unique characteristic (called an identifier)—that is, an attribute or a combination of attributes that uniquely distin- guish each occurrence of that entity.

In contrast, a weak entity type is an entity type whose existence depends on some other entity type. (Some data modeling software, in fact, use the term dependent entity, and some data modeling tools make no distinction between strong and weak entities.) A weak entity type has no business meaning in an E-R diagram without the entity on which it depends. The entity type on which the weak entity type depends is called the identifying owner (or simply owner for short). A weak entity type does not typically

Strong entity type

An entity that exists independently of other entity types.

Weak entity type

An entity type whose existence depends on some other entity type.

Identifying owner

The entity type on which the weak entity type depends.

TREASURER

ACCOUNT

EXPENSE REPORT

Receives

Is Charged

SummarizesManages

EXPENSE

ACCOUNT EXPENSE Is Charged

FIGURE 2-4 Example of inappropriate entities

(a) System user (Treasurer) and output (Expense Report) shown

as entities

(b) E-R diagram with only the necessary entities

M02B_HOFF3359_13_GE_C02.indd 102 12/04/19 12:08 PM

2 • Modeling Data in the Organization 103

have its own identifier. Generally, on an E-R diagram, a weak entity type has an attribute that serves as a partial identifier. During a later design stage (described in Chapter 4), a full identifier will be formed for the weak entity by combining the partial identifier with the identifier of its owner or by representing the weak entity as a strong entity with a sur- rogate, nonintelligent identifier attribute and the partial identifier as a regular attribute of this entity.

An example of a weak entity type with an identifying relationship is shown in Figure 2-5. EMPLOYEE is a strong entity type with identifier Employee ID (we note the identifier attribute by underlining it). DEPENDENT is a weak entity type, as indi- cated by the double-lined rectangle. The relationship between a weak entity type and its owner is called an identifying relationship. In Figure 2-5, Carries is the identifying relationship (indicated by the double line). The attribute Dependent Name serves as a partial identifier of DEPENDENT. (Dependent Name is a composite attribute that can be broken into component parts, as we describe later.) We use a double underline to indi- cate a partial identifier. During a later design stage, Dependent Name will be combined with Employee ID (the identifier of the owner) to form a full identifier for DEPENDENT. Some additional examples of strong and weak entity pairs are BOOK–BOOK COPY, PRODUCT–SERIAL PRODUCT, and COURSE–COURSE OFFERING.

NAMING AND DEFINING ENTITY TYPES In addition to the general guidelines for nam- ing and defining data objects, there are a few special guidelines for naming entity types, which follow:

• An entity type name is a singular noun (such as CUSTOMER, STUDENT, or AUTOMOBILE); an entity is a person, a place, an object, an event, or a concept, and the name is for the entity type, which represents a set of entity instances (i.e., STUDENT represents students Hank Finley, Jean Krebs, and so forth). It is common to also specify the plural form (possibly in a CASE tool repository accompanying the E-R diagram) because sometimes the E-R diagram is read best by using plurals. For example, in Figure 2-1, we would say that a SUPPLIER may supply ITEMs. Because plurals are not always formed by adding an s to the singu- lar noun, it is best to document the exact plural form.

• An entity type name should be specific to the organization. Thus, one organization may use the entity type name CUSTOMER, and another organization may use the entity type name CLIENT (this is one task, e.g., done to customize a purchased data model). The name should be descriptive for everyone in the organization and distinct from all other entity type names within that organization. For exam- ple, a PURCHASE ORDER for orders placed with suppliers is distinct from a CUSTOMER ORDER for orders placed with a company by its customers. Both of these entity types cannot be named ORDER.

• An entity type name should be concise, using as few words as possible. For example, in a university database, an entity type REGISTRATION for the event of a student registering for a class is probably a sufficient name for this entity type; STUDENT REGISTRATION FOR CLASS, although precise, is probably too wordy because the reader will understand REGISTRATION from its use with other entity types.

Identifying relationship

The relationship between a weak entity type and its owner.

Carries

DEPENDENT Dependent Name (First Name, Middle Initial, Last Name) Date of Birth

EMPLOYEE Employee ID Employee Name

Weak Entity

Identifying Owner

Partial Identifier

Identifying Relationship

FIGURE 2-5 Example of a weak entity and its identifying relationship

M02B_HOFF3359_13_GE_C02.indd 103 12/04/19 12:08 PM

104 Part II • Database Analysis and Logical Design

• An abbreviation, or a short name, should be specified for each entity type name, and the abbreviation may be sufficient to use in the E-R diagram; abbreviations must follow all of the same rules as do the full entity names.

• Event entity types should be named for the result of the event, not the activity or process of the event. For example, the event of a project manager assigning an employee to work on a project results in an ASSIGNMENT, and the event of a student contacting his or her faculty adviser seeking some information is a CONTACT.

• The name used for the same entity type should be the same on all E-R diagrams on which the entity type appears. Thus, as well as being specific to the organization, the name used for an entity type should be a standard, adopted by the organization for all references to the same kind of data. However, some entity types will have aliases, or alternative names, which are synonyms used in different parts of the organization. For example, the entity type ITEM may have aliases of MATERIAL (for production) and DRAWING (for engineering). Aliases are specified in docu- mentation about the database, such as the repository of a CASE tool.

There are also some specific guidelines for defining entity types, which follow:

• An entity type definition usually starts with “An X is ….” This is the most direct and clear way to state the meaning of an entity type.

• An entity type definition should include a statement of what the unique characteristic is for each instance of the entity type. In many cases, stating the identifier for an entity type helps convey the meaning of the entity. An example for Figure 2-4b is “An expense is a payment for the purchase of some good or service. An expense is identified by a journal entry number.”

• An entity type definition should make it clear what entity instances are included and not included in the entity type; often, it is necessary to list the kinds of enti- ties that are excluded. For example, “A customer is a person or organization that has placed an order for a product from us or one that we have contacted to advertise or promote our products. A customer does not include persons or organizations that buy our products only through our customers, distributors, or agents.”

• An entity type definition often includes a description of when an instance of the entity type is created and deleted. For example, in the previous bullet point, a cus- tomer instance is implicitly created when the person or organization places its first order; because this definition does not specify otherwise, implicitly a cus- tomer instance is never deleted, or it is deleted based on general rules that are specified about the purging of data from the database. A statement about when to delete an entity instance is sometimes referred to as the retention of the entity type. A possible deletion statement for a customer entity type definition might be “A customer ceases to be a customer if it has not placed an order for more than three years.”

• For some entity types, the definition must specify when an instance might change into an instance of another entity type. For example, consider the situation of a construc- tion company for which bids accepted by potential customers become contracts. In this case, a bid might be defined by “A bid is a legal offer by our organization to do work for a customer. A bid is created when an officer of our company signs the bid document; a bid becomes an instance of contract when we receive a copy of the bid signed by an officer of the customer.” This definition is also a good example to note how one definition can use other entity type names (in this case, the definition of bid uses the entity type name CUSTOMER).

• For some entity types, the definition must specify what history is to be kept about instances of the entity type. For example, the characteristics of an ITEM in Figure 2-1 may change over time, and we may need to keep a complete history of the individual values and when they were in effect. As you will see in some exam- ples later, such statements about keeping history may have ramifications about how we represent the entity type on an E-R diagram and eventually how we store data for the entity instances.

M02B_HOFF3359_13_GE_C02.indd 104 12/04/19 12:08 PM

2 • Modeling Data in the Organization 105

Attributes

Each entity type has a set of attributes associated with it. An attribute is a property or characteristic of an entity type that is of interest to the organization. (Later, you will see that some types of relationships may also have attributes.) Thus, an attribute has a noun name. Following are some typical entity types and their associated attributes:

STUDENT Student ID, Student Name, Home Address, Phone Number, Major

AUTOMOBILE Vehicle ID, Color, Weight, Horsepower

EMPLOYEE Employee ID, Employee Name, Payroll Address, Skill

In naming attributes, we use an initial capital letter followed by lowercase letters. If an attribute name consists of more than one word, we use a space between the words and we start each word with a capital letter, for example, Employee Name or Student Home Address. In E-R diagrams, we represent an attribute by placing its name in the entity it describes. Attributes may also be associated with relationships, as described later. Note that an attribute is associated with exactly one entity or relationship.

Notice in Figure 2-5 that all of the attributes of DEPENDENT are characteristics only of an employee’s dependent, not characteristics of an employee. In traditional E-R notation, an entity type (not just weak entities but any entity) does not include attributes of entities to which it is related (what might be called foreign attributes). For example, DEPENDENT does not include any attribute that indicates to which employee this dependent is associated. This nonredundant feature of the E-R data model is consistent with the shared data property of databases. Because of relationships, which we discuss shortly, someone accessing data from a database will be able to associate attributes from related entities (e.g., show on a display screen a Dependent Name and the associated Employee Name).

REQUIRED VERSUS OPTIONAL ATTRIBUTES Each entity (or instance of an entity type) potentially has a value associated with each of the attributes of that entity type. An attri- bute that must be present for each entity instance is called a required attribute, whereas an attribute that may not have a value is called an optional attribute. For example, Figure 2-6 shows two STUDENT entities (instances) with their respective attribute val- ues. The only optional attribute for STUDENT is Major. (Some students, specifically Melissa Kraft in this example, have not chosen a major yet; MIS would, of course, be a great career choice!) However, every student must, by the rules of the organization, have values for all the other attributes; that is, we cannot store any data about a student in a STUDENT entity instance unless there are values for all the required attributes. In various E-R diagramming notations, a symbol might appear in front of each attribute to indicate whether it is required (e.g., *) or optional (e.g., o), or required attributes will be in bold- face, whereas optional attributes will be in normal font (the format we use in this text); in many cases, required or optional is indicated within supplemental documentation.

Attribute

A property or characteristic of an entity or relationship type that is of interest to the organization.

Required attribute

An attribute that must have a value for every entity (or relationship) instance with which it is associated.

Optional attribute

An attribute that may not have a value for every entity (or relationship) instance with which it is associated.

Entity type: STUDENT

Attributes Attribute Data Type

Required or Optional

Example Instance Example Instance

Student ID CHAR (10) Required 28-618411 26-844576

Student Name CHAR (40) Required Michael Grant Melissa Kraft

Home Address CHAR (30) Required 314 Baker St. 1422 Heft Ave

Home City CHAR (20) Required Centerville Miami

Home State CHAR (2) Required OH FL

Home Zip Code CHAR (9) Required 45459 33321

Major CHAR (3) Optional MIS

FIGURE 2-6 Entity type STUDENT with required and optional attributes

M02B_HOFF3359_13_GE_C02.indd 105 12/04/19 12:08 PM

106 Part II • Database Analysis and Logical Design

In Chapter 3, when you study entity supertypes and subtypes, you will see how some- times optional attributes imply that there are different types of entities. (For example, we may want to consider students who have not declared a major as a subtype of the STUDENT entity type.) An attribute without a value is said to be null. Thus, each entity has an identifying attribute, which we discuss in a subsequent section, plus one or more other attributes. If you try to create an entity that has only an identifier, that entity is likely not legitimate. Such a data structure may simply hold a list of legal values for some attribute, which is better kept outside the database.

SIMPLE VERSUS COMPOSITE ATTRIBUTES Some attributes can be broken down into meaningful component parts (detailed attributes). A common example is Name, which you saw in Figure 2-5; another is Address, which can usually be broken down into the following component attributes: Street Address, City, State, and Postal Code. A com- posite attribute is an attribute, such as Address, that has meaningful component parts, which are more detailed attributes. Figure 2-7 shows the notation that we use for com- posite attributes applied to this example. Most drawing tools do not have a notation for composite attributes, so you simply list all the component parts.

Composite attributes provide considerable flexibility to users, who can either refer to the composite attribute as a single unit or else refer to individual components of that attribute. Thus, for example, a user can either refer to Address or refer to one of its components, such as Street Address. The decision about whether to subdivide an attribute into its component parts depends on whether users will need to refer to those individual components, and hence, they have organizational meaning. Of course, you must always attempt to anticipate possible future usage patterns for the database.

A simple (or atomic) attribute is an attribute that cannot be broken down into smaller components that are meaningful for the organization. For example, all the attributes associated with AUTOMOBILE are simple: Vehicle ID, Color, Weight, and Horsepower.

SINGLE-VALUED VERSUS MULTIVALUED ATTRIBUTES Figure 2-6 shows two entity instances with their respective attribute values. For each entity instance, each of the attributes in the figure has one value. It frequently happens that there is an attribute that may have more than one value for a given instance. For example, the EMPLOYEE entity type in Figure 2-8 has an attribute named Skill, whose values record the skill

Composite attribute

An attribute that has meaningful component parts (attributes).

Simple (or atomic) attribute

An attribute that cannot be broken down into smaller components that are meaningful to the organization.

EMPLOYEE . . . Employee Address (Street Address, City, State, Postal Code) . . .

Composite Attribute

Component Attributes

FIGURE 2-7 A composite attribute

FIGURE 2-8 Entity with multivalued attribute (Skill) and derived attribute (Years Employed)

EMPLOYEE Employee ID Employee Name(. . .) Payroll Address(. . .) Date Employed {Skill} [Years Employed]

Derived Attribute

Multivalued Attribute

M02B_HOFF3359_13_GE_C02.indd 106 12/04/19 12:08 PM

2 • Modeling Data in the Organization 107

(or skills) for that employee. Of course, some employees may have more than one skill, such as PHP Programmer and C++ Programmer. A multivalued attribute is an attribute that may take on more than one value for a given entity (or relationship) instance. In this text, we indicate a multivalued attribute with curly brackets around the attribute name, as shown for the Skill attribute in the EMPLOYEE example in Figure 2-8. In Microsoft Visio, once an attribute is placed in an entity, you can edit that attribute (column), select the Collection tab, and choose one of the options. (Typically, MultiSet will be your choice, but one of the other options may be more appropriate for a given situation.) Other E-R diagramming tools may use an asterisk (*) after the attribute name, or you may have to use supplemental documentation to specify a multivalued attribute.

Multivalued and composite are different concepts, although beginner data model- ers often confuse these terms. Skill, a multivalued attribute, may occur multiple times for each employee; Employee Name and Payroll Address are both likely composite attributes, each of which occurs once for each employee but which have component, more atomic attributes that are not shown in Figure 2-8 for simplicity. It is possible to have a multivalued composite attribute. For example, a Customer Address composite attribute may have a variable number of values for a given customer (home, office, seasonal, etc.). See Problem and Exercise 2-38 to review the concepts of composite and multivalued attributes.

STORED VERSUS DERIVED ATTRIBUTES Some attribute values that are of interest to users can be calculated or derived from other related attribute values that are stored in the database. When users want to use such derived values in calculations and displays, it is likely helpful for them to show these derived attributes in an E-R diagram. For example, suppose for an organization, the EMPLOYEE entity type has a Date Employed attribute. If users need to know how many years a person has been employed, that value can be calculated using Date Employed and today’s date. A derived attribute is an attri- bute whose values can be calculated from related attribute values (plus possibly data not in the database, such as today’s date, the current time, or a security code provided by a system user). We indicate a derived attribute in an E-R diagram by using square brackets around the attribute name, as shown in Figure 2-8 for the Years Employed attribute. Some E-R diagramming tools use a notation of a forward slash (/) in front of the attribute name to indicate that it is derived. (This notation is borrowed from UML for a virtual attribute.) The method for calculating the derived attribute may be stored with the description of the associated entity (or relationship), and this method may be either coded into the physical database definition or programmed into application programs based on the one method description associated with the E-R diagram and database documentation.

In some situations, the value of an attribute can be derived from attributes in related entities. For example, consider an invoice created for each customer at Pine Val- ley Furniture Company. Order Total would be an attribute of the INVOICE entity, which indicates the total dollar amount that is billed to the customer. The value of Order Total can be computed by summing the Extended Price values (unit price times quantity sold) for the various line items that are billed on the invoice. Formulas for computing values such as this are one type of business rule.

IDENTIFIER ATTRIBUTE An identifier is an attribute (or combination of attributes) whose value distinguishes individual instances of an entity type. That is, no two instances of the entity type may have the same value for the identifier attribute. The identifier for the STUDENT entity type introduced earlier is Student ID, whereas the identifier for AUTOMOBILE is Vehicle ID. Notice that an attribute such as Student Name is not a candidate identifier because many students may potentially have the same name and students, like all people, can change their names. To be a candidate identifier, each entity instance must have a single value for the attribute, and the attri- bute must be associated with the entity. We underline identifier names on the E-R dia- gram, as shown in the STUDENT entity type example in Figure 2-9a. To be an identifier, the attribute is also required (so the distinguishing value must exist), so an identifier

Multivalued attribute

An attribute that may take on more than one value for a given entity (or relationship) instance.

Derived attribute

An attribute whose values can be calculated from related attribute values.

Identifier

An attribute (or combination of attributes) whose value distinguishes instances of an entity type.

M02B_HOFF3359_13_GE_C02.indd 107 12/04/19 12:08 PM

108 Part II • Database Analysis and Logical Design

is also in bold. Some E-R drawing software will place a symbol, called a stereotype, in front of the identifier (e.g., <<ID>> or <<PK>>).

For some entity types, there is no single (or atomic) attribute that can serve as the identifier (i.e., that will ensure uniqueness). However, two (or more) attributes used in combination may serve as the identifier. A composite identifier is an identifier that con- sists of a composite attribute. Figure 2-9b shows the entity FLIGHT with the composite identifier Flight ID. Flight ID in turn has component attributes Flight Number and Date. This combination is required to identify uniquely individual occurrences of FLIGHT.

We use the convention that the composite attribute (Flight ID) is underlined to indicate it is the identifier, whereas the component attributes are not underlined. Some data modelers think of a composite identifier as “breaking a tie” created by a simple identifier. Even with Flight ID, a data modeler would ask a question, such as “Can two flights with the same number occur on the same date?” If so, yet another attribute is needed to form the composite identifier and to break the tie.

Some entities may have more than one candidate identifier. If there is more than one candidate identifier, the designer must choose one of them as the identifier. Bruce (1992) suggests the following criteria for selecting identifiers:

1. Choose an identifier that will not change its value over the life of each instance of the entity type. For example, the combination of Employee Name and Payroll Address (even if unique) would be a poor choice as an identifier for EMPLOYEE because the values of Employee Name and Payroll Address could easily change during an employee’s term of employment.

2. Choose an identifier such that for each instance of the entity, the attribute is guar- anteed to have valid values and not be null (or unknown). If the identifier is a composite attribute, such as Flight ID in Figure 2-9b, make sure that all parts of the identifier will have valid values.

3. Avoid the use of so-called intelligent identifiers (or keys), whose structure indicates classifications, locations, and so on. For example, the first two digits of an identi- fier value may indicate the warehouse location. Such codes are often changed as conditions change, which renders the identifier values invalid.

4. Consider substituting single-attribute surrogate identifiers for large composite identifiers. For example, an attribute called Game Number could be used for the entity type GAME instead of the combination of Home Team and Visiting Team.

NAMING AND DEFINING ATTRIBUTES In addition to the general guidelines for naming data objects, there are a few special guidelines for naming attributes, which follow:

• An attribute name is a singular noun or noun phrase (such as Customer ID, Age, Product Minimum Price, or Major). Attributes, which materialize as data values,

Composite identifier

An identifier that consists of a composite attribute.

FIGURE 2-9 Simple and composite identifier attributes

(a) Simple identifier attribute

(b) Composite identifier attribute

STUDENT Student ID Student Name(. . .) . . .

Identifier and Required

Flight ID (Flight Number, Date) Number Of Passengers . . .

FLIGHT

Composite Identifier

M02B_HOFF3359_13_GE_C02.indd 108 12/04/19 12:08 PM

2 • Modeling Data in the Organization 109

are concepts or physical characteristics of entities. Concepts and physical charac- teristics are described by nouns.

• An attribute name should be unique. No two attributes of the same entity type may have the same name, and it is desirable, for clarity purposes, that no two attributes across all entity types have the same name.

• To make an attribute name unique and for clarity purposes, each attribute name should follow a standard format. For example, your university may establish Student GPA, as opposed to GPA of Student, as an example of the standard format for attribute naming. The format to be used will be established by each organization. A common format is [Entity type name { [ Qualifier ] } ] Class, where [ . . . ] is an optional clause, and { . . . } indicates that the clause may repeat. Entity type name is the name of the entity with which the attribute is associated. The entity type name may be used to make the attribute name explicit. It is almost always used for the identifier attribute (e.g., Customer ID) of each entity type. Class is a phrase from a list of phrases defined by the organization that are the permis- sible characteristics or properties of entities (or abbreviations of these character- istics). For example, permissible values (and associated approved abbreviations) for Class might be Name (Nm), Identifier (ID), Date (Dt), or Amount (Amt). Class is, obviously, required. Qualifier is a phrase from a list of phrases defined by the organization that are used to place constraints on classes. One or more qualifiers may be needed to make each attribute of an entity type unique. For example, a qualifier might be Maximum (Max), Hourly (Hrly), or State (St). A qualifier may not be necessary: Employee Age and Student Major are both fully explicit attri- bute names. Sometimes a qualifier is necessary. For example, Employee Birth Date and Employee Hire Date are two attributes of Employee that require one qualifier. More than one qualifier may be necessary. For example, Employee Residence City Name (or Emp Res Cty Nm) is the name of an employee’s city of residence, and Employee Tax City Name (or Emp Tax Cty Nm) is the name of the city in which an employee pays city taxes.

• Similar attributes of different entity types should use the same qualifiers and classes, as long as those are the names used in the organization. For example, the city of residence for faculty and students should be, respectively, Faculty Residence City Name and Student Residence City Name. Using similar names makes it easier for users to understand that values for these attributes come from the same possible set of values, what we will call domains. Users may want to take advantage of common domains in queries (e.g., find students who live in the same city as their adviser), and it will be easier for users to recognize that such a matching may be possible if the same qualifier and class phrases are used.

There are also some specific guidelines for defining attributes, which follow:

• An attribute definition states what the attribute is and possibly why it is important. The definition will often parallel the attribute’s name; for example, Student Resi- dence City Name could be defined as “The name of the city in which a student maintains his or her permanent residence.”

• An attribute definition should make it clear what is included and not included in the attribute’s value; for example, “Employee Monthly Salary Amount is the amount of money paid each month in the currency of the country of residence of the employee, exclusive of any benefits, bonuses, reimbursements, or special payments.”

• Any aliases, or alternative names, for the attribute can be specified in the defini- tion or may be included elsewhere in documentation about the attribute, possibly stored in the repository of a CASE tool used to maintain data definitions.

• It may also be desirable to state in the definition the source of values for the attri- bute. Stating the source may make the meaning of the data clearer. For example, “Customer Standard Industrial Code is an indication of the type of business for the customer. Values for this code come from a standard set of values provided by the Federal Trade Commission and are found on a CD we purchase named SIC provided annually by the FTC.”

M02B_HOFF3359_13_GE_C02.indd 109 12/04/19 12:08 PM

110 Part II • Database Analysis and Logical Design

• An attribute definition (or other specification in a CASE tool repository) also should indicate if a value for the attribute is required or optional. This business rule about an attribute is important for maintaining data integrity. The identifier attri- bute of an entity type is, by definition, required. If an attribute value is required, then to create an instance of the entity type, a value of this attribute must be pro- vided. Required means that an entity instance must always have a value for this attribute, not just when an instance is created. Optional means that a value may not exist for an instance of an entity instance to be stored. Optional can be further qualified by stating whether once a value is entered, a value must always exist. For example, “Employee Department ID is the identifier of the department to which the employee is assigned. An employee may not be assigned to a department when hired (so this attribute is initially optional), but once an employee is assigned to a department, the employee must always be assigned to some department.”

• An attribute definition (or other specification in a CASE tool repository) may also indicate whether a value for the attribute may change once a value is provided and before the entity instance is deleted. This business rule also controls data integrity. Nonintelligent identifiers may not change values over time. To assign a new non- intelligent identifier to an entity instance, that instance must first be deleted and then re-created.

• For a multivalued attribute, the attribute definition should indicate the maximum and minimum number of occurrences of an attribute value for an entity instance. For example, “Employee Skill Name is the name of a skill an employee possesses. Each employee must possess at least one skill, and an employee can choose to list at most 10 skills.” The reason for a multivalued attribute may be that a history of the attribute needs to be kept. For example, “Employee Yearly Absent Days Num- ber is the number of days in a calendar year the employee has been absent from work. An employee is considered absent if he or she works less than 50 percent of the scheduled hours in the day. A value for this attribute should be kept for each year in which the employee works for our company.”

• An attribute definition may also indicate any relationships that attribute has with other attributes. For example, “Employee Vacation Days Number is the number of days of paid vacation for the employee. If the employee has a value of ‘Exempt’ for Employee Type, then the maximum value for Employee Vacation Days Number is determined by a formula involving the number of years of service for the employee.”

MODELING RELATIONSHIPS

Relationships are the glue that holds together the various components of an E-R model. Intuitively, a relationship is an association representing an interaction among the instances of one or more entity types that is of interest to the organization. Thus, a relationship has a verb phrase name. Relationships and their characteristics (degree and cardinality) represent business rules, and usually relationships represent the most complex business rules shown in an ERD. In other words, this is where data modeling gets really interest- ing and fun, as well as crucial for controlling the integrity of a database. Relationships are essential for almost every meaningful use of a database; for example, relationships allow iTunes to find the music you’ve purchased, your cell phone company to find all the text messages in one of your SMS threads, or the campus nurse to see how different students have reacted to different treatments to the latest influenza on campus. So, fun and essential—modeling relationships will be a rewarding skill for you.

To understand relationships more clearly, we must distinguish between relation- ship types and relationship instances. To illustrate, consider the entity types EMPLOYEE and COURSE, where COURSE represents training courses that may be taken by employ- ees. To track courses that have been completed by particular employees, you would define a relationship called Completes between the two entity types (see Figure 2-10a). This is a many-to-many relationship because each employee may complete any number of courses (zero, one, or many courses), whereas a given course may be completed by any number of employees (nobody, one employee, or many employees). For example, in Figure 2-10b, the employee Melton has completed three courses (C++, COBOL, and

M02B_HOFF3359_13_GE_C02.indd 110 12/04/19 12:08 PM

2 • Modeling Data in the Organization 111

Perl). The SQL course has been completed by two employees (Celko and Gosling), and the Visual Basic course has not been completed by anyone.

In this example, there are two entity types (EMPLOYEE and COURSE) that par- ticipate in the relationship named Completes. In general, any number of entity types (from one to many) may participate in a relationship.

We frequently use in this and subsequent chapters the convention of a single verb phrase label to represent a relationship. Because relationships often occur due to an orga- nizational event, entity instances are related because an action was taken; thus, a verb phrase is appropriate for the label. This verb phrase should be in the present tense and descriptive. There are, however, many ways to represent a relationship. Some data mod- elers prefer the format with two relationship names, one to name the relationship in each direction. One or two verb phrases have the same structural meaning, so you may use either format as long as the meaning of the relationship in each direction is clear.

Basic Concepts and Definitions in Relationships

A relationship type is a meaningful association between (or among) entity types. The phrase meaningful association implies that the relationship allows us to answer ques- tions that could not be answered given only the entity types. A relationship type is denoted by a line labeled with the name of the relationship, as in the example shown in Figure 2-10a, or with two names, as in Figure 2-1. We suggest you use a short, descrip- tive verb phrase that is meaningful to the user in naming the relationship. (We say more about naming and defining relationships later in this section.)

A relationship instance is an association between (or among) entity instances, where each relationship instance associates exactly one entity instance from each par- ticipating entity type (Elmasri and Navathe, 1994). For example, in Figure 2-10b, each of the 10 lines in the figure represents a relationship instance between one employee and

Relationship type

A meaningful association between (or among) entity types.

Relationship instance

An association between (or among) entity instances where each relationship instance associates exactly one entity instance from each participating entity type.

FIGURE 2-10 Relationship type and instances

(a) Relationship type (Completes)

(b) Relationship instances

Completes EMPLOYEE

Employee ID Employee Name(. . .) Birth Date

COURSE Course ID Course Title {Topic}

manymany

C++

Java

COBOL

Perl

SQL

Chen

Melton

Ritchie

Celko

Gosling

Employee Completes Course

Visual Basic

Each line represents an instance (10 in all) of the

Completes relationship type

M02B_HOFF3359_13_GE_C02.indd 111 12/04/19 12:08 PM

112 Part II • Database Analysis and Logical Design

one course, indicating that the employee has completed that course. For example, the line between Employee Ritchie and Course Perl is one relationship instance.

ATTRIBUTES ON RELATIONSHIPS It is probably obvious to you that entities have attri- butes, but attributes may be associated with a many-to-many (or one-to-one) relation- ship, too. For example, suppose the organization wishes to record the date (month and year) when an employee completes each course. This attribute is named Date Completed. For some sample data, see Table 2-2.

Where should the attribute Date Completed be placed on the E-R diagram? Refer- ring to Figure 2-10a, you will notice that Date Completed has not been associated with either the EMPLOYEE or the COURSE entity. That is because Date Completed is a prop- erty of the relationship Completes rather than a property of either entity. In other words, for each instance of the relationship Completes, there is a value for Date Completed. One such instance, for example, shows that the employee named Melton completed the course titled C++ in 06/2017.

A revised version of the ERD for this example is shown in Figure 2-11a. In this diagram, the attribute Date Completed is in a rectangle connected to the Completes relationship line. Other attributes might be added to this relationship if appropriate, such as Course Grade, Instructor, and Room Location. We will explain the A and B annotations below.

It is interesting to note that an attribute cannot be associated with a one-to-many relationship, such as Carries in Figure 2-5. For example, consider Dependent Date, simi- lar to Date Completed above, for when the DEPENDENT begins to be carried by the EMPLOYEE. Because each DEPENDENT is associated with only one EMPLOYEE, such a date is unambiguously a characteristic of the DEPENDENT (i.e., for a given DEPEN- DENT, Dependent Date cannot vary by EMPLOYEE). So, if you ever have the urge to associate an attribute with a one-to-many relationship, “step away from the relationship!”

ASSOCIATIVE ENTITIES The presence of one or more attributes on a relationship sug- gests to the designer that the relationship should perhaps instead be represented as an entity type. To emphasize this point, most E-R drawing tools require that such attri- butes be placed in an entity type. An associative entity is 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. The associative entity CERTIFICATE is rep- resented with the rectangle with rounded corners, as shown in Figure 2-11b. Most E-R drawing tools do not have a special symbol for an associative entity. Associative entities are sometimes referred to as gerunds because the relationship name (a verb) is usu- ally converted to an entity name that is a noun. Note in Figure 2-11b that there are no relationship names on the lines between an associative entity and a strong entity. This is because the associative entity represents the relationship. Figure 2-11c shows how associative entities are drawn using Microsoft Visio, which is representative of how you

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.

TABLE 2-2 Instances Showing Date Completed

Employee Name Course Title Date Completed

Chen C++ 06/2017

Chen Java 09/2017

Melton C++ 06/2017

Melton COBOL 02/2018

Melton SQL 03/2017

Ritchie Perl 11/2017

Celko Java 03/2017

Celko SQL 03/2018

Gosling Java 09/2017

Gosling Perl 06/2017

M02B_HOFF3359_13_GE_C02.indd 112 12/04/19 12:08 PM

2 • Modeling Data in the Organization 113

would draw an associative entity with most E-R diagramming tools. In Visio, the rela- tionship lines are dashed because CERTIFICATE does not include the identifiers of the related entities in its identifier. (Certificate Number is sufficient.)

How do you know whether to convert a relationship to an associative entity type? Following are four conditions that should exist:

1. All the relationships for the participating entity types are “many” relationships. 2. The resulting associative entity type has independent meaning to end users and,

preferably, can be identified with a single-attribute identifier. 3. The associative entity has one or more attributes in addition to the identifier. 4. The associative entity participates in one or more relationships independent of the

entities related in the associated relationship.

Figure 2-11b shows the relationship Completes converted to an associative entity type. In this case, the training department for the company has decided to award a cer- tificate to each employee who completes a course. Thus, the entity is named CERTIFI- CATE, which certainly has independent meaning to end users. Also, each certificate has a number (Certificate Number) that serves as the identifier.

The attribute Date Completed is also included. Note also in Figure 2-11b and the Visio version of Figure 2-11c that both EMPLOYEE and COURSE are mandatory participants in the two relationships with CERTIFICATE. This is exactly what occurs when you have to represent a many-to-many relationship (Completes in Figure 2-11a) as two one-to-many relationships (the ones associated with CERTIFICATE in Figures 2-11b and 2-11c).

Notice that converting a relationship to an associative entity has caused the rela- tionship notation to move. That is, the “many” cardinality now terminates at the associa- tive entity rather than at each participating entity type. In Figure 2-11, this shows that an employee, who may complete one or more courses (notation A in Figure 2-11a), may be awarded more than one certificate (notation A in Figure 2-11b) and that a course, which may have one or more employees complete it (notation B in Figure 2-11a), may have

B A EMPLOYEE

Completes

Employee ID Employee Name(. . .) Birth Date

COURSE Course ID Course Title {Topic}

Date Completed

FIGURE 2-11 An associative entity

(a) Attribute on a relationship

(b) An associative entity (CERTIFICATE)

(c) An associative entity using Microsoft VISIO

A BEMPLOYEE Employee ID Employee Name(. . .) Birth Date

COURSE Course ID Course Title {Topic}

Certificate Number Date Completed

CERTIFICATE

Employee IDPK

Employee Name

EMPLOYEE

Certificate NumberPK

Date Completed

CERTIFICATE

Course IDPK

Course Title

COURSE

M02B_HOFF3359_13_GE_C02.indd 113 12/04/19 12:08 PM

114 Part II • Database Analysis and Logical Design

many certificates awarded (notation B in Figure 2-11b). See Problem and Exercise 2-42 for an interesting variation on Figure 2-11a, which emphasizes the rules for when to convert a many-to-many relationship, such as Completes, into an associative entity.

Degree of a Relationship

The degree of a relationship is the number of entity types that participate in that relation- ship. Thus, the relationship Completes in Figure 2-11 is of degree 2 because there are two entity types: EMPLOYEE and COURSE. The three most common relationship degrees in E-R models are unary (degree 1), binary (degree 2), and ternary (degree 3). Higher-degree relationships are possible, but they are rarely encountered in practice, so we restrict our discussion to these three cases. Examples of unary, binary, and ternary relationships appear in Figure 2-12. (Attributes are not shown in some figures for simplicity.)

Degree

The number of entity types that participate in a relationship.

EMPLOYEE PARKING

SPACE

STUDENT COURSE

PRODUCT LINE

PRODUCT

One-to-one

Many-to-many

One-to-many

Is Assigned

Registers For

Contains

FIGURE 2-12 Examples of relationships of different degrees

(a) Unary relationships

(b) Binary relationships

PERSON

One-to-one One-to-many One-to-one

Is Married To Manages Stands After

EMPLOYEE TEAM

VENDOR

PART

WAREHOUSE Supplies

Shipping Mode Unit Cost

For example, an instance is Vendor X Supplies Part C to

Warehouse Y with a Shipping Mode of "next-day air"

and a Unit Cost of $5

(c) Ternary relationship

M02B_HOFF3359_13_GE_C02.indd 114 12/04/19 12:08 PM

2 • Modeling Data in the Organization 115

As you look at Figure 2-12, understand that any particular data model represents a specific situation, not a generalization. For example, consider the Manages relationship in Figure 2-12a. In some organizations, it may be possible for one employee to be man- aged by many other employees (e.g., in a matrix organization). It is important when you develop an E-R model that you understand the business rules of the particular organization you are modeling.

UNARY RELATIONSHIP A unary relationship is a relationship between the instances of a single entity type. (Unary relationships are also called recursive relationships.) Three examples are shown in Figure 2-12a. In the first example, Is Married To is shown as a one-to-one relationship between instances of the PERSON entity type. Because this is a one-to-one relationship, this notation indicates that only the current marriage, if one exists, needs to be kept about a person. What would change if we needed to retain the history of marriages for each person? See Review Question 2-20 and Problem and Exercise 2-34 for other business rules and their effect on the Is Married To relation- ship representation. In the second example, Manages is shown as a one-to-many rela- tionship between instances of the EMPLOYEE entity type. Using this relationship, you could identify, for example, the employees who report to a particular manager. The third example is one case of using a unary relationship to represent a sequence, cycle, or priority list. In this example, sports teams are related by their standing in their league (the Stands After relationship). (Note: In these examples, we ignore whether these are mandatory- or optional-cardinality relationships or whether the same entity instance can repeat in the same relationship instance; we will introduce mandatory and optional cardinality in a later section of this chapter.)

Figure 2-13 shows an example of another unary relationship, called a bill-of- materials structure. Many manufactured products are made of assemblies, which in turn are composed of subassemblies and parts and so on. As shown in Figure 2-13a,

Unary relationship

A relationship between instances of a single entity type.

FIGURE 2-13 Representing a bill-of-materials structure

(a) Many-to-many relationship

Quantity

Has Components

ITEM

(b) Two ITEM bill-of-materials structure instances

Mountain Bike MX300

Transmission System TX100

Qty: 1

Handle Bars HX100 Qty: 1

Brakes BR450 Qty: 2

Wheels WX240 Qty: 2

Derailer DX500 Qty: 1

Tandem Bike TR425

Transmission System TX101

Handle Bars HT200 Qty: 2

Derailer DX500 Qty: 1

Wheels WX340 Qty: 2

Brakes BR250 Qty: 2

Wheels WX240 Qty: 2

Wheel Trim WT100 Qty: 2

M02B_HOFF3359_13_GE_C02.indd 115 12/04/19 12:08 PM

116 Part II • Database Analysis and Logical Design

we can represent this structure as a many-to-many unary relationship. In this figure, the entity type ITEM is used to represent all types of components, and we use Has Components for the name of the relationship type that associates lower-level items with higher-level items.

Two occurrences of this bill-of-materials structure are shown in Figure 2-13b. Each of these diagrams shows the immediate components of each item as well as the quantities of that component. For example, item TX100 consists of item BR450 (quantity 2) and item DX500 (quantity 1). You can easily verify that the associations are in fact many-to-many. Several of the items have more than one component type (e.g., item MX300 has three immediate component types: HX100, TX100, and WX240). Also, some of the components are used in several higher-level assemblies. For example, item WX240 is used in both item MX300 and item WX340, even at different levels of the bill- of-materials. The many-to-many relationship guarantees that, for example, the same subassembly structure of WX240 (not shown) is used each time item WX240 goes into making some other item.

The presence of the attribute Quantity on the relationship suggests that the analyst consider converting the relationship Has Components to an associative entity. Figure 2-13c shows the entity type BOM STRUCTURE, which forms an association between instances of the ITEM entity type. A second (partial identifier) attribute (named Effective Date) has been added to BOM STRUCTURE to record the date when the speci- fied quantity of this component was first used in the related assembly. Effective dates are often needed when a history of values is required. In practice, the identifiers of the component and assembly items along with Effective Date often become nonidentifier attributes, and a surrogate, nonintelligent identifier is used. Other data model struc- tures can be used for unary relationships involving such hierarchies; we show some of these other structures in Chapter 9.

BINARY RELATIONSHIP A binary relationship is a relationship between the instances of two entity types and is the most common type of relationship encountered in data modeling. Figure 2-12b shows three examples. The first (one-to-one) indicates that an employee is assigned one parking place and that each parking place is assigned to one employee (at a given time). The second (one-to-many) indicates that a product line may contain several products and that each product belongs to only one product line. The third (many-to-many) shows that a student may register for more than one course and that each course may have many student registrants.

TERNARY RELATIONSHIP A ternary relationship is a simultaneous relationship among the instances of three entity types. A typical business situation that leads to a ternary relationship is shown in Figure 2-12c. In this example, vendors can supply various parts to warehouses. The relationship Supplies is used to record the specific parts that are supplied by a given vendor to a particular warehouse. Thus, there are three entity types involved: VENDOR, PART, and WAREHOUSE. There are two attributes on the relation- ship Supplies: Shipping Mode and Unit Cost. For example, one instance of Supplies might record the fact that vendor X can ship part C to warehouse Y, that the shipping mode is next-day air, and that the cost is $5 per unit.

Binary relationship

A relationship between the instances of two entity types.

Ternary relationship

A simultaneous relationship among the instances of three entity types.

ITEM

Has Components

Used In Assemblies

BOM STRUCTURE E�ective Date Quantity

(c) Associative entity

FIGURE 2-13 (continued)

M02B_HOFF3359_13_GE_C02.indd 116 12/04/19 12:08 PM

2 • Modeling Data in the Organization 117

Don’t be confused: A ternary relationship is not the same as three binary relation- ships. For example, Unit Cost is an attribute of the Supplies relationship in Figure 2-12c. Unit Cost cannot be properly associated with any one of the three possible binary rela- tionships among the three entity types, such as that between PART and WAREHOUSE. Thus, for example, if we were told that vendor X can ship part C for a unit cost of $8, those data would be incomplete because they would not indicate to which warehouse the parts would be shipped.

As usual, the presence of an attribute on the relationship Supplies in Figure 2-12c suggests converting the relationship to an associative entity type. Figure 2-14 shows an alternative (and preferable) representation of the ternary relationship shown in Figure 2-12c. In Figure 2-14, the (associative) entity type SUPPLY SCHEDULE is used to replace the Supplies relationship from Figure 2-12c. Clearly, the entity type SUPPLY SCHEDULE is of independent interest to users. However, notice that an identifier has not yet been assigned to SUPPLY SCHEDULE. This is acceptable. If no identifier is assigned to an associative entity during E-R modeling, an identifier (or key) will be assigned during logical modeling (discussed in Chapter 4). This will be a composite identifier whose components will consist of the identifier for each of the participating entity types (in this example, PART, VENDOR, and WAREHOUSE) or a surrogate, non- intelligent identifier. Can you think of other attributes that might be associated with SUPPLY SCHEDULE?

As noted earlier, we do not label the lines from SUPPLY SCHEDULE to the three entities. This is because these lines do not represent binary relationships. To keep the same meaning as the ternary relationship of Figure 2-12c, we cannot break the Supplies relationship into three binary relationships, as we have already mentioned.

So, here is a guideline to follow: Convert all ternary (or higher) relationships to associative entities, as in this example. Song et al. (1995) show that participation con- straints (described in a following section on cardinality constraints) cannot be accu- rately represented for a ternary relationship, given the notation with attributes on the relationship line. However, by converting to an associative entity, the constraints can be accurately represented. Also, many E-R diagram drawing tools, including most CASE tools, cannot represent ternary relationships. So, although not semantically accurate, you must use these tools to represent the ternary or higher-order relationship with an associative entity and three binary relationships, which have a mandatory association with each of the three related entity types.

Attributes or Entity?

Sometimes you will wonder if you should represent data as an attribute or an entity; this is a common dilemma. Figure 2-15 includes three examples of situations when an attribute could be represented via an entity type. We use this text’s E-R notation in the left column and the notation from Microsoft Visio in the right column; it is

PART

VENDOR SUPPLY SCHEDULE Shipping Mode Unit Cost

WAREHOUSE

FIGURE 2-14 Ternary relationship as an associative entity

M02B_HOFF3359_13_GE_C02.indd 117 12/04/19 12:08 PM

118 Part II • Database Analysis and Logical Design

important that you learn how to read ERDs in several notations because you will encounter various styles in different publications and organizations. In Figure 2-15a, the potentially multiple prerequisites of a course (shown as a multivalued attribute in the Attribute cell) are also courses (and a course may be a prerequisite for many other courses). Thus, prerequisite could be viewed as a bill-of-materials structure (shown in the Relationship & Entity cell) between courses, not a multivalued attribute of COURSE. Representing prerequisites via a bill-of-materials structure also means that finding the prerequisites of a course and finding the courses for which a course is prerequisite both deal with relationships between entity types. When a prerequisite is a multivalued attribute of COURSE, finding the courses for which a course is a prerequisite means looking for a specific value for a prerequisite across all COURSE instances. As was shown in Figure 2-13a, such a situation could also be modeled as a

FIGURE 2-15 Using relationships and entities to link related attributes

(a) Multivalued attribute versus relationships via bill-of-materials structure

RELATIONSHIP & ENTITYATTRIBUTE

Course ID Pre-Req Course ID

PK PK

Prerequisite Has Prerequisites

Is Prerequisite For

Course IDPK

Course Title

COURSECOURSE Course ID Course Title {Prerequisite}

(c) Composite attribute of data shared with other entity types

(b) Composite, multivalued attribute versus relationship

Employee IDPK

Employee Name

EMPLOYEE Skill CodePK

Skill Title Skill Type

SKILL

Employee ID Skill Code

PK,FK1 PK,FK2

PossessesEMPLOYEE Employee ID Employee Name {Skill (Skill Code, Skill Title, Skill Type)}

Employee IDPK

Employee Name

EMPLOYEE Department NumberPK

Department Name Budget

DEPARTMENT

ORGANIZATIONAL UNIT PROJECT

Employs

EMPLOYEE

Employee Name Employee ID

Department (Department Number, Department Name, Budget)

M02B_HOFF3359_13_GE_C02.indd 118 12/04/19 12:08 PM

2 • Modeling Data in the Organization 119

unary relationship among instances of the COURSE entity type. In Visio, this specific situation requires creating the equivalent of an associative entity (see the Relationship & Entity cell in Figure 2-15a; Visio does not use the rectangle with rounded corners symbol). By creating the associative entity, it is now easy to add characteristics to the relationship, such as a minimum grade required. Also note that Visio shows the identifier (in this case composite) with a PK stereotype symbol and boldface on the composite attribute names, signifying these are required attributes.

In Figure 2-15b, employees potentially have multiple skills (shown in the Attri- bute cell), but skill could be viewed instead as an entity type (shown in the Relationship & Entity cell as the equivalent of an associative entity) about which the organization wants to maintain data (the unique code to identify each skill, a descriptive title, and the type of skill, e.g., technical or managerial). An employee has skills, which are not viewed as attributes but rather as instances of a related entity type. In the cases of Figures 2-15a and 2-15b, representing the data as a multivalued attribute rather than via a relationship with another entity type may, in the view of some people, simplify the diagram. On the other hand, the right-hand drawings in these figures are closer to the way the database would be represented in a standard relational database man- agement system, the most popular type of DBMS in use today. Although we are not concerned with implementation during conceptual data modeling, there is some logic for keeping the conceptual and logical data models similar. Further, as you will see in the next example, there are times when an attribute, whether simple, composite, or multivalued, should be in a separate entity.

So, when should an attribute be linked to an entity type via a relationship? The answer is 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 attri- butes. Figure 2-15c represents an example of this rule. In this example, EMPLOYEE has a composite attribute of Department. Because Department is a concept of the business and multiple employees will share the same department data, department data could be represented (nonredundantly) in a DEPARTMENT entity type, with attributes for the data about departments that all other related entity instances need to know. With this approach, not only can different employees share the storage of the same department data, but projects (which are assigned to a department) and organizational units (which are composed of departments) also can share the storage of this same department data.

Cardinality Constraints

There is one more important data modeling notation for representing common and important business rules. Suppose there are two entity types, A and B, that are con- nected by a relationship. A cardinality constraint specifies the number of instances of entity B that can (or must) be associated with each instance of entity A. For example, consider a video store that rents DVDs of movies. Because the store may stock more than one DVD for each movie, this is intuitively a one-to-many relationship, as shown in Figure 2-16a (technically, movie is a strong entity and DVD is a weak entity; thus, we represent these entities this way with a partial identifier for DVD). Yet it is also true that the store may not have any DVDs of a given movie in stock at a particular time (e.g., all copies may be checked out). We need a more precise notation to indicate the range of cardinalities for a relationship. This notation was introduced in Figure 2-2, which you may want to review at this time.

MINIMUM CARDINALITY The minimum cardinality of a relationship is the minimum number of instances of entity B that may be associated with each instance of entity A. In our DVD example, the minimum number of DVDs for a movie is zero. When the mini- mum number of participants is zero, we say that entity type B is an optional participant in the relationship. In this example, DVD (a weak entity type) is an optional participant in the Is Stocked As relationship. This fact is indicated by the symbol zero through the line near the DVD entity in Figure 2-16b.

Cardinality constraint

A rule that specifies the number of instances of one entity that can (or must) be associated with each instance of another entity.

Minimum cardinality

The minimum number of instances of one entity that may be associated with each instance of another entity.

M02B_HOFF3359_13_GE_C02.indd 119 12/04/19 12:08 PM

120 Part II • Database Analysis and Logical Design

MAXIMUM CARDINALITY The maximum cardinality of a relationship is the maxi- mum number of instances of entity B that may be associated with each instance of entity A. In the video example, the maximum cardinality for the DVD entity type is “many”—that is, an unspecified number greater than one. This is indicated by the “crow’s foot” symbol on the line next to the DVD entity symbol in Figure 2-16b. (You might find interesting the explanation of the origin of the crow’s foot notation found in the Wikipedia entry about the E-R model; this entry also shows the wide variety of notation used to represent cardinality; see http://en.wikipedia.org/wiki/ Entity-relationship_model.)

A relationship is, of course, bidirectional, so there is also cardinality notation next to the MOVIE entity. Notice that the minimum and maximum are both one (see Figure 2-16b). This is called a mandatory one cardinality. In other words, each DVD of a movie must be a copy of exactly one movie. In general, participation in a relationship may be optional or mandatory for the entities involved. If the minimum cardinality is zero, participation is optional; if the minimum cardinality is one, participation is mandatory.

In Figure 2-16b, some attributes have been added to each of the entity types. Notice that DVD is represented as a weak entity. This is because a DVD cannot exist unless the owner movie also exists. The identifier of MOVIE is Movie Name. DVD does not have a unique identifier. However, Copy Number is a partial identifier, which together with Movie Name would uniquely identify an instance of DVD.

Some Examples of Relationships and Their Cardinalities

Examples of three relationships that show all possible combinations of minimum and maximum cardinalities appear in Figure 2-17. Each example states the business rule for each cardinality constraint and shows the associated E-R notation. Each example also shows some relationship instances to clarify the nature of the relationship. You should study each of these examples carefully. Following are the business rules for each of the examples in Figure 2-17:

1. PATIENT Has Recorded PATIENT HISTORY (Figure 2-17a) Each patient has one or more patient histories. (A PATIENT cannot exist unless there is an initial instance of PATIENT HISTORY.) Each instance of PATIENT HISTORY “belongs to” exactly one PATIENT.

2. EMPLOYEE Is Assigned To PROJECT (Figure 2-17b) Each PROJECT has at least one EMPLOYEE assigned to it. (Some projects have more than one.) Each EMPLOYEE may or (optionally) may not be assigned to any existing PROJECT (e.g., employee Pete) or may be assigned to one or more PROJECTs.

3. PERSON Is Married To PERSON (Figure 2-17c) This is an optional zero or one cardinality in both directions because a person may or may not be married at a given point in time.

Maximum cardinality

The maximum number of instances of one entity that may be associated with each instance of another entity.

FIGURE 2-16 Introducing cardinality constraints

(a) Basic relationship

(b) Relationship with cardinality constraints

Is Stocked As DVDMOVIE

Is Stocked As

MAX one, MIN one

MIN zero, MAX many

MOVIE Movie Name

DVD Copy Number

M02B_HOFF3359_13_GE_C02.indd 120 12/04/19 12:08 PM

2 • Modeling Data in the Organization 121

It is possible for the maximum cardinality to be a fixed number, not an arbitrary “many” value. For example, suppose corporate policy states that an employee may work on at most five projects at the same time. We could show this business rule by placing a 5 above or below the crow’s foot next to the PROJECT entity in Figure 2-17b.

A TERNARY RELATIONSHIP We showed the ternary relationship with the associative entity type SUPPLY SCHEDULE in Figure 2-14. Now let’s add cardinality constraints to this diagram, based on the business rules for this situation. The E-R diagram, with the relevant business rules, is shown in Figure 2-18. Notice that PART and WAREHOUSE must relate to some SUPPLY SCHEDULE instance, and a VENDOR optionally may

FIGURE 2-17 Examples of cardinality constraints

(a) Mandatory cardinalities

(b) One optional, one mandatory cardinality

(c) Optional cardinalities

Mark

Sarah

Elsie

Visit 1

Visit 1

Visit 1 Visit 2

PATIENT PATIENT HISTORY

Has Recorded

Mandatory

Rose

Pete

Debbie

Tom

Heidi

BPR

TQM

OO

CR

EMPLOYEE Is Assigned To

PROJECT

Mandatory Optional

Shirley

Mack

Dawn

Kathy

Ellis

Fred

PERSON

Is Married To

Optional

Each vendor can supply many parts to any number of warehouses but need not supply any parts.

Each part can be supplied by any number of vendors to more than one warehouse, but each part must be supplied by at least one vendor to a warehouse.

Each warehouse can be supplied with any number of parts from more than one vendor, but each warehouse must be supplied with at least one part.

Business Rules

1

2

3

PART

VENDOR SUPPLY SCHEDULE Shipping Mode Unit Cost

WAREHOUSE

31

2

FIGURE 2-18 Cardinality constraints in a ternary relationship

M02B_HOFF3359_13_GE_C02.indd 121 12/04/19 12:08 PM

122 Part II • Database Analysis and Logical Design

not participate. The cardinality at each of the participating entities is a mandatory one because each SUPPLY SCHEDULE instance must be related to exactly one instance of each of these participating entity types. (Remember, SUPPLY SCHEDULE is an associa- tive entity.)

As noted earlier, a ternary relationship is not equivalent to three binary relationships. Unfortunately, you are not able to draw ternary relationships with many CASE tools; instead, you are forced to represent ternary relationships as three binaries (i.e., an associative entity with three binary relationships). If you are forced to draw three binary relationships, then do not draw the binary relationships with names and be sure that the cardinality next to the three strong entities is a mandatory one.

Modeling Time-Dependent Data

Database contents vary over time. With renewed interest today in traceability and recon- struction of a historical picture of the organization for various regulatory requirements, such as HIPAA and Sarbanes-Oxley, and for business intelligence and other analytical purposes, the need to include a time series of data has become essential. For example, in a database that contains product information, the unit price for each product may be changed as material and labor costs and market conditions change. If only the cur- rent price is required, Price can be modeled as a single-valued attribute. However, for accounting, billing, financial reporting, and other purposes, we are likely to need to preserve a history of the prices and the time period during which each was in effect. As Figure 2-19 shows, we can conceptualize this requirement as a series of prices and the effective date for each price. This results in the (composite) multivalued attribute named Price History, with components Price and Effective Date. An important characteristic of such a composite, multivalued attribute is that the component attributes go together. Thus, in Figure 2-19, each Price is paired with the corresponding Effective Date.

In Figure 2-19, each value of the attribute Price is time stamped with its effective date. A time stamp is simply a time value, such as date and time, that is associated with a data value. A time stamp may be associated with any data value that changes over time when we need to maintain a history of those data values. Time stamps may be recorded to indicate the time the value was entered (transaction time), the time the value becomes valid or stops being valid, or the time when critical actions were per- formed, such as updates, corrections, or audits. This situation is similar to the employee skill diagrams in Figure 2-15b; thus, an alternative, not shown in Figure 2-19, is to make Price History a separate entity type, as was done with Skill using Microsoft Visio.

The use of simple time stamping (as in the preceding example) is often adequate for modeling time-dependent data. However, time can introduce subtler complexities to data modeling. For example, consider again Figure 2-17c. This figure is drawn for a given point in time, not to show history. If, on the other hand, we needed to record the full history of marriages for individuals, the Is Married To relationship would be an optional many-to-many relationship. Further, we might want to know the beginning and ending date (optional) of each marriage; these dates would be, similar to the bill- of-materials structure in Figure 2-13c, attributes of the relationship or associative entity.

Financial and other compliance regulations, such as Sarbanes-Oxley and Basel II, require that a database maintain history rather than just current status of critical data. In addition, some data modelers will argue that a data model should always be able to

Time stamp

A time value that is associated with a data value, often indicating when some event occurred that affected the data value.

PRODUCT Product ID {Price History (E�ective Date, Price)}

Time Stamp

FIGURE 2-19 Simple example of time stamping

M02B_HOFF3359_13_GE_C02.indd 122 12/04/19 12:08 PM

2 • Modeling Data in the Organization 123

represent history, even if today’s users say they need only current values. These factors suggest that all relationships should be modeled as many-to-many (which is often done in a purchased data model). Thus, for most databases, this will necessitate forming an associative entity along every relationship. There are two obvious negatives to this approach. First, many additional (associative) entities are created, thus cluttering ERDs. Second, a many-to-many (M:N) relationship is less restrictive than a one-to-many (1:M). So, if initially you want to enforce only one associated entity instance for some entity (i.e., the “one” side of the relationships), this cannot be enforced by the data model with an M:N relationship. It would seem likely that some relationships would never be M:N; for example, would a 1:M relationship between customer and order ever become M:N (but, of course, maybe someday our organization would sell items that would allow and often have joint purchasing, like vehicles or houses)? The conclusion is that if his- tory or a time series of values might ever be desired or required by regulation, you should consider using an M:N relationship.

An even more subtle situation of the effect of time on data modeling is illustrated in Figure 2-20a, which represents a portion of an ERD for Pine Valley Furniture Com- pany. Each product is assigned (i.e., current assignment) to a product line (or related group of products). Customer orders are processed throughout the year, and monthly summaries are reported by product line and by product within product line.

Suppose that in the middle of the year, due to a reorganization of the sales func- tion, some products are reassigned to different product lines. The model shown in Figure 2-20a is not designed to track the reassignment of a product to a new product line. Thus, all sales reports will show cumulative sales for a product based on its current product line rather than the one at the time of the sale. For example, a product may have total year-to-date sales of $50,000 and be associated with product line B, yet $40,000 of

PRODUCT LINE

PRODUCT

Assigned

Placed ORDER

Current Product Line, not necessarily same as

at the time the order was placed

FIGURE 2-20 Example of time in Pine Valley Furniture product database

(a) E-R diagram not recognizing product reassignment

(b) E-R diagram recognizing product reassignment

PRODUCT

Assigned

Sales For Product

Sales For Product Line

PRODUCT LINE

Product Line for each Product on the Order as

of the time the order was placed; does not change as current

assignment of Product to Product Line might changeORDER

M02B_HOFF3359_13_GE_C02.indd 123 12/04/19 12:08 PM

124 Part II • Database Analysis and Logical Design

those sales may have occurred while the product was assigned to product line A. This fact will be lost using the model in Figure 2-20a. The simple design change shown in Figure 2-20b will correctly recognize product reassignments. A new relationship, called Sales For Product Line, has been added between ORDER and PRODUCT LINE. As cus- tomer orders are processed, they are credited to both the correct product (via Sales For Product) and the correct product line (via Sales For Product Line) as of the time of the sale. The approach of Figure 2-20b is similar to what is done in a data warehouse to retain historical records of the precise situation at any point in time. (We will return to dealing with the time dimension in Chapter 9.)

Another aspect of modeling time is recognizing that although the requirements of the organization today may be to record only the current situation, the design of the database may need to change if the organization ever decides to keep history. In Figure 2-20b, we know the current product line for a product and the product line for the product each time it is ordered. But what if the product were ever reassigned to a product line during a period of zero sales for the product? Based on this data model in Figure 2-20b, we would not know of these other product line assignments. A common solution to this need for greater flexibility in the data model is to consider whether a one-to-many relationship, such as Assigned, should become a many-to-many relation- ship. Further, to allow for attributes on this new relationship, this relationship should actually be an associative entity. Figure 2-20c shows this alternative data model with the ASSIGNMENT associative entity for the Assigned relationship. The advantage of the alternative is that we now will not miss recording any product line assignment, and we can record information about the assignment (such as the from and to effective dates of the assignment); the disadvantage is that the data model no longer has the restriction that a product may be assigned to only one product line at a time.

We have discussed the problem of time-dependent data with managers in several organizations who are considered leaders in the use of data modeling and database management. Before the recent wave of financial reporting disclosure regulations, these discussions revealed that data models for operational databases were generally inadequate for handing time-dependent data and that organizations often ignored this problem and hoped that the resulting inaccuracies balanced out. However, with these new regulations, you need to be alert to the complexities posed by time-dependent data as you develop data models in your organization. For a thorough explanation of time as a dimension of data modeling, see a series of articles by T. Johnson and R. Weis beginning in May 2007 in DM Review (now Information Management; see Refer- ences at the end of this chapter).

Modeling Multiple Relationships Between Entity Types

There may be more than one relationship between the same entity types in a given orga- nization. Two examples are shown in Figure 2-21. Figure 2-21a shows two relationships

(c) E-R diagram with associative entity for product assignment to product line over time

ASSIGNMENT From Date To Date

PRODUCT LINE

PRODUCT Sales For Product

Sales For Product Line

ORDER

FIGURE 2-20 (continued)

M02B_HOFF3359_13_GE_C02.indd 124 12/04/19 12:08 PM

2 • Modeling Data in the Organization 125

between the entity types EMPLOYEE and DEPARTMENT. In this figure, we use the notation with names for the relationship in each direction; this notation makes explicit what the cardinality is for each direction of the relationship (which becomes important for clarifying the meaning of the unary relationship on EMPLOYEE). One relationship associates employees with the department in which they work. This relationship is one-to-many in the Has Workers direction and is mandatory in both directions. That is, a department must have at least one employee who works there (perhaps the depart- ment manager), and each employee must be assigned to exactly one department. (Note: These are specific business rules we assume for this illustration. It is crucial when you develop an E-R diagram for a particular situation that you understand the business rules that apply for that setting. For example, if EMPLOYEE were to include retirees, then each employee may not be currently assigned to exactly one department; further, the E-R model in Figure 2-21a assumes that the organization needs to remember in which DEPARTMENT each EMPLOYEE currently works rather than remembering the history of department assignments. Again, the structure of the data model reflects the information the organization needs to remember.)

The second relationship between EMPLOYEE and DEPARTMENT associates each department with the employee who manages that department. The relationship from DEPARTMENT to EMPLOYEE (called Is Managed By in that direction) is a mandatory one, indicating that a department must have exactly one manager. From EMPLOYEE to DEPARTMENT, the relationship (Manages) is optional because a given employee either is or is not a department manager.

Figure 2-21a also shows the unary relationship that associates each employee with his or her supervisor and vice versa. This relationship records the business rule that each employee may have exactly one supervisor (Supervised By). Conversely, each employee may supervise any number of employees or may not be a supervisor.

The example in Figure 2-21b shows two relationships between the entity types PROFESSOR and COURSE. The relationship Is Qualified associates professors with the courses they are qualified to teach. A given course must have at a minimum two quali- fied instructors (an example of how to use a fixed value for a minimum or maximum cardinality). This might happen, for example, so that a course is never the “property” of one instructor. Conversely, each instructor must be qualified to teach at least one course (a reasonable expectation).

FIGURE 2-21 Examples of multiple relationships

(a) Employees and departments

(b) Professors and courses (fixed

lower limit constraint)

Supervises

Supervised By

EMPLOYEE DEPARTMENT

Works In Has Workers

Manages Is Managed By

PROFESSOR Is Qualified

COURSE 2

SCHEDULE Semester

M02B_HOFF3359_13_GE_C02.indd 125 12/04/19 12:08 PM

126 Part II • Database Analysis and Logical Design

The second relationship in this figure associates professors with the courses they are actually scheduled to teach during a given semester. Because Semester is a characteristic of the relationship, we place an associative entity, SCHEDULE, between PROFESSOR and COURSE.

One final point about Figure 2-21b: Have you figured out what the identifier is for the SCHEDULE associative entity? Notice that Semester is a partial identifier; thus, the full identifier will be the identifier of PROFESSOR along with the identifier of COURSE as well as Semester. Because such full identifiers for associative entities can become long and complex, it is often recommended that surrogate identifiers be created for each associative entity; so, Schedule ID would be created as the identifier of SCHEDULE, and Semester would be an attribute. What is lost in this case is the explicit business rule that the combination of the PROFESSOR identifier, COURSE identifier, and Semester must be unique for each SCHEDULE instance (because this combination is the identi- fier of SCHEDULE). Of course, this can be added as another business rule.

Naming and Defining Relationships

In addition to the general guidelines for naming data objects, there are a few special guidelines for naming relationships, which follow:

• A relationship name is a verb phrase (such as Assigned To, Supplies, or Teaches). Relationships represent actions being taken, usually in the present tense, so tran- sitive verbs (an action on something) are the most appropriate. A relationship name states the action taken, not the result of the action (e.g., use Assigned To, not Assignment). The name states the essence of the interaction between the partici- pating entity types, not the process involved (e.g., use an Employee is Assigned To a project, not an Employee is Assigning a project).

• You should avoid vague names, such as Has or Is Related To. Use descriptive, pow- erful verb phrases, often taken from the action verbs found in the definition of the relationship.

There are also some specific guidelines for defining relationships, which follow:

• A relationship definition explains what action is being taken and possibly why it is important. It may be important to state who or what does the action, but it is not important to explain how the action is taken. Stating the business objects involved in the relationship is natural, but because the E-R diagram shows what entity types are involved in the relationship and other definitions explain the entity types, you do not have to describe the business objects.

• It may also be important to give examples to clarify the action. For example, for a relationship of Registered For between student and course, it may be useful to explain that this covers both on-site and online registration, and includes registra- tions made during the drop/add period.

• The definition should explain any optional participation. You should explain what conditions lead to zero associated instances, whether this can happen only when an entity instance is first created, or whether this can happen at any time. For example, “Registered For links a course with the students who have signed up to take the course, and the courses a student has signed up to take. A course will have no students registered for it before the registration period begins and may never have any registered students. A student will not be registered for any courses before the registration period begins and may not register for any classes (or may register for classes and then drop any or all classes).”

• A relationship definition should also explain the reason for any explicit maximum cardinal- ity other than many. For example, “Assigned To links an employee with the projects to which that employee is assigned and the employees assigned to a project. Due to our labor union agreement, an employee may not be assigned to more than four projects at a given time.” This example, typical of many upper-bound business rules, suggests that maximum cardinalities tend not to be permanent. In this example, the next labor union agreement could increase or decrease this limit. Thus, the implementation of maximum cardinalities must be done to allow changes.

M02B_HOFF3359_13_GE_C02.indd 126 12/04/19 12:08 PM

2 • Modeling Data in the Organization 127

• A relationship definition should explain any mutually exclusive relationships. Mutu- ally exclusive relationships are ones for which an entity instance can participate in only one of several alternative relationships. We will show examples of this situ- ation in Chapter 3. For now, consider the following example: “Plays On links an intercollegiate sports team with its student players and indicates on which teams a student plays. Students who play on intercollegiate sports teams cannot also work in a campus job (i.e., a student cannot be linked to both an intercollegiate sports team via Plays On and a campus job via the Works On relationship).” Another example of a mutually exclusive restriction is when an employee cannot both be Supervised By and be Married To the same employee.

• A relationship definition should explain any restrictions on participation in the rela- tionship. Mutual exclusivity is one restriction, but there can be others. For example, “Supervised By links an employee with the other employees he or she supervises and links an employee with the other employee who supervises him or her. An employee cannot supervise him- or herself, and an employee cannot supervise other employees if his or her job classification level is below 4.”

• A relationship definition should explain the extent of history that is kept in the relation- ship. For example, “Assigned To links a hospital bed with a patient. Only the cur- rent bed assignment is stored. When a patient is not admitted, that patient is not assigned to a bed, and a bed may be vacant at any given point in time.” Another example of describing history for a relationship is “Places links a customer with the orders he or she has placed with our company and links an order with the associated customer. Only two years of orders are maintained in the database, so not all orders can participate in this relationship.”

• A relationship definition should explain whether an entity instance involved in a rela- tionship instance can transfer participation to another relationship instance. For example, “Places links a customer with the orders he or she has placed with our company and links an order with the associated customer. An order is not transferable to another customer.” Another example is “Categorized As links a product line with the products sold under that heading and links a product to its associated product line. Due to changes in organization structure and product design features, prod- ucts may be recategorized to a different product line. Categorized As keeps track of only the current product line to which a product is linked.”

E-R MODELING EXAMPLE: PINE VALLEY FURNITURE COMPANY

You can develop an E-R diagram from one (or both) of two perspectives. With a top- down perspective, you proceed from basic descriptions of the business, including its policies, processes, and environment. This approach is most appropriate for developing a high-level E-R diagram with only the major entities and relationships and with a lim- ited set of attributes (such as just the entity identifiers). With a bottom-up approach, you proceed from detailed discussions with users, and from a detailed study of documents, screens, and other data sources. This approach is necessary for developing a detailed, “fully attributed” E-R diagram.

In this section, we illustrate a high-level ERD for Pine Valley Furniture Company, based largely on the first of these approaches (see Figure 2-22 for a Microsoft Visio version). For simplicity, we do not show any composite or multivalued attributes (e.g., skill is shown as a separate entity type associated with EMPLOYEE via an associative entity, which allows an employee to have many skills and a skill to be held by many employees).

Figure 2-22 provides many examples of common E-R modeling notations, and hence, it can be used as an excellent review of what you have learned in this chapter. In a moment, we will explain the business rules that are represented in this figure. How- ever, before you read that explanation, one way to use Figure 2-22 is to search for typical E-R model constructs in it, such as one-to-many, binary, or unary relationships. Then ask yourself why the business data was modeled this way. For example, ask yourself:

• Where is a unary relationship, what does it mean, and for what reasons might the cardinalities on it be different in other organizations?

M02B_HOFF3359_13_GE_C02.indd 127 12/04/19 12:08 PM

128 Part II • Database Analysis and Logical Design

• Why is Includes a one-to many relationship, and why might this ever be different in some other organization?

• 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)?

FIGURE 2-22 Data model for Pine Valley Furniture Company in Microsoft Visio notation

Salesperson ID

Salesperson Name Salesperson Telephone Salesperson Fax

PK

Customer ID

Customer Name Customer Address Customer Postal Code

PK

Product ID

Product Description Product Finish Product Standard Price

PK

Material ID

Material Name Material Standard Cost Unit Of Measure

PK

Order ID

Order Date

PK

SkillPK

Ordered Quantity

Product Line ID

Product Line Name

PK

Serves

Submits

Includes

Is Supervised By

Supervises

Territory IDPK

Territory Name

Vendor ID

Vendor Name Vendor Address

PK

Employee ID

Employee Name Employee Address

PK

Work Center ID

Work Center Location

PK

Goes Into Quantity

Supply Unit Price

SALESPERSON

CUSTOMER

PRODUCT

RAW MATERIAL

ORDER

SKILL

ORDER LINE

PRODUCT LINE

TERRITORY DOES BUSINESS IN

VENDOR

EMPLOYEE

WORK CENTER

USES PRODUCED IN

WORKS IN

HAS SKILL

SUPPLIES

M02B_HOFF3359_13_GE_C02.indd 128 12/04/19 12:08 PM

2 • Modeling Data in the Organization 129

• If there were a different customer contact person for each sales territory in which a customer did business, where in the data model would we place this person’s name?

• 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 SALES TERRI- TORY and one CUSTOMER?

• 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?

Each of these questions is included in Problem and Exercise 2-25 at the end of the chap- ter, but we suggest you use these now as a way to review your understanding of E-R diagramming.

From a study of the business processes at Pine Valley Furniture Company, we have identified the following entity types. An identifier is also suggested for each entity, together with selected important attributes:

• The company sells a number of different furniture products. These products are grouped into several product lines. The identifier for a product is Product ID, whereas the identifier for a product line is Product Line ID. We identify the fol- lowing additional attributes for product: Product Description, Product Finish, and Product Standard Price. Another attribute for product line is Product Line Name. A product line may group any number of products but must group at least one product. Each product must belong to exactly one product line.

• Customers submit orders for products. The identifier for an order is Order ID, and another attribute is Order Date. A customer may submit any number of orders but need not submit any orders. Each order is submitted by exactly one customer. The identifier for a customer is Customer ID. Other attributes include Customer Name, Customer Address, and Customer Postal Code.

• A given customer order must request at least one product and only one product per order line item. Any product sold by Pine Valley Furniture may not appear on any order line item or may appear on one or more order line items. An attribute associated with each order line item is Ordered Quantity.

• Pine Valley Furniture has established sales territories for its customers. Each cus- tomer may do business in any number of these sales territories or may not do business in any territory. A sales territory has one to many customers. The identi- fier for a sales territory is Territory ID and an attribute is Territory Name.

• Pine Valley Furniture Company has several salespersons. The identifier for a sales- person is Salesperson ID. Other attributes include Salesperson Name, Salesperson Telephone, and Salesperson Fax. A salesperson serves exactly one sales territory. Each sales territory is served by one or more salespersons.

• Each product is assembled from a specified quantity of one or more raw materials. The identifier for the raw material entity is Material ID. Other attributes include Unit Of Measure, Material Name, and Material Standard Cost. Each raw mate- rial is assembled into one or more products, using a specified quantity of the raw material for each product.

• Raw materials are supplied by vendors. The identifier for a vendor is Vendor ID. Other attributes include Vendor Name and Vendor Address. Each raw material can be supplied by one or more vendors. A vendor may supply any number of raw materials or may not supply any raw materials to Pine Valley Furniture. Sup- ply Unit Price is the unit price at which a particular vendor supplies a particular raw material.

• Pine Valley Furniture has established a number of work centers. The identifier for a work center is Work Center ID. Another attribute is Work Center Location. Each product is produced in one or more work centers. A work center may be used to produce any number of products or may not be used to produce any products.

• The company has more than 100 employees. The identifier for employee is Employee ID. Other attributes include Employee Name, Employee Address, and Skill. An employee may have more than one skill. Each employee may work in one or more work centers. A work center must have at least one employee working in

M02B_HOFF3359_13_GE_C02.indd 129 12/04/19 12:08 PM

130 Part II • Database Analysis and Logical Design

that center but may have any number of employees. A skill may be possessed by more than one employee or possibly no employees.

• Each employee has exactly one supervisor; however, a manager has no supervisor. An employee who is a supervisor may supervise any number of employees, but not all employees are supervisors.

DATABASE PROCESSING AT PINE VALLEY FURNITURE

The purpose of the data model diagram in Figure 2-22 is to provide a conceptual design for the Pine Valley Furniture Company database. It is important to check the quality of such a design through frequent interaction with the persons who will use the database after it is implemented. An important and often performed type of quality check is to determine whether the E-R model can easily satisfy user requests for data and/or infor- mation. Employees at Pine Valley Furniture have many data retrieval and reporting requirements. In this section, we show how a few of these information requirements can be satisfied by database processing against the database shown in Figure 2-22.

We use the SQL database processing language (explained in Chapters 5 and 6) to state these queries. To fully understand these queries, you will need to understand concepts introduced in Chapter 4. However, a few simple queries in this chapter should help you understand the capabilities of a database to answer important organizational questions and give you a jump-start toward understanding SQL queries in Chapter 5 as well as in later chapters.

Showing Product Information

Many different users have a need to see data about the products Pine Valley Furniture produces (e.g., salespersons, inventory managers, and product managers). One specific need is for a salesperson who wants to respond to a request from a customer for a list of products of a certain type. An example of this query is

List all details for the various computer desks that are stocked by the company.

The data for this query are maintained in the PRODUCT entity (see Figure 2-22). The query scans this entity and displays all the attributes for products that contain the description Computer Desk.

The SQL code for this query is

SELECT * FROM Product WHERE ProductDescription LIKE “Computer Desk%”;

Typical output for this query is

PRODUCTID PRODUCTDESCRIPTION PRODUCTFINISH PRODUCTSTANDARDPRICE

3 Computer Desk 48” Oak 375.00

8 Computer Desk 64” Pine 450.00

SELECT * FROM Product says display all attributes of PRODUCT entities. The WHERE clause says to limit the display to only products whose description begins with the phrase Computer Desk.

Showing Product Line Information

Another common information need is to show data about Pine Valley Furniture prod- uct lines. One specific type of person who needs this information is a product manager. The following is a typical query from a territory sales manager:

M02B_HOFF3359_13_GE_C02.indd 130 12/04/19 12:08 PM

2 • Modeling Data in the Organization 131

List the details of products in product line 4.

The data for this query are maintained in the PRODUCT entity. As we explain in Chapter 4, the attribute Product Line ID will be added to the PRODUCT entity when a data model in Figure 2-22 is translated into a database that can be accessed via SQL. The query scans the PRODUCT entity and displays all attributes for products that are in the selected product line.

The SQL code for this query is

SELECT * FROM Product WHERE ProductLineID = 4;

Typical output for this query is

PRODUCTID PRODUCTDESCRIPTION PRODUCTFINISH PRODUCTSTANDARDPRICE PRODUCTONHAND PRODUCTLINEID

18 Grandfather Clock Oak 890.0000 0 4

19 Grandfather Clock Oak 1100.0000 0 4

The explanation of this SQL query is similar to the explanation of the previous one.

Showing Customer Order Status

The previous two queries are relatively simple, involving data from only one table in each case. Often, data from multiple tables are needed in one information request. Although the previous query is simple, we did have to look through the whole database to find the entity and attributes needed to satisfy the request.

To simplify query writing and for other reasons, many database management systems support creating restricted views of a database suitable for the information needs of a par- ticular user. For queries related to customer order status, Pine Valley utilizes such a user view called “Orders for customers,” which is created from the segment of an E-R diagram for PVFC shown in Figure 2-23a. This user view allows users to see only CUSTOMER and ORDER entities in the database, and only the attributes of these entities shown in the figure. For the user, there is only one (virtual) table, ORDERS FOR CUSTOMERS, with the listed attributes. As we explain in Chapter 4, the attribute Customer ID will be added to the ORDER entity (as shown in Figure 2-23a). A typical order status query is:

How many orders have we received from Value Furniture?

FIGURE 2-23 Two user views for Pine Valley Furniture

(a) User View 1: Orders for customers

(b) User View 2: Orders for products

CUSTOMER Customer ID Customer Name

ORDER Order IDSubmits

PRODUCT Product ID Standard Price

ORDER Order ID Order Date

ORDER LINE

Ordered Quantity

M02B_HOFF3359_13_GE_C02.indd 131 12/04/19 12:08 PM

132 Part II • Database Analysis and Logical Design

Assuming that all the data we need are pulled together into this one user view, or virtual entity, called OrdersForCustomers, we can simply write the query as follows:

SELECT COUNT(Order ID) FROM OrdersForCustomers WHERE CustomerName = “Value Furniture”;

Without the user view, we can write the SQL code for this query in several ways. The way we have chosen is to compose a query within a query, called a subquery. (We will explain subqueries in Chapter 6, with some diagramming techniques to assist you in composing the query.) The query is performed in two steps. First, the subquery (or inner query) scans the CUSTOMER entity to determine the Customer ID for the customer named Value Furniture. (The ID for this customer is 5, as shown in the output for the previous query.) Then the query (or outer query) scans the ORDER entity and counts the order instances for this customer.

The SQL code for this query without the “Orders for customer” user view is as follows:

SELECT COUNT (OrderID) FROM Order WHERE CustomerID = (SELECT CustomerID FROM Customer WHERE CustomerName = “Value Furniture”);

For this example query, using a subquery rather than a view did not make writing the query much more complex.

Typical output for this query using either of the query approaches above is:

COUNT(ORDERID) 4

Showing Product Sales

Salespersons, territory managers, product managers, production managers, and oth- ers have a need to know the status of product sales. One kind of sales question is what products are having an exceptionally strong sales month. Typical of this question is the following query:

What products have had total sales exceeding $25,000 during the past month (June, 2018)?

This query can be written using the user view “Orders for products,” which is created from the segment of an E-R diagram for PVFC shown in Figure 2-23b. Data to respond to the query are obtained from the following sources:

• Order Date from the ORDER entity (to find only orders in the desired month). • Ordered Quantity for each product on each order from the associative entity

ORDER LINE for an ORDER entity in the desired month. • Standard Price for the product ordered from the PRODUCT entity associated with

the ORDER LINE entity.

For each item ordered during the month of June 2018, the query needs to multiply Ordered Quantity by Product Standard Price to get the dollar value of a sale. For the

M02B_HOFF3359_13_GE_C02.indd 132 12/04/19 12:08 PM

2 • Modeling Data in the Organization 133

user, there is only one (virtual) table, ORDERS FOR PRODUCTS, with the listed attri- butes. The total amount is then obtained for that item by summing all orders. Data are displayed only if the total exceeds $25,000.

The SQL code for this query is beyond the scope of this chapter because it requires techniques introduced in Chapter 6. We introduce this query now only to suggest the power that a database such as the one shown in Figure 2-22 has to find information for manage- ment from detailed data. In many organizations today, users can use a Web browser to obtain the information described here. The programming code associated with a Web page then invokes the required SQL commands to obtain the requested information.

Summary This chapter has described the fundamentals of model- ing data in the organization. Business rules, derived from policies, procedures, events, functions, and other busi- ness objects, state constraints that govern the organization and, hence, how data are handled and stored. Using busi- ness rules is a powerful way to describe the requirements for an information system, especially a database. The power of business rules results from business rules being core concepts of the business, being able to be expressed in terms familiar to end users, being highly maintainable, and being able to be enforced through automated means, mainly through a database. Good business rules are ones that are declarative, precise, atomic, consistent, express- ible, distinct, and business oriented.

Examples of basic business rules are data names and definitions. This chapter explained guidelines for the clear naming and definition of data objects in a business. In terms of conceptual data modeling, names and defini- tions must be provided for entity types, attributes, and relationships. Other business rules may state constraints on these data objects. These constraints can be captured in a data model and associated documentation.

The data modeling notation most frequently used today is the E-R data model. An E-R model is a detailed, logical representation of the data for an organization. An E-R model is usually expressed in the form of an E-R diagram, which is a graphical representation of an E-R model. The E-R model was introduced by Chen in 1976. However, at the present time, there is no standard nota- tion for E-R modeling. Notations such as those found in Microsoft Visio are used in many CASE tools.

The basic constructs of an E-R model are entity types, relationships, and related attributes. An entity is a person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data. An entity type is a collection of entities that share common properties, whereas an entity instance is a single occurrence of an entity type. A strong entity type is an entity that has its own identifier and can exist without other entities. A weak entity type is an entity whose existence depends on the existence of a strong entity type. Weak entities do not have their own identi- fier, although they normally have a partial identifier. Weak entities are identified through an identifying rela- tionship with their owner entity type.

An attribute is a property or characteristic of an entity or relationship that is of interest to the organiza- tion. There are several types of attributes. A required attri- bute must have a value for an entity instance, whereas an optional attribute value may be null. A simple attribute is one that has no component parts. A composite attribute is an attribute that can be broken down into component parts. For example, Person Name can be broken down into the parts First Name, Middle Initial, and Last Name.

A multivalued attribute is one that can have mul- tiple values for a single instance of an entity. For example, the attribute College Degree might have multiple values for an individual. A derived attribute is one whose values can be calculated from other attribute values. For exam- ple, Average Salary can be calculated from values of Sal- ary for all employees.

An identifier is an attribute that uniquely identifies individual instances of an entity type. Identifiers should be chosen carefully to ensure stability and ease of use. Identifiers may be simple attributes, or they may be com- posite attributes with component parts.

A relationship type is a meaningful association between (or among) entity types. A relationship instance is an association between (or among) entity instances. The degree of a relationship is the number of entity types that participate in the relationship. The most common relationship types are unary (degree 1), binary (degree 2), and ternary (degree 3).

In developing E-R diagrams, you sometimes encoun- ter many-to-many (and one-to-one) relationships that have one or more attributes associated with the rela- tionship, rather than with one of the participating entity types. In such cases, you might consider converting the relationship to an associative entity. This type of entity associates the instances of one or more entity types and contains attributes that are peculiar to the relationship. Associative entity types may have their own simple iden- tifier, or they may be assigned a composite identifier dur- ing logical design.

A cardinality constraint is a constraint that specifies the number of instances of entity B that may (or must) be associated with each instance of entity A. Cardinality constraints normally specify the minimum and maxi- mum number of instances. The possible constraints are mandatory one, mandatory many, optional one, optional

M02B_HOFF3359_13_GE_C02.indd 133 12/04/19 12:08 PM

134 Part II • Database Analysis and Logical Design

many, and a specific number. The minimum cardinality constraint is also referred to as the participation con- straint. A minimum cardinality of zero specifies optional participation, whereas a minimum cardinality of one specifies mandatory participation.

Because many databases need to store the value of data over time, modeling time-dependent data is an important part of data modeling. Data that repeat over

time may be modeled as multivalued attributes or as separate entity instances; in each case, a time stamp is necessary to identify the relevant date and time for the data value. Sometimes separate relationships need to be included in the data model to represent associations at dif- ferent points in time. The recent wave of financial report- ing disclosure regulations have made it more important to include time-sensitive and historical data in databases.

Associative entity 112 Attribute 105 Binary relationship 116 Business rule 96 Cardinality constraint 119 Composite attribute 106 Composite identifier 108 Degree 114 Derived attribute 107

Entity 101 Entity instance 101 Entity-relationship

diagram (E-R diagram) 92 Entity-relationship model

(E-R model) 92 Entity type 101 Fact 99 Identifier 107

Identifying owner 102 Identifying relationship 103 Maximum cardinality 119 Minimum cardinality 120 Multivalued attribute 107 Optional attribute 105 Relationship instance 111 Relationship type 111 Required attribute 105

Simple (or atomic) attribute 106

Strong entity type 102 Term 99 Ternary relationship 116 Time stamp 122 Unary relationship 115 Weak entity type 102

Chapter Review

2-1. Define each of the following terms: a. entity type b. entity-relationship model c. entity instance d. attribute e. relationship type f. strong entity type g. multivalued attribute h. associative entity i. cardinality constraint j. weak entity k. binary relationship l. derived attribute m. business rule

2-2. Match the following terms and definitions.            composite attribute

           associative entity

           unary relationship

           weak entity

           attribute

           entity

           relationship type

           cardinality constraint

           degree

Review Questions

Key Terms

a. uniquely identifies entity instances

b. relates instances of a single entity type

c. specifies maximum and minimum number of instances

d. relationship modeled as an entity type

e. association between entity types

f. collection of similar entities

g. number of participating entity types in relation- ship

h. property of an entity i. can be broken into com-

ponent parts

2-3. Contrast the following terms: a. stored attribute; derived attribute b. minimum cardinality; maximum cardinality c. entity type; relationship type d. strong entity type; weak entity type e. degree; cardinality f. required attribute; optional attribute g. composite attribute; multivalued attribute h. ternary relationship; three binary relationships

2-4. Give four reasons why many system designers believe that data modeling is important and arguably the most important part of the systems development process.

2-5. Give four reasons why a business rules approach is advo- cated as a new paradigm for specifying information sys- tems requirements.

2-6. What are the characteristics of good business rules? 2-7. State six general guidelines for naming data objects in a

data model. 2-8. State the differences between a term and a fact. 2-9. What is the need for time stamping in modeling time-

dependent data? 2-10. Discuss the main guidelines for defining relationships. 2-11. When should an attribute be linked to an entity via a

relationship? 2-12. The chapter makes a distinction between a required attribute

and an optional attribute. Illustrate a required attribute with a relevant example.

j. depends on the existence of another entity type

k. relationship of degree 3 l. may not have a value m. person, place, object, con-

cept, or event

           identifier

           entity type

           ternary

           optional attribute

M02B_HOFF3359_13_GE_C02.indd 134 12/04/19 12:08 PM

2 • Modeling Data in the Organization 135

2-13. State the guidelines for naming entity types. Discuss why organizations customize a purchased data model.

2-14. Give an example (other than those described in this chap- ter) for each of the following, and justify your answer: a. derived attribute b. multivalued attribute c. atomic attribute d. composite attribute e. composite identifier attribute f. optional attribute

2-15. Provide examples (other than those described in this chapter) of multiple relationships, and explain why these examples best represent this type of relationship. Discuss the role of identifiers in modeling this relationship.

2-16. Discuss why the E-R model is a popular modeling tool.

2-17. State a rule that says when to extract an attribute from one entity type and place it in a linked entity type.

2-18. What are the special guidelines for naming relationships? 2-19. Why is data modeling considered more important than

process modeling? 2-20. For the Manages relationship in Figure 2-12a, describe

one or more situations that would result in different cardinalities on the two ends of this unary relationship. Based on your description for this example, do you think it is always clear simply from an E-R diagram what the business rule is that results in certain cardinalities? Jus- tify your answer.

2-21. Explain any two characteristics of a good business rule. 2-22. Why is time stamping considered an important part of the

data modeling process?

Problems and Exercises 2-23. A cellular operator needs a database to keep track of its

customers, their subscription plans, and the handsets (mobile phones) that they are using. The E-R diagram in Figure 2-24 illustrates the key entities of interest to the operator and the relationships between them. Based on the figure, answer the following questions and explain the rationale for your response. For each question, identify the element(s) in the E-R diagram that you used to determine your answer. a. Can a customer have an unlimited number of plans? b. Can a customer exist without a plan? c. Is it possible to create a plan without knowing who

the customer is? d. Does the operator want to limit the types of hand-

sets that can be linked to a specific plan type? e. Is it possible to maintain data regarding a handset

without connecting it to a plan? f. Can a handset be associated with 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?

h. Is the company able to track a manufacturer without maintaining information about its handsets?

i. Can the same operating system be used on multiple handset types?

j. There are two relationships between Customer and Plan. Explain how they differ.

k. Characterize the degree and the cardinalities of the relationship that connects Customer to itself. Explain its meaning.

l. Is it possible to link a handset to a specific customer in a plan with multiple customers?

m. Can the company track a handset without identifying its operating system?

2-24. For each of the descriptions below, perform the following tasks: i. Identify the degree and cardinalities of each relationship. ii. Express the relationships in each description graphi-

cally with an E-R diagram.

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

b. A book (see 2a) 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 regarding prospective authors who have not yet published any books.

c. In the context specified in 2a and 2b, 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 belongs 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.

B el

o n g

s

Is r

es p

o n si

b le

f o

r

In cl

u d

es

Plan Type

Plan

Handset

Operating System

Manufacturer Handset Type

Family member

Customer

FIGURE 2-24 Diagram for Problem and Exercise 2-23

M02B_HOFF3359_13_GE_C02.indd 135 12/04/19 12:08 PM

136 Part II • Database Analysis and Logical Design

d. A book (see 2a) 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.

e. 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, Ebony and Ivory 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.

f. Ebony and Ivory (see 2e) 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.

g. The piano technicians (see 2f) have a hierarchy of reporting relationships: Some of them have supervi- sory responsibilities in addition to their inspection role and have multiple other technicians report to them. The supervisors themselves report to the chief techni- cian of the company.

h. Chiclets Electronics (CE) builds multiple types of tablet computers. Each has a type identification number and a name. The key specifications for each type include amount of storage space and display type. The com- pany uses multiple processor types, exactly one of which is used for a specific tablet computer type; obvi- ously, 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. Each individual tablet computer manufactured by CE (see 2h) is identified by the type identification num- ber and a serial number that is unique within the type identification. CE wants to maintain information about when each tablet is shipped to a customer.

j. Each of the tablet computer types (see 2h) 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 examina- tion for the combination, and the certification is valid for a specific period of time that varies depending on tablet type–operating system combination.

2-25. Answer the following questions concerning Figure 2-22: a. Where is a unary relationship, what does it mean, and

for what reasons might the cardinalities on it be differ- ent in other organizations?

b. Why is Includes a one-to-many relationship, and why might this ever be different in some other organization?

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)?

d. If there is a rating of the competency for each skill an employee possesses, where in the data model would we place this rating?

e. What is the meaning of the DOES BUSINESS IN asso- ciative entity, and why does each DOES BUSINESS IN instance have to be associated with exactly one TERRI- TORY and one CUSTOMER?

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?

2-26. There is a bulleted list associated with Figure 2-22 that describes the entities and their relationships in Pine Valley Furniture. For each of the 10 points in the list, identify the subset of Figure 2-22 described by that point.

2-27. Draw an ER diagram reflecting the needs of an instructor to monitor their class performance, and include entities such as class performance, grades, and attendance. This ER model will be used by the instructor to build a data- base for their course in the future.

2-28. Consider the two E-R diagrams in Figure 2-25, which rep- resent a database of community service agencies and vol- unteers in two different cities (A and B). For each of the following three questions, place a check mark under City A, City B, or Can’t Tell for the choice that is the best answer.

City A City B Can’t Tell

a. Which city maintains data about only those volunteers who currently assist agencies?

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

c. In which city would it be possible for a volunteer to change which agency or agencies he or she assists?

2-29. Draw an E-R diagram for the following situation: Shi- nyShoesForAll (SSFA) is a small shoe repair shop located in a suburban town in the Boston area. SSFA repairs shoes, bags, wallets, luggage, and other similar items. Its customers are individuals and small businesses. The store wants to track the categories to which a customer belongs. SSFA also needs each customer ’s name and phone number. A job at SSFA is initiated when a customer brings an item or a set of items to be repaired to the shop. At that time, an SSFA employee evaluates the condition of the items to be repaired and gives a separate esti- mate of the repair cost for each item. The employee also

City A

Assists Assists

City B

VOLUNTEERAGENCY AGENCY VOLUNTEER

FIGURE 2-25 Diagram for Problem and Exercise 2-28

M02B_HOFF3359_13_GE_C02.indd 136 12/04/19 12:08 PM

2 • Modeling Data in the Organization 137

MILLENNIUM COLLEGE GRADE REPORT FALL SEMESTER 2018

NAME: Emily Williams ID: 268300458 CAMPUS ADDRESS: 208 Brooks Hall MAJOR: Information Systems

COURSE ID

INSTRUCTOR NAME

TITLE GRADE

IS 350 Database Mgt. Codd B104 A BIS 465 System Analysis Parsons B317

INSTRUCTOR LOCATION

FIGURE 2-26 Grade report

estimates the completion date for the entire job. Each of the items to be repaired will be classified into one of many item types (such as shoes, luggage, etc.); it should be possible and easy to create new item types even before any item is assigned to a type and to remember previous item types when no item in the database is currently of that type. At the time when a repair job is completed, the system should allow the completion date to be recorded as well as the date when the order is picked up. If a customer has comments regarding the job, it should be possible to capture them in the system.

2-30. Consider this situation: The faculty at a university (FAC- ULTY entity) can also be part of Board of Studies (BOARD entity). Is there a weak entity here? Why?

2-31. Because Visio does not explicitly show associative entities, it is not clear in Figure 2-22 which entity types are asso- ciative. List the associative entities in this figure. Why are there so many associative entities in Figure 2-22?

2-32. Figure 2-26 shows a grade report that is mailed to stu- dents at the end of each semester. Prepare an ERD reflect- ing the data contained in the grade report. Assume that each course is taught by one instructor. Also, draw this data model using the tool you have been told to use in the course. Explain what you chose for the identifier of each entity type on your ERD.

2-33. Add minimum and maximum cardinality notation to each of the following figures, as appropriate: a. Figure 2-5 b. Figure 2-10a c. Figure 2-12 (all parts) d. Figure 2-13c e. Figure 2-14

2-34. The Is Married To relationship in Figure 2-12a would seem to have an obvious answer in Problem and Exercise 2-33d—that is, until time plays a role in modeling data. Draw a data model for the PERSON entity type and the Is Married To relationship for each of the following variations by showing the appropriate cardinalities and including, if necessary, any attributes: a. All we need to know is who a person is currently mar-

ried to, if anyone. (This is likely what you represented in your answer to Problem and Exercise 2-33d.)

b. We need to know who a person has ever been married to, if anyone.

c. We need to know who a person has ever been married to, if anyone, as well as the date of their marriage and the date, if any, of the dissolution of their marriage.

d. The same situation as in c, but now assume (which you likely did not do in c) that the same two people can remarry each other after a dissolution of a prior mar- riage to each other.

e. In history, and even in some cultures today, there may be no legal restriction on the number of people to whom one can be currently married. Does your answer to part c of this Problem and Exercise handle this situation or must you make some changes (if so, draw a new ERD).

2-35. Figure 2-27 represents members of a library issuing books and returning them to the library. The members can be students, staff, or faculty, and their details are stored in the Member entity. A member can issue no more than 10 books. All the details on books are stored in the Books entity.

a. State the business rule for each relationship and the cardinality of each relationship, then explain them.

b. From your own understanding, identify the probable attributes and identifiers for each entity. Are there any foreign keys in the figure?

c. Suppose the library offers books only to the staff, who can issue only one book. Will this have an impact on the relationship between the Members and Books Issued entities? How? Will there be an impact on any other entity?

d. Suppose, using this ER model, the library wishes to send an overdue mail to members who have not returned the books in due time. Suggest how this can be achieved. State any assumptions.

BOOKS RETURNED

MEMBERS

BOOKS ISSUED

BOOKS

FIGURE 2-27 E-R diagram for Problem and Exercise 2-35

M02B_HOFF3359_13_GE_C02.indd 137 12/04/19 12:08 PM

138 Part II • Database Analysis and Logical Design

e. Is it possible to determine which schools do not have any of their students belonging to any club in that school? Explain.

2-36. Figure 2-28 shows two diagrams (A and B), both of which are legitimate ways to represent that a stock has a history of many prices. Which of the two diagrams do you con- sider a better way to model this situation and why?

2-37. Modify Figure 2-11b to model the following additional information requirements: The training director decides for each employee who completes each class, what course, if any, that employee should take next. The training direc- tor needs to keep track of a suggested date by when the employee should take this follow-on course. This date is the only attribute recorded about this suggestion.

2-38. Review Figure 2-8 and Figure 2-22. a. Identify any attributes in Figure 2-22 that might be

composite attributes but are not shown that way. Jus- tify your suggestions. Redraw the ERD to reflect any changes you suggest.

b. Identify any attributes in Figure 2-22 that might be multivalued attributes but are not shown that way. Jus- tify your suggestions. Redraw the ERD to reflect any changes you suggest.

c. Is it possible for the same attribute to be both com- posite and multivalued? If no, justify your answer; if yes, give an example. (Hint: Consider the CUSTOMER attributes in Figure 2-22.)

2-39. Draw an ERD for each of the following situations. (If you believe that you need to make additional assumptions, clearly state them for each situation.) Draw the same situa- tion using the tool you have been told to use in the course. a. A company has a number of employees. The attri-

butes of EMPLOYEE include Employee ID (identifier), Name, Address, and Birthdate. The company also has several projects. Attributes of PROJECT include Proj- ect ID (identifier), Project Name, and Start Date. Each employee may be assigned to one or more projects or may not be assigned to a project. A project must have at least one employee assigned and may have any number of employees assigned. An employee’s bill- ing rate may vary by project, and the company wishes to record the applicable billing rate (Billing Rate) for each employee when assigned to a particular project. Do the attribute names in this description follow the guidelines for naming attributes? If not, suggest better

names. Do you have any associative entities on your ERD? If so, what are the identifiers for those associative entities? Does your ERD allow a project to be created before it has any employees assigned to it? Explain. How would you change your ERD if the Billing Rate could change in the middle of a project?

b. A laboratory has several chemists who work on one or more projects. Chemists also may use certain chemi- cals on each project. Attributes of CHEMIST include Employee ID (identifier), Name, and Phone No. Attri- butes of PROJECT include Project ID (identifier) and Start Date. Attributes of CHEMICAL include Com- pound No and Cost. The organization wishes to record Volume Used—that is, the amount of a given chemical used by a particular chemist working on a specified project. A chemist must be assigned to at least one proj- ect and one chemical on each project to which he or she is assigned. A given chemical need not be assigned to any project, and a given project need not be assigned to either a chemist or a chemical. Provide good defini- tions for all of the relationships in this situation.

c. A college course may have one or more scheduled sec- tions or may not have a scheduled section. Attributes of COURSE include Course ID, Course Name, and Units. Attributes of SECTION include Section Number and Semester ID. Semester ID is composed of two parts: Semester and Year. Section Number is an integer (such as 1 or 2) that distinguishes one section from another for the same course but does not uniquely identify a section. How did you model SECTION? Why did you choose this way versus alternative ways to model SECTION?

d. A hospital has a large number of registered physi- cians. Attributes of PHYSICIAN include Physician ID (the identifier) and Specialty. Patients are admitted to the hospital by physicians. Attributes of PATIENT include Patient ID (the identifier) and Patient Name. Any patient who is admitted must have exactly one admitting physician. A physician may optionally admit any number of patients. Once admitted, a given patient must be treated by at least one physician. A particular physician may treat any number of patients or may not treat any patients. Whenever a patient is treated by a physician, the hospital wishes to record the details of the treatment (Treatment Detail). Components of Treat- ment Detail include Date, Time, and Results. Did you

B

STOCK

STOCK PRICE E�ective Date Price

Stock ID

A

STOCK Stock ID {Price History (Price, E�ective Date)}

FIGURE 2-28 E-R diagram for Problem and Exercise 2-36

M02B_HOFF3359_13_GE_C02.indd 138 12/04/19 12:08 PM

2 • Modeling Data in the Organization 139

draw more than one relationship between physician and patient? Why or why not? Did you include hospi- tal as an entity type? Why or why not? Does your ERD allow for the same patient to be admitted by different physicians over time? How would you include on the ERD the need to represent the date on which a patient is admitted for each time he or she is admitted?

e. The loan office in a bank receives from various par- ties requests to investigate the credit status of a cus- tomer. Each credit request is identified by a Request ID and is described by a Request Date and Requesting Party Name. The loan office also received results of credit checks. A credit check is identified by a Credit Check ID and is described by the Credit Check Date and the Credit Rating. The loan office matches credit requests with credit check results. A credit request may be recorded before its result arrives; a particular credit result may be used in support of several credit requests. Draw an ERD for this situation. Now, assume that credit results may not be reused for multiple credit requests. Redraw the ERD for this new situation using two entity types, and then redraw it again using one entity type. Which of these two versions do you prefer, and why?

f. Companies, identified by Company ID and described by Company Name and Industry Type, hire consul- tants, identified by Consultant ID and described by Consultant Name and Consultant Specialty, which is multivalued. Assume that a consultant can work for only one company at a time, and we need to track only current consulting engagements. Draw an ERD for this situation. Now, consider a new attribute, Hourly Rate, which is the rate a consultant charges a company for each hour of his or her services. Redraw the ERD to include this new attribute. Now, consider that each time a consultant works for a company, a contract is written describing the terms for this consulting engagement. Contract is identified by a composite identifier of Com- pany ID, Consultant ID, and Contract Date. Assuming that a consultant can still work for only one company at a time, redraw the ERD for this new situation. Did you move any attributes to different entity types in this latest situation? As a final situation, now consider that although a consultant can work for only one company at a time, we now need to keep the complete history of all consulting engagements for each consultant and company. Draw an ERD for this final situation. Explain why these different changes to the situation led to dif- ferent data models, if they did.

g. A parking garage in downtown Baltimore offers its ser- vices to both monthly customers, who pay a fixed fee every month, and to visitors, who pay an hourly fee (assume that the hourly fee is the same regardless of the day or time of day). Each monthly customer gets an ID assigned by the garage, and the garage wants to maintain the customer’s basic contact information. The monthly fee paid is negotiated separately for each cus- tomer, and it changes periodically; it is important for the garage to maintain a history of the fee details for each customer. The garage has more than 700 parking spots, each of which is equipped with a sensor that rec- ognizes whether there is a car in the spot; in addition, the sensor can read each monthly customer’s customer

ID card with an RFID reader and, thus, knows which monthly visitor has parked at which spot and when. Each spot is also equipped with a camera that is able to take a picture of each visitor’s license plate number; this information is stored to help locate any vehicle that an owner has misplaced. The system should keep track of each time a parking spot is used, including an image of the license plate, start and end times, and a link to the monthly customer, if appropriate.

h. Each case handled by the law firm of Dewey, Cheetim, and Howe has a unique case number; a date opened, date closed, and judgment description are also kept on each case. A case is brought by one or more plain- tiffs, and the same plaintiff may be involved in many cases. Each plaintiff in each case has a requested judgment characteristic, such as a requested dollar award, possession of some asset, or other outcome. A case is against one or more defendants, and the same defendant may be involved in many cases. A plain- tiff or defendant may be a person or an organization. Over time, the same person or organization may be a defendant or a plaintiff in cases. In either situation, such legal entities are identified by an entity number, and other attributes are name and net worth. As you develop the ERD for this problem, follow good data naming guidelines.

i. A professional society, CAM, organizes hundreds of meetings for its members every year, and it would like to develop an application to support the organizational processes needed to ensure the success of these meet- ings. Each of the meetings will have five to 500 partici- pants (sometimes even more), and each meeting takes place in a specific hotel in a specific city in a specific state. The organizers need to know each participant’s full name, cell phone number, and e-mail address. CAM wants to maintain information regarding dietary restrictions for each participant at the general level, but the restrictions also need to be confirmed and recorded separately for each meeting. For each member’s par- ticipation for a specific meeting, the organizers need to know how he or she will travel to the meeting and when he or she is planning to arrive and leave. It is important that CAM can produce an accurate report on how many meetings have been organized in a specific city or a specific state.

2-40. Star Hoist is owned by Darth and his wife Ella Vader. The company has had its ups and downs since Darth and Ella built it from the ground up several years ago. The com- pany had some initial difficulties when Darth’s brother, Tacksi, was their accountant and got in trouble with the IRS. Finally, the company is doing well, and the owners are ready to expand the business to new heights. Star Hoist sells and installs replacement parts for lifts and similar equipment from a variety of manufacturers. Business can be very competitive, especially from the original manufac- turers, which directly sell replacement parts and service to end customers. Darth and Ella need every aspect of their business to work smoothly so that they don’t get the shaft in deals with customers. Darth and Ella try to encourage their employees to do the best they can for each customer, which is symbolized by the company motto: “Oh, be the one.” There are many rogue competitors, so accurate ser- vice is also key for Star Hoist.

M02B_HOFF3359_13_GE_C02.indd 139 12/04/19 12:08 PM

140 Part II • Database Analysis and Logical Design

You are to draw an ERD for Star Hoist. The fundamental need for Star Hoist is a computer database to keep track of their in-house inventory and of installed parts. Because the business offers negotiated warranties with customers, all parts installed at customer sites need to be tracked. Each part instance is identified by a number assigned by Ella, but because a particular part might come from the original manufacturer or an alternative supplier, the database must record the source of each part and its sup- plier ’s part number. In general, a part has a description and standard prices that Star Hoist charges a customer for the part and its installation. Each instance of the part has a cost to Star, based on what the supplier actually charged when Star Hoist acquired that part (many parts, due to their materials, have frequent price changes). Each particular part instance must be tracked, whether it is in inventory or sold to a particular customer. When a part is sold to a customer, there is a negotiated warranty end date, until which time Star assumes all replacement costs for the part, and an actual selling and installation price. Customers have a name, account number, contact per- son name, and a code that specifies special terms that have been negotiated with each customer. Each supplier has a name, Star ’s account number with that supplier, and the phone number for the supplier. Each supplier can supply only certain parts. Because many parts can be sourced from multiple suppliers, each part in inven- tory or installed at a customer must be associated with its source supplier; in addition, Star also needs to know which suppliers can supply which parts. Because many of the parts are very expensive, Darth has placed a limit on how many part instances of a given part can be held in the company’s inventory. The limit is three part instances to be held in inventory. As Darth tells the customers, “May the fourth be with you.”

2-41. The management department at Scholars University holds workshops annually in collaboration with two other uni- versities. The department wishes to create a database with the following entities and attributes: • Faculty delivering the workshop: FacultyID, Name,

Email, Address (street, city, state, zip code) and Contact Number

• Workshop: WorkshopID, Year, Theme, Venue • Venue: LocationID, University Name, Address (street,

city, state, zip code), Contact Number • Participants: ParticipantID, Name, Designation, Affiliating

Institute, Charges The participating universities have come up with the fol- lowing rules: • Venue rotates among the three universities, repeating

every three years. • A total of 50 participants are allowed in each workshop

annually on a first-come-first-serve basis. • Charges vary with the designation of the participant. • Accommodation is not provided by any host and other

expenses are not entertained either. Draw an ERD for this situation as well as a data model tool. State any assumptions that you have made.

2-42. Each semester, each student must be assigned an adviser who counsels students about degree requirements and helps students register for classes. Each student must reg-

ister for classes with the help of an adviser, but if the stu- dent’s assigned adviser is not available, the student may register with any adviser. We must keep track of students, the assigned adviser for each, and the name of the adviser with whom the student registered for the current term. Represent this situation of students and advisers with an E-R diagram. Also, draw a data model for this situation using the tool you have been told to use in your course.

2-43. In the chapter, when describing Figure 2-4a, it was argued that the Received and Summarizes relationships and TREASURER entity were not necessary. Within the context of this explanation, this is true. Now, consider a slightly different situation. Suppose it is necessary, for compliance purposes (e.g., Sarbanes-Oxley compli- ance), to know when each expense report was produced and which officers (not just the treasurer) received each expense report and when each signed off on that report. Redraw Figure 2-4a, now including any attributes and relationships required for this revised situation.

2-44. Virtual Campus (VC) is a social media firm that spe- cializes in creating virtual meeting places for students, faculty, staff, and others associated with different col- lege campuses. VC was started as a student project in a database class at Cyber University, an online polytechnic college, with headquarters in a research park in Dayton, Ohio. The following parts of this exercise relate to dif- ferent phases in the development of the database VC now provides to client institutions to support a threaded discussion application. Your assignment is to draw an ERD to represent each phase of the development of the VC database and to answer questions that clients raised about the capabilities (business rules) of the data- base in each phase. The description of each phase will state specific requirements as seen by clients, but other requirements may be implied or possibly should be implemented in the design slightly differently than the clients might see them, so be careful to not limit yourself to only the specifics provided. a. The first phase was fairly simplistic. Draw an ERD to

represent this initial phase, described by the following: • A client may maintain several social media sites

(e.g., for intercollegiate sports, academics, local food and beverage outlets, or a specific student organiza- tion). Each site has attributes of Site Identifier, Site Name, Site Purpose, Site Administrator, and Site Creation Date.

• Any person may become a participant in any public site. Persons need to register with the client’s social media presence to participate in any site, and when they do the person is assigned a Person Identifier; the person provides his or her Nickname and Status (e.g., student, faculty, staff, or friend, or possibly several such values); the Date Joined the site is automatically gen- erated. A person may also include other information, which is available to other persons on the site; this infor- mation includes Name, Twitter Handle, Facebook Page link, and SMS Contact Number. Anyone may register (no official association with the client is necessary).

• An account is created each time a person registers to use a particular site. An account is described by an Account ID, User Name, Password, Date Created, Date Terminated, and Date/Time the person most recently used that account.

M02B_HOFF3359_13_GE_C02.indd 140 12/04/19 12:08 PM

2 • Modeling Data in the Organization 141

• Using an account, a person creates a posting, or mes- sage, for others to read. A posting has a Posting Date/ Time and Content. The person posting the message may also add a Date when the posting should be made invisible to other users.

• A person is permitted to have multiple accounts, each of which is for only one site.

• A person, over time, may create multiple postings from an account.

b. After the first phase, a representative from one of the initial clients asked if it were possible for a person to have multiple accounts on the same site. Answer this question based on your ERD from part a of this exer- cise. If your answer is yes, could you enforce via the ERD a business rule of only one account per site per person, or would other than a data modeling require- ment be necessary? If your answer is no, justify how your ERD enforces this rule.

c. The database for the first phase certainly provided only the basics. VC quickly determined that two additional features needed to be added to the database design, as follows (draw a revised ERD to represent the expanded second phase database): • From their accounts, persons might respond to post-

ings with an additional posting. Thus, postings may form threads, or networks of response postings, which then may have other response postings and so forth.

• It also became important to track not only postings but also when persons from their accounts read a posting. This requirement is needed to produce site usage reports concerning when postings are made, when they are read and by whom, frequency of reading, etc.

d. Clients liked the improvements to the social media application supported by the database from the sec- ond phase. How useful the social media application is depends, in part, on questions administrators at a client organization might be able to answer from inquiries against the database using reports or online queries. For each of the example client inquiries that follow, jus- tify for your answer to part c whether your database could provide answers to that inquiry (if you already know SQL, you could provide justification by show- ing the appropriate SQL query; otherwise, explain the entities, attributes, and relationships from your ERD in part c that would be necessary to produce the desired result): • How many postings has each person created for

each site? • Which postings appear under multiple sites? • Has any person created a posting and then responded

to his or her own posting before any other person has read the original posting?

• Which sites, if any, have no associated postings? e. The third phase of database development by VC dealt

with one of the hazards of social media sites—irrespon- sible, objectionable, or harmful postings (e.g., bully- ing or inappropriate language). So for the third phase, draw a revised ERD to the ERD you drew for the sec- ond phase to represent the following: • Any person from one of their accounts may file a

complaint about any posting. Most postings, of

course, are legitimate and not offensive, but some postings generate lots of complaints. Each com- plaint has a Complaint ID, Date/Time the com- plaint is posted, the Content of the complaint, and a Resolution Code. Complaints and the status of resolution are visible to only the person making the complaint and to the site administrator.

• The administrator for the site about which a com- plaint has been submitted (not necessarily a person in the database, and each site may have a differ- ent administrator) reviews complaints. If a com- plaint is worthy, the associated offensive posting is marked as removed from the site; however, the posting stays in the database so that special reports can be produced to summarize complaints in vari- ous ways, such as by person, so that persons who make repeated objectionable postings can be dealt with. In any case, the site administrator after his or her review fills in the date of resolution and the Resolution Code value for the complaint. As stated, only the site administrator and the complaining person, not other persons with accounts on the site, see complaints for postings on the associated site. Postings marked as removed as well as responses to these postings are then no longer seen by the other persons.

f. You may see various additional capabilities for the VC database. However, in the final phase you will con- sider in this exercise, you are to create an expansion of the ERD you drew for phase three to handle the following: • Not all sites are public, that is, open for anyone to

create an account. A person may create one or more sites as well as groups and then invite other per- sons in a group to be part of a site he or she has cre- ated. A group has a Group ID, Group Name, Date Created, Date Terminated, Purpose, and Number of Members.

• The person creating a “private” site is then, by default, the site administrator for that site.

• Only the members of a group associated with a pri- vate site may then create accounts for that site, post to that site, and perform any other activities for that site.

2-45. After completing a course in database management, you are asked to develop a preliminary ERD for a gym database. The entity types that should be included are as shown in Table 2-3. During further discussions you dis- cover the following: • The employees can be staff or trainers. The Employee

type field is used to distinguish between the two, which take the values “S” and “T” for staff and trainer respectively.

• Each member can opt for one or more programs. • The gym offers several programs. A program might not

be chosen by any member of the gym. • The gym’s management wishes to track the payment

details of the members (Amount, Mode of Payment, and Date of Payment). Suggest how they can track this.

Construct an ER diagram to represent your findings from this situation. Establish the relationship and identify the business rules and how they have been modeled on the

M02B_HOFF3359_13_GE_C02.indd 141 12/04/19 12:08 PM

142 Part II • Database Analysis and Logical Design

ER diagram. What is the identifier for ProgramOpted entity—is it composite or primary? If payment informa- tion is also to be stored in this entity, which other attri- butes are you likely to add? Are there any foreign keys? If there are, what are they? Draw a data model for this situa- tion using the tool you have been told to use in the course.

2-46. Draw an ERD for the following situation, which is based on Lapowsky (2016): The Miami-Dade County, Florida, court system believes that jail populations can be reduced, reincarceration rates lowered, and court system costs lessened and, most important, that bet- ter outcomes can occur for people in and potentially in the court system if there is a database that coordinates activities for county jails, metal health facilities, shelters, and hospitals. Based on the contents of this database, algorithms can be used to predict what kind of help a person might need to reduce his or her involvement in the justice system. Eventually, such a database could be extensive (involving many agencies and lots of personal history and demographic data) once privacy issues are resolved. However, for now, the desire is to create a prototype database with the following data. Data about persons will be stored in the database, including profes- sionals who work for the various participating agen- cies as well as those who have contact with an agency (e.g., someone who is a client of a mental health facility, who is incarcerated, or both). Data about people include name, birth date, education level, job title (if the person is an employee of one of the participating agencies), and (permanent) address. Some people in the system will have been prescribed certain medicines while in the care of county hospitals and mental health facilities. A medicine has a name and a manufacturer. Each prescrip- tion is for a particular medicine and has a dosage. A pre- scription is due to some diagnosis, which was identified on a certain date, to treat some illness, was diagnosed by some facility professional, and has notes explaining family history at the time of the diagnosis. Each illness has a name and some medicines or other treatments commonly prescribed (e.g., certain type of counseling). Each participating agency is of a certain type (e.g., crim- inal justice, mental health) and has a name and a contact person. People visit or contact an agency (e.g., they are arrested by the justice system or stay at a shelter). For each contact a person has with an agency, the database needs to record the contact date, employment status at

time of contact, address at time of contact, reason for visit/contact, and the name of the responsible agency employee.

2-47. Draw an ERD diagram for the following situation: The Sensing Building Company (SBC) installs wireless micro- sensors throughout buildings and building campuses to give building managers, maintenance personnel, and oth- ers real-time data about the status of almost any part of a building. Sensors can be placed on doors, trash cans, plumbing fixtures, windows, lighting fixtures, and heat- ing systems—almost any building element. Sensor data are used to create dashboards to indicate when, for exam- ple, a plumber needs to be dispatched to fix a leaking pipe in a particular wall of an identified building. In addition, data are analyzed over time to determine, for example, where and when electricity and heating/cooling are used so that measures can be taken to reduce energy consump- tion costs. All the collected data must be kept in a data- base, although some data are used to trigger alerts when immediate action must be taken in response to a security or safety issue. Each sensor has various features, depend- ing on its purpose and location. For example, a sensor on a trash can is designed to periodically transmit how full the container is and to immediately send a message when the can is within 5 percent of being full or when the can is no longer upright. In general, each sensor sends peri- odic as well as critical event messages, the latter of which may cause an alert and immediate action to be taken. The following is a somewhat simplified description of the database requirements. Data must be kept on each sensor, sensor transmission, building personnel, building, loca- tion within or outside a building, alert, and action taken. A sensor has a unique 12 character ID, a title, type, date installed, frequency of transmission, and location. Each sensor transmission includes the sensor ID, time stamp, and one or more readings. Personnel have an ID, name, job title, a set of skills, and a set of locations for which he or she is responsible. Each building has a number, descrip- tion, and a senior person responsible for the building. Each location has an ID, type of location, and coordinates of where within a building or the campus it is. An alert has an ID, the ID of the sensor transmission(s) that generated the alert, and a time stamp for when the alert occurred. Finally, an action has an ID, the ID of the alert that caused the action, the individual or several personnel taking the action, and the result of the action.

TABLE 2-3 Entity Types for Problem and Exercise 2-45

Member The members of the gym. Identifier is MemberID, and other attributes are Name, Age, Gender, Email, Contact number, Address, LocationID.

Employees Trainers and other staff at the gym. Identifier is EmployeeID, and other attributes are Employee Type, Name, Email, Contact Number, Reporting Time, Address, Location

Program Available Program for working out at the gym, such as aerobics and weight training. Identifier is ProgramID, and other attributes are Program Name, Duration, Charges.

Program Opted Which member at the gym has opted for which program. This entity contains the fields MemberID, ProgramID, Starting Date, Ending Date.

Location The region of operation of the gym that has several branches in the city. Identifier is LocationID, Name, Contact Number, Address.

M02B_HOFF3359_13_GE_C02.indd 142 12/04/19 12:08 PM

2 • Modeling Data in the Organization 143

2-48. Draw an ERD for the following situation. (State any assumptions you believe you have to make in order to develop a complete diagram.) Also, draw a data model for this situation using the tool you have been told to use in your course: Stillwater Antiques buys and sells one- of-a-kind antiques of all kinds (e.g., furniture, jewelry, china, and clothing). Each item is uniquely identified by an item number and is also characterized by a descrip- tion, asking price, condition, and open-ended comments. Stillwater works with many different individuals, called clients, who sell items to and buy items from the store. Some clients only sell items to Stillwater, some only buy items, and some others both sell and buy. A client is iden- tified by a client number and is also described by a client name and client address. When Stillwater sells an item in stock to a client, the owners want to record the commis- sion paid, the actual selling price, sales tax (tax of zero indicates a tax exempt sale), and date sold. When Stillwa- ter buys an item from a client, the owners want to record the purchase cost, date purchased, and condition at time of purchase.

2-49. Draw an ERD for the following situation. (State any assumptions you believe you have to make in order to develop a complete diagram.) Also, draw a data model for this situation using the tool you have been told to use in your course: The A. M. Honka School of Business operates international business programs in 10 locations through- out Europe. The school had its first class of 9,000 graduates in 1965. The school keeps track of each graduate’s student number, name when a student, country of birth, current country of citizenship, current name, and current home address and current business address, as well as the name of each major the student completed. (Each student has one or two majors.) To maintain strong ties to its alumni, the school distributes various communications, including publications and messages. Each communication has a title, date, and medium (e.g., printed magazine, electronic newsletter, invitation). The school needs to keep track of which graduates have received which communications. For each communication with a graduate, a comment may be recorded with any feedback the school received from the graduate. When a school official knows that he or she will be meeting or talking to a graduate, a report is pro- duced showing the latest information about that graduate and the information learned during the past two years of comments from that graduate.

2-50. Wally Los Gatos, owner of Wally’s Wonderful World of Wallcoverings, Etc., has hired you as a consultant to design a database management system for his new online marketplace for wallpaper, draperies, and home deco- rating accessories. He would like to track sales, prospec- tive sales, and customers. Ultimately, he’d like to become the leading online retailer for all things related to home decorating. During an initial meeting with Wally, you and Wally developed a list of business requirements to begin the design of an E-R model for the database to support his business needs. a. Wally was called away unexpectedly after only a short

discussion with you, due to a sticky situation with the pre-pasted line of wall coverings he sells. He gave you only a brief description of his needs and asked that you fill in details for what you expect he might need for these requirements. Wally expected to be away for only

a short time, so he asked that you go ahead with some first suggestions for the database; but he said, “Keep it basic for now, we’ll do the faux finishes later.” Before Wally left, he requested the following features for his system: • At a basic level, Wally needs to track his customers

(both those who have bought and those Wally has identified as prospective buyers based on his prior brick-and-mortar business outlets), the products he sells, and the products they have bought.

• Wally wants a variety of demographic data about his customers so he can better understand who is buying his products. He’d like a few suggestions from you on appropriate demographic data, but he definitely wants to know customer interests, hob- bies, and activities that might help him proactively suggest products customers might like.

b. True to his word, Wally soon returned, but said he could only step into the room for a short time because the new Tesla he had ordered had been delivered, and he wanted to take it for a test drive. But before he and his friend Elon left, he had a few questions that he wanted the database to allow him to answer, includ- ing the following (you can answer Wally with an SQL query that would produce the result because Wally is proficient in SQL or by explaining the entities, attri- butes, and relationships that would allow the ques- tions to be answered): • Would the database be able to tell him which other

customers had bought the same product a given customer or prospective customer had bought or was considering buying?

• Would the database be able to tell him even something deeper, that is, what other products other customers bought who also bought the product the customer just bought (i.e., an opportunity for cross-selling)?

• Would he be able to find other customers with at least three interests that overlap with those of a given customer so that he can suggest to these other cus- tomers other products they might want to purchase?

Prepare queries or explanations to demonstrate for Wally why your database design in part a of this exer- cise can support these needs or draw a revised design to support these specific questions.

c. Wally is thrilled with his new Tesla and returns from the test drive eager to expand his business to now pay for this new car. The test drive was so invigorating that it helped him to generate more ideas for the new online shopping site, including the following requirements: • Wally wants to be able to suggest products for cus-

tomers to buy. Wally knows that most of the prod- ucts he sells have similar alternatives that a customer might want to consider. Similarity is fairly subtle, so he or his staff would have to specify for each product what other products, if any, are similar.

• Wally also thinks that he can improve sales by reminding customers about products they have pre- viously considered or viewed when on his online marketplace.

Unfortunately, Wally’s administrative assistant, Helen, in her hunt for Wally, knocked on the door and told Wally that his first born child, Julia, had just come in asking to see her father so that she could show him

M02B_HOFF3359_13_GE_C02.indd 143 12/04/19 12:08 PM

144 Part II • Database Analysis and Logical Design

her new tattoo, introduce him to her new “goth” boy- friend, and let him know about her new life plans. This declaration, obviously, got Wally’s attention. Wally left abruptly but asked that you fill in the blanks for these new database requirements.

d. Fortunately, Wally’s assistant was just kidding, and the staff had actually thrown a surprise birthday party for Wally. They needed Wally in the staff dining room quickly before the ice cream melted and the festive draperies adorning the table of presents had to be returned to the warehouse for shipment to Tokyo for display at the summer Olympics. Now overjoyed by the warm reception from his trusted associates, Wally was even more enthusiastic about making his company successful. Wally came in with two additional require- ments for this database: • Wally had learned the hard way that in today’s

world, some of his customers have multiple homes or properties for which they order his products. Thus, different orders for the same customer may go to different addresses, but several orders for the same customer often go to the same address.

• Customers also like to see what other people think about products they are considering to buy. So, the database needs to be able to allow customers to rate and review products they buy and for other cus- tomers considering purchasing a product to see the reviews and ratings from those who have already purchased the product being considered. Wally also wants to know what reviews customers have viewed so that he can tell which reviews might be influencing purchases.

Yet again, Wally has to leave the meeting, this time because it is time for his weekly pickle ball game, and he doesn’t want to brush off his partner in the ladder tournament, which he and partner now lead. He asks that you go ahead and work on adding these require- ments to the database, and he’ll be back after he and his partner hang their new trophy in Wally’s den.

e. Although still a little sweaty and not in his normal dap- per business attire, Wally triumphantly hobbled back to the meeting room. Wally’s thigh was wrapped in what seemed to be a whole reel of painter’s tape (because he didn’t have any sports tape), nursing his agony of victory. Before limping off to his doctor, Wally, ever engaged in his business, wanted to make sure your database design could handle the following needs: • One of the affinities people have for buying is what

other people in their same geographical area are buying (a kind of “keep up with the Jones” phe- nomenon). Justify to Wally why your database design can support this requirement or suggest how the design can be changed to meet this need.

• Customers want to search for possible products based on categories and characteristics, such as paint brushes, lamps, bronze color, etc.

• Customers want to have choices for the sequence in which products are shown to them, such as by rat- ing, popularity, and price.

Justify to Wally why your database design can support these needs or redesign your database to support these additional requirements.

2-51. Doctors Information Technology (DocIT) is an IT services company supporting medical practices with a variety of computer technologies to make medical offices more effi- cient and less costly to run. Medical offices are rapidly becoming automated with electronic medical records, automated insurance claims processing and prescription submissions, patient billing, and other typical aspects of medical practices. In this assignment, you will address only insurance claims processing; however, what you develop must be able to be generalized and expanded to these other areas of a medical practice. Your assign- ment is to draw an ERD to represent each phase of the development of an insurance claims processing database and to answer questions that clients might raise about the capabilities of the application the database supports in each phase. a. The first phase deals with a few core elements. Draw

an ERD to represent this initial phase, described by the following: • A patient is assigned a patient ID, and you need to

keep track of a patient’s gender, date of birth, name, current address, and list of allergies.

• A staff member (doctor, nurse, physician’s assistant, etc.) has a staff ID, job title, gender, name, address, and list of degrees or qualifications.

• A patient may be included in the database even if no staff member has ever seen the patient (e.g., family member of another patient or a transfer from another medical practice). Similarly, some staff members never have a patient contact that requires a claim to be processed (e.g., a receptionist greeting a patient does not generate a claim).

• A patient sees a staff member via an appointment. An appointment has an appointment ID, a date and time of when the appointment is scheduled or when it occurred as well as a date and time when the appointment was made, and a list of reasons for the appointment.

b. As was noted in part a of this exercise the first phase, information about multiple members of the same fam- ily may need to be stored in the database because they are all patients. Actually, there is a broader need. A medical practice may need to recognize various people related to a particular patient (e.g., spouse, child, care- giver, power of attorney, an administrator at a nursing home, etc.) who can see patient information and make emergency medical decisions on behalf of the patient. Augment your answer to part a of this exercise to rep- resent the relationships between people in the database and the nature of any relationships.

c. In the next phase, you will extend the database design to begin to handle insurance claims. Draw a revised ERD to your answer to part b of this exercise to repre- sent the expanded second phase database: • Each appointment may generate several insurance

claims (some patients are self-pay, with no insur- ance coverage). Each claim is for a specific action taken in the medical practice, such as seeing a staff member, performing a test, administering a specific treatment, etc. Each claim has an ID, a claim code (taken from a list of standard codes that all insur- ance companies recognize), date the action was

M02B_HOFF3359_13_GE_C02.indd 144 12/04/19 12:08 PM

2 • Modeling Data in the Organization 145

done, date the claim was filed, amount claimed, amount paid on the claim, optionally a reason code for not paying full amount, and the date the claim was (partially) paid.

• Each patient may be insured under policies with many insurance companies. Each patient policy has a policy number; possibly a group code; a designation of whether the policy is primary, secondary, tertiary, or whatever in the sequence of processing claims for a given patient; and the type of coverage (e.g., medi- cines, office visit, outpatient procedure).

• A medical practice deals with many insurance com- panies because of the policies for their patients. Each company has an ID, name, mailing address, IP address, and company contact person.

• Each claim is filed under exactly one policy with one insurance company. If for some reason a partic- ular action with a patient necessitates more than one insurance company to be involved, then a separate claim is filed with each insurance company (e.g., a patient might reach some reimbursement limit under her primary policy, so a second claim must be filed for the same action with the company associ- ated with the secondary policy).

d. How useful and sufficient a database is depends, in part, on questions it can be used to answer using reports or online queries. For each of the example inquiries that follow, justify for your answer to part c of this exercise whether your database could provide answers to that inquiry (if you already know SQL, you could provide justification by showing the appropriate SQL query; otherwise, explain the entities, attributes, and relationships from your ERD in part c that would be necessary to produce the desired result):

• How many claims are currently fully unreimbursed? • Which insurance company has the most fully or par-

tially unreimbursed claims? • What is the total claims amount per staff member? • Is there a potential conflict of interest in which a

staff member is related to a patient for which that staff member has generated a claim?

e. As was stated in previous parts of this exercise, some claims may be only partially paid or even denied by the insurance company. When this occurs, the medical practice may take follow-up steps to resolve the dis- puted claim, and this can cycle through various nego- tiation stages. Draw a revised ERD to replace the ERD you drew for part c to represent the following: • Each disputed claim may be processed through sev-

eral stages. In each stage, the medical practice needs to know the date processed, the dispute code caus- ing the processing step, the staff person handling the dispute in this stage, the date when this stage ends, and a description of the dispute status at the end of the stage.

• There is no limit to the number of stages a dispute may go through.

• One possible result of a disputed claim processing stage is the submission of a new claim, but usually it is the same original claim that is processed in sub- sequent stages.

2-52. Review your answer to Problem and Exercise 2-49; if nec- essary, change the names of the entities, attributes, and relationships to conform to the naming guidelines pre- sented in this chapter. Then, using the definition guide- lines, write a definition for each entity, attribute, and relationship. If necessary, state assumptions so that each definition is as complete as possible.

Field Exercises

2-53. Interview a database analyst and ask how they go about identifying business rules in the data modeling process. How do they decide to document what business rules they will gather, utilize, manage, and consider while develop- ing an E-R model? How do they decide what falls under the scope of business rules? Identify some of the best prac- tices in the industry as well.

2-54. Interview a database analyst or a systems analyst. How do they extract business rules for ER modeling? Ask for specific sources. Are they all listed in the text? Did they purchase an ER model and customize it or design it on their own? How did they decide on naming entity types? Ask the analyst or administrator to show one or two ER diagrams of the pri- mary databases. Study the diagram carefully and look for multiple relationships in the diagram. How have they been modeled? What is the role of identifiers here?

2-55. Ask a database or systems analyst to give you examples of unary, binary, and ternary relationships that the analyst has dealt with personally at his or her company. Ask which is most common and why. Ask them if they ever model weak or dependent entities and, if so, what they use for the identifier of such entities.

2-56. Ask a database or systems analyst in a local company to show you an E-R diagram for one of the organization’s primary databases. Ask questions to be sure you under- stand what each entity, attribute, and relationship means. Does this organization use the same E-R notation used, in this text? If not, what other or alternative symbols are used, and what do these symbols mean? Does this orga- nization model associative entities on the E-R diagram? If not, how are associative entities modeled? What meta- data are kept about the objects on the E-R diagram?

2-57. For the same E-R diagram used in Field Exercise 2-56 or for a different database in the same or a different organiza- tion, identify any uses of time stamping or other means to model time-dependent data. Why are time-dependent data necessary for those who use this database? Would the E-R diagram be much simpler if it were not necessary to represent the history of attribute values?

2-58. Research various graphics and drawing packages, such as Microsoft Office and SmartDraw, and compare the E-R dia- gramming capabilities of each. Is each package capable of using the notation found in this text? Is it possible to draw a ternary or higher-order relationship with each package?

M02B_HOFF3359_13_GE_C02.indd 145 12/04/19 12:08 PM

146 Part II • Database Analysis and Logical Design

References

Aranow, E. B. 1989. “Developing Good Data Definitions.” Data- base Programming & Design 2,8 (August): 36–39.

Bruce, T. A. 1992. Designing Quality Databases with IDEF1X Information Models. New York: Dorset House.

Chen, P. P.-S. 1976. “The Entity-Relationship Model—Toward a Unified View of Data.” ACM Transactions on Database Sys- tems 1,1 (March): 9–36.

Elmasri, R., and S. B. Navathe. 1994. Fundamentals of Database Systems. 2d ed. Menlo Park, CA: Benjamin/Cummings.

Embarcadero Technologies. 2014. “Seven Deadly Sins of Data- base Design: How to Avoid the Worst Problems in Database Design.” April. Available at www.embarcadero.com.

Gottesdiener, E. 1997. “Business Rules Show Power, Promise.” Application Development Trends 4,3 (March): 36–54.

Gottesdiener, E. 1999. “Turning Rules into Requirements.” Application Development Trends 6,7 (July): 37–50.

GUIDE. 1997 (October).”GUIDE Business Rules Project.” Final Report, revision 1.2.

Haughey, T. 2010 (March) “The Return on Investment (ROI) of Data Modeling.” White paper published by Computer Associates–Erwin Division.

Hay, D. C. 2003. “What Exactly IS a Data Model?” Parts 1, 2, and 3. DM Review 13,2 (February: 24–26), 3 (March: 48–50), and 4 (April: 20–22, 46).

Johnson, T. and R. Weis. 2007. “Time and Time Again: Manag- ing Time in Relational Databases, Part 1.” May. DM Review. This and other related articles by Johnson and Weis on

“Time and Time Again” can be found by doing a search on Weis at www.information-management.com.

Lapowsky, I. 2016. “The Justice Machine: Law Enforcement and Mental Health Workers Are Getting Help from Algo- rithms.” Wired 24,11 (November): 68–70.

Moriarty, T. 2000. “The Right Tool for the Job.” Intelligent Enter- prise 3,9 (June 5): 68, 70–71.

Owen, J. 2004. “Putting Rules Engines to Work.” InfoWorld (June 28): 35–41.

Plotkin, D. 1999. “Business Rules Everywhere.” Intelligent Enterprise 2,4 (March 30): 37–44.

Salin, T. 1990. “What’s in a Name?” Database Programming & Design 3,3 (March): 55–58.

Song, I.-Y., M. Evans, and E. K. Park. 1995. “A Comparative Analysis of Entity-Relationship Diagrams.” Journal of Com- puter & Software Engineering 3,4: 427–59.

Storey, V. C. 1991. “Relational Database Design Based on the Entity-Relationship Model.” Data and Knowledge Engineering 7: 47–83.

Teorey, T. J., D. Yang, and J. P. Fry. 1986. “A Logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model.” Computing Surveys 18, 2 (June): 197–221.

Valacich, J. S., and J. F. George. 2016. Modern Systems Analysis and Design. 8th ed. Upper Saddle River, NJ: Prentice Hall.

von Halle, B. 1997. “Digging for Business Rules.” Database Pro- gramming & Design 8,11: 11–13.

Further Reading

Batini, C., S. Ceri, and S. B. Navathe. 1992. Conceptual Database Design: An Entity-Relationship Approach. Menlo Park, CA: Benjamin/Cummings.

Bodart, F., A. Patel, M. Sim, and R. Weber. 2001. “Should Optional Properties Be Used in Conceptual Modelling? A Theory and Three Empirical Tests.” Information Systems Research 12,4 (December): 384–405.

Carlis, J., and J. Maguire. 2001. Mastering Data Modeling: A User- Driven Approach. Upper Saddle River, NJ: Prentice Hall.

Keuffel, W. 1996. “Battle of the Modeling Techniques.” DBMS 9,8 (August): 83, 84, 86, 97.

Moody, D. 1996. “The Seven Habits of Highly Effective Data Modelers.” Database Programming & Design 9,10 (October): 57, 58, 60–62, 64.

Teorey, T. 1999. Database Modeling & Design. 3d ed. San Fran- cisco, CA: Morgan Kaufman.

Tillman, G. 1994. “Should You Model Derived Data?” DBMS 7,11 (November): 88, 90.

Tillman, G. 1995. “Data Modeling Rules of Thumb.” DBMS 8,8 (August): 70, 72, 74, 76, 80–82, 87.

Web Resources

www.adtmag.com Web site of Application Development Trends, a leading publication on the practice of information systems development.

www.axisboulder.com Web site for one vendor of business rules software.

www.businessrulesgroup.org Web site of the Business Rules Group, formerly part of GUIDE International, which formu- lates and supports standards about business rules.

http://en.wikipedia.org/wiki/Entity-relationship_model The Wikipedia entry for entity-relationship model, with an

explanation of the origins of the crow’s foot notation, which is used in this book.

http://ss64.com/ora/syntax-naming.html Web site that suggests naming conventions for entities, attributes, and relation- ships within an Oracle database environment.

www.tdan.com Web site of The Data Administration Newsletter, an online journal that includes articles on a wide variety of data management topics. This Web site is considered a “must follow” Web site for data management professionals.

M02B_HOFF3359_13_GE_C02.indd 146 12/04/19 12:08 PM

Case Description

Martin was very impressed with your project plan and has given you the go-ahead for the project. He also indicates to you that he has e-mails from several key staff members that should help with the design of the system. The first is from Alex Martin (administrative assistant to Pat Smith, an artist manager). Pat is on vacation, and Martin has promised that Pat’s perspective will be provided at a later date. The other two are from Dale Dylan, an artist who Pat manages, and Sandy Wallis, an event organizer. The text of these e-mails is provided below.

E-mail from Alex Martin, Administrative Assistant

My name is Alex Martin, and I am the administrative assis- tant to Pat Smith. While Pat’s role is to create and maintain relationships with our clients and the event organizers, I am responsible for running the show at the operational level. I take care of Pat’s phone calls while Pat is on the road, respond to inquiries and relay the urgent ones to Pat, write letters to organizers and artists, collect information on prospective art- ists, send bills to the event organizers and make sure that they pay their bills, take care of the artist accounts, and arrange Pat’s travel (and keep track of travel costs). Most of my work I manage with Word and simple Excel spreadsheets, but it would be very useful to be able to have a system that would help me to keep track of the event fees that have been agreed upon, the events that have been successfully completed, can- cellations (in the current system, I sometimes don’t get infor- mation about a cancellation and I end up sending an invoice for a cancelled concert—pretty embarrassing), payments that need to be made to the artists, etc. Pat and other managers seem to think that it would be a good idea if they could better track their travel costs and the impact these costs have on their income.

We don’t have a very good system for managing our art- ist accounts because we have separate spreadsheets for keep- ing track of a particular artist’s fees earned and the expenses incurred, and then at the end of each month we manually create a simple statement for each of the artists. This is a lot of work, and it would make much more sense to have a computer sys- tem that would allow us to be able to keep the books constantly up to date.

A big thing for me is to keep track of the artists whom Pat manages. We need to keep in our databases plenty of informa- tion on them—their name, gender, address (including country, as they live all over the world), phone number(s), instrument(s), e-mail, etc. We also try to keep track of how they are doing in terms of the reviews they get, and thus we are subscribing to a clipping service that provides us articles on the artists whom we manage. For some of the artists, the amount of material we get is huge, and we would like to reduce it somehow. At any rate, we would at least like to be able to have a better idea of what we have in our archives on a particular artist, and thus we should probably start to maintain some kind of a list of the news items we have for a particular artist. I don’t know if this is worth it but it would be very useful if we could get it done.

Scheduling is, of course, a major headache for me. Although Pat and the artists negotiate the final schedules, I do, in practice, at this point maintain a big schedule book for each artist whom we manage. You know, somebody has to have the central copy. This means that Pat, the artists, and the event orga- nizers are calling me all the time to verify the current situation and make changes to the schedule. Sometimes things get mixed up and we don’t get the latest changes to the central calendar (for example, an artist schedules a vacation and forgets to tell us—as you can understand, this can lead to a pretty difficult situation). It would be so wonderful to get a centralized calen- dar which both Pat and the artists could access; it is probably, however, better if Pat (and the other managers for the other art- ists, of course) was the only person in addition to me who had the right to change the calendar. Hmmm . . . I guess it would be good if the artists could block time out if they decide that they need if for personal purposes (they are not, however, allowed to book any performances without discussing it first with us).

One more thing: I would need to have something that would remind me of the upcoming changes in artist contracts. Every artist’s contract has to be renewed annually, and sometimes I forget to remind Pat to do this with the artist. Normally this is not a big deal, but occasionally we have had a situation where the lack of a valid contract led to unfortunate and unnecessary prob- lems. It seems that we would need to maintain some type of list of the contracts with their start dates, end dates, royalty percent- ages, and simple notes related to each of the contracts.

This is a pretty hectic job, and I have not had time to get as good computer training as I would have wanted. I think I am still doing pretty well. It is very important that whatever you develop for us, it has to be easy to use because we are in such a hurry all the time and we cannot spend much time learning complex commands.

E-mail from Dale Dylan, Established Artist

Hi! I am Dale Dylan, a pianist from Austin, TX. I have achieved reasonable success during my career and I am very thankful that I have been able to work with Pat Smith and Mr. Forondo during the past five years. They have been very good at finding suitable performance opportunities for me, particularly after I won an international piano competition in Amsterdam a few years ago. Compared to some other people with whom I have worked, Pat is very conscientious and works hard for me.

During the recent months, FAME and its managers’ cli- ent base has grown quite a lot, and unfortunately I have seen this in the service they have been able to provide to me. I know that Pat and Alex don’t mean any harm but it seems that they simply have too much to do, particularly in scheduling and get- ting my fees to me. Sometimes things seem to get lost pretty easily these days, and occasionally I have been waiting for my money for 2–3 months. This was never the case earlier but it has been pretty typical during the last year or so. Please don’t say anything to Pat or Alex about this; I don’t want to hurt their feelings, but it just simply seems that they have too much to do. Do you think your new system could help them?

CASE Forondo Artist Management Excellence Inc.

2 • Modeling Data in the Organization 147

M02B_HOFF3359_13_GE_C02.indd 147 12/04/19 12:08 PM

148 Part II • Database Analysis and Logical Design

What I would like to see in a new system—if you will develop one for them—are just simple facilities that would help them do even better what they have always done pretty well (except very recently): collecting money from the concert orga- nizers and getting it to me fast (they are, after all, taking 20 per- cent of my money—at least they should get the rest of it to me quickly) and maintaining my schedule. I have either a laptop or at least my smartphone/iPad with me all the time while I am on the road, thus I certainly should be able to check my sched- ule on the Web. Now I always need to call Alex to get any last- minute changes. It seems pretty silly that Pat has to be in touch with Alex before any changes can be made to the calendar; I feel that I should be allowed to make my own changes. Naturally, I would always notify Pat about anything that changes (or maybe the system could do that for me). The calendar system should be able to give me at least a simple list of the coming events in the chronological order for any time period I want. Further- more, I would like to be able to search for events using specific criteria (location, type, etc.).

In addition, we do, of course, get annual summaries from FAME regarding the fees we have earned, but it would be nice to have this information a bit more often. I don’t need it on paper but if I could access that information on the Web, it would be very, very good. It seems to me that Alex is doing a lot of work with these reports by hand; if you could help her with any of the routine work she is doing, I am sure she would be quite happy. Maybe then she and Pat would have more time for get- ting everything done as they always did earlier.

E-mail from Sandy Wallis, Event Organizer

I am Sandy Wallis, the executive director of the Greater Tri-State Area Concert Halls, and it has been a pleasure to have a good working relationship with Pat Smith at FAME for many years. Pat has provided me and my annual concert series several excellent artists per year, and I believe that our cooperation has a potential to continue into the foreseeable future. This does, however, require that Pat is able to continue to give me the best service in the industry during the years to come.

Our business is largely based on personal trust, and the most important aspect of our cooperation is that I can know that I can rely on the artists managed by Pat. I am not interested in the technology Pat is using, but it is important for us that practical matters such as billing and scheduling work smoothly and that technology does not prevent us from

making decisions fast, if necessary. We don’t want to be billed for events that were cancelled and never rescheduled, and we are quite unhappy if we need to spend our time on these types of technicalities.

At times, we need a replacement artist to substitute for a musician who becomes ill or cancels for some other reason, and the faster we can get information about the availability of world-class performers in these situations, the better it is for us. Yes, we work in these situations directly with Pat, but we have seen that occasionally all the information required for fast decision making is not readily available, and this is something that is difficult for us to understand. We would like to be able to assume that Pat’s able assistant Alex should be able to give us information regarding the availability of a certain artist on a certain date on the phone without any problems. Couldn’t this information be available on the Web, too? Of course, we don’t want anybody to know in advance whom we have booked before we announce our annual program; therefore, security is very important for us.

I hope you understand that we run multiple venues but we definitely still want to be treated as one customer. With some agencies we have seen silly problems that have forced them to send us invoices with several different names and customer numbers, which does not make any sense from our perspective and causes practical problems with our systems.

Project Questions

2-59. Redo the enterprise data model you created in Chapter 1 to accommodate the information gleaned from Alex Mar- tin’s, Dale Dylan’s, and Sandy Wallis’s e-mails.

2-60. Create an E-R diagram for FAME based on the enter- prise data model you developed in 1-60. Clearly state any assumptions you made in developing the diagram.

2-61. Use the narratives in Chapter 1 and above to identify the typical outputs (reports and displays) the various stake- holders might want to retrieve from your database. Now, revisit the E-R diagram you created in 2-60 to ensure that your model has captured the information necessary to generate the outputs desired. Update your E-R diagram as necessary.

2-62. Prepare a list of questions that you have as a result of your E-R modeling efforts and that need to be answered to clarify your understanding of FAME’s business rules and data requirements.

M02B_HOFF3359_13_GE_C02.indd 148 12/04/19 12:08 PM

149

The Enhanced E-R Model

3 LEARNING OBJECTIVES After studying this chapter, you should be able to:

■■ Concisely define each of the following key terms: enhanced entity-relationship (EER) model, subtype, supertype, attribute inheritance, generalization, specialization, completeness constraint, total specialization rule, partial specialization rule, disjointness constraint, disjoint rule, overlap rule, subtype discriminator, supertype/subtype hierarchy, entity cluster, and universal data model.

■■ Recognize when to use supertype/subtype relationships in data modeling. ■■ Use both specialization and generalization as techniques for defining supertype/ subtype relationships.

■■ Specify both completeness constraints and disjointness constraints in modeling supertype/subtype relationships.

■■ Develop a supertype/subtype hierarchy for a realistic business situation. ■■ Develop an entity cluster to simplify presentation of an E-R diagram. ■■ Explain the major features and data modeling structures of a universal (packaged) data model.

■■ Describe the special features of a data modeling project when using a packaged data model.

INTRODUCTION

The basic E-R model described in Chapter 2 was first introduced during the mid-1970s (certainly independent of the disco dance craze and the movie Saturday Night Fever, also popular at that time). It has been suitable for modeling most common business problems and has enjoyed widespread use. However, the business environment has changed dramatically since that time. Business relationships are more complex, and as a result, business data are much more complex as well. For example, organizations must be prepared to segment their markets and to customize their products, which places much greater demands on organizational databases.

To cope better with these changes, researchers and consultants have continued to enhance the E-R model so that it can more accurately represent the complex data encountered in today’s business environment. The term enhanced entity- relationship (EER) model is used to identify the model that has resulted from extending the original E-R model with these new modeling constructs (see, e.g., https://en.wikipedia.org/wiki/Enhanced_entity%E2%80%93relationship_model; see also Elmasri and Navathe, 2011). These extensions make the EER model semantically similar to object-oriented data modeling; visit the book’s website for Chapter 14 on the object-oriented data model.

Visit www.pearsonglobaleditions .com to view the accompanying video for this chapter.

Enhanced entity-relationship (EER) model

A model that has resulted from extending the original E-R model with new modeling constructs.

M03_HOFF3359_13_GE_C03.indd 149 10/04/19 2:37 PM

150 Part II • Database Analysis and Logical Design

The most important modeling construct incorporated in the EER model is supertype/subtype relationships. This facility enables you to model a general entity type (called the supertype) and then subdivide it into several specialized entity types (called subtypes). Thus, for example, the entity type CAR can be modeled as a supertype, with subtypes SEDAN, SPORTS CAR, COUPE, and so on. Each subtype inherits attributes from its supertype and in addition may have special attributes and be involved in relationships of its own. Adding new notation for modeling supertype/ subtype relationships has greatly improved the flexibility of the basic E-R model.

E-R, and especially EER, diagrams can become large and complex, requiring multiple pages (or very small font) for display. Some commercial databases include hundreds of entities. Many users and managers specifying requirements for using a database do not need to see all the entities, relationships, and attributes, to understand the part of the database with which they are most interested. Entity clustering is a way to turn a part of an E-R data model into a more macro-level view of the same data. Entity clustering is a hierarchical decomposition technique (a nesting process of breaking a system into further and further subparts), which can make E-R diagrams easier to read and databases easier to design. By grouping entities and relationships, you can lay out an E-R diagram in such a way that you give attention to the details of the model that matter most in a given data modeling task.

As introduced in Chapter 2, universal and industry-specific generalizable data models, which extensively utilized EER capabilities, have become very important for contemporary data modelers. These packaged data models and data model patterns have made data modelers more efficient and produce data models of higher quality. The EER features of supertypes/subtypes are essential to create generalizable data models; additional generalizing constructs, such as typing entities and relationships, are also employed. It has become very important for data modelers to know how to customize a data model pattern or a data model for a major software package (e.g., enterprise resource planning or customer relationship management), just as it has become commonplace for information system builders to customize off-the-shelf software packages and software components.

REPRESENTING SUPERTYPES AND SUBTYPES

Recall from Chapter 2 that an entity type is a collection of entities that share common properties or characteristics. Although the entity instances that make up an entity type are similar, we do not expect them to have exactly the same attributes. For example, recall required and optional attributes from Chapter 2. One of the major challenges in data modeling is to recognize and clearly represent entities that are almost the same, that is, entity types that share common properties but also have one or more distinct properties that are of interest to the organization.

For this reason, the E-R model has been extended to include supertype/subtype relationships. A subtype is a subgrouping of the entities in an entity type that is mean- ingful to the organization. For example, STUDENT is an entity type in a university. Two subtypes of STUDENT are GRADUATE STUDENT and UNDERGRADUATE STUDENT. In this example, we refer to STUDENT as the supertype. A supertype is a generic entity type that has a relationship with one or more subtypes.

In the E-R diagramming we have done so far, supertypes and subtypes have been hidden. For example, consider again Figure 2-22, which is the E-R diagram (in Micro- soft Visio) for Pine Valley Furniture Company. Notice that it is possible for a customer to not do business in any territory (i.e., no associated instances of the DOES BUSINESS IN associative entity). Why is this? One possible reason is that there are two types of customers—national account customers and regular customers—and only regular cus- tomers are assigned to a sales territory. Thus, in that figure the reason for the optional cardinality next to the DOES BUSINESS IN associative entity coming from CUSTOMER is obscured. Explicitly drawing a customer entity supertype and several entity subtypes will help us make the E-R diagram more meaningful. Later in this chapter, we show a

Subtype

A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings.

Supertype

A generic entity type that has a relationship with one or more subtypes.

M03_HOFF3359_13_GE_C03.indd 150 18/03/19 4:37 PM

3 • The Enhanced E-R Model 151

revised E-R diagram for Pine Valley Furniture, which demonstrates several EER nota- tions to make vague aspects of Figure 2-22 more explicit.

Basic Concepts and Notation

The notation that is used for supertype/subtype relationships in this text is shown in Figure 3-1a. The supertype is connected with a line to a circle, which in turn is connected with a line to each subtype that has been defined. The U-shaped symbol on each line con- necting a subtype to the circle emphasizes that the subtype is a subset of the supertype. It also indicates the direction of the subtype/supertype relationship. (This U is optional because the meaning and direction of the supertype/subtype relationship is usually obvi- ous; in most examples, we will not include this symbol.) Figure 3-1b shows the type of EER notation used by Microsoft Visio (which is very similar to that used in this text), and Figure 3-1c shows the type of EER notation used by some CASE tools; the notation in Figure 3-1c is also the form often used for universal and industry-specific data models. These different formats have identical basic features, and you should easily become com- fortable using any of these forms. We primarily use the text notation for examples in this chapter because advanced EER features are more standard with this format.

FIGURE 3-1 Basic notation for supertype/subtype relationships

(a) EER notation

(b) Microsoft Visio notation

and so forth

SUBTYPE 1

Attributes unique to subtype 1

SUBTYPE 2

Attributes unique to subtype 2

Relationships in which all instances participate

Relationships in which only specialized versions

participate

General entity type

Specialized versions of supertype

SUPERTYPE

Attributes shared by all entities

(including identifier)

IdentifierPK

Shared attributes

SUPERTYPE

and so forth

Attributes unique to subtype 1

SUBTYPE 1

Attributes unique to subtype 2

SUBTYPE 2

Relationships in which only specialized versions

participate

Relationships in which all instances participate

General entity type

Specialized versions of supertype

M03_HOFF3359_13_GE_C03.indd 151 18/03/19 4:37 PM

152 Part II • Database Analysis and Logical Design

Attributes that are shared by all entities (including the identifier) are associated with the supertype. Attributes that are unique to a particular subtype are associated with that subtype. The same is true for relationships. Other components will be added to this notation to provide additional meaning in supertype/subtype relationships as we pro- ceed through the remainder of this chapter.

AN EXAMPLE OF A SUPERTYPE/SUBTYPE RELATIONSHIP You can begin to understand supertype/subtype relationships with a simple yet common example. Suppose that an organization has three basic types of employees: hourly employees, salaried employees, and contract consultants. The following are some of the important attributes for each of these types of employees:

• Hourly employees Employee Number, Employee Name, Address, Date Hired, Hourly Rate

• Salaried employees Employee Number, Employee Name, Address, Date Hired, Annual Salary, Stock Option

• Contract consultants Employee Number, Employee Name, Address, Date Hired, Contract Number, Billing Rate

Notice that all of the employee types have several attributes in common: Employee Number, Employee Name, Address, and Date Hired. In addition, each type has one or more attributes distinct from the attributes of other types (e.g., Hourly Rate is unique to hourly employees). If you were developing a conceptual data model in this situation, you might consider three choices:

1. Define a single entity type called EMPLOYEE. Although conceptually simple, this approach has the disadvantage that EMPLOYEE would have to contain all of the attributes for the three types of employees. For an instance of an hourly employee, for example, attributes such as Annual Salary and Contract Number would not apply (optional attributes) and would be null or not used. When taken to a devel- opment environment, programs that use this entity type would necessarily need to be quite complex to deal with the many variations.

2. Define a separate entity type for each of the three entities. This approach would fail to exploit the common properties of employees, and users would have to be careful to select the correct entity type when using the system.

3. Define a supertype called EMPLOYEE with subtypes HOURLY EMPLOYEE, SALARIED EMPLOYEE, and CONSULTANT. This approach exploits the common properties of all employees, yet it recognizes the distinct properties of each type.

SUPERTYPE Identifier Shared attributes

SUBTYPE 1 Attributes unique to subtype 1

SUBTYPE 2 Attributes unique to subtype 2

.

. and so forth

.

Relationships in which all instances participate

Relationships in which only specialized versions

participate

Specialized versions of supertype

(c) Subtypes inside super types notation

FIGURE 3-1 (continued)

M03_HOFF3359_13_GE_C03.indd 152 18/03/19 4:37 PM

3 • The Enhanced E-R Model 153

Figure 3-2 shows a representation of the EMPLOYEE supertype with its three subtypes, using enhanced E-R notation. Attributes shared by all employees are associ- ated with the EMPLOYEE entity type. Attributes that are peculiar to each subtype are included with that subtype only.

ATTRIBUTE INHERITANCE A subtype is an entity type in its own right. An entity instance of a subtype represents the same entity instance of the supertype. For example, if “Therese Jones” is an occurrence of the CONSULTANT subtype, then this same per- son is necessarily an occurrence of the EMPLOYEE supertype. As a consequence, an entity in a subtype must possess not only values for its own attributes but also values for its attributes as a member of the supertype, including the identifier.

Attribute inheritance is the property by which subtype entities inherit values of all attributes and instance of all relationships of the supertype. This important property makes it unnecessary to include supertype attributes or relationships redundantly with the subtypes (remember, when it comes to data modeling, redundancy = bad, simplicity = good). For example, Employee Name is an attribute of EMPLOYEE (Figure 3-2) but not of the subtypes of EMPLOYEE. Thus, the fact that the employee’s name is “Therese Jones” is inherited from the EMPLOYEE supertype. However, the Billing Rate for this same employee is an attribute of the subtype CONSULTANT.

You have seen that a member of a subtype must be a member of the supertype. Is the converse also true—that is, is a member of the supertype also a member of one (or more) of the subtypes? This may or may not be true, depending on the business situ- ation. (Sure, “it depends” is the classic academic answer, but it’s true in this case.) We discuss the various possibilities later in this chapter.

WHEN TO USE SUPERTYPE/SUBTYPE RELATIONSHIPS So, how do you know when to use a supertype/subtype relationship? You should consider using subtypes when either (or both) of the following conditions are present:

1. There are attributes that apply to some (but not all) instances of an entity type. For example, see the EMPLOYEE entity type in Figure 3-2.

2. The instances of a subtype participate in a relationship unique to that subtype.

Figure 3-3 is an example of the use of subtype relationships that illustrates both of these situations. The hospital entity type PATIENT has two subtypes: OUTPATIENT and RESIDENT PATIENT. (The identifier is Patient ID.) All patients have an Admit Date attribute, as well as a Patient Name. Also, every patient is cared for by a RESPONSIBLE PHYSICIAN who develops a treatment plan for the patient.

Attribute inheritance

A property by which subtype entities inherit values of all attributes and instances of all relationships of their supertype.

CONSULTANT

EMPLOYEE

Employee Number Employee Name Address Date Hired

SALARIED EMPLOYEE

Annual Salary Stock Option

Contract Number Billing RateHourly Rate

HOURLY EMPLOYEE

FIGURE 3-2 Employee supertype with three subtypes

M03_HOFF3359_13_GE_C03.indd 153 18/03/19 4:37 PM

154 Part II • Database Analysis and Logical Design

Each subtype has an attribute that is unique to that subtype. Outpatients have Checkback Date, whereas resident patients have Date Discharged. Also, resident patients have a unique relationship that assigns each patient to a bed. (Notice that this is a mandatory relationship; it would be optional if it were attached to PATIENT.) Each bed may or may not be assigned to a patient.

Earlier we discussed the property of attribute inheritance. Thus, each outpatient and each resident patient inherits the attributes of the parent supertype PATIENT: Patient ID, Patient Name, and Admit Date. Figure 3-3 also illustrates the principle of relationship inheritance. OUTPATIENT and RESIDENT PATIENT are also instances of PATIENT; therefore, each Is Cared For by a RESPONSIBLE PHYSICIAN.

Representing Specialization and Generalization

We have described and illustrated the basic principles of supertype/subtype relation- ships, including the characteristics of “good” subtypes. But in developing real-world data models, how can you recognize opportunities to exploit these relationships? There are two processes—generalization and specialization—that serve as mental models in developing supertype/subtype relationships.

GENERALIZATION A unique aspect of human intelligence is the ability and propensity to classify objects and experiences and to generalize their properties. In data modeling, generalization is the process of defining a more general entity type from a set of more specialized entity types. Thus generalization is a bottom-up process.

An example of generalization is shown in Figure 3-4. In Figure 3-4a, three entity types have been defined: CAR, TRUCK, and MOTORCYCLE. At this stage, the data modeler intends to represent these separately on an E-R diagram. However, on closer examination, we see that the three entity types have a number of attributes in common: Vehicle ID (identifier), Vehicle Name (with components Make and Model), Price, and Engine Displacement. This fact (reinforced by the presence of a common identifier) sug- gests that each of the three entity types is really a version of a more general entity type.

This more general entity type (named VEHICLE) together with the resulting supertype/subtype relationships is shown in Figure 3-4b. The entity CAR has the spe- cific attribute No Of Passengers, whereas TRUCK has two specific attributes: Capacity

Generalization

The process of defining a more general entity type from a set of more specialized entity types.

Checkback Date

OUTPATIENT RESIDENT PATIENT

Date Discharged

Is Cared For

Is Assigned BED

Bed ID

PATIENT

Patient ID Patient Name Admit Date

RESPONSIBLE PHYSICIAN

Physician ID

Relationship for all types of patients

Attributes for all types of patients

Relationship for certain types of patients

Attributes for certain types of patients

FIGURE 3-3 Supertype/subtype relationships in a hospital

M03_HOFF3359_13_GE_C03.indd 154 18/03/19 4:37 PM

3 • The Enhanced E-R Model 155

and Cab Type. Thus, generalization has allowed us to group entity types along with their common attributes and at the same time preserve specific attributes that are peculiar to each subtype.

Notice that the entity type MOTORCYCLE is not included in the relationship. Is this simply an omission? No. Instead, it is deliberately not included because it does not satisfy the conditions for a subtype discussed earlier. Comparing Figures 3-4a and 3-4b, you will notice that the only attributes of MOTORCYCLE are those that are common to all vehicles; there are no attributes specific to motorcycles. Furthermore, MOTORCYCLE does not have a relationship to another entity type. Thus, there is no need to create a MOTORCYCLE subtype.

The fact that there is no MOTORCYCLE subtype suggests that it must be possible to have an instance of VEHICLE that is not a member of any of its subtypes. We discuss this type of constraint in the section on specifying constraints.

SPECIALIZATION As we have seen, generalization is a bottom-up process. Specialization is a top-down process, the direct reverse of generalization. Suppose that we have defined an entity type with its attributes. Specialization is the process of defining one or more subtypes of the supertype and forming supertype/subtype relationships. Each subtype is formed based on some distinguishing characteristic, such as attributes or relationships specific to the subtype.

An example of specialization is shown in Figure 3-5. Figure 3-5a shows an entity type named PART, together with several of its attributes. The identifier is Part No, and other attributes are Description, Unit Price, Location, Qty On Hand, Routing Number, and Supplier. (The last attribute is multivalued and composite because there may be more than one supplier with an associated unit price for a part.)

Specialization

The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships.

CAR

Vehicle ID Price Engine Displacement Vehicle Name (Make, Model) No Of Passengers

TRUCK

Vehicle ID Price Engine Displacement Vehicle Name (Make, Model) Capacity Cab Type

MOTORCYCLE

Vehicle ID Price Engine Displacement Vehicle Name (Make, Model)

No Of Passengers

CAR TRUCK

Capacity Cab Type

VEHICLE

Vehicle ID Price Engine Displacement Vehicle Name (Make, Model)

Vehicles of all types, including Motorcycles, which have no unique

attributes or relationships

FIGURE 3-4 Example of generalization

(a) Three entity types: CAR, TRUCK, and MOTORCYCLE

(b) Generalization to VEHICLE supertype

M03_HOFF3359_13_GE_C03.indd 155 18/03/19 4:37 PM

156 Part II • Database Analysis and Logical Design

In discussions with users, we discover that there are two possible sources for parts: Some are manufactured internally, whereas others are purchased from outside suppliers. Further, we discover that some parts are obtained from both sources. In this case, the choice depends on factors such as manufacturing capacity, unit price of the parts, and so on.

Some of the attributes in Figure 3-5a apply to all parts, regardless of source. How- ever, others depend on the source. Thus, Routing Number applies only to manufactured parts, whereas Supplier ID and Unit Price apply only to purchased parts. These factors suggest that PART should be specialized by defining the subtypes MANUFACTURED PART and PURCHASED PART (Figure 3-5b).

In Figure 3-5b, Routing Number is associated with MANUFACTURED PART. The data modeler initially planned to associate Supplier ID and Unit Price with PUR- CHASED PART. However, in further discussions with users, the data modeler sug- gested instead that they create a SUPPLIER entity type and an associative entity linking PURCHASED PART with SUPPLIER. This associative entity (named SUPPLIES in Figure 3-5b) allows users to more easily associate purchased parts with their suppliers. Notice that the attribute Unit Price is now associated with the associative entity so that the unit price for a part may vary from one supplier to another. In this example, special- ization has permitted a preferred representation of the problem domain.

COMBINING SPECIALIZATION AND GENERALIZATION Specialization and generalization are both valuable techniques for developing supertype/subtype relationships. The technique you use at a particular time depends on several factors, such as the nature of the problem domain, previous modeling efforts, and personal preference. You should be prepared to use both approaches and to alternate back and forth as dictated by the preceding factors.

PART

Part No Description Qty On Hand Location Routing Number {Supplier (Supplier ID, Unit Price)}

Routing Number

MANUFACTURED PART

PURCHASED PART

PART

Part No Description Location Qty On Hand

SUPPLIER

Supplier ID

SUPPLIES

Unit Price

Entity types, attributes, and relationship associated

with only Purchased Parts

FIGURE 3-5 Example of specialization

(a) Entity type PART

(b) Specialization to MANUFACTURED PART and PURCHASED PART

M03_HOFF3359_13_GE_C03.indd 156 18/03/19 4:37 PM

3 • The Enhanced E-R Model 157

SPECIFYING CONSTRAINTS IN SUPERTYPE/SUBTYPE RELATIONSHIPS

So far we have discussed the basic concepts of supertype/subtype relationships and introduced some basic notation to represent these concepts. We have also described the processes of generalization and specialization, which help you recognize opportunities for exploiting these relationships. In this section, we introduce additional notation to represent constraints on supertype/subtype relationships. These constraints allow you to capture some of the important business rules that apply to these relationships. The two most important types of constraints that are described in this section are complete- ness and disjointness constraints (Elmasri and Navathe, 2011).

Specifying Completeness Constraints

A completeness constraint 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. The total specialization rule specifies that each entity instance of the supertype must be a member of some sub- type in the relationship. The partial specialization rule specifies that an entity instance of the supertype is allowed not to belong to any subtype. We illustrate each of these rules with earlier examples from this chapter (see Figure 3-6).

TOTAL SPECIALIZATION RULE Figure 3-6a repeats the example of PATIENT (Figure 3-3) and introduces the notation for total specialization. In this example, the business rule is the following: A patient must be either an outpatient or a resident patient. (There are no other types of patient in this hospital.) Total specialization is indicated by the double line extending from the PATIENT entity type to the circle. (In the Microsoft Visio notation, total specialization is called “Category is complete” and is shown also by a double line under the category circle between the supertype and associated subtypes.)

In this example, every time a new instance of PATIENT is inserted into the super- type, a corresponding instance is inserted into either OUTPATIENT or RESIDENT PATIENT. If the instance is inserted into RESIDENT PATIENT, an instance of the rela- tionship Is Assigned is created to assign the patient to a hospital bed.

PARTIAL SPECIALIZATION RULE Figure 3-6b repeats the example of VEHICLE and its subtypes CAR and TRUCK from Figure 3-4. Recall that in this example, motorcycle is a type of vehicle, but it is not represented as a subtype in the data model. Thus, if a vehicle is a car, it must appear as an instance of CAR, and if it is a truck, it must appear as an instance of TRUCK. However, if the vehicle is a motorcycle, it cannot appear as an instance of any subtype because it has no attributes or relationships other than those for

Completeness constraint

A type of constraint that addresses whether an instance of a supertype must also be a member of at least one subtype.

Total specialization rule

A rule that specifies that each entity instance of a supertype must be a member of some subtype in the relationship.

Partial specialization rule

A rule that specifies that an entity instance of a supertype is allowed not to belong to any subtype.

FIGURE 3-6 Examples of completeness constraints

(a) Total specialization rule

Checkback Date

OUTPATIENT RESIDENT PATIENT

Date Discharged

Is Cared For

Is Assigned BED

Bed ID

PATIENT

Patient ID Patient Name Admit Date

RESPONSIBLE PHYSICIAN

Physician ID

Total Specialization: A Patient has to be either an Outpatient or a Resident Patient

M03_HOFF3359_13_GE_C03.indd 157 18/03/19 4:37 PM

158 Part II • Database Analysis and Logical Design

the supertype of VEHICLE. This is an example of partial specialization, and it is speci- fied by the single line from the VEHICLE supertype to the circle.

Partial specialization is, in fact, very common. For example, there might be many sub- types of an EMPLOYEE supertype, but if a subtype (e.g., CLERICAL) has only the attributes of EMPLOYEE and participates only in relationships in which all employees participate, then there is no need to explicitly represent CLERICAL as a subtype of EMPLOYEE.

Specifying Disjointness Constraints

A disjointness constraint addresses whether an instance of a supertype may simulta- neously be a member of two (or more) subtypes. The disjointness constraint has two possible rules: the disjoint rule and the overlap rule. The disjoint rule specifies that if an entity instance (of the supertype) is a member of one subtype, it cannot simultaneously be a member of any other subtype. The overlap rule specifies that an entity instance can simultaneously be a member of two (or more) subtypes. An example of each of these rules is shown in Figure 3-7.

DISJOINT RULE Figure 3-7a shows the PATIENT example from Figure 3-6a. The business rule in this case is the following: At any given time, a patient must be either an outpatient

Disjointness constraint

A constraint that addresses whether an instance of a supertype may simultaneously be a member of two (or more) subtypes.

(b) Partial specialization rule

FIGURE 3-6 (continued)

Checkback Date

OUTPATIENT RESIDENT PATIENT

Date Discharged

Is Cared For

Is Assigned BED

Bed ID

RESPONSIBLE PHYSICIAN

Physician ID

d

PATIENT

Patient ID Patient Name Admit Date

Disjoint rule: A Patient can be either an Outpatient or a

Resident Patient, but not both at the same time

FIGURE 3-7 Examples of disjointness constraints

(a) Disjoint rule

No Of Passengers

CAR TRUCK

Capacity Cab Type

VEHICLE

Vehicle ID Price Engine Displacement Vehicle Name (Make, Model)

Partial Specialization: A Vehicle can be a Car, or

a Truck, but does not have to be either

M03_HOFF3359_13_GE_C03.indd 158 18/03/19 4:37 PM

3 • The Enhanced E-R Model 159

or a resident patient but cannot be both. This is the disjoint rule, as specified by the letter d in the circle joining the supertype and its subtypes. Note in this figure, the subclass of a PATIENT may change over time, but at a given time, a PATIENT is of only one type. (The Microsoft Visio notation does not have a way to designate disjointness or overlap; however, you can place a d or an o inside the category circle using the Text tool.)

OVERLAP RULE Figure 3-7b shows the entity type PART with its two subtypes, MANUFACTURED PART and PURCHASED PART (from Figure 3-5b). Recall from our discussion of this example that some parts are both manufactured and purchased. Some clarification of this statement is required. In this example, an instance of PART is a particular part number (i.e., a type of part), not an individual part (indicated by the identifier, which is Part No). For example, consider part number 4000. At a given time, the quantity on hand for this part might be 250, of which 100 are manufactured and the remaining 150 are purchased parts. In this case, it is not important to keep track of individual parts. When tracking individual parts is important, each part is assigned a serial number identifier, and the quantity on hand is one or zero, depending on whether that individual part exists or not.

The overlap rule is specified by placing the letter o in the circle, as shown in Figure 3-7b. Notice in this figure that the total specialization rule is also specified, as indicated by the double line. Thus, any part must be either a purchased part or a manufactured part, or it may simultaneously be both of these.

Defining Subtype Discriminators

Given a supertype/subtype relationship, consider the problem of inserting a new instance of a supertype. Into which of the subtypes (if any) should this instance be inserted? You have already seen the various possible rules that apply to this situation. Now, you need a simple mechanism to implement these rules, if one is available. Often this can be accomplished by using a subtype discriminator. A subtype discriminator is an attribute of a supertype whose values determine the target subtype or subtypes.

DISJOINT SUBTYPES An example of the use of a subtype discriminator is shown in Figure 3-8. This example is for the EMPLOYEE supertype and its subtypes, introduced in Figure 3-2. Notice that the following constraints have been added to this figure: total specialization and disjoint subtypes. Thus, each employee must be either hourly, sala- ried, or a consultant.

A new attribute (Employee Type) has been added to the supertype to serve as a subtype discriminator. When a new employee is added to the supertype, this attribute is coded with one of three values, as follows: “H” (for Hourly), “S” (for Salaried), or “C” (for Consultant). Depending on this code, the instance is then assigned to the appropri- ate subtype. (An attribute of the supertype may be selected in the Microsoft Visio nota- tion as a discriminator, which is shown similarly next to the category symbol.)

Disjoint rule

A rule that specifies that an instance of a supertype may not simultaneously be a member of two (or more) subtypes.

Overlap rule

A rule that specifies that an instance of a supertype may simultaneously be a member of two (or more) subtypes.

Subtype discriminator

An attribute of a supertype whose values determine the target subtype or subtypes.

Routing Number

MANUFACTURED PART

PURCHASED PART

PART

Part No Description Location Qty On Hand

SUPPLIER

Supplier ID

O

SUPPLIES

Unit Price

Overlap rule: A Part may be both a Manufactured Part and a Purchased

Part at the same time, but it must be one or the other due to Total

Specialization (double line)

(b) Overlap rule

FIGURE 3-7 (continued)

M03_HOFF3359_13_GE_C03.indd 159 18/03/19 4:37 PM

160 Part II • Database Analysis and Logical Design

The notation you can use to specify the subtype discriminator is also shown in Figure 3-8. The expression Employee Type= (which is the left side of a condition state- ment) is placed next to the line leading from the supertype to the circle. The value of the attribute that selects the appropriate subtype (in this example, either “H,” “S,” or “C”) is placed adjacent to the line leading to that subtype. Thus, for example, the condi- tion Employee Type=”S” causes an entity instance to be inserted into the SALARIED EMPLOYEE subtype.

OVERLAPPING SUBTYPES When subtypes overlap, a slightly modified approach must be applied for the subtype discriminator. The reason is that a given instance of the supertype may require that we create an instance in more than one subtype.

An example of this situation is shown in Figure 3-9 for PART and its overlap- ping subtypes. A new attribute named Part Type has been added to PART. Part Type

FIGURE 3-8 Introducing a subtype discriminator (disjoint rule) EMPLOYEE

Employee Number Employee Name Address Date Hired Employee Type

SALARIED EMPLOYEE

Annual Salary Stock Option

Hourly Rate

HOURLY EMPLOYEE

CONSULTANT

Contract Number Billing Rate

Employee Type=

“H” “S”

“C” d

Subtype discriminator with values of H, S, or C

for disjoint subtypes

Routing Number

MANUFACTURED PART

SUPPLIER

Supplier ID

Purchased?=“Y”Manufactured?=“Y”

O

PART

Part Type:

Part No Description Location Qty On Hand Part Type(Manufactured?, Purchased?)

PURCHASED PART

SUPPLIES

Unit Price

Subtype discriminator is a composite attribute when

there is an overlap rule

FIGURE 3-9 Subtype discriminator (overlap rule)

M03_HOFF3359_13_GE_C03.indd 160 18/03/19 4:37 PM

3 • The Enhanced E-R Model 161

is a composite attribute with components Manufactured? and Purchased? Each of these attributes is a Boolean variable (i.e., it takes on only the values yes, “Y,” and no, “N”). When a new instance is added to PART, these components are coded as follows:

Type of Part Manufactured? Purchased?

Manufactured only “Y” “N”

Purchased only “N” “Y”

Purchased and manufactured “Y” “Y”

The method for specifying the subtype discriminator for this example is shown in Figure 3-9. Notice that this approach can be used for any number of overlapping subtypes.

Defining Supertype/Subtype Hierarchies

You have already studied a number of examples of supertype/subtype relationships in this chapter. It is possible for any of the subtypes in these examples to have other sub- types defined on it (in which case, the subtype becomes a supertype for the newly defined subtypes). A supertype/subtype hierarchy is a hierarchical arrangement of supertypes and subtypes, where each subtype has only one supertype (Elmasri and Navathe, 2011).

We present an example of a supertype/subtype hierarchy in this section in Figure 3-10. (For simplicity, we do not show subtype discriminators in this and most subsequent examples. See Problems and Exercises 3-19 and 3-20.) This example includes most of the concepts and notation we have used in this chapter to this

Supertype/subtype hierarchy

A hierarchical arrangement of supertypes and subtypes in which each subtype has only one supertype.

FIGURE 3-10 Example of supertype/subtype hierarchy

PERSON

SSN Name Address Gender Date Of Birth

ALUMNUS

{Degree(Year, Designation, Date)}

Salary Date Hired

EMPLOYEE STUDENT

Major Dept

STAFF

PositionRank

FACULTY UNDERGRAD STUDENT

Class StandingTest Score

GRADUATE STUDENT

dd

O

M03_HOFF3359_13_GE_C03.indd 161 18/03/19 4:37 PM

162 Part II • Database Analysis and Logical Design

point. It also presents a methodology (based on specialization) that you can use in many data modeling situations.

AN EXAMPLE OF A SUPERTYPE/SUBTYPE HIERARCHY Suppose that you are asked to model the human resources in a university. Using specialization (a top-down approach), you might proceed as follows: Starting at the top of a hierarchy, model the most general entity type first. In this case, the most general entity type is PERSON. List and associ- ate all attributes of PERSON. The attributes shown in Figure 3-10 are SSN (identifier), Name, Address, Gender, and Date Of Birth. The entity type at the top of a hierarchy is sometimes called the root.

Next, define all major subtypes of the root. In this example, there are three subtypes of PERSON: EMPLOYEE (persons who work for the university), STUDENT (persons who attend classes), and ALUMNUS (persons who have graduated). Assuming that there are no other types of persons of interest to the university, the total specialization rule applies, as shown in the figure. A person might belong to more than one subtype (e.g., ALUMNUS and EMPLOYEE), so the overlap rule is used. Note that overlap allows for any overlap. (A PERSON may be simultaneously in any pair or in all three subtypes.) If certain combinations are not allowed, a more refined supertype/subtype hierarchy would have to be developed to eliminate the prohibited combinations.

Attributes that apply specifically to each of these subtypes are shown in the figure. Thus, each instance of EMPLOYEE has a value for Date Hired and Salary. Major Dept is an attribute of STUDENT, and Degree (with components Year, Designation, and Date) is a multivalued, composite attribute of ALUMNUS.

The next step is to evaluate whether any of the subtypes already defined qualify for further specialization. In this example, EMPLOYEE is partitioned into two subtypes: FACULTY and STAFF. FACULTY has the specific attribute Rank, whereas STAFF has the specific attribute Position. Notice that in this example the subtype EMPLOYEE becomes a supertype to FACULTY and STAFF. Because there may be types of employ- ees other than faculty and staff (such as student assistants), the partial specialization rule is indicated. However, an employee cannot be both faculty and staff at the same time. Therefore, the disjoint rule is indicated in the circle.

Two subtypes are also defined for STUDENT: GRADUATE STUDENT and UNDERGRAD STUDENT. UNDERGRAD STUDENT has the attribute Class Standing, whereas GRADUATE STUDENT has the attribute Test Score. Notice that total special- ization and the disjoint rule are specified; you should be able to state the business rules for these constraints.

SUMMARY OF SUPERTYPE/SUBTYPE HIERARCHIES You should note two features con- cerning the attributes contained in the hierarchy shown in Figure 3-10:

1. Attributes are assigned at the highest logical level that is possible in the hierarchy. For example, because SSN (i.e., Social Security Number) applies to all persons, it is assigned to the root. In contrast, Date Hired applies only to employees, so it is assigned to EMPLOYEE. This approach ensures that attributes can be shared by as many subtypes as possible.

2. Subtypes that are lower in the hierarchy inherit attributes not only from their immediate supertype but also from all supertypes higher in the hierarchy, up to the root. Thus, for example, an instance of faculty has values for all of the follow- ing attributes: SSN, Name, Address, Gender, and Date Of Birth (from PERSON); Date Hired and Salary (from EMPLOYEE); and Rank (from FACULTY).

EER MODELING EXAMPLE: PINE VALLEY FURNITURE COMPANY

In Chapter 2, you saw a sample E-R diagram for Pine Valley Furniture. (This diagram, developed using Microsoft Visio, is repeated in Figure 3-11.) After studying this dia- gram, you might use some questions to help you clarify the meaning of entities and relationships. Three such areas of questions are (see annotations in Figure 3-11 that indicate the source of each question):

M03_HOFF3359_13_GE_C03.indd 162 18/03/19 4:37 PM

3 • The Enhanced E-R Model 163

FIGURE 3-11 E-R diagram for Pine Valley Furniture Company

Salesperson ID

Salesperson Name Salesperson Telephone Salesperson Fax

PK

SALESPERSON

Customer ID

Customer Name Customer Address Customer Postal Code

PK

CUSTOMER

Product ID

Product Description Product Finish Product Standard Price

PK

PRODUCT

Material ID

Material Name Material Standard Cost Unit of Measure

PK

RAW MATERIAL

Order ID

Order Date

PK

ORDER

SkillPK

SKILL

Ordered Quantity

ORDER LINE

Product Line ID

Product Line Name

PK

PRODUCT LINE

Serves

Submits

Includes

Is Supervised By

Supervises

Territory IDPK

Territory Name

TERRITORY DOES BUSINESS IN

Vendor ID

Vendor Name Vendor Address

PK

VENDOR

Employee ID

Employee Name Employee Address

PK

EMPLOYEE

Work Center ID

Work Center Location

PK

WORK CENTER

Goes into Quantity

USES PRODUCED IN

WORKS IN

HAS SKILL

Supply Unit Price

SUPPLIES

Question 1

Question 3

Question 2

M03_HOFF3359_13_GE_C03.indd 163 18/03/19 4:37 PM

164 Part II • Database Analysis and Logical Design

1 Why do some customers not do business in one or more sales territories?

2 Why do some employees not supervise other employees, and why are they not all supervised by another employee? And, why do some employees not work in a work center?

3 Why do some vendors not supply raw materials to Pine Valley Furniture?

You may have other questions, but we will concentrate on these three to illus- trate how supertype/subtype relationships can be used to convey a more specific (semantically rich) data model.

After some investigation into these three questions, we discover the following business rules that apply to how Pine Valley Furniture does business:

1 There are two types of customers: regular and national account. Only regular customers do business in sales territories. A sales territory exists only if it has at least one regular customer associated with it. A national account customer is associ- ated with an account manager. It is possible for a customer to be both a regular and a national account customer.

2 Two special types of employees exist: management and union. Only union employees work in work centers, and a management employee supervises union employees. There are other kinds of employees besides management and union. A union employee may be promoted into management, at which time that employee stops being a union employee.

3 Pine Valley Furniture keeps track of many different vendors, not all of which have ever supplied raw materials to the company. A vendor is associated with a contract number once that vendor becomes an official supplier of raw materials.

These business rules have been used to modify the E-R diagram in Figure 3-11 into the EER diagram in Figure 3-12. (We have left most attributes off this diagram except for those that are essential to see the changes that have occurred.) Rule 1 means that there is a total, overlapping specialization of CUSTOMER into REGULAR CUSTOMER and NATIONAL ACCOUNT CUSTOMER. A composite attribute of CUSTOMER, Customer Type (with components National and Regular), is used to designate whether a customer instance is a regular customer, a national account, or both. Because only regular cus- tomers do business in sales territories, only regular customers are involved in the Does Business In relationship (associative entity).

Rule 2 means that there is a partial, disjoint specialization of EMPLOYEE into MANAGEMENT EMPLOYEE and UNION EMPLOYEE. An attribute of EMPLOYEE, Employee Type, discriminates between the two special types of employees. Spe- cialization is partial because there are other kinds of employees besides these two types. Only union employees are involved in the Works In relationship, but all union employees work in some work center, so the minimum cardinality next to Works In from UNION EMPLOYEE is now mandatory. Because an employee cannot be both management and union at the same time (although he or she can change status over time), the specialization is disjoint.

Rule 3 means that there is a partial specialization of VENDOR into SUPPLIER because only some vendors become suppliers. A supplier, not a vendor, has a contract number. Because there is only one subtype of VENDOR, there is no reason to specify a disjoint or overlap rule. Because all suppliers supply some raw material, the minimum cardinality next to RAW MATERIAL in the Supplies relationship (associative entity in Visio) now is one.

This example shows how an E-R diagram can be transformed into an EER diagram once generalization/specialization of entities is understood. Not only are supertype and subtype entities now in the data model, but additional attributes, including discriminating attributes, also are added, minimum cardinalities change (from optional to mandatory), and relationships move from the supertype to a subtype.

M03_HOFF3359_13_GE_C03.indd 164 18/03/19 4:37 PM

3 • The Enhanced E-R Model 165

SALESPERSON

REGULAR CUSTOMER NATIONAL CUSTOMER

CUSTOMER

Customer Type National? Regular?

Account Manager

RAW MATERIAL

ORDER

SKILL

ORDER LINE

PRODUCT LINE

PRODUCT

USES

VENDOR

Serves Customer Type

Submits

d

Includes

SALES TERRITORY DOES BUSINESS IN

Contract Number

SUPPLIER

EMPLOYEE

UNION EMPLOYEE

“U”“M”

MANAGEMENT EMPLOYEE

WORK CENTER

PRODUCED IN

WORKS IN HAS SKILL

SUPPLIES

Employee Type

Employee Type

Supervises

O

Rule 3

Rule 1

Rule 2

FIGURE 3-12 EER diagram for Pine Valley Furniture Company using Microsoft Visio

M03_HOFF3359_13_GE_C03.indd 165 18/03/19 4:37 PM

166 Part II • Database Analysis and Logical Design

This is a good time to emphasize a point made earlier about data modeling. A data model is a conceptual picture of the data required by an organization. A data model does not map one-for-one to elements of an implemented database. For example, a database designer may choose to put all customer instances into one database table, not separate ones for each type of customer. Such details are not important now. The purpose now is to explain all the rules that govern data, not how data will be stored and accessed to achieve efficient, required information processing. We will address technol- ogy and efficiency issues in subsequent chapters when we cover database design and implementation.

Although the EER diagram in Figure 3-12 clarifies some questions and makes the data model in Figure 3-11 more explicit, it still can be difficult for some people to com- prehend. Some people will not be interested in all types of data, and some may not need to see all the details in the EER diagram to understand what the database will cover. The next section addresses how we can simplify a complete and explicit data model for presentation to specific user groups and management.

ENTITY CLUSTERING

Some enterprise-wide information systems have more than 1,000 entity types and relationships. How do we present such an unwieldy picture of organizational data to developers and users? With a really big piece of paper? On the wraparound walls of a large conference room? (Don’t laugh about that one; we’ve seen it done!) Well, the answer is that we don’t have to. In fact, there would be very few people who need to see the whole ERD in detail. If you are familiar with the principles of systems analysis and design (see, e.g., Valacich and George, 2016), you know about the concept of func- tional decomposition. Briefly, functional decomposition is an iterative approach to breaking a system down into related components so that each component can be rede- signed by itself without destroying the connections with other components. Functional decomposition is powerful because it makes redesign easier and allows people to focus attention on the part of the system in which they are interested. In data modeling, a similar approach is to create multiple, linked E-R diagrams, each showing the details of different (possibly overlapping) segments or subsets of the data model (e.g., different segments that apply to different departments, information system applications, busi- ness processes, or corporate divisions).

Entity clustering (Teorey, 1999) is a useful way to present a data model for a large and complex organization. An entity cluster is a set of one or more entity types and asso- ciated relationships grouped into a single abstract entity type. Because an entity cluster behaves like an entity type, entity clusters and entity types can be further grouped to form a higher-level entity cluster. Entity clustering is a hierarchical decomposition of a macro-level view of the data model into finer and finer views, eventually resulting in the full, detailed data model.

Figure 3-13 illustrates one possible result of entity clustering for the Pine Valley Furniture Company data model of Figure 3-12. Figure 3-13a shows the complete data model with shaded areas around possible entity clusters; Figure 3-13b shows the final result of transforming the detailed EER diagram into an EER diagram of only entity clusters and relationships. (An EER diagram may include both entity clusters and entity types, but this diagram includes only entity clusters.) In this figure, the entity cluster

• SELLING UNIT represents the SALESPERSON and SALES TERRITORY entity types and the Serves relationship.

• CUSTOMER represents the CUSTOMER entity supertype, its subtypes, and the relationship between supertype and subtypes.

• ITEM SALE represents the ORDER entity type and ORDER LINE associative entity as well as the relationship between them.

• ITEM represents the PRODUCT LINE and PRODUCT entity types and the Includes relationship.

• MANUFACTURING represents the WORK CENTER and EMPLOYEE super- type entity and its subtypes as well as the Works In associative entity and

Entity cluster

A set of one or more entity types and associated relationships grouped into a single abstract entity type.

M03_HOFF3359_13_GE_C03.indd 166 18/03/19 4:37 PM

3 • The Enhanced E-R Model 167

SELLING UNIT

SALESPERSON

REGULAR CUSTOMER NATIONAL CUSTOMER

CUSTOMER CUSTOMER

ITEM SALE

MANUFACTURING

ITEM

MATERIAL

Customer Type National? Regular?

Account Manager

RAW MATERIAL

ORDER

SKILL

ORDER LINE

PRODUCT LINE

PRODUCT

USES

VENDOR

Serves Customer Type

Submits o

d

Includes

SALES TERRITORY DOES BUSINESS IN

Contract Number

SUPPLIER

EMPLOYEE

UNION EMPLOYEE

“U”“M”

MANAGEMENT EMPLOYEE

WORK CENTER

PRODUCED IN

WORKS IN HAS SKILL

SUPPLIES

Employee Type

Employee Type

Supervises

FIGURE 3-13 Entity clustering for Pine Valley Furniture Company

(a) Possible entity clusters (using Microsoft Visio)

M03_HOFF3359_13_GE_C03.indd 167 18/03/19 4:37 PM

168 Part II • Database Analysis and Logical Design

Supervises relationships and the relationship between the supertype and its subtypes. (Figure 3-14 shows an explosion of the MANUFACTURING entity cluster into its components.)

• MATERIAL represents the RAW MATERIAL and VENDOR entity types, the SUPPLIER subtype, the Supplies associative entity, and the supertype/subtype relationship between VENDOR and SUPPLIER.

The E-R diagrams in Figures 3-13 and 3-14 can be used to explain details to people most concerned with assembly processes and the information needed to support this part of the business. For example, an inventory control manager can see in Figure 3-13b that the data about manufacturing can be related to item data (the Produced In relation- ship). Furthermore, Figure 3-14 shows what detail is kept about the production process involving work centers and employees. This person probably does not need to see the details about, for example, the selling structure, which is embedded in the SELLING UNIT entity cluster.

Entity clusters in Figure 3-13 were formed (1) by abstracting a supertype and its subtype (see the CUSTOMER entity cluster) and (2) by combining directly related entity types and their relationships (see the SELLING UNIT, ITEM, MATERIAL, and MANU- FACTURING entity clusters). An entity cluster can also be formed by combining a strong entity and its associated weak entity types (not illustrated here). Because entity cluster- ing is hierarchical, if it were desirable, we could draw another EER diagram in which we combine the SELLING UNIT and CUSTOMER entity clusters with the DOES BUSINESS IN associative entity one entity cluster, because these are directly related entity clusters.

SELLING UNIT CUSTOMER

Customer Type National? Regular?

MATERIAL USES ITEM

PRODUCED IN

MANUFACTURING

ITEM SALE

Submits

DOES BUSINESS IN

(b) EER diagram for entity clusters (using Microsoft Visio)

FIGURE 3-13 (continued)

M03_HOFF3359_13_GE_C03.indd 168 18/03/19 4:37 PM

3 • The Enhanced E-R Model 169

An entity cluster should focus on an area of interest to some community of users, developers, or managers. Which entity types and relationships are grouped to form an entity cluster depends on your purpose. For example, the ORDER entity type could be grouped in with the CUSTOMER entity cluster, and the ORDER LINE entity type could be grouped in with the ITEM entity cluster in the example of entity clustering for the Pine Valley Furniture data model. This regrouping would eliminate the ITEM SALE cluster, which might not be of interest to any group of people. Also, you can do several different entity clusterings of the full data model, each with a different focus.

PACKAGED DATA MODELS

According to Len Silverston (1998), “The age of the data modeler as artisan is passing. Organizations can no longer afford the labor or time required for handcrafting data models from scratch. In response to these constraints, the age of the data modeler as engineer is dawning.” As one executive explained to us, “the acquisition of a [packaged data model] was one of the key strategic things his organization did to gain quick results and long-term success” for the business. Packaged data models are a game-changer for data modeling.

As introduced in Chapter 2, a now popular approach to beginning a data model- ing project is to acquire a packaged or predefined data model (Agnew and Silverston, 2009), either a so-called universal model or an industry-specific model (some providers call these logical data models [LDMs], but these are really EER diagrams as explained in this chapter; the data model may also be part of a purchased software package, such as an enterprise resource planning or customer relationship management system). These packaged data models are not fixed; rather, the data modeler customizes the predefined model to fit the business rules of his or her organization based on a best-practices data model for the industry (e.g., transportation or communications) or chosen func- tional area (e.g., finance or manufacturing). The key assumption of this data modeling approach is that underlying structures or patterns of enterprises in the same industry or functional area are similar. Packaged data models are available from various consul- tants and database technology vendors. Although packaged data models are not inex- pensive, many believe the total cost is lower and the quality of data modeling is better by using such resources. Some generic data models can be found in publications (e.g., see articles and books by Hay and by Silverston listed at the end of this chapter).

FIGURE 3-14 MANUFACTURING entity cluster

d

EMPLOYEE

UNION EMPLOYEE

“U”“M”

MANAGEMENT EMPLOYEE

WORK CENTER

WORKS INSKILL HAS SKILL

Employee Type

Employee Type

Supervises

M03_HOFF3359_13_GE_C03.indd 169 18/03/19 4:37 PM

170 Part II • Database Analysis and Logical Design

A universal data model is a generic or template data model that can be reused as a starting point for a data modeling project. Some people call these data model patterns, similar to the notion of patterns of reusable code for programming. A universal data model is not the “right” data model, but it is a successful starting point for developing an excellent data model for an organization.

Why has this approach of beginning from a universal data model for conduct- ing a data modeling project become so popular? (See the video at https://marketplace .informatica.com/solutions/universal_data_models for some real-world examples of the benefits of a universal data model.) The following are some of the most compelling reasons professional data modelers are adopting this approach (we have developed this reasoning from Hoberman, 2006, and from an in-depth study we have conducted at the leading online retailer Overstock.com, which has adopted several packaged data models from Teradata Corporation):

• Data models can be developed using proven components evolved from cumu- lative experiences (as stated by the data administrator in the company we studied, “why reinvent when you can adapt?”). These data models are kept up to date by the provider as new kinds of data are recognized in an industry (e.g., RFID).

• Projects take less time and cost because the essential components and structures are already defined and only need to be quickly customized to the particular situation. The company we studied stated that the purchased data model was about 80 percent right before customization and that the cost of the package was about equal to the cost of one database modeler for one year.

• Data models are less likely to miss important components or make modeling errors by not recognizing common possibilities. For example, the company we studied reported that its packaged data models helped it avoid the temptation of simply mirroring existing databases, with all the historical “warts” of poor naming con- ventions, data structures customized for some historical purpose, and the inertia of succumbing to the pressure to simply duplicate the inadequate past practices. As another example, one vendor of packaged data models, Teradata, claims that one of its data models was scoped using more than 1,000 business questions and key performance indicators.

• Because of a holistic, enterprise view and development from best practices of data modeling experts found in a universal data model, the resulting data model for a particular enterprise tends to be easier to evolve as additional data require- ments are identified for the given situation. A purchased model results in reduced rework in the future because the package gets it correct right out of the box and anticipates the future needs.

• The generic model provides a starting point for asking requirements questions so that most likely all areas of the model are addressed during requirements determi- nation. In fact, the company we studied said that their staff was “intrigued by all the possibilities” to meet even unspoken requirements from the capabilities of the prepackaged data models.

• Data models of an existing database are easier to read by data modelers and other data management professionals the first time because they are based on common components seen in similar situations.

• Extensive use of supertype/subtype hierarchies and other structures in universal data models promotes reusing data and taking a holistic rather than narrow view of data in an organization.

• Extensive use of many-to-many relationships and associative entities even where a data modeler might place a one-to-many relationship gives the data model greater flexibility to fit any situation and naturally handles time stamping and retention of important history of relationships, which can be important to comply with regulations and financial record-keeping rules.

• Adaptation of a data model from your DBMS vendor usually means that your data model will easily work with other applications from this same vendor or its software partners.

Universal data model

A generic or template data model that can be reused as a starting point for a data modeling project.

M03_HOFF3359_13_GE_C03.indd 170 18/03/19 4:37 PM

3 • The Enhanced E-R Model 171

• If multiple companies in the same industry use the same universal data model as the basis for their organizational databases, it may be easier to share data for interorganizational systems (e.g., reservation systems between rental car and airline firms).

A Revised Data Modeling Process with Packaged Data Models

Data modeling from a packaged data model requires no less skill than data modeling from scratch. Packaged data models are not going to put you out of work (or keep you from getting that job as an entry-level data analyst you want now that you’ve started studying database management!). In fact, working with a package requires advanced skills, like those you are learning in this chapter and Chapter 2. As we will see, the packaged data models are rather complex because they are thorough and developed to cover all possible circumstances. You have to be very knowledgeable of the organi- zation as well as the package to customize the package to fit the specific rules of that organization.

What do you get when you purchase a data model? What you are buying is metadata. You receive, usually on a CD, a fully populated description of the data model, usually specified in a structured data modeling tool, such as ERwin from Computer Associates or Oracle Designer from Oracle Corporation. The supplier of the data model has drawn the EER diagram, named and defined all the elements of the data model, and given all the attributes characteristics of data type (character, numeric, image), length, format, and so forth. You can print the data model and various reports about its con- tents to support the customization process. Once you customize the model, you can then use the data modeling tool to automatically generate the SQL commands to define the database to a variety of database management systems.

How is the data modeling process different when starting with a purchased solution? The following are the key differences (our understanding of these differences is enhanced by the interviews we conducted at Overstock.com):

• Because a purchased data model is extensive, you begin by identifying the parts of the data model that apply to your data modeling situation. Concentrate on these parts first and in the most detail. Start, as with most data modeling activities, first with entities, then attributes, and finally relationships. Consider how your organi- zation will operate in the future, not just today.

• You then rename the identified data elements to terms local to the organization rather than the generic names used in the package.

• In many cases, the packaged data model will be used in new information systems that replace existing databases as well as to extend into new areas. So the next step is to map the data to be used from the package to data in current databases.

One way this mapping will be used is to design migration plans to convert existing databases to the new structures. The following are some key points about this mapping process:

• There will be data elements from the package that are not in current systems, and there will be some data elements in current databases not in the package. Thus, some elements won’t map between the new and former environments. This is to be expected because the package anticipates information needs you have not yet satisfied by your current databases and because you do some special things in your organization that you want to retain but that are not standard practices. However, be sure that each nonmapped data element is really unique and needed. For example, it is possible that a data element in a current database may actually be derived from other more atomic data in the purchased data model. Also, you need to decide if data elements unique to the purchased data model are needed now or can be added on when you are ready to take advantage of these capabili- ties in the future.

• In general, the business rules embedded in the purchased data model cover all possible circumstances (e.g., the maximum number of customers associated with

M03_HOFF3359_13_GE_C03.indd 171 18/03/19 4:37 PM

172 Part II • Database Analysis and Logical Design

a customer order). The purchased data model allows for great flexibility, but a general-purpose business rule may be too weak for your situation (e.g., you are sure you will never allow more than one customer per customer order). As you will see in the next section, the flexibility and generalizability of a purchased data model results in complex relationships and many entity types. Although the pur- chased model alerts you to what is possible, you need to decide if you really need this flexibility and if the complexity is worthwhile.

• Because you are starting with a prototypical data model, it is possible to engage users and managers to be supported by the new database early and often in the data modeling project. Interviews, JAD sessions, and other requirements gathering activities are based on concrete ERDs rather than wish lists. The purchased data model essentially suggests specific questions to be asked or issues to be discussed (e.g., “Would we ever have a customer order with more than one customer associated with it?” or “Might an employee also be a customer?”). The purchased model in a sense provides a visual checklist of items to discuss (e.g., Do we need these data? Is this business rule right for us?); further, it is comprehensive, so it is less likely that an important requirement will be missed.

• Because the purchased data model is comprehensive, there is no way you will be able to build and populate the full database or even customize the whole data model in one project. However, you don’t want to miss the opportunity to visual- ize future requirements shown in the full data model. Thus, you will get to a point where you have to make a decision on what will be built first and possible future phases to build out as much of the purchased data model as will make sense. One approach to explaining the build-out schedule is to use entity clustering to show segments of the full data model that will be built in different phases. Future mini- projects will address detailed customization for new business needs and other segments of the data model not developed in the initial project.

You will learn in subsequent chapters of this book important database modeling and design concepts and skills that are important in any database development effort, including those based on purchased data models. There are, however, some important things to note about projects involving purchased data models. Some of these involve using existing databases to guide how to customize a purchased data model, including the following:

• Over time the same attribute may have been used for different purposes—what people call overloaded columns in current systems. This means that the data values in existing databases may not have uniform meaning for the migration to the new database. Often these multiple uses are not documented and are not known until the migration begins. Some data may no longer be needed (maybe used for a spe- cial business project), or there may be hidden requirements that were not formally incorporated into the database design. More on how to deal with this in a moment.

• Similarly, some attributes may be empty (i.e., have no values), at least for some periods of time. For example, some employee home addresses could be missing, or product engineering attributes for a given product line might be absent for products developed a few years ago. This could have occurred because of appli- cation software errors, human data entry mistakes, or other reasons. As we have studied, missing data may suggest optional data and the need for entity subtypes. So missing data need to be studied to understand why the data are sparse.

• A good method for understanding hidden meaning and identifying inconsisten- cies in existing data models, and hence data and business rules that need to be included in the customized purchased data model, is data profiling. Profiling is a way to statistically analyze data to uncover hidden patterns and flaws. Profiling can find outliers, identify shifts in data distribution over time, and identify other phenomena. Each 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 were combined to improve processing speed for a special set of queries but the better structure was never restored). Data profiling can also be

M03_HOFF3359_13_GE_C03.indd 172 18/03/19 4:37 PM

3 • The Enhanced E-R Model 173

used to assess how accurate current data are and anticipate the cleanup effort that will be needed to populate the purchased data model with high-quality data.

• Arguably the most important challenge of customizing a purchased data model is determining the business rules that will be established through the data model. A purchased data model will anticipate the vast majority of the needed rules, but each rule must be verified for your organization. Fortunately, you don’t have to guess which ones to address; each is laid out by the entities, attributes, and rela- tionships with their metadata (names, definitions, data types, formats, lengths, etc.) in the purchased model. It simply takes time to go through each of these data elements with the right subject matter experts to make sure you have the relation- ship cardinalities and all other aspects of the data model right.

Packaged Data Model Examples

What, then, do packaged or universal data models look like? Central to the universal data model approach are supertype/subtype hierarchies. For example, a core structure of any universal data model is the entity type PARTY, which generalizes persons or organizations as actors for the enterprise, and an associated entity type PARTY ROLE, which generalizes various roles parties can play at different times. A PARTY ROLE instance is a situation in which a PARTY acts in a particular ROLE TYPE. These notions of PARTY, PARTY ROLE, and ROLE TYPE supertypes and their relationship are shown in Figure 3-15a. We use the supertype/subtype notation from Figure 3-1c because this is the notation most frequently used in publicly available universal data models. (Most packaged data models are proprietary intellectual property of the vendor, and, hence,

FIGURE 3-15 PARTY, PARTY ROLE, and ROLE TYPE in a universal data model

(a) Basic PARTY universal data model

PERSON ROLE Current First Name Current Last Name

PARTY ROLE From Date Thru Date

EMPLOYEE CONTACT

ORGANIZATION ROLE ORGANIZATION UNIT

DEPARTMENT

CUSTOMER Used to Identify

Of

For

Acting As

ROLE TYPE Role Type ID Description

PERSON Current First Name Current Last Name Social Security Number

PARTY Party ID

ORGANIZATION Organization Name

SUPPLIER BILL TO CUSTOMER Current Last Name

Attributes of all types of PARTY ROLEs; and there must be a starting date (From Date) when a Party starts to

serve in a Party Role for a certain Role Type

Override attribute of same name in the

entity PERSON ROLE higher in the

hierarchy

A PERSON has names but may have di­erent names when acting in

a PERSON ROLE

M03_HOFF3359_13_GE_C03.indd 173 18/03/19 4:37 PM

174 Part II • Database Analysis and Logical Design

we cannot show them in this text.) This is a very generic data model (albeit simple to begin our discussion). This type of structure allows a specific party to serve in different roles during different time periods (specified by From Date and Thru Date). It allows attribute values of a party to be “overridden” (if necessary in the organization) by val- ues pertinent to the role being played during the given time period (e.g., although a PERSON of the PARTY supertype has a Current Last Name as of now, when in the party role of BILL TO CUSTOMER a different Current Last Name could apply during the particular time period [From Date to Thru Date] of that role). Note that even for this simple situation, the data model is trying to capture the most general circumstances. For example, an instance of the EMPLOYEE subtype of the PERSON ROLE subtype of PARTY ROLE would be associated with an instance of the ROLE TYPE that describes the employee-person role-party role. Thus, one description of a role type explains all the instances of the associated party roles of that role type.

An interesting aspect of Figure 3-15a is that PARTY ROLE actually simplifies what could be a more extensive set of subtypes of PARTY. Figure 3-15b shows one PARTY supertype with many subtypes covering many party roles. With partial specialization and overlap of subtypes, this alternative would appear to accomplish the same data modeling semantics as Figure 3-15a. However, Figure 3-15a recognizes the important distinction between enterprise actors (PARTYs) and the roles each plays from time to time (PARTY ROLEs). Thus, the PARTY ROLE concept actually adds to the generaliza- tion of the data model and the universal applicability of the predefined data model.

The next basic construct of most universal data models is the representation of relationships between parties in the roles they play. Figure 3-16 shows this next extension of the basic universal data model. PARTY RELATIONSHIP is an associative entity, which hence allows any number of parties to be related as they play particular roles. Each instance of a relationship between PARTYs in PARTY ROLEs would be a separate instance of a PARTY RELATIONSHIP subtype. For example, consider the employment of a person by some organization unit during some time span, which over time is a many-to-many association. In this case, the EMPLOYMENT subtype of PARTY RELATIONSHIP would (for a given time period) likely link one PERSON playing the role of an EMPLOYEE subtype of PARTY ROLE with one ORGANIZATION ROLE playing some pertinent party role, such as ORGANIZATION UNIT. (That is, a person is employed in an organization unit during a period of From Date to Thru Date in PARTY RELATIONSHIP.)

EMPLOYEE

CONTACT

ORGANIZATION UNIT

DEPARTMENT

CUSTOMER

PERSON Current First Name Current Last Name Social Security Number

PARTY Party ID

ORGANIZATION Organization Name

SUPPLIER

BILL TO CUSTOMER Current Last Name

CUSTOMER

BILL TO CUSTOMER Current Last Name

(b) PARTY supertype/ subtype hierarchy

FIGURE 3-15 (continued)

M03_HOFF3359_13_GE_C03.indd 174 18/03/19 4:37 PM

3 • The Enhanced E-R Model 175

PARTY RELATIONSHIP is represented very generally, so it really is an associa- tive entity for a unary relationship among PARTY ROLE instances. This makes for a very general, flexible pattern of relationships. What might be obscured, however, are which subtypes might be involved in a particular PARTY RELATIONSHIP and stricter relationships that are not many-to-many, probably because we don’t need to keep track of the relationship over time. For example, because the Involves and Involved In relationships link the PARTY ROLE and PARTY RELATIONSHIP supertypes, this does not restrict EMPLOYMENT to an EMPLOYEE with an ORGANIZATION UNIT. Also, if the enterprise needs to track only current employment associations, the data model in Figure 3-16 will not enforce that a PERSON PARTY in an EMPLOYEE PARTY ROLE can be associated with only one ORGANIZATION UNIT at a time. We will see in the next section how we can include additional business rule notation on an EER diagram to make this specific. Alternatively, we could draw specific relationships from just the EMPLOYEE PARTY ROLE and the ORGANIZATION UNIT PARTY ROLE to the EMPLOYMENT PARTY RELATIONSHIP to represent this particular one-to-many association. As you can imagine, to handle very many special cases like this would cre- ate a diagram with a large number of relationships between PARTY ROLE and PARTY

FIGURE 3-16 Extension of a universal data model to include PARTY RELATIONSHIPs

ORG CONTACT

EMPLOYMENT

PERSON-TO-ORG RELATIONSHIP

ORG CUSTOMER

PARTNERSHIP

ORG-TO-ORG RELATIONSHIP

PARTY RELATIONSHIP From Date Thru Date

PERSON ROLEPARTY ROLE From Date Thru Date

EMPLOYEE CONTACT

ORGANIZATION ROLE ORGANIZATION UNIT

DEPARTMENT

Used to Identify

Of

For

Acting As

PERSON PARTY Party ID ORGANIZATION

To

Involves

From

Involved In

SUPPLIER

CUSTOMER

BILL TO CUSTOMER Current Last Name

ROLE TYPE Role Type ID

Indicates when a RELATIONSHIP or ROLE is in e�ect

M03_HOFF3359_13_GE_C03.indd 175 18/03/19 4:37 PM

176 Part II • Database Analysis and Logical Design

RELATIONSHIP and, hence, a very busy diagram. Thus, more restrictive cardinality rules (at least most of them) would likely be implemented outside the data model (e.g., in database stored procedures or application programs) when using a packaged data model.

We could continue introducing various common, reusable building blocks of universal data models. However, Silverston in a two-volume set (2001a, 2001b) and Hay (1996) provide extensive coverage. To bring our discussion of packaged, univer- sal data models to a conclusion, we show in Figure 3-17, a universal data model for a relationship development organization. In this figure, we use the original notation of Silverston (see several references at the end of the chapter), which is pertinent to Oracle data modeling tools. Now that you have studied EER concepts and notations and have been introduced to universal data models, you can understand more about the power of this data model.

To help you better understand the EER diagram in Figure 3-17, consider the defi- nitions of the highest-level entity type in each supertype/subtype hierarchy:

PARTY Persons and organizations independent of the roles they play

PARTY ROLE Information about a party for an associated role, thus allowing a party to act in multiple roles

PARTY RELATIONSHIP Information about two parties (those in the “to” and “from” roles) within the context of a relationship

EVENT Activities that may occur within the context of relationships (e.g., a CORRESPONDENCE can occur within the context of a PERSON- CUSTOMER relationship in which the “to” party is a CUSTOMER role for an ORGANIZATION and the from party is an EMPLOYEE role for a PERSON)

PRIORITY TYPE Information about a priority that may set the priority for a given PARTY RELATIONSHIP

STATUS TYPE Information about the status (e.g., active, inactive, pending) of events or party relationships

EVENT ROLE Information about all of the PARTYs involved in an EVENT

ROLE TYPE Information about the various PARTY ROLEs and EVENT ROLEs

In Figure 3-17, supertype/subtype hierarchies are used extensively. For example, in the PARTY ROLE entity type, the hierarchy is as many as four levels deep (e.g., PARTY ROLE to PERSON ROLE to CONTACT to CUSTOMER CONTACT). Attributes can be located with any entity type in the hierarchy (e.g., PARTY has the identifier PARTY ID [# means identifier], PERSON has three optional attributes [o means optional], and ORGANIZATION has a required attribute [* means required]). Relationships can be between entity types anywhere in the hierarchy. For example, any EVENT is “in the state of” an EVENT STATUS TYPE, a subtype, whereas any EVENT is “within the con- text of” a PARTY RELATIONSHIP, a supertype.

As stated previously, packaged data models are not meant to be exactly right straight out of the box for a given organization; they are meant to be customized. To be the most generalized, such models have certain properties before they are customized for a given situation:

1. Relationships are connected to the highest-level entity type in a hierarchy that makes sense. Relationships can be renamed, eliminated, added, and moved as needed for the organization.

2. Strong entities almost always have M:N relationships between them (e.g., EVENT and PARTY), so at least one, and sometimes many, associative entities are used. Consequently, all relationships are 1:M, and there is an entity type in which to store intersection data. Intersection data are often dates, showing over what span of time the relationship was valid. Thus, the packaged data model is designed to allow tracking of relationships over time. (Recall that this is a common issue that was discussed with Figure 2-20.) 1:M relationships are optional, at least on the

M03_HOFF3359_13_GE_C03.indd 176 18/03/19 4:37 PM

3 • The Enhanced E-R Model 177

Within The Context Of The Context For

To

Involved In

From

Setting Status For

Involved In

In The State Of

Prioritized By

Setting Priority For

Defined By

EVENT

# EVENT ID

o FROM DATETIME

o THRU DATETIME

o NOTE

COMMUNICATION EVENT

CORRESPONDENCE

TELECOMMUNICATION

INTERNET COMMUNICATION

IN-PERSON COMMUNICATION

OTHER COMMUNICATION EVENT

TRANSACTION EVENT COMMITMENT TRANSACTION RESERVATION ORDER OTHER

COMMITMENT

FULFILLMENT TRANSACTION SHIPMENT PAYMENT OTHER

FULFILLMENT

OTHER TRANSACTION EVENT

PARTY RELATIONSHIP # FROM DATE o THRU DATE

PERSON-TO-ORG RELATIONSHIP

PERSON-CUSTO MER RELATIONSHIP

ORGANIZATION CONTACT RELATIONSHIP

EMPLOYMENT

ORG-TO-ORG RELATIONSHIP

ORG-CUSTOMER RELATIONSHIP

SUPPLIER RELATIONSHIP

DISTRIBUTION CHANNEL RELATIONSHIP

PARTNERSHIP

PERSON-TO- PERSON

RELATIONSHIP

BUSINESS ASSOCIATION

FAMILY ASSOCIATION

PARTY ROLE # FROM DATE o THRU DATE PERSON ROLE

EMPLOYEE CONTRACTOR

CONTACT

CUSTOMER CONTACT

SUPPLIER CONTACT

PARTNER CONTACT

FAMILY MEMBER

PROSPECT SHAREHOLDER

CUSTOMER

BILL-TO CUSTOMER o CURRENT CREDIT LIMIT AMT

SHIP-TO CUSTOMER

END-USER CUSTOMER

For

Acting As

PARTY # PARTY ID

ORGANIZATION ROLE

DISTRIBUTION CHANNEL

AGENT DISTRIBUTOR

PARTNER COMPETITOR

HOUSEHOLD REGULATORY

SUPPLIER AGENCY

ASSOCIATION

ORGANIZATION UNIT

DEPARTMENT OTHER

DIVISION ORGANIZATION

SUBSIDIARY UNIT

PARENT ORGANIZATION

INTERNAL ORGANIZATION

PRIORITY TYPE # PRIORITY TYPE ID * DESCRIPTION

STATUS TYPE # STATUS ID * DESCRIPTION

PARTY RELATIONSHIP STATUS TYPE

EVENT STATUS TYPE

NPERSO o CURRENT FIRST NAME o CURRENT LAST NAME o SOCIAL SECURITY NUMBER

ORGANIZATION * NAME

for

EVENT ROLE # FROM DATE o THRU DATE

ROLE TYPE # ROLE TYPE ID * DESCRIPTION

For

Of

Used To Identify

Of

Used Within

Involving

Involving

Involved In

FIGURE 3-17 A universal data model for relationship development

M03_HOFF3359_13_GE_C03.indd 177 18/03/19 4:37 PM

178 Part II • Database Analysis and Logical Design

many side (e.g., the dotted line next to EVENT for the “involving” relationship signifies that an EVENT may involve an EVENT ROLE, as is done with Oracle Designer).

3. Although not clear on this diagram, all supertype/subtype relationships follow the total specialization and overlap rules, which makes the diagram as thorough and flexible as possible.

4. Most entities on the many side of a relationship are weak, thus inheriting the identifier of the entity on the one side (e.g., the ~ on the “acting as” relation- ship from PARTY to PARTY ROLE signifies that PARTY ROLE implicitly includes PARTY ID).

Summary This chapter has described how the basic E-R model has been extended to include supertype/subtype rela- tionships. A supertype is a generic entity type that has a relationship with one or more subtypes. A subtype is a grouping of the entities in an entity type that is meaning- ful to the organization. For example, the entity type PER- SON is frequently modeled as a supertype. Subtypes of PERSON may include EMPLOYEE, VOLUNTEER, and CLIENT. Subtypes inherit the attributes and relationships associated with their supertype.

Supertype/subtype relationships should normally be considered in data modeling with either (or both) of the following conditions present: First, there are attri- butes that apply to some (but not all) of the instances of an entity type. Second, the instances of a subtype partici- pate in a relationship unique to that subtype.

The techniques of generalization and specialization are important guides in developing supertype/subtype relationships. Generalization is the bottom-up process of defining a generalized entity type from a set of more specialized entity types. Specialization is the top-down process of defining one or more subtypes of a supertype that has already been defined.

The EER notation allows us to capture the impor- tant business rules that apply to supertype/subtype relationships. The completeness constraint allows us to specify whether an instance of a supertype must also be a member of at least one subtype. There are two cases: With total specialization, an instance of the supertype must be a member of at least one subtype. With partial specialization, an instance of a supertype may or may not be a member of any subtype. The disjointness constraint allows us to specify whether an instance of a supertype may simultaneously be a member of two or more sub- types. Again, there are two cases. With the disjoint rule, an instance can be a member of only one subtype at a given time. With the overlap rule, an entity instance can simultaneously be a member of two (or more) subtypes.

A subtype discriminator is an attribute of a super- type whose values determine to which subtype (or sub- types) a supertype instance belongs. A supertype/subtype hierarchy is a hierarchical arrangement of supertypes and subtypes, where each subtype has only one supertype.

There are extensions to the E-R notation other than supertype/subtype relationships. One of the other useful extensions is aggregation, which rep- resents how some entities are part of other entities (e.g., a PC is composed of a disk drive, RAM, a moth- erboard). Due to space limitations, we have not dis- cussed these extensions here. Most of these extensions, like aggregation, are also a part of object-oriented data modeling, which is explained in Chapter 14, on the book Web site.

E-R diagrams can become large and complex, including hundreds of entities. Many users and man- agers do not need to see all the entities, relationships, and attributes to understand the part of the database with which they are most interested. Entity clustering is a way to turn a part of an E-R data model into a more macro-level view of the same data. An entity cluster is a set of one or more entity types and associated relation- ships grouped into a single abstract entity type. Several entity clusters and associated relationships can be fur- ther grouped into even a higher entity cluster, so entity clustering is a hierarchical decomposition technique. By grouping entities and relationships, you can lay out an E-R diagram to allow you to give attention to the details of the model that matter most in a given data modeling task.

Packaged data models, so-called universal and industry-specific data models, extensively utilize EER features. These generalizable data models often use mul- tiple level supertype/subtype hierarchies and associative entities. Subjects and the roles subjects play are sepa- rated, creating many entity types; this complexity can be simplified when customized for a given organization, and entity clusters can be used to present simpler views of the data model to different audiences.

The use of packaged data models can save con- siderable time and cost in data modeling. The skills required for a data modeling project with a packaged data model are quite advanced and are built on the data modeling principles covered in this text. You have to consider not only current needs but also future require- ments to customize the general-purpose package. Data elements must be renamed to local terms, and current

M03_HOFF3359_13_GE_C03.indd 178 18/03/19 4:37 PM

3 • The Enhanced E-R Model 179

data need to be mapped to the target database design. This mapping can be challenging due to various forms of mismatches between the data in current databases with those found in the best-practices purchased data- base model. Fortunately, having actual data models “right out of the box” helps structure the customization process for completeness and ease of communication

with subject matter experts. Overloaded columns, poor metadata, and abuses of the structure of current databases can make the customization and migra- tion processes challenging. Data profiling can be used to understand the current data and uncover hid- den meanings and business rules in data for your organization.

Chapter Review

Key Terms Attribute inheritance 153 Completeness

constraint 157 Disjoint rule 159 Disjointness

constraint 158

Enhanced entity- relationship (EER) model 149

Entity cluster 166 Generalization 154 Overlap rule 159

Partial specialization rule 157

Specialization 155 Subtype 150 Subtype discriminator 159 Supertype 150

Supertype/subtype hierarchy 161

Total specialization rule 157

Universal data model 170

Review Questions

3-1. Define each of the following terms: a. supertype b. subtype c. specialization d. entity cluster e. completeness constraint f. enhanced entity-relationship (EER) model g. supertype/subtype hierarchy h. total specialization rule i. generalization j. disjoint rule k. overlap rule l. partial specialization rule m. universal data model

3-2. Match the following terms and definitions:            supertype            entity cluster            subtype            specialization            subtype

discriminator            attribute

inheritance            generalization

a. subset of supertype b. creating a supertype for entity types c. subtype gets supertype attributes d. generalized entity type e. creating subtypes for an entity

type f. a group of associated entity types

and relationships g. locates target subtype for an entity

3-3. Contrast the following terms: a. supertype; subtype b. generalization; specialization c. disjoint rule; overlap rule d. total specialization rule; partial specialization rule e. PARTY; PARTY ROLE f. entity; entity cluster

3-4. Discuss the notations used to represent EER models. Which notation is the most widely used?

3-5. Explain the need for EER modeling. 3-6. Explain how specialization and generalization assist in

the development of supertype/subtype relationships. 3-7. What is attribute inheritance? Why is it important? 3-8. What is a completeness constraint, and what are the

total and partial specialization rules? 3-9. What types of business rules are normally captured in

an EER diagram? 3-10. Give an example of generalization not discussed in the

text. 3-11. How are the attributes assigned in a supertype/subtype

hierarchy? 3-12. In what ways is starting a data modeling project with

a packaged data model different from starting a data modeling project with a clean sheet of paper?

3-13. Purchasing a packaged data model involves map- ping. What is mapping? What are the points you need to consider in mapping?

3-14. Does a data modeling project using a packaged data model require less or greater skill than a project not using a packaged data model? Why or why not?

3-15. Discuss how it is decided which subtype will be inserted with a new instance of a supertype.

3-16. In Figure 3-5b, why must the minimum cardinality next to SUPPLIES from PURCHASED PART be one yet the minimum cardinality next to SUPPLIES from SUPPLIER may be zero?

3-17. When is a member of a supertype always a member of at least one subtype?

M03_HOFF3359_13_GE_C03.indd 179 18/03/19 4:37 PM

180 Part II • Database Analysis and Logical Design

Problems and Exercises

3-18. Examine the hierarchy for the university EER diagram (Figure 3-10). As a student, you are an instance of one of the subtypes: either UNDERGRAD STUDENT or GRAD- UATE STUDENT. List the names of all the attributes that apply to you. For each attribute, record the data value that applies to you.

3-19. Add a subtype discriminator for each of the supertypes shown in Figure 3-10. Show the discriminator values that assign instances to each subtype. Use the following subtype discriminator names and values: a. PERSON: Person Type (Employee? Alumnus? Stu-

dent?) b. EMPLOYEE: Employee Type (Faculty, Staff) c. STUDENT: Student Type (Grad, Undergrad)

3-20. For simplicity, subtype discriminators were left off many figures in this chapter. Add subtype discriminator nota- tion in each figure listed below. If necessary, create a new attribute for the discriminator. a. Figure 3-2 b. Figure 3-3 c. Figure 3-4b d. Figure 3-7a e. Figure 3-7b

3-21. Refer to the employee EER diagram in Figure 3-2. Make any assumptions that you believe are necessary. Develop a sample definition for each entity type, attribute, and relationship in the diagram.

3-22. Refer to the EER diagram for patients in Figure 3-3. Make any assumptions you believe are necessary. Develop sample definitions for each entity type, attribute, and relationship in the diagram.

3-23. Figure 3-13 shows the development of entity clusters for the Pine Valley Furniture E-R diagram. In Figure 3-13b, explain the following: a. Why is the minimum cardinality next to the DOES BUSI-

NESS IN associative entity coming from CUSTOMER zero?

b. What would be the attributes of ITEM (refer to Figure 2-22)?

c. What would be the attributes of MATERIAL (refer to Figure 2-22)?

3-24. Refer to Problem and Exercise 2-44 in Chapter 2, Part f. Redraw the ERD for your answer to this exercise using appropriate supertypes and subtypes.

3-25. An electronics goods store has devices such as mobile phones, laptops, televisions, and refrigerators for sale. a. Is it possible to apply a supertype/subtype hierarchy

to this situation? How? b. Construct an EER diagram. Which specialization rule

(completeness constraint) does it satisfy? c. In which scenario does the diagram satisfy the other

specialization rule? d. Suppose that the owner has decided to sell both new

and old products for resale. How will you incorporate this into the diagram?

3-26. An institute’s students participate in three types of sports events: long jump, discus throw, and the 100-meter race. The following attributes are recorded for each event:

Long Jump: Student Roll Number, Name, House, Age, Recorded Jump

Discus Throw: Student Roll Number, Name, House, Age, Distance covered

100 m. Race: Student Roll Number, Name, House, Age, Time Taken

Apply the rule of generalization and develop an EER model segment to represent this situation using tradi- tional EER notation, Visio notation, or subtypes inside supertypes notation. Assume that each sport event can be a part of exactly one of these subtypes.

3-27. Refer to your answer to Problem and Exercise 2-44 in Chapter 2. Develop entity clusters for the final version of this E-R diagram and redraw the diagram using the entity clusters. Explain why you chose the entity clusters you used.

3-28. Refer to your answer to Problem and Exercise 3-24. Develop entity clusters for this E-R diagram and redraw the diagram using the entity clusters. Explain why you chose the entity clusters you used.

3-29. Draw an EER diagram for the following problem using this text’s EER notation, the Visio notation, or the subtypes inside supertypes notation, as specified by your instructor:

In a typical university, people occupy one or more roles. There are students, either undergraduates or postgradu- ates, each of whom has an ID number, enrolment, and expected graduate date. Undergraduates have a major, while postgraduates have a thesis title and supervisor. Faculty comprises lecturers and teaching assistants, both of whom have an employee ID. Lecturers have a salary and teaching group, whereas teaching assistants are paid by the hour. All university members have a name, ad- dress, and date of birth. Sometimes faculty members may also be studying for a PhD.

3-30. Draw an EER diagram for the following problem: A company posts job openings online. Job seekers must apply for these jobs online as well. The company will process the applications and call eligible job seekers for an interview. Upon success- ful completion of the interview, a job seeker may be hired, and the corresponding job opening will be deleted from the company’s Web site. Job seekers have an ID, name, address, work history, and qualifications. A job posting can be either for a part-time or full-time position. Part-time positions have a total number of weekly hours and an hourly rate. Full-time positions have a monthly salary. Both types of job listings have details about the position and the company.

3-31. Draw an EER diagram for the following problem: MoneyBags Bank customers can access over 10,000 ATMs worldwide. These are a combination of the Bank’s own machines and those provided through the Visa network. Customers using the Bank’s own machines can check

M03_HOFF3359_13_GE_C03.indd 180 10/04/19 4:59 PM

3 • The Enhanced E-R Model 181

their balance and withdraw money in addition to all the usual ATM facilities. They are also able to transfer money to another account, although this is handled by another of the Bank’s computer systems. Privileged-level customers are able to withdraw up to 25 percent more than their balance, although this is exclusively available through MoneyBags ATMs only.

3-32. Draw an EER diagram for the following problem: AmazingMemories, a travel agency, specializes in holidays to Southeast Asia. It provides bespoke holidays that are set up and handled by an agency rep. Each rep creates a new booking, which has an ID, hotel, hotel room, check-in dates, and number of nights. Once a customer has chosen a hotel and hotel room, they can add up to three excursions that are offered within the vicinity of the hotel. Hotels and excursions are referred to as an itinerary, and customers can assign one or more itineraries to a booking. Often the customer making the booking is not actually the one going on holiday, therefore each booking has an assigned set of travelers.

3-33. Develop an EER model for the following situation using the traditional EER notation, the Visio notation, or the subtypes inside supertypes notation, as specified by your instructor:

An international school of technology has hired you to create a database management system to assist in sched- uling classes. After several interviews with the president, you have come up with the following list of entities, at- tributes, and initial business rules:

• Room is identified by Building ID and Room No and also has a Capacity. A room can be either a lab or a classroom. If it is a classroom, it has an additional attribute called Board Type.

• Media is identified by MType ID and has attributes of Media Type and Type Description. Note: Here we are tracking type of media (such as a VCR, pro- jector, etc.), not the individual piece of equipment. Tracking of equipment is outside the scope of this project.

• Computer is identified by CType ID and has attri- butes Computer Type, Type Description, Disk Capac- ity, and Processor Speed. Note: As with Media Type, we are tracking only the type of computer, not an in- dividual computer. You can think of this as a class of computers (e.g., i7 3.1 GHz).

• Instructor has identifier Emp ID and has attributes Name, Rank, and Office Phone.

• Timeslot has identifier TSIS and has attributes Day Of Week, Start Time, and End Time.

• Course has identifier Course ID and has attributes Course Description and Credits. Courses can have one, none, or many prerequisites. Courses also have one or more sections.

• Section has identifier Section ID and attribute Enroll- ment Limit.

After some further discussions, you have come up with some additional business rules to help you create the initial design:

• An instructor teaches one, none, or many sections of a course in a given semester.

• An instructor specifies preferred time slots. • Scheduling data are kept for each semester, uniquely

identified by semester and year. • A room can be scheduled for one section or no section

during one time slot in a given semester of a given year. However, one room can participate in many schedules, one schedule, or no schedules; one time slot can participate in many schedules, one schedule, or no schedules; one section can participate in many schedules, one schedule, or no schedules. Hint: Can you associate this to anything that you have seen before?

• A room can have one type of media, several types of media, or no media.

• Instructors are trained to use one, none, or many types of media.

• A lab has one or more computer types. However, a classroom does not have any computers.

• A room cannot be both a classroom and a lab. There also are no other room types to be incorporated into the system.

3-34. Develop an EER model for the following situation using the traditional EER notation, the Visio notation, or the subtypes inside supertypes notation, as specified by your instructor:

Wally Los Gatos and his partner Henry Chordate have formed a new limited partnership, Fin and Finicky Secu- rity Consultants. Fin and Finicky consults with corpora- tions to determine their security needs. You have been hired by Wally and Henry to design a database manage- ment system to help them manage their business. Due to a recent increase in business, Fin and Finicky has decided to automate its client tracking system. You and your team have done a preliminary analysis and come up with the following set of entities, attributes, and business rules:

Consultant There are two types of consultants: business consultants and technical consultants. Business consultants are con- tacted by a business in order to first determine security needs and provide an estimate for the actual services to be performed. Technical consultants perform services according to the specifications developed by the business consultants.

Attributes of business consultant are the following: Employee ID (identifier), Name, Address (which is com- posed of Street, City, State, and Zip Code), Telephone, Date Of Birth, Age, Business Experience (which is composed of Number of Years, Type of Business [or businesses], and Degrees Received).

M03_HOFF3359_13_GE_C03.indd 181 10/04/19 4:57 PM

182 Part II • Database Analysis and Logical Design

Attributes of technical consultant are the follow- ing: Employee ID (identifier), Name, Address (which is composed of Street, City, State, and Zip Code), Tele- phone, Date Of Birth, Age, Technical Skills, and Degrees Received.

Customer Customers are businesses that have asked for consulting services. Attributes of customer are Customer ID (iden- tifier), Company Name, Address (which is composed of Street, City, State, and Zip Code), Contact Name, Contact Title, Contact Telephone, Business Type, and Number Of Employees.

Location Customers can have multiple locations. Attributes of loca- tion are Customer ID (identifier), Location ID (which is unique only for each Customer ID), Address (which is composed of Street, City, State, and Zip Code), Telephone, and Building Size.

Service A security service is performed for a customer at one or more locations. Before services are performed, an esti- mate is prepared. Attributes of service are Service ID (identifier), Description, Cost, Coverage, and Clearance Required.

Additional Business Rules In addition to the entities outlined previously, the follow- ing information will need to be stored to tables and should be shown in the model. These may be entities, but they also reflect a relationship between more than one entity:

• Estimates, which have characteristics of Date, Amount, Business Consultant, Services, and Customer

• Services Performed, which have characteristics of Date, Amount, Technical Consultant, Services, and Customer

In order to construct the EER diagram, you may assume the following:

A customer can have many consultants providing many services. You wish to track both actual services performed as well as services offered. Therefore, there should be two relationships between customer, service, and consultant, one to show services performed and one to show services offered as part of the estimate.

3-35. Based on the EER diagram constructed for Problem and Exercise 3-34, develop a sample definition for each entity type, attribute, and relationship in the diagram.

3-36. Refer to your answer to Problem and Exercise 2-51 in Chapter 2. The description for DocIT explained that there were to be data in the database about people who are not patients but are related to patients. Also, it is possible for some staff members to be patients or to be related to patients. And, some staff members have no reason to see patients in appointments, but these staff members pro- vide functions related to only claims processing. Develop supertypes and subtypes to more clearly represent these distinctions, and draw a new EER diagram to show your revised data model.

3-37. Draw an EER diagram for the following problem: A uni- versity is looking to more effectively manage lecture and student appointments. It is currently unable to deter- mine how much time lecturers are devoting to student appointments and consultation and would therefore like a system through which this can be monitored and tracked. Each lecturer is required to set aside 10 hours a week for student consultations. Students can book a consultation via the system as well as cancel it if they wish to. Lecturers can allocate the 10 hours as they see fit depending on their teaching and research commit- ments. Lecturers can therefore determine the number of consultation slots they want to assign for the week, the duration of each slot, the day of the consultation, the time, and the location. The system automatically calculates the hours set and informs the lecturer if more hours are required.

3-38. Add the following to Figure 3-16: An EMPLOYMENT party relationship is further explained by the positions and assignments to positions during the time a person is employed. A position is defined by an organization unit, and a unit may define many positions over time. Over time, positions are assigned to various employ- ment relationships (i.e., somebody employed by some organization unit is assigned a particular position). For example, a position of Business Analyst is defined by the Systems Development organization unit. Carl Gerber, while employed by the Data Warehousing organization unit, is assigned the position of systems analyst. In the spirit of universal data modeling, enhance Figure 3-16 for the most general case consistent with this description.

Field Exercises

3-39. Observe the kind of people who work in your college or university. Interview an official who collects data on these people. Ask about the attributes on which data is collected. Is there a supertype/subtype relationship in this scenario? Apply generalization/specialization rules to construct an ER model for this situation. You can use a subtype discriminator.

3-40. Visit your local library and observe the library users and librarians at work. Ask a librarian how the library records

and stores its information about its borrowers, books, and loans. Based on this information, determine whether the library’s business rules and which of this chapter’s con- cepts have been applied to the design of library’s current database.

3-41. Ask a database administrator or database or system analyst in a local company to show you an EER (or E-R) diagram for one of the organization’s primary databases. Does this organization model have supertype/subtype relationships?

M03_HOFF3359_13_GE_C03.indd 182 10/04/19 2:33 PM

3 • The Enhanced E-R Model 183

If so, what notation is used, and does the CASE tool the company uses support these relationships? Also, what types of business rules are included during the EER modeling phase? How are business rules represented, and how and where are they stored?

3-42. There are other extensions to ER notation than just supertype/subtype relationships. Use the Internet to search for such extensions. One mentioned in the text is aggregation. Look for its examples on the Internet. Report your findings and state the extensions, what

they are intended for, some examples, and what you understood from them.

3-43. Interview a DB analyst or systems administrator in your university or at a local company that has adopted a pack- aged data model. Discuss how they adopted the model. What was the process of customization or mapping involved? Was the process complex? What challenges did they face during customization? Would it have been better if they had developed their own model? Report your findings.

References

Agnew, P., and L. Silverston. 2009. “What Are Universal Patterns for Data Modeling.” Available at www.b-eye-network.com/ view/9644.

Elmasri, R., and S. B. Navathe. 2011. Fundamentals of Data- base Systems (6th ed.). Reading, MA: Pearson/Addison- Wesley.

Gottesdiener, E. 1997. “Business Rules Show Power, Promise.” Application Development Trends 4,3 (March): 36–54.

GUIDE. 1997 (October). “GUIDE Business Rules Project.” Final Report, revision 1.2.

Hay, D. C. 1996. Data Model Patterns: Conventions of Thought. New York: Dorset House Publishing.

Hoberman, S. 2006. “Industry Logical Data Models.” Teradata Magazine. Available at www.teradata.com.

Silverston, L. 1998. “Is Your Organization Too Unique to Use Universal Data Models?” DM Review 8,8 (September). Available at www.information-management.com/ issues/19980901/425-1.html.

Silverston, L. 2001a. The Data Model Resource Book, Volume 1, Rev. ed. New York: Wiley.

Silverston, L. 2001b. The Data Model Resource Book, Volume 2, Rev. ed. New York: Wiley.

Silverston, L. 2002. “A Universal Data Model for Relationship Development.” DM Review 12,3 (March): 44–47, 65.

Teorey, T. 1999. Database Modeling & Design. San Francisco: Morgan Kaufman Publishers.

Valacich, J.S. and J.F. George. 2016 Modern Systems Analysis and Design. 8th ed. Upper Saddle River, NJ: Prentice Hall.

Further Reading

Frye, C. 2002. “Business Rules Are Back.” Application Development Trends 9,7 (July): 29–35.

Moriarty, T. “Using Scenarios in Information Modeling: Bring- ing Business Rules to Life.” Database Programming & Design 6,8 (August): 65–67.

Ross, R. G. 1997. The Business Rule Book. Version 4. Boston: Business Rule Solutions, Inc.

Ross, R. G. 1998. Business Rule Concepts: The New Mechanics of Business Information Systems. Boston: Business Rule Solutions, Inc.

Ross, R. G. 2003. Principles of the Business Rule Approach. Boston: Addison-Wesley.

Schmidt, B. 1997. “A Taxonomy of Domains.” Database Programming & Design 10,9 (September): 95, 96, 98, 99.

Silverston, L. 2002. Silverston has a series of articles in DM Review that discuss universal data models in different settings. See in particular Vol. 12 issues 1 (January) on clickstream analysis, 5 (May) on health care, 7 (July) on financial services, and 12 (December) on manufacturing.

von Halle, B. 1996. “Object-Oriented Lessons.” Database Programming & Design 9,1 (January): 13–16.

von Halle, B. 2001. von Halle has a series of articles in DM Review on building a business rules system. These articles are in Vol. 11, issues 1–5 (January–May).

von Halle, B., and R. Kaplan. 1997. “Is IT Falling Short?” Database Programming & Design 10,6 (June): 15–17.

Web Resources

www.adtmag.com Web site of Application Development Trends, a leading publication on the practice of information systems development.

www.brsolutions.com Web site of Business Rule Solutions, the consulting company of Ronald Ross, a leader in the develop- ment of a business rule methodology. Or you can check out www.BRCommunity.com, which is a virtual community site for people interested in business rules (sponsored by Business Rule Solutions).

www.businessrulesgroup.org Web site of the Business Rules Group, formerly part of GUIDE International, which formulates and supports standards about business rules.

www.databaseanswers.org/data_models A fascinating site that shows more than 100 sample E-R diagrams for a wide vari- ety of applications and organizations. A variety of notations are used, so this a good site to also learn about variations in E-R diagramming.

M03_HOFF3359_13_GE_C03.indd 183 18/03/19 4:37 PM

184 Part II • Database Analysis and Logical Design

https://stevehoberman.com Link to the Web site of well-known data modeling expert Steve Hoberman, including a collection of blog postings and articles.

www.tdan.com Web site of The Data Administration Newsletter, which regularly publishes new articles, special reports, and news on a variety of data modeling and administration topics.

www.teradatauniversitynetwork.com Web site for Teradata University Network, a free resource for a wide variety of information about database management and related topics. Go to this site and search on “entity relationship” to see many articles and assignments related to EER data modeling.

M03_HOFF3359_13_GE_C03.indd 184 18/03/19 4:37 PM

3 • The Enhanced E-R Model 185

Case Description

Martin is encouraged by the progress you have made so far. As promised, he forwards you an e-mail from one of the key mem- bers of his staff, Pat Smith (an artist manager). He also provides you with an e-mail from Shannon Howard, a prospective artist who might use FAME’s services.

E-mail from Pat Smith, Artist Manager

I am Pat Smith, and I am one of the 20 artist managers working for Mr. Forondo. I have worked for him for 15 years, and I am one of the most senior managers within the company. I enjoy working here because Mr. Forondo trusts me and knows that I will do my job. One area we have been lacking in during the last 10–15 years is the use of computers to support our jobs, and it is great to hear and notice that something is happening in this area.

There are two areas that I find particularly important for me. First, I would like to have a system that would help me track prospective artists. There are so many talented musicians around the world that it is almost impossible to know who is doing what and where without keeping very good records and it seems that this would be an area where computers really could help. There are a lot of sources from which I get hints about young artists whose career I should start to follow. Sometimes my friends who are music critics call me and recommend a par- ticular young artist they have heard; sometimes I myself hear a promising artist perform; sometimes we find a jewel among the unsolicited recordings that are sent or referred to us; and we also follow a large number of newspapers, magazines, and web- sites that review performances. Over the years we have learned to value the opinions of certain critics who write reviews, thus it is very important to know the source of a recommendation or an opinion. Sometimes I deal with dozens or even hundreds of recommendations per day and thus the lists that I maintain in a Word file on my laptop just are not very easy to use and organize.

The system for managing prospective artists should keep track of the artists (including their name, gender, year of birth, instrument(s), university degrees, address, phone num- ber, e-mail, honors, etc.) and all the situations in which we have heard of them (including the source, a brief summary, a brief quality evaluation, and space for storing the original story or a reference to it if it was a review either in a newspaper or on the Web). It is essential that I can get this data reported quickly and in an easy-to-read format. It would be fantastic if I could query the database from my personal tablet and smartphone; I definitely need access to my laptop while on the road. This info would be maintained by any of the managers in the company or their administrative assistants (the assistants take care of most of the work with the reviews). I don’t know if Mr. Forondo told you but he makes the final decisions regarding who becomes the artist manager for a new artist if there is any question about the contributions in recruiting the artist.

The second system I would find very helpful would be an application that reports the revenues my artists have earned in

the past (we should be able to choose the period freely) and are predicted to earn in the future based on the contracts we have signed for them with our clients. This way, I would know how much I am earning and going to earn in the future. Somehow, it would be great if the system could also tell how much money I have spent on travel; as you might have learned, we managers pay our own travel costs from the 60 percent of royalties we receive. I am really happy we don’t need to pay the assistant’s salaries, too.

E-mail from Shannon Howard, Prospective Artist

I am Shannon Howard, a soprano from Bloomington, Indiana, and I have had some initial discussions with Pat Smith at FAME regarding the possibility that they might take me under management. I feel that having a good manager would be very important for my career, and I believe that FAME would provide excellent service for me.

One area where FAME is not yet very strong is marketing their artists on the Internet, and maybe your project could have some impact in this area. I think it would be an excellent idea if prospective concert organizers could see an artist’s information on the Web and also hear samples of his/her music. In addition, information about an artist’s availability should be available on the Internet. By the way, has anybody remembered to tell you that an artist may be prevented from performing somewhere not only because of an earlier commitment to perform but also because of rehearsals or time needed for travel? Sometimes large productions need long practice times and transcontinental travel also can take several days away from an artist’s schedule. For me it is very important that I can personally negotiate with my man- ager what I will perform and what I won’t, and I think it would be great if my manager would know what repertoire I have already prepared and what I am not willing or able to perform at this time. Also, it would be great if I could block time away from my calendar in different priority groups so that I could say that certain days I am definitely not available, certain days are not very good but I can perform if Pat can find an excellent opportunity for me, and on certain days I can take any work. I don’t know if this is realistic technologically and whether or not Pat would accept the idea, but it sure would be nice from my perspective.

The smoother all types of practical issues go, the better I can focus on my actual work, i.e., singing. Therefore, I feel that it is very important that FAME has a good computer system to help them in their work for me (assuming I can sign up with them—wish me luck!). I would find it very helpful if they could tell me at the end of the year how much money I have made and from whom I received it—it won’t be a long list in the beginning but hopefully it will become much more extensive over time.

I don’t know if you have thought about it but just in case I have gigs around the world it would be very nice if the system could also tell how much (if anything) each of the governments withheld from my pay at the source before it was forwarded to FAME and if the payments could be sorted and subtotaled by country. If you wonder what this could mean in practice, let

CASE Forondo Artist Management Excellence Inc.

M03_HOFF3359_13_GE_C03.indd 185 18/03/19 4:37 PM

186 Part II • Database Analysis and Logical Design

me give you an example. Let’s say I am performing in Finland and Finland has an at-the-source tax for artists of 15 percent. If my fee there is $2,000, my employer in Finland has to withdraw 15 percent of my fee and pay it to the Finnish government; therefore, FAME will receive only $1,700, and if their royalty is 30 percent, I will receive only $1,190. At the end of the year, FAME should give me a report including four columns: my orig- inal fee (i.e., $2,000 in this case), tax-at-source ($300), FAME’s share ($510), and finally my share ($1,190). The math is simple but it is essential that this is done correctly so that I won’t be in trouble with the tax authorities either in foreign countries or here in the United States.

Project Questions

3-44. Create an EER diagram for FAME that extends the E-R diagram you developed in Chapter 2, 2-60, but accom- modates the information gleaned from the e-mails from Pat Smith and Shannon Howard.

3-45. Document your thought process around what changes you made to the model developed in Chapter 2, 2-60, to accommodate the new information. Pay particular atten- tion to what changes you had to make to the original model to accommodate the need for supertype/subtype relationships that emerged from the new information.

3-46. Use the narratives in Chapter 1 and above to identify the typical outputs (reports and displays) the various stakeholders might want to retrieve from your data- base. Now, revisit the EER diagram you created in 3-45 to ensure that your model has captured the information necessary to generate the outputs desired. Update your EER diagram as necessary.

3-47. Create a plan for reviewing your deliverables with the appropriate stakeholders. Which stakeholders should you meet with? Would you conduct the reviews sepa- rately or together? Who do you think should sign off on your EER model before you move to the next phase of the project?

M03_HOFF3359_13_GE_C03.indd 186 18/03/19 4:37 PM

187

4 LEARNING OBJECTIVES After studying this chapter, you should be able to:

■■ Concisely define each of the following key terms: relation, primary key, composite key, foreign key, null, entity integrity rule, referential integrity constraint, well- structured relation, anomaly, surrogate primary key, recursive foreign key, normalization, normal form, functional dependency, determinant, candidate key, first normal form, second normal form, partial functional dependency, third normal form, transitive dependency, synonyms, alias, homonym, and enterprise key.

■■ List five properties of relations. ■■ State two essential properties of a candidate key. ■■ Give a concise definition of each of the following: first normal form, second normal form, and third normal form.

■■ Briefly describe four problems that may arise when merging relations. ■■ Transform an E-R (or EER) diagram into a logically equivalent set of relations. ■■ Create relational tables that incorporate entity integrity and referential integrity constraints.

■■ Use normalization to decompose a relation with anomalies into well-structured relations.

INTRODUCTION

In this chapter, you will learn about logical database design, with special emphasis on the relational data model. Logical database design is the process of transforming the conceptual data model (described in Chapters 2 and 3) into a logical data model—one that is consistent and compatible with a specific type of database technology. An experienced database designer often will do logical database design in parallel with conceptual data modeling if he or she knows the type of database technology that will be used. It is, however, important to treat these as separate steps so that you concentrate on each important part of database development. Conceptual data modeling is about understanding the organization—getting the requirements right. Logical database design is about creating stable database structures—correctly expressing the requirements in a technical language. Both are important steps that must be performed carefully.

Although there are other logical data models, we have three reasons for emphasizing the relational data model in this chapter. First, the relational data

Visit www.pearsonglobaleditions .com to view the accompanying video for this chapter.

Logical Database Design and the Relational Model

M04_HOFF3359_13_GE_C04.indd 187 10/04/19 2:42 PM

188 Part II • Database Analysis and Logical Design

model is by far the one most commonly used in contemporary database applications. Second, some of the principles of logical database design for the relational model apply to the other logical models as well. Third, knowing the relational model for a database is sufficient for you to query a relational database using the widely used SQL standard, which you will study in the subsequent two chapters.

We have introduced the relational data model informally through simple examples in earlier chapters. It is important, however, to note that the relational data model is a form of logical data model, and as such it is different from the conceptual data models. Thus, an E-R data model is not a relational data model, and an E-R model may not obey the rules for a well-structured relational data model, called normalization, which we explain in this chapter. That is okay because the E-R model was developed for other purposes—understanding data requirements and business rules about the data—not structuring the data for sound database processing, which is the goal of logical database design.

In this chapter, you will learn the important terms and concepts for the relational data model. (We often use the abbreviated term relational model when referring to the relational data model.) Next you will study the process of transforming an EER model into the relational model. Many CASE tools support this transformation today at the technical level. It is, however, important that you understand the underlying principles and procedures. Then you will learn the concepts of normalization in detail. Normalization, which is the process of designing well-structured relations, is an important component of logical design for the relational model. Finally, you will learn how to merge relations while avoiding common pitfalls that may occur in this process.

The objective of logical database design is to translate the conceptual design (which represents an organization’s requirements for data) into a logical database design that can be implemented via a chosen database management system. The resulting databases must meet user needs for data sharing, flexibility, and ease of access. The concepts presented in this chapter are essential to your understanding of the database development process.

THE RELATIONAL DATA MODEL

The relational data model was first introduced in 1970 by E. F. Codd, then of IBM (Codd, 1970); yes, over 40 years old and still going strong. Two early research projects were launched to prove the feasibility of the relational model and to develop prototype systems. The first of these, at IBM’s San Jose Research Laboratory, led to the development of System R (a prototype relational DBMS [RDBMS]) during the late 1970s. The second, at the University of California at Berkeley, led to the development of Ingres, an academi- cally oriented RDBMS. Commercial RDBMS products from numerous vendors started to appear about 1980. (See the Web site for this text for links to DBMS vendors.) Today, RDBMSs have become the dominant technology for database management, and there are literally hundreds of RDBMS products for computers ranging from smartphones and personal computers to mainframes. In Chapter 10 we will discuss a new set of DBMS technologies under the umbrella of NoSQL (Not Only SQL); although increasing in pop- ularity, the use of these technologies is still not anywhere close to that of RDBMSs.

Basic Definitions

The relational data model represents data in the form of tables. The relational model is based on mathematical theory and therefore has a solid theoretical foundation. However, you need only a few simple concepts to describe the relational model. Therefore, it can be easily understood and used even by those unfamiliar with the underlying theory. The relational data model consists of the following three components (Fleming and von Halle, 1989):

1. Data structure Data are organized in the form of tables, with rows and columns. 2. Data manipulation Powerful operations (typically implemented using the SQL

language) are used to manipulate data stored in the relations. 3. Data integrity The model includes mechanisms to specify business rules that

maintain the integrity of data when they are manipulated.

M04_HOFF3359_13_GE_C04.indd 188 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 189

We discuss data structure and data integrity in this section. Data manipulation is discussed primarily in Chapters 5 and 6, and presented in an application context in Chapter 7.

RELATIONAL DATA STRUCTURE A relation is a named, two-dimensional table of data. Each relation (or table) consists of a set of named columns and an arbitrary number of unnamed rows. An attribute, consistent with its definition in Chapter 2, is a named column of a relation. Each row of a relation corresponds to a record that contains data (attribute) values for a single entity. Figure 4-1 shows an example of a relation named EMPLOYEE1. This relation contains the following attributes describing employees: EmpID, Name, DeptName, and Salary. The five rows of the table correspond to five employees. It is important to understand that the sample data in Figure 4-1 are intended to illustrate the structure of the EMPLOYEE1 relation; they are not part of the relation itself. Even if you add another row of data to the figure or change any of the data in the existing rows, it is still the same EMPLOYEE1 relation. Nor does deleting a row change the relation. In fact, you could delete all of the rows shown in Figure 4-1, and the EMPLOYEE1 relation would still exist. In other words, Figure 4-1 is an instance of the EMPLOYEE1 relation.

You can express the structure of a relation by using a shorthand notation in which the name of the relation is followed (in parentheses) by the names of the attributes in that relation. For EMPLOYEE1 we would have

EMPLOYEE1(EmpID, Name, DeptName, Salary)

RELATIONAL KEYS You must be able to store and retrieve a row of data in a relation, based on the data values stored in that row. To achieve this goal, every relation must have a primary key. A primary key is an attribute or a combination of attributes that uniquely identifies each row in a relation. You designate a primary key by underlining the attribute name(s). For example, the primary key for the relation EMPLOYEE1 is EmpID. Notice that this attribute is underlined in Figure 4-1. In shorthand notation, you express this relation as follows:

EMPLOYEE1(EmpID, Name, DeptName, Salary)

The concept of a primary key is related to the term identifier defined in Chapter 2. The attribute or a collection of attributes indicated as an entity’s identifier in an E-R diagram may be the same attributes that comprise the primary key for the relation rep- resenting that entity. There are exceptions: For example, associative entities do not have to have an identifier, and the (partial) identifier of a weak entity forms only part of a corresponding relation’s primary key. In addition, there may be several attributes of an entity that may serve as the associated relation’s primary key. All of these situations will be illustrated later in this chapter.

A composite key is a primary key that consists of more than one attribute. For exam- ple, the primary key for a relation DEPENDENT would likely consist of the combination

Relation

A named, two-dimensional table of data.

Primary key

An attribute or a combination of attributes that uniquely identifies each row in a relation.

Composite key

A primary key that consists of more than one attribute.

EMPLOYEE1

EmpID Name DeptName Salary

100 Margaret Simpson Marketing 48,000 140 Allen Beeton Accounting 52,000 110 Chris Lucero Info Systems 43,000 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000

FIGURE 4-1 EMPLOYEE1 relation with sample data

M04_HOFF3359_13_GE_C04.indd 189 15/03/19 3:38 PM

190 Part II • Database Analysis and Logical Design

EmpID and DependentName. You will see several examples of composite keys later in this chapter.

Often you must represent the relationship between two tables or relations. This is accomplished through the use of foreign keys. A foreign key is an attribute (possibly composite) in a relation that serves as the primary key of another relation. For example, consider the relations EMPLOYEE1 and DEPARTMENT:

EMPLOYEE1(EmpID, Name, DeptName, Salary) DEPARTMENT(DeptName, Location, Fax)

The attribute DeptName is a foreign key in EMPLOYEE1. It allows a user to asso- ciate any employee with the department to which he or she is assigned. Some authors emphasize the fact that an attribute is a foreign key by using a dashed underline, like this:

EMPLOYEE1(EmpID, Name, DeptName, Salary)

You will encounter numerous examples of foreign keys in the remainder of this chapter and will better understand the properties of foreign keys under the heading “Referential Integrity.”

PROPERTIES OF RELATIONS Relations are defined as two-dimensional tables of data. However, not all tables are relations. Relations have several properties that distinguish them from nonrelational tables. We summarize these properties next:

1. Each relation (or table) in a database has a unique name. 2. An entry at the intersection of each row and column is atomic (or single valued).

There can be only one value associated with each attribute on a specific row of a table; no multivalued attributes are allowed in a relation.

3. Each row is unique; no two rows in a relation can be identical. 4. Each attribute (or column) within a table has a unique name. 5. The sequence of columns (left to right) is insignificant. The order of the columns

in a relation can be changed without changing the meaning or use of the relation. 6. The sequence of rows (top to bottom) is insignificant. As with columns, the order

of the rows of a relation may be changed or stored in any sequence.

REMOVING MULTIVALUED ATTRIBUTES FROM TABLES The second property of relations listed in the preceding section states that no multivalued attributes are allowed in a relation. Thus, a table that contains one or more multivalued attributes is not a rela- tion. For example, Figure 4-2a shows the employee data from the EMPLOYEE1 relation extended to include courses that have been taken by those employees. Because a given employee may have taken more than one course, CourseTitle and DateCompleted are multivalued attributes. For example, the employee with EmpID 100 has taken two courses; therefore, there are two values of both CourseTitle (SPSS and Surveys) and DateCompleted (6/9/2018 and 10/7/2018) associated with one value of EmpID (100).

Foreign key

An attribute in a relation that serves as the primary key of another relation in the same database.

FIGURE 4-2 Eliminating multivalued attributes

EmpID Name DeptName Salary CourseTitle DateCompleted

100 Margaret Simpson Marketing 48,000 SPSS 6/19/2018 Surveys 10/7/2018

140 Alan Beeton Accounting 52,000 Tax Acc 12/8/2018 110 Chris Lucero Info Systems 43,000 Visual Basic 1/12/2018

C++ 4/22/2018 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/2018

Java 8/12/2018

(a) Table with repeating groups

M04_HOFF3359_13_GE_C04.indd 190 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 191

EMPLOYEE2

EmpID Name DeptName Salary CourseTitle DateCompleted

100 Margaret Simpson Marketing 48,000 SPSS 6/19/2018 100 Margaret Simpson Marketing 48,000 Surveys 10/7/2018 140 Alan Beeton Accounting 52,000 Tax Acc 12/8/2018 110 Chris Lucero Info Systems 43,000 Visual Basic 1/12/2018 110 Chris Lucero Info Systems 43,000 C++ 4/22/2018 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/19/2018 150 Susan Martin Marketing 42,000 Java 8/12/2018

(b) EMPLOYEE2 relation

If an employee has not taken any courses, the CourseTitle and DateCompleted attribute values are null. (See the employee with EmpID 190 for an example.)

You can see how to eliminate the multivalued attributes in Figure 4-2b by filling the relevant data values into the previously vacant cells of Figure 4-2a. As a result, the table in Figure 4-2b has only single-valued attributes and now satisfies the atomic prop- erty of relations. The name EMPLOYEE2 is given to this relation to distinguish it from EMPLOYEE1. However, as you will see, this new relation does have some undesirable properties. We will discuss some of them later in the chapter, but one of them is that the primary key column EmpID no longer uniquely identifies each of the rows.

Sample Database

A relational database may consist of any number of relations. The structure of the database is described through the use of a schema (defined in Chapter 1), which is a description of the overall logical structure of the database. There are two common methods for expressing a schema:

1. Short text statements, in which each relation is named and the names of its attri- butes follow in parentheses. (See the EMPLOYEE1 and DEPARTMENT relations defined earlier in this chapter.)

2. A graphical representation, in which each relation is represented by a rectangle containing the attributes for the relation.

Text statements have the advantage of simplicity. However, a graphical represen- tation provides a better means of expressing referential integrity constraints (as you will see shortly). In this section, you will see both techniques for expressing a schema so that you can compare them.

A schema for four relations at Pine Valley Furniture Company is shown in Figure 4-3. The four relations shown in this figure are CUSTOMER, ORDER, ORDER LINE, and PRODUCT. The key attributes for these relations are underlined, and other important attributes are included in each relation. You will learn how to design these relations using the techniques of normalization later in this chapter.

Following is a text description of these relations:

CUSTOMER(CustomerID, CustomerName, CustomerAddress, CustomerCity, CustomerState, CustomerPostalCode) ORDER(OrderID, OrderDate, CustomerID) ORDER LINE(OrderID, ProductID, OrderedQuantity) PRODUCT(ProductID, ProductDescription, ProductFinish, ProductStandardPrice, ProductLineID)

Notice that the primary key for ORDER LINE is a composite key consisting of the attributes OrderID and ProductID. Also, CustomerID is a foreign key in the ORDER

FIGURE 4-2 (continued)

M04_HOFF3359_13_GE_C04.indd 191 15/03/19 3:38 PM

192 Part II • Database Analysis and Logical Design

relation; this allows the user to associate an order with the customer who submitted the order. ORDER LINE has two foreign keys: OrderID and ProductID. These keys allow the user to associate each line on an order with the relevant order and product. In cases when a foreign key is also part of a composite key (such as this), frequently only the primary key role of the attribute is marked with a solid underline.

An instance of this database is shown in Figure 4-4. This figure shows four tables with sample data. Notice how the foreign keys allow us to associate the various tables. It is a good idea to create an instance of your relational schema with sample data for four reasons:

1. The sample data allow you to test your assumptions regarding the design. 2. The sample data provide a convenient way to check the accuracy of your design. 3. The sample data help improve communications with users in discussing your

design. 4. The sample data can be used to develop prototype applications and to test queries.

INTEGRITY CONSTRAINTS

The relational data model includes several types of constraints, or rules limiting acceptable values and actions, whose purpose is to facilitate maintaining the accu- racy and integrity of data in the database. The major types of integrity constraints are domain constraints, entity integrity, and referential integrity.

Domain Constraints

All of the values that appear in a column of a relation must be from the same domain. A domain is the set of values that may be assigned to an attribute. A domain definition usually consists of the following components: domain name, meaning, data type, size (or length), and allowable values or allowable range (if applicable). Table 4-1 shows domain definitions for the domains associated with the attributes in Figures 4-3 and 4-4.

Entity Integrity

The entity integrity rule is designed to ensure that every relation has a primary key and that the data values for that primary key are all valid. In particular, it guarantees that every primary key attribute is non-null.

CustomerID CustomerName CustomerAddress CustomerPostalCode

CUSTOMER

CustomerState*CustomerCity*

ProductID ProductFinishProductDescription ProductStandardPrice ProductLineID

PRODUCT

OrderID ProductID

ORDER LINE

OrderedQuantity

OrderID

ORDER

OrderDate CustomerID

* Not in Figure 2-22 for simplicity.

FIGURE 4-3 Schema for four relations (Pine Valley Furniture Company)

M04_HOFF3359_13_GE_C04.indd 192 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 193

FIGURE 4-4 Instance of a relational schema (Pine Valley Furniture Company)

TABLE 4-1 Domain Definitions for INVOICE Attributes

Attribute Domain Name Description Domain

CustomerID Customer IDs Set of all possible customer IDs character: size 5

CustomerName Customer Names Set of all possible customer names character: size 25

CustomerAddress Customer Addresses Set of all possible customer addresses character: size 30

CustomerCity Cities Set of all possible cities character: size 20

CustomerState States Set of all possible states character: size 2

CustomerPostalCode Postal Codes Set of all possible postal zip codes character: size 10

OrderID Order IDs Set of all possible order IDs character: size 5

OrderDate Order Dates Set of all possible order dates date: format mm/dd/yy

ProductID Product IDs Set of all possible product IDs character: size 5

ProductDescription Product Descriptions Set of all possible product descriptions character: size 25

ProductFinish Product Finishes Set of all possible product finishes character: size 15

ProductStandardPrice Unit Prices Set of all possible unit prices monetary: 6 digits

ProductLineID Product Line IDs Set of all possible product line IDs integer: 3 digits

OrderedQuantity Quantities Set of all possible ordered quantities integer: 3 digits

M04_HOFF3359_13_GE_C04.indd 193 15/03/19 3:38 PM

194 Part II • Database Analysis and Logical Design

PRODUCT

ORDER LINE

CustomerID CustomerName CustomerAddress CustomerCity CustomerState CustomerPostalCode

CUSTOMER

ProductID ProductFinishProductDescription ProductStandardPrice ProductLineID

OrderID

ORDER

OrderDate

OrderID ProductID OrderedQuantity

CustomerID

FIGURE 4-5 Referential integrity constraints (Pine Valley Furniture Company)

In some cases, a particular attribute cannot be assigned a data value. There are two situations in which this is likely to occur: Either there is no applicable data value or the applicable data value is not known when values are assigned. Suppose, for example, that you fill out an employment form that has a space reserved for a fax number. If you have no fax number, you leave this space empty because it does not apply to you. Or suppose that you are asked to fill in the telephone number of your previous employer. If you do not recall this number, you may leave it empty because that information is not known. You might also want to leave it empty because you do not want your current employer to know that you are seeking for another position.

The relational data model allows you to assign a null value to an attribute in the just described situations. A null is a value that may be assigned to an attribute when no other value applies or when the applicable value is unknown. In reality, a null is not a value, but rather it indicates the absence of a value. For example, it is not the same as a numeric zero or a string of blanks. The inclusion of nulls in the relational model is somewhat controversial, because it sometimes leads to anomalous results (Date, 2003). However, Codd, the inventor of the relational model, advocates the use of nulls for missing values (Codd, 1990).

Everyone agrees that primary key values must not be allowed to be null. Thus, the entity integrity rule states the following: No primary key attribute (or component of a primary key attribute) may be null.

Referential Integrity

In the relational data model, associations between tables are defined through the use of foreign keys. For example, in Figure 4-4, the association between the CUSTOMER and ORDER tables is defined by including the CustomerID attribute as a foreign key in ORDER. This implies that before we insert a new row in the ORDER table, the customer for that order must already exist in the CUSTOMER table. If you examine the rows in the ORDER table in Figure 4-4, you will find that every customer number for an order already appears in the CUSTOMER table.

A referential integrity constraint is a rule that maintains consistency among the rows of two relations. The rule states that if there is a foreign key in one relation, either each foreign key value must match a primary key value in another relation or the foreign key value must be null. You should examine the tables in Figure 4-4 to check whether the referential integrity rule has been enforced.

The graphical version of the relational schema provides a simple technique for identifying associations where referential integrity must be enforced. Figure 4-5 shows the schema for the relations introduced in Figure 4-3. An arrow has been drawn from each foreign key to the associated primary key. A referential integrity constraint must be

Null

A value that may be assigned to an attribute when no other value applies or when the applicable value is unknown.

Entity integrity rule

A rule that states that no primary key attribute (or component of a primary key attribute) may be null.

Referential integrity constraint

A rule that states that either each foreign key value must match a primary key value in another relation or the foreign key value must be null.

M04_HOFF3359_13_GE_C04.indd 194 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 195

defined for each of these arrows in the schema. Remember that OrderID and ProductID in ORDER LINE are both foreign keys and components of a composite primary key.

How do you know whether a foreign key is allowed to be null? If each order must have a customer (a mandatory relationship), then the foreign key CustomerID cannot be null in the ORDER relation. If the relationship is optional, then the foreign key could be null. Whether a foreign key can be null must be specified as a property of the foreign key attribute when the database is defined.

Actually, whether a foreign key can be null is more complex to model on an E-R diagram and to determine than we have shown so far. For example, what happens to order data if we choose to delete a customer who has submitted orders? We may want to see sales even if we do not care about the customer any more. Three choices are possible:

1. Delete the associated orders (called a cascading delete), in which case we lose not only the customer but also all the sales history.

2. Prohibit deletion of the customer until all associated orders are first deleted (a safety check).

3. Place a null value in the foreign key (an exception stating that although an order must have a CustomerID value when the order is created, CustomerID can become null later if the associated customer is deleted).

We will see how each of these choices is implemented when we describe the SQL database query language in Chapter 5. Note that in practice, organizational rules and various regulations regarding data retention often determine what data can be deleted and when, and they therefore govern the choice between various deletion options.

Creating Relational Tables

In this section, we create table definitions for the four tables shown in Figure 4-5. These definitions are created using the CREATE TABLE statements of the SQL data definition language. In practice, these table definitions are actually created during the implemen- tation phase later in the database development process. However, we show these sam- ple tables in this chapter for continuity and especially to illustrate the way the integrity constraints described previously are implemented in SQL.

The SQL table definitions are shown in Figure 4-6. One table is created for each of the four relations shown in the relational schema (Figure 4-5). Each attribute for a table is then defined. Notice that the data type and length for each attribute are taken from the domain definitions (Table 4-1). For example, the attribute CustomerName in the Customer_T table is defined as VARCHAR (variable character) data type with length  25. By specifying NOT NULL, each attribute can be constrained from being assigned a null value.

The primary key is specified for each table using the PRIMARY KEY clause at the end of each table definition. The OrderLine_T table illustrates how to specify a primary key when that key is a composite attribute. In this example, the primary key of OrderLine_T is the combination of OrderID and ProductID. Each primary key attribute in the four tables is constrained with NOT NULL. This enforces the entity integrity con- straint described in the previous section. Notice that the NOT NULL constraint can also be used with non-primary-key attributes.

Referential integrity constraints are easily defined, based on the graphical schema shown in Figure 4-5. An arrow originates from each foreign key and points to the related primary key in the associated relation. In the SQL table definition, a FOREIGN KEY REFERENCES statement corresponds to each of these arrows. Thus, for the table Order_T, the foreign key CustomerID references the primary key of Customer_T, which is also called CustomerID. Although in this case the foreign key and primary key have the same name, this is not required. For example, the foreign key attribute could be named CustNo instead of CustomerID. However, the foreign and primary keys must be from the same domain (i.e., they must have the same data type).

The OrderLine_T table provides an example of a table that has two foreign keys. For- eign keys in this table reference the Order_T and Product_T tables, respectively. Note that these two foreign keys are also the components of the primary key of OrderLine_T. This type of structure is very common as an implementation of a many-to-many relationship.

M04_HOFF3359_13_GE_C04.indd 195 15/03/19 3:38 PM

196 Part II • Database Analysis and Logical Design

Well-Structured Relations

To prepare for our discussion of normalization, we need to address the following ques- tion: What constitutes a well-structured relation? Intuitively, a well-structured relation contains minimal redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies. EMPLOYEE1 (Figure 4-1) is such a relation. Each row of the table contains data describing one employee, and any modification to an employee’s data (such as a change in salary) is confined to one row of the table. In contrast, EMPLOYEE2 (Figure 4-2b) is not a well-structured relation. If you examine the sample data in the table, you will notice considerable redundancy. For example, values for EmpID, Name, DeptName, and Salary appear in two separate rows for employees 100, 110, and 150. Consequently, if the salary for employee 100 changes, we must record this fact in two rows.

Redundancies in a table may result in errors or inconsistencies (called anomalies) when a user attempts to update the data in the table. We are typically concerned about three types of anomalies:

1. Insertion anomaly Suppose that we need to add a new employee to EMPLOYEE2. The primary key for this relation is the combination of EmpID and CourseTitle (as noted earlier). Therefore, to insert a new row, the user must supply values for both EmpID and CourseTitle (because primary key values cannot be null or nonexis- tent). This is an anomaly because the user should be able to enter employee data without supplying course data.

2. Deletion anomaly Suppose that the data for employee number 140 are deleted from the table. This will result in losing the information that this employee com- pleted a course (Tax Acc) on 12/8/2018. In fact, it results in losing the information that this course had an offering that completed on that date.

Well-structured relation

A relation that contains minimal redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies.

Anomaly

An error or inconsistency that may result when a user attempts to update a table that contains redundant data. The three types of anomalies are insertion, deletion, and modification anomalies.

CREATE TABLE Customer_T (CustomerID NUMBER(11,0) NOT NULL, CustomerName VARCHAR2(25) NOT NULL, CustomerAddress VARCHAR2(30), CustomerCity VARCHAR2(20), CustomerState CHAR(2), CustomerPostalCode VARCHAR2(9),

CONSTRAINT Customer_PK PRIMARY KEY (CustomerID));

CREATE TABLE Order_T (OrderID NUMBER(11,0) NOT NULL, OrderDate DATE DEFAULT SYSDATE, CustomerID NUMBER(11,0),

CONSTRAINT Order_PK PRIMARY KEY (OrderID), CONSTRAINT Order_FK FOREIGN KEY (CustomerID) REFERENCES Customer_T (CustomerID));

CREATE TABLE Product_T (ProductID NUMBER(11,0) NOT NULL, ProductDescription VARCHAR2(50), ProductFinish VARCHAR2(20), ProductStandardPrice DECIMAL(6,2), ProductLineID NUMBER(11,0),

CONSTRAINT Product_PK PRIMARY KEY (ProductID));

CREATE TABLE OrderLine_T (OrderID NUMBER(11,0) NOT NULL, ProductID NUMBER(11,0) NOT NULL, OrderedQuantity NUMBER(11,0),

CONSTRAINT OrderLine_PK PRIMARY KEY (OrderID, ProductID), CONSTRAINT OrderLine_FK1 FOREIGN KEY (OrderID) REFERENCES Order_T (OrderID), CONSTRAINT OrderLine_FK2 FOREIGN KEY (ProductID) REFERENCES Product_T (ProductID));

FIGURE 4-6 SQL table definitions

M04_HOFF3359_13_GE_C04.indd 196 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 197

3. Modification anomaly Suppose that employee number 100 gets a salary increase. We must record the increase in each of the rows for that employee (two occur- rences in Figure 4-2); otherwise, the data will be inconsistent.

These anomalies indicate that EMPLOYEE2 is not a well-structured relation. The prob- lem with this relation is that it contains data about two entities: EMPLOYEE and COURSE. We will use normalization theory (described later in this chapter) to divide EMPLOYEE2 into two relations. One of the resulting relations is EMPLOYEE1 ( Figure 4-1). The other we will call EMPCOURSE, which appears with sample data in Figure 4-7. The primary key of this relation is the combination of EmpID and CourseTitle, and we underline these attribute names in Figure 4-7 to highlight this fact. Examine Figure 4-7 to verify that EMPCOURSE is free of the types of anomalies described previously and is therefore well structured.

TRANSFORMING EER DIAGRAMS INTO RELATIONS

During logical design, you transform the E-R (and EER) diagrams that were developed during conceptual design into relational database schemas. The inputs to this process are the E-R (and enhanced E-R) diagrams that you studied in Chapters 2 and 3. The out- puts are the relational schemas described in the first two sections of this chapter.

Transforming (or mapping) EER diagrams into relations is a relatively straight- forward process with a well-defined set of rules. In fact, many CASE tools can auto- matically perform many of the conversion steps. However, it is important that you understand the steps in this process for four reasons:

1. CASE tools often cannot model more complex data relationships, such as ternary relationships and supertype/subtype relationships. In these situations, you may have to perform the steps manually.

2. There are sometimes legitimate alternatives for which you will need to choose a particular solution.

3. You must be prepared to perform a quality check on the results obtained with a CASE tool.

4. Understanding the transformation process helps you understand why conceptual data modeling (modeling the real-world domain) is different from logical data modeling (i.e., representing the data items within the domain in a way that can be implemented with a DBMS).

In the following discussion, you will see the steps in the transformation with examples taken from Chapters 2 and 3. It will help for you to recall that we discussed three types of entities in those chapters:

1. Regular entities are entities that have an independent existence and generally represent real-world objects, such as persons and products. Regular entity types are represented by rectangles with a single line.

2. Weak entities are entities that cannot exist except with an identifying relation- ship with an owner (regular) entity type. Weak entities are identified by a rect- angle with a double line.

3. Associative entities (also called gerunds) are formed from many-to-many rela- tionships between other entity types. Associative entities are represented by a rectangle with rounded corners.

EmpID CourseTitle DateCompleted

100 SPSS 6/19/2018 100 Surveys 10/7/2018 140 Tax Acc 12/8/2018 110 Visual Basic 1/12/2018 110 C++ 4/22/2018 150 SPSS 6/19/2018 150 Java 8/12/2018

FIGURE 4-7 EMPCOURSE

M04_HOFF3359_13_GE_C04.indd 197 15/03/19 3:38 PM

198 Part II • Database Analysis and Logical Design

Step 1: Map Regular Entities

Each regular entity type in an E-R diagram is transformed into a relation. The name given to the relation is generally the same as the entity type. Each simple attribute of the entity type becomes an attribute of the relation. The identifier of the entity type becomes the primary key of the corresponding relation. You should check to make sure that this primary key satisfies the desirable properties of identifiers outlined in Chapter 2.

Figure 4-8a shows a representation of the CUSTOMER entity type for Pine Valley Furniture Company from Chapter 2 (see Figure 2-22). The corresponding CUSTOMER relation is shown in graphical form in Figure 4-8b. In this figure and those that follow in this section, we show only a few key attributes for each relation to simplify the figures.

COMPOSITE ATTRIBUTES When a regular entity type has a composite attribute, only the simple components of the composite attribute are included in the new relation as its attributes. Figure 4-9 shows a variant of the example in Figure 4-8, where Customer Address is represented as a composite attribute with components Street, City, and State (see Figure 4-9a). This entity is mapped to the CUSTOMER relation, which contains the simple address attributes, as shown in Figure 4-9b. Although Customer Name is mod- eled as a simple attribute in Figure 4-9a, it could have been (and, in practice, would have been) modeled as a composite attribute with components Last Name, First Name, and Middle Initial. In designing the CUSTOMER relation (Figure 4-9b), you may choose to use these simple attributes instead of CustomerName. Compared to composite attributes, simple attributes improve data accessibility and facilitate maintaining data quality. For example, for data reporting and other output purposes it is much easier if CustomerName is represented with its components (last name, first name, and middle initial separately). This way, any process reporting the data can easily create any format it needs to.

FIGURE 4-8 Example of mapping a regular entity

CUSTOMER Customer ID Customer Name Customer Address Customer Postal Code

CustomerID

CUSTOMER

CustomerName CustomerAddress CustomerPostalCode

(a) CUSTOMER entity type

(b) CUSTOMER relation

FIGURE 4-9 Example of mapping a composite attribute

Customer ID Customer Name Customer Address (Customer Street, Customer City, Customer State) Customer Postal Code

CUSTOMER

CustomerID CustomerName CustomerStreet CustomerCity CustomerState CustomerPostalCode

CUSTOMER

(a) CUSTOMER entity type with composite attribute

(b) CUSTOMER relation with address detail

M04_HOFF3359_13_GE_C04.indd 198 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 199

MULTIVALUED ATTRIBUTES When the regular entity type contains a multivalued attri- bute, two new relations (rather than one) are created. The first relation contains all of the attributes of the entity type except the multivalued attribute. The second relation contains two attributes that form the primary key of the second relation. The first of these attributes is the primary key from the first relation, which becomes a foreign key in the second relation. The second is the multivalued attribute. The name of the second relation should capture the meaning of the multivalued attribute.

An example of this procedure is shown in Figure 4-10. This is the EMPLOYEE entity type for Pine Valley Furniture Company. As shown in Figure 4-10a, EMPLOYEE has Skill as a multivalued attribute. Figure 4-10b shows the two relations that are cre- ated. The first (called EMPLOYEE) has the primary key EmployeeID. The second rela- tion (called EMPLOYEE SKILL) has the two attributes, EmployeeID and Skill, which form the primary key. The relationship between foreign and primary keys is indicated by the arrow in the figure.

The relation EMPLOYEE SKILL contains no nonkey attributes (also called descrip- tors). Each row simply records the fact that a particular employee possesses a particular skill. This provides an opportunity for you to suggest to users that new attributes can be added to this relation. For example, the attributes YearsExperience and/or Certifica- tionDate might be appropriate new values to add to this relation. (See Figure 2-15b for another variation on employee skills.) If SKILL itself needs additional attributes, you can create a separate SKILL relation. In this case, EMPLOYEE SKILL becomes an asso- ciative entity between EMPLOYEE and SKILL.

If an entity type contains multiple multivalued attributes, each of them will be converted to a separate relation.

Remember, the transformation process described here is technology indepen- dent. There are many (but not all) relational database management systems that, in fact, support multivalued attributes in a table. For those systems, you will have the choice whether to create a separate table to hold the multivalued attributes or to use the facili- ties of the DBMS to allow users to envision a multivalued attribute as part of the same table as the other related simple attributes.

Step 2: Map Weak Entities

Recall that a weak entity type does not have an independent existence but exists only through an identifying relationship with another entity type called the owner. A weak entity type does not have a complete identifier but must have an attribute called a par- tial identifier that permits distinguishing the various occurrences of the weak entity for each owner entity instance.

FIGURE 4-10 Example of mapping an entity with a multivalued attributeEMPLOYEE

Employee ID Employee Name Employee Address {Skill}

EmployeeID

EMPLOYEE SKILL

Skill

EmployeeID

EMPLOYEE

EmployeeAddressEmployeeName

(a) EMPLOYEE entity type with multivalued attribute

(b) EMPLOYEE and EMPLOYEE SKILL relations

M04_HOFF3359_13_GE_C04.indd 199 15/03/19 3:38 PM

200 Part II • Database Analysis and Logical Design

The following procedure assumes that you have already created a relation corre- sponding to the identifying entity type during Step 1. If you have not, you should create that relation now, using the process described in Step 1.

For each weak entity type, create a new relation and include all of the simple attri- butes (or simple components of composite attributes) as attributes of this relation. Then include the primary key of the identifying relation as a foreign key attribute in this new relation. The primary key of the new relation is the combination of this primary key of the identifying relation and the partial identifier of the weak entity type.

An example of this process is shown in Figure 4-11. Figure 4-11a shows the weak entity type DEPENDENT and its identifying entity type EMPLOYEE, linked by the identifying relationship Claims (see Figure 2-5). Notice that the attribute Dependent Name, which is the partial identifier for this relation, is a composite attribute with com- ponents First Name, Middle Initial, and Last Name. Thus, we assume that, for a given employee, these items will uniquely identify a dependent (a notable exception being the case of prizefighter George Foreman, who has named all his sons after himself).

Figure 4-11b shows the two relations that result from mapping this E-R segment. The primary key of DEPENDENT consists of four attributes: EmployeeID, FirstName, MiddleInitial, and LastName. DateOfBirth and Gender are the nonkey attributes. The foreign key relationship with its primary key is indicated by the arrow in the figure.

In practice, an alternative approach is often used to simplify the primary key of the DEPENDENT relation: Create a new attribute (called DependentID), which will be used as a surrogate primary key in Figure 4-11b. With this approach, the relation DEPENDENT has the following attributes:

DEPENDENT(DependentID, EmployeeID, FirstName, MiddleInitial, LastName, DateOfBirth, Gender)

DependentID is simply a serial number that is assigned to each dependent of an employee. Notice that this solution will ensure unique identification for each dependent (even for those of George Foreman!).

WHEN TO CREATE A SURROGATE KEY A surrogate key is usually created to simplify the key structures. According to Hoberman (2006), a surrogate key should be created when any of the following conditions hold:

Surrogate primary key

A serial number or other system- assigned primary key for a relation.

FIGURE 4-11 Example of mapping a weak entity

EMPLOYEE Employee ID Employee Name

DEPENDENT Dependent Name

(First Name, Middle Initial, Last Name) Date of Birth Gender

Claims

EmployeeID

EMPLOYEE

EmployeeName

DateOfBirthFirstName MiddleInitial LastName EmployeeID

DEPENDENT

Gender

(a) Weak entity DEPENDENT

(b) Relations resulting from weak entity

M04_HOFF3359_13_GE_C04.indd 200 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 201

• There is a composite primary key, as in the case of the DEPENDENT relation shown previously with the four-component primary key.

• The natural primary key (i.e., the key used in the organization and recognized in conceptual data modeling as the identifier) is inefficient. For example, it may be very long and hence costly for database software to handle if it is used as a foreign key that references other tables.

• The natural primary key is recycled (i.e., the key is reused or repeated periodically, so it may not actually be unique over time); a more general statement of this con- dition is when the natural primary key cannot, in fact, be guaranteed to be unique over time (e.g., there could be duplicates, such as with names or titles).

Whenever a surrogate key is created, the natural key is always kept as nonkey data in the same relation because the natural key has organizational meaning that has to be captured in the database. In fact, surrogate keys mean nothing to users, so they are usually never shown to the user. Instead, the natural keys are used as identifiers in searches.

Step 3: Map Binary Relationships

The procedure for representing relationships depends on both the degree of the relation- ships (unary, binary, or ternary) and the cardinalities of the relationships. We describe and illustrate the important cases in the following discussion.

MAP BINARY ONE-TO-MANY RELATIONSHIPS For each binary 1:M relationship, first cre- ate a relation for each of the two entity types participating in the relationship, using the procedure described in Step 1. Next, include the primary key attribute (or attributes) of the entity on the one side of the relationship as a foreign key in the relation that is on the many side of the relationship. (A mnemonic you can use to remember this rule is this: The primary key migrates to the many side.)

To illustrate this simple process, we use the Submits relationship between cus- tomers and orders for Pine Valley Furniture Company (see Figure 2-22). This 1:M relationship is illustrated in Figure 4-12a. (Again, we show only a few attributes for simplicity.) Figure 4-12b shows the result of applying this rule to map the entity types with the 1:M relationship. The primary key CustomerID of CUSTOMER (the one side) is included as a foreign key in ORDER (the many side). The foreign key relationship is indicated with an arrow. Note that it is not necessary to name the foreign key attribute CustomerID. It is, however, essential that it has the same domain as the primary key it references.

FIGURE 4-12 Example of mapping a 1:M relationship

Submits

CUSTOMER Customer ID Customer Name Customer Address Customer Postal Code

ORDER ORDER ID Order Date

OrderDateOrderID

ORDER

CustomerID

CustomerID

CUSTOMER

CustomerAddress CustomerPostalCodeCustomerName

(a) Relationship between CUSTOMER and ORDER entities

(b) CUSTOMER and ORDER relations with a foreign key in ORDER

M04_HOFF3359_13_GE_C04.indd 201 15/03/19 3:38 PM

202 Part II • Database Analysis and Logical Design

MAP BINARY MANY-TO-MANY RELATIONSHIPS Suppose that there is a binary many- to-many (M:N) relationship between two entity types, A and B. For such a relationship, create a new relation, C. Include as foreign key attributes in C the primary key for each of the two participating entity types. These attributes together become the primary key of C. Any nonkey attributes that are associated with the M:N relationship are included with the relation C.

Figure 4-13 shows an example of applying this rule. Figure 4-13a shows the Completes relationship between the entity types EMPLOYEE and COURSE from Figure  2-11a. Figure 4-13b shows the three relations (EMPLOYEE, COURSE, and CERTIFICATE) that are formed from the entity types and the Completes relationship. If Completes had been represented as an associative entity, as is done in Figure 2-11b, a similar result would occur, but we will deal with associative entities in a sub- sequent section. In the case of an M:N relationship, a relation is first created for each of the two regular entity types EMPLOYEE and COURSE. Then a new relation (named CERTIFICATE in Figure 4-13b) is created for the Completes relationship. The primary key of CERTIFICATE is the combination of EmployeeID and Cour- seID, which are the respective primary keys of EMPLOYEE and COURSE. As indi- cated in the diagram, these attributes are foreign keys that “point to” the respective primary keys. The nonkey attribute DateCompleted also appears in CERTIFICATE. Although not shown here, it is often wise to create a surrogate primary key for the CERTIFICATE relation.

MAP BINARY ONE-TO-ONE RELATIONSHIPS Binary one-to-one relationships can be viewed as a special case of one-to-many relationships. The process of mapping such a relationship to relations requires two steps. First, two relations are created, one for each of the participating entity types. Second, the primary key of one of the relations is included as a foreign key in the other relation.

In a 1:1 relationship, the association in one direction is nearly always an optional one, whereas the association in the other direction is a mandatory one. (You can review the notation for these terms in Figure 2-1.) You should include in the relation

FIGURE 4-13 Example of mapping a M:N relationship

Completes

EMPLOYEE Employee ID Employee Name Employee Birth Date

Date Completed

COURSE Course ID Course Title

CERTIFICATE

EmployeeName EmployeeBirthDateEmployeeID

CourseID DateCompletedEmployeeID

EMPLOYEE

CourseTitleCourseID

COURSE

(a) Completes relationship (M:N)

(b) Three resulting relations

M04_HOFF3359_13_GE_C04.indd 202 15/03/19 3:38 PM

4 • Logical Database Design and the Relational Model 203

on the optional side of the relationship a foreign key referencing the primary key of the entity type that has the mandatory participation in the 1:1 relationship. This approach will prevent the need to store null values in the foreign key attribute. Any attributes associated with the relationship itself are also included in the same relation as the foreign key.

An example of applying this procedure is shown in Figure 4-14. Figure 4-14a shows a binary 1:1 relationship between the entity types NURSE and CARE CENTER. Each care center must have a nurse who is in charge of that center. Thus, the asso- ciation from CARE CENTER to NURSE is a mandatory one, whereas the association from NURSE to CARE CENTER is an optional one (since any nurse may or may not be in charge of a care center). The attribute Date Assigned is attached to the In Charge relationship.

The result of mapping this relationship to a set of relations is shown in Figure  4-14b. The two relations NURSE and CARE CENTER are created from the two entity types. Because CARE CENTER is the optional participant, the foreign key is placed in this relation. In this case, the foreign key is NurseInCharge. It has the same domain as NurseID, and the relationship with the primary key is shown in the fig- ure. The attribute DateAssigned is also located in CARE CENTER and would not be allowed to be null.

Step 4: Map Associative Entities

As explained in Chapter 2, when you encounter a many-to-many relationship, you may choose to model that relationship as an associative entity in the E-R diagram. This approach is most appropriate when the end user can best visualize the relationship as an entity type rather than as an M:N relationship. Mapping the associative entity involves essentially the same steps as mapping an M:N relationship, as described in Step 3.

The first step is to create three relations: one for each of the two participating entity types and a third for the associative entity. We refer to the relation formed from the associative entity as the associative relation. The second step then depends on whether on the E-R diagram an identifier was assigned to the associative entity.

IDENTIFIER NOT ASSIGNED If an identifier was not assigned, the default primary key for the associative relation is a composite key that consists of the two primary key attributes

FIGURE 4-14 Example of mapping a binary 1:1 relationship

In Charge

NURSE Nurse ID Nurse Name Nurse Birth Date

Date Assigned

CARE CENTER Center ID Center Location

CenterID CenterLocation

CARE CENTER

DateAssigned

NURSE

NurseID NurseName NurseBirthDate

NurseInCharge

(a) In Charge relationship (binary 1:1)

(b) Resulting relations

M04_HOFF3359_13_GE_C04.indd 203 15/03/19 3:38 PM

204 Part II • Database Analysis and Logical Design

from the other two relations. These attributes are then foreign keys that reference the other two relations.

An example of this case is shown in Figure 4-15. Figure 4-15a shows the associa- tive entity ORDER LINE that links the ORDER and PRODUCT entity types at Pine Valley Furniture Company (see Figure 2-22). Figure 4-15b shows the three relations that result from this mapping. Note the similarity of this example to that of an M:N relation- ship shown in Figure 4-13.

IDENTIFIER ASSIGNED Sometimes you will assign a single-attribute identifier to the associative entity type on the E-R diagram. Two reasons may have motivated you to assign a single-attribute key during conceptual data modeling:

1. The associative entity type has a natural single-attribute identifier that is familiar to end users.

2. The default identifier (consisting of the identifiers for each of the participating entity types) may not uniquely identify instances of the associative entity.

These motivations are in addition to the reasons mentioned earlier in this chapter to cre- ate a surrogate primary key.

The process for mapping the associative entity in this case is now modified as fol- lows. As before, a new (associative) relation is created to represent the associative entity. However, the primary key for this relation is the identifier assigned on the E-R diagram (rather than the default key). The primary keys for the two participating entity types are then included as foreign keys in the associative relation.

FIGURE 4-15 Example of mapping an associative entity

ORDER Order ID Order Date

PRODUCT Product ID Product Description Product Finish Product Standard Price Product Line ID

ORDER LINE

Ordered Quantity

Note: Product Line ID is included here because it is a foreign key into the PRODUCT LINE entity, not because it would normally be included as an attribute of PRODUCT

ProductID ProductDescription

PRODUCT

ProductFinish ProductStandardPrice ProductLineID

OrderID

ORDER

OrderDate

OrderID ProductID

ORDER LINE

OrderedQuantity

(a) An associative entity

(b) Three resulting relations

M04_HOFF3359_13_GE_C04.indd 204 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 205

An example of this process is shown in Figure 4-16. Figure 4-16a shows the asso- ciative entity type SHIPMENT that links the CUSTOMER and VENDOR entity types. Shipment ID has been chosen as the identifier for SHIPMENT for two reasons:

1. Shipment ID is a natural identifier for this entity that is very familiar to end users. 2. The default identifier consisting of the combination of Customer ID and Vendor

ID does not uniquely identify the instances of SHIPMENT. In fact, a given vendor typically makes many shipments to a given customer. Even including the attribute Date does not guarantee uniqueness since there may be more than one shipment by a particular vendor on a given date. The surrogate key ShipmentID will, how- ever, uniquely identify each shipment.

Two nonkey attributes associated with the SHIPMENT associative entity are Shipment Date and Shipment Amount.

The result of mapping this entity to a set of relations is shown in Figure 4-16b. The new associative relation is named SHIPMENT. The primary key is ShipmentID. CustomerID and VendorID are included as foreign keys in this relation, and ShipmentDate and Shipment- Amount are nonkey attributes. It is also possible that the designer decides as part of the logical modeling process to add a surrogate key into a relation that did not have it earlier. In these cases, it is highly recommended to update the conceptual model to keep it consistent.

Step 5: Map Unary Relationships

In Chapter 2, we defined a unary relationship as a relationship between the instances of a single entity type. Unary relationships are also called recursive relationships. The two most important cases of unary relationships are one-to-many and many-to-many relationships. We discuss these two cases separately because the approach to mapping is somewhat different for the two types.

UNARY ONE-TO-MANY RELATIONSHIPS The entity type in the unary relationship is mapped to a relation using the procedure described in Step 1. Next, a foreign key attri- bute is added to the same relation; this attribute references the primary key values in the same relation. (This foreign key must have the same domain as the primary key.) This type of a foreign key is called a recursive foreign key.

Recursive foreign key

A foreign key in a relation that references the primary key values of the same relation.

FIGURE 4-16 Example of mapping an associative entity with an identifierCUSTOMER

Customer ID Customer Name

SHIPMENT Shipment ID Shipment Date Shipment Amount

VENDOR Vendor ID Vendor Address

VendorID VendorAddress

VENDOR

CustomerID

CUSTOMER

CustomerName

ShipmentID CustomerID

SHIPMENT

VendorID ShipmentDate ShipmentAmount

(a) SHIPMENT associative entity

(b) Three resulting relations

M04_HOFF3359_13_GE_C04.indd 205 15/03/19 3:39 PM

206 Part II • Database Analysis and Logical Design

Figure 4-17a shows a unary one-to-many relationship named Manages that associates each employee of an organization with another employee who is his or her manager. Each employee may have one manager; a given employee may manage zero to many employees.

The EMPLOYEE relation that results from mapping this entity and relationship is shown in Figure 4-17b. The (recursive) foreign key in the relation is named ManagerID. This attribute has the same domain as the primary key EmployeeID. Each row of this relation stores the following data for a given employee: EmployeeID, EmployeeName, EmployeeDateOfBirth, and ManagerID (i.e., EmployeeID for this employee’s manager). Notice that because it is a foreign key, ManagerID references EmployeeID.

UNARY MANY-TO-MANY RELATIONSHIPS With this type of relationship, two relations are created: one to represent the entity type in the relationship and an associative rela- tion to represent the M:N relationship itself. The primary key of the associative relation consists of two attributes. These attributes (which need not have the same name) both take their values from the primary key of the other relation. Any nonkey attribute of the relationship is included in the associative relation.

An example of mapping a unary M:N relationship is shown in Figure 4-18. Figure  4-18a shows a bill-of-materials relationship among items that are assembled from other items or components. (This structure was described in Chapter 2, and an example appears in Figure 2-13.) The relationship (called Contains) is M:N because a given item can contain numerous component items, and, conversely, an item can be used as a component in numerous other items.

The relations that result from mapping this entity and its relationship are shown in Figure 4-18b. The ITEM relation is mapped directly from the same entity type. COM- PONENT is an associative relation whose primary key consists of two attributes that are arbitrarily named ItemNo and ComponentNo. The attribute Quantity is a nonkey

FIGURE 4-17 Example of mapping a unary 1:M relationship EMPLOYEE

Employee ID Employee Name Employee Date of Birth

Is Managed By

Manages

EmployeeID EmployeeName

EMPLOYEE

EmployeeDateOfBirth ManagerID

(a) EMPLOYEE entity with unary relationship

(b) EMPLOYEE relation with recursive foreign key

FIGURE 4-18 Example of mapping a unary M:N relationship

ITEM Item No Item Description Item Unit Cost

Quantity

Contains

(a) Bill-of-materials relationship Contains (M:N)

M04_HOFF3359_13_GE_C04.indd 206 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 207

attribute of this relation that, for a given item, records the quantity of a particular com- ponent item used in that item. Notice that both ItemNo and ComponentNo reference the primary key (ItemNo) of the ITEM relation. It is not unusual to give this relation a surrogate key to avoid any practical complexities related to the composite key.

We can easily query these relations to determine, for example, the components of a given item. The following SQL query will list the immediate components (and their quantity) for item number 100:

SELECT ComponentNo, Quantity FROM Component_T WHERE ItemNo = 100;

Step 6: Map Ternary (and n-ary) Relationships

Recall from Chapter 2 that a ternary relationship is a relationship among three entity types. In that chapter, we recommended that you convert a ternary relationship to an associative entity to represent participation constraints more accurately.

To map an associative entity type that links three regular entity types, you create a new associative relation. The default primary key of this relation consists of the three primary key attributes for the participating entity types. (In some cases, additional attri- butes are required to form a unique primary key.) These attributes then act in the role of foreign keys that reference the individual primary keys of the participating entity types. Any attributes of the associative entity type become attributes of the new relation.

An example of mapping a ternary relationship (represented as an associative entity type) is shown in Figure 4-19. Figure 4-19a is an E-R segment (or view) that represents

ItemNo

ITEM

ItemDescription ItemUnitCost

ItemNo ComponentNo

COMPONENT

Quantity

(b) ITEM and COMPONENT relations

FIGURE 4-18 (continued)

FIGURE 4-19 Example of mapping a ternary relationship

(a) PATIENT TREATMENT ternary relationship with associative entity

PATIENT Patient ID Patient Name

TREATMENT Treatment Code Treatment Description

PATIENT TREATMENT

PTreatment Date PTreatment Time PTreatment Results

PHYSICIAN Physician ID Physician Name

M04_HOFF3359_13_GE_C04.indd 207 15/03/19 3:39 PM

208 Part II • Database Analysis and Logical Design

a patient receiving a treatment from a physician. The associative entity type PATIENT TREATMENT has the attributes PTreatment Date, PTreatment Time, and PTreat- ment Results; values are recorded for these attributes for each instance of PATIENT TREATMENT.

The result of mapping this view is shown in Figure 4-19b. The primary key attri- butes PatientID, PhysicianID, and TreatmentCode become foreign keys in PATIENT TREATMENT. The foreign key into TREATMENT is called PTreatmentCode in PATIENT TREATMENT. We are using this column name to illustrate that the foreign key name does not have to be the same as the name of the primary key to which it refers, as long as the values come from the same domain. These three attributes are components of the primary key of PATIENT TREATMENT. However, they do not uniquely identify a given treatment because a patient may receive the same treatment from the same physician on more than one occasion. Does including the attribute Date as part of the primary key (along with the other three attributes) result in a primary key? This would be so if a given patient received only one treatment from a particular physician on a given date. However, this is not likely to be the case. For example, a patient may receive a treatment in the morning, then the same treatment again in the afternoon. To resolve this issue, we include PTreatmentDate and PTreatmentTime as part of the primary key. Therefore, the primary key of PATIENT TREATMENT consists of the five attributes shown in Figure 4-19b: PatientID, PhysicianID, TreatmentCode, PTreatmentDate, and PTreatmentTime. The only nonkey attribute in the relation is PTreatmentResults.

Although this primary key is technically correct, it is complex and therefore dif- ficult to manage and prone to errors. A better approach is to introduce a surrogate key, such as PTreatmentID, that is, a serial number that uniquely identifies each treatment. In this case, each of the former primary key attributes except for PTreatmentDate and PTreatmentTime becomes a foreign key in the PATIENT TREATMENT relation. Another similar approach is to use an enterprise key, as described at the end of this chapter.

Step 7: Map Supertype/Subtype Relationships

The relational data model does not yet directly support supertype/subtype relationships. Fortunately, there are various strategies that you can use to represent these relationships with the relational data model (Chouinard, 1989). We recommend using the following strategy, which is the one most commonly employed:

1. Create a separate relation for the supertype and for each of its subtypes. 2. Assign to the relation created for the supertype the attributes that are common to

all members of the supertype, including the primary key. 3. Assign to the relation for each subtype the primary key of the supertype and only

those attributes that are unique to that subtype. 4. Assign one (or more) attributes of the supertype to function as the subtype dis-

criminator. (The role of the subtype discriminator was discussed in Chapter 3.)

(b) Four resulting relations

PatientID

PATIENT

PatientName PhysicianID

PHYSICIAN

PhysicianName TreatmentCode

TREATMENT

TreatmentDescription

PATIENT TREATMENT

PhysicianIDPatientID PTreatmentTime PTreatmentResultsTreatmentCode PTreatmentDate

FIGURE 4-19 (continued)

M04_HOFF3359_13_GE_C04.indd 208 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 209

EMPLOYEE Employee Number Employee Name Employee Address Employee Date Hired Employee Type

SALARIED EMPLOYEE

Annual Salary Stock Option

Hourly Rate

HOURLY EMPLOYEE

CONSULTANT

Contract Number Billing Rate

Employee Type =

“H”

d

“S” “C”

FIGURE 4-20 Supertype/ subtype relationships

EmployeeNumber EmployeeName

EMPLOYEE

EmployeeAddress EmployeeDateHired EmployeeType

CEmployeeNumber

CONSULTANT

ContractNumber BillingRate

HEmployeeNumber

HOURLY_EMPLOYEE

HourlyRate

SEmployeeNumber

SALARIED_EMPLOYEE

AnnualSalary StockOption

FIGURE 4-21 Example of mapping supertype/subtype relationships to relations

An example of applying this procedure is shown in Figures 4-20 and 4-21. Figure  4-20 shows the supertype EMPLOYEE with subtypes HOURLY EMPLOYEE, SALARIED EMPLOYEE, and CONSULTANT. (This example is described in Chapter 3, and Figure 4-20 is a repeat of Figure 3-8.) The primary key of EMPLOYEE is Employee Number, and the attribute Employee Type is the subtype discriminator.

The result of mapping this diagram to relations using these rules is shown in Figure 4-21. There is one relation for the supertype (EMPLOYEE) and one for each of the three subtypes. The primary key for each of the four relations is EmployeeNum- ber. A prefix is used to distinguish the name of the primary key for each subtype. For example, SEmployeeNumber is the name for the primary key of the relation SALARIED EMPLOYEE. Each of these attributes is a foreign key that references the supertype pri- mary key, as indicated by the arrows in the diagram. Each subtype relation contains only those attributes unique to the subtype.

For each subtype, a relation can be produced that contains all of the attributes of that subtype (both specific and inherited) by using an SQL command that joins the subtype with its supertype. For example, suppose that we want to display a

M04_HOFF3359_13_GE_C04.indd 209 15/03/19 3:39 PM

210 Part II • Database Analysis and Logical Design

TABLE 4-2 Summary of EER-to-Relational Transformations

EER Structure Relational Representation (Sample Figure)

Regular entity Create a relation with primary key and nonkey attributes (Figure 4-8).

Composite attribute Each component of a composite attribute becomes a separate attribute in the target relation (Figure 4-9).

Multivalued attribute Create a separate relation for multivalued attribute with composite primary key, including the primary key of the entity (Figure 4-10).

Weak entity Create a relation with a composite primary key (which includes the primary key of the entity on which this entity depends) and nonkey attributes (Figure 4-11).

Binary or unary 1:M relationship Place the primary key of the entity on the one side of the relationship as a foreign key in the relation for the entity on the many side (Figure 4-12; Figure 4-17 for unary relationship).

Binary or unary M:N relationship or associative entity without its own key

Create a relation with a composite primary key using the primary keys of the related entities plus any nonkey attributes of the relationship or associative entity (Figure 4-13, Figure 4-15 for associative entity, Figure 4-18 for unary relationship).

Binary or unary 1:1 relationship Place the primary key of either entity in the relation for the other entity; if one side of the relationship is optional, place the foreign key of the entity on the mandatory side in the relation for the entity on the optional side (Figure 4-14).

Binary or unary M:N relationship or associative entity with its own key

Create a relation with the primary key associated with the associative entity plus any nonkey attributes of the associative entity and the primary keys of the related entities as foreign keys (Figure 4-16).

Ternary and n-ary relationships Same as binary M:N relationships above; without its own key, include as part of primary key of relation for the relationship or associative entity the primary keys from all related entities; with its own surrogate key, the primary keys of the associated entities are included as foreign keys in the relation for the relationship or associative entity (Figure 4-19).

Supertype/subtype relationship Create a relation for the superclass, which contains the primary and all nonkey attributes in common with all subclasses, plus create a separate relation for each subclass with the same primary key (with the same or local name) but with only the nonkey attributes related to that subclass (Figure 4-20 and 4-21).

table that contains all of the attributes for SALARIED EMPLOYEE. The following command is used:

SELECT * FROM Employee_T, SalariedEmployee_T WHERE EmployeeNumber = SEmployeeNumber;

Summary of EER-to-Relational Transformations

The steps provide a comprehensive explanation of how each element of an EER dia- gram is transformed into parts of a relational data model. Table 4-2 is a quick reference to these steps and the associated figures that illustrate each type of transformation.

INTRODUCTION TO NORMALIZATION

Following the steps outlined previously for transforming EER diagrams into rela- tions typically results in well-structured relations. However, there is no guarantee that all anomalies are removed by following these steps. Normalization is a formal process for deciding which attributes should be grouped together in a relation so that all anomalies are removed. For example, we used the principles of normalization to convert the EMPLOYEE2 table (with its redundancy) to EMPLOYEE1 (Figure 4-1) and EMPCOURSE (Figure 4-7). There are two major occasions during the overall database development process when you can usually benefit from using normalization:

M04_HOFF3359_13_GE_C04.indd 210 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 211

1. During logical database design (described in this chapter) You should use nor- malization concepts to verify the quality of the relations that are obtained from mapping E-R diagrams.

2. When reverse-engineering older systems Many of the tables and user views for older systems are redundant and subject to the anomalies we describe in this chapter.

So far we have presented an intuitive discussion of well-structured relations; however, we need formal definitions of such relations, together with a process for designing them. Normalization is the process of successively reducing relations with anomalies to produce smaller, well-structured relations. Following are some of the main goals of normalization:

1. Minimize data redundancy, thereby avoiding anomalies and conserving storage space.

2. Simplify the enforcement of referential integrity constraints. 3. Make it easier to maintain data (insert, update, and delete). 4. Provide a better design that is an improved representation of the real world and a

stronger basis for future growth.

Normalization makes no assumptions about how data will be used in displays, queries, or reports. Normalization, based on what we will call normal forms and func- tional dependencies, defines rules of the business, not data usage. Further, remember that data are normalized by the end of logical database design. Thus, normaliza- tion, as we will see in Chapter 8, places no constraints on how data can or should be physically stored or, therefore, on processing performance. Normalization is a logical data- modeling technique used to ensure that data are well structured from an organi- zation-wide view.

Steps in Normalization

Normalization can be accomplished and understood in stages, each of which corre- sponds to a normal form (see Figure 4-22). A normal form is a state of a relation that requires that certain rules regarding relationships between attributes (or functional dependencies) are satisfied. We describe these rules briefly in this section and illustrate them in detail in the following sections:

1. First normal form Any multivalued attributes (also called repeating groups) have been removed, so there is a single value (possibly null) at the intersection of each row and column of the table (as in Figure 4-2b).

2. Second normal form Any partial functional dependencies have been removed (i.e., nonkey attributes are identified by the whole primary key).

3. Third normal form Any transitive dependencies have been removed (i.e., non- key attributes are identified by only the primary key).

4. Boyce-Codd normal form Any remaining anomalies that result from functional dependencies have been removed (because there was more than one possible primary key for the same nonkeys).

5. Fourth normal form Any multivalued dependencies have been removed. 6. Fifth normal form Any remaining anomalies have been removed.

We describe and illustrate the first through the third normal forms in this chapter. The remaining normal forms are described in Appendix B, available on the book’s Web site. These other normal forms are in an appendix only to save space in this chapter, not because they are less important. In fact, you can easily continue with Appendix B immediately after the section on the third normal form.

Functional Dependencies and Keys

Up to the Boyce-Codd normal form, normalization is based on the analysis of functional dependencies. A functional dependency is a constraint between two attributes or two sets of attributes. For any relation R, attribute B is functionally dependent on attribute A,

Normalization

The process of decomposing relations with anomalies to produce smaller, well-structured relations.

Normal form

A state of a relation that requires that certain rules regarding relationships between attributes (or functional dependencies) are satisfied.

Functional dependency

A constraint between two attributes in which the value of one attribute is determined by the value of another attribute.

M04_HOFF3359_13_GE_C04.indd 211 15/03/19 3:39 PM

212 Part II • Database Analysis and Logical Design

if for every valid instance of A, that value of A uniquely determines the value of B (Dutka and Hanson, 1989). The functional dependency of B on A is represented by an arrow, as follows: A → B. A functional dependency is not a mathematical dependency: B cannot be computed from A. Rather, if you know the value of A, there can be only one value for B. An attribute may be functionally dependent on a combination of two (or more) attributes rather than on a single attribute. For example, consider the relation EMPCOURSE (EmpID, CourseTitle, DateCompleted) shown in Figure 4-7. We represent the functional dependency in this relation as follows:

EmpID, CourseTitle → DateCompleted

The comma between EmpID and CourseTitle stands for the logical AND opera- tor, because DateCompleted is functionally dependent on EmpID and CourseTitle in combination.

The functional dependency in this statement implies that the date when a course is completed is determined by the identity of the employee and the title of the course. Typical examples of functional dependencies are the following:

1. SSN → Name, Address, Birthdate A person’s name, address, and birth date are functionally dependent on that person’s Social Security number (in other words, there can be only one Name, one Address, and one Birthdate for each SSN).

2. VIN → Make, Model, Color The make, model, and the original color of a vehicle are functionally dependent on the vehicle identification number (as above, there can be only one value of Make, Model, and Color associated with each VIN).

3. ISBN → Title, FirstAuthorName, Publisher The title of a book, the name of the first author, and the publisher are functionally dependent on the book’s interna- tional standard book number (ISBN).

Boyce-Codd normal form

Fourth normal form

Fifth normal form

Remove multivalued

dependencies

Remove remaining anomalies

Table with multivalued attributes

First normal form

Second normal form

Third normal form

Remove multivalued attributes

Remove partial

dependencies

Remove transitive

dependencies

Remove remaining anomalies resulting

from multiple candidate keys

FIGURE 4-22 Steps in normalization

M04_HOFF3359_13_GE_C04.indd 212 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 213

DETERMINANTS The attribute on the left side of the arrow in a functional dependency is called a determinant. SSN, VIN, and ISBN are determinants in the preceding three examples. In the EMPCOURSE relation (Figure 4-7), the combination of EmpID and CourseTitle is a determinant.

CANDIDATE KEYS A candidate key is an attribute, or combination of attributes, that uniquely identifies a row in a relation. A candidate key must satisfy the following prop- erties (Dutka and Hanson, 1989), which are a subset of the six properties of a relation previously listed:

1. Unique identification For every row, the value of the key must uniquely identify that row. This property implies that each nonkey attribute is functionally depen- dent on that key.

2. Nonredundancy No attribute in the key can be deleted without destroying the property of unique identification.

It is also commonly accepted that a candidate cannot be null and a candidate key for a given relation should not change value over time. Also, a determinant must be a candi- date key.

Let’s apply the preceding definitions and properties to identify candidate keys in two of the relations described in this chapter. The EMPLOYEE1 relation (Figure 4-1) has the following schema: EMPLOYEE1(EmpID, Name, DeptName, Salary). EmpID is the only determinant in this relation. All of the other attributes are functionally dependent on EmpID. Therefore, EmpID is a candidate key and (because there are no other candi- date keys) also is the primary key.

You can see the functional dependencies for a relation using the notation shown in Figure 4-23. Figure 4-23a shows the representation for EMPLOYEE1. The horizontal line in the figure portrays the functional dependencies. A vertical line drops from the primary key (EmpID) and connects to this line. Vertical arrows then point to each of the nonkey attributes that are functionally dependent on the primary key.

For the relation EMPLOYEE2 (Figure 4-2b), notice that (unlike EMPLOYEE1) EmpID does not uniquely identify a row in the relation. For example, there are two rows in the table for EmpID number 100. There are two types of functional dependencies in this relation:

1. EmpID → Name, DeptName, Salary 2. EmpID, CourseTitle → DateCompleted

The functional dependencies indicate that the combination of EmpID and CourseTitle is the only candidate key (and therefore the primary key) for EMPLOYEE2. In other words, the primary key of EMPLOYEE2 is a composite key. Neither EmpID

Determinant

The attribute on the left side of the arrow in a functional dependency.

Candidate key

An attribute, or combination of attributes, that uniquely identifies a row in a relation.

FIGURE 4-23 Representing functional dependencies

EMPLOYEE1

EmpID Name DeptName Salary

EMPLOYEE2

EmpID Name DeptName Salary DateCompletedCourseTitle

(a) Functional dependencies in EMPLOYEE1

(b) Functional dependencies in EMPLOYEE2

M04_HOFF3359_13_GE_C04.indd 213 15/03/19 3:39 PM

214 Part II • Database Analysis and Logical Design

nor CourseTitle uniquely identifies a row in this relation and therefore (according to property 1) cannot by itself be a candidate key. Examine the data in Figure 4-2b to ver- ify that the combination of EmpID and CourseTitle does uniquely identify each row of EMPLOYEE2. You can see the functional dependencies in this relation in Figure 4-23b. Notice that DateCompleted is the only attribute that is functionally dependent on the full primary key consisting of the attributes EmpID and CourseTitle.

We can summarize the relationship between determinants and candidate keys as follows: A candidate key is always a determinant, whereas a determinant may or may not be a candidate key. For example, in EMPLOYEE2, EmpID is a determinant but not a candidate key. A candidate key is a determinant that uniquely identifies the remaining (nonkey) attributes in a relation. A determinant may be a candidate key (such as EmpID in EMPLOYEE1), part of a composite candidate key (such as EmpID in EMPLOYEE2), or a nonkey attribute. You will see examples of this shortly. You will see below that first through third normal forms adequately handle determinants and candidate keys to create well-structured relations. Appendix B illustrates one situation not covered by these normal forms, which is when a nonkey attribute determines part of a compos- ite candidate key in the same relation. This rare but certainly not uncommon situation gives rise to Boyce-Codd Normal Form (BCNF), which is briefly described in Appendix B and more fully explained in Elmasri and Navathe (2011).

As a preview to the following illustration of what normalization accomplishes, normalized relations have as their primary key the determinant for each of the nonkeys, and within that relation there are no other functional dependencies.

NORMALIZATION EXAMPLE: PINE VALLEY FURNITURE COMPANY

Now that you have examined functional dependencies and keys, we are ready to describe and illustrate the steps of normalization. If an EER data model has been trans- formed into a comprehensive set of relations for the database, then each of these rela- tions needs to be normalized. In other cases in which the logical data model is being derived from user interfaces, such as screens, forms, and reports, you will want to create relations for each user interface and normalize those relations.

For a simple illustration, consider a customer invoice from Pine Valley Furniture Company (see Figure 4-24.)

Step 0: Represent the View in Tabular Form

The first step (preliminary to normalization) is to represent the user view (in this case, an invoice) as a single table, or relation, with the attributes recorded as column headings.

Customer ID

Product ID

7 Dining Table

5 Writer’s Desk

4

2

2

1

$800.00

$325.00

$650.00

Total

$1,600.00

$650.00

$650.00

$2,900.00

Entertainment Center

Natural Ash

Cherry

Natural Maple

Product Description Finish Quantity Unit Price Extended Price

PVFC Customer Invoice

2

Customer Name Value Furniture

Order ID

Order Date

1006

10/24/2018

Address 15145 S.W. 17th St. Plano TX 75022

FIGURE 4-24 Invoice (Pine Valley Furniture Company)

M04_HOFF3359_13_GE_C04.indd 214 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 215

Sample data should be recorded in the rows of the table, including any repeating groups that are present in the data. The table representing the invoice is shown in Figure 4-25. Notice that data for a second order (OrderID 1007) are included in Figure 4-25 to clarify further the structure of this data.

Step 1: Convert to First Normal Form

A relation is in first normal form (1NF) if the following two constraints both apply:

1. There are no repeating groups in the relation (thus, there is a single fact at the intersection of each row and column of the table).

2. A primary key has been defined, which uniquely identifies each row in the relation.

REMOVE REPEATING GROUPS As you can see, the invoice data in Figure 4-25 con- tain a repeating group for each product that appears on a particular order. Thus, OrderID 1006 contains three repeating groups, corresponding to the three products on that order.

In a previous section, you saw how to remove repeating groups from a table by filling relevant data values into previously vacant cells of the table (see Figures 4-2a and 4-2b). Applying this procedure to the invoice table yields the new relation (named INVOICE) shown in Figure 4-26.

First normal form (1NF)

A relation that has a primary key and in which there are no repeating groups.

OrderID Order Customer Customer Customer ProductID Product Product Product Ordered Date ID Name Address Description Finish StandardPrice Quantity

1006 10/24/2018 2 Value Plano, TX 7 Dining Natural 800.00 2 Furniture Table Ash

5 Writer’s Cherry 325.00 2 Desk

4 Entertainment Natural 650.00 1 Center Maple

1007 10/25/2018 6 Furniture Boulder, 11 4–Dr Oak 500.00 4 Gallery CO Dresser

4 Entertainment Natural 650.00 3 Center Maple

FIGURE 4-25 INVOICE data (Pine Valley Furniture Company)

OrderID Order Customer Customer Customer ProductID Product Product Product Ordered Date ID Name Address Description Finish StandardPrice Quantity

1006 10/24/2018 Value Plano, TX Dining Natural 800.00 2 Furniture Table Ash

1006 10/24/2018 Value Plano, TX Writer’s Cherry 325.00 2 Furniture Desk

1006 10/24/2018 Value Plano, TX Entertainment Natural 650.00 1 Furniture Center Maple

1007 10/25/2018 Furniture Boulder, 4–Dr Oak 500.00 4 Gallery CO Dresser

1007 10/25/2018 6

6

2

2

2

4

11

4

5

7

Furniture Boulder, Entertainment Natural 650.00 3 Gallery CO Center Maple

FIGURE 4-26 INVOICE relation (1NF) (Pine Valley Furniture Company)

M04_HOFF3359_13_GE_C04.indd 215 15/03/19 3:39 PM

216 Part II • Database Analysis and Logical Design

SELECT THE PRIMARY KEY There are four determinants in INVOICE, and their func- tional dependencies are the following:

OrderID → OrderDate, CustomerID, CustomerName, CustomerAddress CustomerID → CustomerName, CustomerAddress ProductID → ProductDescription, ProductFinish, ProductStandardPrice OrderID, ProductID → OrderedQuantity

Why do we know these are the functional dependencies? These business rules come from the organization. You would discover these from studying the nature of the Pine Valley Fur- niture Company business. You can also see that no data in Figure 4-26 violate any of these functional dependencies. But because you don’t see all possible rows of this table, you can- not be sure that there wouldn’t be some invoice that would violate one of these functional dependencies. Thus, we must depend on our understanding of the rules of the organization.

As you can see, the only candidate key for INVOICE is the composite key consist- ing of the attributes OrderID and ProductID (because there is only one row in the table for any combination of values for these attributes). Therefore, OrderID and ProductID are underlined in Figure 4-26, indicating that they compose the primary key.

When forming a primary key, you must be careful not to include redundant (and there- fore unnecessary) attributes. Thus, although CustomerID is a determinant in INVOICE, it is not included as part of the primary key because all of the nonkey attributes are identified by the combination of OrderID and ProductID. We will see the role of CustomerID in the normalization process that follows.

A diagram that shows these functional dependencies for the INVOICE relation is shown in Figure 4-27. This diagram is a horizontal list of all the attributes in INVOICE, with the primary key attributes (OrderID and ProductID) underlined. Notice that the only attribute that depends on the full key is OrderedQuantity. All of the other functional depen- dencies are either partial dependencies or transitive dependencies (both are defined next).

ANOMALIES IN 1NF Although repeating groups have been removed, the data in Figure 4-26 still contain considerable redundancy. For example, CustomerID, Custom- erName, and CustomerAddress for Value Furniture are recorded in three rows (at least) in the table. As a result of these redundancies, manipulating the data in the table can lead to anomalies such as the following:

1. Insertion anomaly With this table structure, the company is not able to introduce a new product (say, Breakfast Table with ProductID 8) and add it to the database before it is ordered the first time: No entries can be added to the table without both ProductID and OrderID. As another example, if a customer calls and requests another product be added to his OrderID 1007, a new row must be inserted in which the order date and all of the customer information must be repeated. This leads to data replication and poten- tial data entry errors (e.g., the customer name may be entered as “Valley Furniture”).

2. Deletion anomaly If a customer calls and requests that the Dining Table be deleted from her OrderID 1006, this row must be deleted from the relation, and we lose the information concerning this item’s finish (Natural Ash) and price ($800.00).

CustomerAddressOrderID OrderDate CustomerID CustomerName

Full Dependency

Transitive Dependencies

Partial Dependencies Partial Dependencies

ProductID ProductDescription ProductFinish Product StandardPrice

OrderedQuantity

FIGURE 4-27 Functional dependency diagram for INVOICE

M04_HOFF3359_13_GE_C04.indd 216 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 217

3. Update anomaly If Pine Valley Furniture (as part of a price adjustment) increases the price of the Entertainment Center (ProductID 4) to $750.00, this change must be recorded in all rows containing that item. (There are two such rows in Figure 4-26.)

Step 2: Convert to Second Normal Form

You can remove many of the redundancies (and resulting anomalies) in the INVOICE relation by converting it to second normal form. A relation is in second normal form (2NF) if it is in first normal form and contains no partial functional dependencies. A partial functional dependency exists when a nonkey attribute is functionally depen- dent on part (but not all) of the primary key. As you can see, the following partial dependencies exist in Figure 4-27:

OrderID → OrderDate, CustomerID, CustomerName, CustomerAddress ProductID → ProductDescription, ProductFinish, ProductStandardPrice

The first of these partial dependencies, for example, states that the date on an order is uniquely determined by the order number and has nothing to do with the ProductID.

To convert a relation with partial dependencies to second normal form, the follow- ing steps are required:

1. Create a new relation for each primary key attribute (or combination of attributes) that is a determinant in a partial dependency. That attribute is the primary key in the new relation.

2. Move the nonkey attributes that are only dependent on this primary key attribute (or attributes) from the old relation to the new relation.

The results of performing these steps for the INVOICE relation are shown in Figure 4-28. Removal of the partial dependencies results in the formation of two new relations: PROD- UCT and CUSTOMER ORDER. The INVOICE relation is now left with just the primary key attributes (OrderID and ProductID) and OrderedQuantity, which is functionally dependent on the whole key. We rename this relation ORDER LINE because each row in this table represents one line item on an order.

As indicated in Figure 4-28, the relations ORDER LINE and PRODUCT are in third normal form. However, CUSTOMER ORDER contains transitive dependencies and therefore (although in second normal form) is not yet in third normal form.

A relation that is in first normal form will be in second normal form if any one of the following conditions applies:

1. The primary key consists of only one attribute (e.g., the attribute ProductID in the PRODUCT relation in Figure 4-28). By definition, there cannot be a partial depen- dency in such a relation.

Second normal form (2NF)

A relation in first normal form in which every nonkey attribute is fully functionally dependent on the primary key.

Partial functional dependency

A functional dependency in which one or more nonkey attributes are functionally dependent on part (but not all) of the primary key.

OrderID

Transitive Dependencies

ProductID OrderedQuantity ORDER LINE (3NF)

ProductID ProductDescription ProductFinish Product

StandardPrice PRODUCT (3NF)

OrderID OrderDate CustomerID CustomerName CustomerAddress CUSTOMER ORDER (2NF)

FIGURE 4-28 Removing partial dependencies

M04_HOFF3359_13_GE_C04.indd 217 15/03/19 3:39 PM

218 Part II • Database Analysis and Logical Design

2. No nonkey attributes exist in the relation (thus, all of the attributes in the relation are components of the primary key). There are no functional dependencies in such a relation.

3. Every nonkey attribute is functionally dependent on the full set of primary key attributes (e.g., the attribute OrderedQuantity in the ORDER LINE relation in Figure 4-28).

Step 3: Convert to Third Normal Form

A relation is in third normal form (3NF) if it is in second normal form and no transitive dependencies exist. A transitive dependency in a relation is a functional dependency between the primary key and one or more nonkey attributes that are dependent on the primary key via another nonkey attribute. For example, there are two transitive depen- dencies in the CUSTOMER ORDER relation shown in Figure 4-28:

OrderID → CustomerID → CustomerName OrderID → CustomerID → CustomerAddress

In other words, both customer name and address are uniquely identified by CustomerID, but CustomerID is not part of the primary key (as we noted earlier).

Transitive dependencies create unnecessary redundancy that may lead to the type of anomalies discussed earlier. For example, the transitive dependency in CUSTOMER ORDER (Figure 4-28) requires that a customer ’s name and address be reentered every time a customer submits a new order, regardless of how many times they have been entered previously. You have no doubt experienced this type of annoying requirement when ordering merchandise online, visiting a doctor ’s office, or any number of similar activities.

REMOVING TRANSITIVE DEPENDENCIES You can easily remove transitive dependencies from a relation by means of a three-step procedure:

1. For each nonkey attribute (or set of attributes) that is a determinant in a relation, create a new relation. That attribute (or set of attributes) becomes the primary key of the new relation.

2. Move all of the attributes that are functionally dependent only on the primary key of the new relation from the old to the new relation.

3. Leave the attribute that serves as a primary key in the new relation in the old rela- tion to serve as a foreign key that allows you to associate the two relations.

The results of applying these steps to the relation CUSTOMER ORDER are shown in Figure 4-29. A new relation named CUSTOMER has been created to receive the com- ponents of the transitive dependency. The determinant CustomerID becomes the pri- mary key of this relation, and the attributes CustomerName and CustomerAddress are moved to the relation. CUSTOMER ORDER is renamed ORDER, and the attribute CustomerID remains as a foreign key in that relation. This allows us to associate an order with the customer who submitted the order. As indicated in Figure 4-29, these relations are now in third normal form.

Normalizing the data in the INVOICE view has resulted in the creation of four relations in third normal form: CUSTOMER, PRODUCT, ORDER, and ORDER LINE.

Third normal form (3NF)

A relation that is in second normal form and has no transitive dependencies.

Transitive dependency

A functional dependency between the primary key and one or more nonkey attributes that are dependent on the primary key via another nonkey attribute.

OrderID OrderDate CustomerID ORDER (3NF)

CustomerID CustomerName CustomerAddress CUSTOMER (3NF)

FIGURE 4-29 Removing transitive dependencies

M04_HOFF3359_13_GE_C04.indd 218 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 219

A relational schema showing these four relations and their associations (developed using Microsoft Visio) is shown in Figure 4-30. Note that CustomerID is a foreign key in ORDER, and OrderID and ProductID are foreign keys in ORDER LINE. (Foreign keys are shown in Visio for logical, but not conceptual, data models.) Also note that mini- mum cardinalities are shown on the relationships even though the normalized relations provide no evidence of what the minimum cardinalities should be. Sample data for the relations might include, for example, a customer with no orders, thus providing evidence of the optional cardinality for the relationship Places. However, even if there were an order for every customer in a sample data set, this would not prove manda- tory cardinality. Minimum cardinalities must be determined from business rules, not illustrations of reports, screens, and transactions. The same statement is true for spe- cific maximum cardinalities (e.g., a business rule that no order may contain more than 100 line items).

Determinants and Normalization

You have seen normalization through 3NF in steps. There is an easy shortcut, however. If you look back at the original set of four determinants and the associated functional dependencies for the invoice user view, each of these corresponds to one of the relations in Figure 4-30. Each determinant is the primary key of a relation, and the nonkeys of each relation are those attributes that are functionally dependent on each determinant. There is a subtle but important difference: Because OrderID determines CustomerID, CustomerName, and CustomerAddress and CustomerID determines its dependent attributes, CustomerID becomes a foreign key in the ORDER relation, which is where CustomerName and CustomerAddress are represented. If you can determine determi- nants that have no overlapping dependent attributes, then you have defined the rela- tions. Thus, you can do normalization step by step as illustrated for the Pine Valley Furniture invoice, or you can create relations in 3NF straight from determinants’ func- tional dependencies.

Step 4: Further Normalization

After completing Steps 0 through 3, all nonkeys will be dependent on the primary key, the whole primary key, and nothing but the primary key (“so help you Codd!”). Actually, normal forms are rules about functional dependencies and, hence, are the result of finding determinants and their associated nonkeys. The steps we outlined above are an aid in creating a relation for each determinant and its associated nonkeys.

You will recall from the beginning of our discussion of normalization that we identified additional normal forms beyond 3NF. The most commonly enforced of these additional normal forms are explained in Appendix B (available on the book’s Web site), which you might want to read or scan now.

Customer IDPK

Customer Name Customer Address

CUSTOMER

Order IDPK

FK1 Order Date Customer ID

ORDER Places

Product IDPK

Product Description Product Finish Product Standard Price

PRODUCT

Order ID Product ID

PK,FK1 PK,FK2

Ordered Quantity

ORDER LINE Is Ordered

Includes

FIGURE 4-30 Relational schema for INVOICE data (Microsoft Visio notation)

M04_HOFF3359_13_GE_C04.indd 219 15/03/19 3:39 PM

220 Part II • Database Analysis and Logical Design

MERGING RELATIONS

In a previous section, we described how to transform EER diagrams into relations. This transformation occurs when you take the results of a top-down analysis of data requirements and begin to structure them for implementation in a database. You then saw how to check the resulting relations to determine whether they are in third (or higher) normal form and perform normalization steps if necessary.

As part of the logical design process, normalized relations may have been cre- ated from a number of separate EER diagrams and (possibly) other user views (i.e., there may be bottom-up or parallel database development activities for different areas of the organization as well as top-down ones). For example, besides the invoice used in the prior section to illustrate normalization, there may be an order form, an account balance report, production routing, and other user views, each of which has been nor- malized separately. The three-schema architecture for databases (see Chapter 1) encour- ages the simultaneous use of both top-down and bottom-up database development processes. In reality, most medium-to-large organizations have many reasonably inde- pendent systems development activities that at some point may need to come together to create a shared database. The result is that some of the relations generated from these various processes may be redundant; that is, they may refer to the same entities. In such cases, we should merge those relations to remove the redundancy. This section describes merging relations (also called view integration). An understanding of how to merge relations is important for three reasons:

1. On large projects, the work of several subteams comes together during logical design, so there is often a need to merge relations.

2. Integrating existing databases with new information requirements often leads to the need to integrate different views.

3. New data requirements may arise during the life cycle, so there is a need to merge any new relations with what has already been developed.

An Example

Suppose that modeling a user view results in the following 3NF relation:

EMPLOYEE1(EmployeeID, Name, Address, Phone)

Modeling a second user view might result in the following relation:

EMPLOYEE2(EmployeeID, Name, Address, Jobcode, NoYears)

Because these two relations have the same primary key (EmployeeID), they likely describe the same entity and may be merged into one relation. The result of merging the relations is the following relation:

EMPLOYEE(EmployeeID, Name, Address, Phone, Jobcode, NoYears)

Notice that an attribute that appears in both relations (e.g., Name in this example) appears only once in the merged relation.

View Integration Problems

When integrating relations as in the preceding example, you must understand the meaning of the data and must be prepared to resolve any problems that may arise in that process. In this section, we describe and briefly illustrate four problems that arise in view integration: synonyms, homonyms, transitive dependencies, and supertype/subtype relationships.

M04_HOFF3359_13_GE_C04.indd 220 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 221

SYNONYMS In some situations, two (or more) attributes may have different names but the same meaning (e.g., when they describe the same characteristic of an entity). Such attributes are called synonyms. For example, EmployeeID and EmployeeNo may be synonyms. When merging the relations that contain synonyms, you should obtain agreement (if possible) from users on a single, standardized name for the attribute and eliminate any other synonyms. (Another alternative is to choose a third name to replace the synonyms.) For example, consider the following relations:

STUDENT1(StudentID, Name) STUDENT2(MatriculationNo, Name, Address)

In this case, you recognize that both StudentID and MatriculationNo are synonyms for a person’s student identity number and are identical attributes. (Another possibility is that these are both candidate keys, and only one of them should be selected as the primary key.) One possible resolution would be to standardize on one of the two attri- bute names, such as StudentID. Another option is to use a new attribute name, such as StudentNo, to replace both synonyms. Assuming the latter approach, merging the two relations would produce the following result:

STUDENT(StudentNo, Name, Address)

Often when there are synonyms, there is a need to allow some database users to refer to the same data by different names. Users may need to use familiar names that are consistent with terminology in their part of the organization. An alias is an alternative name used for an attribute. Many database management systems allow the definition of an alias that may be used interchangeably with the primary attri- bute label.

HOMONYMS An attribute name that may have more than one meaning is called a homonym. For example, the term account might refer to a bank’s checking account, savings account, loan account, or other type of account (and therefore account refers to different data, depending on how it is used).

You should be on the lookout for homonyms when merging relations. Consider the following example:

STUDENT1(StudentID, Name, Address) STUDENT2(StudentID, Name, PhoneNo, Address)

In discussions with users, you may discover that the attribute Address in STUDENT1 refers to a student’s campus address, whereas in STUDENT2 the same attribute refers to a student’s permanent (or home) address. To resolve this conflict, we would probably need to create new attribute names, so the merged relation would become

STUDENT(StudentID, Name, PhoneNo, CampusAddress, PermanentAddress)

TRANSITIVE DEPENDENCIES When two 3NF relations are merged to form a single relation, transitive dependencies (described earlier in this chapter) may result. For example, consider the following two relations:

STUDENT1(StudentID, MajorName) STUDENT2(StudentID, Advisor)

Synonyms

Two (or more) attributes that have different names but the same meaning.

Alias

An alternative name used for an attribute.

Homonym

An attribute that may have more than one meaning.

M04_HOFF3359_13_GE_C04.indd 221 15/03/19 3:39 PM

222 Part II • Database Analysis and Logical Design

Because STUDENT1 and STUDENT2 have the same primary key, the two rela- tions can be merged:

STUDENT(StudentID, MajorName, Advisor)

However, suppose that each major has exactly one advisor. In this case, Advisor is functionally dependent on MajorName:

MajorName → Advisor

If the preceding functional dependency exists, then STUDENT is in 2NF but not in 3NF because it contains a transitive dependency. You can create 3NF relations by removing the transitive dependency. Major Name becomes a foreign key in STUDENT:

STUDENT(StudentID, MajorName) MAJOR (MajorName, Advisor)

SUPERTYPE/SUBTYPE RELATIONSHIPS These relationships may be hidden in user views or relations. Suppose that we have the following two hospital relations:

PATIENT1(PatientID, Name, Address) PATIENT2(PatientID, RoomNo)

Initially, it appears that these two relations can be merged into a single PATIENT relation. However, the analyst correctly suspects that there are two different types of patients: resident patients and outpatients. PATIENT1 actually contains attributes com- mon to all patients. PATIENT2 contains an attribute (RoomNo) that is a characteristic only of resident patients. In this situation, the analyst should create supertype/subtype relationships for these entities:

PATIENT(PatientID, Name, Address) RESIDENTPATIENT(PatientID, RoomNo) OUTPATIENT(PatientID, DateTreated)

We have created the OUTPATIENT relation to show what it might look like if it were needed, but it is not necessary given only PATIENT1 and PATIENT2 user views. For an extended discussion of view integration in database design, see Navathe et al. (1986).

A FINAL STEP FOR DEFINING RELATIONAL KEYS

In Chapter 2, you studied some criteria for selecting identifiers: They do not change values over time and must be unique and known, are nonintelligent, and use a single attribute surrogate for composite identifier. Actually, none of these criteria must apply until the database is implemented (i.e., when the identifier becomes a primary key and is defined as a field in the physical database). Before the relations are defined as tables, the primary keys of relations should, if necessary, be changed to conform to these criteria.

Database experts (e.g., Johnston, 2000) have strengthened the criteria for primary key specification. Experts now also recommend that a primary key be unique across the whole database (a so-called enterprise key), not just unique within the relational table to which it applies. This criterion makes a primary key more like what in object-oriented databases is called an object identifier (see online Chapter 14). With this recommenda- tion, the primary key of a relation becomes a value internal to the database system and has no business meaning.

Enterprise key

A primary key whose value is unique across all relations.

M04_HOFF3359_13_GE_C04.indd 222 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 223

A candidate primary key, such as EmpID in the EMPLOYEE1 relation of Figure 4-1 or CustomerID in the CUSTOMER relation (Figure 4-29), if ever used in the organiza- tion, is called a business key or natural key and would be included in the relation as a nonkey attribute. The EMPLOYEE1 and CUSTOMER relations (and every other relation in the database) then have a new enterprise key attribute (called, say, ObjectID), which has no business meaning.

Why create this extra attribute? One of the main motivations for using an enter- prise key is database evolvability—merging new relations into a database after the database is created. For example, consider the following two relations:

EMPLOYEE(EmpID, EmpName, DeptName, Salary) CUSTOMER(CustID, CustName, Address)

In this example, without an enterprise key, EmpID and CustID may or may not have the same format, length, and data type, whether they are intelligent or nonintel- ligent. Suppose the organization evolves its information processing needs and recog- nizes that employees can also be customers, so employee and customer are simply two subtypes of the same PERSON supertype. (You saw this in Chapter 3, when study- ing universal data modeling.) Thus, the organization would then like to have three relations:

PERSON(PersonID, PersonName) EMPLOYEE(PersonID, DeptName, Salary) CUSTOMER(PersonID, Address)

In this case, PersonID is supposed to be the same value for the same person throughout all roles. But if values for EmpID and CustID were selected before rela- tion PERSON was created, the values for EmpID and CustID probably will not match. Moreover, if we change the values of EmpID and CustID to match the new PersonID, how do we ensure that all EmpIDs and CustIDs are unique if another employee or cus- tomer already has the associated PersonID value? Even worse, if there are other tables that relate to, say, EMPLOYEE, then foreign keys in these other tables have to change, creating a ripple effect of foreign key changes. The only way to guarantee that each primary key of a relation is unique across the database is to create an enterprise key from the very beginning so primary keys never have to change.

In our example, the original database (without PERSON) with an enterprise key is shown in Figures 4-31a (the relations) and 4-31b (sample data). In this figure, EmpID and CustID are now business keys, and OBJECT is the supertype of all other relations. OBJECT can have attributes such as the name of the type of object (included in this example as attribute ObjectType), date created, date last changed, or any other internal system attributes for an object instance. Then, when PERSON is needed, the database evolves to the design shown in Figures 4-31c (the relations) and 4-31d (sample data). Evolution to the database with PERSON still requires some alterations to existing tables but not to primary key values. The name attribute is moved to PERSON because it is common to both subtypes, and a foreign key is added to EMPLOYEE and CUSTOMER to point to the common person instance. As you will see in Chapter 5, it is easy to add and delete nonkey columns, even foreign keys, to table definitions. In contrast, chang- ing the primary key of a relation is not allowed by most database management systems because of the extensive cost of the foreign key ripple effects.

OBJECT (OID, ObjectType) EMPLOYEE (OID, EmpID, EmpName, DeptName, Salary) CUSTOMER (OID, CustID, CustName, Address)

FIGURE 4-31 Enterprise key

(a) Relations with enterprise key

M04_HOFF3359_13_GE_C04.indd 223 15/03/19 3:39 PM

224 Part II • Database Analysis and Logical Design

1

2

3

4

5

6

7

OID

OBJECT

ObjectType

EMPLOYEE

CUSTOMER

CUSTOMER

EMPLOYEE

EMPLOYEE

CUSTOMER

CUSTOMER

1

4

5

OID

EMPLOYEE

EmpID

100

101

102

EmpName

Jennings, Fred

Hopkins, Dan

Huber, Ike

DeptName

Marketing

Purchasing

Accounting

Salary

50000

45000

45000

2

3

6

7

OID

CUSTOMER

CustID

100

101

102

103

CustName

Fred’s Warehouse

Bargain Bonanza

Jasper’s

Desks ’R Us

Address

Greensboro, NC

Moscow, ID

Tallahassee, FL

Kettering, OH

OBJECT (OID, ObjectType) EMPLOYEE (OID, EmpID, DeptName, Salary, PersonID) CUSTOMER (OID, CustID, Address, PersonID) PERSON (OID, Name)

8

9

10

11

12

13

14

OID

PERSON

Name

Jennings, Fred

Fred’s Warehouse

Bargain Bonanza

Hopkins, Dan

Huber, Ike

Jasper’s

Desks ‘R Us

1

2

3

4

5

6

7

8

9

10

11

12

13

14

OID

OBJECT

ObjectType

EMPLOYEE

CUSTOMER

CUSTOMER

EMPLOYEE

EMPLOYEE

CUSTOMER

CUSTOMER

PERSON

PERSON

PERSON

PERSON

PERSON

PERSON

PERSON

1

4

5

OID

EMPLOYEE

EmpID

100

101

102

DeptName

Marketing

Purchasing

Accounting

Salary

50000

45000

45000

PersonID

8

11

12

2

3

6

7

OID

CUSTOMER

CustID

100

101

102

103

PersonID

9

10

13

14

Address

Greensboro, NC

Moscow, ID

Tallahassee, FL

Kettering, OH

(b) Sample data with enterprise key

FIGURE 4-31 (continued)

(c) Relations after adding PERSON relation

(d) Sample data after adding the PERSON relation

M04_HOFF3359_13_GE_C04.indd 224 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 225

Summary Logical database design is the process of transforming the conceptual data model into a logical data model. The emphasis in this chapter has been on the relational data model because of its importance in contemporary database systems. The relational data model repre- sents data in the form of tables called relations. A relation is a named, two-dimensional table of data. A key prop- erty of relations is that they cannot contain multivalued attributes.

In this chapter, you learned the major steps in the logical database design process. This process is based on transforming EER diagrams into normalized relations. This process has three steps: Transform EER diagrams into relations, normalize the relations, and merge the relations. The result of this process is a set of relations in third normal form that can be implemented using any contemporary relational database management system.

Each entity type in the EER diagram is transformed into a relation that has the same primary key as the entity type. A one-to-many relationship is represented by add- ing a foreign key to the relation that represents the entity on the many side of the relationship. (This foreign key is the primary key of the entity on the one side of the rela- tionship.) A many-to-many relationship is represented by creating a separate relation. The primary key of this rela- tion is a composite key, consisting of the primary key of each of the entities that participate in the relationship.

The relational model does not directly support supertype/subtype relationships, but we can model these relationships by creating a separate table (or relation) for

the supertype and for each subtype. The primary key of each subtype is the same (or at least from the same domain) as for the supertype. The supertype must have an attribute called the subtype discriminator that indi- cates to which subtype (or subtypes) each instance of the supertype belongs.

The purpose of normalization is to derive well- structured relations that are free of anomalies (incon- sistencies or errors) that would otherwise result when the relations are updated or modified. Normalization is based on the analysis of functional dependencies, which are constraints between two attributes (or two sets of attributes). It may be accomplished in several stages. Relations in first normal form (1NF) contain no multival- ued attributes or repeating groups. Relations in second normal form (2NF) contain no partial dependencies, and relations in third normal form (3NF) contain no transitive dependencies. You can use diagrams that show the func- tional dependencies in a relation to help decompose that relation (if necessary) to obtain relations in 3NF. Higher normal forms (beyond 3NF) have also been defined; we discuss these normal forms in Appendix B, available on the book’s Web site.

You learned to be careful when combining relations to deal with problems such as synonyms, homonyms, transitive dependencies, and supertype/subtype rela- tionships. In addition, before relations are defined to the database management system, all primary keys should be described as single-attribute nonintelligent keys and, preferably, as enterprise keys.

Key Terms

Alias 221 Anomaly 196 Candidate key 213 Composite key 189 Determinant 213 Enterprise key 222 Entity integrity rule 194 First normal form

(1NF) 215

Foreign key 190 Functional

dependency 211 Homonym 221 Normal form 211 Normalization 211 Null 194 Partial functional

dependency 217

Primary key 189 Recursive foreign key 205 Referential integrity

constraint 194 Relation 189 Second normal form

(2NF) 217 Surrogate primary

key 200

Synonyms 221 Third normal form

(3NF) 218 Transitive

dependency 218 Well-structured

relation 196

Chapter Review

Review Questions 4-1. Define each of the following terms:

a. determinant b. functional dependency c. transitive dependency d. recursive foreign key e. normalization

f. composite key g. candidate key h. normal form i. partial functional dependency j. enterprise key k. surrogate primary key

M04_HOFF3359_13_GE_C04.indd 225 15/03/19 3:39 PM

226 Part II • Database Analysis and Logical Design

4-2. Match the following terms to the appropriate definitions:            well-structured

relation            anomaly            functional

dependency            determinant            composite key            1NF            2NF            3NF            recursive

foreign key            relation            transitive

dependency

a. constraint between two attributes

b. functional dependency between the primary key and a nonkey attribute via another nonkey attribute

c. references the primary key in the same relation

d. multivalued attributes removed e. inconsistency or error f. contains little redundancy g. contains two (or more) attributes h. contains no partial functional

dependencies i. transitive dependencies

eliminated j. attribute on left side of functional

dependency k. named two-dimensional table

of data

4-3. Contrast the following terms: a. normal form; normalization b. candidate key; primary key c. partial dependency; transitive dependency d. composite key; recursive foreign key e. determinant; candidate key f. foreign key; primary key g. natural primary key; surrogate primary key h. enterprise key; surrogate key

4-4. Describe the primary differences between the conceptual and logical data models.

4-5. List the three components of a relational data model. 4-6. What is a schema? Discuss two common methods of

expressing a schema. 4-7. Describe three types of anomalies that can arise in a table

and the negative consequences of each. 4-8. Demonstrate each of the anomaly types with an example. 4-9. Briefly outline the seven steps of transforming an EER

diagram into the associated relations. 4-10. List four reasons why an instance of a relational schema

should be created with sample data.

4-11. Does normalization place any constraint on the storage of data in physical form or on its processing performance? Explain.

4-12. Describe how the following components of an E-R diagram are transformed into relations: a. regular entity type b. relationship (1:M) c. relationship (M:N) d. relationship (supertype/subtype) e. multivalued attribute f. weak entity g. composite attribute

4-13. What do you understand by domain constraint? 4-14. Outline a shortcut to describe relations in 3NF. 4-15. Discuss how transitive dependencies in a relation can be

removed when it leads to anomalies. 4-16. List the three steps to remove transitive dependencies. 4-17. Explain how each of the following types of integrity

constraints is enforced in the SQL CREATE TABLE commands: a. entity integrity b. referential integrity

4-18. What are the benefits of enforcing the integrity constraints as part of the database design and implementation pro- cess (instead of doing it in application design)?

4-19. How do you represent a 1:M unary relationship in a rela- tional data model?

4-20. Suggest four steps to represent super/subtype relation- ships.

4-21. In the context of unary relationships, what is a recursive foreign key?

4-22. What are the properties that a candidate key must satisfy?

4-23. Under what conditions must a foreign key not be null? 4-24. What is an enterprise key, and why is it important? 4-25. Describe the difference between how a 1:M unary relation-

ship and an M:N unary relationship are implemented in a relational data model.

4-26. Why is the natural key preserved whenever a surrogate key is created?

4-27. What are the benefits of the use of an enterprise key?

Problems and Exercises 4-28. For each of the following E-R diagrams from Chapter 2:

I. Transform the diagram to a relational schema that shows referential integrity constraints (see Figure 4-5 for an example of such a schema).

II. For each relation, diagram the functional dependen- cies (see Figure 4-23 for an example).

III. If any of the relations are not in 3NF, transform them to 3NF. a. Figure 2-8 b. Figure 2-9b c. Figure 2-11a d. Figure 2-11b

e. Figure 2-15a (relationship version) f. Figure 2-15b (attribute version) g. Figure 2-16b h. Figure 2-19

4-29. For each of the following EER diagrams from Chapter 3: I. Transform the diagram into a relational schema that

shows referential integrity constraints (see Figure 4-5 for an example of such a schema).

II. For each relation, diagram the functional dependen- cies (see Figure 4-23 for an example).

III. If any of the relations are not in 3NF, transform them to 3NF.

M04_HOFF3359_13_GE_C04.indd 226 10/04/19 2:40 PM

4 • Logical Database Design and the Relational Model 227

a. Figure 3-6b b. Figure 3-7a c. Figure 3-9 d. Figure 3-10 e. Figure 3-11

4-30. For each of the following relations, indicate the normal form for that relation. If the relation is not in third normal form, decompose it into 3NF relations. Functional depen- dencies (other than those implied by the primary key) are shown where appropriate. a. EMPLOYEE(EmployeeNo, ProjectNo) b. EMPLOYEE(EmployeeNo, ProjectNo, Location) c. EMPLOYEE(EmployeeNo, ProjectNo, Location,

Allowance) [FD: Location → Allowance] d. EMPLOYEE(EmployeeNo, ProjectNo, Duration,

Location, Allowance) [FD: Location → Allowance; FD: ProjectNo → Duration]

4-31. For your answers to the following Problems and Exercises from prior chapters, transform the EER diagrams into a set of relational schemas, diagram the functional depen- dencies, and convert all the relations to third normal form: a. Chapter 2, Problem and Exercise 2-39b b. Chapter 2, Problem and Exercise 2-39g c. Chapter 2, Problem and Exercise 2-39h d. Chapter 2, Problem and Exercise 2-39i e. Chapter 2, Problem and Exercise 2-42 f. Chapter 2, Problem and Exercise 2-46

4-32. Figure 4-32 shows a class list for Millennium College. Convert this user view to a set of 3NF relations using an enterprise key. Assume the following:

• An instructor has a unique location.

• A student has a unique major. • A course has a unique title.

4-33. Figure 4-33 shows an EER diagram for a simplified credit card environment. There are two types of card accounts: debit cards and credit cards. Credit card accounts accumu- late charges with merchants. Each charge is identified by the date and time of the charge as well as the primary keys of merchant and credit card. a. Develop a relational schema. b. Show the functional dependencies. c. Develop a set of 3NF relations using an enterprise key.

MILLENNIUM COLLEGE CLASS LIST FALL SEMESTER 2018

COURSE NO.: IS 460 COURSE TITLE: DATABASE INSTRUCTOR NAME: NORMAL. FORM INSTRUCTOR LOCATION: B 104

STUDENT NO. STUDENT NAME MAJOR GRADE

38214 Bright IS A 40875 Cortez CS B 51893 Edwards IS A

FIGURE 4-32 Class list (Millennium College)

Holds

Card Type =

“D” “C”

CARD ACCOUNT Account ID Exp Date Card Type

CUSTOMER Customer ID Cust Name Cust Address

MERCHANT Merch ID Merch Addr

d

CHARGES Charge Date Charge Time Amount

Bank No DEBIT CARD CREDIT CARD

Cur Bal

FIGURE 4-33 EER diagram for bank cards

M04_HOFF3359_13_GE_C04.indd 227 15/03/19 3:39 PM

228 Part II • Database Analysis and Logical Design

4-34. Table 4-3 contains sample data for parts and for vendors who supply those parts. In discussing these data with users, we find that part numbers (but not descriptions) uniquely identify parts and that vendor names uniquely identify vendors. a. Convert this table to a relation (named PART SUP-

PLIER) in first normal form. Illustrate the relation with the sample data in the table.

b. List the functional dependencies in PART SUPPLIER and identify a candidate key.

c. For the relation PART SUPPLIER, identify each of the following: an insert anomaly, a delete anomaly, and a modification anomaly.

d. Draw a relational schema for PART SUPPLIER and show the functional dependencies.

e. In what normal form is this relation? f. Develop a set of 3NF relations from PART SUPPLIER. g. Show the 3NF relations using Microsoft Visio (or any

other tool specified by your instructor). 4-35. Figure 4-34 shows an EER diagram for a restaurant, its

tables, and the waiters and waiting staff managers who work at the restaurant. Your assignment is to: a. Develop a relational schema. b. Show the functional dependencies. c. Develop a set of 3NF relations using an enterprise key.

4-36. Table 4-4 shows a relation called GRADE REPORT for a university. Your assignment is as follows: a. Draw a relational schema and diagram the functional

dependencies in the relation. b. In what normal form is this relation? c. Decompose GRADE REPORT into a set of 3NF rela-

tions. d. Draw a relational schema for your 3NF relations and

show the referential integrity constraints. e. Draw your answer to part d using Microsoft Visio (or

any other tool specified by your instructor). 4-37. Table 4-5 shows a shipping manifest. Your assignment is

as follows: a. Draw a relational schema and diagram the functional

dependencies in the relation. b. In what normal form is this relation? c. Decompose MANIFEST into a set of 3NF relations. d. Draw a relational schema for your 3NF relations and

show the referential integrity constraints. e. Draw your answer to part d using Microsoft Visio (or

any other tool specified by your instructor). 4-38. Transform the relational schema developed in Problem

and Exercise 4-37 into an EER diagram. State any assump- tions that you have made.

TABLE 4-3 Sample Data for Parts and Vendors

Part No Description Vendor Name Address Unit Cost

1234 Logic chip Fast Chips Cupertino 10.00

Smart Chips Phoenix 8.00

5678 Memory chip Fast Chips Cupertino 3.00

Quality Chips Austin 2.00

Smart Chips Phoenix 5.00

RTABLE RTable Nbr RTable Nbr of Seats RTable Rating

ASSIGNMENT

Start TimeDate End TimeDate Tips Earned

EMPLOYEE Employee ID Emp Lname Emp Fname

MANAGER

Monthly Salary

WAITER

Hourly Wage {Specialty}

d

SEATING

Seating ID Nbr of Guests Start TimeDate End TimeDate

Manages

Uses

Manages

FIGURE 4-34 EER diagram for a restaurant

M04_HOFF3359_13_GE_C04.indd 228 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 229

TABLE 4-4 Grade Report Relation

Grade Report

StudentID StudentName CampusAddress Major CourseID CourseTitle Instructor Name

Instructor Location Grade

168300458 Williams 208 Brooks IS IS 350 Database Mgt Codd B 104 A

168300458 Williams 208 Brooks IS IS 465 Systems Analysis Parsons B 317 B

543291073 Baker 104 Phillips Acctg IS 350 Database Mgt Codd B 104 C

543291073 Baker 104 Phillips Acctg Acct 201 Fund Acctg Miller H 310 B

543291073 Baker 104 Phillips Acctg Mkgt 300 Intro Mktg Bennett B 212 A

TABLE 4-5 Shipping Manifest

Shipment ID: 00-0001 Shipment Date: 01/10/2018

Origin: Boston Expected Arrival: 01/14/2018

Destination: Brazil

Ship Number: 39 Captain: 002-15

Henry Moore

Item Number Type Description Weight Quantity TOTALWEIGHT

3223 BM Concrete 500 100 50,000

Form

3297 BM Steel 87 2,000 174,000

Beam

Shipment Total: 224,000

4-39. For your answers to the following Problems and Exercises from prior chapters, transform the EER diagrams into a set of relational schemas, diagram the functional depen- dencies, and convert all the relations to third normal form. a. Chapter 3, Problem and Exercise 3-30 b. Chapter 3, Problem and Exercise 3-32 c. Chapter 3, Problem and Exercise 3-37

4-40. Transform Figure 2-15a, attribute version, to 3NF relations. Transform Figure 2-15b, relationship version, to 3NF rela- tions. Compare these two sets of 3NF relations with those in Figure 4-10. What observations and conclusions do you reach by comparing these different sets of 3NF relations?

4-41. The Public Safety office at Millennium College maintains a list of parking tickets issued to vehicles parked illegally on the campus. Table 4-6 shows a portion of this list for the fall semester. (Attribute names are abbreviated to con- serve space.)

a. Convert this table to a relation in first normal form by entering appropriate data in the table. What are the determinants in this relation?

b. Draw a dependency diagram that shows all functional dependencies in the relation, based on the sample data shown.

c. Give an example of one or more anomalies that can result in using this relation.

d. Develop a set of relations in third normal form. Include a new column with the heading Violation in the appro- priate table to explain the reason for each ticket. Val- ues in this column are: expired parking meter (ticket code  1), no parking permit (ticket code 2), and handi- cap violation (ticket code 3).

e. Develop an E-R diagram with the appropriate cardinal- ity notations.

TABLE 4-6 Parking Tickets at Millennium College

Parking Ticket Table

St ID L Name F Name Phone No St Lic Lic No Ticket # Date Code Fine

38249 Brown Thomas 111-7804 FL BRY 123 15634 10/17/2018 2 $25

16017 11/13/2018 1 $15

82453 Green Sally 391-1689 AL TRE 141 14987 10/05/2018 3 $100

16293 11/18/2018 1 $15

17892 12/13/2018 2 $25

M04_HOFF3359_13_GE_C04.indd 229 15/03/19 3:39 PM

230 Part II • Database Analysis and Logical Design

4-42. The materials manager at Pine Valley Furniture Com- pany maintains a list of suppliers for each of the material items purchased by the company from outside vendors. Table  4-7 shows the essential data required for this appli- cation. a. Draw a dependency diagram for this data. You may

assume the following: • Each material item has one or more suppliers. Each

supplier may supply one or more items or may not supply any items.

• The unit price for a material item may vary from one vendor to another.

• The terms code for a supplier uniquely identifies the terms of the sale (e.g., code 2 means 10 percent net

30 days). The terms for a supplier are the same for all material items ordered from that supplier.

b. Decompose this diagram into a set of diagrams in 3NF. c. Draw an E-R diagram for this situation.

4-43. Table  4-8 shows extracts from a customer’s flight booking confirmation. The booking is identified by the booking ref- erence, which in turn identifies the customer id, their flight origin, and final destination. This booking reference also states the number of air miles eligible, which can also be calculated from the origin and destination. a. Develop a diagram that shows the functional depen-

dencies in the BOOKING relation. b. Convert BOOKING to third normal form if necessary.

Show the resulting table(s) with the sample data pre- sented in BOOKING.

4-44. Figure 4-35 shows an EER diagram for Vacation Property Rentals. This organization rents preferred properties in sev- eral states. As shown in the figure, there are two basic types of properties: beach properties and mountain properties. a. Transform the EER diagram to a set of relations and

develop a relational schema. b. Diagram the functional dependencies and determine

the normal form for each relation. c. Convert all relations to third normal form, if necessary,

and draw a revised relational schema. d. Suggest an integrity constraint that would ensure that no

property is rented twice during the same time interval. 4-45. For your answers to Problem and Exercise 3-33 from

Chapter 3, transform the EER diagrams into a set of rela- tional schemas, diagram the functional dependencies, and convert all the relations to third normal form.

TABLE 4-7 Pine Valley Furniture Company Purchasing Data

Attribute Name Sample Value

Material ID 3792

Material Name Hinges 3” locking

Unit of Measure each

Standard Cost $5.00

Vendor ID V300

Vendor Name Apex Hardware

Unit Price $4.75

Terms Code 1

Terms COD

TABLE 4-8

Booking Reference

Date

Customer Email

From

Place of Embarkation

To

Place of Disembarkation

Eligible Air Miles

B03343 01/12/2018 [email protected] SIN Singapore MLE Male 2111

Signs Books

RENTER Renter ID First Name Middle Initial Last Name Address Phone# EMail

RENTAL AGREEMENT Agreement ID Begin Date End Date Rental Amount

Property Type =

“B” “M”

Blocks to Beach

BEACH PROPERTY

MOUNTAIN PROPERTY

{Activity}

PROPERTY Property ID Street Address City State Zip Nbr Rooms Base Rate Property Type

d

FIGURE 4-35 EER diagram for Vacation Property Rentals

M04_HOFF3359_13_GE_C04.indd 230 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 231

4-46. Figure 4-36 includes an EER diagram describing a car racing league. Transform the diagram into a relational schema that shows referential integrity constraints (see Figure 4-5 for an example of such a schema). In addition, verify that the resulting relations are in 3NF.

4-47. Figure 4-37 includes an EER diagram describing a publisher specializing in large edited works. Transform the diagram into a relational schema that shows referential integrity con- straints (see Figure 4-5 for an example of such a schema). In addition, verify that the resulting relations are in 3NF.

RACE Race ID Race Title Race Location Race Date

RACE COMPONENT RC ID RC Type

PARTICIPATION

Points Earned FINISH

Position Result

TEAM Team ID Team Name Team Manager

DRIVERBelongs To

Consists Of

Driver ID Driver Age Driver Name

FIGURE 4-36 EER diagram for a car racing league

E d

ito r

O rd

er

Includes

Places

E d

its

H as

v o

lu m

es

CHAPTER

Chapter ID Chapter Number Chapter Title

ORDER

Order ID Order Date Order Delivery Date

WHOLESALER

Cust ID Cust Name

ORDER LINE

Orderline Nbr OL Price OL Discount OL Quantity

BOOK

Book Nbr Book ISBN Book Title Book Price

EDITOR

Editor ID Editor LName Editor FName Editor Institution

AUTHOR ASSIGNMENT

Author Position Author Type (Is Lead Author?, Is Contact Author?)

AUTHOR

AuthorID Auth Name (Auth Last Name, Auth First Name, Auth Middle Initial) Auth Phone Auth Email {Auth Expertise}

FIGURE 4-37 EER diagram for a publisher

M04_HOFF3359_13_GE_C04.indd 231 15/03/19 3:39 PM

232 Part II • Database Analysis and Logical Design

4-48. Figure 4-38 includes an EER diagram for a medium-size software vendor. Transform the diagram into a relational schema that shows referential integrity constraints (see Figure 4-5 for an example of such a schema). In addition, verify that the resulting relations are in 3NF.

4-49. Examine the set of relations in Figure 4-39. What normal form are these in? How do you know this? If they are in 3NF, convert the relations into an EER diagram. What assump- tions did you have to make to answer these questions?

4-50. A pet store currently uses a legacy flat file system to store all of its information. The owner of the store, Peter Corona, wants to implement a Web-enabled database application. This would enable branch stores to enter data regarding inventory levels, ordering, and so on. Presently, the data for inventory and sales tracking are stored in one file that has the following format:

StoreName, PetName, Pet Description, Price, Cost, SupplierName, ShippingTime, QuantityOnHand, DateOfLastDelivery, DateOfLastPurchase, DeliveryDate1, DeliveryDate2, DeliveryDate3, DeliveryDate4, PurchaseDate1, PurchaseDate2, PurchaseDate3, PurchaseDate4, LastCustomerName, CustomerName1, CustomerName2, CustomerName3, CustomerName4

Assume that you want to track all purchase and inven- tory data, such as who bought the fish, the date that it was purchased, the date that it was delivered, and so on. The present file format allows only the tracking of the last purchase and delivery as well as four prior purchases and deliveries. You can assume that a type of fish is supplied by one supplier. a. Show all functional dependencies. b. What normal form is this table in? c. Design a normalized data model for these data. Show

that it is in 3NF. 4-51. For Problem and Exercise 4-50, draw the ER diagram

based on the normalized relations. 4-52. How would Problems and Exercises 4-50 and 4-51 change

if a type of fish could be supplied by multiple suppliers? 4-53. Figure 4-40 shows an EER diagram for a university din-

ing service organization that provides dining services to a major university. a. Transform the EER diagram to a set of relations and

develop a relational schema. b. Diagram the functional dependencies and determine

the normal form for each relation. c. Convert all relations to third normal form, if necessary,

and draw a revised relational schema. 4-54. Explore the data included in Table 4-9.

Assume that the primary key of this relation consists of two components: Author’s ID (AID) and Book number

o

REGION Region ID Region Name

PROJECT Proj ID Proj Start Date Proj End Date

TEAM Team ID Team Name Team Start Date Team End Date

COUNTRY Belongs

To

Supervises SupervisesManages

Is Responsible For

Leads

Is Deputy

Mentors

Country ID Country Name

EMPLOYEE Emp ID Emp Name Emp Type

COUNTRY MANAGER

DEVELOPMENT MANAGER

DEVELOPER Developer Type

ASSIGNMENT

Score Hours Rate MEMBERSHIP

Joined Left

SENIOR WIZARD

JUNIOR

d

FIGURE 4-38 EER diagram for a middle-size software vendor

M04_HOFF3359_13_GE_C04.indd 232 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 233

CaseID Description CaseType CourtID

Attorney

Speciality

Bar

Client

Case

Retains

Court

Judge

AttorneyID Name Address City State ZipCode

ClientID Name Address City State ZipCode Telephone DOB

AttorneyID Speciality

AttorneyID Bar

AttorneyID CaseID ClientID Date

CourtID CourtName City State ZipCode

JudgeID Name Years CourtID

FIGURE 4-39 Relations for Problem and Exercise 4-49

Supervises Contains

Served at

STAFF Emp ID Name Salary {Skill}

WORK SCHEDULE Start Time End Time Position

DISH Dish ID Dish Name Prep Time {Ingredient}

EVENT Event ID Event Date Event Location Event Time

Menu ID Menu Description Menu Type

MENU

FIGURE 4-40 EER diagram for university dining services

(BNbr). The relation includes data regarding authors, books, and publishers. In addition, it tells what an indi- vidual author’s per book royalty amount is in the case of multi-authored books.

Your task is to: a. Identify the functional dependencies between the attri-

butes. b. Identify the normal form in which the relation cur-

rently is.

c. Identify the errors in the data that have been made pos- sible by its poor structural characteristics.

d. Take the actions (if any) necessary to convert the rela- tion into the third normal form. Identify all intermedi- ate steps.

4-55. The following attributes form a relation that includes information about the issue and return of books by stu- dents from a university library. Students of each depart- ment in the university are authorized to issue and return

M04_HOFF3359_13_GE_C04.indd 233 15/03/19 3:39 PM

234 Part II • Database Analysis and Logical Design

the books after a specific time period (characterized with attributes Issue Start Date and Issue Ending Date). When the book is returned, the number of overdue days (the difference between Issue End Date and Return Date) is computed. If it is positive, the fine imposed is calcu- lated. Students are identified by ID, Name, Course, and Department. Course and department names are unique. Books are identified by ID, Title, Author, Publisher, and Edition.

The attributes are as follows:

BookIdentificationNo, BookTitle, BookAuthor, BookPublisher, BookEdition, StudentID, StudentName, StudentDepartment, StudentCourse, IssueID, IssueStartDate, IssueEndingDate, ReturnID, ReturnDate, OverdueDays, FineImposed.

Based on this information, a. Identify the functional dependencies between the attri-

butes. b. Identify the reasons why this relation is not in 3NF. c. Present the attributes organized so that the resulting

relations are in 3NF. 4-56. Jack Patel is a huge comic book fan who is looking to turn

his hobby into a business. Spotting a gap in the market, he intends to create a comic rental business to provide locals with access to comics and tap into the growing interest in superheroes. Jack currently has over 5,000 comics and graphic novels, so the first thing he needs to do is cata- log his collection and set the rental price. Each comic is classified according to an ID based on the Jack’s own sys- tem of classification (based on issue number and hero/ team name), which has a title plus information about the writer and illustrator. Along with the title, information is also provided about the main heroes (their alter egos and team affiliation) as well as the main antagonist(s). In some cases, Jack has multiple copies of the same comic,

with each copy assigned a rental status, return date, and rental price. The attributes are as follows:

Comic ID, Title, Publisher, Writer, Illustrator, Hero, Alias, Affiliation, Villain, copy number, rental cost, rental sta- tus, return date, CustomerID

A sample data set regarding a comic would be as follows (the data in the braces is when there is more than one piece of data):

“mx101,” “X-Men Extinction Agenda,” “Marvel Comics,” {“Louise Simonson” | “Chris Claremont”}, “Jim Lee,” {“Wolverine,” “Logan” | “Cyclops,” “Scott Summers” | “Phoenix,” “Jean Gray”}, “Cameron Hodge,” 001, 5.00, “onLoan,” 12/03/2019, “c012”

Based on this information, a. Identify the functional dependencies between the attri-

butes. b. Present the attributes organized into 3NF relations that

have been named appropriately. 4-57. A price aggregator system provides users with a one-

stop portal where they can compare the price of products across multiple Web sites. The portal allows users to not only compare prices but also view customer feedback and reviews of the different Web sites. Users are required to first create an account before using the portal for the first time, after which they can review the results of previous product searches as well compare the fluctuations in prices over a given time. To provide this functionality, the system maintains the following data:

SearchID, UserID, UserName, UserEmail, SearchDate, SearchTime, SearchCategory, SearchBrand, SearchModel,

TABLE 4-9 Author Book Royalties

AID ALname AFname AInst BNbr BName BPublish PubCity BPrice AuthBRoyalty

10 Gold Josh Sleepy Hollow U

106 JavaScript and HTML5

Wall & Vintage

Chicago, IL $62.75 $6.28

102 Quick Mobile Apps

Gray Brothers

Boston, MA $49.95 $2.50

24 Shippen Mary Green Lawns U

104 Innovative Data Management

Smith and Sons

Dallas, TX $158.65 $15.87

106 JavaScript and HTML5

Wall & Vintage

Indianapolis, IN $62.75 $6.00

32 Oswan Jan Middlestate College

126 Networks and Data Centers

Grey Brothers

Boston, NH $250.00 $12.50

180 Server Infrastructure

Gray Brothers

Boston, MA $122.85 $12.30

102 Quick Mobile Apps

Gray Brothers

Boston, MA $45.00 $2.25

M04_HOFF3359_13_GE_C04.indd 234 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 235

BrandID, LowestPrice, LowestPriceURL, Price2, Price2URL, Price3, Price3URL, Price4, Price4URL, Price5, Price5URL, LowestPriceURL_Rating, Price2URL_ Rating, Price3URL_Rating, Price4URL_Rating, Price5URL_ Rating

Sample data for this set of attributes is as follows:

32332, 0332, Clark Kent, [email protected], 12122018, 10.28.34, laptop, IBM, thinkpad, t61, 60, vintageLaptop- sRUs.net, 68, thinkpadsLikeNew.org, 89, getOldLaptops. tv, 143, laptopslikenew.biz, 146, 123t61IBM4u.net, 200, oldlikeNewPCs.biz, 4,3,4,3,5,4

Based on the facts stated above, a. Identify the functional dependencies between the attri-

butes. b. Identify the reasons why this set of data is not in 3NF

and indicate the normal form (if any) it is in. c. Including all intermediate stages, organize the attri-

butes into a set of 3NF relations. 4-58. A university library system is responsible for tracking

information about its books and users. At present, it offers lending facilities to over 5,000 students and has a catalog exceeding 1,000 books and periodicals. It is essential for the library to effectively keep track of what items have been borrowed, by whom, as well as which borrowers

have outstanding fines (this may affect the number of items they can borrow). The data the library has available includes the following attributes:

BookCopyNo, BookISBN, Title, Author, Publisher, LoanStartDate, ReturnDate, StudentID, StudentFName, StudentLName, DegreeProgramme, Year, CurrentLoanNumber, OutstandingFines

Sample data for this set of attributes is as follows:

12, 12203223232, Surviving University Life, Mr A N Other, Uni Books, {12/12/2018, 12/01/2019, 0292, John, Smith, Economics, 3, 12, False | 10/11/2018, 11/12/2018, 0402, Sarah, Chen, Computer Science, 1, 3, True | 04/08/2018, 04/09/2018, 0222, lai, Wit Yah, Economics, 2, 0, False | 23/04/2018, 23/05/2018, 0143, Saira, Saeed, Finance, 2, 4, True}

Note that the information for specific book copies is repeated four times in the sample data provided and is separated by the | symbol. Based on the facts stated above, a. Identify the functional dependencies between the attri-

butes. b. Draw an ER diagram.

Field Exercises

4-59. Interview system designers and database designers at several organizations. Ask them to describe the process they use for logical design. How do they transform their conceptual data models (e.g., E-R diagrams) to relational schema? What is the role of CASE tools in this process? Do they use normalization? If they do, how far in the process do they go, and for what purpose?

4-60. Obtain an EER diagram from a database administrator or system designer. Based on what you have learned in this book, convert this into a relational schema in 3NF. Now interview the administrator on how they convert the diagram into relations. How do they impose integrity constraints? What was the need for this? How do they

identify candidate keys, and is there any usage of sur- rogate primary keys? Did they face the issue of merging relations? How did they overcome it?

4-61. Using the online Appendix B, available on the book’s Web site, as a resource, interview a database analyst/designer to determine whether he or she normalizes relations to higher than 3NF. Why or why not does he or she use nor- mal forms beyond 3NF?

4-62. Look for a receipt from a supermarket or other retail store you have purchased from. Based on the receipt, draw an EER diagram of the data in this form or report. Transform the diagram into a set of 3NF relations.

References

Chouinard, P. 1989. “Supertypes, Subtypes, and DB2.” Database Programming & Design 2,10 (October): 50–57.

Codd, E. F. 1970. “A Relational Model of Data for Large Shared Data Banks.” Communications of the ACM 13,6 (June): 77–87.

Codd, E. F. 1990. The Relational Model for Database Management, Version 2. Reading, MA: Addison-Wesley.

Date, C. J. 2003. An Introduction to Database Systems. 8th ed. Reading, MA: Addison-Wesley.

Dutka, A. F., and H. H. Hanson. 1989. Fundamentals of Data Nor- malization. Reading, MA: Addison-Wesley.

Elmasri, R., and S. B. Navathe. 2015. Fundamentals of Database Systems. 7th ed. Reading, MA: Pearson/Addison-Wesley.

Fleming, C. C., and B. von Halle. 1989. Handbook of Relational Database Design. Reading, MA: Addison-Wesley.

Hoberman, S. 2006. “To Surrogate Key or Not.” DM Review 16,8 (August): 29.

Johnston, T. 2000. “Primary Key Reengineering Projects: The Problem” and “Primary Key Reengineering Projects: The Solution.” Available at www.information- management.com.

Navathe, S., R. Elmasri, and J. Larson. 1986. “Integrating User Views in Database Design.” Computer 19,1 (January): 50–62.

M04_HOFF3359_13_GE_C04.indd 235 15/03/19 3:39 PM

236 Part II • Database Analysis and Logical Design

Further Reading

Russell, T., and R. Armstrong. 2002. “13 Reasons Why Normalized Tables Help Your Business.” Database Administrator, April 20, 2002. Available at http://searchoracle. techtarget.com/tip/13-reasons-why-normalized-tables- help-your-business.

Storey, V. C. 1991. “Relational Database Design Based on the Entity-Relationship Model.” Data and Knowledge Engineering 7,1 (November): 47–83.

Valacich, J.S. and J.F. George. 2016. Modern Systems Analysis and Design. 8th ed. Upper Saddle River, NJ: Prentice Hall.

Web Resources

http://en.wikipedia.org/wiki/Database_normalization Wiki- pedia entry that provides a thorough explanation of first, second, third, fourth, fifth, and Boyce-Codd normal forms.

www.bkent.net/Doc/simple5.htm Web site that presents a summary paper by William Kent titled “A Simple Guide to Five Normal Forms in Relational Database Theory.”

www.stevehoberman.com Web site where Steve Hoberman, a leading consultant and lecturer on database design, presents

and analyzes database design (conceptual and logical) problem. These are practical (based on real experiences or questions sent to him) situations that make for interesting puzzles to solve.

www.troubleshooters.com/codecorn/norm.htm Web page on normalization on Steve Litt’s site that contains various trou- bleshooting tips for avoiding programming and systems development problems.

M04_HOFF3359_13_GE_C04.indd 236 15/03/19 3:39 PM

4 • Logical Database Design and the Relational Model 237

foreign keys as well as clearly state referential integrity constraints.

4-64. Analyze and document the functional dependencies in each relation identified in 4-63 above. If any relation is not in 3NF, decompose it into 3NF, using the steps described in this chapter. Revise your relational schema accordingly.

4-65. Does it make sense for FAME to use enterprise keys? If so, create the appropriate enterprise keys and revise the relational schema accordingly.

4-66. If necessary, revisit and modify the EER diagram you created in Chapter 3, 3-44, to reflect any changes made in answering 4-64 and 4-65 above.

Case Description

Having reviewed your conceptual models (from Chapters 2 and 3) with the appropriate stakeholders and gaining their approval, you are now ready to move to the next phase of the project, logical design. Your next deliverable is the creation of a relational schema.

Project Questions

4-63. Map the EER diagram you developed in Chapter 3, 3-44, to a relational schema using the techniques described in this chapter. Be sure to appropriately identify the primary and

CASE Forondo Artist Management Excellence Inc.

M04_HOFF3359_13_GE_C04.indd 237 15/03/19 3:39 PM

M04_HOFF3359_13_GE_C04.indd 238 15/03/19 3:39 PM

This page intentionally left blank

239

Database Implementation and Use

AN OVERVIEW OF PART III

Part III considers topics associated with implementing and using systems based on the relational model, including the use of databases in modern application development. Database implementation, as indicated in Chapter 1, includes coding and testing database processing programs, completing database documentation and training materials, and installing databases and converting data, as necessary, from prior systems. In the context of the integrated framework introduced in Figure 1-5, this part will focus on the implementation and infrastructure of and access to transactional systems, but the SQL language skills you learn here are widely applicable also in the context of analytic systems. Here, at last, is the point in the systems development life cycle for which you have been preparing. Our prior activities—enterprise modeling, conceptual data modeling, and logical database design—are necessary previous stages. At the end of implementation, you will be able to deliver a functioning system that meets users’ information requirements. After that, the system will be put into production use, and database maintenance will be necessary for the life of the system. The chapters in Part III help develop an initial understanding of the complexities and challenges of implementing a database system. These chapters also prepare you to be an expert-level database user through their focus on Structured Query Language (SQL) and use of relational databases in application development.

In Chapter 5, you will get the first introduction to SQL, which has become a standard language (especially on database servers) for creating and processing relational databases. In addition to a thorough introduction to the features of SQL:1999, currently used by most DBMSs, along with a discussion of the SQL:2011 and SQL:2016 standards that are implemented by increasingly many relational systems, you will learn the core syntax of SQL. After completing the coverage of Chapter 5, you will be able to use commands of data definition language (DDL) to create a database based on a relational model (which you learned to create in Chapter 4) and the data manipulation language (DML) at the single-table level to query a database.

In Chapter 6, you will be exposed to more advanced SQL syntax and constructs. Specifically, you will learn multiple-table queries, along with subqueries and correlated subqueries. These capabilities provide SQL with much of its power. You will also learn about dynamic and materialized views and the role of the data dictionary in database construction. Additional programming capabilities, including triggers and stored procedures, further demonstrate the capabilities of SQL. Strategies for writing and testing queries, from simple to more complex, are offered.

PART III

Chapter 5 Introduction to SQL

Chapter 6 Advanced SQL

Chapter 7 Databases in Applications

Chapter 8 Physical Database Design and Database Infrastructure

M05A_HOFF3359_13_GE_P03.indd 239 22/02/19 2:46 PM

240 Part III • Database Implementation and Use

Chapter 7 helps you learn about the use of relational databases in an application development context and the role of databases in system architecture. After studying the material in this chapter, you will understand how SQL can be embedded in a programming language context. Moreover, Chapter 7 covers transaction integrity and ACID properties of transactions, a vitally important topic area that forms the foundation of most transaction processing systems. The chapter demonstrates to you how to use SQL in the context of modern programming language (Python and Java). You will also learn about database security in an application context and issues you need to consider in applications that provide concurrent access to multiple users.

Chapter 8 will significantly strengthen your understanding of issues related to physical database design and its relationship with database implementation, obviously building on the introduction you received in Chapter 5. You will learn to see why physical database design is a critically important component of ensuring the quality and validity of data in an organization’s databases and why this matters from the regulatory perspective. After studying the chapter, you will be able to make fully informed decisions regarding data types, denormalization of a database, data dictionaries, indexing, and other mechanisms that will allow you to tune the database for a high level of performance. The chapter will also show the role of physical database design on security design, data availability, and database recovery.

As indicated by this brief synopsis of the chapters, Part III provides you with tools for using a relational database at an expert level either directly with a SQL interface or as part of an application. It will also give you a conceptual understanding of the issues involved in implementing database applications and an initial practical understanding of the procedures necessary to construct a database prototype. After covering the material in Part III, you will also be able to contribute to efficient physical database design and implement the design outcomes with SQL.

M05A_HOFF3359_13_GE_P03.indd 240 22/02/19 2:46 PM

241

LEARNING OBJECTIVES After studying this chapter, you should be able to:

■■ Concisely define each of the following key terms: relational DBMS (RDBMS), catalog, schema, data definition language (DDL), data manipulation language (DML), data control language (DCL), scalar aggregate, and vector aggregate.

■■ Interpret the history and role of SQL in database development. ■■ Define a database using the SQL data definition language. ■■ Write single-table queries using SQL commands. ■■ Establish referential integrity using SQL. ■■ Discuss the SQL:1999 and SQL:2016 standards.

INTRODUCTION

In this chapter, you will (finally, many of you might think) be introduced to the tools that will allow you to create a database and manipulate its content. The primary mechanism for that is a language called SQL (pronounced “S-Q-L” by some and “sequel” by others), the de facto standard language of relational database management systems for creating and querying relational databases. SQL has become so popular and widely used that many nonrelational databases that we will discuss in the context of the informational systems (see framework in Figure 1-5) are based on the same ideas and created so that the transition from SQL to these other environments is very straightforward.

SQL has been accepted as a U.S. standard by the American National Standards Institute (ANSI) and is a Federal Information Processing Standard (FIPS). It is also an international standard recognized by the International Organization for Standardization (ISO). ANSI has accredited the International Committee for Information Technology Standards (INCITS) as a standards development organization; INCITS is working on the next version of the SQL standard scheduled to be released in 2021 based on a five-year cycle.

The SQL standard is like afternoon weather in Florida (and maybe where you live, too)—wait a little while, and it will change. The ANSI SQL standards were first published in 1986 and updated in 1989, 1992 (SQL-92), 1999 (SQL:1999), 2003 (SQL:2003), 2006 (SQL:2006), 2008 (SQL:2008), 2011 (SQL:2011), and 2016 (SQL:2016). (See http://en.wikipedia.org/wiki/SQL for a summary of this history.) The standard is now generally referred to as SQL:2016 (ISO/IEC 9075).

SQL-92 was a major revision and was structured into three levels: Entry, Intermediate, and Full. SQL:1999 established the core-level conformance, which must be met before any other level of conformance can be achieved; core-level

Visit www.pearsonglobaleditions .com to view the accompanying video for this chapter.

Introduction to SQL 5

M05B_HOFF3359_13_GE_C05.indd 241 10/04/19 2:46 PM

242 Part III • Database Implementation and Use

conformance requirements are unchanged in SQL:2016. In addition to fixes and enhancements of SQL:1999, SQL:2003 introduced a new set of SQL/XML standards, three new data types, various new built-in functions, and improved methods for generating values automatically. SQL:2006 refined these additions and made them more compatible with XQuery, the XML query language published by the World Wide Web Consortium (W3C). SQL:2008 improved analytics query capabilities and enhanced MERGE for combining tables. The most important new additions to SQL:2011 were related to temporal databases, that is, databases that are able to capture the change in the data values over time. SQL:2016 introduced four significant new features: row pattern recognition (e.g., for analysis of time-series data), support for JSON objects (see Chapter 10), new user-defined functions called polymorphic table functions, and an extended set of analytic capabilities. At the time of this writing, most database management systems claim at least SQL-92 compliance and partial compliance with SQL:1999 and SQL:2011.

Except where noted as a particular vendor’s syntax, the examples in this chapter conform to the SQL standard. Concerns have been expressed about SQL:1999 and SQL:2003/SQL:2008/SQL:2011/SQL:2016 being true standards because conformance with the standard is no longer certified by the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) (Gorman, 2001). “Standard SQL” may be considered an oxymoron (like safe investment or easy payments!). Vendors’ interpretations of the SQL standard differ from one another, and vendors extend their products’ capabilities with proprietary features beyond the stated standard. This makes it difficult to port SQL from one vendor’s product to another. One must become familiar with the particular version of SQL being used and not expect that SQL code will transfer exactly as written to another vendor’s version. Table 5-1 demonstrates differences in handling date and time values to illustrate discrepancies one encounters across SQL vendors (IBM DB2, Microsoft SQL Server, MySQL [an open source DBMS owned by Oracle], and Oracle).

SQL has been implemented in both mainframe and personal computer systems, so this chapter is relevant to both computing environments. Although many of the PC-database packages use a query-by-example (QBE) interface, they also include SQL coding as an option. QBE interfaces use graphic presentations and translate the QBE actions into SQL code before query execution occurs. In Microsoft Access, for example, it is possible to switch back and forth between the two interfaces; a query that has been built using a QBE interface can be viewed in SQL by clicking a button. This feature may aid you in learning SQL syntax. In client/server architectures, SQL

TABLE 5-1 Handling Date and Time Values

TIMESTAMP data type: A core feature, the standard requires that this data type store year, month, day, hour, minute, and second (with fractional seconds; default is six digits).

TIMESTAMP WITH TIME ZONE data type: Extension to TIMESTAMP also stores the time zone.

Implementation:

Product Follows Standard? Comments

DB2 Yes TIMESTAMP WITH TIME ZONE was implemented starting in DB2 11.

Transact-SQL (SQL Server)

No DateTimeOffset data type offers functional equivalency to TIMESTAMP WITH TIME ZONE.

MySQL TIMESTAMP only with limited range

TIMESTAMP captures also the time zone information; TIMESTAMP values are stored in UTC (coordinated universal time) and converted back to the local time for use. TIMESTAMP range is very limited (1-1-1970 to 1-19-2038).

Oracle TIMESTAMP and TIMESTAMP WITH TIME ZONE

TIMESTAMP WITH TIME ZONE is fully supported in Oracle 12c.

M05B_HOFF3359_13_GE_C05.indd 242 23/02/19 12:44 PM

5 • Introduction to SQL 243

commands are executed on the server, and the results are returned to the client workstation.

The first commercial DBMS that supported SQL was Oracle in 1979. Oracle is now available in mainframe, client/server, and PC-based platforms for many operating systems, including various UNIX, Linux, and Microsoft Windows operating systems. IBM’s DB2, Informix, and Microsoft SQL Server are available for this range of operating systems also. See Kulkarni and Michels (2012) and Zemke (2012) for descriptions of the recent features added to SQL.

ORIGINS OF THE SQL STANDARD

The concepts of relational database technology were first articulated in 1970 in E. F. Codd’s classic paper “A Relational Model of Data for Large Shared Data Banks.” Work- ers at the IBM Research Laboratory in San Jose, California, undertook development of System R, a project whose purpose was to demonstrate the feasibility of implementing the relational model in a database management system. They used a language called Sequel, also developed at the San Jose IBM Research Laboratory. Sequel was renamed SQL during the project, which took place from 1974 to 1979. The knowledge gained was applied in the development of SQL/DS, the first relational database management sys- tem available commercially (from IBM). SQL/DS was first available in 1981, running on the DOS/VSE operating system. A VM version followed in 1982, and the MVS version, DB2, was announced in 1983.

When System R was well received at the user sites where it was installed, other vendors began developing relational products that used SQL. One product, Oracle, from Relational Software, was actually on the market before SQL/DS (1979). Other products included INGRES from Relational Technology (1981), IDM from Britton-Lee (1982), DG/SQL from Data General Corporation (1984), and Sybase from Sybase, Inc. (1986). To provide some directions for the development of relational DBMSs, ANSI and the ISO approved a standard for the SQL relational query language (functions and syntax) that was originally proposed by the X3H2 Technical Committee on Database (Technical Committee X3H2—Database, 1986; ISO, 1987), often referred to as SQL/86. For a more detailed early history of the SQL standard, see the documents available at www.wiscorp.com/SQLStandards.html.

The following were the original purposes of the SQL standard:

1. To specify the syntax and semantics of SQL data definition and manipulation languages.

2. To define the data structures and basic operations for designing, accessing, main- taining, controlling, and protecting an SQL database.

3. To provide a vehicle for portability of database definition and application modules between conforming DBMSs.

4. To specify both minimal (Level 1) and complete (Level 2) standards, which permit different degrees of adoption in products.

5. To provide an initial standard, although incomplete, that will be enhanced later to include specifications for handling such topics as referential integrity, trans- action management, user-defined functions, join operators beyond the equi-join, and national character sets.

In terms of SQL, when is a standard not a standard? As explained earlier, most vendors provide unique, proprietary features and commands for their SQL database management system. So what are the advantages and disadvantages of having an SQL standard when there are such variations from vendor to vendor? The benefits of such a standardized relational language include the following (although these are not pure benefits because of vendor differences):

• Reduced training costs Training in an organization can concentrate on one language. A large labor pool of IS professionals trained in a common language reduces retraining for newly hired employees.

M05B_HOFF3359_13_GE_C05.indd 243 23/02/19 12:44 PM

244 Part III • Database Implementation and Use

• Productivity IS professionals can learn SQL thoroughly and become proficient with it from continued use. An organization can afford to invest in tools to help IS professionals become more productive. Because they are familiar with the language in which programs are written, programmers can more quickly maintain existing programs.

• Application portability Applications can be moved from one context to another when each environment uses SQL. Further, it is economical for the computer software industry to develop off-the-shelf application software when there is a standard language.

• Application longevity A standard language tends to remain so for a long time; hence, 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 DBMSs are introduced.

• 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 ven- dors will be more competitive, which may lower prices and improve service.

• Cross-system communication Different DBMSs and application programs can more easily communicate and cooperate in managing data and processing user programs.

On the other hand, a standard can stifle creativity and innovation; one standard is never enough to meet all needs, and an industry standard can be far from ideal because it may be the offspring of compromises among many parties. A standard may be difficult to change (because so many vendors have a vested interest in it), so fixing deficiencies may take considerable effort. Another disadvantage of standards that can be extended with proprietary features is that using special features added to SQL by a particular vendor may result in the loss of some advantages, such as application portability.

The original SQL standard was widely criticized, especially for its lack of referential integrity rules and certain relational operators. Date and Darwen (1997) expressed con- cern that SQL seems to have been designed without adhering to established principles of language design, and “as a result, the language is filled with numerous restrictions, ad hoc constructs, and annoying special rules” (p. 8). They believed that the standard is not explicit enough and that the problem of standard SQL implementations would continue to exist. Some of these limitations have stayed and will be noticeable in this chapter.

Many products are available that support SQL, and they run on machines of all sizes, from small personal computers to large mainframes. The relational data- base market is maturing, and the rate of significant changes in products may slow, but they will continue to be SQL based. The number of relational database vendors with significant market share has continued to consolidate. Gartner Group reports that Oracle controlled almost 42 percent of the overall relational database management sys- tem market in 2015, Microsoft was in second place at 19 percent, and IBM came in third at 17  percent. Teradata and AWS (Amazon Web Services) also had significant—albeit much smaller—shares. Open source products, such as MySQL and PostgreSQL, together have a significant market share, with MySQL, an open source version of SQL that runs on Linux, UNIX, Windows, and Mac OS X operating systems, achieving considerable popularity. (Download MySQL for free from www.mysql.com.) Opportunities still exist for smaller vendors to prosper through industry-specific systems or niche applications. Upcoming product releases may change the relative strengths of the relational database management systems by the time you read this book. But all of them will continue to use SQL, and they will follow, to a certain extent, the standard described here.

In Chapter 10, you will learn about new technologies that are not based on the relational model, including big data technologies such as Hadoop and so-called NoSQL (“Not Only SQL”) database management systems. They are gaining market popu- larity, but their financial share of the market is currently very small compared to the traditional SQL vendors. SQL’s dominant role as a query and data manipulation lan- guage has, however, led to the creation of a wide variety of mechanisms that allow data stored on these new platforms to be accessed with SQL or an SQL-like language. See

M05B_HOFF3359_13_GE_C05.indd 244 23/02/19 12:44 PM

5 • Introduction to SQL 245

Yegulalp (2014) for details of products such as Hive, Stinger, Drill, and Spark (no, we did not make these names up).

Because of its significant market share, we most often illustrate SQL in this text using Oracle 12c syntax. We use a specific relational DBMS not to promote or endorse Oracle but rather so we know that the code we use will work with some DBMS. In the vast majority of the cases, the code will, in fact, work with many relational DBMSs because it complies with standard ANSI SQL. In some cases, we include illustrations using several or other relational DBMSs when there are interesting differences. How- ever, there are only a few such cases because we are not trying to compare systems, and we want to be parsimonious.

THE SQL ENVIRONMENT

With today’s relational DBMSs and application generators, the importance of SQL within the database architecture is not usually apparent to the application users. Many users who access database applications have no knowledge of SQL at all. For example, sites on the Web allow users to browse their catalogs. The information about an item that is presented, such as size, color, description, and availability, is stored in a database. The information has been retrieved using an SQL query, but the user has not issued an SQL command. Rather, the user has used a prewritten program (written in, e.g., Python, Java, or PHP) with embedded SQL commands for database processing.

An SQL-based relational database application involves a user interface, a set of tables in the database, and a relational database management system (RDBMS) with an SQL capability. Within the RDBMS, SQL will be used to create the tables, translate user requests, maintain the data dictionary and system catalog, update and maintain the tables, establish security, and carry out backup and recovery procedures. A relational DBMS (RDBMS) is a data management system that implements a relational data model, one where data are stored in a collection of tables and the data relationships are represented by common values, not links. This view of data was illustrated in Chapter 2 for the Pine Valley Furniture Company database system and will be used throughout this chapter’s SQL query examples.

Figure 5-1 is a simplified schematic of an SQL environment, consistent with the SQL:2016 standard. As depicted, an SQL environment includes an instance of an SQL database management system along with the databases accessible by that DBMS and

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 in related tables.

SQL Environment

USERS

SQL queries

Required information

schema

User schemas

Catalog: DEV_C

Required information

schema

User schemas

Catalog: PROD_C APPLICATIONS

DBMS

DATADATA

FIGURE 5-1 A simplified schematic of a typical SQL environment, as described by the SQL:2016 standards

M05B_HOFF3359_13_GE_C05.indd 245 23/02/19 12:44 PM

246 Part III • Database Implementation and Use

the users and applications that may use that DBMS to access the databases. Each data- base is contained in a catalog, which describes any object that is a part of the database, regardless of which user created that object. Figure 5-1 shows two catalogs: DEV_C and PROD_C. Most companies keep at least two versions of any database they are using. The production version, PROD_C here, is the live version, which captures real busi- ness data and thus must be very tightly controlled and monitored. The development version, DEV_C here, is used when the database is being built and continues to serve as a development tool where enhancements and maintenance efforts can be thoroughly tested before being applied to the production database. Typically, this database is not as tightly controlled or monitored because it does not contain live business data. Each database will have a named schema(s) associated with a catalog. A schema is a collec- tion of related objects, including but not limited to base tables and views, domains, constraints, character sets, triggers, and roles.

If more than one user has created objects in a database, combining information about all users’ schemas will yield information for the entire database. Each catalog must also contain an information schema, which contains descriptions of all schemas in the catalog, tables, views, attributes, privileges, constraints, and domains, along with other information relevant to the database. The information contained in the catalog is maintained by the DBMS as a result of the SQL commands issued by the users and can be rebuilt without conscious action by the user. It is part of the power of the SQL lan- guage that the issuance of syntactically simple SQL commands may result in complex data management activities being carried out by the DBMS software. Users can browse the catalog contents by using SQL SELECT statements.

SQL commands can be classified into three types. First, there are data defini- tion language (DDL) commands. These commands are used to create, alter, and drop tables, views, and indexes, and they are covered first in this chapter. There may be other objects controlled by the DDL, depending on the DBMS. For example, many DBMSs support defining synonyms (abbreviations) for database objects or a field to hold a specified sequence of numbers (which can be helpful in assigning primary keys to rows in tables). In a production database, the ability to use DDL commands will generally be restricted to one or more database administrators in order to protect the database struc- ture from unexpected and unapproved changes. In development or student databases, DDL privileges will be granted to more users. You will be able to practice the SQL DDL commands once your instructor has given you access to a test database.

Next, there are data manipulation language (DML) commands. Many consider the DML commands to be the core of SQL. These commands are used for updating, inserting, modifying, and querying the data in the database. They may be issued interactively so that a result is returned immediately following the execution of the statement, or they may be included within programs written in a procedural program- ming language, such as C, Java, Python, or COBOL, or with a GUI tool (e.g., Oracle’s SQL Developer, SQL Assistant with Teradata, or MySQL Query Browser). Embedding SQL commands may provide the programmer with more control over timing of report generation, interface appearance, error handling, and database security (see Chapter 7 on embedding SQL in applications). Most of this chapter is devoted to covering basic DML commands in interactive format. The general syntax of the SQL SELECT com- mand used in DML is shown in Figure 5-2.

Finally, data control language (DCL) commands help a database administrator (DBA) control the database. They include commands to grant or revoke privileges to access the database or particular objects within the database and to store or remove transactions that would affect the database.

Catalog

A set of schemas that, when put together, constitute a description of a database.

Schema

A structure that contains descriptions of objects created by a user, such as base tables, views, and constraints, as part of a database.

Data definition language (DDL)

Commands used to define a database, including those for creating, altering, and dropping tables and establishing constraints.

Data manipulation language (DML)

Commands used to maintain and query a database, including those for updating, inserting, modifying, and querying data.

Data control language (DCL)

Commands used to control a database, including those for administering privileges and committing (saving) data.

SELECT [ALL/DISTINCT] column_list FROM table_list [WHERE conditional expression] [GROUP BY group_by_column_list] [HAVING conditional expression] [ORDER BY order_by_column_list]

FIGURE 5-2 General syntax of the SELECT statement used in DML

M05B_HOFF3359_13_GE_C05.indd 246 23/02/19 12:44 PM

5 • Introduction to SQL 247

Before you can create a database using DDL, you have to make key design decisions regarding the database implementation. We will cover those decisions at a detailed level in Chapter 8 on physical database design. At this point, it is sufficient for you to remem- ber that the foundation for the process of defining a database in SQL is the conceptual and logical design process that you learned in Chapters 2 to 4. In the database develop- ment cycle, the database implementation is based on the outcome of the logical database design process described in Chapter 4. The relational logical level solution gives you the tables, the columns of the tables, and the referential integrity rules (in practice, foreign keys). In order to implement a database, you will need to determine the data types for the columns. We will discuss those in the next section. In addition, you will need to be able to choose appropriate indexes for the database, which you will start to learn later in this chapter. Chapter 8 on physical database design will give you a much more detailed understanding of the processes you can use to develop a high-quality physical database implementation; we will cover those in Chapter 8 because you will understand those issues much better once you have learned the SQL language in Chapters 5 to 7.

SQL Data Types

Each DBMS has a defined list of data types that it can handle. All contain numeric, string, and date/time-type variables. Some also contain graphic data types, spatial data types, or image data types, which greatly increase the flexibility of data manipulation. When a table is created, the data type for each attribute must be specified. Selection of a particular data type is affected by the data values that need to be stored and the expected uses of the data. A unit price will need to be stored in a numeric format because math- ematical manipulations, such as multiplying unit price by the number of units ordered, are expected. A phone number may be stored as string data, especially if foreign phone numbers are going to be included in the data set. Even though a phone number con- tains only digits, no mathematical operations, such as adding or multiplying phone numbers, make sense with a phone number. Because character data will process more quickly, numeric data should be stored as character data if no arithmetic calculations are expected. Selecting a date field rather than a string field will allow the developer to take advantage of date/time interval calculation functions that cannot be applied to a character field. See Table 5-2 for a few examples of ANSI SQL data types and their Oracle equivalents. SQL:2008 introduced three new data types: BIGINT, MULTISET, and XML. Watch for these new data types to be added to RDBMSs that had not previ- ously introduced them as an enhancement of the existing standard.

Given the wealth of graphic and image data types, it is necessary to consider busi- ness needs when deciding how to store data. For example, color may be stored as a

TABLE 5-2 Sample ANSI SQL Data Types

String CHARACTER(n) or CHAR(n)

Stores string values containing any characters in a character set. CHAR is defined to be a fixed length, for example, CHAR(2).

CHARACTER VARYING(n) or CHAR VARYING(n)

Stores string values containing any characters in a character set using space only for the actual length of the string. In Oracle, VARCHAR2, for example, VARCHAR2(30).

Binary BINARY LARGE OBJECT (BLOB)

Stores binary string values in hexadecimal format. BLOB is defined to be a variable length. (Oracle also has CLOB and NCLOB as well as BFILE for storing unstructured data outside the database.)

Number NUMERIC(p,s) or DECIMAL (p,s)

Stores exact numbers with a defined precision and scale. In Oracle, NUMBER (precision, scale), for example, NUMBER (12,2).

INTEGER or INT Stores exact numbers with a predefined precision and scale of zero.

Temporal TIMESTAMP TIMESTAMP WITH LOCAL TIME ZONE

Stores a moment an event occurs, using a definable fraction-of- a-second precision. Value adjusted to the user’s session time zone (available fully in DB2 and Oracle).

Boolean BOOLEAN Stores truth values: TRUE, FALSE, or UNKNOWN.

M05B_HOFF3359_13_GE_C05.indd 247 23/02/19 12:44 PM

248 Part III • Database Implementation and Use

descriptive character field, such as “sand drift” or “beige.” But such descriptions will vary from vendor to vendor and do not contain the amount of information that could be contained in a spatial data type that includes exact red, green, and blue intensity values. Such data types are now available in universal servers, which handle data warehouses, and can be expected to appear in RDBMSs as well. In addition to the predefined data types included in Table 5-2, SQL:1999 and SQL:2016 support constructed data types and user-defined types. There are many more predefined data types than those shown in Table 5-2. It will be necessary to familiarize yourself with the available data types for each RDBMS with which you work to achieve maximum advantage from its capabilities.

We are almost ready to illustrate sample SQL commands. The sample data that we will be using are shown in Figure 5-3 (which was captured in Microsoft Access). The data model corresponds to that shown in Figure 2-22. The PVFC database files are available for your use on this text’s Web site; the files are available in several formats, for use with different DBMSs, and the database is also available on Teradata University Network. Instructions for locating them are included inside the front cover of the book. There are two PVFC files. The one used here is named BookPVFC (also called Standard PVFC), and you can use it to work through the SQL queries demonstrated in Chapters 5 and 6. Another file, BigPVFC, contains more data and does not always correspond to Figure 2-22, nor does it always demonstrate good database design. Big PVFC is used for some of the exercises at the end of the chapter.

Each table name follows a naming standard that places an underscore and the letter T (for table) at the end of each table name, such as Order_T or Product_T. (Most DBMSs do not permit a space in the name of a table or, typically, in the name of an attri- bute.) When looking at these tables, note the following:

FIGURE 5-3 Sample Pine Valley Furniture Company data

M05B_HOFF3359_13_GE_C05.indd 248 23/02/19 12:44 PM

5 • Introduction to SQL 249

1. Each order must have a valid customer ID included in the Order_T table. 2. Each item in an order line must have both a valid product ID and a valid order ID

associated with it in the OrderLine_T table. 3. These four tables represent a simplified version of one of the most common sets of

relations in business database systems—the customer order for products.

The remainder of the chapter will illustrate DDL, DML, and DCL commands. Figure 5-4 gives an overview of where the various types of commands are used through- out the database development process. We will use the following notation in the illus- trative SQL commands:

1. All-capitalized words denote commands. Type them exactly as shown, though capitalization may not be required by the RDBMSs. Some RDBMSs will always show data names in output using all capital letters, even if they can be entered in mixed case. (This is the style of Oracle, which is what we follow except where noted.) Tables, columns, named constraints, and so forth are shown in mixed case. Remember that table names follow the “underscore T” convention. SQL commands do not have an “underscore” and so should be easy to distinguish from table and column names. Also, RDBMSs do not like embedded spaces in data names, so multiple-word data names from ERDs are entered with the words together, without spaces between them (as specified in our logical data model con- vention). A consequence is that, for example, a column named QtyOnHand will become QTYONHAND when it is displayed by many RDBMSs. (You can use the ALIAS clause in a SELECT to rename a column name to a more readable value for display.)

2. Lowercase and mixed-case words denote values that must be supplied by the user. 3. Brackets enclose optional syntax. 4. An ellipsis (…) indicates that the accompanying syntactic clause may be repeated

as necessary. 5. Each SQL command ends with a semicolon (;). In interactive mode, when the user

presses Enter, the SQL command will execute. Be alert for alternate conventions, such as typing GO or having to include a continuation symbol such as a hyphen at the end of each line used in the command. The spacing and indentations shown here are included for readability and are not a required part of standard SQL syntax.

DDL Define the database: CREATE tables, indexes, views Establish foreign keys Drop or truncate tables

DML Load the database: INSERT data UPDATE the database Manipulate the database: SELECT

DCL Control the database: GRANT, ADD, REVOKE

Physical Design

Maintenance

Implementation

FIGURE 5-4 DDL, DML, DCL, and the database development process

M05B_HOFF3359_13_GE_C05.indd 249 23/02/19 12:44 PM

250 Part III • Database Implementation and Use

We will start our discussion with coverage of how to create a database, create and modify its structure, and insert and modify data. After that, we will move to a conver- sation on queries, which allow data retrieval with SQL. This is a natural order because it would be difficult to perform queries without a database, tables, and data in them. If, however, you want to review the simpler material on queries first, feel free to jump ahead to the section “Processing Single Tables” and return back here once you have studied that material.

DEFINING A DATABASE IN SQL

Because most systems allocate storage space to contain base tables, views, constraints, indexes, and other database objects when a database is created, you may not be allowed to create a database. Because of this, the privilege of creating databases may be reserved for the database administrator, and you may need to ask to have a database created. Students at a university may be assigned an account that gives access to an existing database, or they may be allowed to create their own database in a limited amount of allocated storage space (sometimes called perm space or table space). In any case, the basic syntax for creating a database is:

CREATE SCHEMA schema_name AUTHORIZATION owner_userid

The database will be owned by the authorized user, although it is possible for other specified users to work with the database or even to transfer ownership of the database. Physical storage of the database is dependent on both the hardware and the software environment and is usually the concern of the system administrator. The amount of control over physical storage that a database administrator is able to exert depends on the RDBMS being used. Little control is possible when using Microsoft Access, but Microsoft SQL Server 2008 and later versions allow for more control of the physical database. A database administrator may exert considerable control over the placement of data, control files, index files, schema ownership, and so forth, thus improving the ability to tune the database to perform more efficiently and to create a secure database environment. You will learn more about these topics in Chapter 8.

Generating SQL Database Definitions

Several SQL DDL CREATE commands are included in SQL:2016 (and each command is followed by the name of the object being created):

CREATE SCHEMA

Used to define the portion of a database that a particular user owns. Schemas are dependent on a catalog and contain schema objects, including base tables and views, domains, constraints, assertions, character sets, collations, and so forth.

CREATE TABLE Defines a new table and its columns. The table may be a base table or a derived table. Tables are dependent on a schema. Derived tables are created by executing a query that uses one or more tables or views.

CREATE VIEW Defines a logical table from one or more tables or views. Views may not be indexed. There are limitations on updating data through a view. Where views can be updated, those changes can be transferred to the underlying base tables originally referenced to create the view.

CREATE INDEX Creates a separate data structure that the database management system can use to identify the location of rows that satisfy a specific condition.

You do not have to be perfect when you create these objects, and they do not have to last forever. Each of these CREATE commands can be reversed by using a DROP command. Thus, DROP TABLE tablename will destroy a table, including its definition, contents, and any constraints, views, or indexes associated with it. Usually, only the table creator may delete the table. DROP SCHEMA or DROP VIEW will also destroy the named schema or view. ALTER TABLE may be used to change the definition of

M05B_HOFF3359_13_GE_C05.indd 250 23/02/19 12:44 PM

5 • Introduction to SQL 251

an existing base table by adding, dropping, or changing a column or by dropping a constraint. Some RDBMSs will not allow you to alter a table in a way that the current data in that table will violate the new definitions (e.g., you cannot create a new con- straint when current data will violate that constraint, or if you change the precision of a numeric column, you may lose the extra precision of more precise existing values).

There are also five other CREATE commands included in the SQL standards; we list them here but do not cover them in this text:

CREATE CHARACTER SET Allows the user to define a character set for text strings and aids in the globalization of SQL by enabling the use of languages other than English. Each character set contains a set of characters, a way to represent each character internally, a data format used for this representation, and a collation, or way of sorting the character set.

CREATE COLLATION A named schema object that specifies the order that a character set will assume. Existing collations may be manipulated to create a new collation.

CREATE TRANSLATION A named set of rules that maps characters from a source character set to a destination character set for translation or conversion purposes.

CREATE ASSERTION A schema object that establishes a CHECK constraint that is violated if the constraint is false.

CREATE DOMAIN A schema object that establishes a domain, or set of valid values, for an attribute. Data type will be specified, and a default value, collation, or other constraint may also be specified, if desired.

Creating Tables

Once the data model is designed and normalized, the columns needed for each table can be defined, using the SQL CREATE TABLE command. The general syntax for CRE- ATE TABLE is shown in Figure 5-5. Here is a series of steps to follow when preparing to create a table:

1. Identify the appropriate data type, including length, precision, and scale, if required, for each attribute.

2. Identify the columns that should not accept null values. Column controls that indicate a column cannot be null are established when a table is created and are enforced for every update of the table when data are entered.

3. Identify the columns that need to be unique. When a column control of UNIQUE is established for a column, the data in that column must have a different value for each row of data within that table (i.e., no duplicate values). Where a column or set of columns is designated as UNIQUE, that column or set of columns is a candidate key, as discussed in Chapter 4. Although each base table may have multiple candi- date keys, only one candidate key may be designated as a PRIMARY KEY. When a column(s) is specified as the PRIMARY KEY, that column(s) is also assumed to be

CREATE TABLE tablename ( {column definition [table constraint] } . , . . [ON COMMIT {DELETE | PRESERVE} ROWS] );

where column definition ::5 column_name

{domain name | datatype [(size)] } [column_constraint_clause. . .] [default value] [collate clause]

and table constraint ::5 [CONSTRAINT constraint_name] Constraint_type [constraint_attributes]

FIGURE 5-5 General syntax of the CREATE TABLE statement used in data definition language

M05B_HOFF3359_13_GE_C05.indd 251 23/02/19 12:44 PM

252 Part III • Database Implementation and Use

NOT NULL, even if NOT NULL is not explicitly stated. UNIQUE and PRIMARY KEY are both column constraints. Note that a table with a composite primary key, OrderLine_T, is defined in Figure 5-6. The OrderLine_PK constraint includes both OrderID and ProductID in the primary key constraint, thus creating a composite key. Additional attributes may be included within the parentheses as needed to create the composite key.

4. Identify all primary key–foreign key connections, as presented in Chapter 4. For- eign keys can be established immediately, as a table is created, or later by altering the table. The parent table in such a parent–child relationship should be created first so that the child table will reference an existing parent table when it is created. The column constraint REFERENCES can be used to enforce referential integrity (e.g., the Order_FK constraint on the Order_T table).

5. Determine values to be inserted in any columns for which a default value is desired. DEFAULT can be used to define a value that is automatically inserted when no value is identified during data entry. In Figure 5-6, the command that creates the Order_T table has defined a default value of SYSDATE (Oracle’s name for the current date) for the OrderDate attribute.

6. Identify any columns for which domain specifications may be stated that are more constrained than those established by data type. Using CHECK as a column con- straint, it may be possible to establish validation rules for values to be inserted into the database. In Figure 5-6, creation of the Product_T table includes a check constraint, which lists the possible values for ProductFinish. Thus, even though an entry of ‘White Maple’ would meet the VARCHAR2 data type constraints, it would be rejected because ‘White Maple’ is not in the checklist.

CREATE TABLE Customer_T (CustomerID NUMBER(11,0) CustomerName VARCHAR2(25) CustomerAddress VARCHAR2(30), CustomerCity VARCHAR2(20), CustomerState CHAR(2), CustomerPostalCode VARCHAR2(9),

CONSTRAINT Customer_PK PRIMARY KEY (CustomerID));

CREATE TABLE Order_T (OrderID NUMBER(11,0) NOT NULL,

NOT NULL, NOT NULL,

OrderDate DATE DEFAULT SYSDATE, CustomerID NUMBER(11,0),

CONSTRAINT Order_PK PRIMARY KEY (OrderID), CONSTRAINT Order_FK FOREIGN KEY (CustomerID) REFERENCES Customer_T(CustomerID));

CREATE TABLE Product_T (ProductID NUMBER(11,0) NOT NULL, ProductDescription VARCHAR2(50), ProductFinish VARCHAR2(20)

CHECK (ProductFinish IN ('Cherry', 'Natural Ash', 'White Ash', 'Red Oak', 'Natural Oak', 'Walnut')),

ProductStandardPrice DECIMAL(6,2), ProductLineID INTEGER,

CONSTRAINT Product_PK PRIMARY KEY (ProductID));

CREATE TABLE OrderLine_T (OrderID NUMBER(11,0) NOT NULL, ProductID INTEGER NOT NULL, OrderedQuantity NUMBER(11,0),

CONSTRAINT OrderLine_PK PRIMARY KEY (OrderID, ProductID), CONSTRAINT OrderLine_FK1 FOREIGN KEY (OrderID) REFERENCES Order_T(OrderID), CONSTRAINT OrderLine_FK2 FOREIGN KEY (ProductID) REFERENCES Product_T(ProductID));

FIGURE 5-6 SQL database definition commands for Pine Valley Furniture Company (Oracle 12c)

M05B_HOFF3359_13_GE_C05.indd 252 23/02/19 12:44 PM

5 • Introduction to SQL 253

7. Create the table and any desired indexes, using the CREATE TABLE and CREATE INDEX statements. (CREATE INDEX is not a part of the SQL:2016 standard because indexing is used to address performance issues, but it is available in most RDBMSs.). Indexing is discussed at a more detailed level in Chapter 8 on physical database design.

Figure 5-6 shows database definition commands using Oracle 12c that include additional column constraints as well as the constraint names given to the primary and foreign keys. For example, the Customer table’s primary key is CustomerID. The primary key constraint is named Customer_PK. In Oracle, for example, once a constraint has been given a meaningful name by the user, a database administrator will find it easy to identify the primary key constraint on the customer table because its name, Customer_ PK, will be the value of the constraint_name column in the DBA_CONSTRAINTS table. If a meaningful constraint name were not assigned, a 16-byte system identifier would be assigned automatically. These identifiers are difficult to read and even more difficult to match up with user-defined constraints. Documentation about how system identifiers are generated is not available, and the method can be changed without notification. Bottom line: Give all constraints names or be prepared for extra work later.

When a foreign key constraint is defined, referential integrity will be enforced. This is good: You want to enforce business rules in the database. Fortunately, you are still allowed to have a null value for the foreign key (signifying a zero cardinality of the rela- tionship) as long as you do not put the NOT NULL clause on the foreign key column. For example, if you try to add an order with an invalid CustomerID value (every order has to be related to some customer, so the minimum cardinality is one next to Customer for the Submits relationship in Figure 2-22), you will receive an error message. Each DBMS vendor generates its own error messages, and these messages may be difficult to inter- pret. Microsoft Access, being intended for both personal and professional use, provides simple error messages in dialog boxes. For example, for a referential integrity viola- tion, Access displays the following error message: “You cannot add or change a record because a related record is required in table Customer_T.” No record will be added to Order_T until that record references an existing customer in the Customer_T table.

Sometimes a user will want to create a table that is similar to one that already exists. SQL:1999 introduced the capability of adding a LIKE clause to the CREATE TABLE statement to allow for the copying of the existing structure of one or more tables into a new table. For example, a table can be used to store data that are questionable until an administrator has an opportunity to review these data. This exception table has the same structure as the verified transaction table, and it allows the database admin- istrator to review and resolve missing or conflicting data before those transactions are appended to the transaction table. SQL:2008 expanded the CREATE . . . LIKE capability by allowing additional information, such as table constraints, from the original table to be easily ported to the new table when it is created. The new table exists indepen- dently of the original table. Inserting a new instance into the original table will have no effect on the new table. However, if the attempt to insert the new instance triggers an exception, the trigger can be written so that the data are stored in the new table to be reviewed later.

Oracle, MySQL, and some other RDBMSs have an interesting “dummy” table that is automatically defined with each database—the Dual table. The Dual table is used to run an SQL command against a system variable. For example,

SELECT Sysdate FROM Dual;

displays the current date, and

SELECT 8 + 4 FROM Dual;

displays the result of this arithmetic expression.

M05B_HOFF3359_13_GE_C05.indd 253 23/02/19 12:44 PM

254 Part III • Database Implementation and Use

Creating Data Integrity Controls

We have seen the syntax that establishes foreign keys in Figure 5-6. To establish referen- tial integrity constraint between two tables with a 1:M relationship in the relational data model, the primary key of the table on the one side will be referenced by a column in the table on the many side of the relationship. Referential integrity means that a value in the matching column on the many side must correspond to a value in the primary key for some row in the table on the one side or be NULL. The SQL REFERENCES clause prevents a foreign key value from being added if it is not already a valid value in the referenced primary key column, but there are other integrity issues.

If a CustomerID value is changed, the connection between that customer and orders placed by that customer will be ruined. The REFERENCES clause prevents mak- ing such a change in the foreign key value but not in the primary key value. This prob- lem could be handled by asserting that primary key values cannot be changed once they are established. In this case, updates to the customer table will be handled in most systems by including an ON UPDATE RESTRICT clause. Then any updates that would delete or change a primary key value will be rejected unless no foreign key references that value in any child table. See Figure 5-7 for the syntax associated with updates.

Another solution is to pass the change through to the child table(s) by using the ON UPDATE CASCADE option. Then, if a customer ID number is changed, that change will flow through (cascade) to the child table, Order_T, and the customer’s ID will also be updated in the Order_T table.

A third solution is to allow the update on Customer_T but to change the involved CustomerID value in the Order_T table to NULL by using the ON UPDATE SET NULL option. In this case, using the SET NULL option would result in losing the connection between the order and the customer, which is not a desired effect. The most flexible option to use would be the CASCADE option. If a customer record were deleted, ON DELETE RESTRICT, CASCADE, or SET NULL would also be available. With DELETE RESTRICT, the customer record could not be deleted unless there were no orders from that customer in the Order_T table. With DELETE CASCADE, removing the customer

CUSTOMER (PK5CustomerID)

ORDER (FK5CustomerID)

Restricted Update: A customer ID can only be deleted if it is not found in ORDER table.

CREATE TABLE CustomerT (CustomerID INTEGER DEFAULT ‘999’ NOT NULL,

NOT NULL,CustomerName VARCHAR(40) . . .

CONSTRAINT Customer_PK PRIMARY KEY (CustomerID), ON UPDATE RESTRICT);

Cascaded Update: Changing a customer ID in the CUSTOMER table will result in that value changing in the ORDER table to match.

. . . ON UPDATE CASCADE);

Set Null Update: When a customer ID is changed, any customer ID in the ORDER table that matches the old customer ID is set to NULL.

. . . ON UPDATE SET NULL);

Set Default Update: When a customer ID is changed, any customer ID in the ORDER tables that matches the old customer ID is set to a predefined default value.

. . . ON UPDATE SET DEFAULT);

FIGURE 5-7 Ensuring data integrity through updates

M05B_HOFF3359_13_GE_C05.indd 254 23/02/19 12:44 PM

5 • Introduction to SQL 255

would remove all associated order records from Order_T. With DELETE SET NULL, the order records for that customer would be set to null before the customer’s record was deleted. With DELETE SET DEFAULT, the order records for that customer would be set to a default value before the customer’s record was deleted. DELETE RESTRICT would probably make the most sense. Not all SQL RDBMSs provide for primary key referen- tial integrity. In that case, update and delete permissions on the primary key column may be revoked.

Changing Table Definitions

Base table definitions may be changed by using ALTER on the column specifications. The ALTER TABLE command can be used to add new columns to an existing table. Existing columns may also be altered. Table constraints may be added or dropped. The ALTER TABLE command may include key words such as ADD, DROP, or ALTER and allow the column’s names, data type, length, and constraints to be changed. Usually, when adding a new column, its status will be NULL so that data that have already been entered in the table can be dealt with. When the new column is created, it is added to all of the instances in the table, and a value of NULL would be the most reasonable.

Syntax:

ALTER TABLE table_name alter_table_action;

Some of the alter_table_actions available are:

ADD [COLUMN] column_definition ALTER [COLUMN] column_name SET DEFAULT default-value ALTER [COLUMN] column_name DROP DEFAULT DROP [COLUMN] column_name [RESTRICT] [CASCADE] ADD table_constraint

Command: To add a customer type column named CustomerType to the Cus- tomer table.

ALTER TABLE CUSTOMER_T ADD CustomerType VARCHAR2 (10) DEFAULT ‘Commercial’;

The ALTER command is invaluable for adapting a database to inevitable modi- fications due to changing requirements, prototyping, evolutionary development, and mistakes. It is also useful when performing a bulk data load into a table that contains a foreign key. The constraint may be temporarily dropped. Later, after the bulk data load has finished, the constraint can be enabled. When the constraint is reenabled, it is pos- sible to generate a log of any records that have referential integrity problems. Rather than have the data load balk each time such a problem occurs during the bulk load, the database administrator can simply review the log and reconcile the few (hopefully few) records that were problematic.

Removing Tables

To remove a table from a database, the owner of the table may use the DROP TABLE command.

Command: To drop a table from a database schema.

DROP TABLE Customer_T;

M05B_HOFF3359_13_GE_C05.indd 255 23/02/19 12:44 PM

256 Part III • Database Implementation and Use

This command will drop the table and save any pending changes to the data- base. To drop a table, you must either own the table or have been granted the DROP ANY TABLE system privilege. Dropping a table will also cause associated indexes and privileges granted to be dropped. The DROP TABLE command can be qualified by the key words RESTRICT or CASCADE. If RESTRICT is specified, the command will fail, and the table will not be dropped if there are any dependent objects, such as views or constraints, that currently reference the table. If CASCADE is specified, all depen- dent objects will also be dropped as the table is dropped. Many RDBMSs allow users to retain the table’s structure but remove all of the data that have been entered in the table with its TRUNCATE TABLE command. Commands for updating and deleting part of the data in a table are covered in the next section.

INSERTING, UPDATING, AND DELETING DATA

Once tables have been created, it is necessary to populate them with data and maintain those data before queries can be written. The SQL command that is used to populate tables is the INSERT command. When entering a value for every column in the table, you can use a command such as the following, which was used to add the first row of data to the Customer_T table for Pine Valley Furniture Company. Notice that the data values must be ordered in the same order as the columns in the table.

Command: To insert a row of data into a table where a value will be inserted for every attribute.

INSERT INTO Customer_T VALUES (001, ‘Contemporary Casuals’, ‘1355 S. Himes Blvd.’, ‘Gainesville’, ‘FL’, ‘32601’);

When data will not be entered into every column in the table, either enter the value NULL for the empty fields or specify those columns to which data are to be added. Here, too, the data values must be in the same order as the columns have been specified in the INSERT command. For example, the following statement was used to insert one row of data into the Product_T table because there was no product line ID for the end table.

Command: To insert a row of data into a table where some attributes will be left null.

INSERT INTO Product_T (ProductID, ProductDescription, ProductFinish, ProductStandardPrice) VALUES (1, ‘End Table’, ‘Cherry’, 175, 8);

In general, the INSERT command places a new row in a table based on values supplied in the statement, copies one or more rows derived from other database data into a table, or extracts data from one table and inserts them into another. If you want to populate a table, CaCustomer_T, that has the same structure as CUSTOMER_T, with only Pine Valley’s California customers, you could use the following INSERT command.

Command: Populating a table by using a subset of another table with the same structure.

INSERT INTO CaCustomer_T SELECT * FROM Customer_T WHERE CustomerState = ‘CA’;

In many cases, we want to generate a unique primary identifier or primary key every time a row is added to a table. Customer identification numbers are a good example of a situation where this capability would be helpful. SQL:2008 added a new feature, identity columns, that removes the previous need to create a procedure to generate a sequence and then apply it to the insertion of data. To take advantage of this,

M05B_HOFF3359_13_GE_C05.indd 256 23/02/19 12:44 PM

5 • Introduction to SQL 257

the CREATE TABLE Customer_T statement displayed in Figure 5-6 may be modified (emphasized by bold print) as follows:

CREATE TABLE Customer_T (CustomerID INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1 MINVALUE 1 MAXVALUE 10000 NOCYCLE), CustomerName VARCHAR2(25) NOT NULL, CustomerAddress VARCHAR2(30), CustomerCity VARCHAR2(20), CustomerState CHAR(2), CustomerPostalCode VARCHAR2(9), CONSTRAINT Customer_PK PRIMARY KEY (CustomerID));

Only one column can be an identity column in a table. When a new customer is added, the CustomerID value will be assigned implicitly if the vendor has implemented identity columns.

Thus, the command that adds a new customer to Customer_T will change from this:

INSERT INTO Customer_T VALUES (001, ‘Contemporary Casuals’, ‘1355 S. Himes Blvd.’, ‘Gainesville’, ‘FL’, ‘32601’);

to this:

INSERT INTO Customer_T VALUES (‘Contemporary Casuals’, ‘1355 S. Himes Blvd.’, ‘Gainesville’, ‘FL’, ‘32601’);

The primary key value, 001, does not need to be entered, and the syntax to accom- plish the automatic sequencing has been simplified in SQL:2008. This capability is available in Oracle starting with version 12c.

Batch Input

The INSERT command is used to enter one row of data at a time or to add multiple rows as the result of a query. Some versions of SQL have a special command or utility for entering multiple rows of data as a batch: the INPUT command. For example, Oracle includes a program, SQL*Loader, which runs from the command line and can be used to load data from a file into the database. SQL Server includes a BULK INSERT command with Transact-SQL for importing data into a table or view. (These powerful and feature rich programs are not within the scope of this text.)

Deleting Database Contents

Rows can be deleted from a database individually or in groups. Suppose Pine Valley Furniture decides that it will no longer deal with customers located in Hawaii. Customer_T rows for customers with addresses in Hawaii could all be eliminated using the next command.

Command: Deleting rows that meet a certain criterion from the Customer table.

DELETE FROM Customer_T WHERE CustomerState = ‘HI’;

M05B_HOFF3359_13_GE_C05.indd 257 23/02/19 12:44 PM

258 Part III • Database Implementation and Use

The simplest form of DELETE eliminates all rows of a table.

Command: Deleting all rows from the Customer table.

DELETE FROM Customer_T;

This form of the command should be used very carefully! Deletion must also be done with care when rows from several relations are

involved. For example, if we delete a Customer_T row, as in the previous query, before deleting associated Order_T rows, we will have a referential integrity violation, and the DELETE command will not execute. (Note: Including the ON DELETE clause with a column definition can mitigate such a problem. Refer to the “Creating Data Integrity Controls” section in this chapter if you’ve forgotten about the ON clause.) SQL will actually eliminate the records selected by a DELETE command. Therefore, always exe- cute a SELECT command first to display the records that would be deleted and visually verify that only the desired rows are included.

Updating Database Contents

To update data in SQL, we must inform the DBMS which relation, columns, and rows are involved. If an incorrect price is entered for the dining table in the Product_T table, the following SQL UPDATE statement would establish the correction.

Command: To modify standard price of product 7 in the Product table to 775.

UPDATE Product_T SET ProductStandardPrice = 775 WHERE ProductID = 7;

The SET command can also change a value to NULL; the syntax is SET colum- name = NULL. As with DELETE, the WHERE clause in an UPDATE command may contain a subquery, but the table being updated may not be referenced in the subquery. Subqueries are discussed in Chapter 6.

Since SQL:2008, the SQL standard has included a new key word, MERGE, that makes updating a table easier. Many database applications need to update master tables with new data. A Purchases_T table, for example, might include rows with data about new products and rows that change the standard price of existing prod- ucts. Updating Product_T can be accomplished by using INSERT to add the new products and UPDATE to modify StandardPrice in an SQL:1999 DBMS. SQL:2008 compliant DBMSs can accomplish the update and the insert in one step by using MERGE:

MERGE INTO Product_T AS PROD USING (SELECT ProductID, ProductDescription, ProductFinish, ProductStandardPrice, ProductLineID FROM Purchases_T) AS PURCH ON (PROD.ProductID = PURCH.ProductID) WHEN MATCHED THEN UPDATE PROD.ProductStandardPrice = PURCH.ProductStandardPrice WHEN NOT MATCHED THEN INSERT (ProductID, ProductDescription, ProductFinish, ProductStandardPrice, ProductLineID) VALUES (PURCH.ProductID, PURCH.ProductDescription, PURCH.ProductFinish, PURCH.ProductStandardPrice, PURCH.ProductLineID);

M05B_HOFF3359_13_GE_C05.indd 258 23/02/19 12:44 PM

5 • Introduction to SQL 259

INTERNAL SCHEMA DEFINITION IN RDBMSs

The internal schema of a relational database can be controlled for processing and storage efficiency. The following are some techniques used for tuning the operational performance of the relational database internal data model:

1. Choosing to index primary and/or secondary keys to increase the speed of row selec- tion, table joining, and row ordering. You can also drop indexes to increase speed of table updating. You will learn more about the selection of indexes in Chapter 8.

2. Selecting file organizations for base tables that match the type of processing activity on those tables (e.g., keeping a table physically sorted by a frequently used reporting sort key).

3. Selecting file organizations for indexes, which are also tables, appropriate to the way the indexes are used and allocating extra space for an index file so that an index can grow without having to be reorganized.

4. Clustering data so that related rows of frequently joined tables are stored close together in secondary storage to minimize retrieval time.

5. Maintaining statistics about tables and their indexes so that the DBMS can find the most efficient ways to perform various database operations.

Not all of these techniques are available in all SQL systems. Indexing and cluster- ing are typically available, however, so we discuss these in the following sections.

Creating Indexes

Indexes are created in most RDBMSs to provide rapid random and sequential access to base-table data. Because the ISO SQL standards do not generally address performance issues, no standard syntax for creating indexes is included. The examples given here use Oracle syntax and give a feel for how indexes are handled in most RDBMSs. Note that although users do not directly refer to indexes when writing any SQL command, the DBMS recognizes which existing indexes would improve query performance. Indexes can usually be created for both primary and secondary keys and both single and concat- enated (multiple-column) keys. In some systems, users can choose between ascending and descending sequences for the keys in an index.

For example, an alphabetical index on CustomerName in the Customer_T table in Oracle is created here.

Command: To create an alphabetical index on customer name in the Customer table.

CREATE INDEX Name_IDX ON Customer_T (CustomerName);

RDBMs usually support several different types of indexes, each of which assists in different kinds of key word searches. For example, in MySQL you can create the following index types: unique (appropriate for primary keys), nonunique (secondary keys), fulltext (used for full-text searches), spatial (used for spatial data types), and hash (which is used for in-memory tables).

Indexes can be created or dropped at any time. If data already exist in the key column(s), index population will automatically occur for the existing data. If an index is defined as UNIQUE (using the syntax CREATE UNIQUE INDEX . . .) and the existing data violate this condition, the index creation will fail. Once an index is created, it will be updated as data are entered, updated, or deleted.

When we no longer need tables, views, or indexes, we use the associated DROP statements. For example, the Name_IDX index from the previous example is dropped here.

Command: To remove the index on the customer name in the Customer table.

DROP INDEX Name_IDX;

M05B_HOFF3359_13_GE_C05.indd 259 23/02/19 12:44 PM

260 Part III • Database Implementation and Use

Although it is possible to index every column in a table, use caution when deciding to create a new index. Each index consumes extra storage space and also requires over- head maintenance time whenever indexed data change value. Together, these costs may noticeably slow retrieval response times and cause annoying delays for online users. A system may use only one index even if several are available for keys in a complex quali- fication. A database designer must know exactly how indexes are used by the particular RDBMS in order to make wise choices about indexing. Oracle includes an explain plan tool that can be used to look at the order in which an SQL statement will be processed and at the indexes that will be used. The output also includes a cost estimate that can be compared with estimates from running the statement with different indexes to deter- mine which is most efficient. You will learn much more about indexes in Chapter 8.

PROCESSING SINGLE TABLES

“Processing single tables” may seem like Friday night at the hottest club in town, but we have something else in mind. Sorry, no dating suggestions (and sorry for the pun).

Four data manipulation language commands are used in SQL. We have talked briefly about three of them (UPDATE, INSERT, and DELETE) and have seen several examples of the fourth, SELECT. Although the UPDATE, INSERT, and DELETE com- mands allow modification of the data in the tables, it is the SELECT command, with its various clauses, that allows users to query the data contained in the tables and ask many different questions or create ad hoc queries. The basic construction of an SQL command is fairly simple and easy to learn. Don’t let that fool you; SQL is a powerful tool that enables users to specify complex data analysis processes. However, because the basic syntax is relatively easy to learn, it is also easy to write SELECT queries that are syn- tactically correct but do not answer the exact question that is intended. Before running queries against a large production database, always test them carefully on a small test set of data to be sure that they are returning the correct results. In addition to checking the query results manually, it is often possible to parse queries into smaller parts, examine the results of these simpler queries, and then recombine them. This will ensure that they act together in the expected way. We begin by exploring SQL queries that affect only a single table. In Chapter 6, we join tables and use queries that require more than one table.

Clauses of the SELECT Statement

Most SQL data retrieval statements include the following three clauses:

SELECT Lists the columns (including expressions involving columns) from base tables, derived tables, or views to be projected into the table that will be the result of the command. (That’s the technical way of saying it lists the data you want to display.)

FROM Identifies the tables, derived tables, or views from which columns can be chosen to appear in the result table and includes the tables, derived tables, or views needed to join tables to process the query.

WHERE Includes the conditions for row selection within the items in the FROM clause and the conditions between tables, derived tables, or views for joining. Because SQL is considered a set manipulation language, the WHERE clause is important in defining the set of rows being manipulated.

The first two clauses are required, and the third is necessary when only certain table rows are to be retrieved or multiple tables are to be joined. (Most examples for this section are drawn from the data shown in Figure 5-3.) For example, we can display product name and quantity on hand from the PRODUCT table for all Pine Valley Furni- ture Company products that have a standard price of less than $275.

Query: Which products have a standard price of less than $275?

SELECT ProductDescription, ProductStandardPrice FROM Product_T WHERE ProductStandardPrice < 275;

M05B_HOFF3359_13_GE_C05.indd 260 23/02/19 12:44 PM

5 • Introduction to SQL 261

Result:

PRODUCTDESCRIPTION PRODUCTSTANDARDPRICE

End Table 175

Computer Desk 250

Coffee Table 200

As stated before, in this text, we show results (except where noted) in the style of Oracle, which means that column headings are in all capital letters. If this is too annoy- ing for users, then the data names should be defined with an underscore between the words rather than run-on words, or you can use an alias (described later in this section) to redefine a column heading for display.

Every SELECT statement returns a result table (a set of rows) when it executes. So, SQL is consistent—tables in, tables out of every query. This becomes important with more complex queries because we can use the result of one query (a table) as part of another query (e.g., we can include a SELECT statement as one of the elements in the FROM clause, creating a derived table, which we illustrate later in this chapter).

Two special key words can be used along with the list of columns to display: DISTINCT and *. If the user does not wish to see duplicate rows in the result, SELECT DISTINCT may be used. In the preceding example, if the other computer desk carried by Pine Valley Furniture also had a cost of $250, the results of the query would have had duplicate rows. SELECT DISTINCT ProductDescription would display a result table without the duplicate rows. SELECT *, where * is used as a wildcard to indicate all col- umns, displays all columns from all the items in the FROM clause.

Also, note that the clauses of a SELECT statement must be kept in order, or syntax error messages will occur and the query will not execute. It may also be necessary to qual- ify the names of the database objects according to the SQL version being used. If there is any ambiguity in an SQL command, you must indicate exactly from which table, derived table, or view the requested data are to come. For example, in Figure 5-3 CustomerID is a column in both Customer_T and Order_T. When you own the database being used (i.e., the user created the tables) and you want CustomerID to come from Customer_T, specify it by asking for Customer_T.CustomerID. If you want CustomerID to come from Order_T, then ask for Order_T.CustomerID. Even if you don’t care which table CustomerID comes from, it must be specified because SQL can’t resolve the ambiguity without user direction. When you are allowed to use data created by someone else, you must also specify the owner of the table by adding the owner’s user ID. Now a request to SELECT the CustomerID from Customer_T may look like this: <OWNER_ID>.Customer_T.CustomerID. The examples in this text assume that the reader owns the tables or views being used, as the SELECT statements will be easier to read without the qualifiers. Qualifiers will be included where necessary and may always be included in statements if desired. Problems may occur when qualifiers are left out, but no problems will occur when they are included.

If typing the qualifiers and column names is wearisome (computer keyboards aren’t, yet, built to accommodate the two-thumb cellphone texting technique) or if the column names will not be meaningful to those who are reading the reports, establish aliases for data names that will then be used for the rest of the query. Although the SQL standard does not include aliases or synonyms, they are widely implemented and aid in readability and simplicity in query construction.

Query: What is the address of the customer named Home Furnishings? Use an alias, Name, for the customer name. (The AS clauses are bolded for emphasis only.)

SELECT CUST.CustomerName AS Name, CUST.CustomerAddress FROM Customer_T AS Cust WHERE Name = ‘Home Furnishings’;

This retrieval statement will give the following result in many versions of SQL but not in all of them. In Oracle’s SQL*Plus, the alias for the column cannot be used in the rest

M05B_HOFF3359_13_GE_C05.indd 261 23/02/19 12:44 PM

262 Part III • Database Implementation and Use

of the SELECT statement, except in a HAVING clause, so in order for the query to run, CustomerName would have to be used in the last line rather than Name. Notice that the column header prints as Name rather than CustomerName and that the table alias may be used in the SELECT clause even though it is not defined until the FROM clause.

Result:

NAME CUSTOMERADDRESS

Home Furnishings 1900 Allard Ave.

You’ve likely concluded that SQL generates pretty plain output. Using an alias is a good way to make column headings more readable. (Aliases also have other uses, which we’ll address later.) Many RDBMSs have other proprietary SQL clauses to improve the display of data. For example, Oracle has the COLUMN clause of the SELECT statement, which can be used to change the text for the column heading, change alignment of the column head- ing, reformat the column value, or control wrapping of data in a column, among other properties. You may want to investigate such capabilities for the RDBMS you are using.

When you use the SELECT clause to pick out the columns for a result table, the columns can be rearranged so that they will be ordered differently in the result table than in the original table. In fact, they will be displayed in the same order as they are included in the SELECT statement. Look back at Product_T in Figure 5-3 to see the different ordering of the base table from the result table for this query.

Query: List the unit price, product name, and product ID for all products in the Product table.

SELECT ProductStandardPrice, ProductDescription, ProductID FROM Product_T;

Result:

PRODUCTSTANDARDPRICE PRODUCTDESCRIPTION PRODUCTID

175 End Table 1

200 Coffee Table 2

375 Computer Desk 3

650 Entertainment Center 4

325 Writer’s Desk 5

750 8-Drawer Desk 6

800 Dining Table 7

250 Computer Desk 8

Using Expressions

The basic SELECT . . . FROM . . . WHERE clauses can be used with a single table in a number of ways. You can create expressions, which are mathematical manipulations of the data in the table, or take advantage of stored functions, such as SUM or AVG, to manipulate the chosen rows of data from the table. Mathematical manipulations can be constructed by using the + for addition, − for subtraction, * for multiplication, and / for division. These operators can be used with any numeric columns. Expressions are computed for each row of the result table, such as displaying the difference between the standard price and unit cost of a product, or they can involve computations of columns and functions, such as standard price of a product multiplied by the amount of that product sold on a particular order (which would require summing OrderedQuantities). Some systems also have an operand called modulo, usually indicated by %. A modulo is the integer remainder that results from dividing two integers. For example, 14 % 4 is 2 because 14/4 is 3, with a remainder of 2. The SQL standard supports year-month and

M05B_HOFF3359_13_GE_C05.indd 262 23/02/19 12:44 PM

5 • Introduction to SQL 263

day-time intervals, which makes it possible to perform date and time arithmetic (e.g., to calculate someone’s age from today’s date and a person’s birthday).

Perhaps you would like to know the current standard price of each product and its future price if all prices were increased by 10 percent. Here are the query and the results.

Query: What are the standard price and standard price if increased by 10 percent for every product?

SELECT ProductID, ProductStandardPrice, ProductStandardPrice*1.1 AS Plus10Percent FROM Product_T;

Result:

PRODUCTID PRODUCTSTANDARDPRICE PLUS10PERCENT

2 200.0000 220.00000

3 375.0000 412.50000

1 175.0000 192.50000

8 250.0000 275.00000

7 800.0000 880.00000

5 325.0000 357.50000

4 650.0000 715.00000

6 750.0000 825.00000

The precedence rules for the order in which complex expressions are evaluated are the same as those used in other programming languages and in algebra. Expressions in parentheses will be calculated first. When parentheses do not establish order, multiplication and division will be completed first, from left to right, followed by addition and subtraction, also left to right. To avoid confusion, use parentheses to establish order. Where parentheses are nested, the innermost calculations will be completed first.

Using Functions

Standard SQL identifies a wide variety of mathematical, string and date manipulation, and other functions. We will illustrate some of the mathematical functions in this section. You will want to investigate what functions are available with the DBMS you are using, some of which may be proprietary to that DBMS. The standard functions include the following:

Mathematical MIN, MAX, COUNT, SUM, ROUND (to round up a number to a specific number of decimal places), TRUNC (to truncate insignifi- cant digits), and MOD (for modular arithmetic)

String LOWER (to change to all lowercase), UPPER (to change to all capi- tal letters), INITCAP (to change to only an initial capital letter), CONCAT (to concatenate), SUBSTR (to isolate certain character positions), and COALESCE (finding the first not NULL values in a list of columns)

Date NEXT_DAY (to compute the next date in sequence), ADD_ MONTHS (to compute a date a given number of months before or after a given date), and MONTHS_BETWEEN (to compute the number of months between specified dates)

Analytical TOP (find the top n values in a set, e.g., the top 5 customers by total annual sales)

M05B_HOFF3359_13_GE_C05.indd 263 23/02/19 12:44 PM

264 Part III • Database Implementation and Use

Perhaps you want to know the average standard price of all inventory items. To get the overall average value, use the AVG stored function. We can name the resulting expression with an alias, AveragePrice. Here are the query and the results.

Query: What is the average standard price for all products in inventory?

SELECT AVG (ProductStandardPrice) AS AveragePrice FROM Product_T;

Result:

AVERAGEPRICE 440.625

SQL:1999 stored functions include ANY, AVG, COUNT, EVERY, GROUPING, MAX, MIN, SOME, and SUM. SQL:2008 added LN, EXP, POWER, SQRT, FLOOR, CEILING, and WIDTH_BUCKET. New functions tend to be added with each new SQL standard, and more functions were added in SQL:2003 and SQL:2008, many of which are for advanced analytical processing of data (e.g., calculating moving averages and statistical sampling of data). As seen in the above example, functions such as COUNT, MIN, MAX, SUM, and AVG of specified columns in the column list of a SELECT command may be used to specify that the resulting answer table is to contain aggregated data instead of row-level data. Using any of these aggregate functions will give a one-row answer.

Query: How many different items were ordered on order number 1004?

SELECT COUNT (*) FROM OrderLine_T WHERE OrderID = 1004;

Result:

COUNT (*) 2

It seems that it would be simple enough to list order number 1004 by changing the query.

Query: How many different items were ordered on order number 1004, and what are they?

SELECT ProductID, COUNT (*) FROM OrderLine_T WHERE OrderID = 1004;

In Oracle, here is the result.

Result:

ERROR at line 1: ORA-00937: not a single-group group function

And in Microsoft SQL Server, the result is as follows.

Result:

Column ‘OrderLine_T.ProductID’ is invalid in the select list because it is not contained in an Aggregate function and there is no GROUP BY clause.

M05B_HOFF3359_13_GE_C05.indd 264 23/02/19 12:44 PM

5 • Introduction to SQL 265

The problem is that ProductID returns two values, 6 and 8, for the two rows selected, whereas COUNT returns one aggregate value, 2, for the set of rows with ID  =  1004. In most implementations, SQL cannot return both a row value and a set value; users must run two separate queries, one that returns row information and one that returns set information.

A similar issue arises if we try to find the difference between the standard price of each product and the overall average standard price (which we calculated above). You might think the query would be:

SELECT ProductStandardPrice – AVG(ProductStandardPrice) FROM Product_T;

However, again we have mixed a column value with an aggregate, which will cause an error. Remember that the FROM list can contain tables, derived tables, and views. One approach to developing a correct query is to make the aggregate the result of a derived table, as we do in the following sample query.

Query: Display for each product the difference between its standard price and the overall average standard price of all products.

SELECT ProductStandardPrice – PriceAvg AS Difference FROM Product_T, (SELECT AVG(ProductStandardPrice) AS PriceAvg FROM Product_T);

Result:

DIFFERENCE −240.63 −65.63 −265.63 −190.63 359.38 −115.63 209.38 309.38

Also, it is easy to confuse the functions COUNT (*) and COUNT. The function COUNT (*), used in the previous query, counts all rows selected by a query, regardless of whether any of the rows contain null values. COUNT tallies only rows that contain values; it ignores all null values.

SUM and AVG can only be used with numeric columns. COUNT, COUNT (*), MIN, and MAX can be used with any data type. Using MIN on a text column, for example, will find the lowest value in the column, the one whose first column is clos- est to the beginning of the alphabet. SQL implementations interpret the order of the alphabet differently. For example, some systems may start with A–Z, then a–z, and then 0–9 and special characters. Others treat upper- and lowercase letters as being equivalent. Still others start with some special characters, then proceed to numbers, letters, and other special characters. Here is the query to ask for the first ProductName in Product_T alphabetically, which was done using the AMERICAN character set in Oracle 12c.

Query: Alphabetically, what is the first product name in the Product table?

SELECT MIN (ProductDescription) FROM Product_T;

M05B_HOFF3359_13_GE_C05.indd 265 23/02/19 12:44 PM

266 Part III • Database Implementation and Use

It gives the following result, which demonstrates that numbers are sorted before letters in this character set. [Note: The following result is from Oracle. Microsoft SQL Server returns the same result but labels the column (No column name) in SQL Query Analyzer, unless the query specifies a name for the result.]

Result:

MIN(PRODUCTDESCRIPTION) 8-Drawer Desk

Using Wildcards

The use of the asterisk (*) as a wildcard in a SELECT statement has been previously shown. Wildcards may also be used in the WHERE clause when an exact match is not possible. Here, the key word LIKE is paired with wildcard characters and usually a string containing the characters that are known to be desired matches. The wildcard character % is used to represent any collection of characters. Thus, using LIKE ‘%Desk’ when searching ProductDescription will find all different types of desks carried by Pine Valley Furniture Company. The underscore (_) is used as a wildcard character to represent exactly one character rather than any collection of characters. Thus, using LIKE ‘_-drawer’ when searching ProductName will find any products with specified drawers, such as 3-, 5-, or 8-drawer dressers.

Using Comparison Operators

With the exception of the very first SQL example in this section, we have used the equality comparison operator in our WHERE clauses. The first example used the greater (less) than operator. The most common comparison operators for SQL implementations are listed in Table 5-3. (Different SQL DBMSs can use different comparison operators.) You are used to thinking about using comparison operators with numeric data, but you can also use them with character data and dates in SQL. The query shown here asks for all orders placed after 10/24/2018.

Query: Which orders have been placed since 10/24/2018?

SELECT OrderID, OrderDate FROM Order_T WHERE OrderDate > ‘24-OCT-2018’;

Notice that the date is enclosed in single quotes and that the format of the date is different from that shown in Figure 5-3, which was taken from Microsoft Access. The query was run in the Oracle environment. You should check the reference manual for the SQL language you are using to see how dates are to be formatted in queries and for data input.

Result:

ORDERID ORDERDATE

1007 27-OCT-18

1008 30-OCT-18

1009 05-NOV-18

1010 05-NOV-18

Query: What furniture does Pine Valley carry that isn’t made of cherry?

TABLE 5-3 Comparison Operators in SQL

Operator Meaning

= Equal to

> Greater than

>= Greater than or equal to

< Less than

<= Less than or equal to

<> Not equal to

!= Not equal to

M05B_HOFF3359_13_GE_C05.indd 266 23/02/19 12:44 PM

5 • Introduction to SQL 267

SELECT ProductDescription, ProductFinish FROM Product_T WHERE ProductFinish != ‘Cherry’;

Result:

PRODUCTDESCRIPTION PRODUCTFINISH

Coffee Table Natural Ash

Computer Desk Natural Ash

Entertainment Center Natural Maple

8-Drawer Desk White Ash

Dining Table Natural Ash

Computer Desk Walnut

Using Null Values

Columns that are defined without the NOT NULL clause may be empty, and this may be a significant fact for an organization. You will recall that a null value means that a column is missing a value; the value is not zero or blank or any special code—there sim- ply is no value. We have already seen that functions may produce different results when null values are present than when a column has a value of zero in all qualified rows. It is not uncommon, then, to first explore whether there are null values before deciding how to write other commands, or it may be that you simply want to see data about table rows where there are missing values. For example, before undertaking a postal mail advertising campaign, you might want to pose the following query.

Query: Display all customers for whom we do not know their postal code.

SELECT * FROM Customer_T WHERE CustomerPostalCode IS NULL;

Result:

Fortunately, this query returns 0 rows in the result in our sample database, so we can mail advertisements to all our customers because we know their postal codes. The term IS NOT NULL returns results for rows where the qualified column has a non-null value. This allows us to deal with rows that have values in a critical column, ignoring other rows.

Using Boolean Operators

You probably have taken a course or part of a course on finite or discrete mathematics— logic, Venn diagrams, and set theory, oh my! Remember we said that SQL is a set-oriented language, so there are many opportunities to use what you learned in finite math to write complex SQL queries. Some complex questions can be answered by adjusting the WHERE clause further. The Boolean or logical operators AND, OR, and NOT can be used to good purpose:

AND Joins two or more conditions and returns results only when all conditions are true.

OR Joins two or more conditions and returns results when any conditions are true.

NOT Negates an expression.

If multiple Boolean operators are used in an SQL statement, NOT is evaluated first, then AND, then OR. For example, consider the following query.

M05B_HOFF3359_13_GE_C05.indd 267 23/02/19 12:44 PM

268 Part III • Database Implementation and Use

Query A: List product name, finish, and standard price for all desks and all tables that cost more than $300 in the Product table.

SELECT ProductDescription, ProductFinish, ProductStandardPrice FROM Product_T WHERE ProductDescription LIKE ‘%Desk’ OR ProductDescription LIKE ‘%Table’ AND ProductStandardPrice > 300;

Result:

PRODUCTDESCRIPTION PRODUCTFINISH PRODUCTSTANDARDPRICE

Computer Desk Natural Ash 375

Writer’s Desk Cherry 325

8-Drawer Desk White Ash 750

Dining Table Natural Ash 800

Computer Desk Walnut 250

All of the desks are listed, even the computer desk that costs less than $300. Only one table is listed; the less expensive ones that cost less than $300 are not included. With this query (illustrated in Figure 5-8), the AND will be processed first, returning all tables with a standard price greater than $300. Then the part of the query before the OR is processed, returning all desks, regardless of cost. Finally the results of the two parts of the query are combined (OR), with the final result of all desks along with all tables with standard price greater than $300.

If we had wanted to return only desks and tables costing more than $300, we should have put parentheses after the WHERE and before the AND, as shown in Query B below. Figure 5-9 shows the difference in processing caused by the judicious

OR

Products with Standard Price >

$300

All Tables

Step 1 Process AND

WHERE ProductDescription

LIKE ‘% Table’ AND

StandardPrice >$300

Step 3 Final result is the union (OR) of these two

areas

AND All Desks

Step 2 Process OR

WHERE ProductDescription

LIKE ‘% Desk’

FIGURE 5-8 Boolean query A without the use of parentheses

M05B_HOFF3359_13_GE_C05.indd 268 23/02/19 12:44 PM

5 • Introduction to SQL 269

use of parentheses in the query. The result is all desks and tables with a standard price of more than $300, indicated by the filled area with the darker horizontal lines. The wal- nut computer desk has a standard price of $250 and is not included.

Query B: List product name, finish, and standard price for all desks and tables in the PRODUCT table that cost more than $300.

SELECT ProductDescription, ProductFinish, ProductStandardPrice FROM Product_T; WHERE (ProductDescription LIKE ‘%Desk’ OR ProductDescription LIKE ‘%Table’) AND ProductStandardPrice > 300;

The results follow. Only products with unit price greater than $300 are included.

Result:

PRODUCTDESCRIPTION PRODUCTFINISH PRODUCTSTANDARDPRICE

Computer Desk Natural Ash 375

Writer’s Desk Cherry 325

8-Drawer Desk White Ash 750

Dining Table Natural Ash 800

This example illustrates why SQL is considered a set-oriented, not a record-oriented, language. (C, Java, and Cobol are examples of record-oriented languages because they must process one record, or row, of a table at a time.) To answer this query, SQL will find the set of rows that are Desk products, and then it will union (i.e., merge) that set with the set of rows that are Table products. Finally, it will intersect (i.e., find common rows) the resultant set from this union with the set of rows that have a standard price

OR

Products with StandardPrice > $300

Step 2 Process AND

Step 1 Process OR

All Desks

A N

D

WHERE ProductDescription LIKE

‘%Desk’ OR ProductDescription LIKE

‘%Table’

WHERE Result of first

process AND

StandardPrice >$300

WHERE ProductDescription LIKE

‘%Desk’ OR ProductDescription LIKE

‘%Table’

All Tables

AND

FIGURE 5-9 Boolean query B with the use of parentheses

M05B_HOFF3359_13_GE_C05.indd 269 23/02/19 12:44 PM

270 Part III • Database Implementation and Use

above $300. If indexes can be used, the work is done even faster because SQL will create sets of index entries that satisfy each qualification and do the set manipulation on those index entry sets, each of which takes up less space and can be manipulated much more quickly. You will see in Chapter 6 even more dramatic ways in which the set-oriented nature of SQL works for more complex queries involving multiple tables.

Using Ranges for Qualification

The comparison operators < and > are used to establish a range of values. The key words BETWEEN and NOT BETWEEN can also be used. For example, to find products with a standard price between $200 and $300, the following query could be used.

Query: Which products in the Product table have a standard price between $200 and $300?

SELECT ProductDescription, ProductStandardPrice FROM Product_T WHERE ProductStandardPrice > = 200 AND ProductStandardPrice < = 300;

Result:

PRODUCTDESCRIPTION PRODUCTSTANDARDPRICE

Coffee Table 200

Computer Desk 250

The same result will be returned by the following query.

Query: Which products in the PRODUCT table have a standard price between $200 and $300?

SELECT ProductDescription, ProductStandardPrice FROM Product_T WHERE ProductStandardPrice BETWEEN 200 AND 300;

Result: Same as previous query.

Adding NOT before BETWEEN in this query will return all the other products in Product_T because their prices are less than $200 or more than $300.

Using Distinct Values

Sometimes when returning rows that don’t include the primary key, duplicate rows will be returned. For example, look at this query and the results that it returns.

Query: What order numbers are included in the OrderLine table?

SELECT OrderID FROM OrderLine_T;

Eighteen rows are returned, and many of them are duplicates because many orders were for multiple items.

Result:

ORDERID

1001

1001

1001

M05B_HOFF3359_13_GE_C05.indd 270 23/02/19 12:44 PM

5 • Introduction to SQL 271

ORDERID

1002

1003

1004

1004

1005

1006

1006

1006

1007

1007

1008

1008

1009

1009

1010

18 rows selected.

Do we really need the redundant OrderIDs in this result? If we add the key word DISTINCT, then only 1 occurrence of each OrderID will be returned, 1 for each of the 10 orders represented in the table.

Query: What are the distinct order numbers included in the OrderLine table?

SELECT DISTINCT OrderID FROM OrderLine_T;

Result:

ORDERID

1001

1002

1003

1004

1005

1006

1007

1008

1009

1010

10 rows selected.

DISTINCT and its counterpart, ALL, can be used only once in a SELECT statement. It comes after SELECT and before any columns or expressions are listed. If a SELECT statement projects more than one column, only rows that are identical for every col- umn will be eliminated. Thus, if the previous statement also includes OrderedQuantity, 14 rows are returned because there are now only 4 duplicate rows rather than 8. For example, both items ordered on OrderID 1004 were for 2 items, so the second pairing of 1004 and 2 will be eliminated.

Query: What are the unique combinations of order number and order quantity included in the OrderLine table?

M05B_HOFF3359_13_GE_C05.indd 271 23/02/19 12:44 PM

272 Part III • Database Implementation and Use

SELECT DISTINCT OrderID, OrderedQuantity FROM OrderLine_T;

Result:

ORDERID ORDEREDQUANTITY

1001 1

1001 2

1002 5

1003 3

1004 2

1005 4

1006 1

1006 2

1007 2

1007 3

1008 3

1009 2

1009 3

1010 10

14 rows selected.

Using IN and NOT IN with Lists

To match a list of values, consider using IN.

Query: List all customers who live in warmer states.

SELECT CustomerName, CustomerCity, CustomerState FROM Customer_T WHERE CustomerState IN (‘FL’, ‘TX’, ‘CA’, ‘HI’);

Result:

CUSTOMERNAME CUSTOMERCITY CUSTOMERSTATE

Contemporary Casuals Gainesville FL

Value Furniture Plano TX

Impressions Sacramento CA

California Classics Santa Clara CA

M and H Casual Furniture Clearwater FL

Seminole Interiors Seminole FL

Kaneohe Homes Kaneohe HI

7 rows selected.

IN is particularly useful in SQL statements that use subqueries, which will be cov- ered in Chapter 6. The use of IN is also very consistent with the set nature of SQL. Very simply, the list (set of values) inside the parentheses after IN can be literals, as illustrated here, or can be a SELECT statement with a single result column, the result of which will be plugged in as the set of values for comparison. In fact, some SQL programmers always use IN, even when the set in parentheses after IN includes only one item. Similarly, any “table” of the FROM clause can be itself a derived table defined by including a SELECT statement in parentheses in the FROM clause (as we saw earlier, with the query about the difference between the standard price of each product and the average standard price of

M05B_HOFF3359_13_GE_C05.indd 272 23/02/19 12:44 PM

5 • Introduction to SQL 273

all products). The ability to include a SELECT statement anyplace within SQL where a set is involved is a very powerful and useful feature of SQL, and, of course, totally consistent with SQL being a set-oriented language, as illustrated in Figures 5-8 and 5-9.

Sorting Results: The ORDER BY Clause

Looking at the preceding results, it may seem that it would make more sense to list the California customers, followed by the Floridians, Hawaiians, and Texans. That brings us to the other three basic parts of the SQL statement:

ORDER BY Sorts the final results rows in ascending or descending order.

GROUP BY Groups rows in an intermediate results table where the values in those rows are the same for one or more columns.

HAVING Can only be used following a GROUP BY and acts as a secondary WHERE clause, returning only those groups that meet a specified condition.

So, we can order the customers by adding an ORDER BY clause.

Query: List customer, city, and state for all customers in the Customer table whose address is Florida, Texas, California, or Hawaii. List the customers alpha- betically by state and alphabetically by customer within each state.

SELECT CustomerName, CustomerCity, CustomerState FROM Customer_T WHERE CustomerState IN (‘FL’, ‘TX’, ‘CA’, ‘HI’) ORDER BY CustomerState, CustomerName;

Now the results are easier to read.

Result:

CUSTOMERNAME CUSTOMERCITY CUSTOMERSTATE

California Classics Santa Clara CA

Impressions Sacramento CA

Contemporary Casuals Gainesville FL

M and H Casual Furniture Clearwater FL

Seminole Interiors Seminole FL

Kaneohe Homes Kaneohe HI

Value Furniture Plano TX

7 rows selected.

Notice that all customers from each state are listed together, and within each state, customer names are alphabetized. The sorting order is determined by the order in which the columns are listed in the ORDER BY clause; in this case, states were alphabet- ized first, then customer names. If sorting from high to low, use DESC as a key word, placed after the column used to sort. Instead of typing the column names in the ORDER BY clause, you can use their column positions in the select list; for example, in the pre- ceding query, we could have written the clause as

ORDER BY 3, 1;

For cases in which there are many rows in the result table but you need to see only a few of them, many SQL systems (including MySQL) support a LIMIT clause, such as the fol- lowing, which would show only the first five rows of the result:

ORDER BY 3, 1 LIMIT 5;

M05B_HOFF3359_13_GE_C05.indd 273 23/02/19 12:44 PM

274 Part III • Database Implementation and Use

The following would show five rows after skipping the first 30 rows:

ORDER BY 3, 1 LIMIT 30, 5;

Oracle 12c has added a similar capability to Oracle with a somewhat different syn- tax. In Oracle, the same outcome could be achieved with the following clauses:

ORDER BY 3, 1 OFFSET 30 ROWS FETCH 5 ROWS ONLY;

How are NULLs sorted? Null values may be placed first or last, before or after columns that have values. Where the NULLs will be placed will depend upon the SQL implementation.

Categorizing Results: The GROUP BY Clause

GROUP BY is particularly useful when paired with aggregate functions, such as SUM or COUNT. GROUP BY divides a table into subsets (by groups); then an aggregate function can be used to provide summary information for that group. The single value returned by the previous aggregate function examples is called a scalar aggregate. When aggre- gate functions are used in a GROUP BY clause and several values are returned, they are called vector aggregates.

Query: Count the number of customers with addresses in each state to which we ship.

SELECT CustomerState, COUNT (CustomerState) FROM Customer_T GROUP BY CustomerState ORDER BY CustomerState;

Result:

CUSTOMERSTATE COUNT(CUSTOMERSTATE)

CA 2

CO 1

FL 3

HI 1

MI 1

NJ 2

NY 1

PA 1

TX 1

UT 1

WA 1

11 rows selected.

It is also possible to nest groups within groups; the same logic is used as when sorting multiple items.

Query: Count the number of customers with addresses in each city to which we ship. List the cities by state.

SELECT CustomerState, CustomerCity, COUNT (CustomerCity) FROM Customer_T GROUP BY CustomerState, CustomerCity ORDER BY CustomerState, CustomerCity;

Scalar aggregate

A single value returned from an SQL query that includes an aggregate function.

Vector aggregate

Multiple values returned from an SQL query that includes an aggregate function.

M05B_HOFF3359_13_GE_C05.indd 274 23/02/19 12:44 PM

5 • Introduction to SQL 275

Although the GROUP BY clause seems straightforward, it can produce unex- pected results if the logic of the clause is forgotten (and this is a common “gotcha” for novice SQL coders). When a GROUP BY is included, the columns allowed to be specified in the SELECT clause are limited. Only a column with a single value for each group can be included. In the previous query, each group is identified by the combi- nation of a city and its state. The SELECT statement includes both the city and state columns. This works because each combination of city and state is one COUNT value. But if the SELECT clause of the first query in this section had also included city, that statement would fail because the GROUP BY is only by state. Because a state can have more than one city, the requirement that each value in the SELECT clause have only one value in the GROUP BY group is not met, and SQL will not be able to present the city information so that it makes sense. If you write queries using the following rule, your queries will work: Each column referenced in the SELECT statement must be referenced in the GROUP BY clause, unless the column is an argument for an aggregate function included in the SELECT clause.

Qualifying Results by Categories: The HAVING Clause

The HAVING clause acts like a WHERE clause, but it identifies groups, rather than rows, that meet a criterion. Therefore, you will usually see a HAVING clause following a GROUP BY clause.

Query: Find only states with more than one customer.

SELECT CustomerState, COUNT (CustomerState) FROM Customer_T GROUP BY CustomerState HAVING COUNT (CustomerState) > 1;

This query returns a result that has removed all states (groups) with one customer. Remember that using WHERE here would not work because WHERE doesn’t allow aggregates; further, WHERE qualifies a set of rows, whereas HAVING qualifies a set of groups. As with WHERE, the HAVING qualification can be compared to the result of a SELECT statement, which computes the value for comparison (i.e., a set with only one value is still a set).

Result:

CUSTOMERSTATE COUNT(CUSTOMERSTATE)

CA 2

FL 3

NJ 2

To include more than one condition in the HAVING clause, use AND, OR, and NOT just as in the WHERE clause. In summary, here is one last command that includes all six clauses; remember that they must be used in this order.

Query: List, in alphabetical order, the product finish and the average standard price for each finish for selected finishes having an average standard price less than 750.

SELECT ProductFinish, AVG (ProductStandardPrice) FROM Product_T WHERE ProductFinish IN (‘Cherry’, ‘Natural Ash’, ‘Natural Maple’,

‘White Ash’) GROUP BY ProductFinish HAVING AVG (ProductStandardPrice) < 750 ORDER BY ProductFinish;

M05B_HOFF3359_13_GE_C05.indd 275 23/02/19 12:44 PM

276 Part III • Database Implementation and Use

Result:

PRODUCTFINISH AVG(PRODUCTSTANDARDPRICE)

Cherry 250

Natural Ash 458.333333

Natural Maple 650

Figure 5-10 shows the order in which SQL processes the clauses of a statement. Arrows indicate the paths that may be followed. Remember, only the SELECT and FROM clauses are mandatory. Notice that the processing order is different from the order of the syntax used to create the statement. As each clause is processed, an intermediate results table is produced that will be used for the next clause. Users do not see the intermediate results tables; they see only the final results. A query can be debugged by remembering the order shown in Figure 5-10. Take out the optional clauses and then add them back in one at a time in the order in which they will be processed. In this way, intermediate results can be seen and problems often can be spotted.

FROM Identifies

involved tables

WHERE Finds all rows meeting stated

condition(s)

GROUP BY Organizes rows

according to values in stated column(s)

HAVING Finds all groups meeting stated

condition(s)

SELECT Identifies columns

ORDER BY Sorts rows

results

FIGURE 5-10 SQL statement processing order (based on van der Lans, 2006, p. 100)

M05B_HOFF3359_13_GE_C05.indd 276 23/02/19 12:44 PM

5 • Introduction to SQL 277

Summary This chapter has introduced the SQL language for rela- tional database definition (DDL), manipulation (DML), and control (DCL) languages, commonly used to define and query relational database management systems (RDBMSs). This standard has been criticized as having many flaws. In reaction to these criticisms and to increase the power of the language, extensions are constantly under review by the ANSI X3H2 committee and Interna- tional Committee for Information Technology Standards (INCITS). The current generally implemented standard is SQL:1999, but later versions, including SQL:2008 and SQL:2016, are being implemented by some RDBMSs.

The establishment of SQL standards and confor- mance certification tests has contributed to relational systems being the dominant form of new database devel- opment. Benefits of the SQL standards include reduced training costs, improved productivity, application por- tability and longevity, reduced dependence on single vendors, and improved cross-system communication. SQL has become so dominant as database query and data manipulation language that even the new competi- tors of the relational model are implementing SQL-like interfaces.

The SQL environment includes an instance of an SQL DBMS along with accessible databases and associated users and programs. Each database is included in a cata- log and has a schema that describes the database objects. Information contained in the catalog is maintained by the DBMS itself rather than by the users of the DBMS.

The SQL DDL commands 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. The SQL DML commands are used to load, update, and query the data- base through use of the SELECT, INSERT, UPDATE, and DELETE commands. DCL commands are used to estab- lish user access to the database.

SQL commands may directly affect the base tables, which contain the raw data, or they may affect a database view that has been created. Changes and updates made to views may or may not be passed on to the base tables. The basic syntax of an SQL SELECT statement contains the following key words: SELECT, FROM, WHERE, ORDER BY, GROUP BY, and HAVING. SELECT deter- mines which attributes will be displayed in the query results table. FROM determines which tables or views will be used in the query. WHERE sets the criteria of the query, including any joins of multiple tables that are necessary. ORDER BY determines the order in which the results will be displayed. GROUP BY is used to categorize results and may return either scalar aggregates or vector aggregates. HAVING qualifies results by categories.

Understanding the basic SQL syntax presented in this chapter should enable the reader to start using SQL effectively and to build a deeper understanding of the possibilities for more complex querying with continued practice. Multi-table queries and advanced SQL topics are covered in Chapter 6.

Chapter Review

Key Terms

Catalog 246 Data control language

(DCL) 246

Data definition language (DDL) 246

Data manipulation language (DML) 246

Relational DBMS (RDBMS) 245

Scalar aggregate 274

Schema 246 Vector aggregate 274

Review Questions 5-1. Define each of the following terms:

a. data definition language b. data manipulation language c. referential integrity constraint d. relational DBMS (RDBMS) e. schema

5-2. Match the following terms to the appropriate definitions:            referential

integrity constraint

           SQL:2016            null value            scalar

aggregate

           vector aggregate

           catalog            schema            host

language

a. list of values b. description of a database c. missing or nonexistent value d. descriptions of database objects

of a database e. programming language in which

SQL commands are embedded

f. established in relational data models by use of foreign keys

g. current standard for relational query and definition language

h. single value

5-3. Contrast the following terms: a. scalar aggregate; vector aggregate b. DDL; DML c. catalog; schema

5-4. What are SQL-92, SQL:1999, SQL:2011, and SQL:2016? Briefly describe how SQL:2016 differs from SQL:1999.

5-5. Explain what capabilities the new temporal features added to the SQL standard in SQL:2011.

M05B_HOFF3359_13_GE_C05.indd 277 23/02/19 12:44 PM

278 Part III • Database Implementation and Use

5-6. Describe a relational DBMS (RDBMS), its underlying data model, its data storage structures, and how data relation- ships are established.

5-7. What are some of the advantages and disadvantages of an SQL standard?

5-8. Describe the components and structure of a typical SQL environment.

5-9. Explain the three classes of SQL commands and when they would be used.

5-10. What are the primary data integrity constraints in SQL? 5-11. Explain how referential integrity is established in data-

bases that are SQL:1999 compliant. Explain how the ON UPDATE RESTRICT, ON UPDATE CASCADE, and ON UPDATE SET NULL clauses differ from one another. What happens if the ON DELETE CASCADE clause is set?

5-12. Explain the purpose of indexing in database implementation. 5-13. What are the potential consequences of inappropriate

indexing decisions? 5-14. Explain the factors to be considered in deciding whether

to create an index for a column in SQL. 5-15. Explain and provide at least one example of how to qual-

ify the ownership of a table in SQL. What has to occur for one user to be allowed to use a table in a database owned by another user?

5-16. How is the order in which attributes appear in a result table determined? How are the column heading labels in a result table changed?

5-17. What is the difference between COUNT, COUNT DIS- TINCT, and COUNT(*) in SQL? When will these three commands generate the same and different results?

5-18. What is the evaluation order for the Boolean operators (AND, OR, NOT) in an SQL command? How can a query writer be sure that the operators will work in a specific, desired order?

5-19. If an SQL statement includes a GROUP BY clause, the attributes that can be requested in the SELECT statement will be limited. Explain that limitation.

5-20. How is the HAVING clause different from the WHERE clause?

5-21. In what clause of a SELECT statement is an IN operator used? What follows the IN operator? What other SQL operator can sometimes be used to perform the same operation as the IN operator? Under what circumstances can this other operator be used?

5-22. How do you determine the order in which the rows in a response to an SQL query appear? What options do you have when specifying this order?

5-23. Explain why SQL is called a set-oriented language. 5-24. What considerations should be kept in mind when using

indexing? 5-25. What is an identity column? Explain the benefits of using

the identity column capability in SQL. 5-26. SQL:2006 and SQL:2008 introduced a new key word,

MERGE. Explain how using this key word allows one to accomplish updating and merging data into a table using one command rather than two.

5-27. What is a materialized view, and when would it be used?

5-28. State four rules for choosing indexes for a relational database.

5-29. How can an SQL command be structured to allow paral- lel execution?

5-30. Explain the purpose of the CHECK clause within a CRE- ATE TABLE SQL command.

5-31. What can be changed about a table definition using the SQL command ALTER? Can you identify anything about a table definition that cannot be changed using the ALTER command?

5-32. Explain the difference between the WHERE and HAVING clause.

5-33. What is the purpose of the EXPLAIN or EXPLAIN PLAN command?

Problems and Exercises

Problems and Exercises 5-34 through 5-45 are based on the class scheduling 3NF relations along with some sample data shown in Fig- ure 5-11. Not shown in this figure are data for an ASSIGNMENT re- lation, which represents a many-to-many relationship between faculty and sections. Note that values of the SectionNo column do not repeat across semesters. 5-34. Write a database description for each of the relations

shown, using SQL DDL (shorten, abbreviate, or change any data names, as needed for your SQL version). Assume the following attribute data types:

StudentID (integer, primary key) StudentName (25 characters) FacultyID (integer, primary key) FacultyName (25 characters) CourseID (8 characters, primary key) CourseName (15 characters) DateQualified (date) SectionNo (integer, primary key) Semester (7 characters)

5-35. Analyze the database to determine whether or not it is fully normalized.

5-36. Use SQL to define the following view:

STUDENTID STUDENTNAME

38214 Letersky

54907 Altvater

54907 Altvater

66324 Aiken

5-37. To enforce referential integrity, before any row can be entered into the SECTION table, the CourseID to be entered must already exist in the COURSE table. Write an SQL assertion that will enforce this constraint.

5-38. Write SQL data definition commands for each of the fol- lowing queries: a. How would you add an attribute, Class, to the

STUDENT table? b. How would you remove the REGISTRATION table? c. What would you need to take into account if you

wanted to remove the COURSE table? d. How would you change the FacultyName column

from 25 characters to 40 characters?

M05B_HOFF3359_13_GE_C05.indd 278 23/02/19 12:44 PM

5 • Introduction to SQL 279

5-39. Write SQL commands for the following: a. Create two different forms of the INSERT command to

add a student with a student ID of 65798 and last name Lopez to the STUDENT table.

b. Now write a command that will remove this student from the STUDENT table.

c. How would your command look like if your task was to remove any student with the last name Lopez from the STUDENT table?

d. Create an SQL command that will modify the name of course ISM 4212 from Database to Introduction to Rela- tional Databases.

5-40. Write SQL queries to answer the following questions: a. Which students have an ID number that is less than

50000? b. What is the name of the faculty member whose ID is

4756? c. What is the smallest section number used in the first

semester of 2018?

5-41. Write SQL queries to answer the following questions: a. How many students are enrolled in Section 2714 in the

first semester of 2018? b. What are the numbers of the faculty members who are

currently qualified to teach the course ISM 3113? c. Which faculty members have qualified to teach a

course since 2011? List the faculty ID, course, and date of qualification.

5-42. Write SQL queries to answer the following questions: a. Which students are enrolled in Database and Network-

ing? (Hint: Use SectionNo for each class so you can deter- mine the answer from the REGISTRATION table by itself.)

b. Which instructors cannot teach both Syst Analysis and Syst Design?

c. Which courses were taught in the first semester of 2018 but not in the second semester of 2018?

5-43. Write SQL queries to answer the following questions: a. What are the courses included in the Section table? List

each course only once.

FacultyID

2143 2143 3467 3467 4756 4756 ...

CourseID

ISM 3112 ISM 3113 ISM 4212 ISM 4930 ISM 3113 ISM 3112

DateQualified

9/2008 9/2008 9/2015 9/2016 9/2011 9/2011

QUALIFIED (FacultyID, CourseID, DateQualified)

SectionNo

2712 2713 2714 2715 ...

SECTION (SectionNo, Semester, CourseID)

StudentID

38214 54907 54907 66324 ...

SectionNo

2714 2714 2715 2713

REGISTRATION (StudentID, SectionNo)

STUDENT (StudentID, StudentName)

StudentID

38214 54907 66324 70542 ...

StudentName

Letersky Altvater Aiken Marra

FacultyID

2143 3467 4756 ...

FacultyName

Birkin Berndt Collins

FACULTY (FacultyID, FacultyName)

CourseID

ISM 3113 ISM 3113 ISM 4212 ISM 4930

CourseID

ISM 3113 ISM 3112 ISM 4212 ISM 4930 ...

CourseName

Syst Analysis Syst Design Database Networking

COURSE (CourseID, CourseName)

I-2018 I-2018 II-2018 II-2018

Semester

FIGURE 5-11 Class scheduling relations (missing ASSIGNMENT)

M05B_HOFF3359_13_GE_C05.indd 279 23/02/19 12:44 PM

280 Part III • Database Implementation and Use

b. List all students in alphabetical order by Student- Name.

c. List the students who are enrolled in each course in Semester I, 2018. Group the students by the sections in which they are enrolled.

d. List the courses available. Group them by course pre- fix. (ISM is the only prefix shown, but there are many others throughout the university.)

5-44. Write SQL queries to answer the following questions: a. List the numbers of all sections of course ISM 3113 that

are offered during the semester “I-2018.” b. List the course IDs and names of all courses that start

with the letters “Data.” c. List the IDs of all faculty members who are qualified to

teach both ISM 3112 and ISM 3113. d. Modify the query above in part c so that both qualifica-

tions must have been earned after the year 2011. e. List the ID of the faculty member who has been assigned

to teach ISM 4212 during the semester II-2018. 5-45. Write SQL queries to answer the following questions:

a. For each course included in the QUALIFIED table, list CourseID and the number of faculty members quali- fied to teach it.

b. For each section included in the REGISTRATION table, list SectionNo and the number of students registered for it. Include only those sections that have more than one student registered for it.

c. For each course, list CourseID and the number of sec- tions offered during semester II-2018.

Problems and Exercises 5-46 through 5-56 are based on the rela- tions shown in Figure 5-12. The database tracks an adult literacy program. Tutors complete a certification class offered by the agency. Students complete an assessment interview that results in a report for the tutor and a recorded Read score. Each student belongs to a student group. When matched with a student, a tutor meets with the student for one to four hours per week. Some students work with the same tutor for years, some for less than a month. Other students change tutors if their learning style does not match the tutor’s tu- toring style. Many tutors are retired and are available to tutor only part of the year. Tutor status is recorded as Active, Temp Stop, or Dropped.

5-46. How many tutors have a status of Temp Stop? Which tutors are active?

5-47. What is the average Read score for all students? What are the minimum and maximum Read scores?

5-48. List the IDs of the tutors who are currently tutoring more than one student.

5-49. What are the TutorIDs for tutors who have not yet tutored anyone?

5-50. How many students were matched with someone in the first five months of the year?

5-51. Which student has the highest Read score? 5-52. Show the average, maximum, and minimum Read score

per student group. 5-53. How long had each student studied in the adult literacy

program? 5-54. Which tutors have a Dropped status and have achieved

their certification after 4/01/2018? 5-55. How many tutors have an Active status in the data-

base? 5-56. What is the average length of time a student stayed (or has

stayed) in the program?

Problems and Exercises 5-57 through 5-93 are based on the entire (“big” version) Pine Val- ley Furniture Company data- base. Note: Depending on what DBMS you are using, some field names may have changed to avoid using reserved words for the DBMS. When you first use the DBMS, check the table definitions to see what the exact field names are for the DBMS you are using. See the Preface and inside covers of this book for instructions on where to find this database at www.teradatauniver- sitynetwork.com.

5-57. Modify the Product_T table by adding an attribute Qty- OnHand that can be used to track the finished goods inventory. The field should be an integer field of five char- acters and should accept only positive numbers.

5-58. Enter sample data of your own choosing into QtyOn- Hand in the Product_T table. Test the modification you made in Problem and Exercise 5-57 by attempting to update a product by changing the inventory to 10,000 units. Test it again by changing the inventory for the product to −10 units. If you do not receive error mes- sages and are successful in making these changes, then you did not establish appropriate constraints in Problem and Exercise 5-57.

5-59. Add an order to the Order_T table and include a sample value for every attribute. a. First, look at the data in the Customer_T table and

enter an order from any one of those customers. b. Enter an order from a new customer. Unless you have

also inserted information about the new customer in the Customer_T table, your entry of the order data should be rejected. Referential integrity constraints should prevent you from entering an order if there is no information about the customer.

5-60. Use the Pine Valley database to answer the following questions: a. How many work centers does Pine Valley have? b. Where are they located?

5-61. List the employees whose last names begin with an L. 5-62. Which employees were hired during 2005? 5-63. List the customers who live in California or Washington.

Order them by zip code, from high to low. 5-64. List the number of customers living at each state that is

included in the Customer_T table. 5-65. List all raw materials that are made of cherry and that

have dimensions (thickness and width) of 12 by 12. 5-66. List the MaterialID, MaterialName, Material, Material-

StandardPrice, and Thickness for all raw materials made of cherry, pine, or walnut. Order the listing by Material, StandardPrice, and Thickness.

5-67. Display the product line ID and the average standard price for all products in each product line.

5-68. 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.

5-69. For every product that has been ordered, display the product ID and the total quantity ordered (label this result TotalOrdered). List the most popular product first and the least popular last.

5-70. For each order, display the order ID, the number of sepa- rate products included in the order, and the total number of product units (for all products) ordered.

M05B_HOFF3359_13_GE_C05.indd 280 23/02/19 12:44 PM

5 • Introduction to SQL 281

Active5/22/2018106

Temp Stop5/22/2018105

Active5/22/2018104

Active5/22/2018103

Dropped1/05/2018102

Temp Stop1/05/2018101

Active1/05/2018100

StatusCertDateTutorID

TUTOR (TutorID, CertDate, Status)

3007

3006

3005

3004

3003

3002

3001

3000

ReadGroupStudentID

1.5

7.8

4.8

2.7

3.3

1.3

5.6

2.3

4

3

4

2

1

3

2

3

STUDENT (StudentID, Group, Read)

6/01/20187

6/28/20186/01/20186

6/15/20186/01/20185

5/28/20184

3/01/20182/10/20183

5/15/20181/15/20182

1/10/20181

EndDateStartDateStudentIDTutorIDMatchID

3006104

3005104

3004103

3003106

3002102

3001101

3000100

MATCH HISTORY (MatchID, TutorID, StudentID, StartDate, EndDate)

FIGURE 5-12 Adult literacy program (for Problems and Exercises 5-46 through 5-56)

5-71. For each customer, list the CustomerID and total number of orders placed.

5-72. For each salesperson, display a list of CustomerIDs. 5-73. Display the product ID and the number of orders placed

for each product. Show the results in decreasing order by the number of times the product has been ordered and label this result column NumOrders.

5-74. For each payment made on or after March 10, 2018, list PaymentID, OrderID, PaymentAmount, and the first 10 characters of PaymentComment.

5-75. For each customer, list the customer ID and the total num- ber of orders placed in 2018.

5-76. For each salesperson, list the total number of orders.

M05B_HOFF3359_13_GE_C05.indd 281 23/02/19 12:44 PM

282 Part III • Database Implementation and Use

5-77. For each customer who had more than two orders, list the CustomerID and the total number of orders placed.

5-78. Assume that for those materials the ID of which starts with a numeric character, the last three letters of the ID 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.

5-79. List all sales territories (TerritoryID) that have more than one salesperson.

5-80. Which product is ordered most frequently? 5-81. For employees who live in TN or FL, list the age at which

they were hired. 5-82. Measured by average standard price, what is the least

expensive product finish? 5-83. Display the territory ID and the number of salespersons

in the territory for all territories that have more than one salesperson. Label the number of salespersons NumSales- Persons.

5-84. Display the SalesPersonID and a count of the number of orders for that salesperson for all salespersons except salespersons 3, 5, and 9. Write this query with as few clauses or components as possible, using the capabilities of SQL as much as possible.

5-85. For each salesperson, list the total number of orders by month for the year 2018. (Hint: If you are using Access, use the Month function. If you are using Oracle, convert the date to a string, using the TO_CHAR function, with the format string ‘Mon’ [i.e., TO_CHAR(order_date,’MON’)]. If you are using another DBMS, you will need to investi- gate how to deal with months for this query.)

5-86. List MaterialName, Material, and Width for raw materials that are not cherry or oak and whose width is greater than 10 inches. Show how you constructed this query using a Venn diagram.

5-87. List ProductID, ProductDescription, ProductFinish, and ProductStandardPrice for oak products with a Product- StandardPrice greater than $400 or cherry products with a StandardPrice less than $300. Show how you constructed this query using a Venn diagram.

5-88. For each order, list the order ID, customer ID, order date, and most recent date among all orders. Show how you constructed this query using a Venn diagram.

5-89. For each customer, list the customer ID, the number of orders from that customer, and the ratio of the number of orders from that customer to the total number of orders from all customers combined. (This ratio, of course, is the percentage of all orders placed by each customer.)

5-90. For products 1, 2, and 7, list in one row and three respec- tive columns that product’s total unit sales; label the three columns Prod1, Prod2, and Prod7.

5-91. List the average number of customers per state (including only the states that are included in the Customer_T table). Hint: A query can be used as a table specification in the FROM clause.

5-92. Not all versions of this database include referential integrity constraints for all foreign keys. Use whatever commands are available for the RDBMS you are using, investigate if any referential integrity constraints are miss- ing. Write any missing constraints and, if possible, add them to the associated table definitions.

5-93. Tyler Richardson set up a house alarm system when he moved to his new home in Seattle. For security purposes, he has all of his mail, including his alarm system bill, mailed to his local UPS store. Although the alarm sys- tem is activated and the company is aware of its physical address, Richardson receives repeated offers mailed to his physical address, imploring him to protect his house with the system he currently uses. What do you think the prob- lem might be with that company’s database(s)?

Field Exercises

5-94. Locate three database administrator vacancies advertised online and assess the requirements for the position. What is the key knowledge and skill employers require of a database administrator? If you were interested in a career in administration, how would you go about acquiring this essential knowledge and expertise? Create a continuing professional development plan that maps out your 5-year blueprint for developing as a database professional.

5-95. Arrange an interview with a database administrator in your area. Focus the interview on understanding the environment within which SQL is used in the organiza- tion. Inquire about the version of SQL that is used and determine whether the same version is used at all loca- tions. If different versions are used, explore any difficul-

ties that the DBA has had in administering the database. Also inquire about any proprietary languages, such as Oracle’s PL/SQL, that are being used. Learn about possi- ble differences in versions used at different locations and explore any difficulties that occur if different versions are installed.

5-96. Arrange an interview with a database administrator in your area who has at least seven years of experience as a database administrator. Focus the interview on under- standing how DBA responsibilities and the way they are completed have changed during the DBA’s tenure. Does the DBA have to generate more or less SQL code to admin- ister the databases now than in the past? Has the position become more or less stressful?

References

Codd, E. F. 1970. “A Relational Model of Data for Large Shared Data Banks.” Communications of the ACM 13,6 (June): 77–87.

Date, C. J., and H. Darwen. 1997. A Guide to the SQL Standard. Reading, MA: Addison-Wesley.

Gorman, M. M. 2001. “Is SQL a Real Standard Anymore?” The Data Administration Newsletter (July). Available at http:// tdan.com/is-sql-a-real-standard-anymore/4923

Kulkarni, K. G., and J-E. Michels. 2012. “Temporal Features in SQL:2011.” SIGMOD Record, 41,3: 34–43.

M05B_HOFF3359_13_GE_C05.indd 282 23/02/19 12:44 PM

5 • Introduction to SQL 283

van der Lans, R. F. 2006. Introduction to SQL: Mastering the Relational Database Language. 4th ed. Workingham: Addison- Wesley.

Yegulalp, S. 2014. “10 Ways to Query Hadoop with SQL.”

Available at http://www.infoworld.com/article/2683729/ hadoop/10-ways-to-query-hadoop-with-sql.html

Zemke, F. 2012. “What’s New in SQL:2011.” SIGMOD Record, 41,1: 67–73.

Further Reading

Atzeni, P., C. S. Jensen, G. Orsi, S. Ram, L. Tanca, and R. Torlone. 2013. “The Relational Model Is Dead, SQL Is Dead, and I Don’t Feel So Good Myself.” SIGMOD Record, 42,2: 64–68.

Beaulieu, A. 2009. Learning SQL. Sebastopol, CA: O’Reilly.

Celko, J. 2006. Joe Celko’s SQL Puzzles & Answers. 2nd ed. San Francisco: Morgan Kaufmann.

Gulutzan, P., and T. Petzer. 1999. SQL-99 Complete, Really. Lawrence, KS: R&D Books.

Mistry, R., and S. Misner. 2014. Introducing Microsoft SQL Server 2014. Redmond, WA: Microsoft Press.

Nielsen, P., U. Parui, and M. White. 2009. Microsoft SQL Server 2008 Bible. Indianapolis, IN: Wiley Publishing.

Price, J. 2012. Oracle Database 12c SQL. New York: McGraw-Hill Professional.

Web Resources

http://standards.ieee.org The home page of the IEEE Standards Association.

www.1keydata.com/sql/sql.html Web site that provides tutori- als on a subset of ANSI standard SQL commands.

www.ansi.org Information on ANSI and the latest national and international standards.

www.fluffycat.com/SQL Web site that defines a sample database and shows examples of SQL queries against this database.

www.incits.org The home page of the International Committee for Information Technology Standards, which used to be the National Committee for Information Technology Standards, which used to be the Accredited Standard Committee X3.

www.iso.org/iso/home.html International Organization for Standardization Web site, from which copies of current standards may be purchased.

www.itl.nist.gov/div897/ctg/dm/sql_examples.htm Web site that shows examples of SQL commands for creating tables and views, updating table contents, and performing some SQL database administration commands.

www.java2s.com/Code/SQL/CatalogSQL.htm Web site that provides tutorials on SQL in a MySQL environment.

www.khanacademy.org/computing/computer-programming/ sql An SQL tutorial section of a well-known educational

resource site in mathematics, science, computing, and other fields.

www.mysql.com The official home page for MySQL, which includes many free downloadable components for working with MySQL.

www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=27 Web site that provides a brief explanation of the power of SQL and a variety of sample SQL queries.

www.sqlcourse.com and www.sqlcourse2.com Web sites that provide tutorials for a subset of ANSI SQL, along with a practice database.

www.teradatauniversitynetwork.com Web site where your instructor may have created some course environments for you to use Teradata SQL Assistant, Web Edition, with one or more of the Pine Valley Furniture data sets for this text.

www.tizag.com/sqlTutorial A set of tutorials on SQL concepts and commands.

www.wiscorp.com/SQLStandards.html Whitemarsh Informa- tion Systems Corp., a good source of information about SQL standards, including SQL:2003 and later standards.

www.w3schools.com/SQL/deFault.asp Comprehensive SQL tutorials by offered by W3schools.com.

M05B_HOFF3359_13_GE_C05.indd 283 23/02/19 12:44 PM

284 Part III • Database Implementation and Use

5-98. Reread the case descriptions in Chapters 1 through 3 with an eye toward identifying the typical types of reports and displays the various stakeholders might want to retrieve from your database. Create a document that summarizes these findings.

5-99. Based on your findings from 5-98 above, populate the tables in your database with sample data that can poten- tially allow you to test/demonstrate that your database can generate these reports.

5-100. Write and execute a variety of queries to test the func- tionality of your database based on what you learned in this chapter. Don’t panic if you can’t write all the que- ries; many of the queries will require knowledge from Chapter 6. Your instructor may specify for which reports or displays you should write queries.

Case Description

In Chapter 4, you created the logical data model for the database that will support the functionality needed by FAME. You will use this information to implement the data- base in the DBMS of your choice (or as specified by your instructor).

Project Questions

5-97. Write the SQL statements for creating the tables, speci- fying data types and field lengths, establishing pri- mary keys and foreign keys, and implementing any other constraints you may have identified. Use the examples shown in this chapter to specify indexes, if appropriate.

CASE Forondo Artist Management Excellence Inc.

M05B_HOFF3359_13_GE_C05.indd 284 23/02/19 12:44 PM

285

LEARNING OBJECTIVES After studying this chapter, you should be able to:

■■ Concisely define each of the following key terms: join, equi-join, natural join, outer join, correlated subquery, base table, virtualized table, dynamic view, materialized view, trigger, Persistent Stored Modules (SQL/PSM), function, and procedure.

■■ Write single- and multiple-table queries using SQL commands. ■■ Define three types of join commands and use SQL to write these commands. ■■ Write noncorrelated and correlated subqueries and know when to write each. ■■ Write queries to create dynamic and materialized views. ■■ Understand common uses of database triggers and stored procedures. ■■ Discuss the SQL:2011 and SQL:2016 standards and explain SQL enhancements and extensions.

INTRODUCTION

In the previous chapter, you learned about SQL and explored its capabilities for querying one table. The real power of the relational model derives from its storage of data in many related entities. Taking advantage of this approach to data storage requires establishing relationships and constructing queries that use data from multiple tables. This chapter examines multiple-table queries at a detailed level. Different approaches to getting results from more than one table are demonstrated, including the use of subqueries, inner and outer joins, and union joins. You will also learn about triggers, small modules of code that execute automatically when a particular condition, defined in the trigger, exists. Procedures are similar modules of code that must be explicitly called for them to execute.

Completion of this chapter gives you a comprehensive overview of the SQL language and some of the ways in which it may be used. Many additional features, often referred to as “obscure” in more detailed SQL texts, will be needed in particular situations. Practice with the syntax and the problem-solving skills that utilize the syntax included in this chapter will give you a good start toward mastery of SQL. As you learned in Chapter 5, the key concepts of SQL have been used as foundational elements of many languages also in the Analytical–Big Data category (see Figure 1-5 and Chapter 10); thus, the value of these skills goes significantly beyond the traditional transactional systems.

Visit www.pearsonglobaleditions .com to view the accompanying video for this chapter.

Advanced SQL 6

M06_HOFF3359_13_GE_C06.indd 285 10/04/19 2:51 PM

286 Part III • Database Implementation and Use

PROCESSING MULTIPLE TABLES

Now that you have explored some of the possibilities for working with a single table, it’s time to bring out the light sabers, jet packs, and tools for heavy lifting: you will learn how to work with multiple tables simultaneously. The power of RDBMSs is realized when working with multiple tables. When relationships exist among tables, the tables can be linked together in queries. Remember from Chapter 4 that these relationships are established by including a common column(s) in each table where a relationship is needed. In most cases, this is accomplished by setting up a primary key–foreign key rela- tionship, where the foreign key in one table references the primary key in another and the values in both come from a common domain. You can use these columns to establish a link between two tables by finding common values in the columns. Figure 6-1 carries forward two relations from Figure 5-3, depicting part of the Pine Valley Furniture Com- pany database. Notice that CustomerID values in Order_T correspond to CustomerID values in Customer_T. Using this correspondence, you can deduce that Contemporary Casuals placed orders 1001 and 1010 because Contemporary Casuals’s CustomerID is 1, and Order_T shows that OrderID 1001 and 1010 were placed by customer 1. In a rela- tional system, data from related tables are combined into one result table or view and then displayed or used as input to a form or report definition.

The linking of related tables varies among different types of relational systems. In SQL, the WHERE clause of the SELECT command is also used for multiple-table opera- tions. In fact, SELECT can include references to two, three, or more tables in the same command. As illustrated next, SQL has two ways to use SELECT for combining data from related tables.

The most frequently used relational operation, which brings together data from two or more related tables into one resultant table, is called a join. Originally, SQL specified a join implicitly by referring in a WHERE clause to the matching of common columns over which tables were joined. Since SQL-92, joins may also be specified in the FROM clause. In either case, two tables may be joined when each contains a column that shares a common domain with the other. As mentioned previously, a primary key from one table and a foreign key that references the table with the primary key will share a common domain and are frequently used to establish a join. In special cases, joins will be established using columns that share a common domain but not the pri- mary key–foreign key relationship, and that also works (e.g., you might join customers and salespersons based on common postal codes, for which there is no relationship in the data model for the database). The result of a join operation is a single table. Selected columns from all the tables are included. Each row returned contains data from rows in the different input tables where values for the common columns match.

Explicit JOIN . . . ON commands are included in the FROM clause. The fol- lowing join operations are included in the standard, though each RDBMS product is likely to support only a subset of the key words: INNER, OUTER, FULL, LEFT, RIGHT, CROSS, and UNION. (We’ll explain these in a following section.) NATURAL is an optional key word. No matter what form of join you are using, there should be one ON or WHERE specification for each pair of tables being joined. Thus, if two tables are to be combined, one ON or WHERE condition would be necessary, but if three tables (A, B, and C) are to be combined, then two ON or WHERE conditions would

Join

A relational operation that causes two tables with a common domain to be combined into a single table or view.

FIGURE 6-1 Pine Valley Furniture Company Customer_T and Order_T tables, with pointers from customers to their orders

M06_HOFF3359_13_GE_C06.indd 286 23/02/19 1:01 PM

6 • Advanced SQL 287

be necessary because there are two pairs of tables (A-B and B-C) and so forth. Most systems support up to 10 pairs of tables within one SQL query. At this time, core SQL does not support CROSS JOIN, UNION JOIN, FULL [OUTER] JOIN, or the key word NATURAL. Knowing this should help you understand why you may not find these implemented in the RDBMS you are using. Because they are included in the SQL:2016 standard and are useful, expect to find them becoming more widely available.

The various types of joins are described in the following sections.

Equi-Join

With an equi-join, the joining condition is based on equality between values in the common columns. For example, if you want to know data about customers who have placed orders, you will find that information in two tables, Customer_T and Order_T. It is necessary to match customers with their orders and then collect the information about, for example, customer name and order number in one table in order to answer our question. We call the table created by the query the result or answer table.

Query: What are the customer IDs and names of all customers, along with the order IDs for all the orders they have placed?

SELECT Customer_T.CustomerID, Order_T.CustomerID, CustomerName, OrderID FROM Customer_T, Order_T WHERE Customer_T.CustomerID = Order_T. CustomerID ORDER BY OrderID

Result:

CUSTOMERID CUSTOMERID CUSTOMERNAME ORDERID

1 1 Contemporary Casuals 1001

8 8 California Classics 1002

15 15 Mountain Scenes 1003

5 5 Impressions 1004

3 3 Home Furnishings 1005

2 2 Value Furniture 1006

11 11 American Euro Lifestyles 1007

12 12 Battle Creek Furniture 1008

4 4 Eastern Furniture 1009

1 1 Contemporary Casuals 1010

10 rows selected.

The redundant CustomerID columns, one from each table, demonstrate that the customer IDs have been matched and that matching gives one row for each order placed. We prefixed the CustomerID columns with the names of their respective tables so that SQL knows which CustomerID column we referenced in each element of the SELECT list. We did not, however, have to prefix CustomerName or OrderID with their associated table names because each of these columns is found in only one table in the FROM list. We suggest that you study Figure 6-1 to see that the 10 arrows in the figure correspond to the 10 rows in the query result. Also, notice that there are no rows in the query result for those customers with no orders because there is no match in Order_T for those CustomerIDs.

The importance of achieving the match between tables can be seen if the WHERE clause is omitted. That query will return all combinations of customers and orders, or 150 rows, and includes all possible combinations of the rows from the two tables (i.e., an order will be matched with every customer, not just the customer who placed that

Equi-join

A join in which the joining condition is based on equality between values in the common columns. Common columns appear (redundantly) in the result table.

M06_HOFF3359_13_GE_C06.indd 287 23/02/19 1:01 PM

288 Part III • Database Implementation and Use

order). In this case, this join does not reflect the relationships that exist between the tables and is not a useful or meaningful result. The number of rows is equal to the num- ber of rows in each table, multiplied together (10 orders × 15 customers = 150 rows). This is called a Cartesian join. Cartesian joins with spurious results will occur when any joining component of a WHERE clause with multiple conditions is missing or erroneous. In the rare case that a Cartesian join is desired, omit the pairings in the WHERE clause. A Cartesian join may be explicitly created by using the phrase CROSS JOIN in the FROM statement. FROM Customer_T CROSS JOIN Order_T would create a Cartesian product of all customers with all orders. (Use this query only if you really mean to because a cross join against a production database can produce hundreds of thousands of rows and can consume significant computer time—plenty of time to receive a pizza delivery!)

The keywords INNER JOIN . . . ON are used to establish an equi-join in the FROM clause. While the syntax demonstrated here is Microsoft Access SQL syntax, note that some systems, such as Oracle and Microsoft SQL Server, treat the key word JOIN by itself without the word INNER to establish an equi-join:

Query: What are the customer IDs and names of all customers, along with the order IDs for all the orders they have placed?

SELECT Customer_T.CustomerID, Order_T.CustomerID, CustomerName, OrderID FROM Customer_T INNER JOIN Order_T ON Customer_T.CustomerID = Order_T.CustomerID ORDER BY OrderID;

Result: Same as the previous query.

Simplest of all would be to use the JOIN . . . USING syntax, if this is supported by the RDBMS you are using. If the database designer thought ahead and used identical column names for the primary and foreign keys, as has been done with CustomerID in the Customer_T and Order_T tables, the following query could be used:

SELECT Customer_T.CustomerID, Order_T.CustomerID, CustomerName, OrderID FROM Customer_T INNER JOIN Order_T USING CustomerID ORDER BY OrderID;

Notice that the WHERE clause now functions only in its traditional role as a filter as needed. Since the FROM clause is generally evaluated prior to the WHERE clause, some users prefer using the newer syntax of ON or USING in the FROM clause. A smaller record set that meets the join conditions is all that must be evaluated by the remaining clauses, and performance may improve. All DBMS products support the tra- ditional method of defining joins within the WHERE clause. Microsoft SQL Server sup- ports the INNER JOIN . . . ON syntax, Oracle has supported it since 9i, and MySQL has supported it since version 3.23.17.

We again emphasize that SQL is a set-oriented language. Thus, this join example is produced by taking the Customer_T table and the Order_T table as two sets and appending together those rows from Customer_T with rows from Order_T that have equal CustomerID values. This is a set intersection operation, which is followed by appending the selected columns from the matching rows. Figure 6-2 uses set diagrams to display the most common types of two-table joins.

Natural Join

A natural join is the same as an equi-join, except that it is performed over matching columns, and one of the duplicate columns is eliminated in the result table. The natural join is the most commonly used form of join operation. (No, a “natural” join is not a more healthy join with more fiber, and there is no unnatural join, but you will find it a

Natural join A join that is the same as an equi-join except that one of the duplicate columns is eliminated in the result table.

M06_HOFF3359_13_GE_C06.indd 288 23/02/19 1:01 PM

6 • Advanced SQL 289

natural and essential function with relational databases.) Notice in the query below that CustomerID must still be qualified because there is still ambiguity; CustomerID exists in both Customer_T and Order_T, and therefore it must be specified from which table CustomerID should be displayed. NATURAL is an optional key word when the join is defined in the FROM clause.

Query: For each customer who has placed an order, what is the customer’s ID, name, and order number?

SELECT Customer_T.CustomerID, CustomerName, OrderID FROM Customer_T NATURAL JOIN Order_T ON Customer_T.CustomerID = Order_T.CustomerID;

Note that the order of table names in the FROM clause is immaterial. The query opti- mizer of the DBMS will decide in which sequence to process each table. Whether indexes exist on common columns will influence the sequence in which tables are processed, as will which table is on the 1 and which is on the M side of the 1:M relationship. If a query takes significantly different amounts of time, depending on the order in which tables are listed in the FROM clause, the DBMS does not have a very good query optimizer.

Outer Join

In joining two tables, you often find that a row in one table does not have a matching row in the other table. For example, several CustomerID numbers do not appear in the Order_T table. In Figure 6-1, pointers have been drawn from customers to their orders. Contemporary Casuals has placed two orders. Furniture Gallery, Period Furniture, M & H Casual Furniture, Seminole Interiors, Heritage Furnishings, and Kaneohe Homes have not placed orders in this small example. You can assume that this is because those customers have not placed orders since 10/21/2018, or their orders are not included in our very short sample Order_T table. As a result, the equi-join and natural join shown previously do not include all the customers shown in Customer_T.

Of course, the organization may be very interested in identifying those customers who have not placed orders. It might want to contact them to encourage new orders, or it might be interested in analyzing these customers to discern why they are not order- ing. Using an outer join produces this information: Rows that do not have matching values in common columns are also included in the result table. Null values appear in columns where there is not a match between tables.

Outer joins can be handled by all the major RDBMS vendors, but the syntax used to accomplish an outer join varies across vendors. The example given here uses ANSI standard syntax. When an outer join is not available explicitly, use UNION and NOT EXISTS (discussed later in this chapter) to carry out an outer join. Here is an outer join.

Outer join

A join in which rows that do not have matching values in common columns are nevertheless included in the result table.

Natural Join Left Outer Join

Union Join

Darker area is result returned.

All records are returned.

All records returned from outer table. Matching records returned from joined table.

FIGURE 6-2 Visualization of different join types, with the results returned in the shaded area

M06_HOFF3359_13_GE_C06.indd 289 23/02/19 1:01 PM

290 Part III • Database Implementation and Use

Query: List customer name, identification number, and order number for all cus- tomers listed in the Customer table. Include the customer identification number and name even if there is no order available for that customer.

SELECT Customer_T.CustomerID, CustomerName, OrderID FROM Customer_T LEFT OUTER JOIN Order_T WHERE Customer_T.CustomerID = Order_T. CustomerID;

The syntax LEFT OUTER JOIN was selected because the Customer_T table was named first, and it is the table from which we want all rows returned, regardless of whether there is a matching order in the Order_T table. Had we reversed the order in which the tables were listed, the same results would be obtained by requesting a RIGHT OUTER JOIN. It is also possible to request a FULL OUTER JOIN. In that case, all rows from both tables would be returned and matched, if possible, including any rows that do not have a match in the other table. INNER JOINs are much more common than OUTER JOINs because outer joins are necessary only when the user needs to see data from all rows, even those that have no matching row in another table.

It should also be noted that the OUTER JOIN syntax does not apply easily to a join condition of more than two tables. The results returned will vary according to the vendor, so be sure to test any outer join syntax that involves more than two tables until you understand how it will be interpreted by the DBMS being used.

Also, the result table from an outer join may indicate NULL (or a symbol, such as ??) as the values for columns in the second table where no match was achieved. If those columns could have NULL as a data value, you cannot know whether the row returned is a matched row or an unmatched row unless you run another query that checks for null values in the base table or view. Also, a column that is defined as NOT NULL may be assigned a NULL value in the result table of an OUTER JOIN. In the following result, NULL values are shown by an empty value (i.e., a customer without any orders is listed with no value for OrderID).

Result:

CUSTOMERID CUSTOMERNAME ORDERID

1 Contemporary Casuals 1001

1 Contemporary Casuals 1010

2 Value Furniture 1006

3 Home Furnishings 1005

4 Eastern Furniture 1009

5 Impressions 1004

6 Furniture Gallery

7 Period Furniture

8 California Classics 1002

9 M & H Casual Furniture

10 Seminole Interiors

11 American Euro Lifestyles 1007

12 Battle Creek Furniture 1008

13 Heritage Furnishings

14 Kaneohe Homes

15 Mountain Scenes 1003

16 rows selected.

It may help you to glance back at Figures 6-1 and 6-2. In Figure 6-2, customers are rep- resented by the left circle, and orders are represented by the right. With a NATURAL JOIN of Customer_T and Order_T, only the 10 rows that have arrows drawn in Figure 6-1 will be

M06_HOFF3359_13_GE_C06.indd 290 23/02/19 1:01 PM

6 • Advanced SQL 291

returned. The LEFT OUTER JOIN on Customer_T returns all of the customers along with the orders they have placed, and customers are returned even if they have not placed orders. Because Customer 1, Contemporary Casuals, has placed two orders, a total of 16 rows are returned because rows are returned for both orders placed by Contemporary Casuals.

The advantage of an outer join is that information is not lost. Here, all customer names were returned, whether or not they had placed orders. Requesting a RIGHT OUTER join would return all orders. (Because referential integrity requires that every order be associated with a valid customer ID, this right outer join would ensure that only referential integrity is being enforced.) Customers who had not placed orders would not be included in the result.

Query: List customer name, identification number, and order number for all orders listed in the Order table. Include the order number, even if there is no cus- tomer name and identification number available.

SELECT Customer_T.CustomerID,CustomerName, OrderID FROM Customer_T RIGHT OUTER JOIN Order_T ON Customer_T.CustomerID = Order_T.CustomerID;

Sample Join Involving Four Tables

Much of the power of the relational model comes from its ability to work with the rela- tionships among the objects in the database. Designing a database so that data about each object are kept in separate tables simplifies maintenance and data integrity. The capability to relate the objects to each other by joining the tables provides critical business informa- tion and reports to employees. Although the examples provided in Chapter 5 and this chapter are simple and constructed only to provide a basic understanding of SQL, it is important to realize that these commands can be and often are built into much more com- plex queries that provide exactly the information needed for a report or process.

Here is a sample join query that involves a four-table join. This query produces a result table that includes the information needed to create an invoice for order number 1006. We want the customer information, the order and order line information, and the product information, so we will need to join four tables. Figure 6-3a shows an anno- tated ERD of the four tables involved in constructing this query; Figure 6-3b shows an

FIGURE 6-3 Diagrams depicting a four-table join

(a) Annotated ERD with relations used in a four-table join

CUSTOMER CustomerID CustomerName CustomerAddress CustomerCity CustomerState CustomerPostalCode

PRODUCT ProductID ProductDescription ProductFinish ProductStandardPrice ProductLineID

JOIN 5

JOIN 5

JOIN 5

ORDER OrderID OrderDate CustomerID

ORDER LINE OrderID ProductID OrderedQuantity

WHERE 5 1006

M06_HOFF3359_13_GE_C06.indd 291 23/02/19 1:01 PM

292 Part III • Database Implementation and Use

(b) Annotated instance diagram of relations used in a four-table

join

FIGURE 6-3 (continued)

abstract instance diagram of the four tables with order 1006 hypothetically having two line items for products Px and Py, respectively. We encourage you to draw such dia- grams to help conceive the data involved in a query and how you might then construct the corresponding SQL query with joins.

Query: Assemble all information necessary to create an invoice for order num- ber 1006.

SELECT Customer_T.CustomerID, CustomerName, CustomerAddress, CustomerCity, CustomerState, CustomerPostalCode, Order_T.OrderID, OrderDate, OrderedQuantity, ProductDescription, StandardPrice, (OrderedQuantity * ProductStandardPrice) FROM Customer_T, Order_T, OrderLine_T, Product_T WHERE Order_T.CustomerID = Customer_T.CustomerID AND Order_T.OrderID = OrderLine_T.OrderID AND OrderLine_T.ProductID = Product_T.ProductID AND Order_T.OrderID = 1006;

The results of the query are shown in Figure 6-4. Remember, because the join involves four tables, there are three column join conditions, as follows:

1. Order_T.CustomerID = Customer_T.CustomerID links an order with its associ- ated customer.

2. Order_T.OrderID = OrderLine_T.OrderID links each order with the details of the items ordered.

3. OrderLine_T.ProductID = Product_T.ProductID links each order detail record with the product description for that order line.

Self-Join

There are times when a join requires matching rows in a table with other rows in that same table—that is, joining a table with itself. There is no special command in SQL to do this, but people generally call this operation a self-join. Self-joins arise for several reasons, the most common of which is a unary relationship, such as the Supervises rela- tionship in the Pine Valley Furniture database in Figure 2-22. This relationship is imple- mented by placing in the EmployeeSupervisor column the EmployeeID (foreign key) of the employee’s supervisor, another employee. With this recursive foreign key column, you can ask the following question:

CustomerID

. . . .

Cx

. . . .

. . . .

. . . .

. . . .

. . . .

CustomerID

Cx

. . . .

. . . .

OrderID

1006

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

ProductID

Px

. . . .

Py

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

ProductID

. . . .

Py

Px

. . . .

OrderID

. . . .

1006

1006

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . 5

5

5

5

5

CUSTOMER ORDER

PRODUCT ORDER LINE

M06_HOFF3359_13_GE_C06.indd 292 23/02/19 1:01 PM

6 • Advanced SQL 293

Query: What are the employee ID and name of each employee and the name of his or her supervisor (label the supervisor’s name Manager)?

SELECT E.EmployeeID, E.EmployeeName, M.EmployeeName AS Manager FROM Employee_T E, Employee_T M WHERE E.EmployeeSupervisor = M.EmployeeID;

Result:

EMPLOYEEID EMPLOYEENAME MANAGER

123-44-347 Jim Jason Robert Lewis

Figure 6-5 depicts this query in both a Venn diagram and an instance diagram. There are two things to note in this query. First, the Employee table is, in a sense, serving

CUSTOMERID

2 2 2

CUSTOMERNAME

Value Furniture Value Furniture Value Furniture

CUSTOMERADDRESS

15145 S. W. 17th St. 15145 S. W. 17th St. 15145 S. W. 17th St.

CUSTOMER CITY

Plano Plano Plano

CUSTOMER STATE

TX TX TX

CUSTOMER POSTALCODE

75094 7743 75094 7743 75094 7743

ORDERID

1006 1006 1006

ORDERDATE

24-OCT-18 24-OCT-18 24-OCT-18

ORDERED QUANTITY

1 2 2

PRODUCTNAME

Entertainment Center Writer’s Desk Dining Table

PRODUCT STANDARDPRICE

650 325 800

(QUANTITY* STANDARDPRICE)

650 650

1600

FIGURE 6-4 Results from a four-table join (edited for readability)

EmployeeID

Employees (E)

Employees (E)

EmployeeName EmployeeSupervisor

Sue Miller

Stan Getz

Jim Jason

Bill Blass

Robert Lewis

107-55-789

123-44-347

547-33-243

678-44-546

098-23-456

EmployeeID

Employees who have supervisors; i.e., WHERE E.EmployeeSupervisor 5 M.EmployeeID

Managers (M)

Managers (M)

EmployeeName EmployeeSupervisor

678-44-546

Sue Miller

Stan Getz

Jim Jason

Bill Blass

Robert Lewis

107-55-789

123-44-347

547-33-243

098-23-456

678-44-546

678-44-546

FIGURE 6-5 Example of a self-join

M06_HOFF3359_13_GE_C06.indd 293 23/02/19 1:01 PM

294 Part III • Database Implementation and Use

two roles: It contains a list of employees and a list of managers. Thus, the FROM clause refers to the Employee_T table twice, once for each of these roles. However, to distin- guish these roles in the rest of the query, you can give the Employee_T table an alias for each role (in this case, E for employee and M for manager roles, respectively). Then the columns from the SELECT list are clear: first the ID and name of an employee (with pre- fix E) and then the name of a manager (with prefix M). Which manager? That then is the second point: The WHERE clause joins the “employee” and “manager” tables based on the foreign key from employee (EmployeeSupervisor) to manager (EmployeeID). As far as SQL is concerned, it considers the E and M tables to be two different tables that have identical column names, so the column names must have a suffix to clarify from which table a column is to be chosen each time it is referenced.

It turns out that there are various interesting queries that can be written using self-joins following unary relationships. For example, which employees have a salary greater than the salary of their manager (not uncommon in professional baseball but generally frowned on in business or government organizations), or (if you had these data in your database) is anyone married to his or her manager (not uncommon in a family-run business but possibly prohibited in many organizations)? Several of the Problems and Exercises at the end of this chapter require queries with a self-join.

As with any other join, it is not necessary that a self-join be based on a foreign key and a specified unary relationship. For example, when a salesperson is scheduled to visit a particular customer, she might want to know all the other customers who are in the same postal code as the customer she is scheduled to visit. Remember, it is possible to join rows on columns from different (or the same) tables as long as those columns come from the same domain of values and the linkage of values from those columns makes sense. For example, even though ProductFinish and EmployeeCity may have the identical data type, they don’t come from the same domain of values, and there is no conceivable busi- ness reason to link products and employees on these columns. However, one might con- ceive of some reason to understand the sales booked by a salesperson by looking at order dates of the person’s sales relative to his or her hire date. It is amazing what questions SQL can answer (although you will have limited control on how SQL displays the results).

Subqueries

The preceding SQL examples illustrate one of the two basic approaches for joining two tables: the joining technique. SQL also provides the subquery technique, which involves placing an inner query (SELECT . . . FROM . . . WHERE) within a WHERE or HAVING clause of another (outer) query. The inner query provides a set of one or more values for the search condition of the outer query. Such queries are referred to as subqueries or nested subqueries. Subqueries can be nested multiple times. Subqueries are prime examples of SQL as a set-oriented language.

Sometimes, either the joining or the subquery technique can be used to accomplish the same result, and different people will have different preferences about which tech- nique to use. Other times, only a join or only a subquery will work. The joining tech- nique is useful when data from several relations are to be retrieved and displayed and the relationships are not necessarily nested, whereas the subquery technique allows you to display data from only the tables mentioned in the outer query. Let’s compare two queries that return the same result. Both answer the question: What are the name and address of the customer who placed order number 1008? First, we will use a join query, which is graphically depicted in Figure 6-6a.

Query: What are the name and address of the customer who placed order num- ber 1008?

SELECT CustomerName, CustomerAddress, CustomerCity, CustomerState, CustomerPostalCode FROM Customer_T, Order_T WHERE Customer_T.CustomerID = Order_T. CustomerID AND OrderID = 1008;

M06_HOFF3359_13_GE_C06.indd 294 23/02/19 1:01 PM

6 • Advanced SQL 295

ORDER_T

CustomerID

. . . .

Cx

. . . .

WHERE Order_T.CustomerID 5 Customer_T.CustomerID

OrderID

. . . .

1008

. . . .

. . . .

. . . .

. . . .

. . . .

CUSTOMER_T

CustomerID

Cx

Customer Name

Customer Address

Customer City

Customer State

Customer PostalCode

WHERE OrderID 5 1008

SELECT

FIGURE 6-6 Graphical depiction of two ways to answer a query with different types of joins

All CustomerIDs

Show customer data for customers with these CustomerIDs; i.e., WHERE Customer_T. CustomerID 5 result of inner query

Order_T. CustomerIDs

WHERE OrderID 5

1008

(a) Join query approach

(b) Subquery approach

In set-processing terms, this query finds the subset of the Order_T table for OrderID = 1008 and then matches the row(s) in that subset with the rows in the Customer_T table that have the same CustomerID values. In this approach, it is not necessary that only one order have the OrderID value 1008. Now, look at the equivalent query using the subquery technique, which is graphically depicted in Figure 6-6b.

Query: What are the name and address of the customer who placed order number 1008?

SELECT CustomerName, CustomerAddress, CustomerCity, CustomerState, CustomerPostalCode FROM Customer_T WHERE Customer_T.CustomerID = (SELECT Order_T.CustomerID FROM Order_T WHERE OrderID = 1008);

Notice that the subquery, shaded in blue and enclosed in parentheses, follows the form learned for constructing SQL queries and could stand on its own as an inde- pendent query. That is, the result of the subquery, as with any other query, is a set of rows—in this case, a set of CustomerID values. We know that only one value will be

M06_HOFF3359_13_GE_C06.indd 295 23/02/19 1:01 PM

296 Part III • Database Implementation and Use

in the result. (There is only one CustomerID for the order with OrderID 1008.) To be safe, you can—and probably should—use the IN operator rather than = when writing subqueries. The subquery approach may be used for this query because you need to display data from only the table in the outer query. The value for OrderID does not appear in the query result; it is used as the selection criterion in the inner query. To include data from the subquery in the result, use the join technique because data from a subquery cannot be included in the final results.

As noted previously, we know in advance that the preceding subquery will return at most one value, the CustomerID associated with OrderID 1008. The result will be empty if an order with that ID does not exist. (It is advisable to check that your query will work if a subquery returns zero, one, or many values.) A subquery can also return a list (set) of values (with zero, one, or many entries) if it includes the key word IN. Because the result of the subquery is used to compare with one attribute (CustomerID, in this query), the select list of a subquery may include only one attribute. For example, which cus- tomers have placed orders? Here is a query that will answer that question.

Query: What are the names of customers who have placed orders?

SELECT CustomerName FROM Customer_T WHERE CustomerID IN (SELECT DISTINCT CustomerID FROM Order_T);

This query produces the following result. As required, the subquery select list con- tains only the one attribute, CustomerID, needed in the WHERE clause of the outer query. Distinct is used in the subquery because we do not care how many orders a cus- tomer has placed, as long as they have placed an order. For each customer identified in the Order_T table, that customer’s name has been returned from Customer_T. (You will study this query again in Figure 6-8a.)

Result:

CUSTOMERNAME

Contemporary Casuals

Value Furniture

Home Furnishings

Eastern Furniture

Impressions

California Classics

American Euro Lifestyles

Battle Creek Furniture

Mountain Scenes

9 rows selected.

The qualifiers NOT, ANY, and ALL may be used in front of IN or with logical operators such as = , >, and <. Because IN works with zero, one, or many values from the inner query, many programmers simply use IN instead of = for all queries, even if the equals sign would work. The next example shows the use of NOT, and it also dem- onstrates that a join can be used in an inner query.

Query: Which customers have not placed any orders for computer desks?

SELECT CustomerName FROM Customer_T WHERE CustomerID NOT IN

M06_HOFF3359_13_GE_C06.indd 296 23/02/19 1:01 PM

6 • Advanced SQL 297

SELECT CustomerName FROM Customer_T

WHERE CustomerID NOT IN

(SELECT CustomerID FROM Order_T, OrderLine_T, Product_T

WHERE Order_T.OrderID 5 OrderLine_T.OrderID

AND OrderLine_T.ProductID 5 Product_T.ProductID

AND ProductDescription 5 ‘Computer Desk’);

1. The subquery (shown in the box) is processed first and an intermediate results table created. It returns the Customer ID for every customer that has purchased at least one computer desk.

CUSTOMERID 1 5 8

12 15

2. The main query is then processed and returns every customer who was NOT IN the subquery’s results.

CUSTOMERNAME Value Furniture Home Furnishings Eastern Furniture Furniture Gallery Period Furniture M and H Casual Furniture Seminole Interiors American Euro Lifestyles Heritage Furnishings Kaneohe Homes

CustomerIDs from orders for Computer Desks

All Customers

Show names

FIGURE 6-7 Using the NOT IN qualifier

(SELECT CustomerID FROM Order_T, OrderLine_T, Product_T WHERE Order_T.OrderID = OrderLine_T.OrderID AND OrderLine_T.ProductID = Product_T.ProductID AND ProductDescription = ‘Computer Desk’);

Result:

CUSTOMERNAME

Value Furniture

Home Furnishings

Eastern Furniture

Furniture Gallery

Period Furniture

M & H Casual Furniture

Seminole Interiors

American Euro Lifestyles

Heritage Furnishings

Kaneohe Homes

10 rows selected.

The result shows that 10 customers have not yet ordered computer desks. The inner query returned a list (set) of all customers who had ordered computer desks. The outer query listed the names of those customers who were not in the list returned by the inner query. Figure 6-7 graphically breaks out the results of the subquery and main query.

Qualifications such as < ANY or >= ALL instead of IN are also useful. For exam- ple, the qualification >= ALL can be used to match with the maximum value in a set.

M06_HOFF3359_13_GE_C06.indd 297 23/02/19 1:01 PM

298 Part III • Database Implementation and Use

But be careful: Some combinations of qualifications may not make sense, such as = ALL (which makes sense only when all the elements of the set have the same value).

Two other conditions associated with using subqueries are EXISTS and NOT EXISTS. These key words are included in an SQL query at the same location where IN would be, just prior to the beginning of the subquery. EXISTS will take a value of true if the subquery returns an intermediate result table that contains one or more rows (i.e., a nonempty set) and false if no rows are returned (i.e., an empty set). NOT EXISTS will take a value of true if no rows are returned and false if one or more rows are returned.

So, when do you use EXISTS versus IN, and when do you use NOT EXISTS ver- sus NOT IN? You use EXISTS (NOT EXISTS) when your only interest is whether the subquery returns a nonempty (empty) set (i.e., you don’t care what is in the set, just whether it is empty), and you use IN (NOT IN) when you need to know what values are (are not) in the set. Remember, IN and NOT IN return a set of values from only one column, which can then be compared to one column in the outer query. EXISTS and NOT EXISTS return only a true or false value depending on whether there are any rows in the answer table of the inner query or subquery.

Consider the following SQL statement, which includes EXISTS.

Query: What are the order IDs for all orders that have included furniture fin- ished in natural ash?

SELECT DISTINCT OrderID FROM OrderLine_T WHERE EXISTS (SELECT * FROM Product_T WHERE ProductID = OrderLine_T.ProductID AND ProductFinish = ‘Natural Ash’);

The subquery is different from the subqueries that you have seen before because it will include a reference to a column in a table specified in the outer query. The subquery is executed for each order line in the outer query. The subquery checks for each order line to see if the finish for the product on that order line is natural ash (indicated by the arrow added to the query above). If this is true (EXISTS), the outer query displays the order ID for that order. The outer query checks this one row at a time for every row in the set of referenced rows (the OrderLine_T table). There have been seven such orders, as the result shows. (You will learn more about this query further in Figure 6-8b.)

Result:

ORDERID

1001

1002

1003

1006

1007

1008

1009

7 rows selected.

When EXISTS or NOT EXISTS is used in a subquery, the select list of the subquery will usually just select all columns (SELECT *) as a placeholder because it does not mat- ter which columns are returned. The purpose of the subquery is to test whether any rows fit the conditions, not to return values from particular columns for comparison purposes in the outer query. The columns that will be displayed are determined strictly by the outer query. The EXISTS subquery illustrated previously, like almost all EXISTS subque- ries, is a correlated subquery, which is described next. Queries containing the key word NOT EXISTS will return a result table when no rows are found that satisfy the subquery.

M06_HOFF3359_13_GE_C06.indd 298 23/02/19 1:01 PM

6 • Advanced SQL 299

SELECT CustomerName

What are the names of customers who have placed orders?

FROM Customer_T WHERE CustomerID IN

1. The subquery (shown in the box) is 2. The outer query returns the requested processed first and an intermediate customer information for each customer results table created: included in the intermediate results table:

CUSTOMERID CUSTOMERNAME Contemporary Casuals

8 15 Home Furnishings 5 Eastern Furniture 3 2

11 American Euro Lifestyles 12 Battle Creek Furniture 4

9 rows selected. 9 rows selected.

(SELECT DISTINCT CustomerID FROM Order_T);

CustomerIDs from orders

All Customers

Show names

1 Value Furniture

Impressions California Classics

Mountain Scenes

FIGURE 6-8 Subquery processing

(a) Processing a noncorrelated subquery

In summary, use the subquery approach when qualifications are nested or when qualifications are easily understood in a nested way. Most systems allow pairwise join- ing 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 key word. Data can be displayed only from the table(s) referenced in the outer query. The number of levels of nesting supported vary depending on the RDBMS, but it is seldom a significant con- straint. Queries are processed from the inside out, although another type of subquery, a correlated subquery, is processed from the outside in.

Correlated Subqueries

In the first subquery example in the prior section, it was necessary to examine the inner query before considering the outer query. That is, the result of the inner query was used to limit the processing of the outer query. In contrast, correlated subqueries use the result of the outer query to determine the processing of the inner query. That is, the inner query is somewhat different for each row referenced in the outer query. In this case, the inner query must be computed for each outer row, whereas in the earlier examples, the inner query was computed only once for all rows processed in the outer query. The EXISTS subquery example in the prior section had this characteristic, in which the inner query was executed for each OrderLine_T row, and each time it was executed, the inner query was for a different ProductID value—the one from the OrderLine_T row in the outer query. Figures 6-8a and 6-8b depict the different processing order for each of the examples from the previous section on subqueries.

Let’s consider another example query that requires composing a correlated subquery.

Query: List the details about the product with the highest standard price.

SELECT ProductDescription, ProductFinish, ProductStandardPrice FROM Product_T PA WHERE PA.ProductStandardPrice > ALL (SELECT ProductStandardPrice FROM Product_T PB WHERE PB.ProductID ! = PA.ProductID);

Correlated subquery

In SQL, a subquery in which processing the inner query depends on data from the outer query.

M06_HOFF3359_13_GE_C06.indd 299 23/02/19 1:01 PM

300 Part III • Database Implementation and Use

(b) Processing a correlated subquery

*

2 4

SELECT DISTINCT OrderID FROM OrderLine_T WHERE EXISTS

(SELECT * FROM Product _T

WHERE ProductID 5 OrderLine_T.ProductID AND Productfinish 5 ‘Natural Ash’);

1

3

ProductID 1 2 3 4 5 6 7 8

(AutoNumber)

ProductDescription End Table Co�ee Table Computer Desk Entertainment Center Writer’s Desk 8-Drawer Dresser Dining Table Computer Desk

ProductFinish Cherry Natural Ash Natural Ash Natural Maple Cherry White Ash Natural Ash Walnut

ProductStandardPrice ProductLineID 10001 20001 20001 30001 10001 20001 20001 30001

What are the order IDs for all orders that have included furniture finished in natural ash?

$175.00 $200.00 $375.00 $650.00 $325.00 $750.00 $800.00 $250.00

$0.00

1. The first order ID is selected from OrderLine_T: OrderID 51001.

2. The subquery is evaluated to see if any product in that order has a natural ash finish. Product 2 does, and is part of the order. EXISTS is valued as true and the order ID is added to the result table.

3. The next order ID is selected from OrderLine_T: OrderID 51002.

4. The subquery is evaluated to see if the product ordered has a natural ash finish. It does. EXISTS is valued as true and the order ID is added to the result table.

5. Processing continues through each order ID. Orders 1004, 1005, and 1010 are not included in the result table because they do not include any furniture with a natural ash finish. The final result table is shown in the text on page 303.

FIGURE 6-8 (continued)

As you can see in the following result, the dining table has a higher unit price than any other product.

Result:

PRODUCTDESCRIPTION PRODUCTFINISH PRODUCTSTANDARDPRICE

Dining Table Natural Ash 800

The arrow added to the query above illustrates the cross-reference for a value in the inner query to be taken from a table in the outer query. The logic of this SQL state- ment is that the subquery will be executed once for each product to be sure that no other product has a higher standard price. Notice that we are comparing rows in a table to themselves and that we are able to do this by giving the table two aliases, PA and PB; you’ll recall we identified this earlier as a self-join. First, ProductID 1, the end table, will be considered. When the subquery is executed, it will return a set of values, which are the standard prices of every product except the one being considered in the outer query (product 1, for the first time it is executed). Then the outer query will check to see if the standard price for the product being considered is greater than all of the standard prices returned by the subquery. If it is, it will be returned as the result of the query. If not, the next standard price value in the outer query will be considered, and the inner query

M06_HOFF3359_13_GE_C06.indd 300 23/02/19 1:01 PM

6 • Advanced SQL 301

will return a list of all the standard prices for the other products. The list returned by the inner query changes as each product in the outer query changes; that makes it a cor- related subquery. Can you identify a special set of standard prices for which this query will not yield the desired result (see Problem and Exercise 6-77)?

Using Derived Tables

Subqueries are not limited to inclusion in the WHERE clause. They may also be used in the FROM clause to create a temporary derived table (or set) that is used in the query. Creating a derived table that has an aggregate value in it, such as MAX, AVG, or MIN, allows the aggregate to be used in the WHERE clause. Here, pieces of furniture that exceed the average standard price are listed.

Query: Show the product description, product standard price, and overall aver- age standard price for all products that have a standard price that is higher than the average standard price.

SELECT ProductDescription, ProductStandardPrice, AvgPrice FROM (SELECT AVG(ProductStandardPrice) AvgPrice FROM Product_T), Product_T WHERE ProductStandardPrice > AvgPrice;

Result:

PRODUCTDESCRIPTION PRODUCTSTANDARDPRICE AVGPRICE

Entertainment Center 650 440.625

8-Drawer Dresser 750 440.625

Dining Table 800 440.625

So, why did this query require a derived table rather than, say, a subquery? The reason is we want to display both the standard price and the average standard price for each of the selected products. The similar query in the prior section on correlated subqueries worked fine to show data from only the table in the outer query, the product table. However, to show both standard price and the average standard price in each displayed row, we have to get both values into the “outer” query, as is done in the query above. The use of derived queries simplifies many solutions and allows you to fulfill complex data requirements.

Combinings Queries

Sometimes, no matter how clever you are, you can’t get all the rows you want into the single answer table using one SELECT statement. Fortunately, you have a lifeline! The UNION clause is used to combine the output (i.e., union the set of rows) from multiple queries together into a single result table. To use the UNION clause, each query involved must output the same number of columns, and they must be UNION compatible. This means that the output from each query for each column should be of compatible data types. Acceptance as a compatible data type varies among the DBMS products. When performing a union where output for a column will merge two differ- ent data types, it is safest to use the CAST command to control the data type conver- sion yourself. For example, the DATE data type in Order_T might need to be converted into a text data type. The following SQL query would accomplish this:

SELECT CAST (OrderDate AS CHAR) FROM Order_T;

The following query determines the customer(s) who has in a given line item pur- chased the largest quantity of any Pine Valley product and the customer(s) who has in a given line item purchased the smallest quantity and returns the results in one table.

M06_HOFF3359_13_GE_C06.indd 301 23/02/19 1:01 PM