Relational Database Design

Relational database design defines the structure that makes stored facts usable and trustworthy. You decide what one row means, how rows identify each other, and which states the database must reject.

A relational database stores data in tables. The important part is not the grid. It is the contract behind the grid: each table represents one kind of fact, each row represents one instance of that fact, and relationships express how facts connect.

Start from the domain, not from columns. An ordering system may contain customers, orders, products, and order lines. Ask what each term means, which facts change independently, and which rules must remain true after every write.

Design from facts and rules

Write the grain of every table as one sentence. For example: “One row in order_line records one product on one order.” Grain prevents a familiar error: mixing order-level facts, such as the order date, with line-level facts, such as quantity.

Then list the business rules. An order belongs to one customer. An order has one or more lines. A line names one product. A product code is unique. A quantity is positive. These statements become relationships, keys, and constraints.

A diagram helps people review the model. It does not enforce the model. The database needs declarations that reject invalid rows and invalid references.