CMPS 3420-01 Fall 2020 Amairany Chavez Luis Aguilar Cody Davis

1 CMPS 3420-01 Fall 2020 Amairany Chavez Luis Aguilar Cody Davis 2 Table of Contents 1.1 - Fact-Finding Techniques and Information Gathering 1.1.1 - Introduction to the Enterprise/Organization 1.1.2 - Description of Fact-Finding Techniques 1.1.3 - The Miniverse of Interest 1.1.4 - Itemized Description of Entity sets and Relationship sets 1.1.5 - User Groups, Data Views, and Operations. 1.2 - Conceptual Database Design 1.2.1 - Entity Type Descriptions 1.2.2 - Relationship Type Description 1.2.3 - Related Entity Types 1.2.4 - ER Diagram 2.1 - The ER and Relational models 2.1.1 - Descriptions of ER and Relational Models 2.1.2 - Model Comparisons 2.2 - Conceptual to Logical Conversion Process 2.2.1 Converting Entity Types to Relations 2.2.2 - Converting Relationship Types to Relations 2.2.3 - Converting Extended Types to Relations 2.2.4 - Database Constraints 3 - Results of ER to Relational Conversion 3.1 - Relation Schema 3.2 - Sample Data 3 4 - Samples Queries 4.1 Design of Queries 4.2 Relational Algebra Expressions 4.3 Relational Calculus Expressions 5 - Normalization of Your Relations 5.1 Normalization Process 5.2 Application to Relational Model 6 - Database Implementation 6.1 Background Information 6.2 Schema and Hosting 7 - Query Implementation 8 - Programming Logic for SQL 8.1 - Introduction 8.2 - Syntax of Programming Logic 8.3 - Implementation 8.3.1 - Views 8.3.2 - Stored Procedures / Functions 8.3.3 - Triggers 9 - GUI Development 9.1 - GUI Functionalities and User Groups 9.1.1 - Itemized Descriptions of the GUI 9.1.2 - Screenshots and Walkthrough 9.1.3 - Demonstration of Programming Logic 9.2 - GUI Programming 9.2.1 - Server-side Programming 9.2.2 - Middle-tier Programming 9.2.3 - Client-side Programming 4 1.1 - Fact-Finding Techniques and Information Gathering 1 .1.1 - Introduction to the Enterprise/Organization The business will be delivering a platform that allows the users to log in and order CD’s and Vinyl records. The store would be a website-based platform allowing people to login and purchase the music products. These products would each have a list of reviews and a star rating system. The profiles would be used to keep track of shipping info and purchase records of each user. The idea is to create a web-based CD/Vinyl store like smaller shops that have physical locations and make this available to a wider audience via online. The goal would be to have a similar platform to Apple music however providing physical music items and delivering them. This store’s goals would be like Amazon in which there would be no physical locations but rather warehouses of stock sent to customers. 1 .1.2 - Description of Fact-Finding Techniques This team is reaching out to web developers who have widespread knowledge on basic database systems including those who have performed projects involving music. In order to collect valuable information about the components that are included in this system, these people will be interviewed and asked for specific details about their experiences aligned with this type of database. Another one of our methods will be to take notes on webpages such as “Amazon” and “Apple music” where information about entities, attributes, keys, and relationships can be found by observing their layouts. Through observation of “Apple music” and their service we can see the username being immutable indicates it as the primary key for the database and we can design our database similarly. We would employ these types of observations to our database. 1 .1.3 - The Mini-verse of Interest Our database will focus on the sales of physical music! Since many aspects of media are becoming digital, we wanted to focus our attention to those desired physical copies of their favorite music. Our database will be most accessed by consumers who are looking to purchase physical music, or merchandise. Some of our major entities in our database will be the Warehouse entity as it handles the orders and shipments that are entered, as well as keeping track of what products are currently available. Another major entity is the Supplier entity, as it is important to know how warehouses are getting their stock and what stock they supply us with. 5 1 .1.4 - Itemized Description of Entity sets and Relationship sets Entity Sets: Customer: address, fName, lName, mName, id, This will be the customer of our website meaning the users that will login and purchase our items. Order: cart, order_id, order_date This will be the items in which the customer has selected and put in their cart. This will keep track of the date of purchase and an identifying number unique to this order Warehouse: Address, warehouse_id, product This will be the warehouse in which we store the products and set up the order to be shipped out. Shipment: products, shipment_id This will be the products that are being sent to the customer through the mail. Supplier: company_name, id, carried_items These will be the companies that sell and use our stock for our warehouse and have it shipped to us. Employee: dob, ssn, fName, lName, mName, address, age The people that work in our facilities to put together each order and help prepare each item to ship. Merch: Size, MerchType This will describe things like stickers and shirts and posters. All of which are 1 of the three types and all have sizes associated with them. Artist/Band: Artist_ID, Name This will provide specific artists/bands with an id for our products allowing for easy tables generation and look up as well as linking. Product: ReleaseDate, SKU, Price This will be the superclass for all our products that we carry in the store. Album: Genre, Name This will be the entity that has all our bands or artists albums which we will be selling. Relationship sets: Customer → Order: Once the customer adds the items to their cart and presses purchase with info entered it will be sent electronically to the warehouse. This will allow the order ID to be tracked at the warehouse to help as shipment is prepared. 6 Order → Warehouse: Order being placed online after customer purchase is then sent to the warehouse to be processed. Warehouse →Shipment: The shipment is sent from the warehouse after it is prepared. The shipment has a tracking ID and the products listed in the shipment. This allows tracking of the items to the customer. Shipment →Customer: This will be the package at the end of its shipping and has arrived at the customers' house. Supplier →Warehouse: The supplier supplies the warehouse with their goods so we can then sell them to the customer. Employee →Warehouse: The employee works for the warehouse. This is a relationship for the employees who will work at our facility packaging items to be shipped. Warehouse→ Product: This will be for the warehouse listing what they have as products within that warehouse Product→Album: This here is for the superclass product to map to albums that we have in the store which is a subclass of product. Product→Merch: This will have a superclass and subclass relationship with product and merch and be for specifying the type of product we have and whether it is merch Product→Artist/Band: This is another superclass and subclass model with Product and artist/band and will be used to combine with other subclasses to create complete information on the product given artistID. 1 .1.5 - User Groups, Data Views, and Operations Within this database, the two users represented consist of customers and warehouse employees. The customer user group can either order in small or large quantities. Customers can order items from stock such as posters, CDs, Vinyl's, stickers, and shirts. Each item that is purchased has an order identification number attached that is used by the warehouse employees. The warehouse employees are then able to track who bought specific items by using the customer’s order identification number that is used to ship that item directly from the warehouse back to the correct customer. With the relationship in products, we have an order containing a relationship where there is an order id and product id in which products that are in the order are being tracked and are able to see the contents of the order. In order to maintain an overview of each item that is being seen, workers are given the ability to track the items that have been viewed by the customer user. Customers can add and delete items from their shopping cart as long as they have not entered an order yet and warehouse employees can take a look at those logs that show how much of each product has received interest in order to produce better results in the future. Employees should be able to see when the warehouse should be restocked by looking at the 7 supplier data. Once an order has been completed, warehouse employees gain access to a purchasing history for operation purposes. 1.2 - Conceptual Database Design 1 .2.1 - Entity Type Descriptions Employee: Employee entity contains all the information for the employee that work in the warehouse, or programmers that work on the website. Primary Key: Employee ID Strong or Weak: Strong Attribute Employee Emp. Emp. Emp. Emp. Emp. Emp.SSN Emp.Age Name ID DOB fName mName lName address DescriptionEmployee When First Middle Last name Employees Employee Age of unique the name name of of address SSN Person ID employee of employetEmployee was born employee e Domain/Ty int DateTime varchar varchar varchar varchar int int pe r Value-Ran 0-Max 1/1/2022- A-Z A-Z A-Z A-Z & 000000000 00-150 ge Emp 1/1/2004 0000-9999 - 999999999 Default +1 n/a n/a n/a n/a n/a n/a +1 Value NULL No No No yes No No No No allowed? Unique Yes no no no no No Yes No Single/ Single Single Single Single Single Single Single Single Multiple Simple/ Simple Simple Simple Simple Simple Simple Simple Simple Composite 8 Customers: Keeps track of basic customer information such as their Unique ID, name, and their address.

Load more