Changing a primary key value is technically possible but generally discouraged because it can lead to significant complications, especially if the key is referenced by foreign keys in other tables. If the primary key is updated, all related foreign key values must also be updated to preserve referential integrity. Many database systems offer cascading updates, where a change in the primary key is automatically propagated to all foreign key references. However, relying on this feature can introduce performance overhead and the risk of unintended changes. More importantly, primary keys should ideally represent a stable and permanent aspect of the data. If a key is prone to change (e.g. email address or mobile number), it is a sign that the attribute is unsuitable as a primary key. In such cases, a surrogate key—such as an auto-incremented integer—should be used instead, and the mutable attribute can remain as a normal, indexed column with additional constraints if necessary.

When a primary key is defined in a relational database management system (RDBMS), the system automatically applies two constraints: a UNIQUE constraint and a NOT NULL constraint. The UNIQUE constraint ensures that no two records in the table can have the same value for the primary key field(s). This is usually implemented through indexing, which allows the database engine to quickly check for duplicates whenever a new record is inserted or an existing one is updated. The NOT NULL constraint ensures that a value must always be provided for the primary key; if a null is attempted, the database will reject the operation. These constraints are enforced at the schema level and apply to both simple and composite primary keys. In the case of composite keys, the database checks the combination of all included attributes—ensuring that the full set of values across those attributes is both unique and non-null in every record.

Yes, a primary key can consist of a foreign key, particularly in tables that represent relationships between entities. This typically occurs in junction tables that model many-to-many relationships. In such cases, the foreign key(s) can form part or all of a composite primary key. For instance, in an Enrolments table that links students to courses, both StudentID and CourseID might be foreign keys referencing the Students and Courses tables, respectively. Together, they can also act as a composite primary key for the Enrolments table, uniquely identifying each student-course pairing. This design ensures referential integrity while maintaining uniqueness in the junction table. However, a foreign key used as a primary key must still meet the conditions of uniqueness and non-nullability. If a foreign key is the sole attribute in the primary key, the referencing table must ensure that each foreign value is unique and not null, which may not be practical in all designs.

A natural key is an attribute that already exists within the real-world data and is inherently unique, such as a National Insurance Number or ISBN. A surrogate key, on the other hand, is an artificially created value, such as an auto-incremented ID, that has no real-world meaning outside the database. Both can serve as primary keys, but each has advantages and drawbacks. Natural keys can provide more meaningful data and reduce redundancy since the value already exists. However, they can be problematic if the natural attribute changes, is sensitive (like personal information), or becomes duplicated due to data entry errors. Surrogate keys are generally stable, simpler, and consistent across systems, but they can obscure meaning and introduce additional joins if more context is needed. In most modern database designs, surrogate keys are preferred for primary keys because they are reliable, reduce coupling between entities, and minimise risk when real-world data changes.

Using a composite primary key with more than two attributes is technically possible but generally discouraged due to complexity and practical limitations. As the number of attributes increases, so does the likelihood of performance issues and maintenance difficulties. Large composite keys make indexing slower and queries more complex, especially when those attributes are also used as foreign keys in other tables. This increases redundancy and the chance of errors during joins or data updates. It can also complicate constraints and validation logic. Additionally, user input forms and interfaces must handle more fields, making the system harder to use. From a design perspective, such composite keys often indicate a need for re-evaluating the data model. A better approach might be to use a surrogate key as the primary key and enforce uniqueness over the necessary combination of attributes using a unique constraint. This maintains data integrity while simplifying the primary key structure.