Scribd
Upload
29 views6 pages

Module 3.0 PDF

Uploaded by

Nitya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
29 views6 pages

Module 3.0 PDF

Uploaded by

Nitya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

DATABASE MANAGEMENT SYSTEM

MCA 104
Module-3
3.0 Relational Database Design
features of good relational database design:
A good relational database design should exhibit certain
features that ensure data integrity, efficiency, and ease of
maintenance. Here are some key features of a well-designed
relational database:

 Normalization: The database should be properly


normalized to eliminate data redundancy and improve
data integrity. Normalization reduces the risk of data
anomalies and ensures that each piece of data is stored in
only one place, minimizing the chance of inconsistencies.

 Appropriate Use of Keys: Primary keys should be carefully


chosen for each table to uniquely identify each record.
Foreign keys should establish relationships between tables,
ensuring referential integrity.

 Data Integrity Constraints: The database design should


incorporate data integrity constraints, such as unique
constraints, foreign key constraints, and check constraints.
These constraints help enforce business rules and prevent
the entry of invalid or inconsistent data.

 Consistent Naming Conventions: Adopting consistent and


descriptive naming conventions for tables, columns, and
other database objects improves the understandability of
the database schema and eases maintenance.

 Scalability: A good database design should be scalable,


allowing for the addition of new data and accommodating
increased user load without significant performance
degradation.

 Backup and Recovery Considerations: The design should


incorporate strategies for regular backups and disaster
recovery to protect against data loss and ensure business
continuity.

 Security Measures: Database security measures, such as


access control, encryption, and data masking, should be
integrated into the design to protect sensitive data from
unauthorized access.
 Data Partitioning: For large databases, partitioning data
across different physical storage locations can enhance
performance, backup, and maintenance operations.

 Concurrency Control: The database design should address


concurrency control to handle multiple users accessing and
modifying data simultaneously without data
inconsistencies or conflicts.
Design Alternatives: large schema and smaller Schema
In the context of relational database design, the terms "large
schema" and "smaller schema" refer to two different
approaches to organizing the structure of a database. Let's
define each of them:
Large Schema:

 A large schema in relational database design refers to an


approach where the database is designed with a higher
degree of normalization. It involves breaking down the
data into a larger number of smaller, more specialized
tables.

 Example - Large Schema: Library Database


Entities:
Books (BookID [PK], Title, AuthorID [FK], ISBN, PublicationDate)
Authors (AuthorID [PK], FirstName, LastName)
In this example, the database follows a large schema approach
with separate tables for "Books" and "Authors." The "AuthorID"
in the "Books" table acts as a foreign key (FK), linking the books
to their respective authors in the "Authors" table. This design
ensures data integrity and minimizes data duplication. For
instance, if an author publishes multiple books, their details
need to be entered only once in the "Authors" table, reducing
redundancy.
Smaller Schema:

 In contrast, a smaller schema in relational database design


refers to an approach where the database is designed with
a lower degree of normalization. It involves combining
related data into fewer, more generalized tables.

 Example - Smaller Schema: E-commerce Database

Entities:
Products (ProductID [PK], ProductName, Category, Price, Brand)
Orders (OrderID [PK], Order Date, Customer Name, Customer
Email)
Order Details (Order DetailID [PK], OrderID [FK], ProductID [FK],
Quantity, Unit Price)
In this example, the database follows a smaller schema
approach by combining data from multiple entities into
denormalized tables. The "Orders" table contains both
customer information and order details. The "OrderDetails"
table stores information about products ordered, including the
quantity and unit price. While this design may result in some
data redundancy (e.g., customer information being repeated in
multiple orders), it simplifies query complexity, making it easier
to retrieve order details and product information in a single
query without numerous joins.
Choosing between a large schema and a smaller schema
depends on the specific requirements of the application and
the nature of the data being stored. Large schemas are
generally preferred for applications where data integrity and
consistency are critical, such as financial systems or data
warehouses. On the other hand, smaller schemas may be more
suitable for applications where read performance is a higher
priority, such as web applications with a large number of
concurrent users.

You might also like