Relational Data Model

The relational data model represents data as relations, commonly implemented as tables. A table describes an entity or association, such as customers, orders, or order items. Each row represents a record, and each column represents an attribute with a defined data type. The logical model describes how data is organized independently of the storage devices, servers, or cloud infrastructure that run the database.

Keys make records identifiable and relationships explicit. A primary key uniquely identifies each row, while a foreign key references a primary or other unique key in a related table. For example, an Orders table can contain a customer_id that references Customers. An OrderItems table can connect orders to products and store quantities and purchase prices. When supported and enforced by the database engine, foreign key constraints prevent invalid references, such as an order that points to a nonexistent customer.

SQL is the usual language for working with relational databases. Engineers use it to define schemas, insert and update records, filter results, join tables, and calculate aggregates. A customer-service application might join Customers and Orders to display purchase history, while a finance report groups orders by month to calculate revenue. SQL and the relational model are closely associated but are not identical: some nonrelational systems also support SQL-like queries, and SQL tables do not exactly reproduce every mathematical property of relations.

Relational database systems commonly support ACID transactions: atomicity, consistency, isolation, and durability. During checkout, a transaction can create an order and update inventory as one unit, so a failure does not leave only part of the operation committed. These guarantees depend on engine capabilities, transaction boundaries, isolation settings, and appropriate application logic. A relational schema alone does not automatically make every business operation correct.

In the cloud, managed relational services retain the table-and-key model while handling infrastructure tasks such as provisioning, backups, and maintenance. Amazon RDS provides managed relational database engines, and Amazon Aurora is a managed relational database compatible with MySQL or PostgreSQL. For AWS Cloud Practitioner questions, both are relational database choices. Amazon DynamoDB, in contrast, is a nonrelational key-value and document database, even though it also uses the term table.

Schema design involves trade-offs. Normalization separates facts into appropriate tables to reduce duplication and update anomalies. However, retrieving data across many tables can require expensive joins. Selective denormalization can simplify frequent reads but introduces duplicated values that must remain consistent. Indexes improve selected queries but consume storage and add work to inserts, updates, and deletes. Schema changes also require planning to avoid disrupting running applications.

Relational databases are not limited to small workloads or a single server. Depending on the engine and service, they can use larger instances, read replicas, partitioning, or distributed architectures. Nevertheless, scaling writes and coordinating transactions across nodes can be more complex than scaling reads. High availability, backup recovery, and read scaling are separate concerns: a standby is not necessarily a read replica, and replication does not replace backups. Choose the relational model for its fit with relationships, integrity requirements, and query patterns, rather than assuming every structured dataset requires it.