Scribd
Upload
0 views

Unit 2 Assignment

The document outlines a database design including entities like Customer, Order, Product, and their attributes, along with primary key identification and relationships with cardinality. It also details additional requirements for payment processing and product reviews, and contrasts conceptual versus physical design. The design aims for scalability, data integrity, and functionality, supported by an E-R diagram for clarity.

Uploaded by

vzooanjaan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0 views

Unit 2 Assignment

The document outlines a database design including entities like Customer, Order, Product, and their attributes, along with primary key identification and relationships with cardinality. It also details additional requirements for payment processing and product reviews, and contrasts conceptual versus physical design. The design aims for scalability, data integrity, and functionality, supported by an E-R diagram for clarity.

Uploaded by

vzooanjaan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

### **Explanation of Each Section with E-R Diagram**

---

### **a. Entities and Attributes**


**Entities** are the core objects in the database that represent real-world concepts.
- **Customer**: Stores customer information.
- Attributes: `CustomerID` (unique identifier), `Name`, `Email`, `Phone`, `RegistrationDate`.
- **Order**: Represents a customer’s purchase.
- Attributes: `OrderID` (unique identifier), `CustomerID` (links to the customer), `OrderDate`,
`TotalAmount`, `Status`.
- **Product**: Contains product details.
- Attributes: `ProductID` (unique identifier), `Name`, `Description`, `Price`, `StockQuantity`,
`CategoryID` (links to the category).
- **Category**: Groups products (e.g., Electronics, Clothing).
- Attributes: `CategoryID`, `CategoryName`, `Description`.
- **ShippingAddress**: Stores customer addresses.
- Attributes: `AddressID` (unique identifier), `CustomerID`, `Street`, `City`, `State`, `ZipCode`,
`Country`.
- **OrderDetail**: Tracks products within an order (junction entity for the many-to-many
relationship between `Order` and `Product`).
- Attributes: `OrderID`, `ProductID`, `Quantity`, `UnitPrice`.

**Reasoning**:
- **Customer**, **Order**, and **Product** are fundamental entities for tracking users,
transactions, and inventory.
- **OrderDetail** resolves the many-to-many relationship between `Order` and `Product` by
breaking it into two one-to-many relationships.

---

### **b. Primary Key Identification**


A **primary key (PK)** uniquely identifies each record in a table.

| Entity | Primary Key | Reasoning |


|------------------|-------------------|---------------------------------------------------------------------------|
| Customer | `CustomerID` | Ensures each customer is uniquely identifiable.
|
| Order | `OrderID` | Guarantees no duplicate orders. |
| Product | `ProductID` | Uniquely identifies each product (e.g., SKU code).
|
| Category | `CategoryID` | Unique identifier for product groupings. |
| ShippingAddress | `AddressID` | A customer can have multiple addresses, so each needs a
unique identifier.|
| OrderDetail | `OrderID` + `ProductID` | Composite PK ensures uniqueness of a product
within an order. |

**Reasoning**:
- Composite keys (e.g., `OrderDetail`) are used when a single attribute cannot uniquely identify
a record.

---

### **c. Relationships and Cardinality**


**Relationships** define how entities interact. **Cardinality** specifies the number of
instances involved.

1. **Customer → Order**
- **Cardinality**: 1:N (One-to-Many).
- **Reasoning**: A customer can place multiple orders, but each order belongs to **one**
customer.

2. **Order → OrderDetail**
- **Cardinality**: 1:N (One-to-Many).
- **Reasoning**: An order can include multiple products (via `OrderDetail`), but each line
item is tied to **one** order.

3. **Product → OrderDetail**
- **Cardinality**: 1:N (One-to-Many).
- **Reasoning**: A product can appear in multiple orders, but each `OrderDetail` entry refers
to **one** product.

4. **Product → Category**
- **Cardinality**: N:1 (Many-to-One).
- **Reasoning**: Many products belong to **one** category (e.g., 100 products in the
"Electronics" category).

5. **Customer → ShippingAddress**
- **Cardinality**: 1:N (One-to-Many).
- **Reasoning**: A customer can save **multiple** addresses (e.g., home, office).

6. **Order → ShippingAddress**
- **Cardinality**: N:1 (Many-to-One).
- **Reasoning**: Multiple orders can use the **same** shipping address (e.g., recurring
orders to the same location).

---
### **d. Additional Requirements**
**Requirement 1: Payment Processing**
- **Entities**:
- **Payment**: `PaymentID` (PK), `OrderID` (FK), `PaymentMethod`, `Amount`,
`TransactionDate`.
- **Relationships**:
- **Order → Payment**: 1:1 (One-to-One).
- **Reasoning**: Each order has **one** payment, and each payment corresponds to
**one** order.

**Requirement 2: Product Reviews**


- **Entities**:
- **Review**: `ReviewID` (PK), `ProductID` (FK), `CustomerID` (FK), `Rating`, `Comment`,
`ReviewDate`.
- **Relationships**:
- **Customer → Review**: 1:N (One-to-Many).
- **Product → Review**: 1:N (One-to-Many).
- **Reasoning**: A customer can write **multiple** reviews, and a product can have
**multiple** reviews.

---

### **e. E-R Diagram (Text-Based Crow’s Foot Notation)**


Below is a text-based representation of the E-R diagram using **standard crow’s-foot
notation**:

```plaintext
Customer (1) ────< Places >──── (N) Order
│
│
< Maintains >──── (N) ShippingAddress
│
< Writes >──── (N) Review

Order (1) ────< Contains >──── (N) OrderDetail


│
< Uses >──── (1) ShippingAddress
│
< Has >──── (1) Payment

OrderDetail (N) ────< RefersTo >──── (1) Product

Product (N) ────< BelongsTo >──── (1) Category


│
< Has >──── (N) Review
```

**Symbols**:
- **Crow’s Foot (N)**: Represents the "many" side.
- **Single Line (1)**: Represents the "one" side.

**Explanation**:
- **Customer** places **many** orders (1:N).
- **Order** contains **many** products via `OrderDetail` (1:N).
- **Product** belongs to **one** category (N:1).
- **Customer** maintains **many** addresses (1:N).
- **Order** uses **one** shipping address (N:1).
- **Payment** is a 1:1 relationship with `Order`.
- **Review** connects to both `Customer` and `Product` in 1:N relationships.

---

### **f. Conceptual vs. Physical Design Differences**

1. **Conceptual Design**:
- **Focus**: High-level structure (entities, attributes, relationships).
- **Example**: Defines `Customer` with attributes like `Email` but does not specify data
types.
- **Purpose**: Facilitates communication between stakeholders.

2. **Physical Design**:
- **Focus**: Implementation details (data types, indexes, storage).
- **Example**: Converts `Email` to `VARCHAR(255) NOT NULL UNIQUE` and adds an index on
`CustomerID` for faster queries.
- **Purpose**: Optimizes performance and storage for the specific database system (e.g.,
MySQL, PostgreSQL).

**Key Difference**:
- **Conceptual** = **What** the database includes.
- **Physical** = **How** the database is built.

---

### **Summary**
This design ensures:
1. **Scalability**: Supports growing customers, orders, and products.
2. **Data Integrity**: Avoids redundancy (e.g., using `CategoryID` instead of repeating category
names).
3. **Functionality**: Handles payments, reviews, and multiple shipping addresses.

The E-R diagram visually organizes these relationships, making the system easy to understand
and implement.

You might also like