0% found this document useful (0 votes)
9 views

Unique Identifiers (UIDs)

dbms

Uploaded by

Krish Patel
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views

Unique Identifiers (UIDs)

dbms

Uploaded by

Krish Patel
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 32

Unique Identifiers in

Databases
 Natural Identifier
 Natural Identifier
Types of  Primary Identifier
Unique  Artificial Identifier
Identifiers
 To select a unique identifier using business rules,

Selecting a evaluate the candidate identifiers based on their


ability to consistently and uniquely identify
Unique records, considering stability, simplicity, and

Identifier relevance to business processes.


Define a Candidate Unique Identifier
Using  A candidate unique identifier is an attribute, or a
Business set of attributes, that can uniquely identify a tuple

Rules in a relation and from which a primary key can be


chosen.
 An artificial unique identifier, or surrogate key, is
Define an an internally generated unique key that is not
derived from the actual data. It is used when no
Artificial natural key is suitable. It usually takes the form of

Unique an auto-incrementing number or a universally


unique identifier (UUID). For example, user_id in
Identifier a users table that auto-increments with each new
entry.
One-to-One Relationship
 Definition: In a one-to-one relationship, a single
record in one table is associated with a single
Database record in another table. Each entity instance in the

Relationship relationship will have exactly one related entity


instance.
s  Example: A Person table and a Passport table
where each person has exactly one passport, and
each passport is assigned to exactly one person.
 Definition: In a one-to-many relationship, a single
record in one table is associated with multiple
records in another table. One entity instance in the
One-to-Many relationship can be related to many instances of
Relationship the other entity.
 Example: An Author table and a Book table where
each author can write multiple books, but each
book is written by only one author.
 Definition: In a many-to-many relationship,
multiple records in one table are associated with
multiple records in another table. Each entity
Many-to-Many instance can be related to many instances of the
Relationship other entity.
 Example: A Students table and a Courses table
where each student can enroll in multiple courses,
and each course can have multiple students. This
relationship is usually implemented with a junction
table (e.g., Enrollments).
Optionality
 Definition: Optionality indicates whether a
Identifying relationship between two entities is mandatory or
Relationship optional.

Characteristi  Example: In a Library and Books relationship, if


every book must belong to a library, it is a
cs mandatory relationship. If some books might not
belong to any library, it is an optional relationship.
 Definition: Cardinality specifies the number of
instances of one entity that can or must be
associated with each instance of another entity.
 Example: In a Teacher and Class relationship:
Cardinality
 One-to-One: Each teacher is assigned to exactly
one class.
 One-to-Many: Each teacher can teach many
classes.
 Many-to-Many: Teachers can teach multiple
classes, and each class can have multiple teachers.
 Definition: Nontransferable relationships are
those where the association between entities
cannot be reassigned or transferred to another
Non- entity.
transferable  Example: A BirthCertificate associated with a

Relationship Person is nontransferable because a birth


certificate uniquely belongs to the person it was
s issued to and cannot be transferred to another
person.
Intersection Entity
 To resolve a many-to-many relationship, an
intersection entity (junction table) is created. This
Resolving a Many- table includes foreign keys from both related
to-Many entities and may contain additional attributes
Relationship Using relevant to the relationship.
an Intersection  Example: Consider a many-to-many relationship
Entity between Students and Courses. The intersection
entity Enrollments would be created to resolve
this relationship.
 After creating an intersection entity, unique
identifiers can vary:
Unique Identifiers  Natural Composite Key:
After Creation of  The primary key is a combination of the foreign keys
an Intersection from the related tables.
Entity  Example: (student_id, course_id) can be the
composite primary key for the Enrollments table.
 CREATE TABLE Enrollments (
 student_id INT,
 course_id INT,
 enrollment_date DATE,
 PRIMARY KEY (student_id, course_id),

EXAMPLE  FOREIGN KEY (student_id) REFERENCES


Students(student_id),
 FOREIGN KEY (course_id) REFERENCES
Courses(course_id)
 );
 An artificial unique identifier is introduced as a
primary key, such as an auto-incremented ID.
Surrogate Key:  Example: enrollment_id as a primary key.
 CREATE TABLE Enrollments (
 enrollment_id INT PRIMARY KEY
AUTO_INCREMENT,
 student_id INT,
 course_id INT,
EXAMPLE:  enrollment_date DATE,
 FOREIGN KEY (student_id) REFERENCES
Students(student_id),
 FOREIGN KEY (course_id) REFERENCES
Courses(course_id)
 );
 A barred relationship is a relationship where a
foreign key attribute or set of attributes must form

Barred part of the primary key in the table where the


foreign key resides. This ensures that the foreign
Relationship key is always part of a unique identifier.
 A composite unique identifier consists of two or
Composite Unique more columns that together ensure the
uniqueness of a record in a table.
Identifiers
 CREATE TABLE Enrollments (
 enrollment_id INT PRIMARY KEY
AUTO_INCREMENT,
 student_id INT,
 course_id INT,
EXAMPLE  enrollment_date DATE,
 UNIQUE (student_id, course_id),
 FOREIGN KEY (student_id) REFERENCES
Students(student_id),
 FOREIGN KEY (course_id) REFERENCES
Courses(course_id)
 );
Hierarchical Relationship

Types of  Definition: A hierarchical relationship in database


modeling represents a parent-child relationship
Relationship where each parent can have multiple children, but

s in each child has only one parent. It forms a tree-like


structure with a single root and branching nodes.
Database  Example: An organizational chart where each

Modeling employee (child) reports to a manager (parent),


and managers report to higher-level managers,
and so on.
 Definition: A recursive relationship occurs when
entities of the same type are linked together in a
relationship. This relationship type is common
Recursive when an entity can have a relationship with itself.
Relationship  Example: In an organization, an employee might
have a relationship with another employee (e.g.,
mentorship or reporting structure).
 Definition: An arc relationship (also known as
non-hierarchical relationship or network
relationship) exists when entities are connected in
a non-linear fashion, often without a clear
hierarchy or recursion.
Arc Relationship  Example: Social networks where users can follow
each other without a strict hierarchy or when
modeling complex dependencies between entities.
 Hierarchical Relationship
Unique
 Recursive Relationship
Identifiers (UIDs)
 Arc Relationship
in Different
Relationship
Models
Constructing  CREATE TABLE Employees (

a Model 

employee_id INT PRIMARY KEY,
name VARCHAR(100),
Using  manager_id INT,
Recursion  FOREIGN KEY (manager_id) REFERENCES
and Employees(employee_id)

Hierarchies  );
Arc Differences:

Relationship  Arc Relationship: Focuses on non-linear


connections between entities without necessarily
vs. defining a strict hierarchy or inheritance.

Supertype/S  Supertype/Subtype Entity: Specifically defines


inheritance relationships where subtypes inherit
ubtype attributes and relationships from a common

Entity supertype, allowing for specialization and


generalization.
Necessity of  Historical Analysis
Tracking  Auditing and Compliance

Data  Correctness and Accuracy

Changes  Recovery and Rollback

Over Time  Business Insights


 Customer Information: Addresses, contact
details, preferences.

Data That  Financial Data: Sales figures, transaction details.


 Inventory: Stock levels, item details.
Changes  Employee Records: Job titles, salaries, roles.
Over Time  Product Information: Prices, specifications,
availability.
 System Logs: Audit trails, user activity.
 Natural Keys: If using natural keys (e.g., social
security numbers, email addresses) as identifiers,
they may need to be supplemented with a time
component (e.g., effective date) to differentiate
Changes in between versions of the same entity over time.

Unique  Surrogate Keys: Artificial identifiers (e.g., auto-

Identifiers incremented IDs) typically remain unchanged over


time but can still be linked to time-stamped
After Adding records to track changes.

Time to an  Historical Identifiers: In some cases, historical


identifiers may be used to uniquely identify
ERD versions of entities at specific points in time,
allowing for a comprehensive historical record.
 CREATE TABLE Employees (
 employee_id INT PRIMARY KEY,
 name VARCHAR(100),
 position VARCHAR(50),
EXAMPLE  start_date DATE,
 end_date DATE);
Purpose of Eliminate Redundancy
Reduce Update Anomalies
Normalizatio Improve Data Integrity
n
Rules of
First,  First Normal Form (1NF)

Second, and  Definition: Ensures that each column in a table


contains atomic (indivisible) values, and each row
Third contains unique data without repeating groups or
Normal arrays.

Forms (1NF,
2NF, 3NF)
 Definition: Builds on 1NF and ensures that all
non-key attributes (attributes not part of the
• Second Normal primary key) are fully dependent on the primary
Form (2NF) key.
 Definition: Builds on 2NF and ensures that there
Third Normal Form are no transitive dependencies; that is, no non-key
attribute depends on another non-key attribute.
(3NF)

You might also like