[ Final Project ]

Al Rajhi Bank's
Group 3
Sec: 2107
Cours: MIS 309

- Siddiq Yasir Muzayn

2220001160
- Faris Alzahrani
2220005317
- Fares Helmi
2220001742
- Abdullah Mohammed Al-dossary
2220007041
- Mohammed Alshulah
2220005654
Abstract:
This report delves into the critical issues Al Rajhi Bank faces due to its outdated
database system. At the core of these issues is a slow database that hampers transaction
speed and undermines customer satisfaction. As data volumes grow, the bank struggles
to effectively manage, analyze, and retrieve information, leading to operational hiccups.
Moreover, the system’s lackluster cybersecurity exposes the bank to serious threats such
as cyber-attacks and data breaches, putting both customer trust and the bank’s
reputation at risk. The inflexibility of the current technology also prevents the bank
from embracing new and innovative solutions, stifling progress, and efficiency.
Additionally, the limited capacity for analytics and decision support curtails the bank’s
ability to harness insights for better strategic decisions. The report outlines these
challenges in depth and recommends strategic upgrades to revitalize Al Rajhi Bank’s
data management, security, and technology infrastructure.
An Entity Relationship Diagram (ERD)
Main Body
Customer Table
CREATE TABLE Customer (
CustomerID NUMBER PRIMARY KEY,
Name VARCHAR2(100),
Address VARCHAR2(255),
Phone VARCHAR2(20)
);

CREATE OR REPLACE TRIGGER customer_bir

BEFORE INSERT ON Customer
FOR EACH ROW
BEGIN
SELECT customer_seq.NEXTVAL INTO :new.CustomerID FROM dual;
END;

INSERT INTO Customer (Name, Address, Phone) VALUES ('Mohammed Ali', '123
King Fahd Rd, Riyadh', '050 123 4567');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Fatima Khalid', '456
Prince Sultan St, Jeddah', '050 234 5678');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Ahmed Zaki', '789
Tahlia St, Riyadh', '050 345 6789');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Sara Amjad', '321 Al
Amir Sultan, Jeddah', '050 456 7890');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Khaled Tareq', '654 Al
Olaya, Riyadh', '050 567 8901');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Noor Sami', '987 Al
Khobar Shores, Khobar', '050 678 9012');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Omar Farouk', '159 Al
Tahlia, Jeddah', '050 789 0123');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Laila Bassam', '213
King Abdulaziz Rd, Riyadh', '050 890 1234');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Youssef Adel', '468
Corniche Rd, Dammam', '050 901 2345');
INSERT INTO Customer (Name, Address, Phone) VALUES ('Nadia Yasser', '752 Al
Andalus, Jeddah', '050 012 3456');
Normalization Analysis:
1NF (First Normal Form):
Achieved as each column holds atomic values, and each record is uniquely identified
by the primary key CustomerID.

2NF (Second Normal Form):

The table is in 2NF because all non-key attributes (Name, Address, Phone) are fully
dependent on the primary key CustomerID alone. There are no partial dependencies on
the primary key.

3NF (Third Normal Form):

The table satisfies 3NF. There are no transitive dependencies; non-key attributes do not
depend on each other. Each attribute is directly dependent on the primary key
CustomerID and not through another non-key attribute. For example, Address and
Phone depend solely on CustomerID and are not interdependent.
Account Table
CREATE TABLE Account (
AccountID NUMBER PRIMARY KEY,
CustomerID NUMBER NOT NULL,
Balance DECIMAL(10, 2),
Type VARCHAR2(50),
FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

CREATE OR REPLACE TRIGGER account_bir

BEFORE INSERT ON Account
FOR EACH ROW
BEGIN
SELECT account_seq.NEXTVAL INTO :new.AccountID FROM dual;
END;
INSERT INTO Account (CustomerID, Balance, Type) VALUES (1, 5000.00,
'Checking');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (2, 3000.00,
'Savings');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (3, 4500.00,
'Checking');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (4, 1200.00,
'Savings');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (5, 7600.00,
'Checking');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (6, 9800.00,
'Savings');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (7, 11200.00,
'Checking');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (8, 5500.00,
'Savings');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (9, 4800.00,
'Checking');
INSERT INTO Account (CustomerID, Balance, Type) VALUES (10, 6300.00,
'Savings');
Normalization Analysis:
1NF (First Normal Form):
Achieved as each column holds atomic values, and each record is uniquely identified
by the primary key AccountID.

2NF (Second Normal Form):

The table is in 2NF because all non-key attributes (Balance, Type) are fully dependent
on the primary key AccountID alone. There are no partial dependencies on the primary
key. The CustomerID is a foreign key and does not constitute a partial dependency but
rather a necessary relational link.

3NF (Third Normal Form):

The table satisfies 3NF. There are no transitive dependencies; non-key attributes do not
depend on each other or any other non-primary key attribute. Balance and Type are
directly dependent on AccountID, and there are no dependencies between non-key
attributes that would violate 3NF.
Transaction Table
CREATE TABLE TransactionTable (
TransactionID NUMBER PRIMARY KEY,
AccountID NUMBER NOT NULL,
EmployeeID NUMBER NOT NULL,
Amount DECIMAL(10, 2),
TransactionDate DATE,
FOREIGN KEY (AccountID) REFERENCES Account(AccountID),
FOREIGN KEY (EmployeeID) REFERENCES Employee(EmployeeID) );

CREATE OR REPLACE TRIGGER transaction_bir

BEFORE INSERT ON TransactionTable
FOR EACH ROW
BEGIN
SELECT transaction_seq.NEXTVAL INTO :new.TransactionID FROM dual;
END;
SELECT AccountID FROM Account;
SELECT EmployeeID FROM Employee;

INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,

TransactionDate) VALUES (1, 21, 150.00, TO_DATE('2024-05-10', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (2, 22, 200.00, TO_DATE('2024-05-11', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (3, 23, 250.00, TO_DATE('2024-05-12', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (4, 24, 300.00, TO_DATE('2024-05-13', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (5, 25, 350.00, TO_DATE('2024-05-14', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (6, 26, 400.00, TO_DATE('2024-05-15', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (7, 27, 450.00, TO_DATE('2024-05-16', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (8, 28, 500.00, TO_DATE('2024-05-17', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (9, 29, 550.00, TO_DATE('2024-05-18', 'YYYY-MM-
DD'));
INSERT INTO TransactionTable (AccountID, EmployeeID, Amount,
TransactionDate) VALUES (10, 30, 600.00, TO_DATE('2024-05-19', 'YYYY-MM-
DD'));

Normalization Analysis:
1NF (First Normal Form):
Achieved as each column holds atomic values, and each record is uniquely identified
by the primary key TransactionID.

2NF (Second Normal Form):

The table is in 2NF because all non-key attributes (AccountID, EmployeeID, Amount,
TransactionDate) are fully dependent on the primary key TransactionID alone. There
are no partial dependencies on the primary key.

3NF (Third Normal Form):

The table satisfies 3NF. There are no transitive dependencies; non-key attributes do not
depend on each other or any other non-primary key attribute. Each attribute such as
Amount and TransactionDate is directly dependent on TransactionID and not through
another non-key attribute.
Employee Table
CREATE TABLE Employee (

EmployeeID NUMBER PRIMARY KEY,

BranchID NUMBER NOT NULL,
Name VARCHAR2(100),
Position VARCHAR2(100),
FOREIGN KEY (BranchID) REFERENCES Branch(BranchID)
);

CREATE OR REPLACE TRIGGER employee_bir

BEFORE INSERT ON Employee
FOR EACH ROW
BEGIN
SELECT employee_seq.NEXTVAL INTO :new.EmployeeID FROM dual;
END;

INSERT INTO Employee (BranchID, Name, Position) VALUES (1, 'Ali Hassan',
'Manager');
INSERT INTO Employee (BranchID, Name, Position) VALUES (2, 'Huda Faisal',
'Assistant Manager');
INSERT INTO Employee (BranchID, Name, Position) VALUES (3, 'Majed Saleh',
'Teller');
INSERT INTO Employee (BranchID, Name, Position) VALUES (4, 'Rania Yousif',
'Customer Service Rep');
INSERT INTO Employee (BranchID, Name, Position) VALUES (5, 'Faisal Omar',
'Manager');
INSERT INTO Employee (BranchID, Name, Position) VALUES (6, 'Lama Ayman',
'Teller');
INSERT INTO Employee (BranchID, Name, Position) VALUES (7, 'Sami Nasser',
'Loan Officer');
INSERT INTO Employee (BranchID, Name, Position) VALUES (8, 'Reem Khaled',
'Teller');
INSERT INTO Employee (BranchID, Name, Position) VALUES (9, 'Kareem Ahmad',
'Manager');
INSERT INTO Employee (BranchID, Name, Position) VALUES (10, 'Sara Abdullah',
'Assistant Manager');

Normalization Analysis:
1NF (First Normal Form):
The table is in 1NF as each column holds atomic values, and each record is unique
through the primary key EmployeeID.
2NF (Second Normal Form):
Achieved, as there are no partial dependencies of any column on the primary key.
Each non-key column (Name, Position, BranchID) is fully functionally dependent on
the primary key.

3NF (Third Normal Form):

The table also satisfies 3NF. There are no transitive dependencies; non-key columns do
not depend on other non-key columns. Each non-key attribute is dependent only on
EmployeeID.
Branch Table
CREATE TABLE Branch (
BranchID NUMBER PRIMARY KEY,
Address VARCHAR2(255),
Phone VARCHAR2(20)
);

CREATE OR REPLACE TRIGGER branch_bir

BEFORE INSERT ON Branch
FOR EACH ROW
BEGIN
SELECT branch_seq.NEXTVAL INTO :new.BranchID FROM dual;
END;

INSERT INTO Branch (Address, Phone) VALUES ('100 Main St, Riyadh', '011 123
4567');
INSERT INTO Branch (Address, Phone) VALUES ('200 Second St, Jeddah', '012 234
5678');
INSERT INTO Branch (Address, Phone) VALUES ('300 Third St, Dammam', '013
345 6789');
INSERT INTO Branch (Address, Phone) VALUES ('400 Fourth St, Medina', '014 456
7890');
INSERT INTO Branch (Address, Phone) VALUES ('500 Fifth St, Mecca', '015 567
8901');
INSERT INTO Branch (Address, Phone) VALUES ('600 Sixth St, Khobar', '016 678
9012');
INSERT INTO Branch (Address, Phone) VALUES ('700 Seventh St, Tabuk', '017 789
0123');
INSERT INTO Branch (Address, Phone) VALUES ('800 Eighth St, Taif', '018 890
1234');
INSERT INTO Branch (Address, Phone) VALUES ('900 Ninth St, Najran', '019 901
2345');
INSERT INTO Branch (Address, Phone) VALUES ('1000 Tenth St, Al Qassim', '020
012 3456');
Normalization Analysis:
1NF (First Normal Form):
The table is in 1NF as each column holds atomic values, and each record is unique
through the primary key BranchID.

2NF (Second Normal Form):

Achieved, as there are no partial dependencies of any column on the primary key.
Address and Phone are fully functionally dependent on BranchID, not on a subset of
the primary key.

3NF (Third Normal Form):

The table satisfies 3NF as there are no transitive dependencies among non-key
attributes. Both Address and Phone are directly dependent on BranchID and not on each
other or any other non-key attribute.
Loan Table
CREATE TABLE Loan (
LoanID NUMBER PRIMARY KEY,
AccountID NUMBER NOT NULL,
LoanAmount DECIMAL(10, 2),
InterestRate DECIMAL(5, 2),
StartDate DATE,
EndDate DATE,
FOREIGN KEY (AccountID) REFERENCES Account(AccountID)
);

CREATE OR REPLACE TRIGGER loan_bir

BEFORE INSERT ON Loan
FOR EACH ROW
BEGIN
SELECT loan_seq.NEXTVAL INTO :new.LoanID FROM dual;
END;

INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)

VALUES (1, 10000.00, 5.00, TO_DATE('2024-01-01', 'YYYY-MM-DD'),
TO_DATE('2029-01-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (2, 15000.00, 4.50, TO_DATE('2024-02-01', 'YYYY-MM-DD'),
TO_DATE('2029-02-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (3, 20000.00, 4.25, TO_DATE('2024-03-01', 'YYYY-MM-DD'),
TO_DATE('2029-03-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (4, 25000.00, 4.00, TO_DATE('2024-04-01', 'YYYY-MM-DD'),
TO_DATE('2029-04-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (5, 30000.00, 3.75, TO_DATE('2024-05-01', 'YYYY-MM-DD'),
TO_DATE('2029-05-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (6, 35000.00, 3.50, TO_DATE('2024-06-01', 'YYYY-MM-DD'),
TO_DATE('2029-06-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (7, 40000.00, 3.25, TO_DATE('2024-07-01', 'YYYY-MM-DD'),
TO_DATE('2029-07-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (8, 45000.00, 3.00, TO_DATE('2024-08-01', 'YYYY-MM-DD'),
TO_DATE('2029-08-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (9, 50000.00, 2.75, TO_DATE('2024-09-01', 'YYYY-MM-DD'),
TO_DATE('2029-09-01', 'YYYY-MM-DD'));
INSERT INTO Loan (AccountID, LoanAmount, InterestRate, StartDate, EndDate)
VALUES (10, 55000.00, 2.50, TO_DATE('2024-10-01', 'YYYY-MM-DD'),
TO_DATE('2029-10-01', 'YYYY-MM-DD'));

Normalization Analysis:
1NF (First Normal Form):
The table is in 1NF as each column holds atomic values (single values), and each record
is uniquely identified by the primary key LoanID.

2NF (Second Normal Form):

Achieved, as there are no partial dependencies of any column on the primary key. All
attributes (AccountID, LoanAmount, InterestRate, StartDate, EndDate) are fully
functionally dependent on the whole primary key (LoanID), not just a part of it.

3NF (Third Normal Form):

The table satisfies 3NF as there are no transitive dependencies among non-key
attributes. All attributes are dependent on LoanID and not on each other. For example,
LoanAmount and InterestRate depend only on LoanID and are independent of each
other or any secondary key.
Investment Table
CREATE TABLE Investment (
InvestmentID NUMBER PRIMARY KEY,
CustomerID NUMBER NOT NULL,
Type VARCHAR2(100),
Amount DECIMAL(10, 2),
StartDate DATE,
MaturityDate DATE,
FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

CREATE OR REPLACE TRIGGER investment_bir

BEFORE INSERT ON Investment
FOR EACH ROW
BEGIN
SELECT investment_seq.NEXTVAL INTO :new.InvestmentID FROM dual;
END;

INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)

VALUES (1, 'Bonds', 10000.00, TO_DATE('2024-01-01', 'YYYY-MM-DD'),
TO_DATE('2029-01-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (2, 'Stocks', 15000.00, TO_DATE('2024-02-01', 'YYYY-MM-DD'),
TO_DATE('2029-02-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (3, 'Mutual Funds', 20000.00, TO_DATE('2024-03-01', 'YYYY-MM-DD'),
TO_DATE('2029-03-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (4, 'Real Estate', 25000.00, TO_DATE('2024-04-01', 'YYYY-MM-DD'),
TO_DATE('2029-04-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (5, 'Bonds', 30000.00, TO_DATE('2024-05-01', 'YYYY-MM-DD'),
TO_DATE('2029-05-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (6, 'Stocks', 35000.00, TO_DATE('2024-06-01', 'YYYY-MM-DD'),
TO_DATE('2029-06-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (7, 'Mutual Funds', 40000.00, TO_DATE('2024-07-01', 'YYYY-MM-DD'),
TO_DATE('2029-07-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (8, 'Real Estate', 45000.00, TO_DATE('2024-08-01', 'YYYY-MM-DD'),
TO_DATE('2029-08-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (9, 'Bonds', 50000.00, TO_DATE('2024-09-01', 'YYYY-MM-DD'),
TO_DATE('2029-09-01', 'YYYY-MM-DD'));
INSERT INTO Investment (CustomerID, Type, Amount, StartDate, MaturityDate)
VALUES (10, 'Stocks', 55000.00, TO_DATE('2024-10-01', 'YYYY-MM-DD'),
TO_DATE('2029-10-01', 'YYYY-MM-DD'));

Normalization Analysis:
1NF (First Normal Form):
The table is in 1NF as each column holds atomic values (single values), and each record
is uniquely identified by the primary key InvestmentID.

2NF (Second Normal Form):

Achieved, as there are no partial dependencies of any column on the primary key. All
attributes (Type, Amount, StartDate, MaturityDate) are fully functionally dependent on
the whole primary key (InvestmentID), not just a part of it.

3NF (Third Normal Form):

The table satisfies 3NF as there are no transitive dependencies among non-key
attributes. All attributes are dependent on InvestmentID and not on each other. For
example, Amount and Type depend only on InvestmentID and are independent of each
other or any secondary key.
ATM Table
CREATE TABLE ATM (
ATMID NUMBER PRIMARY KEY,
Location VARCHAR2(255),
ManagedBy NUMBER NOT NULL,
InstallationDate DATE,
Model VARCHAR2(100),
FOREIGN KEY (ManagedBy) REFERENCES Employee(EmployeeID)
);

CREATE OR REPLACE TRIGGER atm_bir

BEFORE INSERT ON ATM
FOR EACH ROW
BEGIN
SELECT atm_seq.NEXTVAL INTO :new.ATMID FROM dual;
END;

INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('123

Main St, Riyadh', 21, TO_DATE('2023-01-01', 'YYYY-MM-DD'), 'Model X100');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('234
Second St, Jeddah', 22, TO_DATE('2023-01-02', 'YYYY-MM-DD'), 'Model X200');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('345
Third St, Dammam', 23, TO_DATE('2023-01-03', 'YYYY-MM-DD'), 'Model X300');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('456
Fourth St, Mecca', 24, TO_DATE('2023-01-04', 'YYYY-MM-DD'), 'Model X400');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('567
Fifth St, Medina', 25, TO_DATE('2023-01-05', 'YYYY-MM-DD'), 'Model X500');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('678
Sixth St, Khobar', 26, TO_DATE('2023-01-06', 'YYYY-MM-DD'), 'Model X600');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('789
Seventh St, Tabuk', 27, TO_DATE('2023-01-07', 'YYYY-MM-DD'), 'Model X700');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('890
Eighth St, Taif', 28, TO_DATE('2023-01-08', 'YYYY-MM-DD'), 'Model X800');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('901
Ninth St, Najran', 29, TO_DATE('2023-01-09', 'YYYY-MM-DD'), 'Model X900');
INSERT INTO ATM (Location, ManagedBy, InstallationDate, Model) VALUES ('1012
Tenth St, Al Qassim', 30, TO_DATE('2023-01-10', 'YYYY-MM-DD'), 'Model X1000');

Normalization Analysis:
1NF (First Normal Form):
Achieved as each column holds atomic values, and each record is uniquely identified
by the primary key ATMID.

2NF (Second Normal Form):

The table is in 2NF because all non-key attributes (Location, ManagedBy,
InstallationDate, Model) are fully dependent on the primary key ATMID alone. There
are no partial dependencies on the primary key.

3NF (Third Normal Form):

The table satisfies 3NF. There are no transitive dependencies; non-key attributes do not
depend on each other. Each attribute is directly dependent on the primary key ATMID
and not through another non-key attribute. For example, Model and Location depend
solely on ATMID and are not interdependent.
Credit Card Table
CREATE TABLE CreditCard (
CardID NUMBER PRIMARY KEY,
AccountID NUMBER NOT NULL,
CreditLimit DECIMAL(10, 2),
IssueDate DATE,
ExpiryDate DATE,
FOREIGN KEY (AccountID) REFERENCES Account(AccountID)
);

CREATE OR REPLACE TRIGGER card_bir

BEFORE INSERT ON CreditCard
FOR EACH ROW
BEGIN
SELECT card_seq.NEXTVAL INTO :new.CardID FROM dual;
END;

INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES

(1, 5000.00, TO_DATE('2024-01-01', 'YYYY-MM-DD'), TO_DATE('2029-01-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(2, 7000.00, TO_DATE('2024-02-01', 'YYYY-MM-DD'), TO_DATE('2029-02-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(3, 9000.00, TO_DATE('2024-03-01', 'YYYY-MM-DD'), TO_DATE('2029-03-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(4, 11000.00, TO_DATE('2024-04-01', 'YYYY-MM-DD'), TO_DATE('2029-04-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(5, 12000.00, TO_DATE('2024-05-01', 'YYYY-MM-DD'), TO_DATE('2029-05-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(6, 13000.00, TO_DATE('2024-06-01', 'YYYY-MM-DD'), TO_DATE('2029-06-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(7, 15000.00, TO_DATE('2024-07-01', 'YYYY-MM-DD'), TO_DATE('2029-07-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(8, 16000.00, TO_DATE('2024-08-01', 'YYYY-MM-DD'), TO_DATE('2029-08-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(9, 17000.00, TO_DATE('2024-09-01', 'YYYY-MM-DD'), TO_DATE('2029-09-01',
'YYYY-MM-DD'));
INSERT INTO CreditCard (AccountID, CreditLimit, IssueDate, ExpiryDate) VALUES
(10, 18000.00, TO_DATE('2024-10-01', 'YYYY-MM-DD'), TO_DATE('2029-10-01',
'YYYY-MM-DD'));

Normalization Analysis:
1NF (First Normal Form):
Achieved as each column holds atomic values, and each record is uniquely identified
by the primary key CardID.

2NF (Second Normal Form):

The table is in 2NF because all non-key attributes (CreditLimit, IssueDate, ExpiryDate)
are fully dependent on the primary key CardID alone. There are no partial dependencies
on the primary key.

3NF (Third Normal Form):

The table satisfies 3NF. There are no transitive dependencies; non-key attributes do not
depend on each other. Each attribute is directly dependent on the primary key CardID
and not through another non-key attribute. For example, CreditLimit and IssueDate
depend solely on CardID and are not interdependent.
Safe Deposit Box Table
CREATE TABLE SafeDepositBox1 (
BoxID NUMBER PRIMARY KEY,
BranchID NUMBER NOT NULL,
CustomerID NUMBER NOT NULL,
RentalStartDate DATE,
RentalEndDate DATE,
FOREIGN KEY (BranchID) REFERENCES Branch(BranchID),
FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

CREATE OR REPLACE TRIGGER box_bir

BEFORE INSERT ON SafeDepositBox1
FOR EACH ROW
BEGIN
:new.BoxID := box_seq.NEXTVAL;
END;

INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,

RentalEndDate) VALUES (1, 1, TO_DATE('2024-01-01', 'YYYY-MM-DD'),
TO_DATE('2025-01-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (2, 2, TO_DATE('2024-01-15', 'YYYY-MM-DD'),
TO_DATE('2025-01-15', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (3, 3, TO_DATE('2024-02-01', 'YYYY-MM-DD'),
TO_DATE('2025-02-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (4, 4, TO_DATE('2024-03-01', 'YYYY-MM-DD'),
TO_DATE('2025-03-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (5, 5, TO_DATE('2024-04-01', 'YYYY-MM-DD'),
TO_DATE('2025-04-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (6, 6, TO_DATE('2024-05-01', 'YYYY-MM-DD'),
TO_DATE('2025-05-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (7, 7, TO_DATE('2024-06-01', 'YYYY-MM-DD'),
TO_DATE('2025-06-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (8, 8, TO_DATE('2024-07-01', 'YYYY-MM-DD'),
TO_DATE('2025-07-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (9, 9, TO_DATE('2024-08-01', 'YYYY-MM-DD'),
TO_DATE('2025-08-01', 'YYYY-MM-DD'));
INSERT INTO SafeDepositBox1 (BranchID, CustomerID, RentalStartDate,
RentalEndDate) VALUES (10, 10, TO_DATE('2024-09-01', 'YYYY-MM-DD'),
TO_DATE('2025-09-01', 'YYYY-MM-DD'));

Normalization Analysis:
1NF (First Normal Form):
Achieved as each column holds atomic values, and each record is uniquely identified
by the primary key BoxID.

2NF (Second Normal Form):

The table is in 2NF because all non-key attributes (BranchID, CustomerID,
RentalStartDate, RentalEndDate) are fully dependent on the primary key BoxID alone.
There are no partial dependencies on the primary key.

3NF (Third Normal Form):

The table satisfies 3NF. There are no transitive dependencies; non-key attributes do not
depend on each other. Each attribute is directly dependent on the primary key BoxID
and not through another non-key attribute. For example, RentalStartDate and
RentalEndDate are solely dependent on BoxID and do not depend on BranchID or
CustomerID.
Identification of Primary (PK) and Foreign (FK) Keys in Each Table:
1. Customer Table:
- Primary Key (PK): CustomerID
- Foreign Key (FK): None (This is a foundational table with no dependencies on other
tables)

2. Account Table:
- Primary Key (PK): AccountID
- Foreign Key (FK): CustomerID (References CustomerID in Customer table)

3. Transaction Table:
- Primary Key (PK): TransactionID
- Foreign Keys (FKs):
- AccountID (References AccountID in Account table)
- EmployeeID (References EmployeeID in Employee table)

4. Employee Table:
- Primary Key (PK): EmployeeID
- Foreign Key (FK): BranchID (References BranchID in Branch table)

5. Branch Table:
- Primary Key (PK): BranchID
- Foreign Key (FK): None (This table serves as a foundational structure for other
tables like Employee)

6. Loan Table:
- Primary Key (PK): LoanID
- Foreign Key (FK): AccountID (References AccountID in Account table)
7. Investment Table:
- Primary Key (PK): InvestmentID
- Foreign Key (FK): CustomerID (References CustomerID in Customer table)

8. ATM Table:
- Primary Key (PK): ATMID
- Foreign Key (FK): ManagedBy (References EmployeeID in Employee table)
9. Credit Card Table:
- Primary Key (PK): CardID
- Foreign Key (FK): AccountID (References AccountID in Account table)

10. Safe Deposit Box Table:

- Primary Key (PK): BoxID
- Foreign Keys (FKs):
- BranchID (References BranchID in Branch table)
- CustomerID (References CustomerID in Customer table)
Conclusion and Recommendations
In conclusion, the design and implementation of the Entity Relationship Diagram
(ERD) and the corresponding database tables for Al Rajhi Bank have been outlined
comprehensively. This project aimed to provide a structured framework for managing
various aspects of the bank's operations, including customer accounts, transactions,
employee assignments, branch information, as well as additional services such as loans,
investments, ATMs, credit cards, and safe deposit boxes.
The ERD illustrates the relationships between different entities, guiding the
organization of data within the relational database. Additionally, the normalization
process ensured that the tables are structured efficiently, minimizing redundancy and
dependency issues while adhering to the principles of First, Second, and Third Normal
Forms.

Recommendations:
1. Maintain data integrity through regular monitoring and validation.
2. Design the database structure to be scalable for future growth and changes.
3. Implement robust security measures to protect sensitive data.
4. Optimize database performance for efficient operations.
5. Establish a backup and recovery strategy to mitigate data loss risks.
6. Provide adequate user training and documentation for effective database utilization.
7. Ensure regulatory compliance with relevant laws and standards.

These recommendations aim to support the bank in managing its database securely,
efficiently, and in compliance with industry requirements.