After my database modeling class, my teacher gave us a test with a simple instruction: "model a car." No tips, no examples, no guidance. I was completely lost, but here's what I tried to figure out:

When I first started learning about database modeling, I found it really confusing to translate real-world objects into database structures. Let me share my attempt at understanding this, using a car as our example. I'm not sure if this is the right way, but it's what made sense to me.

The first thing I tried to do was identify the basic attributes of a car. I'm not sure if I got all of them, but here's what I thought we might need to store:

CREATE TABLE cars (
    id INT PRIMARY KEY,
    brand VARCHAR(50),
    model VARCHAR(50),
    year INT,
    color VARCHAR(20),
    price DECIMAL(10,2),
    version VARCHAR(50),
    wheels VARCHAR(50)
);

After that, I started wondering about related entities. This is where I got really confused: A car seems like one thing, but it's actually made up of lots of different parts. Does this parts deserve a separate table? Why? What will happen if we keep it in the same table? I don't get it.

She advised us to add more stuff:

CREATE TABLE cars (
    id INT PRIMARY KEY,
    brand VARCHAR(50),
    model VARCHAR(50),
    year INT,
    color VARCHAR(20),
    price DECIMAL(10,2),
    engine_id INT,
    wheels_id INT
);

CREATE TABLE engines (
    id INT PRIMARY KEY,
    type VARCHAR(50),
    horsepower INT,
    fuel_type VARCHAR(20)
);

CREATE TABLE wheels (
    id INT PRIMARY KEY,
    car_id INT,
    size VARCHAR(20),
    brand VARCHAR(50),
    condition VARCHAR(20)
    color VARCHAR(20),
);

I'm still trying to understand relationships between tables. From what I can tell, in our car model, each car has one engine (1-1 relationship?), but it can have multiple wheels (1-N), and it can have different upgrades over time (also 1-N). Just folowing her instructions...

As I was working on this, I started thinking about other things we might need to track. Maybe things like car parts inventory, service providers, insurance policies, or warranty information? I'm not sure which of these are actually important to include in the database. Maybe it could combine more with sales department instead factory-wise concerns.

One concept that really confused me was database normalization. I think it's about organizing data efficiently and maintaining data integrity, but I'm not sure I understand it completely. From what I can tell, it involves getting rid of duplicate data and making sure data dependencies make sense, but it's still a gray area.

I've tried to come up with some basic practices that make sense to me. I start by trying to understand what information we need to store, then I try to figure out how different pieces relate to each other. I'm not sure about the normalization rules, but I try to apply them where I think they might fit. Apperently we have to think about how the database might need to grow in the future, and we have to prevent issues when it comes.

A lot of questions to ask her.