Advance Database

Assignment Scenario

By Mariyam Mahroosa (S1800051)

Table of Contents

ER-Modeling _________________________________________________ 2

Modeling and Normalization Process Discussion _____ 3

Extensions to the E-R diagram ____________________________ 4

SQL Queries and Example Statements ___________________ 5

Recreate model in MongoDB ______________________________ 7

Compare and Contrast Report _____________________________ 9

ER- Modeling
Below is the UML notated E-R diagram for the assignment scenario.
Modeling and Normalization Process
Discussion
In the UML model above, the entities, attributes and relationships are identified. For the first
normalization process (1NF), primary key for each table is identified. For the Visitor table, it is
v_no, which is the primary key or unique number saved for each customer to make it easier to
identify them. Name column is divided into name and surname so that there will be no multiple
items in the same column. For the Exhibition table, it is tit_id, which is the primary key or
unique number saved for each exhibition to identify them easily. For Ticket table, ticket_no,
which is the primary key or unique number saved to keep a record of each ticket. For the
Payment table, it is pay_no, which is the primary key or unique number saved for each payment
done for the ticket or tickets. For the second normalization process (2NF), the primary keys of
all the tables were checked to see whether the non-key fields completely depend upon the
primary key. For the Visitor table, if the primary key was name then it could depend upon the
surname to be complete so instead v_no is used as the primary key. For Exhibition table, if
primary key is title, then the start and the end columns could depend on the theme to be
complete. For Ticket table, v_no and tit_id are references to or foreign keys of Visitor and
Exhibition table then there are type, price and valid_till which don’t depend on each other so
ticket_no is the column that could be used as the primary key. For Payment table, ticket_no is
reference to or of Ticket table then there are date, card and status which cannot be completely
depend upon so pay_no is the column that could be used as the primary key. For the third
normalization process (3NF), all non-prime attributes of each table must be dependent on the
primary key. For the Visitor table, if there was road and city of the address to be noted road
would have been transitively depending on the city as it didn’t seemed necessary to have the
address, it was removed. The Visitor table is in the 3NF as all attributes depend solely to the
primary key or v_no in this case. For the Exhibition table, if there was a description with the
title, the start and end columns would transitively depend on it so it was removed. Only the
title will do. Exhibition table is in the 3NF as all attributes depend solely to the primary key or
tit_id. For the Ticket table, if there was tax column, the price would transitively depend on the
tax so it was removed. The Ticket table is in the 3NF as all attributes depend solely on the
primary key or ticket_no. For the Payment table, if there was price and tax then the price would
transitively depend upon tax and to reduce adding unnecessary attributes, there is a foreign
key to the Ticket table. The Payment table is in the 3NF as all attributes depend solely to the
primary key or pay_no.
Extensions to the E-R diagram
Below is with the extensions for the UML notated E-R diagram for the assignment scenario.
SQL Queries and Example Statements
An example SQL statement of building a database table is below. An empty database is created.

An example SQL statement of populating a database table with values is below. One row with
the values below is inserted.

An SQL query to retrieve the exhibition details such as theme, start and end date for a specific
exhibition is below. The particular exhibition, “Grand Opening” is searched and found.

An SQL query to retrieve the range of available exhibitions for a particular date. Start date and
time range is given and searched only one was there for the particular search.
An SQL query to retrieve the average price of all tickets sold. The average of the tickets sold
here is 17.4286.

An SQL query to retrieve the number of tickets bought by a particular visitor. There are three
tickets bought by the person whose v_no is 2.

An SQL query to retrieve the email account of every visitor that visited any of exhibitions. Using
the particular query the email of the visitors are displayed.
Recreate Model in MongoDB
The database is created and the sample information for each collection is created. To create the
booking, we have to use the UI of the application. First the visitor will be created and then a
ticket will be created then payment should be done. After the payment is done the booking will
be confirmed. To retrieve a booking, type the pay_no to get the booking. In this case if the
booking is confirmed then it doesn’t need the ticket_no and increases the speed of the system.
Compare and Contrast Report
Introduction
In this report, I will be comparing between the two types of solutions of databases, relational
and non-relational. There will be contrast between the advantages and the disadvantages of
both the solutions. It will go into detail about the features in each of the solutions and will
examples of the databases using the particular solution.

Relational and Non-relational

Relational database model has quite a rigid schema that means that a schema must be
designed in advance before data had been loaded and all attributes of the schema are uniform
for all elements, in the case of missing values null values are used instead. It has strong rules for
every part. It is difficult to change the schema of databases, especially when, it is a partitioned
relational database that spreads across multiple servers. If our data capture and management
requirements are constantly evolving, a rigid schema can quickly become an obstacle to change.
So as to remove this rigidity, companies such as Google, Amazon, Facebook and LinkedIn have
been among the first companies that discovered those limitations of the relational database
model as far as the demands of new applications. These limitations have led to the
development of non-relational databases, also commonly known as NoSQL (Cornelia Győrödi,
2015).

The SQL data model which is the relational solution was designed to avoid redundancy and use
relations between data. Therefore in queries there are many joins which can be very inefficient
for large data sets. The data model for MongoDB, which refers to the non-relational solution, is
the simplest one. By using features like nested documents and arrays, it consists of three
collections of documents. (Konrad Fraczek, 2017).

Advantages and Disadvantages

Some of the benefits of the relational database design as follows. Most of the information is
stored in the database and not in the application, so the database is self-documenting. It is easy
to add, update or delete data. It gives benefits of data summarization, retrieval and reporting.
The database is structured in a tabular form with highly related tables; the nature of the
database is predictable. Also, any changes required to make in the schema of the database is
quite simple making it simple tool to use.

Some of the disadvantages of relational database designs are as follows. Relational databases
do not support high scalability, until a certain point better hardware can be employed but
beyond that point the database must be distributed. One of the major disadvantage is data is
stored in relational database in form of tables; this structure can give rise to high complexity in
case data cannot be easily encapsulated in a table. Much of the features provided by relational
databases are not used hence simply add to the cost as well as the complexity of the database.
Relational Databases make use of SQL, which is featured to work on structured data, but SQL
can be highly complex when working with unstructured data making it hard to track down data.
When the amount of data turns huge the database has to be partitioned across multiple
servers, this partitioning poses several problems because joining tables in distributed servers is
not an easy task. So overall we need a system which could store large information in a better
way.

The benefits of using non-relational database are as follows. It loosens the requirement of
formatted data for storage, eliminating the need for fixed data model. Fast retrieval of
documents on the basis of its contents as the document store is used. Patterns of the data
could be found as there are nodes as the database uses graph data structure. Column-oriented
databases are comparatively efficient than row oriented one’s when new values for a column
are entered for all rows at once as column data can be written efficiently and replace old data
without altering any other columns for the rows. Object Oriented Databases also commonly
known as OODBMS), is a database system. It stores its data in the form of objects. This feature
supports inheritance and hence reusability similar as in object oriented programming. Grid
computing is exploited to manage heterogeneous and geographically distributed databases
while Cloud Computing provides easy access to remote hardware and storage resources thus
managing the unstructured data. XML database is a database management system that is used
to store XML data. XML mapping makes it easier to map the data.

Disadvantages of non-relational database are as follows. Most of the Non-Relational databases

are open source software and though well appreciated, it compromises in reliability as nobody
is responsible in times of failures. Many of the Non-Relational databases are disk based which
implement buffer pool and multithreading hence require buffer management and locking
features which add on to performance overhead. Many Non-relational databases provide BASE
properties and sacrifice conventional ACID properties as a step to increase performance. This
could mean the non-relational databases compromise on consistency within the database.
Because of leaving out ACID properties, the degree of reliability provided by non-relational
databases is lower than what is provided by the relational databases. Developers have to rope
in programming to apply ACID restraints which could have been provided easily in relational
databases. As the market is still unfamiliar to non-relational databases, it causes a major reason
for developers to use it and in determining whether it will be beneficial or not (Nishtha Jatana,
2012).
Conclusion
If the database contains big data then a non-relational solution would be best but if the data is
not as large and needs a simple format then relational solution would be the best. Relational
solution gives an easy card but non-relational solution opens to another level of possiblities.

References
Cornelia Győrödi, R. G. (2015). A Comparative Study of Relational and Non-Relational Database Models
in a Web- Based Application. (IJACSA) International Journal of Advanced Computer Science and
Applications, 78-83.

Konrad Fraczek, M. P.-W. (2017). Comparative analysis of relational andnon-relational databases in the
context ofperformance in web applications. In D. M.-M. Stanislaw Kozielski, Beyond Databases,
Architectures and Structures. Towards Efficient Solutions for Data Analysis and Knowledge
Representation (pp. 153-164). ustron.

Nishtha Jatana, S. P. (2012). A Survey and Comparison of Relational and Non-Relational Database.
International Journal of Engineering Research & Technology (IJERT), 1-5.