Tải bản đầy đủ (.doc) (24 trang)

Assignment 1 Database (1622) Greenwich

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (6.34 MB, 24 trang )

ASSIGNMENT 1 FRONT SHEET
Qualification

TEC Level 5 HND Diploma in Computing

Unit number and title

Unit 04: Database Design & Development

Submission date

Date Received 1st submission

Re-submission Date

Date Received 2nd submission

Student Name

Student ID

Class

Assessor name

Student declaration
I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that
making a false declaration is a form of malpractice.
Student’s signature
Grading grid


P1

M1

D1


 Resubmission Feedback:

 Summative Feedback:

2.1

Grade:
Signature & Date:

Assessor Signature:

Date:


Table of Contents
Introduction........................................................................................................................................................................... 1
1. User and system requirement....................................................................................................................................... 1
1. 1. Overview about the problem............................................................................................................................... 1
1.2. Requirement of the application............................................................................................................................ 1
1.2.1. Process of library............................................................................................................................................. 1
1.2.2. Requirement...................................................................................................................................................... 2
1.2.3. Input/Output...................................................................................................................................................... 2
2. Design the relational database system........................................................................................................................ 4

2.1. Analyse the requirement........................................................................................................................................ 4
2.2. Database design with explanations..................................................................................................................... 5
2.3. Normalization of the database.............................................................................................................................. 6
2.4. List of tables............................................................................................................................................................. 7
2.5. Data validation....................................................................................................................................................... 12
2.6. Wireframe of the application.............................................................................................................................. 13
2.7. Evaluation............................................................................................................................................................... 18
2.7.1. Advantage........................................................................................................................................................ 18
2.7.2. Disadvantage.................................................................................................................................................. 19
2.7.3. Future development direction..................................................................................................................... 19
Conclusion...................................................................................................................................................................... 20
Reference list.................................................................................................................................................................. 20


Introduction
Today, digital transformation technology is becoming a trend for many fields, especially
business management models. While offline libraries are gradually becoming obsolete, online
libraries are a good choice to develop this format. In this assignment, the relational database for
an online library of FPT University is analyzed and built according to the user's requirements,
functions, and necessary standards.
1. User and system requirement
1. 1. Overview about the problem
Currently, all universities have libraries but these offline libraries have become obsolete in the
age of technology, it has many major defects that cause inconvenience to users. First, the
reader/user has to go to the library at a fixed location, which takes a long time. Next, the search
and borrowing procedures are also complicated because the library has a lot of readers and a
huge number of books. The management of the library is a dilemma, it is difficult for the
administrator to know the
status of all the books and the
borrowers. In addition, the

Covid-19 epidemic is the
biggest cause, it makes the
library unable
to operate,
which wastes resources and
staff.
Therefore,
FPT
University needs a database to
build an online library system
to
solve the above problems.

Figure 1: The offline library cannot operate due to the epidemic
1.2. Requirement of the
application
1.2.1. Process of library
After consulting with the library manager of FPT University, the system needs to perform some
necessary work. Firstly, each user will have a separate account and password for the same role.
Book information such as title, author need to be added to the system because the number of
books is always added new every day. Employees will also know the status of their quantities
and their prices. Record all the information on the loan slip, their details so that they can be
checked again if necessary. Know the borrower information, repayment date and status of the
books paid. Each person in a loan can only borrow up to 3 books and the return period is
within 1 month; when returning the book, it will check and record the condition of the book.
1


1.2.2. Requirement
To make the requirements easy to understand, I will use the User Story format below to

describe the requirements.
As a library manager, I wanted a system that could perform a number of important actions so that
they help me manage the library easily. The most basic operations are entering, looking up
complete information of books as well as their status, recording book loan slip with loan details,
viewing reader information, can add, edit, delete information of book, last name, see the status of
the returned book. View statistics of readers' borrowing, paying and interest activities.

As a reader, I would like to edit and view personal information along with account password,
some information such as loan date, employee name, book title should be clear so as not to be
confused about the details. this information.
1.2.3. Input/Output
The input/output to the system will be the data of information of readers, staffs, and books, etc.

Figure 2: Information of books

Figure 3: Information of staf
2


Figure 4: Information of member

Figure 5: Login

3


Figure 6: Information of borrowing
2. Design the relational database system
2.1. Analyse the requirement
In order to facilitate the construction of the database, and the system, the requirements will be

clearly analyzed.
Regarding login, the information to use is account (gmail), ID, password and Role. Regarding
the information of the book, some of the main information to display is the title of the book,
the date of publication, the publisher, the price, the number. Furthermore, the author's
information must clearly display the first and last name.
Regarding member information, readers will have some information to identify that is ID, last
name, first name; Date of Birth is also an important information for age statistics, Phone
Number is an indispensable field, and Address. Regarding Staff, ID is as important as member,
in addition Full name will appear in the database. Regarding the loan, it will include
Membership Number, Employee, Borrow Code, Borrowing Date and Repayment Date.
About BorrowDetail, ID is the count, IDborrow helps identify the borrow code because there
are many different loan vouchers, Quantity is the number of books borrowed (maximum 3
books), and 3 Titles of 3 books. Regarding ReturnBook, ID is the count, IDborrow helps to
identify the borrowed code, QuantityReturn is the number of books returned, Status is the
status of the book is good or bad and Note to record notes if any.
In terms of entities, it has Login, Member, Staff, Borrow, Author, Book, BorrowDetail, and
ReturnBook.

4


2.2. Database design with explanations
Logical design (ERD) of database:

Figure 7: Entity relationship diagram
Entities are joined by 1-to-many association because the same information can be used more
than once and 1-to-1 association, for example, between Login entity and Member, Staff.
The book entity should have fields that record detailed and important information for easy
searching and statistics such as book title, author name, publication date, total number of books
in the library and its price. The foreign key is set in the IDAuthor field to refer to the Author

table. The Author entity only includes the ID as the primary key and two other fields,
Firstname and Lastname, to identify the author's name.
The Login entity needs Gmail for each user to log in with the password in the profile along with
the role and ID of the staff or member. The primary key is Gmail, the foreign key includes the
IDstaff and IDmember fields, depending on the role that refer to the Member or Staff entity.

For Staff, the basic data is the name, the staff code for identification purposes, the ID is set as
the primary key. For Members, the ID is also set as the primary key, in addition to information
that needs detailed information, add an address field, a phone number for easy contact; The
date of birth field makes statistics easy.

5


Borrowing entity, some basic information is the fields of member code, employee, borrowed
date, return date for easier management. IDborrow is the primary key, IDstaff and IDmember
are set as secondary keys to refer to the Staff and Member entities for the purpose of getting the
ID.
Entity BorrowDetail has a primary key of ID to distinguish the data, IDborrow is a foreign key
that refers to entity Borrow to get information of borrowed tickets, Quantity is the borrowed
quantity (up to 3), 3 foreign keys Title from 1 up to 3 references to the Book entity to get the
Title of the book, up to 3 books.
The ReturnBook entity has a primary key that is ID to distinguish the data, IDborrow is a foreign
key that refers to the Borrow entity to get information about the loan slips, QuantityReturn is the
quantity returned, Status is the status of the returned book, and Note field if required.

2.3. Normalization of the database
Normalization is a database design method that starts with a look at the links between attributes
(known as functional dependencies) (Connolly and Begg, 2015). In normalization, a number of
tests are performed to identify the best grouping for these qualities and, as a result, an

appropriate set of relations to satisfy the user's data needs.
1NF Normalization:
At Borrow:
Key -> IDborrow
Each record has 1 value and is unique. As a result, Borrow reached 1NF normalization, the
same happened for all the other entities so they all met 1NF normalization.
2NF Normalization:
At Member:
Primary Key -> ID
ID -> Firstname
ID -> Lastname
ID -> DoB
ID -> Phone number
ID -> Address
The attribute fields are all dependent on the primary key. The same goes for the rest of the
entities. Entities have been separated to depend entirely on the primary key, using foreign keys
to preserve data integrity and the association between entities.
The above condition and the condition of reaching 1NF normalization, entities have achieved
2NF normalization.
3NF Normalization:
At Book:
Primary Key ->Title
6


Title ->IDAuthor
Title-> Publication date
Title -> PublishingHouse
Title -> Publisher
Title -> Quantity

Title -> Cost
All non-primary key fields depend directly on the primary key, not transitively; The rest of the
entities are similar. Combined with achieving 2NF normalization, all entities achieve 3NF
normalization.
2.4. List of tables
Table 1: Entity Author (physical design)
Column Name

Data type

ID

Int

Firstname

nvarchar(30)

Lastname

nvarchar(30)

Allow nulls

Table 2: Author
ID

Firstname

Lastname


123

Bill

Gates

124

Michos

Keqing

Table 3: Entity Book (physical design)
Column Name

Data type

Title

nvarchar(50)

IDAuthor

Int

Publication year

Int


PublishingHouse

Varchar(50)

Allow nulls

X

7


Publisher

Vachar(20)

Quantity

Int

Cost

Int

X

X

Table 4: Book
Title


IDAuthor

Publication
year

PublishingHouse Publisher

Quantity Cost

Business

123

2015

Pearson

Bill Gates

5

999000

Roll: Keqing
C3

124

2021


Pearson

Manh Tung

2

1000000

Table 5: Entity Staf (physical design)
Column Name

Data type

ID

Char(4)

Firstname

Nvarchar(50)

Lastname

Nvarchar(50)

Allow nulls

Table 6: Staf
ID


Firstname

Lastname

G111

Hoang

Long

G112

Hoang

Nam

Table 7: Entity Member (physical design)
Column Name

Data type

ID

Char(6)

Firstname

Nvarchar(30)

Allow nulls


8


Lastname

Nvarchar(30)

DoB

Date

PhoneNumber

Char(10)

Address

Nvarchar(50)

X

X

Table 8: Member
ID

Firstname

Lastname


DoB

PhoneNumber

Address

GCH001

Pham

Trong

1/1/2003

0213536732

null

GCH003

Nguyen

Nam

Null

0213536733

null


Table 9: Entity Borrow (physical design)
Column Name

Data type

IDborrow

Int

IDmember

Char(6)

IDstaff

Char(4)

Date of borrow

Date

Date of return

Date

Allow nulls

X


Table 10: Borrow
IDborrow IDmember IDstaff

Date of borrow

Date of return

1

GCH002

G111

12/6/2021

20/6/2021

2

GCH003

G112

10/6/2021

18/6/2021

9



Table 11: Entity Login (physical design)
Column Name

Data type

Gmail

Nvarchar(50)

IDmember

Char(6)

IDstaff

Char(4)

Role

Varchar(10)

Password

Varchar(10)

Allow nulls

Table 12: Table Login
Gmail


IDmember

IDstaff

Role

Password



GCH000

G111

Staff

12345



GCH001

G000

Member

12347

Table 13: Entity BorrowDetail
Column


Data type

Allow nulls

ID

Int

IDborrow

Int

Quantity

Int

Title1

Varchar(50)

Title2

Varchar(50)

X

Title3

Varchar(50)


X

10


Table 14: BorrowDetail
ID

IDborrow

Quantity

Title1

Title2

Title3

1

2

1

Business

null

null


Table 15: Entity ReturnBook
Column

Data type

ID

int

IDborrow

int

QuantityReturn

int

Status

Varchar(10)

Note

Varchar(50)

Allow nulls

X


Table 16: ReturnBook
ID

IDborrow

QuantityReturn

Status

Note

1

2

1

Good

null

11


2.5. Data validation
Data validation is simply understood as checking the input data is correct according to the
meaning of that data or not (Riolo, 1986). Here, the email will be checked according to the
school's email format so that the users are only students and employees of the school. Some
integer data will be formatted greater than 0; phone numbers are formatted as 10 numbers,
starting with '0' followed by numbers 0 through 9. Some date data is formatted smaller than the

current date so that no errors are encountered in statistics or calculations.
Table 17: Data validation of fields
Entity

Column Name

Data type

Login

Gmail

nvarchar(50)

like '%@%.edu.vn'

Role

Varchar(10)

in (‘Staff’, ‘Member’)

Book

Allow nulls

Quantity

Int


Cost

int

X

IDAuthor

Int

X

Publication year Year

Data Validation

>0

X

Like ‘[0-2][0-9][0-9][0-9]’
<= year(getdate())

Member

DoB

Date

PhoneNumber


Char(10)

X

< getdate()
Like ‘0[0-9][0-9][0-9][0-9][0-9][0-9]
[0-9][0-9][0-9]’

Borrow

BorrowDetail
ReturnBook

IDmember

Char(4)

X

Like ‘G_H[0-9][0-9][0-9]’

IDstaff

Char(4)

X

Like ‘G[0-9][0-9][0-9]’


Date of borrow

Date

Date of return

Date

Quantity

Int

>0 and <4

Status

Varchar(10)

In (‘Good’, ‘Bad’)

QuantityReturn

Varchar(10)

Between 1 and 3

< getdate()
X

>[Date of borrow]


12


2.6. Wireframe of the application
The system will have two main interfaces because there are two user roles, staff and reader.
For staffs, they can read, create, update, delete data about books, loan vouchers, personal
information, view reader information, and perform certain statistics about data in the database.
For readers, they can find, borrow books and edit personal information.

Figure 8: Login interface

Figure 9: Main interface for staf
13


Figure 10: Information of staf

Figure 11: CRUD (Create/Read/Update/Delete) information of book (part 1)

14


Figure 12: CRUD information of book (part 2)

Figure 13: View information of readers
15


Figure 14: CRUD borrowing


Figure 15: Borrow Detail

16


Figure 16: Return Book

Figure 17: Main interface for reader

17


Figure 18: Information of reader
2.7. Evaluation
The relational database for this library management system has basically been built. However,
it will have advantages and disadvantages, they will be evaluated through a number of factors
such as tools, design methods, results for users.
2.7.1. Advantage
During the logical and physical design of the relational database, the draft will be designed on the
SQL server so that it can be easily tested and checked. SQL server is a great application to design
and develop logical and physical relational databases for the system. Developers can use the tools
available on this application to develop a simple database, the lines of code are also simple, easy to
understand, and highly effective. Can be used on many platforms such as PC, laptop, phone, etc.
Can connect with many programming applications, and other support functions such as Security
are available. Information is easily queried with simple statements, it can also detect errors in the
code. ERD is designed using draw.io website, this is a good website that supports designing entities
with available templates, ensuring aesthetics and accuracy.
In terms of design method, entities and fields are created first. All are consistent with the
information of objects such as books, employees, and borrowers. Clear, consistent data types make

entering information easy, especially the simplicity of memory cells of different data types that
makes the information complete but doesn't waste a lot of memory. This is necessary because a
database will grow for a long time and the amount of data will increase over time, saving memory
is necessary. Entities are linked together by 1-to-many and 1-to-1 links along with primary and
foreign keys, making it easy to refer to information in other entities. Normalizing data according to
3 levels of normalization helps to prevent data from being redundant and without errors when
performing operations such as adding, editing, deleting, and updating. Data
18


validation helps to check whether the data is in the correct format of the manager, which makes
data management and statistics easy because the data format will be unified.
For users who are staff and managers, querying information is easy because the entities are
linked by primary and foreign keys. Moreover, the information at the table containing the
primary key cannot be deleted without deleting the information at the foreign key, in some
cases, this will prevent data from being lost. With the particularity of a library, information
about books and loan slips, readers will always be edited, added, updated, and managed easily
with the database. Information about entities, detailed fields for the characteristics of objects
are stored, so management and statistics become easy. The statistics will help the management
know the current status to build a development direction for the library, for example, based on
the loan card to know which books are borrowed the most, then buy more this genre books
belonging for the library. In the future, new properties will appear, updating them to the
database is not difficult. For readers, their information can be completely edited easily, they
can query information about books and loan slips. Security is an important issue, in this
database, each person will have a separate account and password using the email of FPT
University, so outsiders cannot use this system, it also assigns suitable roles to users. The
simple interface, easy to understand for new employees also plays an important role in the
management of this library system.
2.7.2. Disadvantage
Regarding the design tool, its biggest drawback is that the application runs quite slowly,

affecting the design.
Some disadvantages in the design approach are clearly pointed out. Some field data types make
data entry difficult, for example, the date data type requires the user to enter dates in the correct
order and using the correct symbols; The varchar/nvarchar type takes up memory because the
input will not fill the allocated memory. Normalization increases the number of entities and
increases the query time as well.
For the library manager, all the not-null configuration information must be entered for the
convenience of statistical operations and calculations later, however, a problem is raised that
there is a ratio small objects lack such information, this is a problem that has no optimal
solution. Entity fields are still incomplete, do not reflect all the data of an object, for example,
books have other important information such as edition, old or new, multiple authors, etc.
There is no decentralization between the main management and employees, the main manager
does not need to have data entry functions, but only controls, statistics, and calculates data.
2.7.3. Future development direction
In the future, when the database is expanded, creating more roles for users is necessary to
develop the system, some of the target audiences are non-FPT university readers, they are great
potentials. In addition, it is necessary to decentralize management and staff to improve the
management of the system, to do that, it is necessary to build the necessary entities along with
the appropriate fields for data management such as number of borrowers, number of times
borrowed, favorite books, etc. Add book fields like publication date, more authors, readers can
borrow more books. Upgrade existing database entities to provide more complete object
information. Finally, optimize data validation so that statistics and data entry become easy and
synchronized.
19


Conclusion
In this assignment, a relational database of the library is built based on the detailed
requirements of the users, they have been clearly analyzed about the entities and fields needed
for data management, the functional requirements of the users that are employees and readers .

After that, a relational database was built to meet those requirements, the data types, primary
keys, foreign keys used were explained in detail about usage and effects. To optimize and avoid
data redundancy, the normalization from 1NF to 3NF has been carried out and completed, data
validation helps to format the desired data type for the manager so that the data in the system
becomes synchronous. than. The physical designs have also been provided in detail. The
wireframes for the system have also been designed to suit the requirements of the users who
are the readers and the librarians. Finally, the advantages and disadvantages were given based
on the following factors: tools, design methods, and results for users; along with the direction
of future development.
Reference list
Connolly, T. and Begg, C., 2015. Database Systems: A Practical Approach to Design,
Implementation, and Management. 6th ed. Pearson, p.451.
Riolo, R., 1986. Introduction to Database Management Systems on MTS. p.24.

20

Powered by TCPDF (www.tcpdf.org)


Index of comments
2.1

Your report has an obvious frame! Very good!

You do all the required sections of the P, M D grade. However, the most critical part, your database design still
has errors. Errors have been noted in the report.
The evaluation (also) is not valid. Therefore, overall, only the highest mark can be graded as M.

Powered by TCPDF (www.tcpdf.org)




×