Data, Databases, and the Software Engineering ProcessDataBuilding a DatabaseWhat is the Software Engineering Process?Entity Relationship Diagrams and the Software Engineering Life Cycle Phase 1: Get the Requirements for the Database Phase 2: Specify the Database Phase 3: Design the DatabaseData and Data ModelsFiles, Records, and Data ItemsMoving from 3 x 5 Cards to ComputersDatabase Models The Hierarchical ModelThe Network ModelThe Relational Model The Relational Model and Functional DependenciesFundamental Relational DatabaseRelational Database and SetsFunctional DependencyNon-1NF to 1NFThe Second Normal Form Anomalies Non-2NF to 2NFThe Third Normal FormThe Equijoin OperationSome Functional Dependency RulesThe Boyce Codd Normal Form The Basic ER Diagram: A Data Modeling SchemaWhat Is a Data Modeling Schema? So, What Is an Entity Relationship Diagram?Defining a Database- Some Definitions: Entity, Relationship, Attribute A Beginning Methodology ER Design MethodologyA First "Entity-Only" ER Diagram: An Entity with AttributesMore about Attributes The Simple or Atomic Attribute The Composite Attribute The Multivalued Attribute The Derived Attribute KeysEnglish Description of the Entity The Method ER Design Methodology ExamplesMapping the Entity Diagram to a Relational DatabaseCase Study Beyond the First Entity DiagramExamining an Entity: Changing an Attribute to Be an EntityDefining a Relationship for Our New Entity ER Design MethodologyA Preliminary Grammar for the ER Diagrams The RelationshipDefining a Second EntityDoes a Relationship Exist?Attribute or Relationship? ER Design MethodologyCase Study Extending Relationships/Structural ConstraintsThe Cardinality Ratio of a Relationship One to One (1:1) Many to One (M:1) One to Many (1:M) Many to Many (M:N)Participation: Full/PartialEnglish DescriptionsTighter English Pattern 1-x:y::k:1 Pattern 2-x:y::k:1 Pattern 3-x:y::k:M Pattern 4-x:y::k:M Summary of the Patterns and Relationships ER Design MethodologySome Examples of Other Relationships An Example of the One-to-Many Relationship An Example of the Many-to-One Relationship An Example of the Many-to-Many Relationship One Final Example ER Design Methodology Pattern 1-M:1, from the M Side, Full Participation Pattern 3-1:M, from the 1 Side, Full ParticipationMapping Relationships to a Relational Database Mapping Binary M:N Relationships Mapping Binary 1:1 Relationships Mapping Binary 1:N RelationshipsCase Study The Weak EntityStrong and Weak EntitiesWeak Entities and Structural ConstraintsWeak Entities and the Identifying Owner Another Example of a Weak Entity and the Identifying OwnerWeak Entities Connected to Other Weak EntitiesRevisiting the MethodologyWeak Entity Grammar The KeysMapping Weak Entities to a Relational DatabaseCase Study Further Extensions for ER Diagrams with Binary RelationshipsAttributes of Relationships The AttributesRelationships Developing into Entities: The M:N Relationship Revisited The EntityMore Entities and Relationships More than Two EntitiesMore Evolution of the DatabaseAttributes that Evolve into EntitiesRecursive Relationships Recursive Relationships and Structural ConstraintsMultiple RelationshipsThe Derived or Redundant RelationshipOptional: An Alternative ER Notation for Specifying Structural Constraints on RelationshipsReview of the Methodology ER Design Methodology The Entity The Attributes The KeysMapping Rules for Recursive RelationshipsCase Study Ternary and Higher-Order ER DiagramsIntroductionBinary or Ternary Relationship?Structural Constraints for Ternary Relationships Many to Many to Many (M:M:M)An Example of an n-ary Relationshipn-ary Relationships Do Not Preclude Binary RelationshipsMethodology and Grammar for the n-ary Relationship A More Exact Grammar Grammar in a Partial Participation, Ternary Relationship with an M:1:M RelationshipTernary Relationships from Relationship-Relationship Situationsn-ary Relationships that May Be Resolved into Binary RelationshipsMapping n-ary Relationships to a Relational DatabaseReview of the Methodology ER Design Methodology The Enhanced Entity Relationship (EER) ModelIntroductionWhat Is a Generalization or Specialization?VariantsExamples of Generalizations or SpecializationsMethodology and Grammar for Generalization/Specialization RelationshipsMapping Rules for Generalizations and Specializations Mapping Rule 15 Mapping Rule 16 Mapping Rule 17 Mapping Rule 18 Subclasses of Subclasses Mapping Rule 19Categories or Union Types Participation Ratios in Categories or Union Types Mapping Categories or Union Types When Superclasses Have the Same Primary Keys Mapping Categories or Union Types When SuperclasseFinal ER Design Methodology ER Design MethodologyCase Study Relational Mapping and Reverse Engineering ER/EER DiagramsIntroductionSteps Used to Map ER/EER Diagrams to Relational DatabasesReverse Engineering Reverse Engineering Rule 1. Develop Strong Entities Reverse Engineering Rule 2. Look for 1:1 and 1:N (1:x) Relationships Reverse Engineering Rule 2a. Check for Attributes of the 1:x Relationship Reverse Engineering Rule 3. Look for Weak Entities and Multivalued Attributes Reverse Engineering Rule 3a. Checking for Weak Entities Reverse Engineering Rule 3b. Checking for Multivalued Attributes Reverse Engineering Rule 4. Check for M:N and n-ary Relationships Reverse Engineering Rule 4a. Check for the Binary Case Reverse Engineering Rule 4b. Check for the n-ary Case Reverse Engineering Rule 5. Check for Generalization/Specialization Relationships Have Different Primary Keys Reverse Engineering Rule 5a. Check for Generalization/Specialization Relationships with Disjoint or Overlap Relationships with Total or Partial Participation Constraints Reverse Engineering Rule 5b. Check for Disjoint Generalization/ Specialization Relationships with Single-Predicate-Defined Attributes Reverse Engineering Rule 5c. Check for Overlap Generalization/Specialization Relationship with More than One Flag Reverse Engineering Rule 6. Check for Shared Subclasses Reverse Engineering Rule 7. Check for Categories or Union Types A Brief Overview of the Barker/Oracle-Like ModelIntroductionA First "Entity-Only" ER Diagram: An Entity with AttributesAttributes in the Barker/Oracle-Like Model Optional versus Mandatory AttributesRelationships in the Barker/Oracle-Like ModelStructural Constraints in the Barker/Oracle-Like ModelDealing with the Concept of the Weak Entity in the Barker/Oracle-Like ModelDealing with the Concept of Multivalued Attributes in the Barker/Oracle-Like ModelTreatment of Foreign KeysRecursive Relationships in the Barker/Oracle-Like ModelMapping M:N RelationshipsGlossaryIndex Each chapter includes an introduction, chapter summary, exercises, and a bibliography
Dr. Sikha Saha Bagui is an associate professor and interim associate chair in the Department of Computer Science at the University of West Florida, Pensacola, Florida. She teaches a variety of computer science and database courses, and her research areas of concentration are database design, web databases, data mining and statistical computing. Dr. Bagui has published many journal articles and co-authored several books with Dr. Earp. Dr. Richard Walsh Earp, Professor Emeritus, is a former chair of and former associate professor in the Department of Computer Science and former dean of the College of Science and Technology at the University of West Florida in Pensacola, Florida. Dr. Earp was also an instructor with Learning Tree International and worked for Computer Sciences Corporation at the Naval Air Station in Pensacola as a database consultant after his retirement from academia. He has co-authored several books with Dr. Bagui.