x Contents 2.2 Advanced ER Constructs 23 2.2.1 Generalization: Supertypes and Subtypes 23 2.2.2 Aggregation 25 2.2.3 Ternary Relationships 25 2.2.4 General n-ary Relationships 28 2.2.5 Exclusion Constraint 29 2.2.6 Referential Integrity 30 2.3 Summary 30 2.4 Literature Summary 31 Chapter 3 The Unified Modeling Language (UML) 33 3.1 Class Diagrams 34 3.1.1 Basic Class Diagram Notation 35 3.1.2 Class Diagrams for Database Design 37 3.1.3 Example from the Music Industry 43 3.2 Activity Diagrams 46 3.2.1 Activity Diagram Notation Description 46 3.2.2 Activity Diagrams for Workflow 48 3.3 Rules of Thumb for UML Usage 50 3.4 Summary 51 3.5 Literature Summary 51 Chapter 4 Requirements Analysis and Conceptual Data Modeling 53 4.1 Introduction 53 4.2 Requirements Analysis 54 4.3 Conceptual Data Modeling 55 4.3.1 Classify Entities and Attributes 56 4.3.2 Identify the Generalization Hierarchies 57 4.3.3 Define Relationships 58 4.3.4 Example of Data Modeling: Company Personnel and Project Database 61 4.4 View Integration 66 4.4.1 Preintegration Analysis 67 4.4.2 Comparison of Schemas 68 4.4.3 Conformation of Schemas 68 Teorey.book Page x Saturday, July 16, 2005 12:57 PM Contents xi 4.4.4 Merging and Restructuring of Schemas 69 4.4.5 Example of View Integration 69 4.5 Entity Clustering for ER Models 74 4.5.1 Clustering Concepts 75 4.5.2 Grouping Operations 76 4.5.3 Clustering Technique 78 4.6 Summary 81 4.7 Literature Summary 82 Chapter 5 Transforming the Conceptual Data Model to SQL 83 5.1 Transformation Rules and SQL Constructs 83 5.1.1 Binary Relationships 85 5.1.2 Binary Recursive Relationships 90 5.1.3 Ternary and n-ary Relationships 92 5.1.4 Generalization and Aggregation 101 5.1.5 Multiple Relationships 103 5.1.6 Weak Entities 103 5.2 Transformation Steps 103 5.2.1 Entity Transformation 104 5.2.2 Many-to-Many Binary Relationship Transformation 104 5.2.3 Ternary Relationship Transformation 105 5.2.4 Example of ER-to-SQL Transformation 105 5.3 Summary 106 5.4 Literature Summary 106 Chapter 6 Normalization 107 6.1 Fundamentals of Normalization 107 6.1.1 First Normal Form 109 6.1.2 Superkeys, Candidate Keys, and Primary Keys 109 6.1.3 Second Normal Form 111 6.1.4 Third Normal Form 113 6.1.5 Boyce-Codd Normal Form 115 6.2 The Design of Normalized Tables: A Simple Example 116 6.3 Normalization of Candidate Tables Derived from ER Diagrams 118 Teorey.book Page xi Saturday, July 16, 2005 12:57 PM xii Contents 6.4 Determining the Minimum Set of 3NF Tables 122 6.5 Fourth and Fifth Normal Forms 127 6.5.1 Multivalued Dependencies 127 6.5.2 Fourth Normal Form 129 6.5.3 Decomposing Tables to 4NF 132 6.5.4 Fifth Normal Form 133 6.6 Summary 137 6.7 Literature Summary 138 Chapter 7 An Example of Logical Database Design 139 7.1 Requirements Specification 139 7.1.1 Design Problems 140 7.2 Logical Design 141 7.3 Summary 145 Chapter 8 Business Intelligence 147 8.1 Data Warehousing 148 8.1.1 Overview of Data Warehousing 148 8.1.2 Logical Design 152 8.2 Online Analytical Processing (OLAP) 166 8.2.1 The Exponential Explosion of Views 167 8.2.2 Overview of OLAP 169 8.2.3 View Size Estimation 170 8.2.4 Selection of Materialized Views 173 8.2.5 View Maintenance 176 8.2.6 Query Optimization 177 8.3 Data Mining 178 8.3.1 Forecasting 179 8.3.2 Text Mining 181 8.4 Summary 185 8.5 Literature Summary 186 Teorey.book Page xii Saturday, July 16, 2005 12:57 PM Contents xiii Chapter 9 CASE Tools for Logical Database Design 187 9.1 Introduction to the CASE Tools 188 9.2 Key Capabilities to Watch For 191 9.3 The Basics 192 9.4 Generating a Database from a Design 196 9.5 Database Support 199 9.6 Collaborative Support 200 9.7 Distributed Development 201 9.8 Application Life Cycle Tooling Integration 202 9.9 Design Compliance Checking 204 9.10 Reporting 206 9.11 Modeling a Data Warehouse 207 9.12 Semi-Structured Data, XML 209 9.13 Summary 211 9.14 Literature Summary 211 Appendix: The Basics of SQL 213 Glossary 231 References 239 Exercises 249 Solutions to Selected Exercises 259 About the Authors 263 Index 265 Teorey.book Page xiii Saturday, July 16, 2005 12:57 PM 1 1 Introduction atabase technology has evolved rapidly in the three decades since the rise and eventual dominance of relational database systems. While many specialized database systems (object-oriented, spatial, mul- timedia, etc.) have found substantial user communities in the science and engineering fields, relational systems remain the dominant database technology for business enterprises. Relational database design has evolved from an art to a science that has been made partially implementable as a set of software design aids. Many of these design aids have appeared as the database component of computer-aided software engineering (CASE) tools, and many of them offer interactive modeling capability using a simplified data modeling approach. Logical design—that is, the structure of basic data relation- ships and their definition in a particular database system—is largely the domain of application designers. These designers can work effectively with tools such as ERwin Data Modeler or Rational Rose with UML, as well as with a purely manual approach. Physical design, the creation of efficient data storage and retrieval mechanisms on the computing plat- form being used, is typically the domain of the database administrator (DBA). Today’s DBAs have a variety of vendor-supplied tools available to help design the most efficient databases. This book is devoted to the logical design methodologies and tools most popular for relational databases today. Physical design methodologies and tools are covered in a separate book. D Teorey.book Page 1 Saturday, July 16, 2005 12:57 PM . Tools for Logical Database Design 187 9.1 Introduction to the CASE Tools 188 9.2 Key Capabilities to Watch For 191 9.3 The Basics 192 9.4 Generating a Database from a Design 196 9.5 Database Support. available to help design the most efficient databases. This book is devoted to the logical design methodologies and tools most popular for relational databases today. Physical design methodologies. dominant database technology for business enterprises. Relational database design has evolved from an art to a science that has been made partially implementable as a set of software design aids. Many