Databases Chapter 1 - Database Design
Databases Chapter 1 - Database Design
Chapter 1
Entities:
In database design, an entity is an object or concept that you want to store data about. Entities
help organize the database by grouping related information together. Each entity will usually
correspond to a table in the database.
Example:
You might create an entity (a table) named Students, that stores information about students,
such as their name, student ID, date of birth.
The Course entity might store details about courses, such as the course name, course code, and
description.
Rows (Records):
A row, also called a record, is a single, unique entry within a table that represents a specific
instance of an entity. If a table is like a spreadsheet, each row is like a separate line in that
spreadsheet that contains data about one specific item or individual. Rows store the actual data
in a table. Each row is unique and represents one record of an entity.
Example:
Considering the previous example, in a Student entity/table, each row would represent a
different student:
- Row 1: John Smith, student ID 001, born on 2005-05-21
- Row 2: Emily Jones, student ID 002, born on 2006-08-15
Columns (Fields):
A column, also called a field, defines a specific type of information within a table. Columns run
vertically and are shared by all rows in the table, so each column holds the same type of data
for each record. Columns define what information each record should contain. By structuring
data into fields, the database ensures that each record is consistent and organized.
Example:
Considering the previous example, in a Student entity/table, columns could include:
- Student name
- Student ID
- Date of Birth
Primary Key:
A Primary Key is a unique identifier for each record (or row) in a table. No two records in a
table can have the same primary key value, and a primary key cannot be empty (null). The
primary key ensures that each row in the table is unique, making it easy to identify and retrieve
specific records. It also helps establish relationships between tables in the database.
Example:
A good primary key might be the Student ID, because each student has a unique ID. For
instance:
Composite Key:
A Composite Key is a primary key that consists of two or more columns (fields) combined to
create a unique identifier for each record. This is used when a single column isn’t enough to
uniquely identify records. Composite keys are useful when a unique identifier can only be
achieved by combining multiple pieces of information. They’re often used in tables that store
relationships between entities.
Example:
In an Enrollment table (representing students enrolling in courses), a composite key might
consist of both Student ID and Course ID. Here’s why:
Each student can take multiple courses, and each course can have multiple students. Using
Student ID alone or Course ID alone wouldn’t be unique because a student can appear multiple
times (once for each course they’re enrolled in), and a course can appear multiple times (once
for each student enrolled).
By combining Student ID and Course ID as a composite key, you ensure each record in the
Enrollment table is unique. For example:
Student ID 001 + Course ID 1001 uniquely identifies that John Smith is enrolled in Math.
Student ID 001 + Course ID 1002 uniquely identifies that John Smith is also enrolled in Science.
Data types:
We need to make sure to choose a data type that we need while using as few bytes a possible.
If you know a number range is going to be smaller, you may want to use a smaller number value
to use fewer bytes over all for storage.
Entity Relationships:
Primary key recap:
The primary key enables easy identification and retrieval of each record. It also helps establish
relationships between tables by acting as a reference point for other tables.
Foreign key:
A field in one table that links to the primary key of another table. This field is called a foreign
key in the "child" table (the table that references another table). Foreign keys let tables connect
with each other, which is important for keeping data organized across different parts of a
database.
Example:
Suppose you have a Student table and an Enrollment table. If Student ID is the primary key in
the Student table, it can be used as a foreign key in the Enrollment table to link each
enrollment record to a specific student.
Example: A Customer table linked to an Order table, where each customer can have multiple
orders, but each order is placed by one customer.
Many-to-Many: Each record in Table A can be related to multiple records in Table B, and each
record in Table B can also be linked to multiple records in Table A.
Example: A Student table linked to a Course table, where each student can enroll in multiple
courses, and each course can have multiple students.
When referential integrity is enforced, any value in a foreign key column must match a valid
primary key value in the referenced table. If you try to add a record in a table with a foreign key
that doesn’t have a corresponding primary key in the related table, the database will reject it.
Example:
If Student ID is a primary key in the Student table and a foreign key in the Enrollment table:
- If you try to add an Enrollment record for Student ID 999 (assuming there is no student
with this ID in the Student table), the database will prevent it to maintain referential
integrity.
- This ensures all enrollments reference actual students, preventing data inconsistencies
and "orphan" records.
Normalization:
Normalization is a process used in database design to organize data in a way that reduces
redundancy (duplicate data) and improves data integrity. By dividing data into smaller, related
tables and setting up relationships between them, normalization helps ensure that the
database is efficient, easier to maintain, and free of unnecessary duplicates.
The goal of normalization is to structure the database so that each piece of data is stored in
only one place, minimizing inconsistencies and making it easier to update data across the
database.
Normalization is divided into several levels, called normal forms. Each normal form builds upon
the previous one, adding more rules to refine the structure.
Boyce-Codd Normal Form (BCNF) - A table is in Boyce-Codd Normal Form (BCNF) if:
- It meets all the requirements of 3NF.
- Every determinant is a candidate key. (A determinant is any column or group of columns
that can uniquely determine the values in another column.)
BCNF is a stricter version of 3NF, handling special cases where 3NF might still allow for some
redundancy.
Fourth Normal Form (4NF) - A table is in Fourth Normal Form (4NF) if:
- It meets all the requirements of BCNF.
- It has no multi-valued dependencies. This means that a record should not have two or
more independent sets of multi-valued data.
4NF further reduces redundancy by ensuring that each record contains only one independent
set of related data.
Backups:
Creating regular backups helps ensure data can be restored in case of accidental deletion,
corruption, or other issues.
To backup a database, you should do the following process:
Go to DataBaseName > Tasks > Back Up > OK.
Restore:
Restoring is the process of using a backup to recover lost or damaged data, returning the
database to its previous state. Restore operations bring the database back to a previous state.
Restoring overwrites existing data, so regular backups are crucial.
To restore a database, you should do the following process:
Revoking Permissions: