Databases can be categorized into several types based on their data model, structure,
and use cases:
1. Relational Databases (RDBMS)
Structure: Data is organized in tables (rows and columns).
Key Features: Primary and foreign keys, normalization, and SQL support.
Examples: MySQL, PostgreSQL, Oracle, SQL Server.
2. Hierarchical Databases
Structure: Data is stored in a tree-like structure with parent-child relationships.
Use Case: File systems, organizational charts.
Examples: IBM IMS.
3. Network Databases
Structure: Data is organized in a graph format, supporting many-to-many
relationships.
Use Case: Complex relationships in industries like telecom.
Examples: Integrated Data Store (IDS).
4. Object-Oriented Databases
Structure: Data is stored as objects, similar to object-oriented programming.
Use Case: Complex applications with multimedia, CAD, and real-time systems.
Examples: ObjectDB, db4o.
5. NoSQL Databases
Structure: Non-relational; can be document-based, key-value pairs, wide-
column stores, or graph-based.
Use Case: Big data, real-time analytics, and scalability.
Examples: MongoDB (document), Redis (key-value), Cassandra (wide-column),
Neo4j (graph).
6. Distributed Databases
Structure: Data is distributed across multiple locations but appears as a single
database to users.
Use Case: Global applications with high availability.
Examples: Google Spanner, Apache Cassandra.
7. Cloud Databases
Structure: Hosted and managed on cloud platforms.
Key Features: Scalability, high availability, and pay-as-you-go pricing.
Examples: AWS RDS, Google Cloud Spanner, Azure SQL Database.
Entity, Attributes, and Relationships
Entity
Represents a real-world object or concept in a database.
Types:
o Entity Type: A collection of similar entities (e.g., Students).
o Entity Instance: A single entity from the entity type (e.g., a specific
student, John).
o Weak Entity: An entity dependent on another entity, lacking a unique key.
Attributes
Describes the properties or characteristics of an entity.
Types:
o Simple Attribute: Cannot be divided further (e.g., Name, Age).
o Composite Attribute: Can be broken into smaller parts (e.g., Address →
Street, City).
o Derived Attribute: Derived from other attributes (e.g., Age derived from
DOB).
o Multivalued Attribute: Can hold multiple values (e.g., Phone Numbers).
Relationships
Defines how entities are associated with each other.
Types:
o One-to-One (1:1): Each entity in A is related to one in B.
o One-to-Many (1:N): One entity in A relates to multiple in B.
o Many-to-Many (M:N): Multiple entities in A relate to multiple in B.
Represented using ER diagrams with symbols for entities and relationships.
Keys in DBMS
1. Primary Key
A unique identifier for a record in a table.
Properties:
o Unique and non-null.
o A table can have only one primary key.
Example: StudentID in a Students table.
2. Foreign Key
An attribute in one table that references the primary key of another table.
Purpose: Establishes relationships between tables.
Example: CourseID in Enrollments table referencing CourseID in Courses table.
3. Candidate Key
A set of attributes that can uniquely identify a record.
Properties:
o Can have multiple candidate keys in a table.
o One candidate key is chosen as the primary key.
Example: Email and StudentID in a Students table.
4. Super Key
Any combination of attributes that can uniquely identify a record.
Includes: Primary key, candidate keys, and additional attributes.
Example: {StudentID, Name} if StudentID alone is the primary key.
Integrity Constraints
1. Primary Key Constraint
Ensures the column(s) identified as the primary key is unique and non-null.
2. Foreign Key Constraint
Ensures referential integrity by requiring values in the foreign key column to
match the primary key in the referenced table.
3. Unique Constraint
Ensures all values in a column or group of columns are unique across rows.
4. NOT NULL Constraint
Ensures a column cannot have null (empty) values.
5. Check Constraint
Validates data against a condition (e.g., Salary > 0).
6. Default Constraint
Sets a default value for a column if no value is provided during insertion.
Normalization
Normalization is the process of organizing data in a database to:
1. Minimize redundancy.
2. Eliminate undesirable characteristics like insertion, update, and deletion
anomalies.
3. Ensure data integrity.
Need for Normalization
1. Reduce Redundancy: Avoid duplicate data to save storage and maintain
consistency.
2. Improve Data Integrity: Ensure accurate and reliable data.
3. Eliminate Anomalies: Prevent issues like:
o Insertion Anomaly: Di iculty adding new data due to missing attributes.
o Update Anomaly: Inconsistent data when updating redundant fields.
o Deletion Anomaly: Loss of useful data when a record is deleted.
Normal Forms (NF)
Normalization involves transforming a database through a series of normal forms, each
addressing specific types of redundancy and anomalies.
1. First Normal Form (1NF)
Requirement:
o Each column contains atomic (indivisible) values.
o No repeating groups or arrays in columns.
Example:
A table with multiple phone numbers in a single column violates 1NF. Separate
them into rows or columns.
2. Second Normal Form (2NF)
Requirement:
o Table must be in 1NF.
o No partial dependency (non-prime attributes depend only on part of a
composite key).
Example:
In a table with StudentID + CourseID as a composite key, attributes like
StudentName depend only on StudentID and should be moved to another table.
3. Third Normal Form (3NF)
Requirement:
o Table must be in 2NF.
o No transitive dependency (non-prime attributes depend indirectly on the
primary key through another non-prime attribute).
Example:
A table where StudentID → DepartmentID → DepartmentName should separate
DepartmentID and DepartmentName into another table.
4. Boyce-Codd Normal Form (BCNF)
Requirement:
o Table must be in 3NF.
o For every functional dependency, the determinant must be a super key.
Example:
If Professor → Subject but Professor is not a super key, split the table to satisfy
BCNF.
1. Generalization
Definition: The process of combining two or more entities into a single higher-
level entity by extracting common features.
Purpose: To simplify the database structure by generalizing common attributes.
Example:
o Entities: Car and Truck.
o Generalized Entity: Vehicle (common attributes like VehicleID, Make,
Model).
Key Points:
o Bottom-up approach.
o Used when entities share similar properties.
o Removes redundancy by creating a unified parent entity.
2. Specialization
Definition: The process of dividing a higher-level entity into two or more
specialized lower-level entities based on unique features.
Purpose: To handle specific attributes or behaviors of sub-entities.
Example:
o Entity: Employee.
o Specialized Entities: Manager (with TeamSize) and Developer (with
ProgrammingLanguages).
Key Points:
o Top-down approach.
o Used to focus on distinct characteristics of sub-entities.
o Adds more specificity to the database structure.