Data Models Notes.pdf

Data Models Definition: A database model determines the logical structure of a database, dictating how data is stored, organized, and manipulated. Example: The relational model, which uses a table-based format. Purpose: Introduces abstraction in a DBMS, defining ho...

Data Models Definition: A database model determines the logical structure of a database, dictating how data is stored, organized, and manipulated. Example: The relational model, which uses a table-based format. Purpose: Introduces abstraction in a DBMS, defining how data is connected, processed, and stored. History: o Flat Data Models: Early models where all data was kept on the same plane, leading to duplication and update anomalies. DBMS (Database Management System) Definition: A technology solution used to optimize and manage the storage and retrieval of data from databases. Key Terms Tuples: A single row of a table, containing a single record for that relation. Relation Instance: A finite set of tuples in the relational database system representing a relation instance. SSD (Solid-State Drive) Definition: A new generation of storage device used in computers. Function: Replaces traditional mechanical hard disks with flash-based memory, offering significantly faster performance. Hierarchical Model Definition: A hierarchical database model organizes data in a tree-like structure using parent/child relationships, limiting the number of relationships. Entity Types: o Parent: An entity type that can have multiple child entities. o Child: An entity type that is derived from a parent entity. Tree Mapping: Entity types are related using tree mapping, represented by one parent with many child relationships. Attributes: Specific data recorded under an entity. Tree Structure Representation: Displays the hierarchy of a structure, showing which entity is derived from a parent or a child. Appearance: Resembles a tree, with branches (parents) and leaves (children).  Data Representation: Both child and parent are data entities within the hierarchy model, connected to form a tree-like structure. Example One-to-Many Relationship: o Department: Can have many courses, professors, and students. Relational Model Origin: Proposed by Ted Codd of IBM in the 1970s, with commercial implementations in the 1980s. Purpose: Employed for storing and processing data in databases. Theoretical Foundations Concepts: Based on mathematical relations, set theory, and first-order predicate logic. Alternative Name: Also known as the record-based model, as it frames the database in fixed- format records of various types. Key Features Simplicity: Popular for its simplicity and ability to hide low-level implementation details from developers and users. Data Representation: Expresses the database as a set of relations (tables of values). o Relations: Each relation (table) has columns (attributes) and rows (tuples). o Attributes: Columns in a table, representing the type of information each tuple contains. o Tuples: Rows in a table, representing real-world entities or relationships. o Fields: Individual data values in a row or tuple. Example Relation Naming: Each relation has a name indicating the type of tuples it contains. For example, a relation named ‘Student’ contains student entities. Attributes Example: A ‘Student’ relation might have attributes like Roll_No., Name, and Department, indicating the information each student tuple contains. Summary Points The database is a set of related relations (tables of values). Each relation has a name indicating the type of tuples it contains. Each relation has a set of attributes representing the type of information the tuples have. A tuple in a relation is a real-world entity with a set of values for corresponding attributes. Each data value in a row or tuple is called a field. Network Model Definition: A database model that allows multiple records to be linked to the same owner file, resembling an upside-down tree where branches (members) are linked to the owner (bottom of the tree). Flexibility: The multiple linkages make the network database model very flexible. Relationships: Defined as many-to-many relationships, where one owner file can be linked to many member files and vice versa. Structure Owner and Member: o Owner: The bottom of the tree. o Member: The branches linked to the owner. Example: o A1: Owner with members B1 and B2. o Customer: Owner with members Invoice and Payment. o B1: Member with child entities C1, C2, and C3. Evolution Progression: Developed from the hierarchical database model to address its lack of flexibility. Parent-Child Relationship: Unlike the hierarchical model, the network model allows each child to have multiple parents (members and owners). Entity-Relationship (ER) Model Definition: An ER diagram shows the relationship among entity sets. An entity set is a group of similar entities, which can have attributes. In DBMS, an entity is a table or attribute of a table, showing the complete logical structure of a database. Key Concepts Entities and Attributes: o Entity: A real-world object or concept, represented as a table in a database. o Attributes: Properties of an entity, defined by a set of values called a domain. Relationships: Logical associations among entities, represented in various ways. Structure Entity Set: A group of similar entities. Relationship Set: Associations among entity sets. General Attributes: Characteristics of entities. Constraints: Rules governing the relationships and attributes. Example Entities: o Student: Attributes include Stu_Id, Stu_Name, and Stu_Addr. o College: Attributes include Col_ID and Col_Name. Relationship: o Student-College: Many-to-one relationship, where a college can have many students, but a student can only study in one college at a time. Mapping Cardinalities One to One: Each entity in the relationship will have exactly one related entity. One to Many: One entity can be related to multiple entities. Many to One: Multiple entities can be related to one entity. Many to Many: Multiple entities can be related to multiple entities. Visual Representation Fig 7a: Shows entities Student and College and their many-to-one relationship. Fig 7b: Illustrates the concept of entities and relationships in an ER diagram. Database Schema Definition: The skeleton structure representing the logical view of the entire database. It defines data organization and the relationships among data, including all constraints applied to the data. Key Concepts Entities and Relationships: Defines entities and their relationships within the database. Schema Diagrams: Used to depict the descriptive details of the database. Designers: Database designers create the schema to help programmers understand and utilize the database. Types of Schemas Logical Database Schema: o Definition: Defines all logical constraints on the stored data, including tables, views, and integrity constraints. o Design Level: Logical level, where programmers and database administrators work. Describes data records stored in data structures. Physical Database Schema: o Definition: Pertains to the actual storage of data, including files, indices, etc. o Design Level: Physical level, describing how data is stored in blocks of storage.  View Schema: o Definition: Describes end-user interaction with database systems. Blueprint Schema: Refers to the organization of data as a blueprint of how the database is constructed, divided into database tables in relational databases. Database Instance Definition: The data stored in a database at a particular moment in time is called an instance of the database. The value of the variables in the tables at any given moment is the instance of that database. Key Concepts Database Schema: o Definition: The skeleton structure of the database, defining variable declarations in tables. o Characteristics: Designed before the database exists and does not contain any data. Database Instance: o Definition: The state of an operational database with data at any given time, representing a snapshot of the database. o Characteristics: Changes over time as data is added or deleted. Example Student Table: o Today: The table has 100 records, so the instance of the database today has 100 records. o Tomorrow: Adding 100 more records will result in the instance of the database having 200 records. Distinction Schema vs. Instance: o Schema: The blueprint or skeleton of the database, designed before the database is operational. o Instance: The actual data in the database at any given time, which changes as data is modified. Valid State DBMS Role: Ensures that every instance (state) of the database is valid by following all validations, constraints, and conditions imposed by the database designers. Data Independence  Definition: The ability to modify schema definitions at one level without affecting schema definitions at the next higher level. It ensures that changes in the database system do not impact the overall structure. Types of Data Independence 1. Physical Data Independence: o Definition: The ability to modify the physical schema without causing application programs to be rewritten. o Purpose: Necessary to improve performance by changing the physical storage without affecting the conceptual or external view of the data. o Characteristics: ▪ Changes are absorbed by mapping techniques. ▪ Actual data is stored in bit format on the disk. o Example: Upgrading the storage system from hard disks to SSDs without impacting the logical data or schemas. 2. Logical Data Independence: o Definition: The ability to modify the logical schema without causing application programs to be rewritten. o Purpose: Necessary when the logical structure of the database is altered, such as adding new columns or removing columns from a table. o Characteristics: ▪ Logical data stores information about how data is managed inside. ▪ Changes in table format should not affect the data residing on the disk. o Example: Adding a new column (e.g., salary) to a table without affecting the external view for other users, even though the internal schema has changed. Challenges Logical Data Independence: More difficult to achieve than physical data independence because application programs are heavily dependent on the logical structure of the data they access. This structured format should help you understand data independence more efficiently. If you need further clarification or examples, feel free to ask!