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

sql basics

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

sql basics

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

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.

You might also like