Atomic values are single, indivisible units of data. In a relational database, atomicity ensures that each field in a table contains only one piece of information. This is important for several reasons. Firstly, atomic values support efficient querying, as search conditions can target specific attributes without needing to parse or break down complex data structures. Secondly, atomic fields simplify updates—modifying a single value does not risk corrupting multiple unrelated pieces of data. Thirdly, atomicity is a prerequisite for first normal form (1NF), which is a foundation of good relational database design. Without atomic values, a table may store lists or sets in a single field, leading to redundancy, data inconsistency, and difficulties in enforcing constraints. For example, if a PhoneNumbers column contains multiple numbers in one field, searching for a specific number becomes inefficient and error-prone. Maintaining atomicity upholds the relational model’s integrity and makes the database more maintainable and scalable.

Naming conventions play a vital role in the clarity, usability, and long-term maintainability of a relational database. A consistent and descriptive naming strategy for tables and attributes ensures that the structure is understandable to developers, database administrators, and other stakeholders. Effective naming reduces ambiguity—using clear names like StudentID or CourseName makes it immediately obvious what data the column holds. Tables are usually named in the singular form to indicate a single entity (e.g. Customer), which avoids confusion when writing queries. Additionally, consistent casing (e.g. camelCase or snake_case) aids in readability and standardisation across the database. Without proper naming conventions, collaboration becomes harder, and the risk of errors increases—especially in complex systems involving multiple linked tables. Good naming also improves query writing, as it makes joins, filters, and conditions easier to interpret. In the long term, well-named tables and fields simplify maintenance, documentation, and onboarding of new team members.

The logical view of data refers to how data is perceived and organised by users and developers. It involves the structure of tables, the relationships between entities, and the data’s conceptual organisation. The logical view abstracts away from implementation details, focusing instead on what data is stored and how it is connected. It is what users interact with through SQL queries—tables, columns, records, and relationships. On the other hand, the physical view concerns how the data is actually stored on the hardware. It includes file formats, storage mechanisms, indexing, memory allocation, and optimisation strategies. The physical view is managed by the RDBMS and is usually invisible to end users. This separation allows the logical structure to remain consistent even if the physical storage method changes. For example, an index might be added to speed up queries without altering the logical table. This abstraction makes relational databases more flexible, efficient, and easier to manage.

Poor table design can have several negative impacts on a relational database system, ranging from performance issues to data inconsistency and maintenance difficulties. If a table contains redundant or duplicated data, it increases storage requirements and the likelihood of inconsistency—when one copy of a value is updated but others are not. Poorly chosen attributes or lack of atomicity can lead to complex queries, data parsing problems, and errors during updates. Inadequate normalisation may cause dependencies between unrelated data, making it harder to isolate changes. Excessively wide tables with too many attributes may result in unused fields and bloated storage, while overly narrow tables may fragment data and require too many joins. Tables without meaningful or consistent primary keys can lead to duplication and hinder relationships with other tables. Additionally, unclear naming and lack of constraints make the schema harder to understand and maintain. Altogether, poor design reduces efficiency, increases error rates, and complicates long-term database evolution.

The relational database model is inherently scalable due to its structured design and the separation of concerns through the use of tables. As data grows, new tables can be added to the schema without disrupting existing structures, and relationships can be established through keys. Efficient indexing allows queries to target specific records quickly, reducing the impact of large data volumes on performance. Normalisation ensures that data is not unnecessarily duplicated, making the database leaner and more manageable. In addition, relational databases support partitioning (splitting tables across different storage systems) and sharding (dividing data across servers), which enables horizontal scaling. The use of declarative SQL also allows the same query to be run efficiently on small or massive datasets, as the database engine optimises execution behind the scenes. Finally, the logical structure remains consistent, even as physical storage is expanded or optimised. This flexibility and structure allow relational databases to handle increasing data without loss of performance or integrity.