Unit 4 Database Design and Development 4

UNIT 4 DATABASE DESIGN AND DEVELOPMENT
ASSIGNMENT: Design and development of a database system
Anusha Asim
Pearson ID: RF64842
HND
Regent Middle East
Contents
UNIT 4 DATABASE DESIGN AND DEVELOPMENT.................................................................1
Activity 1.......................................................................................................................................3
Databases: Relational and Non-Relational...............................................................................3
Databases Across Different Sectors.........................................................................................7
Database System for Dubai Properties.....................................................................................8
Design Phase...............................................................................................................................9
User Requirements......................................................................................................................9
System Requirements.................................................................................................................9
Data Dictionary..........................................................................................................................10
Entity Relationship Diagrams (ERDs)......................................................................................11
Input and Output Design...........................................................................................................15
Evaluation of Design.................................................................................................................30
Overview of Object-Oriented Databases.................................................................................33
Database Development Phase.................................................................................................33
Considering and Choosing Database Platform......................................................................33
Developing Tables.....................................................................................................................34
Table Relationships...................................................................................................................54
Running Queries........................................................................................................................55
Assessing Queries....................................................................................................................68
Developing and Designing Forms...........................................................................................70
Screenshot.................................................................................................................................82
Developing and Designing Reports.........................................................................................86
Security and Maintenance Implementation.............................................................................89
Testing........................................................................................................................................91
Assessment of Testing.............................................................................................................98
Evaluation of the Database Solution.....................................................................................102
Documentation.........................................................................................................................106
Evaluation for Continuous Improvement and Effectiveness..............................................110
References...............................................................................................................................112
Student Declaration Form.......................................................................................................114
Activity 1
Databases: Relational and Non-Relational

A database is a structured collection of data which is stored electronically. It primarily falls into
two categories: relational or non-relational. Usually, a database management system (DBMS)
handles the database.
Relational Database
A relational database uses relational algebra to define relationships among elements stored in
the database.
The notion of the relational database has been proposed by E. F. Codd in 1970. In this type of
database, the data is stored within tables composed of rows and columns. Thus, all the factors
contribute to the final result of various data points.Hence, the name “relational”. The main
feature is the development of the relations between the tables. In turn, this helps to run a query
and also get access to edit data from any table. Transactions take place in relational databases
usually using the ACID criteria (Atomicity, Consistency, Isolation, Durability) to ensure that the
information is consistent and reliable. These data systems are managed using relational
database management systems (RDBMS) such as MySQL, PostgreSQL, and Microsoft SQL
Server.
Principles
1. Tabular Structure: Relational databases offer the ability to organize and arrange data in
the form of tables that can easily be searched through using rows and columns.
2. Data Integrity: Maintaining data integrity is also another vital notion of these databases.
The relations between their tables are keys-based, so achieving data integrity and
accuracy is possible.
3. ACID Properties: Dealings in the world of relational databases take place following
ACID principles (Atomicity, Consistency, Isolation and Durability). This hence is
presented as the thread that ties together reliable and secure systems for data
management.
4. Structured Query Language (SQL): Working with a relational database is performed

through a language for data management and querying, referred to as SQL which is, is
the standard.
Uses:
1. Business Applications: Relational databases are considered quite well-suited for

business applications. This can be attributed to the stability and structured nature of the
data in such applications, along with the need for a high level of integrity. One relevant
example would be customer relationship management (CRM) systems.
2. Financial Systems: Applications dealing with financial transactions can benefit from the
ACID properties of relational databases, since they need to ensure the accuracy and
reliability of the data they manage.
3. Education Management Systems:

Systems that manage student records, course schedules, grades, and educational
resources often rely on relational databases for accurate and structured data storage.
4. Human Resources Systems:

HR systems benefit from the relational model for storing employee data, payroll
information, performance evaluations, and organizational hierarchies. The structured
nature paves the way for efficient reporting and analysis.
Relational databases are the optimal choice in scenarios where data relationships and integrity
are critical.
Non-Relational Database
A non-relational database, also referred to as NoSQL (Not Only SQL), is a dynamic data
storage system, diverging from the structured and tabular model of relational databases. NoSQL
databases are typically designed to handle large volumes of unstructured or semi-structured
data. The term "NoSQL" does not imply the absence of SQL queries but rather refers to a
departure from the traditional relational database model.
Principles:
1. Flexible Schema: Non-relational databases follow a dynamic and flexible approach for
data storage, allowing for the insertion of data without a predefined criteria.
2. Scalability: NoSQL databases are designed to scale horizontally, accommodating

growing data volumes and high-traffic scenarios. They do this by distributing the data
across multiple servers.
3. Diverse Data Models: Non-relational databases support various data models. This
includes document-oriented, key-value pairs, column-family and graph databases. This
demonstrates the versatility that they provide for different types of data.
4. Eventual Consistency: Some NoSQL databases prioritize scalability over strict

consistency. They opt for ‘eventual consistency’, which means that they don’t limit the
data they store to strict criteria, aiming for consistency to naturally be achieved over time
(if the system is successful).
Non-relational databases are designed on the BASE (Basically available, Soft state,
Eventually consistent) principles. “Basically available” means that the system remains
operational, even in challenging situations. It prioritizes availability over accuracy, ensuring that
users can still access and interact with the system even if it's dealing with changes or updates.
“Soft state” refers to the flexibility of the system and as mentioned above, “Eventual
consistency” refers to the consistency model that allows for the data store to have high
availability.
Uses:
1. Big Data and Real-Time Applications: Non-relational databases are optimal for
applications that deal with massive datasets and require real-time processing, such as
analytics and social media platforms. For example, Instagram uses Cassandra, a non-
relational database.
2. Dynamic Data: Contexts where data structures are demonstrating their swiftly evolving
characteristics, subject to frequent changing, are ideal for the open-ended and flexible
structure of NoSQL databases. Content management systems are a great example of
this.
3. Scalable Web Applications: NoSQL databases are commonly used in web

applications. This is due to their high demand of scalability for handling increasing user
loads and diverse data types.
4. Agile Development: Non-relational databases that adapt to varying development

processes needed for operations are vital for agile development, thus, the developers
can easily handle the changing requirements of data.
Besides that, non-relational databases can be used in many cases dealing with different data
types where scalability is being seen as the main priority in the place of data being consistent
immediately.
Use Case Relational Database Non-Relational Database

Examples Examples
E-commerce Transactions Amazon, eBay MongoDB (used by Alibaba

for product catalog)
Social Media Platforms Facebook (MySQL, Cassandra (used by

PostgreSQL), LinkedIn Instagram for scalable data
(Oracle) storage)
Financial Systems JPMorgan Chase (Oracle), Apache HBase (used by

PayPal (MySQL) OpenX for real-time financial
data)
Content Management WordPress (MySQL), Drupal MongoDB (used by Forbes

Systems (CMS) (PostgreSQL) for content storage)
Many well-known companies use a hybrid of relational databases and relational databases. For
example, Instagram uses different relational and non-relational databases for its various
operations. This is useful due to the unique aspects of each database, making it well-suited for
specific purposes.
Aspect Relational Databases Non-Relational Databases
Data Structure Tabular structure with rows and Flexible and dynamic,
columns. supporting various models
Scalability Scaling up can be challenging Scaling up is often easier,

making it suitable for large-
scale systems
Query Language Utilizes SQL (Structured Query May use various query
Language) languages or APIs(Access
Point Interfaces), and SQL
support can vary
Data Modeling Normalized data modeling is Denormalized and flexible
common to reduce redundancy data modeling
Use in Development Well-suited for projects with Ideal for agile development
stable and well-defined where data requirements
requirements, especially those evolve rapidly or are not well-
using the waterfall model. known initially.
Databases Across Different Sectors

Databases are a vital part of businesses, which cuts across many organizations. They might be
seen as the critical gatherers of information management operations, as will be demonstrated
by the following examples below:
1. Healthcare:
a. Patient Records: Storing and managing patient records.
b. Research and Analysis: Supporting medical research by giving structured

platform for data analysis.
2. Finance:
a. Transaction Processing: Real-time transaction processing.
b. Risk Management: Enabling historical analysis of selected financial data.
3. Education:
a. Student Information Systems: Managing student records, grades, schedules, and
educational resources, as well as making administrative procedures much more
efficient.
b. Research Databases: Organizing and storing scholarly articles.
4. Retail:
a. Inventory Management: Supporting inventory tracking, hence, make the
management of the supply chain more organized.
b. Customer Relationship Management (CRM): Storing customer information,

purchase history, as well as aiding in personalizing marketing strategies.
5. Manufacturing:
a. Supply Chain Management: Tacking materials and ensuring timely production.
b. Quality Control: Storing data related to product inspections and testing.

6. Telecommunications:
a. Subscriber Information: Databases manage subscriber data, billing information,
and call records in telecommunications systems.
b. Network Management: Telecommunication companies use databases to monitor

and improve network performance.
7. Government:
a. Public Services: Government agencies rely on databases for managing citizen
information, issuing permits, and providing various public services.
b. Law Enforcement: Databases store and retrieve criminal records, making law
enforcement efforts smoother in investigations and crime prevention strategies.
Database System for Dubai Properties
As Dubai Properties grows, its operational scope increases, and this comes with an increase in
IT-related challenges. Hence, the introduction of an Information System for the help desk,
specifically a database system, is crucial. As the database developer, I will ensure that the
system is able to document and manage the IT queries being sent to the helpdesk. Ultimately,
this will improve the process of issue resolution.
The main objective is to design a relational database system that is suited for the systematic
logging and monitoring of each support request. By recording critical details such as caller
information, call timestamps, and serial numbers affiliated with different devices, the system will
enhance the efficiency of the support team. It will also give valuable insights into the overall
performance of the company's IT department.
The following user and system requirements are centered around this objective.
Design Phase
User Requirements
1. User-friendly Interface:
The system should provide a user-friendly interface for help desk operators to easily log
and manage IT queries.
2. Efficient Query Logging:

Users should be able to easily log new IT queries, being able to add details such as the
names of the help desk operator, caller and selected specialist, the time of the call, and
relevant hardware/software details. hence smoothly recording each query received..
3. Problem Categorization:
The system should let the help desk operators sort each problem deriving from the calls
into a distinct problem category, depending on its nature.
4. Caller Information Retrieval:

Users of the database should have the ability to quickly retrieve all of the relevant
information for each individual caller, including their ID number, serial number and name.
5. Equipment Information Retrieval:

Users should have the ability to check equipment details, including the operating system
and software information. This will also include the validity of the software license.
6. Problem Referral System:

The system should make it easier for help desk operators to assign problems to specific
specialists by letting them retrieve the area of specialty of each of the specialists, since
knowing the area of expertise will help them to settle more of the issues related to their
specialties.
7. Specialist Performance:
Help desk operators should be able to view the open and closed cases of specialists,
including the number of problems that each specialist is working on and has worked on
(essentially, their full personal problem resolution history).
8. Resolution Recording:
Help desk operators must be given the privilege by the system to log the date, time, and
resolution details once a problem is resolved, ensuring a good record of issue resolution.
System Requirements
1. Relational Database System:
The system should be implemented on a relational database, where its data would be
structured and organized by having defined the data types and how they should relate,
thus, one can ensure a high level of overall data integrity.
2. Security Measures:
The system should be having defense mechanisms in place that will ensure that only
authorized users are allowed to access, edit and disclose the information in a system.
3. Scalability:
The system ought to be scalable to be capable of expanding to the growing company's
future requirements, as Dubai Properties' operations might be expanding in the future.
4. Backup and Recovery:

There must be regular backup procedures and a reliable recovery system to prevent
data loss and make system restoration easier, in case disruption occurs.
5. User Authentication and Authorization:

A secure user authentication or authorization system is needed to control access levels.
The access levels can be based on user roles within the help desk and specialist teams.
6. Compatibility:
The system must be compatible with the various hardware and software configurations
commonly used within the company.
7. Documentation and Training:

There must be comprehensive documentation and training resources for users, helping
them to understand and utilize the system effectively, and with ease.
8. Reliability:
The system must be reliable without any data discrepancies. Referential integrity and
data validations must be enforced.
Data Dictionary
A data dictionary serves as a reference guide, outlining the attributes, structure and
characteristics of the entities within a database system. The data dictionary below can be
viewed as a reference guide for the IT help desk of Dubai Properties.
Entity Relationship Diagrams (ERDs)
Entity-Relationship Diagrams (ERDs) are valuable tools in database design. They give a visual
depiction of the relationships between different elements within a system. Basically, ERDs show
how various entities (like people, objects, or concepts) are connected through different
relationships. For a relational database, this comes in very handy.
For designing a database that will be managing IT queries at Dubai Properties, an ERD is going
to act like a blueprint through mapping out all the entities that are involved (like callers,
specialists, problem details, etc.) and their relationships.
This will serve the following purposes:
1. Clarifying Data Relationships:

ERDs will give a visual of how different parts of the database are linked. For example,
being able to see which employees are asking IT questions and which specialists are
fixing them.
2. Identifying and Displaying Key Information:

ERDs allow developers to highlight the main entities and their attributes ,as well as
excluding the data not needed for the database. Thus, the overall database design
becomes appropriate.
3. Helping with Data Integrity:

ERDs help maintain data integrity through highlighting entity relationships and
constraints (primary and foreign keys). This prevents inconsistencies and errors.
4. Making Collaboration Easier:

ERDs can also play the role of a communication tool. They help coordination between
developers, stakeholders and other team members. The visual nature of the diagram
makes it easy for stakeholders to give important feedback, notifying the database
developer of changes to be made.
Simple ERD
This simple ERD gives a basic overview of all the entities present in the database and their
relationships with each other, as well as the primary keys of each entity However, this is vastly
oversimplified since the type of relationships is not depicted, and neither are the key details
about the data within the entities.
Logical ERD
A logical ERD is a bit more detailed in a comparative sense to the above version, due to its
entities interacting with each other through various relationships, as well as reflecting cardinality
(how many occurrences of an entity are related to the occurrence of another entity). Hence, this
gives a deeper look into the data architecture, becoming especially useful when designing
databases.
This logical ERD shows the various entities in the database, their primary keys, as well as the
data types they contain and field sizes for each one. Furthermore, the relationships between the
entities in the database are clearly depicted:
1. One-to-many relationship between the Caller Details table and the Problem ID table
since one caller can have multiple (i.e many) problems.
2. One-to-many relationship between the Caller Details and Employee details tables since
one employee can make several calls.
3. One-to-many relationship between the Equipment and Caller Details table since multiple
calls can be made regarding one piece of equipment.
4. One-to-many relationship between Caller Details and Specialist table since specialists
can be assigned to resolve the issues of multiple calls.
The set field sizes and data types depicted in this ERD will be justified in the data validation of
the report.
Input and Output Design
The input design in databases refers to creating an interface that is friendly to users for entry of
data. While output design on the other hand, is more in reference to reports, dashboards and
query results for users, to improve the readability and arrangement of database information.
In accordance with Dubai Properties’ user requirements of a user-friendly and interactive

system, input and output designs will be created. They will aid in making the inputting of data an
easy process, reduce errors, and improve the usability for help desk staff at large.
User Input Design Output Design Validation Test

Requirement
Add new queries Enter details of The details get Only employees Enter incorrect
(calls) the call on a inserted into the can make calls employee name
form relevant table or ID to ensure
that it is rejected
Problem Enter category Gets stored in Must show in Enter a new

Categorization of problem on a relevant table, related queries problem
form showing up in and forms according to
various related category
queries and
forms
Equipment Enter a piece of View all the key Equipment Enter serial
information identifying details of the information number to check
retrieval information of equipment entered on a that all key
the equipment form must match details of the
(like serial no.1) existing records equipment are
on a form to be valid displayed
accurately
Retrieve Enter specialist View all the Specialist names Enter a valid
specialist name problems they entered should specialist name:
problems are working on be validated Ensure that all
and have against existing problems the
worked on specialists in the specialist is
system. working on and
has worked on
are matching the
specialist table.
Resolution Enter resolution Gets stored in Resolution Enter a

Update time/date, the relevant updates must be resolution
description and table, showing updated in all update and
status up in various related queries ensure that it is
related queries and forms showing up on
and forms related queries
and forms
Interface Designs
The following interface designs show how the various tables, forms and queries will look like in
the database. In order to meet the Dubai Properties’ requirement of a user-friendly interface,
they will be designed with the aim of having a simple and easy-to-navigate layout including
visible fields, buttons, neatly arranged tables, etc.
For this purpose, Canva was used as a graphical user interface (GUI) tool despite mainly being
a graphic design platform. While it was not specifically designed for this purpose and its present
use deviates from that, Canva's intuitive interface and great variety of options was effective in
use for certain low-fidelity designs like the visualizations of data, proving to be a cost-effective
and simpler alternative to traditional GUI tools.
Tables
The key data and entities will enter the database will have the following layout:
1. Arranged in a tabular manner

2. Columns and rows
3. The rows will be expendable
4. There will be a title for each table, showing what entity it is
5. There will be checkboxes in the resolution status and license validity columns.
6. Visually enhanced in terms of colors and font (pastel background, along with
professional font like Calibri or Arial) to match the branding of Dubai Properties
Queries
For the sake of simplicity, it was opted for queries to have the same design and layout as tables
after the criteria had been applied.
1. Data will be arranged in a tabular manner

2. Columns and rows
3. The rows and columns will be expendable
4. There will be checkboxes in the resolution status and license validity columns.
5. Visually enhanced in terms of colors and font (pastel background, along with
professional font like Calibri or Arial) to match the branding of Dubai Properties
6. There will be a title for each query, showing its purpose
Forms
The forms in the database will have the following interface:
1. Dubai Properties logo at the top, with relevant background to match branding.
2. Enable help desk operators to browse through records with ease
3. Linked with relevant tables and queries
4. Visually appealing
5. Any queries or tables that they depict must be easily scrollable
6. Enable help desk operators to easily add new records through the form
The “welcome” form is going to be the main form of the database, which will be linked to the
main caller details table, letting help desk operators easily browse through records and having
the ability to add new ones.
Additionally, it will also have a specialists subform so that help desk operators can quickly view
specialist details before assigning them to the problem being extracted from a call. Other forms
in the database will be having a similar design and layout, a little variation may occur depending
on the nature and purpose of the particular form but overall design and formatting will be the
same for consistency.
Furthermore, a main menu form is going to be included which will have buttons linked to
important tables, queries and forms for easy navigation by help desk operators.
Reports
The reports of the database will have the following interface:
1. Dubai Properties logo at the top, with relevant background to match branding.
2. Relevant report titles so that help desk operators can easily understand them.
3. Clearly organized
4. Data retrieved in tabular format for consistency
5. Linked with relevant queries and forms
6. Print button for easily getting print preview
Now that the design of the database interfaces is ready, the next step is going to be about
dealing with the raw data and preparing it to fit into the database, so that it matches with the
requirements. In order to achieve this, processes of data normalisation and validation will be
applied.
Data Normalisation (1NF, 2NF and 3NF)

Data normalisation is the first step towards getting structured and organized data, which is not
only essential for insertion into a database, but it is also needed if the database is going to be
upscaled in the future to implement predictive analytics, artificial intelligence and such other
optimizations.
Initially, the raw data existed unstructured and unorganized in a spreadsheet.

As it can be seen, the data is currently completely unnormalised, with several repeating groups
which creates redundancy, imbalance, as well as empty fields. To rectify this, it will firstly be
normalized to the first normal form (1NF).
In order to meet this form, two repeating rows were identified and deleted.
The “Caller ID and Name” column was violating 1NF by having two attributes per cell so the two
attributes were split into separate columns.
Furthermore, some important primary keys were identified in this form:
1. CallID
2. EmployeeID
3. SpecialistID
After this, the requirements of the first normal form (1NF) were satisfied: No cell has more than
one attribute and data in all rows is unique (no repetitions).
Next, for normalisation into second normal form (2NF), tables were created based on the
identified primary keys with the columns that fully depended on them.
It was checked that each column depended on the primary key.
Table 1: Caller Details

All the attributes in the caller details table are linked to the primary key, which is the callID.
Table 2: Employee Details
All the attributes in the employee details had some level of dependency on the primary key of
EmployeeID, showing personal details of the employees and their equipment.
Table 3: Specialists
All the attributes in the specialists table had some level of dependency on the primary key of
SpecialistID, showing personal details of the specialists and their problems.
Moving on to third normal form (3NF), it is required that all the attributes in a table are fully
dependent on the primary key, with the transitive (i.e. partial) dependencies being removed or
getting rearranged into their own separate table.The main caller details table is already in third
normal form with each of its attribute either directly originating from or being directly decided on
the bases the call ID, however the following two tables of Employee Details and Specialists are
presently violating third normal form. This is because not all of their data depends fully on the
primary key, there are some transitive dependencies which are going to be addressed.
Aside from showing the serial number of an assigned piece of equipment that the employee
gets access to based on their employee id, it doesn’t make sense to have all the other
equipment details i.e equipment ID, serial number, operating system, software installed and
valid license since these attributes are not directly dependent on the primary key of employee
ID. Instead, they are dependent on equipment ID. Hence, a new table will be created for
equipment with equipment ID as the primary key.
Updated Employee Details Table

Table 4: Equipment
There is a similar issue in the specialists table that will now be dealt with: all of the attributes are
not depending fully on the primary key of Specialist ID. The column of problem type is directly
dependent on problem ID, not specialist ID, with which it has no direct dependency on. To
address this, a new table will be created for problems with the problem ID as the primary key.
This will also solve the issue of repeating “problem ID” columns that were overlooked before.
Due to this repetition, 1NF was also being violated in the specialist table.
Updated Specialist Table
Table 4: Problems
All of the data is now normalised to the third normal form (3NF).
Data Validation
Data validation is crucial since it guarantees that every piece of information in a database is
exactly according to the specified rules, and that the attributes of data are consistent, complete,
or accurate. This is done by strictly following the validation rules which can consequently bring
down the cases of errors, inconsistencies, and inaccuracies as a result, the system turns out to
be more reliable. Data validation is also needed to enforce referential integrity, which is the
concept of changes getting automatically updated and reflected in related records.
For the case of Dubai Properties’ database, the following rules are set for the data in each table.
Data Types and Field Sizes for Caller Details Table
1. CallID (Short Text, 3): Short text data type is suitable for unique identifiers, along with
the field size of 3 characters allowing for concise representation of unique identifiers,
preventing errors.
2. CallerID (Short Text, 3): Similar to CallID, this will also be a short text data type
containing a field size of 3 characters, which appears to be appropriate for the purpose
of storing caller identifiers.
3. CallerName (Short Text, 40): This must be kept a short text data type, containing a field
size of 40 characters which will be successfully accommodating most names , all while
minimizing storage space.
4. OperatorName (Short Text, 40): Similarly as CallerName, this must also be kept a
short text data type, having a field size of 40 characters which is going to be suitable for
storing operator names.
5. SerialNumber (Short Text, 5): This will also be a short text data type for the purpose of
storing serial numbers, containing a field size of 5 characters allowing for efficient
storage of alphanumeric serial numbers.
6. TimeOfCall (Date/Time, NA): Date/Time data type is appropriate for storing

timestamps, providing accuracy and consistency in recording call times.
7. ProblemID (Short Text, 3): Short text data type is suitable for problem identifiers, and a
field size of 3 characters will allow for concise representation of the unique identifiers.
8. ProblemType (Short Text, 80): Just like most of the other columns, this is also a short
text data type, however its field size will be accommodating 80 characters in case longer
problem types need to be updated into the database in the future.
9. Description (Long Text, NA): This will be kept a long text data type, in order to prepare
it for successfully storing detailed problem descriptions, all without limiting the length of
text entries.
10. SpecialistName (Short Text, 50): This will be a short text data type with a field size of
50 characters, to allow it to store specialist names while at the same time. minimizing
storage space.
11. ProblemStatus (Short Text, 50): This is going to be a short text data type with a field
size of 50 characters, to make it suitable for recording problem statuses.
12. Resolved (Yes/No, NA): Yes/No data type is appropriate for the boolean values which
will be present in this attribute, indicating problem resolution status while occupying a
minimal storage space.
13. ResolutionTime (Date/Time, NA): The Date/Time data type will be accurately
recording the problem resolution times i.e what day, month and year they were resolved
on.
14. ResolutionDescription (Long Text, NA): This must be a long text data type, allowing
for the entry of descriptions of steps taken or the method used to resolve the problem
without limiting the length of text entries.
Data Types and Field Sizes for the Equipment Table
1. Serial Number (Short Text, 5): This will be a short text data type for the purpose of
storing serial numbers, containing a field size of 5 characters to allow for efficient
storage of alphanumeric serial numbers.
2. EquipmentID (Short Text, 5): This is going to be set as a short text data type with a
field size of 5 characters, making it appropriate to sufficiently store unique equipment
identifiers, all within minimal storage space.
3. OperatingSystem (Short Text, 50): This will be a short text data type, having a field
size of 50 characters, making it suitable for the purpose of storing the names of various
operating systems within a reasonable amount of storage space.
4. SoftwareInstalled (Long Text, NA): This will be kept as a long text data type, allowing
it to store the names of installed software without limiting the length, seeing that there is
no maximum software limit on Dubai Properties’ employee devices.
5. ValidLicense (Yes/No, NA): The data type set for this will be Yes/No, accurately
indicating whether the software licenses are valid or not.
Data Types and Field Sizes for the Specialist Table
1. SpecialistID (Short Text, 3): This is going to be set as a short text data type with a field
size of 3 characters, enabling it to store unique equipment identifiers, within the optimal
storage space.
2. SpecialistName (Short Text, 50): This is going to be a short text data type with a field
size of 50 characters, allowing it to store specialist names while at the same time,
minimizing storage space.
3. Department (Short Text, 50): Similarly to a few other nominal data types, this will be
having a short text format, containing a field size of 50 characters which lets it
accommodate various department names.
4. Specialization (Short Text, 25): This will be a short text data type with a field size of 25
characters, which will be suitable for the purpose of recording each specialist’s
specialization.
5. ProblemID (Short Text, 3): This will be set as a short text data type, making it suitable
for storing problem identifiers within its field size of 3 characters for concise
representation.
6. BackupSpecialist (Long Text, NA): This will be set as a long text data type for the
purpose of entering multiple backup specialists for one specialist, hence the limit is
removed.
Data Types and Field Sizes for the Problems Table
1. ProblemID (Short Text, 3): Just like in the previous table, this will be set as a short text
data type, making it suitable for storing problem identifiers within its field size of 3
characters for concise representation.
2. ProblemType (Short Text, 80): This will also be a short text length field, but as a matter
of added precaution, the size of the field should be increased to 80 characters in regard
to the case where in future a longer problem type is needed to be entered into the
database.
3. Specialist (Short Text, 50): This will be a short text data type with a field size of 50
characters, allowing it to store specialist names while at the same time, minimizing
storage space.
Data Types and Field Sizes for the Employees Details Table
1. EmployeeID (Short Text, 3): This must also be a short text data type containing a field
size of 3 characters, which appears to be appropriate for the purpose of storing each
employee’s unique identifier that is used to distinguish them.
2. EmployeeName (Short Text, 40): This will be kept as a short text data type, containing
a field size of 40 characters which will be successfully accommodating most names, all
while minimizing storage space.
3. DateOfBirth (Short Text, 30): This will be stored as a short text data type since the birth
date is mainly for display purposes, and storing it as short text instead of date/time
allows for easier data validation. Additionally, the field size of 30 characters will be giving
sufficient storage for date information, while taking up minimal storage space.
4. Department (Short Text, 50): This will be having a short text format, containing a field
size of 50 characters which serves the purpose of letting it store various department
names.
5. Serial Number (Short Text, 5): This is going to be a short text data type for the purpose
of storing serial numbers of the employees’ devices, containing a field size of 5
characters to allow for optimal storage of the alphanumeric serial numbers.
6. JobTitle (Short Text, 50): This will be set as a short text data type, having a field size of
50 characters for the purpose of storing relevant job titles.
7. LicenseNumber (Long Text, NA): This will be a long text data type, appropriate for the
purpose of storing different kinds of license numbers without limiting the length of text
entries. This is because due to Dubai Properties evolving nature as a company, new
departments and licenses may be required in the future, making it best to avoid this
constraint in the database.
Evaluation of Design
1. Entity Relationship Diagrams (ERDS):
Advantages:
● Application to Requirements: The ERDs reveal entities and their relationships that is as
per Dubai Properties user and system expectations. The ERD could, for example, show
the roles that callers, specialists, problems, and equipment play in the issue and
resolution process, which would meet the requirement to track call center queries and
allocate resources properly.
● Enhanced Collaboration: The ERDs are designed in a way that makes them visually
understandable to everybody that is involved in the database development for instance,
the developers, and other stakeholders. Hence, it is very important for good
communication and coordination in the design and implementation of the strategy.
Disadvantage:
● Oversimplification: Whereas ERDs heighten the level of understanding, they can lack
details with regard to complexities among attributes. Unfortunately, this may result in a
lack of clarity or missing some details.
Overall Evaluation:
● Although ERDs have limitations, they provide a clear mapping of data relationships and
a basic guide for database design, which fits the “documentation and training” system
requirement of Dubai Properties.
2. Normalization (2NF and 3NF):
Advantages:
● Alignment with Requirements: The process normalizes data to be reliable (since it
removes inconsistencies) and makes it easily manageable, aligning with the user
requirement that the logging is to be done with ease and effectively done.
● Scalability: Normalizing the data helps in making it scalable, which will be key in
enabling smoother adjustments and updates with any future expansion that may happen
within Dubai Properties.
● Disadvantages:
Complexity: Ironically, normalization might have the potential to make the database
more complex, since it increases the number of tables and relationships.
Speed: It may also be slowing down query execution and the time taken to seek data
because one needs to join more tables and lookups to collect the required data.
● Overall Evaluation:
Despite potential challenges, normalization satisfactorily meets the requirements of
Dubai Properties; it provides the structure that ensures integrity of the data, all while
helping with potential scalability.
3. Data Validation:
● Advantages:
Adherence to Requirements: Data validation helps keep the database up-to-date and
accurate, and it satisfies the user requirement of the orderly logging of call query activity
and issue categorization.
Data Integrity: Validation rules are executed when the user tries to enter data into a table
and set the referential integrity rule for the database. Therefore, data validation enables
full faith in the database.
● Disadvantages:
Implementation Overhead: The deployment of data validation rules will face the
additional processing requirement making the development of the system to be slow.
Despite the concerns of data validation, it ensures that the data remains accurate and
the system keeps being reliable, which is what the users and system of Dubai Properties
require.
4. Interface Designs:
Advantages:
● User-Friendly Interface: This feature under the input and output designs highlight
a rather easy to use interface with clear titles, functions etc. This is basically
seeking to respond to Dubai Properties that the system should be user-friendly
and be navigated effortlessly.
● Enhanced Usability: A variety of forms, reports, queries, and tables designed in
Canva are elements with some of the components of a visually appealing page,
which are top of the class and provide better usability to help desk operators.
Disadvantages:
● Learning Curve: Even though the newly designed user interface seems to be
simple to use and compatible with most devices, it might take some time for the
new help desk operators to get used to it and to learn all the functions it has.
There are also imperfections within the accessibility options such as the absence
of alt text.
Despite the disadvantage, user requirements are still met since the designs
seem to be serving the purpose of helping help desk operators navigate the
pages with ease through their user-friendliness. They also have visually pleasant
layouts, thus, giving a good user experience.
Areas for Improvement

1. Next and Previous Buttons: Navigation buttons in forms and reports being included is
a step towards improving user experience and this requirement fits into the category of
user friendly interface which the users require.
2. Email Form in Report: A placement of an email button in one of the relevant reports will
improve the communication between help desk operators and their supervisor.
3. Linking Main Menu to External Documentation: By placing links outside of the menu,
to places containing more instruction in regard to the database functionality, it would be
straightforward for the new help desk operators in getting to know how to use and
navigate the database.
4. Security Considerations: Passwords and administrator privileges could be added in

the database to improve security.
5. Improving Data Validation: Some of the unique identifiers like employee IDs, serial
numbers and equipment IDs start with certain key letters. The validation rules can
enforce these key letters and disable any erroneous entries where the key letters are
missing or typed out wrong.
Overview of Object-Oriented Databases
An object-oriented database is a complete paradigm shift from the traditional relational
databases in terms of organization: the object, and not the table, is the building block. In
OODBs, the objects inwardly encapsulate data, with each one building up attributes (data fields)
and methods (functions or operations). This model bridges principles of object-oriented
programming (OOP) and squarely fits with database systems and application code.
Designing tools come along with a wide range of characteristics, which include: Object-
Relational Mapping (ORM) Tools, Object-Oriented Design Patterns, and Graphical User
Interface (GUI) Tools.
Database Development Phase
Considering and Choosing Database Platform

After careful consideration, Microsoft Access was chosen as the preferred platform for the
following reasons:
1. Compatibility with Existing Infrastructure: Microsoft Access is an integral part of the

Microsoft Office package, in which a number of services including Microsoft Excel and
Outlook are being utilized by the Dubai Properties commonly. Such compatibility grants
fast and convenient data transfer and synergy among different teams thus, the overall
motion becomes more efficient.
2. Ease of Use: Access has a simple interface with handy design tools, which are capable
of being used by non-technical users such as the help desk operator. By borrowing all
the familiar look and feel of the other Office applications, this reduces the learning curve
and facilitates quick adoption and implementation within the organization.
3. Cost-Effectiveness: Being more cost-effective than enterprise-level DBMS, such as SQL

Server, is a very important advantage for smaller businesses like Dubai Properties since
just like most small and medium-sized businesses, they also operate with lower budgets.
To begin with, low license fees and infrastructure costs are among the reasons it is so
popular. Secondly, despite these low prices, users are still given access to high quality
database functions.
4. Scalability: Although Access may not be as great in terms of its handling of vast
databases when compared to SQL Server, it still provides a great scalability level to
meet the database needs of Dubai Properties. This means that the database can be
scaled up or moved to SQL Server or any other leading DBMS solutions when the
organization grows,thus, keeping the database scalable and flexible for the future.
Despite the constraint posed by the use of Access in the handling of massive databases, the
system still caters to the demands of the business at the moment of data handling while offering
room for future increase and transitions.
Developing Tables
The tables were developed in accordance with the interface designs, Dubai Properties’
requirements and the suggestions made in the evaluation. The data which had been normalized
to third normal form (3NF) was inputted into each table, along with clearly named columns and
table titles to make sure that help desk operators are going to be able navigate them easily in
case any changes are to be directly made to the tables, or if any cross-checking is to be done.
Additionally, pastel backgrounds were added to each table to match the theme of Dubai
Properties. After developing each table, its validation rules were enforced through design view.
Based on the suggestion made in the evaluation, an extra validation rule was added for unique
identifiers through design view. All call IDs will start with “C”, caller and employee IDs will start
with “A”, serial numbers will start with “SN”, problem IDs will start with “P”, license numbers will
start with “LN”, equipment IDs will start with “E” and specialist IDs will start with “SP”.
Caller Details Table

Caller Details Table Data Validation
Employee Details Table
Employee Details Table Data Validation

Equipment Table
Equipment Table Data Validation
Problems Table
Problems Table Data Validation
Specialists Table
Specialists Table Data Validation
Table Relationships
The relationships determined during the design phase of the database were implemented using
Ms Access’s relationships tool to enforce referential integrity, as well as for the purpose of
preventing “orphan records”, which are records that refer to a non-existing primary key.
Running Queries
A query is a command for information or an act to perform any of the database operations
related to data (such as retrieval, modification, or manipulation). Various queries were run on
the database to satisfy the requirements of Dubai Properties’. They were implemented in SQL
as well (a query language designed for the purpose of managing and manipulating relational
databases).
Query 1: Closed Problems

This query involves retrieving the relevant columns from the problems and caller details tables
by filtering the problems which have “closed” status.
Query 1 SQL Implementation

SELECT: Restricts itself to certain fields to be extracted from the tables.
Problems.ProblemID, Problems.ProblemType, Problems.Specialist: Filters chosen to limited

data from the table "Issues" to show only the specific data.
CallerDetails.TimeOfCall, CallerDetails.ProblemType, CallerDetails.Description,
CallerDetails.ProblemStatus, CallerDetails.ResolutionTime, CallerDetails.ResolutionDescription:
The fielded data chooses to come from the "CallerDetails" table.
FROM: The tables clear from where the data will be fetching.
Problems INNER JOIN CallerDetails ON Problems.ProblemID = CallerDetails.ProblemID:

Indicates the "join condition" on matching records from the "Problems" table with "CallerDetails"
table through their "ProblemID" fields as the basis.
WHERE: Indicates the order and conditions to specify the index sought.
CallerDetails.ProblemStatus="Closed": Filters the data to include only those records, where the
"ProblemStatus" field from the "CallerDetails" table occurs as an equal "Closed" value.
Query 2: Devices with Problems

The second query shows the pieces of equipment that are affected by problems by fetching the
relevant data from the problems, equipment and caller details tables.
SELECT: Specifies the fields to be retrieved from the tables.
Equipment.SerialNumber: Field selected from the "Equipment" table.

Problems.ProblemID, Problems.ProblemType: Fields selected from the "Problems" table.
Equipment.EquipmentID: Field selected from the "Equipment" table.
FROM: Indicates the tables from which the data will be retrieved.
Problems INNER JOIN (Equipment INNER JOIN CallerDetails ON Equipment.SerialNumber =

CallerDetails.SerialNumber) ON Problems.ProblemID = CallerDetails.ProblemID: Specifies the
join conditions where:
Records from the "Problems" table are matched with records from the "CallerDetails" table
based on their "ProblemID" fields.
Records from the "Equipment" table are matched with records from the "CallerDetails" table
based on their "SerialNumber" fields.
Query 3: Employee Device Details

This query retrieves key details about each employee’s device using the equipment, employee
details and caller details tables.
SELECT: This specifies the fields that are going to be retrieved from the tables.
EmployeeDetails.EmployeeID,
EmployeeDetails.EmployeeName: Fields chosen to be from the table "EmployeeDetails".
Equipment.SerialNumber, Equipment.EquipmentID, Equipment.OperatingSystem,
Equipment.SoftwareInstalled, Equipment.[Valid License]: "Equipment” table - fields chosen from
it. FROM: Specify what tables will be the sources of the data.
(Equipment INNER JOIN EmployeeDetails ON Equipment.SerialNumber =
EmployeeDetails.SerialNumber) INNER JOIN CallerDetails ON (Equipment.SerialNumber =
CallerDetails.SerialNumber) AND (EmployeeDetails.EmployeeID = CallerDetails.CallerID):
Specifies the join conditions as, where:
The data from "EmployeeDetails" table is cross-matched with data from "Equipment" table
based on their same "SerialNumber" keys.
Records belonging to the "Equipment" table are matched with records belonging to the
"CallerDetails" table, where the condition for a "SerialNumber" attached to each of the records is
met. In the "EmployeeDetails" table, the records are matched to the records from "CallerDetails"
table, based on their "EmployeeID" and "CallerID" fields.
Query 4: Employee Names

This basic query simply fetches the employee names from the employee details table, so that
help desk operators are able to take a quick glance at the name list.

SELECT: Specifies the field which is going to be retrieved. EmployeeDetails.EmployeeName:
Name of the field that has been selected from the "EmployeeDetails" table.
FROM: is indicating the table from which the data is going to be retrieved.
EmployeeDetails: specifies the "EmployeeDetails" table.
Query 5: Expired Licenses

This query shows the software licenses that have expired and which equipment, as well as
employees, that they belong to through data retrieval from the equipment and employee details
tables. It will help the help desk operators view and share this information easily for the purpose
of issuing update notices.
SELECT: is Specifying the fields which must be retrieved. Equipment.SerialNumber,

Equipment.EquipmentID, Equipment.OperatingSystem, Equipment.SoftwareInstalled,
Equipment.[Valid License]: are the fields selected from the "Equipment" table.
EmployeeDetails.EmployeeName: is the fieldselected from the "EmployeeDetails" table.
FROM: Indicates the tables from which the data is going to be retrieved.
Equipment INNER JOIN EmployeeDetails ON Equipment.SerialNumber =
EmployeeDetails.SerialNumber: Is specifying the join condition where records from the
"Equipment" table are matched with records from the "EmployeeDetails" table based on their
"SerialNumber" fields.
WHERE: Specification of the condition that the retrieved records must be meeting.
Equipment.[Valid License]=No: filtering the records to include only those where the "Valid
License" field in the "Equipment" table is "No".
Query 6: Help Desk Department

This query shows which employees are the members of the help desk department through
retrieval of the employees who have "help desk" entered as their department, from the
employee details table.
SELECT: specifies which of the fields are going to be retrieved.

EmployeeDetails.EmployeeID, EmployeeDetails.EmployeeName, EmployeeDetails.DateOfBirth,
EmployeeDetails.Department, EmployeeDetails.SerialNumber, EmployeeDetails.JobTitle,
EmployeeDetails.LicenseNumber: Names of the fields which are selected from the
"EmployeeDetails" table in the database.
FROM: Indicating the table from which the data will be retrieved.
EmployeeDetails: Specifies the "EmployeeDetails" table.
WHERE: Specifies the condition that the retrieved records must be meeting.
EmployeeDetails.Department="Help Desk": Filtering the records so that they include only those
where the "Department" field in the "EmployeeDetails" table is equal to "Help Desk" i.e it
contains "Help Desk".
Query 7: Open Problems

Similar to the first query except with the inverse purpose, this query involves retrieving the
relevant columns from the caller details table by filtering the problems which have “open” status.

SELECT: Defines the entities to be extracted.
CallerDetails.SpecialistName, CallerDetails.ProblemStatus: these of the "CallerDetails" table's
fields are picked up.
FROM: specify the table from which the data will be extracted which is mentioned in the next
line.
CallerDetails: Adds the "CallerDetails" table.
WHERE: Sets that the retrieved records must be meeting a certain condition.
CallerDetails.ProblemStatus="Open": Filters records to include where the "ProblemStatus" from
the "CallerDetails" table is "Open".
Query 8: Problems by Employees

This query shows each employee’s problems by retrieving the relevant data from the caller
details, employee details and problems tables, so that help desk operators can conveniently
track the problems of each employee.
SELECT: Mentions the fields which are to be retrieved.

Problems.ProblemID, Problems.ProblemType: names of the fields selected from the
"Problems" table.
EmployeeDetails.EmployeeName, EmployeeDetails.EmployeeID: names of the fields that are
selected from the "EmployeeDetails" table.
FROM: Indicates the tables from which the data is going to be retrieved.
Problems INNER JOIN (EmployeeDetails INNER JOIN CallerDetails ON
EmployeeDetails.EmployeeID = CallerDetails.CallerID) ON Problems.ProblemID =
CallerDetails.ProblemID: Gives the specific joining conditions where: Records from the
"EmployeeDetails" table are matched with records from the "CallerDetails" table on the basis of
their "EmployeeID" and "CallerID" fields.
Records from the "Problems" table are also matched with records from the "CallerDetails" table
based on their "ProblemID" fields.
Query 9: Specialty of Specialist

This query shows the speciality of each specialist by retrieving the data from the specialist table
and excluding irrelevant data so that the help desk operators can quickly review this information
before assigning specialists on problems.
SELECT: Selects the fields to be retrieved for the query.

Specialists.SpecialistID, Specialists.SpecialistName, Specialists.Specialization: these are the
names of the specific selected from the "Specialists" table.
FROM: This shows the table from which the data will be retrieved.
Specialists: This specifies that the "Specialists" table is that table
Assessing Queries
The Microsoft database system implements queries that aid in IT queries management at Dubai
Properties, developed in order to draw meaningful pieces of information from the tables.
However, each of the query has a specific purpose that aims to produce adequate management
information for better decision making and problem solving. I will now analyze each query
separately by breaking down how it serves an information management purpose for Dubai
Properties.
Query Purpose Analysis
Query 1: Closed Problems Help desk operators need to The query retrieves relevant
track closed problems for columns from the problems
reporting and analysis. and caller details tables,
filtering problems with a
"closed" status. It effectively
provides information on
resolved issues, enabling
analysis of resolution times
and methods.
Query 2: Devices with Help desk operators need to This query fetches data from
Problems identify equipment affected by the problems, equipment, and
problems to give access to caller details tables, allowing
specialists. operators to view affected
equipment and associated
problems. It facilitates
efficient problem resolution
by providing visibility into
affected devices.
Query 3: Employee Help desk operators require key By joining the equipment,
Device Details details about each employee's employee details, and caller
device for support purposes. details tables, this query
retrieves essential
information about employee
devices. It enables operators
to access device details
quickly, enhancing support
efficiency.
Query 4: Employee Help desk operators need a list This basic query fetches
Names of employee names for reference employee names from the
and communication. employee details table,
providing operators with a
quick reference list. It
simplifies communication and
facilitates personalized
support.
Query 5: Expired Licenses Help desk operators need to The query retrieves data on
identify expired software licenses expired licenses and
for renewal and compliance. associated equipment and
employees, enabling
operators to issue update
notices. It supports license
management and ensures
compliance with software
agreements.
Query 6: Help Desk Help desk operators need to This query retrieves
Department identify members of the help employee details for those
desk department for assigned to the help desk
collaboration and coordination. department, facilitating
collaboration among team
members. It ensures efficient
communication within the
help desk team.
Query 7: Open Problems Help desk operators need to Similar to Query 1, this query
track open problems for retrieves relevant columns
prioritization and resolution. from the caller details table,
filtering problems with an
"open" status. It provides
visibility into unresolved
issues, aiding in prioritization
and timely resolution.
Query 8: Problems by Help desk operators need to By joining the problems,

Employees track problems reported by each employee details, and caller
employee for individualized details tables, this query
support. retrieves data on problems
reported by each employee. It
enables operators to provide
personalized support and
track individual problem
trends.
Query 9: Specialty of Help desk operators need to This query retrieves data
Specialist assign specialists based on their from the specialist table,
expertise for efficient problem providing information on each
resolution. specialist's specialization. It
assists operators in assigning
specialists with relevant
expertise to address specific
problems.
Overall Assessment
The implemented queries appear to be extracting meaningful data from the database, each
serving an information management purpose for Dubai Properties. They enable help desk
operators to track, analyze, and resolve IT queries efficiently, ultimately improving overall user
experience, as well as operations.
Areas of Improvement
Although the queries seem to satisfy information management purposes, there are some
improvements that can be made.
1. Irrelevant rows can be excluded. For instance, how the “Devices with Problems” doesn’t
give criteria to only show devices with problems which means that even though this
query can be successfully used to track problematic devices, irrelevant records of
devices without problems will still be displayed.
2. Most of the queries are “Select” queries i.e they are mainly doing data retrieval.
Efficiency can be increased through using other queries, like action queries, which are
used to add or update data in the database. For example, an action query can be
created to add new devices in equipment and to delete ones that are not in use
anymore.
3. Relevant queries can be linked to various forms and reports.
Developing and Designing Forms

In Microsoft Access, a form serves the purpose of allowing users to interact with and input data
into a database in an organized and user-friendly way. The forms below were made so that the
help desk operators can receive displays of, quickly review information from or enter data into
various tables and queries in Dubai Properties' databases. The design of the forms were based
on the interface designs from the design phase, along with adding improvements that have
been gathered from the design evaluation like the "next" and "buttons". Additionally, an “add
new” record button was added in the main welcome form so that help desk operators can have
a smoother experience.
Form 1: Welcome Form

This is the most important form in the database. Here, operators can browse through all
problems in the main caller details table, as well as having the ability to add new problems
received from calls. In order to make it easier for them to quickly assign specialists to problems,
a specialists subform has been added so that help desk operators can view specialist details
and browse through them while adding new records or reviewing pre-existing problems.
This form was developed on the basis of the caller details and specialist tables.
Adding Buttons
For the “Add new” button, the command box was dropped down from the tools in design view,
following with formatting to match the theme and then a macro was embedded to take the user
to the last page on the form, where they can enter a new record based on new calls.
Similar steps were taken for the “Next” and “Previous” buttons.
Additionally, it was determined that a “search problem type” dropdown menu would make it
faster and more reliable to filter problems. This would also prevent errors that could potentially
occur while typing it in a search box. This is why this was also added through the combo box
from design view tools.
Buttons were added in a similar manner throughout all of the forms in the database. To avoid
redundancy, the descriptions won’t be repeated, as well as screenshots of identical “next” and
“previous” buttons but screenshots of each unique button will be attached.
Form 2: Specialists
This form was created for the purpose of allowing help desk operators to review the information
of each specialist i.e essentially get a profile of their key attributes and problems they are
working on or have worked on. An “Email” button is also included so a pdf of open specialist
cases can be shared with a supervisor or with the specialist themselves if they want to track
their own performance.
The “Email” button extracts data from the “Open Problems” query.
Email Report Button
Form 3: Resolved Problems
Based on the closed problems query, this form will let help desk operators easily view specialist
problems which have been resolved.
Form 4: Problems by Employee:
Based on the Problems by Employees query and Problems subform, this form lets help desk
operators view the problems that each individual employee is dealing with.
Form 5: Main Menu Form

The main menu form is a dashboard of sorts which was created for the purpose of making it
easy for help desk operators to navigate the database. Each button is linked to an important
section of a database (query, form, or report) or external documentation files, which are saved
in a database folder (this will be shared with all of the help desk department).
To ensure that the form automatically opens when the database is launched, it was set as the
“display form” of the database.
The linking of the buttons has been done through hyperlinks and embedded macros.
Similarly, the rest of the buttons were linked to their relevant pages or files.
Form 6: Equipment with Problems
Based on the “Devices with Problems” query, this form was created for the purpose of allowing
help desk operators to easily browse through the devices with logged problems that are in need
of specialist attention.
Developing and Designing Reports

In Microsoft Access, reports are used for the purpose of presenting relevant data from tables,
queries, forms in a neatly formatted and organized manner, mainly for printing, presenting and
viewing purposes. The layout of forms below is based on the interface design drafted in the
design phase. Additionally, “print” button is added which directly opens print preview on-click.
Report 1: Employees’ Problems

This report displays each employee’s individual problems altogether, based on the “Problems by
Employees” query.
Similarly, print buttons were added for the other reports.
Report 2: Monthly Resolution Report
For the purpose of keeping progress checks on the performance of specialists and help desk
operators, a monthly problem resolution report was created on the basis of the “Closed
Problems” query. The presents resolution time by month.
Report 3: Open Problems

Based on the “open problems” query, this report was created for the purpose of presenting a
count of currently open problems and the various names of the specialists dealing with them.
Specialists’ names are repeated if they are dealing with multiple open problems at once.
Security and Maintenance Implementation
Security
Security is one of the system requirements by Dubai Properties. In order to adhere to it, the
database was password encrypted, securing it significantly and preventing the database from
being accessed by unauthorised users who are not a part of the help desk department. All
members of the help desk department will receive the database password: #Real2024.
Additionally, enforcing access restriction to the database also complies with the principle of least
privilege whereby one is granted access level as per the requirements for their roles and
responsibility. Such a step raises data integrity and confidentiality level as well as the
compliance with the regulatory requirements (concerning access level and data protection).
In essence, securely encrypting the database itself with a strong password, then limiting its
visibility to those who should be able to access it, is a good security measure for the exclusive
custody of sensitive information as well as the upholding of Dubai Properties security needs.
Maintenance
Maintenance of the database is important for the future when Dubai Properties scales up and
expands, as well as in the present for the purpose of avoiding data loss or corruption.
For the sake of maintenance, a backup of the database was saved.
Since the backups are saved with dates, it can be made a policy to save weekly backups of the
database.
Back-ups at this frequency will guarantee that when there is a hardware failure or any other
unforeseen circumstances, the most recent version of the database will be available for
recovery. This provides the safety net for a situation where data loss or corruption might occur.
Additionally, this maintenance approach might also help Dubai Properties for documentation
purposes of their internal processes.
Testing
Test Plan
Now that the database solution has been developed and designed, it will be put to the test
through the test plan that has been designed below, covering some of Dubai Properties' user
and system requirements.
Test No. Requirement Test Action Expected Outcome

Addressed
1 User-friendly Click on closed When clicked on, the

Interface problems to check button should lead to
them through the the resolved
main menu problems form
2 Efficient Query Use the caller details It should be recorded

Logging form to log a new IT in the main caller
query details table
3 Problem The newly added The newly added

Categorization problem category problem category
should be available in should be available
the problem type and filter to the
dropdown menu relevant problem
case
4 Reliability Enter an incorrect Incorrect serial

serial number to test number must be
the reliability of the rejected
database
5 Security Attempt to access Incorrect password

database with message
incorrect password
6 Caller Information Search for a caller's Caller information

Retrieval information using should be retrieved
their ID number
Tests Execution
Screenshots of each test being carried out are attached below. Each outcome and result will be
added to the test plan table.
Test 1: Navigating Main Menu to Resolved Problems

Test 2: Logging a new IT query
Test 3: Adding and Searching a New Problem Category
Test 4: Entering Incorrect Serial Number
Test 5: Entering Incorrect Database Password

Test 6: Search for Caller Information Using their ID
Error: query or form available to achieve this type of search or filtration

Tests Results
Test No. Requirement Test Action Expected Actual Pass or Fail

Addressed Outcome Outcome
1 User-friendly Click on When clicked The button Pass

Interface closed on, the button led to the
problems to should lead resolved
check them to the problems
through the resolved form
main menu problems
form
2 Efficient Use the caller It should be The new IT Pass

Query details form recorded in query was
Logging to log a new the main recorded in
IT query caller details the caller
table details table
3 Problem Search a The newly The new Pass

Categorizatio newly added problem was
n categorized problem available as a
problem category filtering
through the should be option in the
drop down on available in problem type
the welcome the problem dropdown
form type
dropdown
menu
4 Reliability Enter an Incorrect Incorrect Fail

incorrect serial number serial number
serial number must be was accepted
to test the rejected and recorded
reliability of
the database
5 Security Attempt to Invalid Invalid Pass

access password password
database with message message
incorrect
password
6 Caller Search for a Caller Button not Fail

Information caller's information available due
Retrieval information should be to no such
using their ID retrieved query or form
number
Assessment of Testing
Out of the six tests, two passed and four failed, which shows that the database system is
reliable but also has notable areas for improvements. Now, each test will be assessed
individually, going over its strength, weakness, overall evaluation and an explanation of the test
data that was used.
Test 1: User Friendly Interface
1. Strength: The test was successful in verifying the expected behavior of the interface
(namely the main menu), showing that users will be able to navigate from the main menu
to the resolved problems form easily.
2. Weakness: Although the test appears to be valid, it can be said that it isn’t
comprehensive enough. More similar interface tests can be added.
3. Overall Assessment: The test was effective in validating Dubai Properties’ user-friendly
interface requirement, showing that the help desk operators are going to be having an
overall positive user experience.
4. Explanation of Test Data Used: The test used typical user behavior, simulating the
action of a user clicking on a button on the main menu form, for the purpose of
accessing a relevant form. This matches with the user requirement of an interface that is
user-friendly and easy to navigate, proving a good level of accessibility.
Test 2: Logging IT Queries Efficiently
1. Strength: The test has success in confirming that new IT queries are being logged
effectively in the database through the main caller details form, serving its primary
purpose.
2. Weakness: The scope of this test case was a bit limited since the test case only
included problem details without a resolution update. In future testing, resolution updates
will also be tested in the main caller details form.
3. Overall Assessment: The test successfully verified the functioning of query logging
through the main caller details form, making sure that IT queries are accurately recorded
in the database, being reflected in the relevant table after being added through the form.
4. Explanation of Test Data Used: The test involved inputting sample IT query data into
the caller details form which was the following: relevant ID numbers (short text), names
of problem-affected employee, help desk operator and assigned specialist (short text),
time of call (date/time), problem type (short text) and problem description (long text).
This is successful in mimicking real-world scenarios of query logging and satisfying
Dubai Properties’ user requirement of efficiency in IT queries logging.
Test 3: Problem Categorization
1. Strength: This test showed that the problem categories just added are present in the
problem selection dropdown menu, thus, improving how well the problems are being
categorized and maintaining a comprehensive list of problem types.
2. Weakness: Other preexisting problem categories were not tested in terms of how
effectively they filtered problem cases.
3. Overall Assessment: The verification of this feature of quickly categorizing and filtering
problem types, has led to the fact that the help desk team stays unburdened, being able
manage problems easily, as well as satisfying Dubai Properties’ user requirement of
problem categorization.
4. Explanation of Test Data Used: The test data consisted of the introduction of a new
problem category (short text) and then trying to pick it from a drop down box, which is a
common step in typical problem classifications.
Test 4: Reliability
1. Strength: The test which was conducted to check the accuracy of the system did this by
simulating the problem of an invalid input in the serial number column of the equipment
table. It successfully contributed to finding out that due to the flawed validation rule “Like
SN*” , there are no restrictions on characters displayed after “SN”, for example,
containing a combination of letters and symbols instead of the required numeric digits.
2. Weakness: A single invalid input has a huge limitation. A broader data set that will
include more examples should be implemented.
3. Overall Assessment: The test spotted a data validation error that resulted from the
presence of a flaw in the system's validation rules. In this way, Dubai Properties’ system
requirement of reliability was addressed.
4. Explanation of Test Data Used: The test involved inputting an incorrect serial number,
containing letters following the “SN” code instead of numeric digits, representing
common cases where users may make mistakes while entering data.
Test 5: Security
1. Strength: The test allowed to verify the correctness of the security function which was
implemented for the purpose of blocking unauthorized access.
2. Weakness: The strength of the password itself was not tested, or how quickly it can be
cracked through a simple brute force attack.
3. Overall Assessment: Through this test, the security system underwent a verification
process that ultimately confirmed that the database could only be accessed by
authorized users holding the required encryption key. This addresses Dubai Properties’
system requirement of security, showing how the current database is successful in
meeting it.
4. Explanation of Test Data Used: The test involved putting in an incorrect password, one
that is as not "#Real2024", simulating a situation that could be loosely connected to a
security breach.
Test 6: Retrieving Caller Information
1. Strength: The test was designed to check the system's capability of finding all key caller
details just through the Call ID number, successfully showing a system defect through its
failure during the attempt to execute it.
2. Weakness: Other ways for caller information to be viewed like simply browsing through
the caller details form (which already contains all caller information) is not considered,
casting a significant doubt on the accuracy of this test, and whether it truly is valid.
3. Overall Assessment: Overall, the test has highlighted the absence of a caller
information retrieval feature, indicating a need for further development of a relevant form
and button which lets the help desk operators quickly look up caller details through
entering or selecting the call ID. This is one of Dubai Properties’ user requirements.
However, it can be argued that this requirement is already being fulfilled due to how the
main caller form shows all caller details. Perhaps, the call ID filtration is redundant in
relation to the user requirement.
4. Explanation of Test Data Used: The test involved trying to search for caller information
using a known ID number (short text), representing a common user action in a help desk
scenario. However, no site to input this data was found, highlighting the system flaw.
Tests Classification: White Box and Black Box

The tests done can be classified into the categories of white box testing and black box testing.
1. White box tests:

These tests involve testing a system with knowledge and consideration of its internal
process and working. Oftentimes, this involves the back-end.
2. Black box tests:

These tests involve testing a system in terms by interacting with the interface through
clicking and exchanging surface-level inputs and outputs without
knowledge/consideration of the internal processes. Most of the time, this involves front-
end procedures.
The six tests executed can be sorted into the white box and black box categories depending on
the scope and considerations of their testing.
Test No. Test Description Testing Method
1 Navigating from Main Menu Black Box

to Resolved Problems
2 Logging a new IT query Black Box
3 Adding and Searching a New White Box

Problem Category
4 Entering Incorrect Serial White Box

Number
5 Entering Incorrect Database Black Box
Password
6 Search for Caller Information Black Box

Using their ID
It can be observed that most of the tests are black box, mainly involving surface level
interactions and input-output-exchange. More white box tests for the help desk specialist can
be added. However for the help desk operator, the testing seems sufficient.
Evaluation of the Database Solution

The evaluation below looks into the suitability of the database solution that has been developed
for Dubai Properties so far, the one which takes into account both user and system
requirements. A comprehensive technical assessment of the database solution including its
interface design, query capabilities, security mechanisms, and scalability are done to provide
detailed insights of the solution’s pros and cons.
1. User-Friendly Interface:
Advantages:
The interface design is easy to use and understand, closely resembling other Microsoft Office
applications, thus, making the learning curve much smaller for users.
The handy design tools and clear navigation options enhance usability and make it far easier to
be used by the help desk operator.
Disadvantages:
While the interface is user-friendly, some operators might still require training to fully use all
features. Although, they will have support from the specialist at the help desk. It is possible that
this slight disadvantage will be compensated for by Dubai Properties’ organizational setup.
There is also some inconsistency in design elements like font types and sizes, even though the
colors, logo and overall theme remains consistent.
2. Efficient Query Logging:
Advantages:
The Welcome Form of the database is serving the purpose of quickly logging new IT queries,
and making it more effective for help desk operators to enter data into the database.
As for common actions, buttons have been added faster to make it easier to log IT queries, and
to see various related tables and queries.
Disadvantages:
The limited validation rules make it possible for help desk operators to make errors while they
are entering data, thus, risking the accuracy and reliability of the system.
3. Problem Categorization:
Advantages:
Having a dropdown menu for filtering different types of problems improves browsing the speed
of looking up relevant information, since it is now able to be accessed just based on a single
click, thus, increasing both speed and time efficiency. It also prevents errors that could occur
while help desk operators are typing in a search box for problem types, so opting for a
dropdown menu is a far better choice.
Disadvantages:
There is limited flexibility. Additionally, it hasn’t been tested if the problem type drop menus can
filter multiple problems belonging to the same category, raising concerns of only having limited
functionality, as it may not be able to display multiple problems belonging to the same problem
category.
4. Caller Information Retrieval:
Advantages:
Through the main caller details form, help desk operators can browse through information about
all of the callers.
Disadvantages:
There isn’t a way to search up a specific caller by name, requiring the help desk operators to do
needless clicking and scrolling until they get to the right person. Even though the form (and the
query it depends on) have made the data easily viewable in one location, the actions required to
get to it can be reduced through adding search-based filtration.
5. Equipment Information Retrieval:
Advantages:
Through the forms and queries displaying the data of equipment with problems, as well
separate ones for each piece of equipment, help desk operators will be able to easily retrieve
information about equipment, which will speed up the troubleshooting process.
Disadvantages:
Relying on accurate data entry for equipment details may introduce errors if they are not
properly validated, like how previous testing uncovered insufficient data validation for serial
numbers of equipment.
6. Problem Referral System:
Advantages:
When help desk operators are logging new IT queries and assigning specialists to problems,
they will be doing this through the main caller form, which also includes a subform of specialists
and depicts their areas of specialty. This makes it much easier to assign problems to a specific
specialist, depending on the nature of the problem that a particular caller is dealing with and
reporting.
Disadvantages:
Manually assigning specialists can create human errors and also may cause an unequal
distribution of workload, burdening some specialists.
7. Specialist Performance:
Advantages:
Specialist cases viewed through various types of forms and queries, as well as monthly
performance reports help help desk agents to share this information with their supervisors,
allowing specialists’ performance to be evaluated properly.
Disadvantages:
A measure for callers feedback can be added since only assessing specialist efficiency based
on the open and close cases can not be comprehensive enough. Fundamentally, caller
satisfaction and effective problem resolution are the most significant metrics.
8. Resolution Recording:
Advantages:
Detailed accounting of resolution processes particularly the date helps with easy recording of
the data for accuracy and future reference.
Disadvantages:
Just recording the day of resolution is not enough, resolution timestamps can be added as well.
9. Security
Advantages:
Encryption i.e access restrictions of the database through a strong password containing
numbers, letters and symbols, provides a good level of security and ensures conformance to
regulatory requirements among others.
Disadvantages:
A single password can be broken or used improperly by an unscrupulous attacker through
password breaches or unauthorized access.
10. Scalability
Advantages:
The scalability of the database allows the system to add more elements as and when required
and to increase the volume of the associated queries.
Disadvantages:
Being restricted in scalability compared to enterprise level DBMS solutions may become a
problem when data volume tends to grow, requiring the change to another database
management system.
11. Reliability
Advantages:
Referential integrity is enforced in records and even though the data validation rules can be
made stricter, they still are currently enforced and limit erroneous data entry to an extent. When
one record is added or updated through a single form, query or table, the changes are reflected
in all records throughout the database.
Disadvantages:
As mentioned before, the data validation can be significantly improved.
Overall Evaluation
The database produced for Dubai Properties has advantages including user friendly layout,
effective logging query feature, quick categorization of the problem, among many others. It
mainly meets the given requirements but some gaps can be filled, like the security measures
need to be advanced and data validation rules must be made stricter. Scalability is something
that should also be monitored well. In the end, though successful, increasing amounts of these
improvements are still required for total effectiveness.
Improvement Suggestions
1. Stricter Data Validation Rules:

Use validation rules that are very strict for unique identifiers like serial numbers,
equipment IDs, etc. Identifiers names with spaces or special characters should not be
accepted. Check characters against compliance upon entry.
2. User-Based Permissions: Set up tiered access that will serve to block the disclosure
of confidential data, while, at the same time, the overall features and functions are being
controlled.
3. Action Queries: Develop actions queries which point to where the information needed
to manipulate the data is stored. This will speed up processes by a large margin.
4. Enhanced Error Handling: Currently, only error messages for invalid data entry exist
in the database. More error handling mechanisms can be added which guide the users
how they can move around to find a solution when they get stuck.
5. Performance Optimization: Do performance tuning in order to allow the database to

work at the best capacity and reduce its response time.
Documentation
Documentation is of vital importance since it gives a deeper look into the database, recording its
back-end and front-end processes, which will be essential for help desk operators and for the
help desk specialist to consult while they are getting used to the developed database. They will
also be required to maintain its upkeep for future help desk team members.
User Documentation
By offering instructions for using the database and completing activities quickly, user
documentation lowers the need for help and increases user satisfaction. The help desk operator
will find this useful.
1. Flowchart
This gives a brief, step-by-step overview of navigating from the main menu to important queries
and forms.
2. Video Tutorial
This video tutorial acts as the pathway through which the database interface is explored, and
users are given instructions on how to operate its critical functions (video attached in the
documentation folder, linked on the main menu form).
Technical Documentation
Technical documentation assists administrators in the creation and management of the
database infrastructure, performing routine maintenance tasks and the troubleshooting of
equipment problems. This will be especially helpful for the help desk specialist.
1. Data Dictionary
This database data dictionary shows the data structures within the database, their organization
(in terms of primary and foreign keys), the definitions of each element, making it easier for
operational duties regarding data management to be performed.
2. Data Flow Diagram - Level 0

This high-level data flow diagram of Level 0, visually depicts the flow of information inside the
database, indicating the correspondence between the external components and the major
processes, thus making the system conceptualisation and analysis process a lot easier.
3. Entity Relationship Diagram (ERD)

This diagram provides a visual of the structure of the database and the relationship between
entities and their attributes, as well as between the entities themselves. Briefly, this will help to
understand how the database organisation is done.
How the Database Works

The current database works through both the backend and frontend processes; thus, the data
management and user interaction become efficient.
Backend Processes:
1. Data Storage: Gives the information back in tables by using Microsoft Access.
2. Query Processing: Handles getting data and modifying it using SQL queries.
3. Validation and Enforcement: Drives data integrity by means of data validation and
referential integrity.
Frontend Processes:
1. User Interface: Provides a framework to be implemented by users.
2. Data Entry and Retrieval: It provides an interface that enables its user to enter and
retrieve data conveniently.
3. Query Execution: Users can execute a system coming with prepared queries to acquire
desired details.
4. Navigation and Workflow: Provides users with simple and clear tasks and tasks flows.
Evaluation for Continuous Improvement and Effectiveness

The development of the database system is also backed by suggestions and strategies to
ensure that its efficiency will be sustained, as well as improved. The improvements needed are
evaluated below, seeking to maintain and advance the effectiveness of the solution.
1. Integration for Artificial Intelligence (AI):

For Dubai Properties, the integration of AI features within the database system will offer
automation for routine activities like problem classification and specialist assignment. AI
algorithms treat the data in such a way that the patterns and trends are well identified,
giving insights that are useful in taking decisions and optimizing the processes instead of
relying on the manual and cognitive labor of help desk operators, as well as reducing the
margin of human error.
2. Cloud-Based Data Backups:

Although the database will be backed up locally by the help desk operators due to Ms
Access’s backup feature, there is a risk of data loss in the case of hardware failure or
damage. Cloud-based backups will ensure the storage of Dubai Properties' critical data
off-site in a secure manner, deploying any cloud-based platforms for the database.
Accordingly, this will ensure that there will be minimized data loss risk that may emanate
from hardware crashes or any other disastrous occurrences. Cloud-based backups offer
an enhanced resilience and data protection for Dubai Properties through ensuring there
are always redundant copies of the database in remote sites.
3. Using Ms Access’s Compact and Repair Database Tool:

Currently, maintenance of the database relies solely on ensuring data consistency and
reliability, which is not quite sufficient. The use of the Compact and Repair Database tool
will enforce a good practice for maintaining the database towards achieving peak
performance of the database and data integrity, since it minimizes unused storage space
and prevents, often even fixes, corrupted data.
This will, in turn, avoid data corruption and make sure that compacting and repairing are
done frequently on the database. Scheduling of the jobs and regular monitoring,
however, is one thing that should be put in place for one to have the best output from the
feature.
4. Automating Specialist Assignment on Problems:

An algorithm can account much better for the specialty of each specialist, as well their
current workload, free from human bias. Hence, automated specialist assignment will
increase operational efficiency by optimally allocating resources in Dubai Properties. It
will reduce the workload of the help desk operators in terms of manual work. This will, in
return, help to resolve the problem quickly and improve caller satisfaction from the
intelligent assignment of right specialists. However, in that case, due attention should be
paid to careful planning and testing, taking into account that the automated assignment
process has the required accuracy and fairness in it.
Improvement Advantages Disadvantages
Artificial Intelligence (AI) 1. Automates routine tasks 1. Requires initial

Integration 2. Enhances decision- development
making 2. Ensuring accuracy
3. Reduces manual effort can be challenging
Cloud-Based Backups 1. Minimizes data loss 1. Dependence on

risks internet connectivity
2. Enhances resilience 2. Potential costs and
privacy concerns
Ms Access Compact and 1. Maintains data integrity 1. User-initiated

Repair Tool 2. Improves database maintenance
performance required
2. Potential for data
loss
Automated Specialist 1. Optimizes resource 1. Requires careful

Assignment allocation planning and testing
2. Improves problem 2. Ongoing monitoring
resolution needed for accuracy
Finally, each one of the improvements, no matter how exciting it is, must be looked at in the
context of both its advantages and disadvantages, with effort being made to minimize the
difficulties, so as to realize the best result in enriching Dubai Properties' database system.
References
1. (2019) What are data types? [Preprint]. doi:10.4135/9781529687644.
2. Codd, E.F. (1970) ‘A relational model of data for large shared data banks’,
Communications of the ACM, 13(6), pp. 377–387. doi:10.1145/362384.362685.
3. Elmasri, R. (2018) ‘Data Management Fundamentals: Database Management System’,
Encyclopedia of Database Systems, pp. 784–785. doi:10.1007/978-1-4614-8265-
9_80674.
4. Ganti, V., Gehrke, J. and Ramakrishnan, R. (1999) ‘A framework for measuring changes
in data characteristics’, Proceedings of the eighteenth ACM SIGMOD-SIGACT-SIGART
symposium on Principles of database systems [Preprint]. doi:10.1145/303976.303989.
5. Linton, M.A. (1983) Queries and views of programs using a relational database system
[Preprint]. doi:10.21236/ada603469.
6. Verhofstad, J.S. (1978) ‘Recovery techniques for database systems’, ACM Computing
Surveys, 10(2), pp. 167–195. doi:10.1145/356725.356730.
7. Weldon, J.-L. (1975) ‘Review of “an introduction to database systems” by C. J. Date.
Addison-Wesley Publishing Co. 1975.’, ACM SIGMOD Record, 7(3–4), pp. 53–54.
doi:10.1145/984403.984407.
8. Özsu, M.T. and Valduriez, P. (2011) ‘Distributed Object Database Management’,
Principles of Distributed Database Systems, Third Edition, pp. 551–609.
doi:10.1007/978-1-4419-8834-8_15.
9. ‘Database control’ (2010) Distributed Database Management Systems, pp. 83–109.
doi:10.1002/9780470602379.ch3.
10. ‘Introduction to logical database design’ (2005) Foundations of Database Design
[Preprint]. doi:10.1201/9780203505168.ch1.
Student Declaration Form

Unit 4 Database Design and Development 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 4 Database Design and Development 4

Uploaded by

Copyright:

Available Formats

UNIT 4 DATABASE DESIGN AND DEVELOPMENT

ASSIGNMENT: Design and development of a database system

Databases: Relational and Non-Relational

4. Structured Query Language (SQL): Working with a relational database is performed

1. Business Applications: Relational databases are considered quite well-suited for

3. Education Management Systems:

4. Human Resources Systems:

2. Scalability: NoSQL databases are designed to scale horizontally, accommodating

4. Eventual Consistency: Some NoSQL databases prioritize scalability over strict

3. Scalable Web Applications: NoSQL databases are commonly used in web

4. Agile Development: Non-relational databases that adapt to varying development

Use Case Relational Database Non-Relational Database

E-commerce Transactions Amazon, eBay MongoDB (used by Alibaba

Social Media Platforms Facebook (MySQL, Cassandra (used by

Financial Systems JPMorgan Chase (Oracle), Apache HBase (used by

Content Management WordPress (MySQL), Drupal MongoDB (used by Forbes

Aspect Relational Databases Non-Relational Databases

Scalability Scaling up can be challenging Scaling up is often easier,

Databases Across Different Sectors

b. Research and Analysis: Supporting medical research by giving structured

b. Risk Management: Enabling historical analysis of selected financial data.

b. Research Databases: Organizing and storing scholarly articles.

b. Customer Relationship Management (CRM): Storing customer information,

b. Quality Control: Storing data related to product inspections and testing.

b. Network Management: Telecommunication companies use databases to monitor

Database System for Dubai Properties

2. Efficient Query Logging:

4. Caller Information Retrieval:

5. Equipment Information Retrieval:

6. Problem Referral System:

4. Backup and Recovery:

5. User Authentication and Authorization:

7. Documentation and Training:

This will serve the following purposes:

1. Clarifying Data Relationships:

2. Identifying and Displaying Key Information:

3. Helping with Data Integrity:

4. Making Collaboration Easier:

In accordance with Dubai Properties’ user requirements of a user-friendly and interactive

User Input Design Output Design Validation Test

Problem Enter category Gets stored in Must show in Enter a new

Resolution Enter resolution Gets stored in Resolution Enter a

1. Arranged in a tabular manner

1. Data will be arranged in a tabular manner

Data Normalisation (1NF, 2NF and 3NF)

Initially, the raw data existed unstructured and unorganized in a spreadsheet.

Table 1: Caller Details

Table 2: Employee Details

Updated Employee Details Table

Updated Specialist Table

Data Types and Field Sizes for Caller Details Table

6. TimeOfCall (Date/Time, NA): Date/Time data type is appropriate for storing

Data Types and Field Sizes for the Equipment Table

Data Types and Field Sizes for the Specialist Table

Data Types and Field Sizes for the Problems Table

1. Entity Relationship Diagrams (ERDS):

2. Normalization (2NF and 3NF):

Areas for Improvement

4. Security Considerations: Passwords and administrator privileges could be added in

Database Development Phase

Considering and Choosing Database Platform

1. Compatibility with Existing Infrastructure: Microsoft Access is an integral part of the

3. Cost-Effectiveness: Being more cost-effective than enterprise-level DBMS, such as SQL

Caller Details Table