InjibaraUniversity

College of Engineering and Technology

Department of Software Engineering

Fundamentals of database system (Seng4021/Comp3021)

Assignment I: for only Regular Software Engineering and Statistics

students Maximum Weight=30%

Scenario 1: Read the next case study and do the following questions

Consider a database system to be developed for “XYZ Software Share Company”. The following are brief
and short listed structures of the company. The company runs various projects with a total of 68 full-time
employees and over 120 part-time employees. A project has a unique id and a name that may be
designed for a new software development or for a release of a new version of software that had been
developed by the company. The projects are having start date, due date, complete date and status that
describe their progress. Every project is lead by a senior manager organized into teams of five to eight
programmers coordinated by a team leader. The owners of the projects are the customers of the
company. A single customer can own one or more projects. The customers have unique id, name and
address. The company is organized into departments that are identified by a unique name and lead by
department heads. A department head can only lead a single department in his/her employment by the
company. An employee can only belong to one department. Every employee is identified by an Id, a
name, an address, and a position. In addition full-time employees have monthly salary and allowance
rate; and part-time employees have contract period and hourly rate. Working schedule of both full-time
employees and part-time employees is maintained on weekly bases.

Questions: Based on the above three scenario, do the next Seven(7)activities accordingly.

1. List and describe the entity and its type with clear justification?(2 Mark)
Based on the above scenario we identified five entities with description and justification.

1. Employee

1.Type: Entity

Description: This entity represents the individuals who work for the company, including both
full-time and part-time employees. An employee has unique attributes: an ID, a name, an
address, and a position. In this scenario, the distinction between full-time and part-time
employees adds additional attributes specific to their employment types.

1 / 44
 Justification: The employee entity is fundamental to the database as it captures the main
resource (the workforce) for the company. Each employee has unique characteristics and roles
that are necessary for project assignments and team organization.

2. Project

 Type: Entity
 Description: A project entity represents initiatives undertaken by the company, including new
software development or versions of existing software. It has unique identifiers such as a project
ID, along with attributes like project name, start date, due date, completion date, and project
status.
 Justification: The project entity is critical as it encapsulates the company’s primary output. Each
project needs to be tracked individually, along with its associated attributes for effective
management and evaluation of progress.

3. Customer

 Type: Entity
 Description: This entity represents the clients who own one or more projects developed by the
company. Custodians have unique identifiers (customer ID), names, and addresses.
 Justification: Understanding the customer entity is essential for relationship management and
tracking project ownership. It enables the company to manage interactions with multiple
customers and their respective projects efficiently.

4. Department

 Type: Entity
 Description: The department entity represents the organizational structure of the company.
Each department is identified by a unique name and has a department head. Employees can
only belong to one department.
 Justification: Departments are essential for defining the hierarchical structure of the company,
allowing clear delineation of roles, responsibilities, and reporting. The relationship between
departments and employees enables proper management of personnel resources.

5. Team

 Type: Entity
 Description: The team entity involves the collection of programmers organized under a team
leader for each project. A team typically consists of between five to eight members.
 Justification: Teams are crucial for project execution and collaboration. This entity represents the
specific grouping of staff who work together towards project completion, and understanding
team structures is vital for workflow and communication within the company.

2. List and describe the attributes , its type and key with clear
justifications?(3mark)

2 / 44
 1. Customer
 Attributes:
Customer_Id (Primary Key) - Type: Integer, Unique Identifier for each customer.
Customer_Name - Type: Varchar, Name of the customer.
Customer_Address - Type: Varchar, Address of the customer.
 Justification: Every customer needs to be uniquely identifiable, and their name and address are
essential information for business operations.
2. Employee
 Attributes:
Employee_Id (Primary Key) - Type: Integer, Unique Identifier for each employee.
Employee_Name - Type: Varchar, Name of the employee.
Employee_Address - Type: Varchar, Address of the employeeEmployee_Position - Type:
Varchar, Position of the employee.Monthly_Salary - Type: Decimal, Monthly salary of
full-time employees.
Allowance_Rate - Type: Decimal, Allowance rate for full-time employees.
Contract_Period - Type: Integer, Contract period of part-time employees.
Hourly_Rate - Type: Decimal, Hourly rate of part-time employees.
 Justification: Employees require a unique identifier, and their position, salary information (for
full-time employees), and contract details (for part-time employees) are crucial.
3. Project
 Attributes:
Project_Id (Primary Key) - Type: Integer, Unique Identifier for each project.
Project_Name - Type: Varchar, Name of the project.
Start_Date - Type: Date, Start date of the project.
Due_Date - Type: Date, Due date of the project.
Complete_Date - Type: Date, Completion date of the project.- Type: Varchar, Status of
the project's progress.
 Justification: Projects require a unique identifier, and their name, start and due dates,
completion date, and status are essential project details.
4. Team
 Attributes:
Team_Id (Primary Key) - Type: Integer, Unique Identifier for each team.
Team_Name - Type: Varchar, Name of the team.
 Justification: Teams are not uniquely identified within this system but are essential for grouping
employees for project coordination.
5,Department
Attributes:
 Department ID (Unique identifier, could be a composite key with the
Department Name)
 Name (Department name, e.g., Development, Marketing)
 Department Head ID (Id of the employee who is leading the department)

3 / 44
 Justification: The Department entity organizes the structure of the company, indicating
how employees are grouped based on functions, ensuring efficient management and
operations.

3. Define the relationship in between entity and attributes, with

justifications?
4. E En
1. Employee
o Attributes:
 Employee ID (Unique identifier)
 Name (Employee’s full name)
 Address (Employee’s residence)
 Position (Job title, e.g., Programmer, Manager)
 Employment Type (Full-time or Part-time)
 Monthly Salary (For full-time employees)
 Allowance Rate (For full-time employees)
 Contract Period (For part-time employees)
 Hourly Rate (For part-time employees)
Justification: The Employee entity represents all staff members in the company, storing
essential details about them, such as identification and compensation for both full-time
and part-time employees.
2. Project
Attributes:
 Project ID (Unique identifier)
 Name (Name of the project)
 Start Date (Date project commenced)
 Due Date (Expected completion date)
 Complete Date (Actual completion date)
 Status (Current status of the project: ongoing, completed, etc.)
 Senior Manager ID (Id of the leading manager)
Justification: The Project entity captures details of the various projects undertaken by
the company, including their timelines and leadership, which are crucial for project
management.
3. Customer
Attributes:
 Customer ID (Unique identifier)
 Name (Name of the customer)
 Address (Customer’s residence or business address)
Justification: The Customer entity is vital as it connects to the ownership of projects,
enabling the company to manage client relationships effectively.

4 / 44
4. Department
Attributes:
 Department ID (Unique identifier, could be a composite key with the
Department Name)
 Name (Department name, e.g., Development, Marketing)
 Department Head ID (Id of the employee who is leading the department)
Justification: The Department entity organizes the structure of the company, indicating
how employees are grouped based on functions, ensuring efficient management and
operations.
Relationships
1. Employee to Department
Relationship Type: One-to-Many
Justification: Each employee belongs to one department, but each department can have
multiple employees. This is a direct relationship which helps in organizing employees
based on their respective departments.
2. Project to Customer
Relationship Type: Many-to-One
Justification: A customer can own one or many projects; however, each project is
associated with a single customer. This relationship helps in tracking project ownership.
3. Project to Employee (Team Leader)
Relationship Type: Many-to-One
Justification: Each project has one senior manager overseeing it. However, multiple
projects can be assigned to a single senior manager.
4. Project to Employee (Programmers)
Relationship Type: One-to-Many
Justification: Each project can have a team of 5 to 8 programmers, indicating that
multiple employees are working on the same project.
5. Department Head to Department
Relationship Type: One-to-One
Justification: Each department can only have one head, and each head can only lead one
department, establishing a clear structure for leadership within departments

4.Design and illustrate clearly the ER models of each scenario with

justifications?
To design an Entity-Relationship (ER) model for the “XYZ Software Share Company” based on the
information provided, we can identify the key entities, their relationships, and the attributes that
describe each entity. Here’s a breakdown of the ER model along with justifications for each
component.

Key Entities and Their Attributes:

1. Employee

5 / 44
 Attributes:

 EmployeeID (Primary Key)

 Name

 Address

 Position

 EmploymentType (Full-time/Part-time)

 MonthlySalary (for Full-time)

 AllowanceRate (for Full-time)

 ContractPeriod (for Part-time)

 HourlyRate (for Part-time)

Justification: This entity captures all relevant information about employees and
distinguishes between full-time and part-time employees through their attributes.

2. Project

Attributes:

 Project ID (Primary Key)

 Name

 StartDate

 Due Date

 Complete Date

 Status

Justification: Projects being the primary output of the company, this entity stores
essential information about each project’s lifecycle.

3. Customer

Attributes:

 CustomerID (Primary Key)

 Name

 Address

6 / 44
 Justification: Customers own the projects, and thus this entity holds attributes that
describe them.

4. Department

Attributes:

 Department ID (Primary Key)

 Name

Justification: Departments are essential for organizing employees. Each department will
have a unique identification.

Relationships:

1. Works_In

Between: Employee and Department

Type: Many-to-One (Many Employees work in one Department)

Justification: Each employee belongs to one department, but a department can have
multiple employees.

2. Leads

Between: Department Head and Department

Type: One-to-One (One Department Head leads one Department)

Justification: A department head is responsible for one department only.

3. Manages

Between: Employee (Senior Manager) and Project

Type: One-to-Many (One Senior Manager manages multiple Projects)

Justification: A project is led by a senior manager; thus, one manager can oversee
multiple projects.

4. Team

Between: Employee (Programmer/Team Leader) and Project

Type: Many-to-Many (Many Programmers work on one Project, and one Project can
have many Programmers)

Justification: Programmers can work on different projects, and each project employs
several programmers, requiring a separate associative table likely called “Works_On”.

7 / 44
5. Owns

Between: Customer and Project

Type: One-to-Many (One Customer can own multiple Projects)

Justification: A customer can have multiple projects but each project belongs to one
specific customer.

ER Model Diagram

5. Write the full implementation code for each scenario ERD with appropriate constraints and
validations. Note each code/syntax should be clearly align with your ERD.?(10 mark)
1. Defining Entities and Relationships
We'll define the main entities:
 Customer
 Project
 Department
 Employee

8 / 44
 Project
2. Creating the ERD
We'll visualize the relationships between these entities:
mermaid
er Diagram
CUSTOMER ||--o{ PROJECT : owns
PROJECT ||--o{ PROJECTASSIGNMENT : includes
PROJECT ||--o{ EMPLOYEE : leads
DEPARTMENT ||--o{ EMPLOYEE :
3. Creating Database Tables with Constraints and Validations
Based on the ERD, we will create SQL tables with appropriate constraints and validations:
sql
CREATE TABLE Customer (
CustomerID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Address TEXT NOT NULL
);

CREATE TABLE Project (

Project ID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Status VARCHAR(50),
CustomerID INT,
FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

CREATE TABLE Department (

Department ID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL UNIQUE,
Head ID INT,
FOREIGN KEY (Head ID) REFERENCES Employee(Employee ID)
);

CREATE TABLE Employee (

Employee ID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Address TEXT NOT NULL,
Position VARCHAR(50) NOT NULL,
Department ID INT,
Employment Type VARCHAR(20) NOT NULL,
Monthly Salary DECIMAL(10,2),
Allowance Rate DECIMAL(10,2),

9 / 44
 Contract Period VARCHAR(50),
Hourly Rate DECIMAL(10,2),
FOREIGN KEY (Department ID) REFERENCES Department(Department ID)
);

CREATE TABLE ProjectAssignment (

ProjectID INT,
EmployeeID INT,
Role VARCHAR(50) NOT NULL,
PRIMARY KEY (ProjectID, EmployeeID),
FOREIGN KEY (ProjectID) REFERENCES Project(ProjectID),
FOREIGN KEY (EmployeeID) REFERENCES Employee(EmployeeID)
);

CREATE TABLE Schedule (

EmployeeID INT,
WeekStartDate DATE,
HoursWorked DECIMAL(5,2),
PRIMARY KEY (EmployeeID, WeekStartDate),
FOREIGN KEY (EmployeeID) REFERENCES Employee(EmployeeID)
);
4. Validations and Data Integrity
Adding constraints to ensure data integrity:
sql
ALTER TABLE Project
ADD CONSTRAINT CK_Project_Dates CHECK (StartDate <= DueDate AND (CompleteDate IS NULL
OR CompleteDate >= StartDate));

ALTER TABLE Employee

ADD CONSTRAINT CK_Employee_SalaryAllowance CHECK (EmploymentType = 'Full-Time' AND
MonthlySalary IS NOT NULL AND AllowanceRate IS NOT NULL) OR (EmploymentType = 'Part-
Time' AND ContractPeriod IS NOT NULL AND HourlyRate IS NOT NULL);
5. Sample Data Insertion
Inserting sample data into the tables:
sql
INSERT INTO Customer (CustomerID, Name, Address)
VALUES (1, 'Acme Corp', '123 Main Street');

INSERT INTO Project (ProjectID, Name, StartDate, DueDate, Status, CustomerID)

VALUES (1, 'New Software Development', '2025-01-01', '2025-12-31', 'In Progress', 1);

INSERT INTO Department (DepartmentID, Name, HeadID)

10 / 44
 VALUES (1, 'Development', NULL);

INSERT INTO Employee (EmployeeID, Name, Address, Position, DepartmentID, EmploymentType,

MonthlySalary, AllowanceRate)
VALUES (1, 'Jane Doe', '456 Elm Street', 'Senior Manager', 1, 'Full-Time', 8000.00, 500.00);

INSERT INTO Project Assignment (ProjectID, Employee ID, Role)

VALUES (1, 1, 'Team Leader');

INSERT INTO Schedule (EmployeeID, WeekStartDate, HoursWorked)

VALUES (1, '2025-01-06', 40);
6. Ensuring Transactions and Consistency
Using transaction control to maintain consistency:
sql
BEGIN TRANSACTION;

UPDATE Employee
SET Monthly Salary = 8500.00
WHERE Employee ID = 1;

INSERT INTO Project Assignment (Project ID, Employee ID, Role)

VALUES (1, 2, 'Programmer');

COMMIT;
7. Access Control and User Roles
Defining roles and access controls:
sql
CREATE ROLE Senior Manager;
CREATE ROLE Team Leader;
CREATE ROLE Programmer;
CREATE ROLE Customer Service;

GRANT SELECT, INSERT, UPDATE, DELETE ON Customer TO Senior Manager;

GRANT SELECT, INSERT, UPDATE ON Project TO Team Leader;
GRANT SELECT, INSERT ON Project Assignment TO Programmer;
GRANT SELECT

6. Assume you are delegated on scenario three as an administrator, system analyses, system designer,
database implementer or end user on student information database system. so what was your
responsibility on each actor, list the responsibility that follow each actor on a database system?(2 mark)

11 / 44
 each actor plays a distinct role with specific responsibilities. Below is a breakdown of
responsibilities for each actor: Administrator, System Analyst, System Designer, Database
Implementer, and End User.

1. Administrator

 User Management: Create, modify, and delete user accounts and manage permissions/roles for
different levels of access, ensuring that sensitive data is protected.

 Database Maintenance: Regularly monitor the database for performance, integrity, and security.
Implement backups and recovery procedures to prevent data loss.

 Data Security: Establish and enforce security protocols, including setting access controls,
auditing, and safeguarding against unauthorized access and data breaches.

 Policy Implementation: Develop and enforce policies for data access and usage within the
organization, ensuring compliance with relevant regulations and standards.

2. System Analyst

 Requirements Gathering: Work with stakeholders to understand their needs and gather
requirements for the database system, translating these into technical specifications.

 System Evaluation: Analyze existing systems, processes, and workflows to determine how they
can be improved or which new systems should be integrated.

 Feasibility Studies: Conduct feasibility studies to assess the practicality, technology, and costs
involved in implementing new database solutions.

 Documentation: Prepare documentation for system requirements, workflow processes, and data
entry guidelines for future reference and training.

3. System Designer

 ER Model Design: Create Entity-Relationship (ER) models to visually represent data structures,
entities, relationships, and attributes according to requirements gathered.

 Schema Design: Develop the logical and physical database schema, including defining tables,
fields, data types, constraints, and ensure normalization to eliminate redundancy.

 Interface Design: Design user interfaces and interactions, ensuring they are user-friendly and
meet the needs of end users based on usability principles.

 System Integration: Plan how the new database system will integrate with existing software and
ensure that all parts of the system work together smoothly.

4. Database Implementer

12 / 44
  Database Creation: Set up and create the database environment based on the designed schema,
ensuring proper configuration for optimal performance.

 Data Migration: Facilitate the transition of existing data from legacy systems to the new
database, ensuring data integrity and accuracy.

 Testing: Perform testing of the database system, including unit testing, integration testing, and
user acceptance testing, to identify and fix any issues before deployment.

 Documentation: Provide documentation of the database architecture, operational procedures,

and troubleshooting guides for ongoing support.

5. End User

 Data Entry: Input and manage data within the database according to established protocols,
ensuring accuracy and completeness of records.

 Query Execution: Utilize the database system to generate reports, access information, and
retrieve data as needed for personal or organizational tasks.

 Feedback: Provide feedback to system analysts and designers on usability and functionality
based on actual usage experience, which can lead to future improvements.

 Training and Adoption: Engage in training sessions to learn how to properly use the database
system and participate in initiatives to encourage adoption among colleague

7. Assume you are inviting to upgrading the Injibara university student information database system to
latest version.

A. What type of DBMS tools you will use/prefer and why?(2 mark)

DBMS Tools Preference

For upgrading the Injibara University student information database system to the latest version, I would
prefer to use PostgreSQL as the RDBMS tool.

Reasons:

1. Advanced Features: PostgreSQL supports advanced data types (like JSON and arrays) and
features such as full-text search and indexing capabilities. This allows for more complex queries
and data storage options, which can be advantageous for a university system that may require
diverse data handling (e.g., managing multiple programs, student projects, etc.).

2. Strong ACID Compliance: PostgreSQL is known for its strong adherence to ACID principles,
ensuring that all transactions are processed reliably. This is crucial for the integrity of student
records, grades, and other critical data within the university.

13 / 44
 3. Extensibility and Customization: PostgreSQL is highly extensible, allowing the addition of
custom functions and data types. This flexibility can be valuable for tailoring the system to
specific university needs and requirements.

4. Community & Support: PostgreSQL has a large and active community, providing ample
resources for troubleshooting, enhancing functionality, and security updates. This can be
invaluable for a university looking to maintain a robust and up-to-date database system.

B. What type of security mechanism you will be use/ prefer and why? (2 mark)

Security Mechanism Preference

For securing the Injibara University student information database, I would prefer to implement a multi-
layered security mechanism encompassing role-based access control (RBAC) and encryption of
sensitive data.

Reasons:

1. Role-Based Access Control (RBAC): This approach ensures that access to data is granted based
on the user's role within the university (e.g., student, faculty, administrator). By establishing
clear access levels and permissions, the university can minimize the risk of unauthorized access
to sensitive information, such as academic records and personal details of students.

2. Data Encryption: Implementing encryption for sensitive data, both at rest (stored on disk) and in
transit (data sent over networks), safeguards against data breaches and unauthorized
interception. This is especially critical for preventing exposure of sensitive information, such as
social security numbers, grades, and contact details.

3. Audit Logging: Keeping detailed logs of database access and modifications serves as a deterrent
against unauthorized actions and provides transparency. This mechanism allows for tracking user
activities within the system and facilitates compliance with regulatory requirements regarding
data handling.

Scenario 2: Banking database Scenario

Scenario 2: Banking database Scenario Consider “Ethiopian Dashen bank system”. in this bank there are a
lots of activities doing by different bank actor. The most bank actors that involve in day to day activity are
customer service, payment service, account in/out service and coordinating the whole tasks and reports
the overall activities in main and sub branch of the bank. In the bank most of the customer depose
money their own account and loan many from any payment and also customers are checking their
account using Automatic tailor machine (ATM), face-to-face checking in bank by requesting banker
employee and mobile banking.

14 / 44
Questions: Based on the above three scenario, do the next Seven(7)activities accordingly.

1. List and describe the entity and its type with clear justification?(2 Mark)

In the context of the "Ethiopian Dashen Bank System," we can identify several key entities that represent
the fundamental components involved in the bank's operations. Each entity serves as a logical structure
to organize data within the database. Here’s a breakdown of the primary entities, their types, and
justifications for their inclusion.

1. Customer

 Type: Entity

 Description: Represents individuals or organizations that maintain accounts with the bank. This
entity stores information about customers to facilitate banking services.

 Attributes:

Customer ID (Primary Key)

Name

Address

Phone Number

Email

Date of Birth

 Justification: The customer is a central entity, as they are the primary user of banking services.
Each customer's information is essential for service provisioning, loan applications, deposits, and
withdrawals.

2. Account

 Type: Entity

 Description: Represents the various accounts held by customers, such as savings accounts,
checking accounts, loan accounts, etc.

 Attributes:

o Account Number (Primary Key)

Account Type (e.g.Savings, Checking, Loan)

Balance

Date Opened

Customer ID (Foreign Key)

15 / 44
  Justification: The account entity is crucial for tracking the financial transactions and balances
associated with each customer. Observing accounts allows the bank to manage transactions,
fees, and interest rates effectively.

3. Transaction

 Type: Entity

 Description: Represents financial transactions that occur within the bank system, such as
deposits, withdrawals, transfers, loan payments, etc.

 Attributes:

Transaction ID (Primary Key)

Transaction Type (e.g., Deposit, Withdrawal, Loan Payment)

Amount

Transaction Date

Account Number (Foreign Key)

 Justification: The transaction entity captures the detailed history of all monetary interactions
involving customer accounts. It is pivotal for accounting, auditing, and customer service
inquiries.

4. Employee

 Type: Entity

 Description: Represents bank staff who provide services to customers, such as customer service
representatives and loan officers.

 Attributes:

Employee ID (Primary Key)

Name

Position

Department

Phone Number

 Justification: Employees are essential for operational activities in the bank. They interact directly
with customers and manage transactions, making it critical to store and manage their
information.

5. ATM

16 / 44
  Type: Entity

 Description: Represents the Automated Teller Machines available for customer transactions,
including cash withdrawals and account balance inquiries.

 Attributes:

ATM ID (Primary Key)

Location

Status (e.g., Active, Out of Service)

 Justification: ATMs serve as crucial access points for customers to perform transactions. Tracking
ATMs allows the bank to manage service availability, maintenance schedules, and transaction
volumes.

6. Loan

 Type: Entity

 Description: Represents the loans provided by the bank to customers, including details of loan
types, amounts, and repayment schedules.

 Attributes:

Loan ID (Primary Key)

Loan Amount

Interest Rate

Start Date

Customer ID (Foreign Key)

Status (e.g., Active, Paid Off)

 Justification: The loan entity is vital for managing lending operations within the bank. It tracks
customer borrowing behaviors and repayment activities, essential for financial health and
compliance

2.List and describe the attributes , its type and key with clear justifications?(3mark)

In analyzing the activities and operations of the Ethiopian Dashen Bank system, we can identify several
entities relevant to the banking services provided. Below are potential attributes, their types, and keys
for each entity relevant to the bank's system.

1. Customer

 Attributes:

17 / 44
 Customer ID (Type: Integer, Key: Primary Key)

 Justification: A unique identifier for each customer, ensuring no two customers

can have the same ID.

First Name (Type: String)

 Justification: Captures the first name of the customer for personalized service.

Last Name (Type: String)

 Justification: Captures the last name for identification and record-keeping.

Email (Type: String)

 Justification: Used for communication and notifications regarding account

activity.

PhoneNumber (Type: String)

 Justification: A contact method for customer service and alerts.

2. Account

 Attributes:

Account ID (Type: Integer, Key: Primary Key)

Justification: Uniquely identifies each bank account.

Customer ID (Type: Integer, Key: Foreign Key)

 Justification: Establishes a relationship between the customer and their account.

Account Type (Type: String)

 Justification: Specifies whether the account is a savings, checking, or loan

account, thereby informing functionality and features.

Balance (Type: Decimal)

 Justification: Reflects the current monetary value in the account, crucial for
transactions.

Creation Date (Type: Date)

 Justification: Records when the account was opened, which can be useful for
tracking account history.

3. Transaction

 Attributes:

18 / 44
 Transaction ID (Type: Integer, Key: Primary Key)

 Justification: A unique identifier for each transaction, ensuring traceability.

Account ID (Type: Integer, Key: Foreign Key)

 Justification: Links a transaction back to the specific account it affects, essential

for maintaining records.

TransactionType (Type: String)

 Justification: Indicates whether the transaction is a deposit, withdrawal, loan

payment, etc., thereby categorizing the activity.

Amount (Type: Decimal)

 Justification: Represents the value of the transaction, critical for account balance
updates.

#TransactionDate (Type: Date)

 Justification: Provides a timestamp for when the transaction took place, aiding in
historical record-keeping.

4.Employee

 Attributes:

Employee ID:

 Type: Integer (Primary Key)

 Justification: Uniquely identifies each employee, facilitating effective human

resource management and operational tracking.

Name:

 Type: String

 Justification: Important for identifying and interacting with employees, enabling

internal communication and customer service management.

Position:

 Type: String

 Justification: Indicates the role of the employee, important for organizational

structure and management of responsibilities.

Department:

 Type: String

19 / 44
  Justification: Helps categorize employees within the organization, allowing for
efficient resource allocation and workflow management.

Phone Number:

 Type: String

 Justification: Facilitates communication with employees, necessary for

operational coordination and customer handling.

5. ATM

 Attributes:

ATM ID:

 Type: Integer (Primary Key)

 Justification: Uniquely identifies each ATM, which is critical for management,

maintenance, and tracking transaction history at specific locations.

Location:

 Type: String

 Justification: Indicates the geographical placement of the ATM, essential for

customer convenience and operational logistics.

Status:

 Type: String

 Justification: Tracks whether the ATM is operational or out of service, crucial for
customer service and maintenance management.

6. Loan

 Attributes:

Loan ID:

 Type: Integer (Primary Key)

 Justification: Uniquely identifies each loan, which is required for tracking

borrower obligations and repayment activities.

Loan Amount:

 Type: Decimal

 Justification: Represents the sum borrowed by the customer, essential for

financial reporting and monitoring outstanding obligations.

20 / 44
 Interest Rate:

Type: Decimal

 Justification: The percentage charged on the loan amount, critical for

determining borrower costs and profitability for the bank.

Start Date:

 Type: Date

 Justification: Indicates when the loan was disbursed, significant for managing
the repayment schedule and interest calculations.

Customer ID:

 Type: Integer (Foreign Key)

 Justification: Links the loan to the customer who availed it, enabling customer
management and tracking of individual financial commitments.

Status:

 Type: String

 Justification: Provides the current state of the loan (e.g., Active, Paid Off), which
is essential for managing the bank's loan portfolio and assessing credit risk

3.Define the relationship in between entity and attributes, with justifications?(3 Mark)

In the analysis of the Ethiopian Dashen Bank system, we can define the relationships between identified
entities and their attributes, as well as provide justifications for these relationships. The main entities in
this banking context include Customer, Account, Transaction, and Banking Activity/Service.

1. Customer and Account

 Relationship Type: One-to-Many

 Justification:Each Customer can hold multiple Accounts (e.g., a savings account, a checking
account, a loan account). Therefore, there is a one-to-many relationship where one customer
can have many associated accounts, but each account is owned by only one customer. This is
reflected in the CustomerID attribute in the Account entity being a foreign key.

2. Account and Transaction

 Relationship Type: One-to-Many

 Justification:Each Account can be involved in many Transactions (e.g., deposits, withdrawals).

Thus, there is a one-to-many relationship, where a single account can have many transactions

21 / 44
 associated with it. The AccountID in the Transaction entity serves as a foreign key to establish
this relationship.

3. Customer and Transaction (Indirect Relationship)

 Relationship Type: One-to-Many (indirect through the Account)

 Justification:While a Customer does not directly own a transaction, each transaction is

performed on an account that belongs to a customer. Therefore, there exists an indirect
relationship where one customer can be associated with many transactions mediated through
their accounts.

4. Transaction and Banking Activity/Service

 Relationship Type: One-to-Many

 Justification:Each Transaction can correlate with a specific Banking

Activity/Service (transactional service such as deposit or withdrawal). For instance, multiple
transactions might occur as a part of account management services by banking staff or as
automated services via ATMs. The ActivityID in the Banking Activity/Service entity can serve as
a foreign key in transactions if we wish to track which service facilitated the transaction.

Summary of Relationships

To summarize the relationships:

 Customer (1) ↔ (M) Account

 Account (1) ↔ (M) Transaction

 Banking Activity/Service (M) ↔ (1) Employee

 Transaction (M) ↔ (1) (indirectly via Account) Customer

4.Design and illustrate clearly the ER models of each scenario with justifications?
To design an Entity-Relationship (ER) model for the "Ethiopian Dashen Bank
System" based on the provided information, we will identify the key entities,
relationships, and attributes relevant to the bank's operations. The bank system
will encompass several actors and activities, focusing on customers, accounts,
services, and branches.
Key Entities and Their Attributes:
1. Customer
Attributes:

22 / 44
  Customer ID (Primary Key)
 Name
 Address
 Phone Number
 Email
Justification: The Customer entity captures essential details for
individuals who use the banking services.
2. Account
Attributes:
 Account ID (Primary Key)
 Account Type (e.g.Savings, Checking)
 Balance
 Customer ID (Foreign Key)
 Creation Date
Justification: Accounts are fundamental to banking operations,
representing the financial resources of customers. The foreign key
links accounts to customers.
3. Transaction
Attributes:
 Transaction ID (Primary Key)
 Transaction Type (Deposit, Withdrawal, Loan Repayment)
 Amount
 Date
 Account ID (Foreign Key)

23 / 44
 Justification: The Transaction entity logs all activities related to
accounts, ensuring that every deposit, withdrawal, or loan repayment
is recorded.
4. Branch
Attributes:
 Branch ID (Primary Key)
 Branch Name
 Location
Justification: Branches are where customers perform banking
operations. This entity identifies each branch and its location.
Employee
o Attributes:
 Employee ID (Primary Key)
 Name
 Role (Customer Service, Payment Service, etc.)
 Branch ID (Foreign Key)
Justification: Employees handle various services within the bank, and
it is crucial to link them to specific branches.
5. ATM
Attributes:
 ATM ID (Primary Key)
 Location
 Branch ID (Foreign Key)

24 / 44
 Justification: ATMs provide electronic access to bank accounts for
customers and are linked to specific branches, facilitating easy
identification.
Relationships:
1. Has
Between: Customer and Account
Type: One-to-Many (One Customer can have multiple Accounts)
Justification: A customer can maintain multiple bank accounts.
2. Performs
Between: Customer and Transaction
Type: One-to-Many (One Customer can perform multiple
Transactions)
Justification: Each transaction is linked to a customer who initiates it.
3. Belongs_To
Between: Account and Branch
Type: Many-to-One (Many Accounts can belong to one Branch)
Justification: Accounts may be managed at the bank's branches.
4. Employs
Between: Branch and Employee
Type: One-to-Many (One Branch can employ several Employees)
Justification: Each branch has various employees delivering banking
services.
5. Located_At
Between: ATM and Branch

25 / 44
 Type: Many-to-One (Many ATMs can be located at one Branch)
Justification: Each ATM is physically located at a branch, serving
customers from that branch.

ER Model Diagram
Here is ER model structure:

26 / 44
5.Write the full implementation code for each scenario ERD with appropriate constraints and validations.
Note each code/syntax should be clearly align with your ERD.?(10 Mark)

Below is a sample implementation in Python using Object-Oriented Programming (OOP) principles to

represent the entities and their relationships as defined by the ERD for the Ethiopian Dashen Bank
system. This implementation includes classes for Customer, Account, Transaction, Banking
Activity/Service, Employee, and Branch, with appropriate attributes, methods, and constraints.

Creating a comprehensive ERD (Entity-Relationship Diagram) and implementing the code for a banking
database system requires a good understanding of the requirements. I'll break it down into the following
seven activities to give you a clear understanding:

1. Defining Entities and Relationships

We'll define the main entities in the banking system and their relationships:

 Customer

 Account

 Transaction

 ATM

 Branch

 Employee

2. Creating the ERD

An ERD diagram visually represents the entities and their relationships. Here's a simple ERD:

mermaid

er Diagram

CUSTOMER ||--o{ ACCOUNT : owns

CUSTOMER ||--o{ TRANSACTION : initiates

ACCOUNT ||--o{ TRANSACTION : involves

CUSTOMER ||--o{ ATM : uses

BRANCH ||--o{ ATM : contains

EMPLOYEE ||--o{ BRANCH : works_at

CUSTOMER ||--o{ BRANCH : visits

27 / 44
3. Creating Database Tables with Constraints and Validations

Based on the ERD, we will create SQL tables with appropriate constraints and validations.

sql

CREATE TABLE Customer (

CustomerID INT PRIMARY KEY,

Name VARCHAR(100) NOT NULL,

Phone VARCHAR(15) NOT NULL,

Email VARCHAR(100) UNIQUE NOT NULL,

Address TEXT NOT NULL

);

CREATE TABLE Account (

Account ID INT PRIMARY KEY,

CustomerID INT,

Balance DECIMAL(15,2) NOT NULL,

Account Type VARCHAR(50) NOT NULL,

FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)

);

CREATE TABLE Transaction (

Transaction ID INT PRIMARY KEY,

Account ID INT,

Amount DECIMAL(15,2) NOT NULL,

Transaction Type VARCHAR(50) NOT NULL,

Transaction Date DATETIME DEFAULT CURRENT_TIMESTAMP,

FOREIGN KEY (Account ID) REFERENCES Account(Account ID)

);

28 / 44
CREATE TABLE ATM (

ATMID INT PRIMARY KEY,

Location TEXT NOT NULL,

Branch ID INT,

FOREIGN KEY (Branch ID) REFERENCES Branch(Branch ID)

);

CREATE TABLE Branch (

Branch ID INT PRIMARY KEY,

Name VARCHAR(100) NOT NULL,

Location TEXT NOT NULL

);

CREATE TABLE Employee (

Employee ID INT PRIMARY KEY,

Name VARCHAR(100) NOT NULL,

Position VARCHAR(50) NOT NULL,

Branch ID INT,

FOREIGN KEY (Branch ID) REFERENCES Branch(Branch ID)

);

4. Validations and Data Integrity

We'll add validations to ensure data integrity.

sql

ALTER TABLE Account

ADD CONSTRAINT CK_Account_Balance CHECK (Balance >= 0);

29 / 44
ALTER TABLE Transaction

ADD CONSTRAINT CK_Transaction_Amount CHECK (Amount > 0);

5. Sample Data Insertion

Inserting sample data into the tables.

sql

INSERT INTO Customer (CustomerID, Name, Phone, Email, Address)

VALUES (1, 'John Doe', '1234567890', '[email protected]', '123 Elm Street');

INSERT INTO Account (AccountID, CustomerID, Balance, AccountType)

VALUES (1, 1, 5000.00, 'Savings');

INSERT INTO Transaction (TransactionID, AccountID, Amount, TransactionType)

VALUES (1, 1, 1000.00, 'Deposit');

INSERT INTO Branch (BranchID, Name, Location)

VALUES (1, 'Main Branch', '456 Oak Avenue');

INSERT INTO ATM (ATMID, Location, BranchID)

VALUES (1, 'Central Plaza', 1);

INSERT INTO Employee (EmployeeID, Name, Position, BranchID)

VALUES (1, 'Alice Smith', 'Manager', 1);

6. Ensuring Transactions and Consistency

We'll ensure transactions are consistent and data integrity is maintained using transaction control.

sql

BEGIN TRANSACTION;

30 / 44
UPDATE Account

SET Balance = Balance - 200.00

WHERE AccountID = 1;

INSERT INTO Transaction (TransactionID, AccountID, Amount, TransactionType)

VALUES (2, 1, 200.00, 'Withdrawal');

COMMIT;

7. Access Control and User Roles

Adding access control to the database by defining user roles.

sql

CREATE ROLE BankManager;

CREATE ROLE Teller;

CREATE ROLE CustomerService;

GRANT SELECT, INSERT, UPDATE, DELETE ON Customer TO BankManager;

GRANT SELECT, INSERT, UPDATE ON Account TO Teller;

GRANT SELECT ON Account TO

Scenario 3: Students database system scenario

Consider InjibaraUniversity “Student Information database System”. In this database system lots of
information are recorded and store for a long period of time for the purpose of locally administer and
facilitating teaching and learning process. The most information that store in this database system are
students detail information, course detail information, instructors detail information which is delegated
on the course and advisors per section and employee which is controlling the overall activates of the
student information system like database administrators(registrar manager) which is controlling internal
and external tasks that involves within students information database Page 2 of 2 system and recorder
which has the role of registered updated students information per semester and year according to the
university legislation.

Questions: Based on the above three scenario, do the next Seven(7)activities accordingly.

1.List and describe the entity and its type with clear justification?(2 Mark)

31 / 44
In the context of the Injibara University "Student Information Database System," we can identify several
key entities, their types, and provide justification for each entity based on the requirements described.
Below is a list of the primary entities in this system along with their descriptions:

1. Student

 Type: Strong Entity

 Justification:

The Student entity represents individual students enrolled at the university. Each
student has unique identifying attributes such as StudentID, Name, Date of Birth,
Address, Email, Phone Number, Program of Study, and Enrollment Date.

This entity is crucial as it holds the core information necessary for managing student
registrations, academic progress, and personal information.

2. Course

 Type: Strong Entity

 Justification:

The Course entity captures the details of the various courses offered at the university.
Key attributes include CourseID, CourseName, CourseDescription, Credits,
Semester, and InstructorID (to link to the instructor teaching the course).

This entity is essential for the academic structure of the university, as it organizes the
curriculum and allows students to enroll in specific courses as part of their programs.

3. Instructor

 Type: Strong Entity

 Justification:

The Instructor entity contains information about faculty members who teach courses.
Important attributes include InstructorID, Name, Department, Email, Phone
Number, and Office Location.

This entity is critical because it provides the necessary information for assigning
instructors to courses and facilitating communication between students and faculty.

4. Advisor

 Type: Strong Entity

 Justification:

32 / 44
 o The Advisor entity refers to academic advisors assigned to students to guide them in
their course selection and academic paths. Attributes include AdvisorID, Name,
Department, Email, and Phone Number.

o The Advisor entity is important for supporting the academic success of students, helping
them navigate their studies and providing personalized guidance.

5. Employee

 Type: Strong Entity

 Justification:

The Employee entity encompasses staff involved in administrative tasks, such as the
Registrar Manager and Recorders. Attributes may include EmployeeID, Name, Position,
Department, Email, and Phone Number.

This entity is necessary to maintain the operational aspects of the university, ensuring
that administrative functions and record-keeping are properly managed.

6. Registration

 Type: Weak Entity

 Justification:

The Registration entity represents the enrollment of students in courses, including

details such as RegistrationID, StudentID, CourseID, Semester, and Year.

This entity is categorized as a weak entity because it depends on both the Student and
Course entities for its existence. It is essential to track which students are enrolled in
which courses during specific semesters, thus linking students to their academic
activities.

2 .List and describe the attributes , its type and key with clear justifications?
In the context of the Injibara University "Student Information Database System," we can define
several entities along with their attributes, types, and keys. Here are the main entities with their
respective attributes, including justifications for each:
1. Student
 Attributes:
Student ID
 Type: Integer (Primary Key)
 Justification: This is a unique identifier for each student, ensuring that all
records pertaining to a student can be accurately linked and retrieved.
FirstName
 Type: String

33 / 44
  Justification: Represents the first name of the student, used for identification
and communication.
LastName
 Type: String
 Justification: Represents the last name of the student, essential for
identification.
Date of Birth
 Type: Date
 Justification: Required to determine the age of the student and for eligibility
requirements.
Email
 Type: String
 Justification: Used for official communications with the student.
Phone Number
 Type: String
 Justification: Allows for direct communication, essential for administrative
processes.
Program Of Study
 Type: String
 Justification: Identifies the degree program in which the student is enrolled and
important for academic tracking.
Enrollment Date
 Type: Date
 Justification: Indicates when the student was admitted and helps track their
academic tenure.
2. Course
 Attributes:
Course ID
 Type: Integer (Primary Key)
 Justification: This unique identifier is essential for cataloging and managing the
course information within the system.
Course Name
 Type: String
 Justification: Represents the name of the course, used for enrollment and
course materials.
Course Description
 Type: String
 Justification: Provides details about the course content, beneficial for students
in selecting courses.
Credits
 Type: Integer

34 / 44
  Justification: Indicates the number of credits the course carries, which is crucial
for fulfilling degree requirements.
Semester
 Type: String
 Justification: Specifies the semester in which the course is offered, facilitating
better scheduling and planning.
3. Instructor
 Attributes:
Instructor ID
 Type: Integer (Primary Key)
 Justification: A unique identifier for each instructor, necessary for managing
course assignments and staff information.
FirstName
 Type: String
 Justification: Used for personal identification and communications.
LastName
 Type: String
 Justification: Important for identifying the instructor in the academic context.
Department
 Type: String
 Justification: Indicates the department in which the instructor works, useful for
categorizing courses and faculty.
Email
 Type: String
 Justification: Used for official communications and correspondence.
4. Advisor
 Attributes:
Advisor ID
 Type: Integer (Primary Key)
 Justification: A unique identifier for each academic advisor, essential for tracking
their assignments to students.
FirstName
 Type: String
 Justification: Used for identification and communication purposes.
LastName
 Type: String
 Justification: Important for personal identification of the advisor.
Department
 Type: String
 Justification: Indicates which department the advisor belongs to, important for
context when students seek guidance.
5. Employee

35 / 44
 Attributes:
Employee ID
 Type: Integer (Primary Key)
 Justification: This unique identifier is critical for managing employee records and
roles within the administration.
FirstName
 Type: String
 Justification: Used for personal identification and communication.
LastName
 Type: String
 Justification: Critical for recognizing the employee within the university context.
Position
 Type: String
 Justification: Describes the role of the employee (e.g., Registrar Manager,
Recorder), necessary for operational management.
Department
 Type: String
 Justification: Indicates the administrative department the employee belongs to,
essential for coordinating tasks.
6. Registration
 Attributes:
Registration ID
 Type: Integer (Primary Key)
 Justification: This unique identifier for each registration record is necessary for
tracking student enrollments in courses.
Student ID
 Type: Integer (Foreign Key)
 Justification: Links the registration record to a specific student, facilitating
tracking of which courses a student is enrolled in.
Course ID
 Type: Integer (Foreign Key)
 Justification: Links the registration to specific courses, ensuring accurate records
for course enrollment.
Semester
 Type: String
 Justification: Specifies the semester in which the registration took place,
important for academic planning and tracking.
Year
 Type: Integer
 Justification: Helps indicate the academic year of the registration, essential for
records and reporting.

36 / 44
3.Define the relationship in between entity and attributes, with justifications?
(3 Mark)
In the Injibara University “Student Information Database System,” entities are interconnected
through various relationships based on their attributes. Below are the primary entities, their
relationships, and justifications:
1. Student and Registration
 Relationship: One-to-Many (1:N)
 Justification:
o Attributes Involved:
 Student (Student ID as Primary Key)
 Registration (Student ID as Foreign Key)
o Each student can enroll in multiple courses across different semesters. Therefore, a
single Student record can be linked to many Registration records, indicating that a
student can take numerous courses over time. Each registration record must reference a
single Student, thus establishing a one-to-many relationship.
2. Course and Registration
 Relationship: One-to-Many (1:N)
 Justification:
o Attributes Involved:
 Course (Course ID as Primary Key)
 Registration (Course ID as Foreign Key)
o A single course can have many students enrolled in it, with multiple registration records
linking students to that course. Each course can be taken by many students in different
semesters, hence a one-to-many relationship exists between Course and Registration.
3. Instructor and Course
 Relationship: One-to-Many (1:N)
 Justification:
Attributes Involved:
 Instructor (Instructor ID as Primary Key)
 Course (Instructor ID as Foreign Key)
An instructor can teach multiple courses, but each course is usually assigned to one
primary instructor. This creates a one-to-many relationship where one instructor has
multiple courses, enabling efficient management of course assignments and instructor
responsibilities.
4. Advisor and Student
 Relationship: One-to-Many (1:N)
 Justification:
Attributes Involved:
 Advisor (Advisor ID as Primary Key)
 Student (Advisor ID as Foreign Key, assuming each student is assigned one
advisor)

37 / 44
 While one advisor can guide multiple students, each student typically has one assigned
advisor for personalized academic counseling. Hence, the relationship between Advisor
and Student is one-to-many.
5. Employee and Administrator Functions
 Relationship: One-to-Many (1:N)
 Justification:
Attributes Involved:
 Employee (Employee ID as Primary Key)
 Various Roles (like Registrar Manager and Recorder)
An employee can hold various administrative roles or responsibilities within the Student
Information System. For example, one employee (e.g., a registrar manager) could
oversee multiple administrative tasks, thus creating a one-to-many relationship between
the Employee entity and administrative functions.

4.Design and illustrate clearly the ER models of each scenario with

justifications?

Designing an Entity-Relationship (ER) model for the Injibara University "Student Information
Database System" involves creating a visual representation of the various entities, their
attributes, and the relationships between them. Below is a textual explanation of the ER model
including the necessary entities, their attributes, relationships, and justifications. For illustration
purposes, I will describe how you can represent this model graphically.
Entities and Attributes
1. Student
o Attributes:
 Student ID (Primary Key)
 FirstName
 LastName
 Date Of Birth
 Email
 Phone Number
 Program Of Study
 Enrollment Date
2. Course
o Attributes:
 Course ID (Primary Key)
 Course Name
 Course Description
 Credits
 Semester

38 / 44
3. Instructor
o Attributes:
 Instructor ID (Primary Key)
 FirstName
 LastName
 Department
 Email
4. Advisor
o Attributes:
 Advisor ID (Primary Key)
 FirstName
 LastName
 Department
5. Employee
o Attributes:
 Employee ID (Primary Key)
 FirstName
 LastName
 Position
 Department
6. Registration
o Attributes:
 Registration ID (Primary Key)
 Student ID (Foreign Key)
 Course ID (Foreign Key)
 Semester
 Year
Relationships
1. Student - Registration
Type: One-to-Many (1:N)
Justification: Each student can have multiple course registrations.
2. Course - Registration
o Type: One-to-Many (1:N)
o Justification: Each course can have multiple students enrolled.
3. Instructor - Course
o Type: One-to-Many (1:N)
o Justification: Each instructor can teach multiple courses.
4. Advisor - Student
o Type: One-to-Many (1:N)
o Justification: Each advisor can guide multiple students.
5. Employee - Role
o Type: One-to-Many (1:N)

39 / 44
 o Justification: Each employee can have multiple roles or responsibilities within
administrative functions.
ER Model

Summary and Justification

This ER model graphically organizes the various entity attributes and outlines their relationships.
1. One-to-Many Relationships indicate that an entity can be linked to multiple instances of another
entity. For example:
o A single Student can have multiple Registrations in different courses.
o A single Course can enroll multiple Students.
2. Foreign Keys are used to link entities effectively, ensuring that data integrity is maintained
through relationships.
3. By clearly organizing entities and their relationships, this ER model supports the comprehensive
management of student records, course tracking, and faculty assignments, thereby enhancing
the administrative functions of Injibara University.

5.Write the full implementation code for each scenario ERD with appropriate
constraints and validations. Note each code/syntax should be clearly align with
your ERD.?
· Student
· Course
· Instructor
· Enrollment
· Advisor

40 / 44
· Employee
2. Creating the ERD
Here's a visual representation of the entities and their relationships:
mermaid
erDiagram
STUDENT ||--o{ ENROLLMENT : enrolls_in
COURSE ||--o{ ENROLLMENT : has
INSTRUCTOR ||--o{ COURSE : teaches
ADVISOR ||--o{ STUDENT : advises
EMPLOYEE ||--o{ STUDENT : manages
EMPLOYEE ||--o{ INSTRUCTOR : supervises
EMPLOYEE ||--o{ COURSE : coordinates
3. Creating Database Tables with Constraints and Validations
Based on the ERD, we will create SQL tables with appropriate constraints and validations.
sql
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Address TEXT NOT NULL,
DateOfBirth DATE NOT NULL,
Email VARCHAR(100) UNIQUE NOT NULL,
Phone VARCHAR(15)
);

CREATE TABLE Course (

CourseID INT PRIMARY KEY,
CourseName VARCHAR(100) NOT NULL,
Credits INT NOT NULL
);

CREATE TABLE Instructor (

InstructorID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Department VARCHAR(100) NOT NULL,
Email VARCHAR(100) UNIQUE NOT NULL
);

CREATE TABLE Enrollment (

EnrollmentID INT PRIMARY KEY,
StudentID INT,
CourseID INT,
Semester VARCHAR(10) NOT NULL,

41 / 44
 Year INT NOT NULL,
Grade CHAR(1),
FOREIGN KEY (StudentID) REFERENCES Student(StudentID),
FOREIGN KEY (CourseID) REFERENCES Course(CourseID)
);

CREATE TABLE Advisor (

AdvisorID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Department VARCHAR(100) NOT NULL
);

CREATE TABLE Employee (

EmployeeID INT PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Position VARCHAR(50) NOT NULL,
Department VARCHAR(100),
Email VARCHAR(100) UNIQUE NOT NULL
);
4. Validations and Data Integrity
Adding constraints to ensure data integrity.
sql
ALTER TABLE Enrollment
ADD CONSTRAINT FK_Enrollment_Student FOREIGN KEY (StudentID) REFERENCES
Student(StudentID),
ADD CONSTRAINT FK_Enrollment_Course FOREIGN KEY (CourseID) REFERENCES
Course(CourseID);

ALTER TABLE Student

ADD CONSTRAINT CK_Student_Email CHECK (Email LIKE '%@%');

ALTER TABLE Instructor

ADD CONSTRAINT CK_Instructor_Email CHECK (Email LIKE '%@%');

ALTER TABLE Employee

ADD CONSTRAINT CK_Employee_Email CHECK (Email LIKE '%@%');
5. Sample Data Insertion
Inserting sample data into the tables.
sql
INSERT INTO Student (StudentID, Name, Address, DateOfBirth, Email, Phone)
VALUES (1, 'John Doe', '123 Main Street', '2000-01-01', '[email protected]', '1234567890');

42 / 44
INSERT INTO Course (CourseID, CourseName, Credits)
VALUES (1, 'Database Systems', 3);

INSERT INTO Instructor (InstructorID, Name, Department, Email)

VALUES (1, 'Dr. Jane Smith', 'Computer Science', '[email protected]');

INSERT INTO Enrollment (EnrollmentID, StudentID, CourseID, Semester, Year, Grade)

VALUES (1, 1, 1, 'Spring', 2025, 'A');

INSERT INTO Advisor (AdvisorID, Name, Department)

VALUES (1, 'Dr. Alice Johnson', 'Information Technology');

INSERT INTO Employee (EmployeeID, Name, Position, Department, Email)

VALUES (1, 'Michael Brown', 'Registrar Manager', 'Administration',
'[email protected]');
6. Ensuring Transactions and Consistency
Using transaction control to maintain consistency.
sql
BEGIN TRANSACTION;

UPDATE Student
SET Email = '[email protected]'
WHERE StudentID = 1;

INSERT INTO Enrollment (EnrollmentID, StudentID, CourseID, Semester, Year, Grade)

VALUES (2, 1, 1, 'Fall', 2025, 'B');

COMMIT;
7. Access Control and User Roles
Defining roles and access controls.
sql
CREATE ROLE Registrar;
CREATE ROLE InstructorRole;
CREATE ROLE StudentAdvisor;

GRANT SELECT, INSERT, UPDATE, DELETE ON Student TO Registrar;

GRANT SELECT, INSERT, UPDATE ON Course TO InstructorRole;
GRANT SELECT ON Enrollment TO StudentAdvisor;

43 / 44
 The end!!!

44 / 44