Relational Databases are database systems that organise information into relations, commonly represented as tables consisting of rows and columns. Each table normally represents a particular type of entity or relationship, each row represents an individual record, and each column represents an attribute with a defined domain or data type. The relational model was formally described by Edgar F. Codd in 1970 and became influential because it provided a mathematically grounded way to represent structured information independently of particular storage mechanisms.
Relationships between tables are normally represented through keys, particularly primary keys that uniquely identify records and foreign keys that reference records in other tables. This structure allows applications to represent customers, products, orders, employees, transactions and many other forms of structured information while maintaining explicit relationships among them.
A central characteristic of Relational Databases is the separation between logical organisation and physical storage. Users and applications normally interact with logical relations through a Database Management System rather than directly manipulating storage structures. Structured Query Language is the dominant language used to define schemas, retrieve records, insert and modify data, control access and manage transactions, although implementations differ in their SQL dialects and capabilities. A relational schema specifies tables, columns, data types, constraints and relationships. Constraints can include primary keys, foreign keys, unique constraints, check constraints and non-null requirements. These mechanisms allow the database itself to reject many invalid states, reducing reliance on application code alone and making data integrity an explicit part of the database design.
Relational design commonly uses normalisation to reduce unnecessary duplication and undesirable update anomalies. First Normal Form generally requires atomic values and a suitable relational representation, while Second and Third Normal Forms progressively address dependencies that can produce redundancy. Boyce-Codd Normal Form provides a stronger treatment of functional dependencies, while higher normal forms address specialised dependency patterns.
Normalisation can improve consistency because a fact is stored in an appropriate place rather than repeated throughout numerous records, but highly normalised schemas may require more joins when retrieving information. Consequently, practical systems sometimes deliberately denormalise selected data for reporting, caching, search performance or other workload requirements. Normalisation is therefore a design technique rather than an absolute requirement that every production schema must follow to the maximum possible degree.
Relational systems are particularly strong when data has well-defined structure and relationships and when transactions require dependable consistency. A transaction groups operations into a logical unit and is commonly governed by the ACID properties of atomicity, consistency, isolation and durability. Atomicity means that a transaction is treated as an all-or-nothing operation, consistency requires defined integrity rules to remain satisfied, isolation controls interactions between concurrent transactions, and durability ensures committed changes survive appropriate failures. Concurrency control can involve locking, multiversion concurrency control, timestamp mechanisms or combinations of techniques. These capabilities make relational systems suitable for banking transactions, accounting, inventory, order processing, reservations, enterprise applications and other workloads where incorrect or partially applied updates can have significant consequences.
Query processing is another major feature of Relational Databases. SQL expresses what information is required, while the database engine determines how to obtain it. A query optimiser can consider available indexes, table statistics, join algorithms, filtering strategies, access paths and estimated costs when selecting an execution plan. Common join algorithms include nested-loop joins, hash joins and merge joins. Indexes can accelerate selective searches and ordering but consume storage and impose maintenance costs when data changes. Database engines can also use partitioning, materialised views, caching and parallel execution for larger workloads. Performance therefore depends not only on the amount of data but also on schema design, cardinality, query structure, indexes, transaction behaviour, hardware and the database engine's optimiser.
Relational Databases have developed substantially since early mainframe and client-server systems. Commercial and open-source implementations now support sophisticated transaction processing, replication, partitioning, parallel queries, stored procedures, triggers, JSON data, full-text search and extensive analytical functionality. Systems such as PostgreSQL, MySQL, MariaDB, Microsoft SQL Server and Oracle Database implement the relational model with different feature sets and operational characteristics. Relational technology has also influenced data warehousing, business intelligence and analytical platforms. Although alternative database models have become prominent for particular workloads, relational systems remain central to general-purpose data management because structured schemas, declarative querying, transactional guarantees and mature operational tooling address a broad range of requirements.
A common misconception is that Relational Databases are incapable of handling large or flexible datasets. In reality, modern relational engines can manage very large databases and can store semi-structured information using mechanisms such as JSON columns while retaining relational capabilities. Another misconception is that relational databases always require rigid schemas that can never change. Production schemas can evolve through controlled migrations, compatibility strategies and versioned application deployments.
The important distinction is that relational systems generally make structure and integrity explicit rather than treating arbitrary document structure as the fundamental storage model. Their limitations become more apparent when workloads demand extremely flexible records, specialised graph traversal, massive horizontally distributed workloads or data models that do not map naturally onto tables.
The practical significance of Relational Databases lies in their combination of structured modelling, integrity controls, expressive queries and mature transaction mechanisms. They are often selected when relationships among records matter and when reliable state transitions are more important than unrestricted schema flexibility. Their advantages include mature tooling, standardised concepts, strong transactional semantics, powerful query languages and extensive administrative knowledge. Disadvantages can include schema migration complexity, join-heavy queries for certain data models, operational overhead and challenges in scaling some workloads horizontally without architectural changes. The choice of a relational design should therefore follow workload characteristics rather than the assumption that one database model is universally appropriate.
