Database Design Services

Database normalisation structures a relational database to reduce data redundancy and improve data integrity. A normalised schema stores each fact exactly once in the most appropriate table rather than repeating it across multiple tables. The normal forms define progressively stricter rules: First Normal Form (1NF) requires atomic column values (no arrays or lists stored in a single column), Second Normal Form (2NF) requires that non-key attributes depend on the entire primary key (not a subset), Third Normal Form (3NF) requires that non-key attributes depend only on the primary key (not on other non-key attributes), and BCNF requires that every determinant is a candidate key. The practical consequence of poor normalisation: update anomalies (changing a customer's email requires updating it in 5 tables miss one and data is inconsistent), delete anomalies (deleting the last order for a customer deletes the customer's contact information), and insert anomalies (cannot add a product category without a product).

Row-Level Security (RLS) enforces access control at the row level restricting which rows each database session can read or modify based on a policy. For multi-tenant SaaS: every tenant-scoped table has an organisation_id column. An RLS policy is applied: `CREATE POLICY tenant_isolation ON orders USING (organisation_id = current_setting('app.current_org_id')::uuid)`. When the application authenticates a user, it sets the session variable `SET app.current_org_id = 'user-org-uuid'`. Every subsequent query on that connection is automatically filtered by the RLS policy `SELECT * FROM orders` returns only the authenticated organisation's data. The database enforces this regardless of what SQL the application writes a bug that accidentally omits a WHERE clause cannot return another tenant's data. This is safer than application-level filtering where a single coding mistake can cause a data breach.