Lucas Azevedo dos Santos

N9383191

Due date: 18/10/20115 – 23:59h

Workshop: Mondays 2-4 PM

Task 1

Task 2

1

Task 3

Customers(customer_ID, customer_fn, customer_ln, street_address, street_number, postcode, state)

Orders(customer_ID, product_ID, customer_fn, customer_ln, street_address, street_number, postcode, state, products_name, unit_price, quantity, purchase_date, store_or_online)

Products(product_ID, product_category, product_name, product_description, unit_price, in_stock)

Categories(categorie_name, responsible, responsible_number)

Store(store_ID, store_street, store_number, store_postcode, store_state, store_phone, store_manager)

Constraints

All PK are mandatory fields and are underlined All FK are in italic No attribute can be null

Task 4

Tables Customers, Products, Categories and Store are already normalised to 4NF, so there is no need to change them.

Table orders is currently in 1NF.

To normalize to 2NF, a table need to ne on 1NF and every non PK need to be fully functional dependent on the PK.

customer_fn, customer_ln, street_address, street_number, postcode, state are only dependent on customer_ID; and products_name, unit_price are only dependent on product_ID. As they are dependent on only part of the candidate key, the table is not 2NF. To change this, we split the table. There is no need to create two new tables, because they already exist (Customers and Products).

To be normalized in 3NF, every non PK need to be on 2NF and also they need to be transitively dependent on the PK. In our case, the table is already on 3NF.

The tables are also normalized to BCNF, which is necessary to be normalized to 3NF and every determinant is a candidate key. And also, they are already normalized to 4NF, once it does not contain nontrivial multi-valued dependencies.

So, the new relational model will look like this:

Customers(customer_ID, customer_fn, customer_ln, street_address, street_number, postcode, state)

Orders(customer_ID, product_ID, quantity, purchase_date, store_or_online)

Products(product_ID, product_category, product_name, product_description, unit_price, in_stock)

Categories(categorie_name, responsible, responsible_number)

2

Store(store_ID, store_street, store_number, store_postcode, store_state, store_phone, store_manager)

Constraints

All PK are mandatory fields and are underlined All FK are in italic No attribute can be null

It will also solve the problems of the store in placing multiple orders.

Task 5

To upgrade the existing database, these statements have been used:

CREATE TABLE Stores(store_ID INT(3), store_street VARCHAR(50), store_number INT(5), store_postcode INT(4), store_state VARCHAR(3), store_phone INT(10), store_manager VARCHAR(50),PRIMARY KEY (store_Id));

ALTER TABLE OrdersDROP customer_fn, DROP customer_ln, DROP street_address, DROP street_number, DROP postcode, DROP state,DROP product_name, DROP unit_price;

3

ALTER TABLE OrdersADD store_or_online enum('online', 'store');

ALTER TABLE CategoriesADD responsible_number INT(10);

4

DESCRIBE Customers;DESCRIBE Stores;DESCRIBE Orders;DESCRIBE Products;DESCRIBE Categories;

5

Task 6

6.1

SELECT product_name, unit_price, in_stock FROM ProductsWHERE product_name = "comfy shoes";

π product_name, unit_price, in_stock( σproduct_name = “comfy shoes”(Products))

6.2

SELECT customer_fn, customer_ln, product_name, unit_priceFROM customers as cINNER JOIN orders as o ON c.customer_id=o.customer_idINNER JOIN products as p ON o.product_id=p.product_idORDER BY unit_price DESCLIMIT 1;

Τ unit_price (π customer_fn, customer_ln, product_name, unit_price(customers⋈

c.customer_id=o.customer_id orders⋈ o.product_id=p.product_id products))

6

6.3

SELECT responsible, category_name FROM categoriesORDER BY responsible, category_name;

Τ responsible, category_name (π responsible, category_name(Categories))

7

6.4

SELECT customer_fn, customer_ln, product_name, product_category, unit_price, in_stockFROM customers as cINNER JOIN orders as o ON c.customer_id=o.customer_idINNER JOIN products as p ON o.product_id=p.product_idWHERE state = 'QLD';

π customer_fn, customer_ln, product0_name, product_category, unit_price,

in_stock(σstate=’QLD’ (customers⋈ c.customer_id=o.customer_id orders⋈

o.product_id=p.product_id products))

6.5

SELECT customer_fn, customer_ln, state, product_category, unit_price, responsibleFROM customers as cINNER JOIN orders as o ON c.customer_id=o.customer_idINNER JOIN products as p ON o.product_id=p.product_idINNER JOIN categories as cc ON cc.category_name=p.product_categoryWHERE unit_price > 70;

8

π customer_fn, customer_ln, state, product_category, unit_price, responsible (σ unit_price > 70

(customers ⋈ c.customer_id=o.customer_id orders ⋈ o.product_id=p.product_id

products ⋈ cc.category_name=p.product_category categories))

Task 7

We are asked to evaluate the difference between SQL based DBMS and NoSQL based document store DBMS and which one would fit the necessities of Clothing Brothers store better. NoSQL is a new approach in databases. NoSQL is growing recently, and inside and outside the databases industry, people are saying NoSQL is the future and SQL is already out of date. But in fact, both have different aspects we need to evaluate before choosing which one to work with.SQL uses a highly structured table organization, where you store information in rows about data which is stored in the columns. Each record conforms a fixed schema, meaning the table must be created before data is inserted. Tables can be changed, but it involves changing the whole database. NoSQL is actually a collection of complex databases with different data and storage formats. The main database types in NoSQL is documents, graphs, key-valued and columnar. NoSQL is a more flexible when it comes to data storage, once you don’t need to insert data in a pre-defined schema, as you do in SQL; it has easy scalability, which means it spreads data across servers in a more efficient way. It is called horizontal scaling. SQL database uses vertical scaling, meaning data in big servers instead of multiple servers; and it has a consistent, high performance. It caches

9

data transparently in the system memory, which helps the developer. In SQL, there are less duplicated data then we have in NoSQL, due to normalization across multiple tables. Using tables makes it easier to manipulate data, as joining different tables. Also, SQL have more complex security.When it comes to choose a system, there is no system which will fit all necessities. Each approach has its pros and cons. In our case, since Clothing Brothers is already using DMBS based database, there is no need to change that. The information is well stored, and changing systems will be an effort that will not worth. According to Avram [2012] interview, “the main difficulty [in migrating from SQL to NoSQL] basically boils down to understanding the differences between the traditional RDBMS systems and document databases. “ Also, NoSQL is more efficiently used when the data you are using is growing fast and you need to scale out quickly across multiple servers, which is not the case in our situation. Using a vertical scaling will fit the necessities of the store in a good way.

References:

Macnulty, E. (2014). SQL VS. NOSQL- WHAT YOU NEED TO KNOW. Retrieved from http://dataconomy.com/sql-vs-nosql-need-know/.

Avram, A. (2012). Transitioning from RDBMS to NoSQL. Interview with Couchbase’s Dipti Borkar. Retrieved from http://www.infoq.com/articles/Transition-RDBMS-NoSQL/.

MongoDB (n.d.) NOSQL Database Explained. Retrieved form https://www.mongodb.com/nosql-explained

10