5/7/2025 Design, Creating Documentation

& Report
Database Design & Development

Moe Kaung Kin

GUSTO COLLEGE
HND-67 TJ76242 Moe Kaung Kin

TABLE OF CONTENTS

INTRODUCTION .......................................................................................................................................................................2
DEFINITION OF DATABASE .................................................................................................................................................3
USER REQUIREMENT ...............................................................................................................................................................3
SYSTEM REQUIREMENTS .........................................................................................................................................................5
DEFINITION OF DATABASE DESIGN .................................................................................................................................5
Data Integrity and Accuracy ...............................................................................................................................................8
Improved Performance ........................................................................................................................................................8
Enhanced Application Functionality ...................................................................................................................................8
Security ................................................................................................................................................................................9
TYPES OF DATABASES ...............................................................................................................................................................9
IMPORTANCE OF DATABASE DESIGN.......................................................................................................................................10
PROBLEMS IF DATABASE DESIGN IS NOT USED PROPERLY ....................................................................................................11
BENEFITS OF USING DATABASE DESIGN ...................................................................................................................................12
GOOD DATABASE DESIGN AND BAD DATABASE DESIGN .........................................................................................................14
DATABASE LIFE CYCLE (DBLC) .......................................................................................................................................14
REQUIREMENT ANALYSIS .......................................................................................................................................................14
CONCEPTUAL DESIGN .............................................................................................................................................................16
Entity ..................................................................................................................................................................................16
Attributes............................................................................................................................................................................16
Relationship .......................................................................................................................................................................16
Cardinality .........................................................................................................................................................................17
Participation ......................................................................................................................................................................17
Effectiveness of ERD..........................................................................................................................................................22
LOGICAL DESIGN.....................................................................................................................................................................22
Evaluate & align with Requirements .................................................................................................................................30
PHYSICAL DESIGN ...................................................................................................................................................................32
Data Dictionary (Physical Design Stage) .........................................................................................................................33
IMPLEMENTATION ...................................................................................................................................................................37
CONCLUSION ...........................................................................................................................................................................38
REFERENCES ..........................................................................................................................................................................40

1
HND-67 TJ76242 Moe Kaung Kin

Introduction
“Aurora” is a successful garment factory, from beginning to end, from initial design to finished
product, from raw materials such as cotton, polyester, and then yarn to fabric, shape, quality control,
fashion designers draw the design, cut the pattern using cutting machine, sewing to combine with
collars, pockets, logos and brands, printing, etc. It is a factory that produce various categories or
clothing in large scale. Aurora is a large factory, so it has many important equipment such as cutting
machines, sewing machines, pressing machines, quality inspection system.
These equipment play an important role in production process and are used every day, so regular
machine inspections must be carried out. When doing so, if a production machine is defective the
employee must immediately inform machine team. This team also prepares & should immediately
investigate and find out what the problem is.
Otherwise, equipment may be damaged and production volume may be reduced, even if thousand
of pieces of clothing are produced. After repair, a respective inspector must verify whether the
machine is actually working. The faulty equipment must be replaced and then allowed to be used
only after the inspection.
I am a senior database developer at Aurora company, and I have been assigned to design and
implement a database that can meet a following requirement,
I. To effectively monitor a maintenance records of equipment
II. Ensure efficient executing of machine maintenance tasks
III. Reduce machine downtime
IV. Optimizing operational cost

2
HND-67 TJ76242 Moe Kaung Kin

Definition of Database
Before designing database, I will first explain what a database is. Is essentially a place where data
is systematically and properly organized and stored. To put it simply, in real life, it is similar to
keeping files and documents together in one place. But in this case, data is stored inside a computer,
so you can easily search for it using keywords, edit it, and use it whenever you need.
As a senior database developer, relational database I will be creating is a system where data is stored
in tables. These tables are connected to each other in a way that build the information easy to
understand at a glance.
In assignment-1, a goal is to design a database that will store all of records related to maintenance
of machine & equipment for Aurora company. (None, 2020)
According to the requirements of the owner of Aurora Company, I, as a senior database developer,
will fulfill the user and system requirements of the business. First of all, I would like to explain what
user and system requirements are, and what key elements are involved.

User Requirement

Although the owner will not personally use the system, the reason for commissioning such a system
is to ensure proper data control and improve maintenance efficiency for the business.

To explain more precisely whenever a machine breaks down and requires repair, it incurs costs.
Following that, it’s important to track why the breakdown occurred, which part was damaged, who
repaired it and when, whether it can be repaired or not, and if not, whether a new replacement can
be installed and whether the necessary parts are readily available.

This need to track and manage such information is where the user requirements arise from.

User requirements may include not only the needs of the owner but also the requirements of
individuals who are directly responsible for monitoring business-critical data such as income,
expenses, employees, and machine components.

This is because someone in charge of such responsibilities needs to report information to the
company for example, when a machine breaks down and requires repair. Therefore, the data related
to those tasks becomes part of the user requirements. It may also support business forecasting, and
requirements may arise directly from mechanics or inspectors who use the system themselves.

3
HND-67 TJ76242 Moe Kaung Kin

1. They want to store detailed information about the machines.Aurora Company uses various
machines like cutting, sewing, and pressing machines. Since these machines are used daily,
it is crucial to be aware of their usage status and condition.

For example, suppose a mechanic comes in to repair a sewing machine. If they do not know
the Machine Number, Name, or Location, they will waste time locating the machine. However,
if this information is stored in the database, the mechanic can go directly to the machine and
repair it efficiently without delay.

2. To store part (component) information like components of machines often need to be repaired
or replaced in coordination with their suppliers. By storing data such as Part Number, Part
Name, and Part Supplier, defective parts can be quickly identified and reordered.

For example, if the motor of a sewing machine breaks down, and the original part number
and supplier information are stored in the database, the supplier can be contacted easily. This
is important for minimizing downtime.

3. To store maintenance records.It is essential to record which part of which machine was
damaged and repaired.Since some machines may require frequent repairs, keeping a history
of these repairs helps identify patterns and enables preventive maintenance.

For instance, if Cutting Machine A has had its motor repaired three times, once every two
months, the database record can reveal this trend. Without preventive maintenance, it is
likely to break down again soon.By having this data available, the company can plan ahead,
reducing operational costs and downtime.

4. To store mechanic (repair personnel) information. If the company knows which mechanic has
previously repaired a specific machine or part, it becomes easier to assign them again for
quicker service. Simply storing information like Name, ID, and Role is sufficient.

To make it easy to understand suppose Engineer Kyaw Kyaw had previously repaired Machine
B. If the machine needs repairs again, the system can quickly identify and assign him
directly.Without knowing the machine’s pattern or repair history, another mechanic may take
longer. But someone familiar with the machine can carry out the repair more efficiently and
with minimal downtime.

4
HND-67 TJ76242 Moe Kaung Kin

5. To store inspection records and inspector information.After a machine is repaired, an inspector

needs to verify whether the machine is functioning correctly. This inspection record serves as
evidence of whether the repair was successful.

For example, suppose Inspector Ko Kyaw inspected Machine C and marked it as OK. A month
later, the machine breaks down again. By checking the inspection report, the company can
find out who inspected it, what comments were made, and details such as the inspection date
and result.This allows for appropriate follow-up actions and helps build a reliable maintenance
and quality assurance (QA) process.

System Requirements

To meet the user requirements within the system, certain components must be included. Specifically,
tools like the Entity Relationship Diagram (ERD), Normalization, and a Data Dictionary serve as
foundational design elements for any database system. These are essential to be developed
specifically for the company.

Among these, the system must be capable of storing all data related to Machines, Parts, Records of
Repairs, Inspections, and Inspectors. These are key specifications that define what the system must
support, along with the required technologies for proper functioning.

For Aurora Company, it is necessary to implement Logical and Physical Database Design in other
words, detailed design of a relational database system using tools such as ERD, Normalization, and
Data Dictionary.Each of these design tools has its own advantages and will be explained in more
detail later, including their impact, usefulness, and additional relevant elements.

In short, System Requirements refer to the functions that the system must be able to perform. These
are defined as Functional Requirements and are directly aligned with what the user requirements
demand from the system.

Next, I will explain in more detail the database design mentioned above.

Definition of Database Design

5
HND-67 TJ76242 Moe Kaung Kin

Database design is a structured arrangement of information (files and records) that allows the
storage, modification, and retrieval of data using a software system called a DBMS (Database
Management System).

In earlier times, before the advancement of technology, data was stored in file formats. However,
due to several limitations of file systems, such as
→ Excessive storage usage
→ Difficulty in manipulation
→ Lack of transaction support
…they were gradually replaced by DBMS solutions. (Anonmyous, n.d.) (Anonmyous, 2025)

In essence, database design refers to the process of structuring and organizing data in a systematic
way for storage and management. It ensures data is properly structured and well-managed.

Sometimes, database design is also referred to as a database schema, which represents the structure
of a database. This includes the relationships between entities, as well as any constraints, and shows
how everything is connected inside the database.

The details of these components will be explained in the following sections.

Software developers and database designers use database diagrams (such as ERDs) to decide how
to store, manage, and use data within a database. (Gupta, 2024)

When the Database Schema can be visualized through diagrams like ERDs, developers can use that
structure as a foundation to expand and improve the database design. This kind of improvement
helps enhance performance and ensures that user requirements are effectively fulfilled.

The term “schema” refers to the precise structure of a database including columns, tables,
relationships, constraints, primary keys, and foreign keys. Even when normalization is applied in
tools like Excel using columns and structured data, it can be considered part of schema design.

The focus of a database is to determine

→ How to store data
→ How to connect different data elements
→ And how to align with the specific requirements of the business or users
When a database is well-designed, it enables
→ Efficient data storage

6
HND-67 TJ76242 Moe Kaung Kin

→ Fast retrieval when needed

→ And the ability to meet both user and business needs effectively (Gupta, 2024)

Key Concepts to Understand

1. Relationships

Defining how different entities are related to each other.

Example:A customer can place multiple orders, and each order can include multiple products.

2. Ensuring Data Integrity

To ensure data accuracy and avoid errors, rules and constraints must be defined.
Examples include:
→ Primary Key to uniquely identify each record
→ Foreign Key to establish relationships between tables
→ Not Null to prevent missing important data (guide, 2011)

Also, data types should be respected for example, preventing text from being entered into numeric
or name-only fields.

3. Optimizing for Performance

A well-designed database must be optimized to allow users to store and retrieve data quickly and
efficiently.

When creating a database diagram, there can be various types of structural representations. The
most commonly used format is a flowchart-style layout. In this layout, entities are represented in a
table-like structure, and they are connected with arrows that show how the entities are related to
each other. (guide, 2011)

These arrows indicate direction in which data flows, and nature of the relationships between
entities.There are different techniques for designing a database, and the type of diagram used often
depends on the purpose it serves.

A well-designed database it include ERD, Normalization, Data dictionary -

→ Helps ensure data integrity (accuracy and consistency),

7
HND-67 TJ76242 Moe Kaung Kin

→ Reduces redundancy (duplicate data),

→ Enables fast data retrieval, and
→ Even improves how applications perform.

Data Integrity and Accuracy

A good database design helps reduce data redundancy (duplicate or repeated data), which prevents
errors and inconsistencies in the system.

It also enforces data validation through the use of constraints, such as:
1. NOT NULL - to prevent missing values,
2. UNIQUE - to ensure no duplicate entries,
3. CHECK - to ensure data meets specific rules.

This ensures the system always maintains consistency meaning the data remains uniform across all
areas of the system.

Example, In a retail store, the quantity of an item shown in the warehouse system should match the
quantity shown at the point-of-sale system.If these numbers don’t match, it may cause stock-out
issues.With a proper database design, such issues can be prevented. (Tejeda, n.d.)

Improved Performance

Good database design also improves system performance in the following ways such as reduced
Storage Requirements by through normalization, redundant data is removed, which decreases
database size.Better Scalability cause a well-structured database can handle an increasing number
of users or data without a drop in performance.

Example:Instead of storing the author’s information repeatedly in every row of a Books table, create
a separate Authors table and link it using a foreign key.This reduces repetition and improves
efficiency.As a another example, If you only need to store short text strings, using VARCHAR(255)
instead of TEXT improves performance and reduces memory usage. (Developer, n.d.) (Tejeda, n.d.)

Enhanced Application Functionality

8
HND-67 TJ76242 Moe Kaung Kin

Because the structure and relationships are clearly defined, it becomes easier to perform data mining,
reporting, and forecasting.A well-designed database can be managed in a way that allows it to adapt
to both current and future business needs.

Good database design helps an application perform better, with faster response times, better
reliability, and more advanced features. A real-world example of this is Netflix.

Netflix has a huge database that manages millions of users, their viewing habits, preferences, and
recommendations. Netflix can provide real-time recommendations, keep track of where users left off
in a show, and offer personalized content that keeps users engaged. Without good database design,
Netflix would struggle to offer these seamless, personalized features. (Tejeda, n.d.)

Security

Database design can incorporate features like encryption, access control, and role-based
permissions.Compared to working with regular paper documents which are vulnerable to theft a
properly designed database with built-in access controls ensures data security and minimizes such
risks.

Databases allow users to

→ Store data
→ Retrieve data
→ Update or manage data
…in a fast and reliable manner. (Tejeda, n.d.)

That’s why it’s crucial for businesses to choose the right type of database, depending on their specific
needs.

Types of Databases

1. Hierarchical Databases
Data is organized in a tree-like structure, with parent-child relationships between records.

2. Network Databases
Evolved from hierarchical databases, these follow a graph model that allows many-to-many
relationships.

9
HND-67 TJ76242 Moe Kaung Kin

3. Object-Oriented Databases
Based on Object-Oriented Programming (OOP) principles, data is stored as objects, which
include
→ Attributes (e.g., name, address)
→ Methods (e.g., getAddress())
Example:
A Person object might contain Name, Age, Address (attributes) and getLatestAddress()
(method)

4. Relational Databases
The most widely used type of database in the world today.Data is stored in tables, where
→ Rows is Records
→ Columns is Attributes
→ Each row is identified by a Primary Key and
→ Relationships between tables are established using Foreign Keys

Example, A Customer table is related to an Order table like CustomerID is the Primary
Key in the Customer table. CustomerID appears as a Foreign Key in the Order.
(Anonymous, 2025)

Importance of Database Design

In today’s world, businesses rely heavily on data to drive success and make informed decisions.To
manage that data accurately, securely, and efficiently, a well-structured database design is
absolutely essential.

1. Improved Data Management and Operational Efficiency

A good database design provides a systematic way to manage data effectively.Ensures Data
Accuracy and Integrity by incorporating validation rules and constraints, it helps minimize
data errors.Decisions made based on reliable and consistent data are more accurate and
trustworthy.Enhances Performance and Scalability with techniques like normalization, data
retrieval becomes faster and more efficient.This boosts application performance, and even as
data volumes grow, the system remains stable and manageable. (Developer, n.d.)

2. Strengthening Data Security and Privacy

10
HND-67 TJ76242 Moe Kaung Kin

In today’s data-driven era, protecting sensitive information is more critical than ever.
Database design plays a vital role by integrating security measures during the design phase
itself.By including features such as
→ Access Control
→ Authentication
→ Encryption

System can Prevent unauthorized access and reduce the risk of data breaches.Example,
encrypting credit card numbers in a payment processing database ensures that even if a
hacker gains access, they cannot read the actual card numbers. (Developer, n.d.)

3. Support for Data Analysis and Decision-Making

A well-structured database design not only supports day-to-day operations but also enhances
Business Intelligence (BI) and Data Analytics.By clearly designing the schema and data
models, it becomes easier to generate insightful visualizations and analytics through BI tools
such as Power BI or Tableau.

This enables faster decision-making.Thanks to well-structured data warehousing, integration,

and data consistency, decision-makers can access accurate, real-time data to make informed
choices. (Anonmyous, n.d.)

In addition, a concept of a “Single Source of Truth” means that all relevant data is sourced
from a centralized, trusted database, ensuring consistency and reliability.

Problems If Database Design Is Not Used Properly

1. Data Inconsistency and Inaccuracy

Redundancy (Unnecessary duplication) which mean same piece of data is stored across
multiple tables.Example: If an address is stored in three tables, but only one is updated, the
remaining two become outdated, leading to data inconsistency.

Update Anomalies, due to redundancy, errors may occur during updates, as the same data
must be updated in multiple locations.Lack of Integrity cause poor design may result in storing
data in a way that does not accurately represent real-world information, reducing trust and
reliability. (Anon., 2024)

2. Performance Issues

11
HND-67 TJ76242 Moe Kaung Kin

When related data is not properly separated, it causes redundancy, which may lead to system
overload and hinder system performance.Incorrect data types (e.g., storing a number as text)
can slow down the system and cause logical errors.As traffic and data volume increase, these
issues can result in system failure or crashes.

3. Scalability Issues

Difficulty Adding Features, if the database structure is poorly defined and lacks proper
normalization, it becomes difficult and time-consuming to add new features or make
updates.It also limited growth, as the number of users and transactions increases, the system
may lack the scalability to handle the load efficiently. Sometimes, even small changes require
a complete redesign of the database.This is not ideal for Aurora Company, especially if the
goal is to minimize operational costs. (Kemnitz, 2021)

4. Maintainability Issues
It occur inconsistent table and column names, unclear relationships, and poor structure make
the database hard to read or manage.A small change to one part of the schema can result in
critical errors across the entire database.Time-Consuming Maintenance as a result of
developers may need to spend a lot of time on updates or bug fixes due to poor structure.

5. Security Risks
Poor design may lead to unstable backups or data corruption, resulting in permanent loss of
information. Without proper data integrity enforcement and access control, the system
becomes vulnerable.Even a basic SQL injection attack could compromise the entire database.
(Kemnitz, 2021)

Benefits of using database design

1. Data Integrity and Consistency

With the use of constraints such as NOT NULL, UNIQUE, and CHECK,
→ Ensures that data is accurate, complete, and reliable
→ Reduces data redundancy and increases trustworthiness of the information

By defining relationships and dependencies, related data can be updated consistently across
the entire system. (Castro, 2020)

2. Improved Performance

12
HND-67 TJ76242 Moe Kaung Kin

Due to reduced redundancy and optimized storage, data can be accessed more quickly,
improving query performance.The system can handle growing volumes of data without a
decline in performance is called scalability.Data is logically organized and separated, making
it easy to retrieve what’s needed.

3. Enhanced Data Management

Centralized Data Storage, when all organizational data is stored in one central location it
becomes easier to search, manage, and maintain.Reduced Redundancy with minimizing
duplicate data helps save storage space.In a well-structured database, modifying or updating
data is Easier, and there is less chance of errors. (Castro, 2020)

4. Enhanced Security
Security features such as Access Control, Role-Based Access, and Encryption can be
integrated during the design phase, preventing unauthorized access.

5. Better Decision-Making
With accurate and consistent data, organizational decision-making improves. And also Data
Analysis Tools like Reporting and Business Intelligence (BI) can extract valuable insights it
supporting long-term strategic planning.

6. Streamlined Operations
Improved Efficiency because data retrieval and updates are systematic and fast, Operational
processes across the business are optimized. Reduced Manual Effort, it less reliance on
manual data entry and file tracking its lead frees up skilled employees to focus on strategic
tasks. (Castro, 2020)

13
HND-67 TJ76242 Moe Kaung Kin

Good database design and bad database design

(JetBrain, 2024) (Castro, 2020) (Star, 2025)

Database Life Cycle (DBLC)

Database Life Cycle (DBLC) refers to the stages that must be carried out to build a database. Below,
for each stage of the DBLC, I will explain in detail:
1. What this stage is and what it includes
2. What the output of this stage will be
3. What problems might occur if this stage is skipped
4. How this stage relates to user and system requirements (Anon., 2024)

Requirement Analysis
In order to build a database, it’s essential to understand what the users and the system need. The
process of collecting such needs is called requirements analysis.

To put it simply, it involves identifying the business needs of company owners and understanding
the functional requirements that is, what the system should be able to do.

14
HND-67 TJ76242 Moe Kaung Kin

For example, in the case of Aurora Company, this includes things like maintaining records of
machines and parts, identifying who performed the repairs, etc. All of these were already mentioned
under the introduction and in the sections on user and system requirements.

More specifically, it covers detailed information about machines such as Machine No and Machine
Name, as well as data related to parts such as the Part Supplier. It also includes data regarding
inspections and inspectors.

All of this falls under the detailed scope of user, system, and functional requirements, which were
already explained clearly in the introduction. So here, I’ve focused on summarizing the key points.

Let’s say one of the end users is an inspector. Their role is to regularly inspect machines. Their
requirement is to be able to easily record daily machine inspections, and when a problem arises,
they need to know who repaired that specific machine. (Anon., 2024)

This is important because only when the inspector can see that information can they write accurate
comments about the machine. Then the engineer can review those comments and proceed to fix the
identified weaknesses.

In addition, the owner’s requirements are also relevant in requirement analysis. Let’s assume the
owner is responsible for overseeing the overall business process of Aurora Company. Their
requirement is to be able to view monthly reports showing the maintenance cost for each machine.
The goal is to increase productivity and reduce unnecessary costs (cost saving).

If requirement analysis is not properly conducted, the system might fail to meet actual user needs.
It can result in a lack of clear understanding of what the user or owner truly wants.
To avoid that, it’s essential to ask detailed questions during this phase. Without doing so, the system
might end up including unnecessary functions, making it overly complex. That could also lead to
budget issues, potentially preventing successful implementation of the system.

Finally, when considering what the owner wants the system to do, it includes things like building the
ERD, applying normalization, and ensuring the system meets system requirements like data integrity,
defining proper relationships, and enforcing constraints. (Anon., 2024) (Anon., 2024)

As a Aurora’s Example Requirements

→ The system must include at least 5 tables.
→ It must include ERD, Normalization, and a Data Dictionary.

15
HND-67 TJ76242 Moe Kaung Kin

→ Referential integrity must be established.

→ It must be normalized up to 3NF.

All of these are part of Aurora Company’s requirements analysis.

Conceptual Design

Based on the gathered requirements, the Entity Relationship Diagram (ERD) is constructed. This
stage involves identifying Entities, Attributes, and Relationships.

What needs to be done:

• Select Entities (e.g., Machine, Repair, Part)
• Define Attributes (e.g., MachineNo, RepairDate)
• Draw Relationships (e.g., One-to-Many, One-to-One)
• Specify Cardinality and Participation

Let me now explain what each of these means:

Entity

An Entity is something that represents a real-world object or concept about which data is stored in
the ERD.

For example – Machine, Part, Repair, Engineer, Inspector – these are all entities.

Entities represent distinct objects in the database and are designed to store records. Each entity
typically becomes a table in the database. (Gupta, 2024)

Attributes

Attributes are the pieces of information that need to be described for each entity.
For example, the Engineer entity may have attributes such as EngineerID, Name, Phone, and
Specialization.
In the database, attributes appear as columns in a table, and one of those attributes can serve as
the Primary Key.

Relationship

A Relationship refers to the connection or association between two or more entities.

16
HND-67 TJ76242 Moe Kaung Kin

For instance, an Engineer “performs” a Repair this is a relationship.

In an ERD, relationships are typically represented using a diamond shape, and they can show the
type of interaction between entities.
Relationships play an important role in database foreign key design. (Ramadhan, 2020)

Cardinality

Cardinality describes the numeric association between entities in a relationship.

Examples include One-to-One, One-to-Many, and Many-to-Many relationships.

For instance, if one Engineer can perform many Repairs, then the relationship is One-to-Many.

Cardinality is essential when building an ERD because it shows how many instances of one entity can
or must be associated with another. (Anon., 2024) (Anon., 2025)

Participation

Participation constraints in a Database Management System (DBMS) define the minimum and
maximum number of times an entity must participate in a relationship.
→ Partial Participation means that an entity may or may not participate in a relationship.
→ Total Participation means that every instance of an entity must be involved in a specific
relationship.

An ERD (Entity Relationship Diagram) serves as a roadmap for database developers like us when
designing a database. By clearly understanding elements such as entities, relationships, attributes,
and cardinalities, we can construct an efficient and well-structured database. When defining Foreign
Keys and Primary Keys, the structure must follow the logic shown in the ERD. For example, a
developer can look at the ERD to understand how tables like Machine, Repair, and Engineer are
connected and then proceed with the implementation accordingly. (Ramadhan, 2020)

In the case of the database we designed for Aurora Company, we included entities such as Machine,
Part, Repair, Engineer, Inspection, and Inspector. These entities are connected through relationships
represented by diamond shapes. For example, the relationship between Machine and Part is modeled
as “has”, meaning a machine can have multiple parts. In terms of cardinality, this is a 1-to-many
relationship: one machine (e.g., Machine 001) can consist of multiple parts like P001, P002, etc. This
means a single machine can own many parts. However, if we consider the possibility that the same

17
HND-67 TJ76242 Moe Kaung Kin

part could be reused in multiple machines, the relationship could become many-to-many. But since
machines are considered distinct and separate in this context, we chose to model it as a 1-to-many
relationship.

Regarding participation, we used total participation between Machine and Part, indicating that every
machine must have parts, and parts must be associated with a machine to function. A machine
cannot operate without parts, and standalone parts are also meaningless without a machine, which
justifies the use of total participation here. The Machine entity includes attributes like
MachineLocation, MachineName, and MachineNo, where MachineNo is unique and serves as the
Primary Key.

18
HND-67 TJ76242 Moe Kaung Kin

The same approach applies to other entities. For instance, there’s a relationship between Part and
Repair. Here, the cardinality is again 1-to-many, meaning one part can be repaired multiple times.
This is based on the assumption that a part may break down more than once and need multiple
repairs. However, not every part will necessarily break, so we use partial participation on the Part
side. On the other hand, every Repair must be associated with a specific Part, so we use total
participation on the Repair side. (Anon., 2025)

As for the attributes

→ In the Part table, we include PartSupplier, PartName, and designate PartNo as the Primary
Key.
→ In the Repair table, we include EngineerID, MachineNo, and PartNo as Foreign Keys, while
RepairID is the Primary Key. We also add attributes like RepairStatus and RepairDate.

Foreign Keys are used to reference Primary Keys from other tables and create direct links between
tables.

Since repairs are carried out by engineers, a relationship has been established between the Repair
and Engineer entities. It is assumed that one engineer can handle multiple repairs, and each repair
is performed by one engineer. This implies a many-to-one cardinality from Repair to Engineer. While
it’s theoretically possible that multiple engineers could work on a single repair, there is no significant
error or conflict in assuming that each repair is handled by one engineer. This assumption is based
on the paper-based documents from Aurora, which indicate that each repair record is associated with
a single engineer. Therefore, we chose many-to-one cardinality.

On the Repair side, we used total participation because repairs must always be carried out by
engineers, repairs cannot exist without them. On the other hand, we used partial participation on

19
HND-67 TJ76242 Moe Kaung Kin

the Engineer side. This is because an engineer is not necessarily required to perform a repair all the
time it’s optional depending on circumstances.

The Engineer entity includes:

Primary Key: EngineerID
Other attributes: EngineerName, Role

After the repair process is completed, the system must verify whether the repair was successful or
not. Therefore, a relationship has been established between Repair and Inspection. The cardinality
is defined as 1-to-many, meaning one repair may be inspected multiple times. This assumption
reflects the possibility that a repair might undergo multiple checks before final approval.

Both Repair and Inspection entities participate in a total participation relationship

→ A Repair must be inspected.
→ An Inspection cannot exist without a corresponding Repair.

The Inspection entity includes

1. Attributes: InspectorComments, InspectionDateTime
2. Foreign Keys: RepairID, InspectorID
3. Primary Key: InspectionID

Since inspections are carried out by inspectors, a relationship has been established between the
Inspection and Inspector entities. It is assumed that each inspection is conducted by one inspector,
while one inspector can perform multiple inspections. This results in a many-to-one cardinality from
Inspection to Inspector. Moreover, for an inspection to occur, an inspector is absolutely required
(total participation from Inspection side), whereas an inspector is not necessarily required to conduct
inspections at all times it is optional for the Inspector entity (partial participation). This assumption
aligns with real-world practices.

20
HND-67 TJ76242 Moe Kaung Kin

Without an ERD, it becomes unclear

21
HND-67 TJ76242 Moe Kaung Kin

→ What the entities are,

→ How they are related,
→ And how they should be connected.

Also, normalization becomes difficult or impossible to carry out without understanding these
relationships. Without an ERD, developers would struggle to fulfill user and system
requirements efficiently.

Effectiveness of ERD

ERDs (Entity Relationship Diagrams) visually represent the relationships between entities (tables)
within a database.They help developers and stakeholders easily understand the structure of the
database and serve as a communication tool between technical and non-technical teams.

In the context of Aurora Company, the ERD we’ve created matches the structure outlined in their
existing tables and organizes the data clearly, step by step, in a way that is easy to understand and
implement.

When visualizing the database structure, issues such as missing relationships, data redundancy, and
absent keys can be identified early in the process. By using an ERD to understand the structure in
advance, the database can be developed more quickly, with fewer errors and reduced development
time.

As a result of this approach, the ERD we created for the company aligns with its user and system
requirements such as storing machine-related data including MachineNo, Location, and Name, along
with associated part details. The ERD makes the subsequent normalization process more
straightforward and visually clear, since each entity already has its attributes clearly defined. (Star,
2025)

Logical Design

Normalization is applied in this phase to remove data redundancy and ensure data consistency. It
does this by breaking down large, unstructured tables into smaller, related ones. This enhances data
integrity and improves overall performance.

22
HND-67 TJ76242 Moe Kaung Kin

This stage involves transforming the Conceptual Design (ERD) into a relational database structure.
Key tasks include
→ Converting ER Diagram into relational tables
→ Defining Primary Keys for each table
→ Adding Foreign Keys to establish relationships
→ Performing Normalization steps from 1NF → 2NF → 3NF

Since both the Owner and Database Developer of Aurora Company rely heavily on accurate and
efficient data management, applying Normalization is essential.

If normalization is not performed, data such as MachineName, PartName, and EngineerInfo would
have to be repeatedly entered across multiple rows. This leads to increased data size, higher storage
costs, and a higher chance of inconsistencies.

For example, suppose the Machine table contains two rows with the machine name “Cutter,” and
later the name is updated to “Auto Cutter.”
If the database is not normalized, each row would have to be manually updated, increasing the
chance of human error.
However, with normalization in place using IDs and foreign key references only one value in one
location needs to be updated, and that change will be reflected wherever it’s linked.
Without normalization, the system may contain both “Cutter” and “Auto Cutter,” creating confusion
and inconsistency.

Therefore, Normalization is essential to

→ Ensure Data Consistency
→ Reduce Redundancy
→ Maintain Data Integrity
→ Improve overall Database Performance

Normalization in database design is crucial for eliminating data redundancy and ensuring data
integrity. It involves organizing data into tables and defining relationships between them to reduce
inconsistencies and improve data management. This process makes it easier to update, and maintain
the database, leading to more efficient and reliable data storage.

Here's a more detailed breakdown of the reasons

1. Reducing Data Redundancy

23
HND-67 TJ76242 Moe Kaung Kin

Normalization minimizes the duplication of data across multiple tables.For example, instead
of storing a customer's address multiple times in different tables, it's stored only once in a
customer table.This saves storage space and prevents inconsistencies when updating
information.

2. Improving Data Integrity

As a System Requirement: “Design a relational system with at least 5 interrelated tables”
After 3NF, at least 5 tables but I build

→ Machine(MachineNo, MachineName, MachineLocation)

→ Part(PartNo, PartName, PartSupplier)
→ Repair(RepairID, MachineNo, PartNo, RepairDate, EngineerID)
→ Engineer(EngineerID, Name, Role)
→ Inspection(InspectionID, RepairID, InspectorID, Comments)
→ Inspector(inspectorID, inspectorName)
→ Supplier Table( supplierID, supplier name)

Let me explain how we convert from 0NF (Unnormalized Form) to 1NF (First Normal Form).

24
HND-67 TJ76242 Moe Kaung Kin

In 0NF, the cells contain multiple values, and there are repeating groups.To convert it to 1NF, it’s
important to know that each column must contain atomic values.An atomic value means a single,
indivisible value not a composite or grouped value.Each row must represent a single record, and
there must be no repeating groups or multi-valued attributes.

As shown in the given example, the 0NF table contains repeating groups and lacks atomicity.This is
clearly seen in attributes such as Part No, Part Name, Repair Date, and Repair Engineer.Because of
these issues, Aurora Company’s requirements such as tracking repairs, cannot be met efficiently,
and the system becomes time-consuming to use.

That’s why we converted the table into two separate tables in 1NF.

Also, in the 0NF table, the values for Machine Name and Machine Location are repeated many times.
For example:

"SM-001, Single Needle Lock Stitch, Line 1"

This value appears in every repair record, even though it refers to the same machine.

25
HND-67 TJ76242 Moe Kaung Kin

Since the rows contain the same Machine No, Name, and Location, it makes sense to extract this
data into a separate Machine table.This is an easy decision because the machine-related values are
identical across rows.

For the other columns, we couldn’t yet split them into separate tables at this stage because the multi-
valued fields and duplicates still need to be resolved first.

According to normalization rules, we must split any repeating or grouped values into individual
rows.For example, in the Part No column, a single cell may contain:

P-001, P-002, P-003

In 1NF, we separated this into three distinct rows each containing only one part number while
repeating the associated values accordingly, as shown in the converted table.

The purpose of 2NF is to eliminate repeated information and prevent issues where an update in one
place is forgotten in other rows due to data duplication.It also helps to relate the current table more
effectively with other tables. These reasons make 2NF necessary in the normalization process.

To convert a table into 2NF, we follow the steps below

1. Identify Candidate Keys

Find sets of attributes that can uniquely identify each row in the table.These are called
Candidate Keys.For example, if RepairID alone can uniquely identify each record, then
RepairID is a candidate key.

2. Identify Functional Dependencies

Look for any functional dependency in the table, which means identifying where the value of
one attribute determines the value of another attribute.Example: PartNo → PartName
This means the PartName can be determined based on the PartNo

3. Check for Partial Dependencies

26
HND-67 TJ76242 Moe Kaung Kin

For each non-key attribute, verify whether it depends on entire primary key, or only a part of
the primary key. If it depends on only part of a composite key, it is considered a Partial
Dependency, which violates 2NF.

4. Decompose the Table

If partial dependencies are found, create new tables.Move the attributes that are partially
dependent into the new table along with the key they depend on.

That key will become the Primary Key of the new table.This step helps reduce redundancy
and improves data integrity.

In the case of the 2NF design for Aurora Company, the Repair table uses RepairID as a
Candidate Key because it uniquely identifies each record.

For functional dependencies

→ MachineNo determines both MachineName and MachineLocation.
→ PartNo determines both PartName and PartSupplier.

This indicates the presence of partial dependencies, because these attributes are not fully
dependent on the entire primary key (in this case, RepairID, if considering it in relation to other
composite keys).

Additionally, as shown in the diagram, RepairID determines other attributes as well, such as
those related to machine, part, and engineer.

27
HND-67 TJ76242 Moe Kaung Kin

Since 2NF requires the elimination of all partial dependencies, we decomposed the table by
extracting the Part table and Machine table separately.If MachineNo and PartNo remain in the
Repair table along with their dependent attributes (e.g., MachineName, PartName), partial
dependencies would continue to exist, so decomposition was necessary.

As for the remaining attributes, they are fully functionally dependent on RepairID, which means
they do not violate 2NF.For example, given a RepairID = 3, we can determine:
→ Who repaired it
→ On which date it was repaired
→ Who inspected it, etc.

This confirms that the table is now in Second Normal Form (2NF) with no partial dependencies.

To convert from 2NF to 3NF, it’s important to understand the concept of transitive dependency.This
occurs when an attribute is not directly dependent on the primary key, but instead depends on
another non-key attribute, making the dependency indirect.

If you look at the images provided below, this concept becomes easier to understand.

28
HND-67 TJ76242 Moe Kaung Kin

29
HND-67 TJ76242 Moe Kaung Kin

To resolve these transitive dependencies, we need to separate those attributes into their own tables.
Then, connect them back to the original table using foreign keys.This ensures that the data is stored
in only one place, which helps to

→ Reduce data redundancy

→ Minimize inconsistencies
→ Prevent update anomalies and errors

We can explain how to separate them with image.Put simply, we extract any attribute that does not
directly depend on the primary key, and store it in a new table.As a result, similar sets of attributes
are grouped into individual tables, and proper relationships are established.

In the 2NF stage, attributes like Role were not directly dependent on RepairID.This is why we
separated such elements into individual tables like

→ Supplier
→ Inspector
→ Engineer
→ Inspection

Each of these new tables is linked back to the relevant table via foreign keys, and their unique
identifiers are used as primary keys.

In the final 3NF design for Aurora, we have ensured that:

→ All data validation rules are supported
→ All necessary keys (Primary and Foreign) are correctly defined
→ The design eliminates transitive dependencies and supports a clean, consistent, and
normalized structure

Evaluate & align with Requirements

Firstly, in the Machine table, MachineNo, MachineName, and MachineLocation are stored separately
to ensure that machine-related information is captured comprehensively.For part-related data, both
the Part table and Supplier table have been created independently, with SupplierName linked via a
foreign key to prevent redundancy.

30
HND-67 TJ76242 Moe Kaung Kin

In the Repair table, fields such as MachineNo, PartNo, RepairDate, RepairStatus, and EngineerID are
included, which makes it possible to trace which machine had which part repaired.To manage
mechanics, the Engineer table is used to store EngineerID, EngineerName, and Role separately.

For the inspection process, the design separates Inspection table and Inspector table, allowing
inspector-specific data such as Comment and InspectionDateTime to be recorded based on the
corresponding RepairID.

All of this has been structured according to Third Normal Form (3NF), ensuring a system that is
→ Free from redundancy
→ Maintains data consistency
→ Offers scalability for future growth

Since similar data has been placed in separate tables, redundancy is reduced.The use of Primary
Keys (PK) and Foreign Keys (FK) ensures data integrity.Because 1NF and 2NF were properly
implemented, it becomes much easier to add new engineers or inspectors in the 3NF structure.

All these aspects together ensure that the system fully meets the system requirements set by the
organization.

As a Requirements “Keep detailed information of all machines like Machine Number, Machine Name,
Machine Location”

As part of the logical design, the Machine table was separated as an individual table to store
MachineNo, MachineName, and MachineLocation.This eliminates the need to repeatedly store the
same machine name and location in every repair record.Instead, by linking the Repair table to the
Machine table through a foreign key (MachineNo), data redundancy is reduced, and each repair can
be directly associated with the relevant machine.

As a requirement

“Keep track of maintenance records of any faulty single part of a machine,”

the Repair table includes:

1. RepairID (Primary Key)

2. MachineNo (Foreign Key)
3. PartNo (Foreign Key)

31
HND-67 TJ76242 Moe Kaung Kin

4. RepairDate
5. RepairStatus

Using MachineNo and PartNo, the system can easily identify which part on which machine is being
repaired.As a result, when a single part becomes faulty, a detailed maintenance record can be
accurately captured.Since RepairID is unique, each repair record can be uniquely identified and
separated from others.

In addition, the Inspection process is also well-structured.For each inspection record, the system can
clearly identify:
→ Who performed the inspection
→ When it was performed
→ What comments were made

This ensures that all inspection-related information is traceable and linked to the appropriate repair
action. (Javed, 2018)

Physical Design

Logical design is the stage where decisions are made about how the structure will actually be
implemented inside a Database Management System (DBMS).At this stage, a Data Dictionary is also
developed.

A Data Dictionary is a detailed reference document that describes all data elements within a database
or system.It acts as a centralized source of truth that defines the structure, meaning, and constraints
of the data.

Typical contents of a Data Dictionary include

→ Field Names (Data Elements)
→ Data Types (e.g., Integer, Varchar, Date)
→ Key Constraints (such as Primary Key and Foreign Key)
→ Descriptions explaining the purpose of each field
→ Example Values for clarity (Anon., 2025)

Problems That May Occur Without a Data Dictionary:

32
HND-67 TJ76242 Moe Kaung Kin

→ Performance down
→ Storage overuse
→ Misunderstanding

Data Dictionary (Physical Design Stage)

Data dictionary provides detailed metadata (data type, constraint, example, description) for each
field. This ensures consistency in how data is entered, validated, and interpreted.

Benefit Explanation

Centralized Stores all details about each field, including constraints and data types, in one
Information place, making it easier for developers and new team members to understand
the structure.

Improved Defines how each data element should be used, ensuring uniformity across the
Consistency entire database system.

Enhanced Provides clarity on the role, description, and example values of each field,
Understanding improving comprehension for all stakeholders.

Now I will summarize and explain the data dictionary created for Aurora company.

A separate data dictionary has been made for each 3NF table. For each table, the field names
represent the attributes, and the data types are chosen based on the nature of the data to be stored.

For example, the attribute location uses varchar(20). Why? Because a location can contain both
letters (e.g., place names) and numbers (e.g., room numbers), so varchar is suitable. The (20)
means it allows up to 20 characters to be entered, which is considered enough for this case.

The nullable property asks whether a field is allowed to be left blank. (Anon., 2025)

The unique property ensures that a value appears only once in a table it’s used only for fields that
must be distinctly identifiable like IDs (e.g., RepairID, EngineerID). (Javed, 2018)

Constraints are important. For example, if a field like location must always be filled in and cannot be
left blank, then a constraint like NOT NULL should be applied. These kinds of constraints will be
explained in more detail as well.

33
HND-67 TJ76242 Moe Kaung Kin

Constraint

→ NOT NULL - Ensures that a column cannot have a NULL value

→ UNIQUE - Ensures that all values in a column are different
→ PRIMARY KEY - A combination of a NOT NULL and UNIQUE. Uniquely identifies each row in a
table
→ FOREIGN KEY - Prevents actions that would destroy links between tables
→ CHECK - Ensures that the values in a column satisfies a specific condition
→ DEFAULT - Sets a default value for a column if no value is specified

34
HND-67 TJ76242 Moe Kaung Kin

35
HND-67 TJ76242 Moe Kaung Kin

In the “Description” column, the purpose of each field and the reason for applying certain constraints
are written. For example, as shown in the diagram, in the case of machine_loc, the reason why it
needs to be checked is also included.

Although each individual table is not explained in full detail, all of them follow the same principles
mentioned above.

Each table contains field name, data type, constraint, and description, so it serves as a reference
document that creates a common understanding among developers, analysts, and users clearly
showing what each field is used to store.

By using constraints and validations, data integrity and accuracy can be more effectively ensured.

36
HND-67 TJ76242 Moe Kaung Kin

Implementation

Using the output of the physical design, the actual database is created and integrated with the
application. This is where the design is brought to life.

What needs to be done?

→ Create tables, views, triggers, and stored procedures
→ Set up user access control and permissions
→ Perform unit and integration testing
→ Establish a backup and recovery plan

As a output a fully functional database system will be achieved.if you skipped, system cannot be built
successfully and high risk of data corruption

Implementation is the final phase of the Database Design Life Cycle (DBLC).It is the stage where
both the Logical Design and Physical Design are put into action, resulting in the construction of a
complete database system.

Implementation Tasks and Description

Task Description

Database Creation Create a new database, e.g., AuroraDB using MySQL, Access, etc.

Table Creation Use SQL to create 5+ tables based on the logical design

Apply Constraints Define constraints such as PK, FK, NOT NULL, CHECK, DEFAULT, UNIQUE, etc.

Insert Test Data Add sample records for tables like Machine, Part, Repair, etc.

Query Testing Test SQL queries like SELECT, JOIN, WHERE, etc.

Data Validation Use forms or constraints to ensure only valid data can be entered

CREATE TABLE Machine (

MachineNo VARCHAR(10) PRIMARY KEY,
MachineName VARCHAR(50),
MachineLocation VARCHAR(100) NOT NULL
);

CREATE TABLE Part (

37
HND-67 TJ76242 Moe Kaung Kin

PartNo VARCHAR(10) PRIMARY KEY,

PartName VARCHAR(50),
PartSupplier VARCHAR(50),
MachineNo VARCHAR(10),
FOREIGN KEY (MachineNo) REFERENCES Machine(MachineNo)
);

Similarly, create the Repair, Engineer, Inspector, and Inspection tables.

The implementation phase involves transforming the logical and physical design into a working
database system. The Aurora database was created in MySQL and contains seven interrelated tables:
Machine, Part, Repair, Engineer, supplier, Inspector, and Inspection.

Each table was created using SQL with appropriate data types, constraints, and relationships. Sample
data was inserted to verify data integrity and test the relationships between tables. Several queries
were also executed to demonstrate the database functionality.

Conclusion

In conclusion, this report has successfully fulfilled all the requirements outlined in the assignment
brief for Aurora Company. Through a comprehensive application of the Database Design Lifecycle
stages, we have carefully identified user and system requirements, constructed a well-structured
Entity Relationship Diagram (ERD), and applied data normalization techniques up to Third Normal
Form (3NF) to eliminate redundancy and ensure data integrity.

A total of seven interrelated tables (Machine, Part, Repair, Engineer, Inspector) were developed,
aligned with the functional requirements such as tracking machine and part information, maintenance
records, mechanic team data, and inspection details. The Data Dictionary provided precise metadata
about all attributes, ensuring clarity and consistency throughout the system.

At the implementation stage, I provide some example code of some logical designs were translated
into physical structures using appropriate constraints such as Primary Keys, Foreign Keys, NOT NULL,
and CHECK, supporting both data validation and referential integrity.

Overall, this relational database system is scalable, maintainable, and aligned with best practices,
making it a solid foundation for future enhancements.

38
HND-67 TJ76242 Moe Kaung Kin

39
HND-67 TJ76242 Moe Kaung Kin

References
Anon., 2023. Database design, conceptual, logical, physical. [Online]
Available at: https://guides.visual-paradigm.com/navigating-the-three-levels-of-database-design-
conceptual-logical-and-
physical/#:~:text=Conceptual%20database%20design%20is%20the,getting%20into%20technical
%20implementation%20details.
[Accessed 24 Jul 2025].
Anon., 2024. Database design fundamentals. [Online]
Available at: https://www.geeksforgeeks.org/dbms/database-design-fundamentals/
[Accessed 24 Jul 2025].
Anon., 2024. Database Development Life Cycle. [Online]
Available at: https://www.geeksforgeeks.org/dbms/database-development-life-cycle/
[Accessed 24 Jul 2025].
Anon., 2025. Explain database Normalization. [Online]
Available at: https://www.geeksforgeeks.org/dbms/introduction-of-database-normalization/
[Accessed 13 Jul 2025].
Anon., 2025. Physical design. [Online]
Available at: https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=relationships-physical-
database-design
[Accessed 24 Jul 2025].
Anonmyous, 2025. DBMS. [Online]
Available at: https://www.geeksforgeeks.org/dbms/database-design-in-dbms/
[Accessed 24 Jul 2025].
Anonmyous, n.d. Why database design important?. [Online]
Available at: https://miro.com/diagramming/why-is-database-design-important/
[Accessed 24 Jul 2025].
Anonymous, 2025. Type of Database. [Online]
Available at: https://www.geeksforgeeks.org/dbms/types-of-databases/
[Accessed 24 Jul 2025].
Anonymous, n.d. Date, DATETIME. [Online]
Available at:
https://dev.mysql.com/doc/refman/8.4/en/datetime.html#:~:text=The%20DATE%20type%20is%
20used,both%20date%20and%20time%20parts.
[Accessed 23 Jul 2025].

40
HND-67 TJ76242 Moe Kaung Kin

Anonymous, n.d. What is database design?. [Online]

Available at: https://miro.com/diagramming/what-is-database-design/
[Accessed 24 Jul 2025].
Castro, K., 2020. Benefits off good database design. [Online]
Available at: https://www.tutorialspoint.com/the-benefits-of-good-database-design
[Accessed 24 Jul 2025].
Developer, n.d. Why id database design important?. [Online]
Available at: https://miro.com/diagramming/why-is-database-design-important/
[Accessed 24 Jul 2025].
Gloossary, 2024. Network Database. [Online]
Available at: https://phoenixnap.com/glossary/network-database
[Accessed 24 Jul 2025].
guide, P., 2011. Requirement analysis. [Online]
Available at: https://www.sciencedirect.com/topics/computer-science/data-requirement-
analysis#:~:text=Data%20Requirements%20Analysis%20is%20defined,the%20context%20of%20
Computer%20Science.
[Accessed 24 Jul 2025].
Gupta, H., 2024. Conceptual design. [Online]
Available at: https://www.tutorialspoint.com/conceptual-database-design
[Accessed 24 Jul 2025].
Javed, 2018. Logical and physical design. [Online]
Available at:
https://en.wikipedia.org/wiki/Database_design#:~:text=Database%20design%20is%20the%20or
ganization,that%20consists%20of%20several%20steps.
[Accessed 24 Jul 2025].
JetBrain, 2024. Problem of poor database design. [Online]
Available at: https://www.quora.com/What-are-some-potential-problems-of-poor-database-design
[Accessed 24 Jul 2025].
Kemnitz, G., 2021. Impact of bad database design. [Online]
Available at: https://www.quora.com/What-are-the-signs-that-you-are-using-a-badly-designed-
database
[Accessed 24 Jul 2025].
Kumar, P., 2019. Understanding Data Type. [Online]
Available at: https://www.digitalocean.com/community/tutorials/sql-data-types
[Accessed 23 Jul 2025].

41
HND-67 TJ76242 Moe Kaung Kin

None, 2020. What is Database. [Online]

Available at: https://www.oracle.com/database/what-is-database/
[Accessed 23 Jul 2025].
Ramadhan, M., 2020. Database life cycle. [Online]
Available at: https://medium.com/informatics/the-database-life-cycle-4151969ca57d
[Accessed 24 Jul 2025].
Sesame, 2021. Physical database design. [Online]
Available at: https://sesamesoftware.com/white-papers/physical-database-design/
[Accessed 24 Jul 2025].
Star, D., 2025. Why good database design really matter. [Online]
Available at: https://www.youtube.com/watch?v=LtDXgOzKuZM&t=17s
[Accessed 24 Jul 2025].
Tejeda, V., n.d. Advantages of Database Management System[DBMS]. [Online]
Available at: https://pipeline.zoominfo.com/operations/6-benefits-of-using-database-management-
systems-dbms
[Accessed 23 Jul 2025].
Teorey, 2009. Datebase design. [Online]
Available at:
https://en.wikipedia.org/wiki/Database_design#:~:text=Database%20design%20is%20the%20or
ganization,that%20consists%20of%20several%20steps.
[Accessed 24 Jul 2025].

42