Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
19 views

Databases Chapter 1 - Database Design

Uploaded by

Bucataru Gabby
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views

Databases Chapter 1 - Database Design

Uploaded by

Bucataru Gabby
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

Databases

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:

 Student ID 001 represents John Smith.


 Student ID 002 represents Emily Jones.

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.

Primary Key and Foreign Key Relationship:


The primary key uniquely identifies records in one table, while the foreign key in a different
table references these unique records. This way, databases enforce data consistency by
ensuring each foreign key value corresponds to an existing primary key.
Types of Relationships Between Tables:
One-to-One: Each record in Table A is related to one and only one record in Table B, and vice
versa.
Example: A Person table linked to a Passport table, where each person has only one passport.
One-to-Many: Each record in Table A can be related to multiple records in Table B, but each
record in Table B is linked to only one record in Table A.

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.

Entity-Relationship Diagrams (ERDs):


An Entity-Relationship Diagram (ERD) is a visual tool used to illustrate the structure of a
database. ERDs help visualize how entities in a database are connected. They are especially
helpful during the design phase of database creation, as they make it easier to plan and
understand data relationships.
Referential Integrity:
Referential Integrity is a rule that ensures data consistency between tables by enforcing valid
relationships between primary and foreign keys. Referential integrity prevents data errors. For
example, it stops you from adding an entry in a related table (like Enrollment) that refers to a
non-existent record in another table (like a Student that doesn’t exist).

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.

First Normal Form - A table is in First Normal Form (1NF) if:


- All columns contain atomic (indivisible) values. This means each column should have
only one value per row, with no repeating groups or arrays.
- Each column contains only one type of data (e.g., all values in a column should be
integers, text, dates, etc.).
1NF eliminates duplicate groups of data within a table.
Second Normal Form - A table is in Second Normal Form (2NF) if:
- It meets all the requirements of 1NF.
- It has no partial dependencies. This means that all non-key columns should depend on
the whole primary key, not just part of it. (This is relevant only if the table has a
composite primary key, meaning a primary key that consists of multiple columns).
2NF removes redundant data that is partially dependent on a part of a composite key, which
can prevent issues with data duplication and inconsistencies.

Third Normal Form - A table is in Third Normal Form (3NF) if:


- It meets all the requirements of 2NF.
- It has no transitive dependencies. This means that non-key columns should depend only
on the primary key and not on other non-key columns.
3NF removes dependencies that are not directly related to the primary key, further reducing
data duplication and promoting data consistency.

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:

Go to DataBaseName > Tasks > Restore > Database > OK.

Setting Permissions on Databases and Tables:


Database Permissions:
Go to DataBaseName > Properties > Permissions > OK.
Table Permissions:
Go to TableName > Properties > Permissions > OK.

Granting Permissions to Users:


GRANT EXECUTE ON GetDepartment TO procTester WITH GRANT OPTION;
This command grants the procTester user permission to execute procedures on the
GetDepartment object.
WITH GRANT OPTION allows procTester to grant the same permission to other users or groups.

Revoking Permissions:

REVOKE EXECUTE ON GetDepartment TO procTester CASCADE;


CASCADE removes the ability of procTester to grant permission to others, fully revoking their
access. Revoking permissions is essential for security, preventing unnecessary or harmful
access.
Server Roles (From Most to Least Powerful):
1. sysadmin - Can perform any activity on the server.
2. serveradmin - Can modify server configurations and shut down the server.
3. securityadmin - Can grant and revoke server-level permissions, as well as database
permissions where allowed.
4. processadmin - Can end running processes on the server (e.g., stopping a lengthy
backup process).
5. setupadmin - Can add or remove linked servers, enabling cross-server data queries.
6. bulkadmin - Can use bulk insert statements to import large datasets into the database.
7. diskadmin - Can manage disk files.
8. dbcreator - Can create, alter, delete, and restore databases.
9. public - This role is assigned to all users by default. Permissions granted to public apply
to anyone on the server, so permissions should be minimal to avoid security risks.

Database Roles (From Most to Least Powerful):


1. db_owner - Has full control over the database, including the ability to delete it.
2. db_securityadmin - Manages membership of custom roles and overall permissions
within the database.
3. db_accessadmin - Adds or removes access for Windows and SQL accounts in the
database.
4. db_backupoperator - Can back up the database.
5. db_ddladmin - Can run Data Definition Language (DDL) commands, such as creating,
altering, and deleting tables.
6. db_datawriter - Can add, modify, and delete data within tables.
7. db_datareader - Can read data from tables and views.
8. db_denydatawriter - Prevents users from adding, modifying, or deleting data.
9. db_denydatareader - Prevents users from reading data in tables and views.
10. public - Like the server-level role, this database role is automatically assigned to all
users, so be cautious about granting permissions.

Principle of Least Privilege (PoLP):


The Principle of Least Privilege means granting users only the minimum access they need to
perform their tasks. This reduces the risk of accidental or malicious actions that could
compromise data integrity, privacy, or security.

You might also like