Software Shinobi
caa5bbb983
All checks were successful
learn org at code.softwareshinobi.com/databases.softwareshinobi.com/pipeline/head This commit looks good
51 lines
3.7 KiB
Markdown
51 lines
3.7 KiB
Markdown
# Table Keys
|
|
|
|
Robust application development hinges on a solid understanding of database fundamentals. Keys are the bedrock of relational database integrity and efficient data access. Comprehending their function and purpose is non-negotiable for Java Team Six developers building resilient systems. These constructs prevent data inconsistency and enable precise data manipulation.
|
|
|
|
## Types of Relational Keys
|
|
|
|
Database relations (tables) must uniquely identify individual records (tuples) to prevent duplication and ensure data accuracy. Relational keys provide the mechanisms for this critical requirement.
|
|
|
|
## Super Keys
|
|
|
|
A Super Key is any combination of one or more attributes that uniquely identifies a tuple within a relation. It's a superset of uniqueness; adding more attributes to a Super Key retains its Super Key property. Think of it as any column or set of columns guaranteeing you hit only one row.
|
|
|
|
For example, in a `Customer` table, `CustomerID` alone might be unique. The combination `{CustomerID, CustomerName}` is also a Super Key, even if `CustomerName` isn't unique by itself. It simply over-specifies the identification.
|
|
|
|
## Candidate Keys
|
|
|
|
A Candidate Key is a *minimal* Super Key. This means it uniquely identifies tuples, but no subset of its attributes can achieve that same unique identification. These are the viable choices for primary identifiers of records.
|
|
|
|
For the `Customer` table, potential Candidate Keys might be:
|
|
* `CustomerID`
|
|
* `{CustomerName, CustomerAddress}` (assuming this combination is unique)
|
|
* `{CustomerName, CustomerContactNumber}` (assuming this combination is unique)
|
|
|
|
Each of these sets uniquely identifies a customer, and removing any attribute from the set would break that uniqueness.
|
|
|
|
## Primary Key
|
|
|
|
From the set of Candidate Keys, one is designated as the Primary Key. This is the *official*, chosen identifier for records in that relation. There can be only one Primary Key per table.
|
|
|
|
The Primary Key enforces two critical constraints for application data integrity:
|
|
1. **Uniqueness:** No two records can have the same Primary Key value.
|
|
2. **NOT NULL:** The Primary Key column(s) cannot contain null values.
|
|
|
|
Selecting the Primary Key is a design decision. Opt for a key that is stable and unlikely to change, such as a generated ID (`CustomerID`) rather than mutable data like a name or address. This stability is crucial for maintaining reliable references from other tables.
|
|
|
|
## Alternate Keys
|
|
|
|
Alternate Keys are simply the Candidate Keys that were *not* chosen as the Primary Key. They still possess the unique identification property but serve as secondary unique identifiers if needed.
|
|
|
|
Based on the previous example, if `CustomerID` is chosen as the Primary Key, then `{CustomerName, CustomerAddress}` and `{CustomerName, CustomerContactNumber}` would be Alternate Keys.
|
|
|
|
## Foreign Key
|
|
|
|
A Foreign Key establishes a link between two tables. It is a column or set of columns in one table (`referencing table`) that references the Primary Key (or occasionally a Unique Key) in another table (`referenced table `).
|
|
|
|
This constraint is fundamental to enforcing referential integrity. It guarantees that values in the Foreign Key column(s) of the referencing table must exist as values in the referenced table 's Primary Key column(s). This prevents orphaned records and ensures relationships between data are valid.
|
|
|
|
A table can have multiple Foreign Keys, enabling complex relationships between different entities in the database.
|
|
|
|
For instance, in an `Orders` table (`referencing table`) with columns `OrderID`, `CustomerID`, `OrderDate`, the `CustomerID` column would be a Foreign Key referencing the `CustomerID` Primary Key in the `Customer` table (`referenced table`). This ensures every order record is linked to a valid customer record.
|