0% found this document useful (0 votes)
46 views23 pages

Integrated CA OOC DB Report

Uploaded by

Fantic Bot
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views23 pages

Integrated CA OOC DB Report

Uploaded by

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

1

CCT College Dublin Continuous Assessment

Programme Title: BSc (Hons) in Computing in Information Technology

Delivery Mode: In-person

Cohort Details: Sep 2023

Module Title(s): Databases & OOC Integrated CA

Assignment Type: Group Weighting(s): OOC (50%)

DB (20%)

Assignment Title: Integrated Databases and OCC

Lecturer(s): James Garza ([email protected])

Kayoum Khbuli ([email protected])

Issue Date: 25th-Nov-2024

Submission Sunday, 15th December 2024 @ 23:59


Deadline Date:

Late submissions will be accepted up to 5 calendar days after the deadline. All late
Late Submission submissions are subject to a penalty of 10% of the mark awarded.
Penalty: Submissions received more than 5 calendar days after the deadline above will not
be accepted and a mark of 0% will be awarded.

Method of
This assignment is submitted via Moodle.
Submission:

Source code (.java files and GitHub link).


Instructions for
Documentation in Word format.
Submission:
DO NOT ZIP YOUR FILES, UPLOAD THE FILES TO MOODLE INDIVIDUALLY.

Feedback
Results posted in Moodle gradebook
Method:

Feedback Date: After February Board Meeting


2

INTEGRATED CA – OOC and DB


TAX COLLECTION SYSTEM
WITH JAVA and MYSQL

Fredrick Kipngetich Kimutai – 2024658


Joel Jose Martin – 2024635
Joyce Lisboa do Nascimento – 2023445
Tayyaba Mehboob - 2024376
3

CONTENT
1. Introduction……………………………………………………………………… 4
2. Object-Oriented Design: Overview…………………………............... 4-5
3. Database Interaction and MySQL Interaction: Overview…… 5-19
4. CA1 Updated Part……………………………………………………….......... 19-22
5. References………………………………………………………………………… 23
4

Report: OOC and DB


Introduction
The project aims at producing and developing a User Management System that
implements both the Object-Oriented Programming principles as well as connecting to a
Database and storing the data in the created database. The system aims to manage user
data for registration and user authentication or login. It also does tax calculation. It was
developed using JAVA, MySQL and OOP principle within JAVA like inheritance,
encapsulation and polymorphism.
The User Management system has types of users, which includes the Regular user as
well as the Admin. The admin has power to modifying user profiles, view user details
and also has the ability to remove users. The regular user can modify their profiles and
calculate their taxes. The JAVA program uses MySQL database to store and retrieve data
and conduct the necessary operations.
This report in overall provides in depth an overview of all the OOP principles used and
how all the class interact with MySQL database. It will also provide the logical and
conceptual design and normalization of the database.

Object-Oriented Design: Overview


The system is designed using Object-Oriented Programming Principles (OOP). It makes
the application more appealing, easy to read and understand and also easy to
implement. It is also easily maintained and also scalable. Encapsulation, Polymorphism
and Inheritance are the main concepts used.
Different Classes:
• User – it consists of the user. It has functions for storing all the suer data and for
setting and getting the details. It makes sure data is safe and secure.
• RegularUser – it is a subclass of User, helping in calculating taxes on gross
income and modifying the user profile. It inherits functionality from the User
class like attributes and modifications.
• AdminUser – it is also a subclass of User class and is designed for Admins. They
can view all users and delete them as necessary. They can also modify profiles
and manage all the users. It also inherits functionalities from the User class just
like the RegularUser class.
• UserDAO – the UserDAO (Data Access Object) class interacts with MySQL. It is
the class that performs CRUD operations as per requirements. This class
authenticates a user, adds a new user, deletes as well as updates the details. This
class displays the logic behind the database interactions.
• OperationLog – this class records the operations done by the Users and the
Admin. Creating, updating or deleting will record a change in the OperationLog
object.
5

• DatabaseConnection and TestConnection – these classes are made to connect


to MySQL database. And to test the connection respectively. The
DatabaseConnection class sets the connection, username as well as password.
The TestConnection class tests the connections and displays message
accordingly.
• OOP_DB_INTEGRATED – this is the main class of the program. This combines all
the created classes and executes its functionalities together. It helps in
completing all the functions and connections all the other classes incorporate.

Inheritance, Encapsulation and Polymorphism


• Inheritance – this principle of OOP is displayed mainly in the AdminUser and
RegularUser classes. These classes inherit the functionalities of the User class.
This makes the code more understandable and maintainable. The subclasses
have access to the methods defined in the User class while being able to add their
own functionalities. (GeeksForGeeks, 2017)
• Encapsulation – this principle is implemented through the User class and
OperationLog class. Encapsulation principle protects all the user data and also
bundling the data with different methods that operate within the class and are
not directly accessible with other classes. The User class protects the passwords
and other details while the OperationLog class has its variables declared in
private stopping direct access of the variable and methods. (Janssen, 2023)
• Polymorphism - this principle of OOP allows objects to be treated as instances
of their parent class. It is implemented here through overriding the AdminUser
and RegularUser classes. They override the methods from the User class
providing the functionality of User class to be implemented in them. (Taylor,
2023)
What Each Member Did
• Joyce – DatabaseConnection and TestConnetion class
• Joel – User and RegularUser Class
• Tayyaba – UserDOA and AdminUser class
• Fredrick – OperationLog and OOP_DB_INTEGRATED class

Database Interaction and MySQL Interaction: Overview


Challenges faced while creating the project
Many challenges were faced during the design and implementation of this system. The
main one was designing the object-oriented integration. The system required making
two types of users: Regular User and Admin, both having different functions.
Implementing these and assigning different roles for each other was a big task.
Designing the Database as well as connecting to the MySQL database was a primary
challenge. We had to make sure that the connections were proper and it was secure and
6

all tables and values and data were stored in real-time in the database while running
and executing the system.
Then we had to make sure that the user inputs were correct and valid and it followed
the rules mentioned. We also had to make sure that they were correctly stored in the
database. We had to make sure that only the admins with special authority have access
to all user data to ensure integrity. The other challenge was to show error management
while inputting data and make sure user input right data. There were also other
challenges like creating the right schema and tables, normalisation of data and making
the right decisions.
Strategies used to Overcome the Challenges
Various strategies were used to overcome the challenges.
▪ Researching and using available sources to create an idea on what to create.
▪ Created a schema and used iterative design. Used GitHub to pool the code and
cultivate ideas and complete the system program and design.
▪ Used OOP principles in JAVA to meet the requirements of the system.
▪ We implemented role-based access for different types of users.
▪ Used MySQL queries to check and test the table creation and data storage.
▪ Made use of the JAVA multi class attribute to divide different function into
various classes making it easy to design.
▪ Used error-handling mechanisms to check for errors and faulty user inputs.
▪ Made sure that the data was secure and was only accessible to admins by
utilising Encapsulation principle of OOP.
▪ We made a separate class just to ensure that if the connection was made
successfully or not. It showed us if the connection was made or if there were any
error with the connection.

Rationale behind the Decisions


▪ Object-Oriented Design – it was chosen because it was modular and scalable. It is
easy to scale the system to meet any additional requirements. It helps add new
functions as well as new users easily.
The reason for using Encapsulation was to ensure data security and to make sure
that the classes and methods are not misused. Used Polymorphism and Inheritance as it
helps having a common functionality class and having subclasses which uses those
functionalities. I did that as it makes the code more appealing and manageable.
▪ Database Design – used MySQL because it is reliable and it supports relational
databases. Separate tables were made for Users and Operation Logs because it
helped the database to be scalable and modular. These are the two tables which
store the data.
The User table was created to store the details of the User and the Operation Log
table was created to store the functions and the calculated tax and other
7

calculations. The tables are expandable and can be expanded and be added new
functions as per need.

Logical Design
The User Management interacts with MySQL database to store the data and manage it. A
database schema was made which stores information about users including their
personal details, user types, passwords and operation logs. The connection between the
JAVA and MySQL is done by the DatabaseConnection class and the interactions and all
the workload is handled by the UserDOA class.
Mainly three tables were created: The User table for the users and the Operation_Log
table for carrying out the operations.
➢ user_types Table – this defines the types of users in the system: Admin and
Regular. They are identified by the type_id and type_name. These store the
numbers to choose if the the user wants to sign in as admin or as a regular user.
In this type_id is the Primary Key.

This is the SQL code to create the table:


CREATE TABLE user_types (
type_id INT PRIMARY KEY,
type_name VARCHAR(50) NOT NULL
);

This is the table: user_types


Column Name Data Type Constraints
type_id (PK) INT PRIMARY KEY
type_name VARCHAR(50) NOT NULL

➢ users Table – it is used to store essential information about the user. It includes
the usernames, password email, gross_income, etc. Then there is type-id that
links the user to the user type in user_type table as a foreign key. In this table the
user_id is the Primary Key.
This is the SQL code to create the table:
CREATE TABLE users (
user_id INT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50) UNIQUE NOT NULL,
password VARCHAR(255) NOT NULL,
first_name VARCHAR(50),
last_name VARCHAR(50),
8

email VARCHAR(100),
type_id INT,
gross_income DECIMAL(10,2) DEFAULT 0.00,
tax_credits DECIMAL(10,2) DEFAULT 0.00,
FOREIGN KEY (type_id) REFERENCES user_types(type_id)
);
This is the table: users Table
Column Name Data Type Constraints
user_id (PK) INT PRIMARY KEY, AUTO_INCREMENT
username VARCHAR(50) UNIQUE, NOT NULL
password VARCHAR(255) NOT NULL
first_name VARCHAR(50)
last_name VARCHAR(50)
email VARCHAR(100)
type_id (FK) INT FOREIGN KEY(REFERENCES
user_types(type_id))
gross_income DECIMAL(10,2) DEFAULT 0.00
tax_credits DECIMAL(10,2) DEFAULT 0.00

➢ operations_log – this tables logs or stores the actions that are performed by the
users like tax calculations, profile modifications, etc. In this table the
‘operation_id’ is the Primary Key. Each log entry includes an ‘operation_type’,
‘operation_details’, and an ‘operation_timestamp’. This table references users
through the’user_id’.

The sql code to create the table is:

CREATE TABLE operations_log (


operation_id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
operation_type VARCHAR(50) NOT NULL,
operation_details TEXT,
operation_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(user_id)
);

This is the table: operations_log


Column Name Data Type Constraints
operation_id (PK) INT PRIMARY KEY, AUTO_INCREMENT
user_id (FK) INT FOREIGN KEY (REFERENCES users
(user_id))
operation_type VARCHAR(50) NOT NULL
9

operation_details TEXT
operation_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP

CRUD Operations in UserDAO


UserDAO class interacts and carries out the operations and functions with MySQL
database using the JAVA Database Connectivity (JDCB). The JDCB uses SQL queries to
perform various operations such as creating, reading, updating and deleting users. We
have implemented the CRUD operation in the system using this. Here are the example
codes written in the program which does this.
public boolean authenticateUser9String username, String password) {
String sql = “SELECT*FROM users WHERE username = ? AND password = ?”;
try (Connection conn = DatabaseConnection.getConnection();
PreparedStatement pstmt = conn.prepareStatement(sql)) {
ptsmt.setString(1, username);
ptsmt.setString(2, password);
try (ResultSet rs = ptsmt.executeQuery()) {
return rs.next();
}
}catch (SQLException e) {
e.printStackTrace();
return false;
}
}

NORMALISATION
It is the process in which the database is organised to reduce dependency and
redundancy. It ensures data integrity as well as efficiency. Redundancy may cause
insertion, deletion and update anomalies. (Microsoft, 2024). They are a series of
guidelines which helps in ensuring that the data is efficiently organised. The schema we
created will be transformed from Un-normalized Form (UNF) to First, Second and Third
Normal Form (1NF, 2NF, 3NF).
The schema we created has three different entities. They are ‘user’, ‘user_types’ and
‘operations_log’.
Table: user_types
10

type_id (PK) type_name


1 Admin
2 Regular

Table: user
user_id (PK) 1
username CCT
password Dublin
first_name Admin
last_name User
email [email protected]
type_id (FK) 1
gross_income 0.00
tax_credits 0.00

Table: operations_log
operation_id user_id operation_type operation_details operation_timestamp
(PK) (FK)
1 1 Login Successful login 2024-12-19
00:00:00
2 1 Profile Update Changed email 2024-12-19
01:00:00

These schema tables are the entities and they contain the dummy values passed to them.
We have to normalise these.
➢ 1st Normal Form – All the tables or entities are in First Normal Form as all the
columns contain atomic values. No groups in these tables have repeating values
and every column has a unique value. Therefore, they are in 1NF,
➢ 2nd Normal Form – They are already in 2NF as there are no partial key
dependencies. All the non-key attributes in all the tables completely depend on
the Primary Key. Therefore, they are in 2NF.
➢ 3rd Normal Form – All the entities are already in 3NF also. It is because to be in
3NF all non-key dependencies should be dependent on the Primary Key. It should
not be dependent on other non-key dependencies. It means there should be no
Transitive dependencies. All the entities completely follow this rule. Therefore,
they are in 3NF.
Is Normalisation Necessary?
In this case Normalisation is not necessary as all the entities are already in 3NF and
follow all the rules. They completed the normalisation process. Therefore, there is no
further need of Normalisation.
11

CHEN NOTATION
In this CHEN diagram the entities are related to each other.

• User Types to Users – It has a one-to-many relation as a user type can have
multiple users.
• Users to Operations Log – It has a one-to-many relation as a user can have
multiple operation logs.

SQL STATEMENTS
The system connects to MySQL database and stores all the data and the operations. SQL
queries will demonstrate how the system works and store the data in the database.
12

This SQL query will create a Database called user_management.

Then this will create the User Types table in the database just created. The table created
and its contents is shown on the left side under schema.

Next, this query will create a table for Users to store the user’s data. The table is also
shown on the left side under schema.
13

This query is to create the Operations Log table. This is also shown on the left side under
schema.

This query will insert dummy data values into the User Types table and the User table.
14

This live time shows the values entered into the User Type table. The values passed
through the code are inserted into the table as we can see.

This live time shows the values entered into the User table. The table now contains the
values passed through the query code into the User table.
15

The next 2 queries are to verify if the user tables was created or not and to drop the
foreign key from the Operation logs table.

This query is to add anew Foreign Key to the Operations Log table. It will add user_id as
the key.
16

The next queries have some purposes. It creates a trigger before a row in users table is
deleted. The next set of the query deletes all log operations from operations_log where
the user_id matches the user that is going to be deleted.

The last set of 5 lines of queries are Optional queries which can be executed if needed.
It copies the logs of the user that is going to be deleted into an Archive table.
Then, it delets the original log of that user from the operations_log table.
The END line indicates the end of the Trigger logic.
17

Database File
CREATE DATABASE IF NOT EXISTS user_management;
USE user_management;

CREATE TABLE user_types (


type_id INT PRIMARY KEY,
type_name VARCHAR(50) NOT NULL
);

CREATE TABLE users (


user_id INT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50) UNIQUE NOT NULL,
password VARCHAR(255) NOT NULL,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(100),
type_id INT,
gross_income DECIMAL(10,2) DEFAULT 0.00,
tax_credits DECIMAL(10,2) DEFAULT 0.00,
FOREIGN KEY (type_id) REFERENCES user_types(type_id)
);

CREATE TABLE operations_log (


operation_id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
operation_type VARCHAR(50) NOT NULL,
operation_details TEXT,
operation_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(user_id)
);
18

INSERT INTO user_types (type_id, type_name) VALUES


(1, 'ADMIN'),
(2, 'REGULAR');

-- Insert admin user (CCT/Dublin)


INSERT INTO users (username, password, first_name, last_name, email, type_id) VALUES
('CCT', 'Dublin', 'Admin', 'User', '[email protected]', 1);
-- Verify tables were created
SHOW TABLES;

-- Verify user types were inserted


SELECT * FROM user_types;

-- Verify admin user was created


SELECT * FROM users;
ALTER TABLE operations_log
DROP FOREIGN KEY operations_log_ibfk_1;

-- Add it back with CASCADE option


ALTER TABLE operations_log
ADD CONSTRAINT operations_log_ibfk_1
FOREIGN KEY (user_id)
REFERENCES users(user_id)
ON DELETE CASCADE;

DELIMITER //

CREATE TRIGGER before_user_delete


BEFORE DELETE ON users
19

FOR EACH ROW


BEGIN
-- Either delete the logs
DELETE FROM operations_log WHERE user_id = OLD.user_id;

-- Or move them to an archive table


-- INSERT INTO operations_log_archive
-- SELECT * FROM operations_log
-- WHERE user_id = OLD.user_id;
-- DELETE FROM operations_log
-- WHERE user_id = OLD.user_id;
END//

CA1 UPDATED PART

1. Schema Design
Table 1: Employee Table
Column Name Data Type Constraints
employee_ID INT PRIMARY KEY,
AUTO_INCREMENT
first_name VARCHAR(50) NOT NULL
last_name VARCHAR(50) NOT NULL
date_of_birth DATE NOT NULL
gender CHAR(1) NOT NULL
email VARCHAR(100) UNIQUE, NOT NULL
phone_number VARCHAR(15) UNIQUE, NOT NULL
employment_status VARCHAR(20) NOT NULL
start_date DATE NOT NULL
end_date DATE NULLABLE
manager_ID INT FOREIGN KEY
REFERENCES employee_ID

Table 2: Address Table


Column Name Data Type Constraints
20

address_ID INT PRIMARY KEY,


AUTO_INCREMENT
employee_ID INT FOREIGN KEY
REFERENCES employee_ID
address VARCHAR(255) NOT NULL
city VARCHAR(50) NOT NULL
country VARCHAR(50) NOT NULL

Table 3: Job Table


Column Name Data Type Constraints
job_ID INT PRIMARY KEY,
AUTO_INCREMENT
employee_ID INT FOREIGN KEY
REFERENCES employee_ID
job_title VARCHAR(100) NOT NULL
department VARCHAR(100) NOT NULL
salary DECIMAL(10, 2) NOT NULL

Table 4: Language Table

Column Name Data Type Constraints


language_ID INT PRIMARY KEY,
AUTO_INCREMENT
employee_ID INT FOREIGN KEY
REFERENCES employee_ID
language VARCHAR(50) NOT NULL

The schema's data structure consists of four entities: Employee, Address, Job, and
Language. It enables relationships like one-to-many and recursive ones and employs
foreign and primary keys to provide referential integrity (Dohmen, et al., 2024). This
structure is scalable, redundant-free, and based on relational database concepts,
making it ideal for effective and accurate data administration.
21

2. ERD Using Chen Notation

Figure 1: ERD Using Chen Notation

ERD graphically depicts the database structure, outlining entities, their properties, and
relationships regarding language, job, address, and employee (Han & Wang, 2024). The
Employee entity has a one-to-many relationship with the Address entity since any
employee might have multiple addresses. Since an employee may have various job
records at any moment, the Employee-Job connection is also one-to-many. Employees
fluent in more than one language can be accommodated by maintaining a one-to-many
relationship with the language. In addition, the manager_ID property of the Employee
object represents a hierarchical link between employees and managers in the form of a
recursive one-to-many relationship. These linkages make flexible and accurate data
representation possible, reflecting real-world organisational hierarchies and preserving
referential integrity.

3. Normalisation
Table 5: 1NF
Table Name Column Names
Employee employee_ID (PK), first_name, last_name,
date_of_birth, gender, email, phone_number,
language
Address address_ID (PK), employee_ID (FK), address, city,
country
Job job_ID (PK), employee_ID (FK), job_title,
department, salary

Table 6: 2NF
Table Name Column Names
Employee employee_ID (PK), first_name, last_name,
date_of_birth, gender, email, phone_number
Language language_ID (PK), employee_ID (FK),
language
22

Address address_ID (PK), employee_ID (FK), address, city,


country
Job job_ID (PK), employee_ID (FK), job_title,
department, salary

Table 7: 3NF
Table Name Column Names
Employee employee_ID (PK), first_name, last_name,
date_of_birth, gender, email, phone_number,
manager_ID (FK)
Language language_ID (PK), employee_ID (FK), language

Address address_ID (PK), employee_ID (FK), address, city,


country
Job job_ID (PK), employee_ID (FK), job_title,
department, salary

Normalisation is key for effective data organisation, redundancy elimination, and logical
dependency assurance regarding relational database (Khattabi, et al., 2024). We
removed transitive dependencies, ensured atomicity, and removed partial dependencies
by going through 1NF, 2NF, and 3NF. This procedure improved query performance,
reduced data duplication, and strengthened data integrity. When data is partitioned into
related tables like Employee, Address, Job, and Language, the database becomes more
adaptable and easier to maintain. This enables consistent and scalable data
management.
23

References
Döhmen, T., Geacu, R., Hulsebos, M. & Schelter, S., 2024. SchemaPile: A Large Collection of
Relational Database Schemas. Proceedings of the ACM on Management of Data, Volume
172, pp. 1-25.
Han, Z. & Wang, J., 2024. Knowledge enhanced graph inference network-based entity-
relation extraction and knowledge graph construction for industrial domain. Frontiers of
Engineering Management, Volume 11, pp. 143-158.
Khattabi, M.-Z.E. et al., 2024. Understanding the Interplay Between Metrics, Normalization
Forms, and Data distribution in K-Means Clustering: A Comparative Simulation Study.
Arabian Journal for Science and Engineering, Volume 49, pp. 2987-3007.
GeeksForGeeks (2017). Inheritance in Java - GeeksforGeeks. [online] GeeksforGeeks.
Available at: https://www.geeksforgeeks.org/inheritance-in-java/.
Janssen, T. (2023). OOP Concept for Beginners: What is Encapsulation. [online] Stackify.
Available at: https://stackify.com/oop-concept-for-beginners-what-is-encapsulation/.
Taylor, T. (2023). Understanding the role of polymorphism in OOP | TechTarget. [online]
App Architecture. Available at:
https://www.techtarget.com/searchapparchitecture/tip/Understanding-the-role-of-
polymorphism-in-OOP.
Microsoft (2024). Database normalization description. [online] learn.microsoft.com.
Available at: https://learn.microsoft.com/en-us/office/troubleshoot/access/database-
normalization-description.
Simplilearn.com. (n.d.). what is Normalization in SQL? 1NF, 2NF, 3NF and BCNF |
Simplilearn. [online] Available at: https://www.simplilearn.com/tutorials/sql-
tutorial/what-is-normalization-in-sql.
Studytonight (2019). 1NF, 2NF, 3NF and BCNF in Database Normalization | Studytonight.
[online] Studytonight.com. Available at: https://www.studytonight.com/dbms/database-
normalization.php.

You might also like