Relational Databases

Relational databases

A relational database splits data into linked tables. Instead of one huge duplicated table, hotel_db has gosti, sobe, rezervacije, and placanja — each with a clear role.

Relationships use primary and foreign keys. A reservation references gost_id and soba_id instead of copying guest name and room number. In hotel_db reception, finance, and housekeeping share gosti, sobe, rezervacije, placanja, and zaposleni — every change must stay consistent for all app modules.

In depth

Normalization reduces redundancy and update anomalies. SQL JOIN combines tables when the app needs a full view. In Workbench run the sample SQL on test data before production, check EXPLAIN as tables grow, and document expected results for teammates.

Key points

• Each table has one role. — hotel_db example.
• PK uniquely identifies a row. — hotel_db example.
• FK links tables. — hotel_db example.
• JOIN merges data on read. — hotel_db example.
• Model follows hotel business flow. — hotel_db example.

Practical example

JOIN gosti and rezervacije.

SELECT g.ime, r.datum_od
        FROM gosti g
        JOIN rezervacije r ON r.gost_id = g.id;

Common mistake

Keeping everything in one table because it seems easier at first. Typical fallout: mismatched reception vs finance data, lost reservations, or blocked check-ins at peak season — always backup before production DDL/DML.

Summary

The relational model is the foundation of hotel_db and serious apps. Practice again on hotel_db until you can explain every result row and tie it to hotel workflows (check-in, billing, reporting).

Note: Tip: keep versioned .sql scripts (hotel_schema.sql, seed.sql) in Git — reproducibility matters when several people work on the same hotel_db model.