Skip to content

Latest commit

 

History

History
77 lines (55 loc) · 5.17 KB

17. Types of Database Models.md

File metadata and controls

77 lines (55 loc) · 5.17 KB
Raw

DATABASE MODELS

HIERARCHICAL MODEL

  1. Data organized in a tree-like structure.
  2. Each record (entity) has only one parent but can have** multiple child records**.
  3. Suitable for one-to-many relationships.
  4. Parent-child relationships are established.
  5. Example Structure: An organizational chart where each employee has one direct manager (parent) and can have multiple subordinates (children).

NETWORK MODEL

  1. Extends the hierarchical model by allowing records to have multiple parent and child relationships.
  2. Utilizes pointers to connect records in a graph-like structure.
  3. More flexible than the hierarchical model, handling many-to-many relationships better.
  4. Example Structure: A university course registration system where a student can take multiple courses, and each course can have multiple students. A course may also have multiple instructors, and each instructor can teach multiple courses.

RELATIONAL MODEL:

  1. Organizes data into tables, each representing an entity with rows and columns.
  2. Uses keys (primary and foreign keys) to establish relationships between tables.
  3. SQL (Structured Query Language) used to interact with the database.
  4. Provides a clear separation between logical data structures and physical storage.
  5. Example Structure: Employee Management System with tables for "Employees" and "Departments" with relationships established using foreign keys. Each employee belongs to a department based on the department's ID.

ENTITY-RELATIONSHIP MODEL (ER MODEL)

  1. A conceptual model to visualize the relationships between entities in a database.
  2. Represents real-world objects as entities and their attributes.
  3. Relationships show how entities are connected and interact with each other.
  4. Example Structure: An Online Shopping Platform with entities like "Customer," "Product," and "Order" represented, along with relationships like "Customer places Order" and "Order contains Product."

OBJECT-ORIENTED DATABASE MODEL (OODBMS)

  1. Extends the relational model to handle complex data types like objects, classes, and inheritance relationships.
  2. Useful for applications where data and behavior are closely tied together.
  3. Example Structure: Library Catalog System with objects representing "Books," "Authors," and "Genres" with methods and properties for each. Inheritance relationships could be defined, such as "FictionBook" and "NonFictionBook" inheriting from "Book."

OBJECT-RELATIONAL MODEL (ORDBMS)

  1. Combines features of both the relational and object-oriented models.
  2. Allows storage of objects, classes, and inheritance while maintaining compatibility with the relational model.
  3. Aims to bridge the gap between the relational and object-oriented paradigms.
  4. Example Structure: A Human Resources System similar to the relational model but with additional object-oriented features. Tables representing "Employees" and "Departments" could have object-like attributes or methods associated with them.

DOCUMENT STORE MODEL (NoSQL)

  1. Stores and retrieves data in the form of documents (e.g., JSON or BSON format).
  2. Each document can have a varying number of fields and data types.
  3. Schema-less and flexible, suitable for handling semi-structured or unstructured data.
  4. Often used for web applications and content management systems.
  5. Example Structure: A Blogging Platform with documents representing blog posts with varying fields like "title," "content," "author," and "tags." Each blog post may have different attributes, and there is no strict schema for all documents.

KEY-VALUE STORE MODEL (NoSQL)

  1. Stores data as simple key-value pairs.
  2. Efficient for high-volume, low-latency data access.
  3. Lacks the ability to query data based on complex relationships but offers high scalability.
  4. Example Structure: A User Preferences Storage where data is stored as key-value pairs. For example, a user ID could be the key, and their preferences (e.g., theme, language, notifications) are stored as values associated with that key.

COLUMN-FAMILY STORE MODEL (NoSQL)

  1. Organizes data into column families, each containing rows with multiple columns.
  2. Suitable for handling large amounts of distributed data.
  3. Provides high scalability and performance advantages for certain use cases.
  4. Example Structure: Time Series Data Management where data is organized into column families, with each row representing a timestamp. Columns could represent different data points measured at that timestamp.

GRAPH MODEL (NoSQL)

  1. Represents data as nodes, edges, and properties.
  2. Designed for managing highly interconnected data.
  3. Well-suited for applications such as social networks, recommendation engines, and complex relationship representations.
  4. Example Structure: A Social Network where users are represented as nodes, and their relationships (e.g., friendship, following) are represented as edges between nodes. Additional properties can be associated with nodes and edges to capture additional information.

KEY AND NON-KEY ATTRIBUTES

image