Data Modeling Advanced Concepts & Database tables and Normalization

Data Modeling Advanced Concepts

Data modeling is an essential aspect of designing efficient and effective databases. While basic data
modeling focuses on understanding entities, attributes, and relationships, advanced data modeling dives into more
complex concepts such as the Extended Entity Relationship (EER) model, entity clustering, and entity
integrity. This guide will walk through these advanced concepts, offering insights and examples.
1. The Extended Entity Relationship (EER) Model
The Extended Entity Relationship (EER) Model is an enhancement of the basic Entity Relationship (ER) model.
The EER model incorporates additional concepts to handle complex relationships and more detailed structures
within a database.
Key Features of the EER Model:
 Generalization & Specialization:
o Generalization: The process of combining several lower-level entities into a higher-level entity (a
parent entity).
o Specialization: The process of dividing a higher-level entity into lower-level entities (child
entities).
 Aggregation:
o Involves grouping multiple entities together to model a higher-level entity. This is useful when an
entity is involved in a relationship with another entity, and you want to treat them as a whole
entity for easier management.
 Weak Entities:
o Weak entities depend on other entities for identification and don't have a unique key by
themselves. They must have a relationship with a strong (or regular) entity to be fully defined.
 Inheritance:
o Inheritance allows child entities to inherit attributes and relationships from parent entities, making
the design more flexible.
Example of an EER Model:
Consider a Library System:
 Generalization: A Book and a Magazine can both be generalized as Publication. Both share common
attributes like title, author, and publication year.
 Specialization: The Publication entity could be specialized into Hardcover and Paperback, based on the
type of binding.
Diagram:
 Publication (Generalization) → Book, Magazine
 Publication (Attributes: Title, Author, Year Published)
2. Entity Clustering
Entity Clustering is an advanced data modeling technique used to group related entities together to simplify
complex relationships. It’s especially useful when a large number of entities are involved, and grouping them into
clusters can enhance manageability, scalability, and performance.
When to Use Entity Clustering:
 When you have many entities with complex relationships.
 To avoid excessive complexity in ER diagrams by grouping related entities and their relationships.
Example:
Consider a Retail Store:
 Entities: Products, Customers, Orders, Inventory.
 By using entity clustering, you can group related entities, such as Product and Inventory, into a cluster
representing the Product Stock, making the database more structured and easier to manage.
Clustering Example:
 Cluster 1: Product and Inventory
 Cluster 2: Customer and Order
 Cluster 3: Supplier and Product (if there’s a supplier relationship).

3. Entity Integrity: Selecting Primary Keys

Entity Integrity is a fundamental concept in relational database design. It ensures that every entity has a unique
identifier, known as the Primary Key. The primary key guarantees that each record in a table is unique and can be
distinguished from others.
Primary Key Selection:
Choosing the right primary key is critical to ensuring the integrity and performance of a database. A primary key
must:
 Uniqueness: Each value must be unique across the table.
 Non-null: Every entity must have a primary key value; null values are not allowed.
 Minimal: The primary key should consist of the smallest number of attributes necessary to uniquely
identify an entity.
Types of Primary Keys:
 Natural Key (Business Key): A key that has a real-world meaning (e.g., a Social Security Number or
ISBN).
 Surrogate Key: A system-generated key that has no business meaning (e.g., a unique ID generated by the
database).
Example of Primary Key Selection:
Consider a Student table:
 Natural Key: Student_ID (a student’s university-issued ID number).
  Surrogate Key: A system-generated Student_PK (e.g., a number automatically assigned by the database).

4. Design Cases: Flexible Database Design

A flexible database design refers to designing databases that can evolve with changing business requirements. It’s
about creating a structure that is adaptable to new features, data sources, and types of data, without needing major
redesigns.
Key Principles of Flexible Database Design:
 Scalability: The ability to handle growing data without significant performance degradation.
 Adaptability: The database should be flexible enough to accommodate new data elements or relationships.
 Maintainability: Easy to modify, extend, and maintain as requirements change over time.
 Normalization vs. Denormalization: While normalization reduces redundancy, denormalization can
sometimes be used for performance reasons.
Case 1: Online Shopping System
 Initially, an e-commerce database might store customers, orders, products, and payments.
 Over time, the business may need to support new types of products (e.g., digital products), incorporate a
loyalty points system, and introduce a return process.
 A flexible database design might include:
o Use of generalization to group different types of products.
o Adding an entity for loyalty programs and using inheritance to extend the customer entity.
Case 2: Social Media Platform
 The platform begins with a basic database structure for users, posts, and comments.
 As it grows, the design must adapt to include new features like:
o User groups or communities.
o Privacy settings for posts.
o Media attachments (images, videos).
 The flexible design would allow the introduction of new entities and relationships without disrupting
existing data.

Database Tables and Normalization

Introduction to Database Tables: A database table consists of rows and columns. The columns represent the
attributes of the data, and each row represents a record. The design of these tables should ensure that data is stored in
an efficient, non-redundant manner to improve performance and avoid anomalies.
1. The Need for Normalization
Normalization is a technique used to design a relational database schema that minimizes redundancy and
dependency by organizing fields and tables in such a way that dependencies are properly enforced.
Why Normalize?
 Avoid Data Redundancy: Redundant data increases storage requirements and the potential for
inconsistent data.
 Eliminate Anomalies: Redundancies lead to update, insert, and delete anomalies.
 Improve Data Integrity: Ensures that each piece of data is stored in only one place.
Example of Data Redundancy:
Order_ID Customer_Name Customer_Address Product_Name Product_Price Quantity
1 John Doe 123 Elm St Laptop 1200 2
2 John Doe 123 Elm St Phone 800 1
Problem:
 Redundant customer information for each order.
 Customer's address is repeated, which leads to storage inefficiencies.
2. The Normalization Process
Normalization involves several stages (normal forms), each focusing on eliminating different kinds of redundancy
and ensuring data integrity.
First Normal Form (1NF):
 Eliminate repeating groups and ensure each column contains atomic values (i.e., indivisible values).
 Example: A column for multiple products in an order should be split into separate rows.

Second Normal Form (2NF):

 Meet the requirements of 1NF.
 Eliminate partial dependencies (i.e., when non-key columns depend on part of a composite primary key).
 Example: If you have a composite primary key like (Order_ID, Product_ID), and an attribute like
Product_Price depends only on Product_ID, it violates 2NF.
Third Normal Form (3NF):
 Meet the requirements of 2NF.
 Eliminate transitive dependencies (i.e., when a non-key column depends on another non-key column).
 Example: If Customer_Address depends on Customer_Name, but Customer_Name is already dependent
on Customer_ID, it violates 3NF.
Boyce-Codd Normal Form (BCNF):
  A stricter version of 3NF that eliminates every kind of dependency based on non-trivial functional
dependencies.
Fourth Normal Form (4NF):
 Meet the requirements of 3NF.
 Eliminate multi-valued dependencies (where one attribute is dependent on multiple independent attributes).
3. Improving the Design
The normalization process improves the database design by:
 Reducing Redundancy: Breaking tables into smaller, related entities to avoid repeating the same data.
 Increasing Flexibility: Normalized tables can handle a variety of queries without the risk of introducing
inconsistencies.
 Enhancing Query Performance: While normalization may initially decrease performance due to the need
for more joins, it eventually leads to better overall performance through more efficient data retrieval and
updates.
Example: Consider a non-normalized database where a customer’s multiple orders are stored in a single table. After
normalization, the customer information and order information are stored in separate tables with a relationship
between them.
4. Surrogate Key Considerations
A surrogate key is a unique identifier for a record in a table that has no meaning outside the database. Surrogate keys
are often used in place of natural keys (keys that have real-world meaning).
Advantages of Surrogate Keys:
 No Change Over Time: Surrogate keys don't change, even if other attributes (e.g., customer name) do.
 Simplified Primary Keys: Surrogate keys are typically smaller in size and have no business logic tied to
them.
Example: Instead of using a customer’s phone number as a primary key, you can create a surrogate key (like
Customer_ID).
5. Higher-Level Normal Forms
 Fifth Normal Form (5NF): Focuses on removing join dependencies and ensures that data is stored without
unnecessary redundancy.
 Sixth Normal Form (6NF): Deals with temporal data and decomposition of relations to handle time-
varying data.
6. Normalization and Database Design
The goal of normalization in database design is to create a structure that supports the required data integrity,
minimizes redundancy, and ensures flexibility in querying. However, over-normalization can lead to performance
issues.

For example:
  Normalized Schema: In a normalized schema, the customer table would store customer details, and the
order table would store orders. A Customer_ID would serve as the foreign key in the order table.
 De-normalized Schema: In a denormalized schema, customer details might be repeated in each order
record to speed up query performance (at the cost of potential data anomalies).
7. Denormalization
Denormalization is the process of deliberately introducing redundancy into a database schema by merging
tables or storing redundant data to improve query performance.

Why Denormalize?
 Performance Improvement: Sometimes, normalized databases require complex joins, which can slow
down query performance.
 Faster Data Retrieval: By denormalizing, queries can be optimized to reduce the number of joins
required, leading to faster data retrieval.
Example: In an order database:
 Normalized: The customer table stores customer info, and the orders table stores order info with a
Customer_ID as a foreign key.
 Denormalized: Customer information is duplicated in the order table, so each order record includes
customer details.
Real-World Example:
Consider an e-commerce system with three entities: Customers, Orders, and Products.
1. Non-Normalized Design:
Order_ID Customer_Name Customer_Address Product_Name Product_Price Quantity
1 John Doe 123 Elm St Laptop 1200 2
2 Jane Smith 456 Oak St Phone 800 1
2. First Normal Form (1NF):
In 1NF, we ensure atomicity. If we were storing multiple products per order, we would split them:
Order_ID Customer_Name Customer_Address Product_Name Product_Price Quantity
1 John Doe 123 Elm St Laptop 1200 2
1 John Doe 123 Elm St Phone 800 1
2 Jane Smith 456 Oak St Laptop 1200 1
3. Second Normal Form (2NF):
We split the customer information into a separate table to remove partial dependencies:

Customers Table:
 Customer_ID Customer_Name Customer_Address
1 John Doe 123 Elm St
2 Jane Smith 456 Oak St
Orders Table:
Order_ID Customer_ID Product_Name Product_Price Quantity
1 1 Laptop 1200 2
1 1 Phone 800 1
2 2 Laptop 1200 1
4. Third Normal Form (3NF):
To further normalize, ensure that no transitive dependencies exist (e.g., customer address should not depend on
customer name):
Customers Table:
Customer_ID Customer_Name Customer_Address
1 John Doe 123 Elm St
2 Jane Smith 456 Oak St
Orders Table:
Order_ID Customer_ID Product_Name Product_Price Quantity
1 1 Laptop 1200 2
1 1 Phone 800 1
2 2 Laptop 1200 1