Virtual Tech Gaming Store

Database Design

This page presents Phase 1 and Phase 2 of the Virtual Tech Gaming Store capstone project. These phases focused on planning the database structure, identifying the required tables, defining primary keys and foreign keys, and building the relationships that support the rest of the system.

Phase 1 – Initial Database Design

In Phase 1, the goal was to plan the overall structure of the Virtual Tech Gaming Store database. The system was designed to manage customer accounts, product listings, inventory tracking, order processing, shipping addresses, and payment records in a structured and organized way.

The database was planned around seven main tables: Customer, Address, Product, Inventory, Orders, OrderItem, and Payment. Each table serves a specific purpose, and together they support the full transaction flow of the gaming store.

Phase 1 Screenshot Evidence

Screen shots design work, planning documents, ERD draft, or any screenshots that show how the database idea was first organized.

Phase 2 – Schema and Relationships

In Phase 2, the database design was expanded into a full schema. This phase defined the table attributes, primary keys, foreign keys, and relationships between the tables. This step was important because it made the database more accurate, more scalable, and easier to enforce through MySQL.

The relationships include one-to-many connections such as Customer to Address and Customer to Orders, as well as one-to-one relationships such as Product to Inventory and Orders to Payment. The OrderItem table was used as a junction table to resolve the many-to-many relationship between orders and products.

Relationship Summary

• Customer to Address = One-to-Many
• Customer to Orders = One-to-Many
• Address to Orders = One-to-Many
• Orders to OrderItem = One-to-Many
• Product to OrderItem = One-to-Many
• Product to Inventory = One-to-One
• Orders to Payment = One-to-One

Phase 2 Screenshot Evidence

See Screenshots These can include schema diagram, table design, key structure, and relationship mapping.

What this page proves

• The database was planned before it was built
• The schema includes clearly defined primary and foreign keys
• The relationships support accurate order and payment processing
• The design reduces redundancy and improves structure through normalization

Core Tables

• Customer
• Address
• Product
• Inventory
• Orders
• OrderItem
• Payment

Design Highlights

• Uses relational database structure
• Separates customers, orders, products, and payments logically
• Supports reporting, triggers, and stored procedures in later phases
• Creates a strong foundation for the full capstone project

Group Project By:

• Rickeria Lendale
• Soraya Prada
• Elizabeth Ruiz