Crave & Cork was designed to address a clearly defined problem domain: helping users elevate everyday takeout meals by making wine pairings more accessible, intuitive, and personalized. Data modeling—recognized as the first step in designing any relational database—was critical in translating this problem domain into an abstract, usable format. A data model serves as a simplified graphical representation of real-world data structures and their relationships. Its purpose is to help database designers better understand the system’s complexity and constraints while enabling structured implementation.

As Coronel & Morris (2023) explain, "A model’s main function is to help you understand the complexities of the real-world environment." In the case of Crave & Cork, the data model helped organize how food items, wines, users, and pairings interact—ultimately guiding the schema toward scalability and usability.

Initial business rules were derived from the imagined user experience and functional requirements. For example:

1. Each User can place one or more Orders, and each Order must be placed by exactly one User.
2. Each Order can include only one Dish, and each Dish can be included in zero or more Orders.
3. Each Dish must be categorized under one CuisineGenre, and each CuisineGenre can categorize one or more Dishes.

These rules were documented to identify key entities, relationships, and constraints. The rules also ensured that relationships between entities were normalized and logically enforced in the schema.


From Conceptual to Logical Modeling
The conceptual model served as a high-level, technology-independent blueprint of the system. It outlined major entities (e.g., Dishes, Wines, Users), their relationships (e.g., Orders, Pairings), and the fundamental rules governing their interactions. This model was created in Lucidchart and used to visualize how different elements of the food and wine pairing domain fit together.

The conceptual Entity-Relationship Diagram (ERD) served as a high-level map of how key parts of the system relate to each other. At this stage, I identified major entities like Users, Dishes, Wines, and Orders, along with how they interact. For example, the many-to-many relationship between Dishes and Wines—central to the pairing logic—was mapped early, allowing me to prepare for its decomposition during logical modeling.

After validation, the schema was translated into a logical model using Crow’s Foot notation. At this stage, abstract entities became tables, relationships were mapped with primary and foreign keys, and constraints were applied. Functional dependencies were carefully analyzed to support normalization.

In the logical model, the abstract entities from the conceptual diagram are translated into relational tables with clearly defined keys and constraints. Here, I decomposed the many-to-many Dishes–Wines relationship into two one-to-many relationships using a Pairings table as an associative entity. This allowed me to include a “justification” field explaining why the match works—something essential to my mission of making wine pairing both educational and accessible.

Normalization, Naming, and Data Integrity
All entities were normalized to Third Normal Form (3NF) or higher to reduce redundancy, enforce atomicity, and maintain referential integrity. Naming conventions were strictly followed: entities were singular and familiar, attributes used descriptive suffixes like _ID or _CODE, and derived fields were excluded unless justified.

As Coronel & Morris (2023) explain, "The main goal of normalization is to eliminate data anomalies by eliminating unnecessary or unwanted data redundancies." Functional dependencies were used to identify which attributes determined others, ensuring logical structure and consistency. For instance, importer details were stored in a separate Importers table rather than repeated in each wine record. Foreign key constraints and referential integrity rules ensured that all data remained synchronized and valid.

Triggers were added not just as a technical flourish, but to model real user behaviors—like tracking the last time someone placed a takeout order or when a wine’s price changed. These backend features were chosen to support a seamless user experience in a potential web or mobile app where recommendations update in real time.

Next Steps
Crave & Cork functions as a prototype system for wine recommendation based on user preferences and takeout meals. Future development would involve linking to external APIs (e.g., UberEats, Drizly), integrating a front-end interface, and adding user-generated reviews. Machine learning could further personalize pairings based on order history and ratings.

This project reflects my broader commitment to designing with purpose—using data not just to optimize systems, but to elevate human experiences. Crave & Cork isn’t about food or wine alone; it’s about building tools that democratize expertise and celebrate everyday culture.