database design assesment

30
THE ROBERT GORDON UNIVERSITY ABERDEEN BYSINESS SCHOOL DEPARTMENT OF INFORMATION MANAGEMENT Rotten Records: Design and Implementation of a normalized Database 1

Upload: laumicha

Post on 24-Apr-2015

84 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Database Design Assesment

THE ROBERT GORDON UNIVERSITY

ABERDEEN BYSINESS SCHOOL

DEPARTMENT OF INFORMATION MANAGEMENT

Rotten Records: Design and Implementation of a

normalized Database

Submitted by: Daphne Michailidou

Word count: 2532

1

Page 2: Database Design Assesment

Table of Contents

Part 1: Design of Rotten Records database

1.1 ER Diagram and Entity description……………………………………………3

1.2 DBMS: A Short Report …………………………………………………………7

Part 2: Implementation of the Database

2.1Test of the Database ……………………………………………………11

Overall review………………………………………………………………………15

Bibliography………………………………………………………………………16.

2

Page 3: Database Design Assesment

Part 1: Design of Rotten Records Database

1.1 ER Diagram and Entity description

Scenario

Rotten Records Music Microstore needs a database to help staff answer enquiries from their extremely inquisitive customers. Rotten only stock about 20 CDs, but some are by bands, which may have two or more members, some are by solo artists, who may also be members of bands, some are compilations, with tracks by more than one artist or band, and perhaps more than one track by a particular artist or band. Some musicians appear as guest performers on other musicians’ albums. Some musicians produce each others’ albums, though there are also producers who do not perform. Musicians may play one, or several instruments, if we count vocals as an “instrument”.

Coursework part 1

1. Design a normalised database in relational form for Rotten Records, and supply a complete Entity-Relationship model which describes it (that is, the E-R diagram, plus the entity descriptions, plus a list of assumptions and constraints).

2. Write a short report (about 1,500 words) explaining the main features of a DBMS and the principles used in DBMS design, and explaining the different forms of DBMS architecture (for example, hierarchical, network,).

In our attempt to design our database, we would like to present our

work by providing some information concerning the way we created it. Our

first step was the design of our Rotten Records database with the help of

Office Access 2003. At this point we needed to take into consideration our

data and the relations between them. For our purpose we used real names of

bands, solo artists, albums and tracks in order to give a real life tone to our

assessment. The names of bands and artists who are involved are:

3

Page 4: Database Design Assesment

AC/DC ( Dave Evans, Angus & Malcolm Young, Larry Van Kriedt,

Colin Burgess )

METALLICA ( James Hetfield, Lars Ulrich, Jason Newsted, Kirk

Hammett )

THERION ( Christopher Johnsson, Kristian & Johan Niemann, Peter

Karlsson )

MICHAEL JACKSON

LADY GAGA

STING

CARLOS SANTANA

ELTON JOHN

Our first step was the creation of our ER diagram. For that purpose we had

to consider once again our needs. We needed an SQL provider, so we used

the open source software from http://wb.mysql.com , MySQL Workbench 5.2

as we support open source software. We consider useful to give some details

concerning our work. Our thoughts focused on the relation between the data

given. The relations could be 1:1 or 1: M and at the same way M: 1 or M: M

like Artists: Album Tracks, where we have songs performed by a band that

contains more than two members, or we have artists that are involved in one

album or song and others that are related to more that one albums for

example. In addition, each of them could play more than one instruments for

example. In this occasion we needed a relational/ network model

characteristics. “Artists” are the main table, followed by secondary ones like

“Artists has Instruments” or “Role has Artists”. Thus, we managed to create all

the possible relations between them.

In first place and we can obviously see from the ER diagram, we decided to

use a combination of models, so we used the parent – child relation of the

hierarchical model but as we had multiple relations this couldn’t support our

task.

4

Page 5: Database Design Assesment

Given the fact, we created a primary table at Access that is the Artists

and then some additional tables like the Instruments or the Album type

(compilation, solo album). In the same way, an artist can be connected with

more than one instrument such as guitar & vocals or guitar and violin at the

same time. These facts should be carefully taken into consideration because

we had to make right tables and connection between them. Here is an

example of our database’s “Artists” main table:

5

Page 6: Database Design Assesment

6

Page 7: Database Design Assesment

1.2 DBMS: A Short Report

Living in a world where technological miracles happen every day,

common and continually augmented needs lead to the foundation of new

methods in order to provide a better result in every sector. When it comes to

information technologies, databases helped out to many problems such as

storage, organisation of knowledge and free space issues. We would like to

make a short historical review and a presentation of database management

system (dbms). Databases have been in use since the earliest days of

electronic computing. At first place they were used in large organisations with

the hardware needed, to support large data sets. This type of systems was

mostly linked to the custom databases in order to gain speed at the expense

of flexibility rather than application to widely different databases and needs.

Technically speaking, it is a software system that uses a standard method of

cataloging, retrieving, and running queries on data. The DBMS manages

incoming data, organizes it, and provides ways for the data to be modified or

extracted by users or other programs. Some known examples of database

programs are: Microsoft Access, MySQL, SQL Server, Oracle and many

more. The availability of so many database management systems gave birth

to the need of a communication between them. For this reason, most of

database software comes with an Open Database Connectivity (ODBC) driver

that allows the database to integrate with other systems. In large systems, a

DBMS allows users and other software to store and retrieve data in

a structured way. In this way, users can ask simple questions in a query

language.

7

Page 8: Database Design Assesment

In this point, we would like to make a presentation of the existing

Database Management System Models and explain their differences. There

are nine types of models:

1. Hierarchical model

First met at 1960’s, this familiar model organizes data in a tree

structure way (parent – child hierarchy PCR). Different record types

are arranged in 1: N relationships so that occurrence exists. This

model is more efficient due to the fact that it hasn’t so much

redundant data, even though, there is a problem when it comes to

more than one subjects because it can copy only from one tree.

2. Network model

This model appeared in the 1970’s and it was popular for more

than a decade. Based on mathematical set theory, it brought

more flexibility. With this model, some data were more naturally

modeled with more than one parent per child (1: M) so, it

permitted the modeling of many-to-many relationships in data in

comparison to the hierarchical one. The Relational model came

to replace it.

3. Relational model

This model was developed by E.E Codd and it’s based on

relational algebra. This relational database allows the definition of data

structures, storage and retrieval operations and integrity constraints.

Data and its relations are organized in tables. A table is a collection of

records and each record contains the exactly same fields. There are

some properties that made it more attractive: Atomic values,

Uniqueness of rows, Insignificance of the columns’ and of rows’

8

Page 9: Database Design Assesment

sequence, Same kind of column values and Same names on different

tables, are some of them.

4. Object / Relational model

The ORDBMS systems add new object storage capabilities to the

relational systems that integrate management of additional fielded data

and complex objects like time series or geospatial data and in addition

they diverse binary media as video or images. It provides choice of

working with DDL (data definition language) and at the same time it

has the robust transaction and performance of its relational ancestors.

5. Object / Oriented model

This model with the use and extension of semantics of C++ language

brought much more than persistent storage, and the Java provided the

unification of the application and database development into a

seamless data model and language environment which means that

less code requirements, usage of more natural data modeling and

easier maintenance of code basis. In contrast to a relational DBMS

where a complex data structure must be flattened out to fit into tables

or joined together from those tables to form the in-memory structure,

object DBMSs have no performance overhead to store or retrieve a

web or hierarchy of interrelated objects.

At this point we would like to refer to three other models: the

Semistructured, the Associative and the Entity – Attribute – Value

(EAV) one. We consider more important to explain the final context

model.

6. Context model

The Context model combines features from all the above models and

this makes it very flexible because we can use any type of database

structure depending on the task. The fundamental storage unit is THE

CLASS that contains METHODS and describes OBJECTS which

9

Page 10: Database Design Assesment

contains FIELDS and PROPERTY or in other words permanent and

variable parts. It can be considered as a collection of object-oriented,

network and semi structured models or as some kind of object

database. A context database that does not have composite or pointer

fields and property is essentially RELATIONAL. With static composite

and pointer fields, context database become OBJECT-ORIENTED. If

the context database has only Property in this case it is an ENTITY-

ATTRIBUTE-VALUE database. With dynamic composite fields, a

context database becomes what is now known as a

SEMISTRUCTURED database.

All in all, databases came to organize our data and provide a much

better, easier and more modern maintenance and storage.

10

Page 11: Database Design Assesment

Part 2: Implementation of the Database

2.1 Test of the Database

Our database unfortunately has part of its content in Greek as we had

the Greek edition. It consist main tables, secondary tables, queries, forms and

finally the reports. In order to achieve a satisfying result we created a lot input

forms, three query forms with simple and more complicated questions and

one five pages report. We would like to add that as we wanted to make the

“release year” work, we had to use the “albums query”. Given the chance, we

also wanted to mention how crucial the cautious entry of info is. For example

we made the mistake to enter twice the name of a band member and at the

final report we had a duplicate. Our queries were:

1. Where AC/DC released their album “Back in Black”?

2. Which Michael Jackson’s album included the song “Billie Jean”?

3. Who played the guitar on Therion’s song “Midgard”?

11

Page 12: Database Design Assesment

We give the design of our third query because it’s more complicated and we

would like to show the tables and relations included. In order to reach the

result we had to relate artists with instruments, artists with band, album tracks

etc.

12

Page 13: Database Design Assesment

Finally in case the user needs a copy of his query we should be able to

provide one. In that case Reports are of extreme importance. We created two

reports, one for the Albums with tracks and one for the Band members.

13

Page 14: Database Design Assesment

14

Page 15: Database Design Assesment

Overall review

The module appeared to be very attractive and it was a basic reason

why we chose this post graduation course. We consider crucial to be part of

the modern world and to be capable of familiarize with the new technologies.

Database design was a very good way to learn something new and very

useful and obtain the foundation to develop more skills.

We made an effort to use as many knowledge as we could, combined

and critical thought and find the proper tools to express it. Open source

software was a very good way to achieve it. Briefly we note that we used

Microsoft Office Access 2003 and MySQL workbench.

In general, we found the module very interesting and rich and on the

other hand demanding and with high expectations which made us be more

careful. We enjoyed the whole experience and we feel very happy for

designing our own database. We can’t forget that technology never sleeps

and everyday is a new day for a new model, language or design mode.

15

Page 16: Database Design Assesment

Bibliography

http://www.coders2020.com/what-are-the-different-data-models-in-dbms

http://unixspace.com/context/databases.html

www.wikipedia.com

16

Page 17: Database Design Assesment

11.0 EXTENUATING CIRCUMSTANCES CLAIM FORM SESSION 2010/11

All sections of this form must be completed.

It is essential you read the Guidance Notes before completing the form.

Surname/Family Name Michailidou Daphne

Title miss Forename(s)

Address

[all correspondence relating to this appeal

will be sent to this address]

Pileas 65 Thessaloniki, Greece

Telephone Number(s) +306948049853

Email Address(es)

[all correspondence relating to this appeal

will be sent to this address]

[email protected]

RGU Enrolment Number 1013426

School Aberdeen business school

Course Msc Information Management DL

Stage 1rst

17

Page 18: Database Design Assesment

SECTION 1: MODULES AFFECTED

Columns 1 & 2 must be completed. Complete columns 3 & 4 as applicable.

1 2 3 4

Module Number Module TitleCoursework

submission Date

Exam/Class Test

Date

BSM053 Relational Database Systems 29/3 2011

SECTION 2: REASON FOR SUBMISSION OF CLAIM

Please indicate the reason(s) you are submitting the form by ticking the relevant box(es):

(i) Extension to coursework submission date

(ii) Non-submission/Late submission of coursework x

(iii) Non-attendance at an examination

(iv) Poor performance

18

Page 19: Database Design Assesment

SECTION 3 (Only applicable if you ticked (i) in Section 2 above):

Extenuating Circumstances - Extension to coursework submission date

Describe concisely the extenuating circumstances which have caused you to request a

coursework extension. Include relevant dates and refer to supporting evidence.

Completion of this section is compulsory.

I had a serious log in problem for a long period of time and I spoke to mr Alan McLennan

who permitted me to have more days in order to submit my assessment.

19

Page 20: Database Design Assesment

SECTION 4 (Only applicable if you ticked (ii), (iii) or (iv)in Section 2 above):

Extenuating Circumstances – Impact on performance

Describe concisely the circumstances which had an adverse effect on your performance or

ability to undertake an assessment. Include relevant dates and refer to supporting evidence.

Completion of this section is compulsory.

No relevant days proof. Mr McLennan has email of mine with the problem.

20

Page 21: Database Design Assesment

Section 4 continued

Impact on Performance

Describe clearly how these circumstances affected your performance when preparing for or

undertaking the assessment. Completion of this section is compulsory.

I couldn’t log in after demand of the system to change my password. Neither the old nor the

new one worked after that.

Section 5a: Evidence Submitted

List the supporting evidence submitted with this form:

1.

2.

3.

4.

5.

21

Page 22: Database Design Assesment

Section 5b: Evidence to be Submitted Later

List the item(s) you intend to submit later*. [Complete the box below only if you have

additional supporting evidence that is not yet available but which you intend to submit

shortly.]

1.

2.

3.

4.

5.

* This should be submitted no later than ten working days after submission of this

Claim Form.

Forms without supporting evidence will not usually be considered. You should not delay

submitting a form if supporting evidence is not immediately available, but it is your own

responsibility to submit this evidence as soon as possible.

22

Page 23: Database Design Assesment

Section 6a:

Claim submitted after required deadline

Where it was impossible or unreasonable for extenuating circumstances to be notified to the

School within the 5 working day deadline, describe clearly why this was the case.

Section 6b: Evidence to support a late claim

List the supporting evidence submitted to justify a late claim:

1.

2.

3.

4.

5.

23

Page 24: Database Design Assesment

Section 7: Declaration

By signing this form you are declaring the above information to be accurate to the best of your

knowledge, and that you understand the information provided in support of your claim will be

treated in confidence unless disclosure is necessary to progress the claim.

Please be aware the University’s Disciplinary Procedure for Non-Academic Misconduct, as

contained in Academic Regulation A3, Section 2, might be applied should there be any doubts

about the authenticity of the claim or documents submitted to support the claim.

Signature Date

Daphne Michailidou 11/5/2011

Data Protection Statement

The Robert Gordon University is a data controller under the Data Protection Act 1998. The

personal data you provide with this form will be kept on your student file for monitoring

purposes and the data will be anonymised and used for statistical purposes. The data will not be

transferred to third parties.

SCHOOL USE ONLY

For completion by School Office

Student’s enrolment number:

Date claim received:

24

Page 25: Database Design Assesment

Supporting evidence included: yes/no/to follow:

(i) Extension to Coursework submission date

Recommendation made:

Date:

Recommendation communicated to student by whom:

Date of communication:

For completion at Extenuating Circumstances Panel

(ii) Non-submission of coursework

(iii) Non-attendance at an examination

25

Page 26: Database Design Assesment

(iv) Poor performance

Date of meeting:

Recommendation made:

26