First Normal Form (1NF) requires that each table has a primary key, and all entries are atomic (no repeating groups or arrays). Second Normal Form (2NF) results from 1NF and eliminates partial dependencies; it ensures no non-primary key attribute depends on a part of a composite key. Third Normal Form (3NF) eliminates transitive dependencies, ensuring no non-primary key attribute depends on another non-primary key attribute. For example, consider a table with columns (StudentID, CourseID, InstructorName). In 1NF, this table is atomic. Transforming to 2NF, if (StudentID, CourseID) is the primary key, we ensure InstructorName only depends on CourseID, leading to tables: (CourseID, InstructorName) and (StudentID, CourseID). Finally, for 3NF, if InstructorName functionally depends only on CourseID, no further changes are needed. Otherwise, separate out further dependencies .

Candidate keys are attributes, or sets of attributes, uniquely identifying a tuple in a relation. Among all possible candidate keys, one is chosen to be the primary key. Candidate keys must contain unique values, and they cannot contain NULL values. They essentially serve as potential primary keys, with only one being designated as the primary key explicitly to enforce entity integrity. Thus, if a table has multiple candidate keys, any of them could be selected as the primary key, but the choice usually involves considerations of simplicity and stability in terms of data .

Referential integrity constraints ensure that relationships between tables remain consistent. Specifically, they guarantee that a foreign key value always refers to an existing, valid primary key in the referenced table, thereby maintaining the correct links across tables. For example, in a database with 'employee' and 'department' tables, where each employee is assigned to one department, referential integrity constraints ensure that any 'deptno' (department number) value used in the 'employee' table must exist as a primary key value in the 'department' table. This prevents referencing non-existing departments and maintains data consistency across related tables .

Normalization is a database design process that organizes columns and tables to minimize data redundancy and improve data integrity. The primary objectives of normalization are to eliminate redundant data, ensure data dependencies make sense (only storing related data together), and to simplify the structure as much as possible. This process is usually carried out through a series of normal forms, such as 1NF, 2NF, and 3NF, each with specific rules and goals to ensure an efficient and logical database structure .

A unique constraint ensures that all values in a column are distinct across a database table, meaning no two entries in the column could be the same but allows multiple NULL values unless specified otherwise. A primary key constraint also requires unique values but goes further by disallowing NULLs and ensuring the column or columns can uniquely identify every row in the table. Use a primary key when you need to enforce the uniqueness and presence of the value in every row. Use a unique constraint when two or more columns can share this requirement, but NULL values are permissible in exceptional cases .

Domain constraints limit the values that can be placed in a column, ensuring the data remains within a specified domain, such as type, format, or range. These constraints maintain data integrity by preventing invalid data entry. For example, a domain constraint for a 'birthdate' field might ensure entries are valid dates only. Domain constraints might be defined using data types—the attribute (column) expected data type such as INTEGER or DATE—size limits, or even specific ranges like CHECK (EmployeeAge BETWEEN 18 AND 65) to ensure the age is realistic for employment .

In an entity-relationship model, a strong entity set is independent and can exist without relying on another entity, typically having its own primary key. For instance, a 'Department' entity could be considered strong because it can independently exist with 'deptno' (department number) as its primary key. A weak entity set, however, cannot exist without a relationship to another entity, lacking its unique key. For example, an 'Employee' entity dependent on 'Department' might be considered weak if it's identified based on the department number combined with another attribute (like 'employee ID'), showing its dependency on an associated department .

An entity-relationship diagram (ERD) visually represents the data entities and relationships within a database, providing a blueprint for designing the database's structure. ERDs facilitate understanding of the system by highlighting how entities interact, including primary and foreign keys, cardinality, and participation constraints. These diagrams support the normalization process by illustrating how data is grouped and related, allowing designers to identify potential redundancies and plan the transformation of data structures into normal forms. Thus, an ERD serves as an important initial step in ensuring a logical and normalized database design .

A primary key is a field or combination of fields in a database table that uniquely identifies each record within that table. No two rows can have the same primary key value, and it cannot contain NULL values. A foreign key, on the other hand, is a field (or fields) in one table that refers to the primary key in another table. The foreign key enforces referential integrity between the two tables, ensuring that only values existing in the referenced primary key field are allowed in the foreign key field. This difference highlights the primary key's role in ensuring uniqueness within its own table, while the foreign key ensures a valid relationship between tables .

Check constraints enhance data validity and consistency by specifying conditions that each row in a database table must satisfy. These constraints effectively prevent invalid data entry, ensuring that only data meeting defined conditions are stored in the database. For example, a check constraint on an 'employee' table might ensure valid salaries by setting a condition: CHECK (salary > 0). They maintain consistency by ensuring business rules are enforced consistently across all entries. Properly designed, these constraints dynamically adapt to changes, reducing errors and ensuring compliance with necessary rules across varied datasets .