Chapter No.

Database Environment
Instructor: Muhammad Younas

1
 Three-Level Architecture- Background
• Developed by:
• Database Task Group (DBTG) in 1971 (appointed by
CODASYL).
• ANSI Standards Planning and Requirements Committee in
1975.
• Purpose: To establish a standard vocabulary and
architecture for database systems.

2
 Three-Level Schema

• Three-Level Architecture:
• Basis for modern database management systems.
• Provides abstraction and data independence.
• Supports evolving user requirements while maintaining
consistency.

3
 Introduction to Three-Level Architecture
• Definition:
• Framework for organizing and managing databases at three
distinct levels.
• Separates user interaction, logical design, and physical
storage.
• Key Result:
• Forms the basis of modern database structures.
• Key Terms:
• Intension: Permanent database structure (schema).
• Extension: Data stored at a given time (database instance).
4
 Three-Level Schema
• Purpose:
• Isolates details between levels.
• Ensures flexibility and data independence.
• Structure:
• External schemas (views).
• Conceptual schema (entire database structure).
• Internal schema (physical data storage).

5
 External Level / View – Overview
• Definition:
• Represents different user views of the database, tailored to
their needs.
• Characteristics:
• Each user has a unique view of the system.
• Users focus only on their relevant parts of the database.
• Users may not be aware of the complete system.

6
 External Level / View – Details
• Representation:
• Same data can have different representations:
• Example: Dates stored as month/day/year vs. year/month/day.
• Includes virtual or calculated data:
• Example 1:
• Total bill computed from product names and prices.
• Example 2:
• Overall grades computed from marks in different subjects.
• Schema:
• Described by external schemas (subschemas).
• Defines how users view and interact with the database.

7
 Logical or Conceptual Level – Overview
• Definition:
• Middle-level view describing the entire structure of the
database.
• Known as the community view.
• Features:
• Contains the complete definition of data stored in the
database.
• Includes rules, structure, and type of data.

8
 Logical or Conceptual Level – Details
• Conceptual Schema:
• Unique for each database.
• Includes:
• Entities, attributes, and their relationships.
• Constraints on data.
• Semantic, security, and integrity information.
• Supports External Views:
• Any data required by a user must be accessible through the
conceptual level.
• Changes in external views do not affect the conceptual
schema.
9
 Conceptual Level – Intension and
Extension
• Intension:
• The permanent structure of the database.
• Once defined, it should not change to avoid impacting
stored data.
• Extension:
• Data added to the database after the structure is finalized.
• Performed according to rules defined in the intension.

10
 Internal or Physical Level – Overview
• Definition:
• Lowest level describing the physical representation of data
on storage media.
• Covers data structures, file organization, and storage
techniques.
• Key Roles:
• Decides how data is stored and accessed.
• Includes additional metadata for retrieval and optimization.

11
 Internal or Physical Level – Details
• Storage Management:
• Data is stored in binary format on disk.
• Operating system manages physical storage.
• Optimizations:
• Storage space utilization and compression.
• Encryption for data security.
• Internal Schema:
• Defines stored records, methods of representation, fields,
and indexes.
12
 Internal vs Physical Levels
• Internal Level:
• Managed by DBMS.
• Physical Level: Managed by the operating system.
• Format:
• Internal level: Records as per schema definition.
• Physical level: Data in character or binary format.

13
 Introduction to Mapping
• Definition:
• Mapping is the process of converting data between different
levels of database architecture.
• Purpose:
• Relates data across levels for consistency and functionality.
• Types:
• Conceptual/Internal Mapping
• External/Conceptual Mapping

14
 Conceptual/Internal Mapping
• Definition:
• Specifies the correspondence between the conceptual schema
and the stored database.
• Responsibilities:
• Defines how conceptual records/fields appear at the internal
level.
• Ensures consistency of conceptual schema when storage
changes.
• Example:
• Change in storage format must update mapping without affecting
conceptual schema.

15
 External/Conceptual Mapping
• Definition:
• Establishes correspondence between an external view and
the conceptual schema.
• Features:
• Different data types and names for fields.
• Combination of multiple conceptual fields into one external
field.
• Flexibility:
• Multiple external views can exist.
• Views can overlap and be shared among users.
16
External/Conceptual & Conceptual/Internal
Mapping

17
 Representation of Data

• Overview of Levels:
• Physical Level: Binary data with block and record headers.
• Internal Level: Storage-specific structures.
• Conceptual Level: Logical schema for all data.
• External Level: User-specific custom views.
• Key Details:
• Mapping bridges these levels for consistency and usability.

18
Representation of Data

19
 Introduction to Data Independence
• Definition:
• The separation of data and application programs to ensure
flexibility and abstraction.
• Importance:
• Core advantage of three-level architecture.
• Ensures that changes in lower levels do not affect upper
levels.
• Purpose:
• Allows modifications to database structure without altering
application programs.

20
Overview of Types of Data Independence
• Two Types:
• Physical Data Independence:
• Changes to the physical storage level do not affect the conceptual
level.
• Logical Data Independence:
• Changes to the logical structure do not impact the user or
application view.

21
 Physical Data Independence
• Definition:
• Allows changes to the internal level without affecting the
conceptual level.
• How It Works:
• DBMS abstracts physical changes and ensures consistent
logical views.
• Application programs remain unaffected.
• Examples of Changes:
• Altering file organizations or storage structures.
• Using new storage devices.
• Modifying indexes or hashing algorithms.
• Changing access methods.
22
 Logical Data Independence
• Definition:
• Enables changes to the conceptual level without impacting the
external level.
• How It Works:
• Application programs and user views are unaffected by logical
changes.
• Examples of Changes:
• Adding or removing entities or relationships.
• Introducing new files or fields to the database.
• Changing the type of a field.
• Key Consideration:
• Removing an attribute may disrupt applications using it, requiring
careful planning.
23
 Advantages of Data Independence
• Flexibility:
• Allows smooth system updates and expansions.
• Consistency:
• Prevents disruptions in application programs or user
interactions.
• Efficiency:
• Minimizes the need for changes across all levels of the
system.

24
 Introduction to Data Models
• What is a Data Model?
• A representation of real-world objects, events, and their
associations.
• Helps users understand the complexities of the real-world
environment.
• A data model is a collection of concepts used to:
• Describe data
• Manipulate relationships between data
• Enforce constraints on data

25
 Parts of a Data Model
• Structural Part
• Defines a set of rules specifying how a database can be
developed.
• Manipulative Part
• Defines operations that can be performed on data.
• Includes updating, retrieving data, and changing database
structure.
• Set of Integrity Rules
• Ensures data accuracy in the database.
26
 Importance of a Data Model
• Data Model:
• Acts as a communication tool among database designers,
application programmers, and end-users.
• Enables better understanding of the organization for which
the database design is developed.
• Essential for designing a good database.
• No DBMS can exist without a data model.
• Helps users understand the structures, manipulation
languages, and integrity facilities provided by the DBMS.

27
 Types of Data Models
• Object-Based Data Models:
• Entities, attributes, and relationships.
• Record-Based Data Models:
• Logical structure and implementation options.
• Physical Data Models:
• Describe data at the internal level.

28
 Object-Based Data Models
• Definition:
• Uses concepts like entities, attributes, and relationships.
• Key Concepts:
• Entity:
• A person, place, thing, or event for which data is collected.
• Attribute:
• Characteristics of an entity.
• Relationship:
• Association between two or more entities.
• Examples:
• Entity-Relationship, Semantic, and Object-Oriented models.
29
 Record-Based Data Models
• Definition:
• Describes external and conceptual levels of databases.
• Specifies logical structure and implementation options.
• Characteristics:
• Database consists of records with fixed fields.

30
 Types of Record-Based Data Models
• Hierarchical Model
• Network Model
• Relational Model

31
 Types of Record-Based Data Models
• Hierarchical Model
• Overview:
• Based on parent-child relationships.
• Suitable for applications like Production Planning with hierarchical
structures.
• Characteristics:
• Data represented as hierarchical trees.
• Each sub-module has one super-module.
• Uses pointers for hierarchy navigation.
• Simple structure with high performance
• Difficult to reorganize and handle complex real-life requirements.

32
 Types of Record-Based Data Models
• Hierarchical Model

33
 Types of Record-Based Data Models
• Network Model
• Overview:
• Developed to address limitations of the hierarchical model.
• Supports multiple parent-child relationships (sets).
• Characteristics:
• Represents data record types as a network.
• Allows one sub-module to have multiple super-modules.
• Difficult to reorganize due to pointer-based navigation.
• Complex structure with high performance.
34
 Types of Record-Based Data Models
• Network Model

35
 Types of Record-Based Data Models
• Relational Model
• Developed by Dr. E. F. Codd in 1970.
• Stores data in relations (tables).
• Key Terminology:
• Relation: Table.
• Tuple: Row or record.
• Attribute: Column or characteristic.
• Domain: Collection of all possible attribute values.
• Degree: Number of attributes.
• Cardinality: Number of tuples.
36
 Types of Record-Based Data Models
• Relational Model

37
 Types of Record-Based Data Models
• Relational Model

38
 Types of Record-Based Data Models
• Relational Model

39
 Types of Record-Based Data Models
• Relational Model

40
 Types of Record-Based Data Models
• Advantages of Relational Model
• Data Integrity:
• Avoids duplication, ensures valid relationships.
• Data Independence:
• Changes in design/software do not affect the database.
• Structural Independence:
• Structure changes do not affect data access.
• Data Consistency & Accuracy:
• Built-in constraints ensure reliability.
• Easy Data Retrieval & Sharing:
• Facilitates data extraction and sharing among users.
41
 Types of Record-Based Data Models
• Physical Data Models
• Overview:
• Describe storage of data in a computer.
• Represent information like record structures, record orderings, and
access paths.
• Examples:
• Unifying model and
• frame memory.

42
 Introduction to DBMS Functions
• Overview:
• Database Management Systems (DBMS) perform a variety
of essential functions that facilitate the efficient management
and use of databases.
• Key Functions:
• Data Processing
• User-accessible Catalog
• Transaction Support
• Concurrency Support
• Recovery Services
• Data Communication Support
43
 Introduction to DBMS Functions
• Function 1 – Data Processing
• Definition:
• The most important function of a DBMS is data processing.
• Key Aspects:
• Includes creation, storage, and arrangement of data in the
database.
• Provides access to data stored in databases efficiently.

44
 Introduction to DBMS Functions
• Function 2 – User-accessible Catalog
• Definition:
• A catalog is an object containing all necessary information about the
database.
• Includes Information About:
• Schema information.
• User information.
• User rights and permissions.
• Importance:
• The administrative user of a database must be able to access
the catalog.
45
 Introduction to DBMS Functions
• Function 3 – Transaction Support
• Definition:
• A transaction is a collection of steps needed to complete a process.
• DBMS Role:
• Ensures that all steps in a transaction are executed
successfully or none of them is executed.
• Maintains the database in a consistent state even if a
transaction fails due to system crash, power failure, or other
issues.

46
 Introduction to DBMS Functions
• Function 4 – Concurrency Support
• Definition:
• Concurrency is a situation where two or more users access the
same data simultaneously.
• Risks Without Concurrency:
• Potential loss of information or integrity.
• DBMS Solution:
• Provides concurrency support to enable multiple users to
access the same record simultaneously without data loss.

47
 Introduction to DBMS Functions
• Function 5 – Recovery Services
• Definition:
• A DBMS must provide mechanisms to recover a database if it is
damaged in any way.
• Key Features:
• Ensures the database remains in a consistent state.
• Minimizes data loss during the recovery process.

48
 Introduction to DBMS Functions
• Function 6 – Data Communication Support
• Definition:
• DBMS must support data communication for users accessing the
database from different locations.
• Details:
• Capable of integrating with communication software.
• Supports user access from workstations connected to host
computers over a network.
• Role of Data Communication Manager (DCM):
• DBMS must integrate seamlessly with the DCM, which handles
communication messages.

49
 Introduction to Staged Database Design
Approach
• Definition:
• A top-down methodology for designing an information
system.
• Starts with analyzing general requirements and progresses
to detailed analysis.
• Key Feature:
• Iterative process with opportunities for refinement at various
stages.

50
Introduction to Staged Database Design
Approach

51
 Introduction to Staged Database Design
Approach
• Step 1 - Analyze User Environment
• Objective:
• Understand the current user environment.
• Key Activities:
• Study existing system outputs.
• Interview users to gather current and future requirements.
• Outcome:
• Clear understanding of the system's operational and data needs.

52
 Introduction to Staged Database Design
Approach
• Step 2 - Develop Logical Data Model
• Objective:
• Create a logical representation of organizational data.
• Key Components:
• Entities, Attributes, Relationships:
• Define the structure of the database.
• Operational Considerations:
• Types of applications and transactions.
• Database access patterns and frequency.
• Data volume and transaction volume.
• Budgetary constraints and performance requirements.
• Action:
• Choose a DBMS that meets all requirements.
53
 Introduction to Staged Database Design
Approach
• Step 3 - Map Logical Model to DBMS
• Objective:
• Map the logical data model to data structures supported by the
selected DBMS.
• Outcome:
• Logical model aligned with the technical capabilities of the DBMS.

54
 Introduction to Staged Database Design
Approach
• Step 4 - Develop Physical Model
• Objective:
• Design the exact layout of data using the facilities of the selected
DBMS.
• Key Considerations:
• Resources available in terms of hardware and software.
• Optimization for database performance.

55
 Introduction to Staged Database Design
Approach
• Step 5 - Evaluate Physical Model
• Objective:
• Ensure that the physical model meets performance and user
requirements.
• Key Activities:
• Test applications and transactions.
• Validate user views and system performance.
• Implement portions of the database for evaluation

56
 Introduction to Staged Database Design
Approach
• Step 6 - Perform Tuning
• Objective:
• Improve database performance.
• Key Actions:
• Make necessary adjustments to the physical model.
• Optimize system configurations and database structures.

57
 Introduction to Staged Database Design
Approach
• Step 7 - Implement Physical Model
• Objective:
• Make the database fully operational.
• Key Activities:
• Deploy the database system.
• Ensure that all user requirements are met.
• Transition from development to production.

58
 Introduction to Staged Database Design
Approach
• Iterative Nature of Staged Design
• Key Characteristics:
• Flexibility to revisit and revise steps as needed.
• Reevaluate user environment during logical model development.
• Reassess DBMS selection during mapping of the logical to physical
model.
• Adjust all prior steps during tuning or error correction.
• Outcome:
• Continuous improvement and alignment with user needs.

59
 Introduction to DBA
• Who is a DBA?
• Key person in designing, operating, and managing
databases.
• Requires technical, managerial, and diplomatic skills.
• Effective communication is crucial for interaction with users
and stakeholders.
• Why is a DBA Important?
• Ensures database functionality, integrity, and efficiency.
• Facilitates seamless database operations to meet
organizational goals.
60
 Skills Required for a DBA
• Managerial Skills:
• Planning, coordination, and task execution.
• Technical Skills:
• Understanding complex hardware and software issues.
• Diplomatic Skills:
• Communicating with users, resolving conflicts, and
negotiating requirements.

61
 Functions of DBA (1-3)
• Preliminary Database Planning:
• Early involvement in database planning stages.
• Identifying User Requirements:
• Analyze current systems and outputs.
• Conduct interviews to gather user needs and expectations.
• Developing & Maintaining Data Dictionary:
• Maintain data definitions, sources, and uses.
• Regular updates ensure alignment with project goals.

62
 Functions of DBA (4-7)
• Designing Logical Data Model:
• Define entities, attributes, and relationships.
• Choosing a DBMS:
• Select a suitable database management system that meets
organizational needs.
• Developing Physical Model:
• Create a detailed data layout using the selected DBMS.
• Creating & Loading Database:
• Establish the database structure and populate it with data.
63
 Functions of DBA (8-11)
• Developing User Views:
• Design user-specific views and address unmet user requests.
• Writing & Maintaining Documentation:
• Ensure comprehensive documentation for reviews and revisions.
• Developing & Enforcing Data Standards:
• Ensure data integrity and consistency.
• Example:
• No contradictory or inconsistent employee records.
• Developing Operating Procedures:
• Establish protocols for security, failure management, and
recovery.
64
 Functions of DBA (12-16)
• Training the Users:
• Train end users, application programmers, and other stakeholders.
• Helping Database Users:
• Ensure data availability and provide guidance for system use.
• Defining Backup and Recovery Procedures:
• Implement backup systems for data restoration in case of failures.
• Monitoring Performance:
• Address user complaints and optimize database performance.
• Tuning & Reorganizing:
• Optimize database efficiency through adjustments to indexes and
models.

65
 Key Responsibilities of a DBA
• Maintain
• database integrity, consistency, and performance.
• Ensure
• secure access and data protection.
• Respond
• to user needs and organizational requirements.
• Continuously
• monitor and enhance database systems.
66
 Who is a Data Administrator (DA)?
• Introduction
• Database Administrator is:
• Responsible for managing multiple databases in large organizations.
• Oversees the entire information resource.
• Ensures alignment between data operations and organizational
goals.

67
 Key Responsibilities of a DA (1/3)
• Developing Requirements for Databases
• Collects and documents data requirements from various departments.
• Aligns requirements with business objectives.
• Developing Logical Design
• Creates logical database structures.
• Ensures efficient data storage and retrieval.
• Performing Non-Technical Functions
• Administrative tasks related to database management.
• Facilitates collaboration between stakeholders.
• Controlling and Managing Databases
• Supervises database operations to ensure security and integrity.
• Establishes database usage policies.

68
 Key Responsibilities of a DA (2/3)
• Establishing Data Standards
• Defines standards for naming, formats, and quality.
• Maintains consistency in organizational data usage.
• Communicating with Users
• Acts as a liaison between developers and end-users.
• Collects user feedback and shares updates.
• Developing Data Dictionary
• Documents data definitions, formats, and relationships.
• Maintains a comprehensive and updated data dictionary.
• Planning Database and Application Development
• Plans database and application program development.
• Allocates resources and schedules tasks.

69
 Additional Responsibilities of DA (3/3)
• Training Users
• Provides training on database functionalities.
• Educates users on best practices for database usage.
• Maintaining Documentation
• Ensures thorough documentation of processes and updates.
• Keeps records accessible to stakeholders.

70
 Data Dictionary
• Definition of Data Dictionary
• Repository that:
• Describes the logical structure of the database.
• Contains:
• Record types, data item types, data aggregates.
• Stores:
• Database schema and metadata (data about the data stored in the
database).

71
 Uses of Data Dictionary (Part 1)
• Information About Data
• Central repository for collecting and storing data information.
• Helps management control data as a resource.
• Communication with Users
• Stores exact meanings of data items for problem resolution.
• Enhances communication through precise data definitions.

72
 Uses of Data Dictionary (Part 2)
• Record of Changes in Database Structure
• Tracks modifications, such as creation or alteration of data
items.
• Ensures an up-to-date record of structural changes.
• Determining the Impact of Change
• Records relationships between data items.
• Enables DBA to predict and manage the effects of changes.

73
 Uses of Data Dictionary (Part 3)
• Recording Access Control Information
• Maintains details of authorized users and their access
levels.
• Helps enforce database security.
• Audit Information
• Logs all database accesses for auditing purposes.
• Ensures accountability and traceability.

74
 Types of Data Dictionaries
• Integrated Data Dictionary
• Part of the DBMS, used throughout the database’s lifecycle.
• Freestanding Data Dictionary
• Independent of a specific DBMS.

75
 Types of Data Dictionaries
• Integrated Data Dictionary
• Definition:
• Embedded within the DBMS and utilized throughout the database
lifecycle.
• Types
• Active Data Dictionary:
• Checked by DBMS during every database access.
• Automatically updated and consistent with the database structure.
• Passive Data Dictionary:
• Not used in daily database processing.
• May become inconsistent with the actual database over time.
76
 Types of Data Dictionaries
• Integrated Data Dictionary
• Part of the DBMS, used throughout the database’s lifecycle.
• Freestanding Data Dictionary
• Independent of a specific DBMS.

77
 Types of Data Dictionaries
• Freestanding Data Dictionary
• Definition:
• Independent of a specific DBMS.
• Characteristics:
• Can be a commercial product or a custom file created by the
designer.
• Commonly used in early design stages before selecting a DBMS.
• Often included as a tool in CASE (Computer-Aided Software
Engineering) packages.

78
 Introduction to Logical Database Design
• Definition:
• Logical database design defines the data to be stored in the
database.
• Includes rules, structure, and type of data.
• Describes entities, their attributes, and their relationships.
• Purpose:
• Provides a complete description of the data stored in the
database.

79
 Logical Database Design Process
• The logical design process consists of four key steps:
• Represent Entities
• Represent Relationships
• Merge the Relations
• Normalize the Relations

80
Introduction to Logical Database Design

81
 Logical Database Design Process
• Step 1 - Represent Entities
• Conversion Process:
• Each entity in the E-R diagram becomes a relation in the relational
model.
• Entity name → Relation name.
• Entity identifier → Primary key.
• Other attributes → Non-key attributes.
• Example:
• EMPLOYEE Entity:
• Attributes: EmployeeID, Name, Address, Birthdate.
• EMPLOYEE Relation:
• Fields: EmployeeID (Primary Key), Name, Address, Birthdate.

82
Logical Database Design Process

83
 Logical Database Design Process
• Step 2 - Represent Relationships
• Each relationship in an E-R diagram is represented in the
relational model.
• Techniques:
• Use the primary key of one relation as a foreign key in
another relation.
• Create a separate relation for specific relationships.
• Representation depends on the nature of the
relationship.
84
 Logical Database Design Process
• Step 3 - Merge the Relations
• Objective:
• Remove redundancy by merging relations.
• Process:
• Combine relations describing the same entity type (view integration).
• Example:
• EMP1: (EMPNO, NAME, ADDRESS, PHONE).
• EMP2: (EMPNO, ENAME, EMP_ADDR, EMP_JOB_CODE, EMP_DOB).
• Merged Relation:
• EMP (EMPNO, NAME, ADDRESS, PHONE, EMP_JOB_CODE, EMP_DOB).
• Ensures no repeating attributes.
85
 Logical Database Design Process
• Step 4 - Normalize the Relations
• Purpose:
• Refine relations to remove redundancy and avoid anomalies.
• Benefits:
• Reduces errors in data updates.
• Optimizes database structure.
• Outcome:
• Relations become efficient, consistent, and easier to manage.

86
 Physical Database Design
• Introduction
• Physical database design is the final stage of the database
design process.
• The main objective is to implement the database as a set of
records, files, indexes, and other data structures.
• Focuses on the physical aspects of storing and accessing
data efficiently.

87
 Major Inputs to Physical Database Design
• Logical Database Structure
• Developed during logical database design.
• Includes normalized relations that form the basis of the database
schema.
• User Processing Requirements
• Size and frequency of database usage.
• Response time, security, backup, and recovery requirements.
• Characteristics of DBMS
• Involves DBMS and the components of the computer operating
environment.
88
 Components of Physical Database Design
• Data Volume and Usage Analysis
• Estimating the size and usage patterns of the database.
• Usage Analysis:
• Helps in selecting storage devices, determining storage costs,
and planning access methods.
• Crucial for selecting file organization and distribution strategies.
• Informs decisions about indexes and data distribution.
• Data Distribution Strategy
• Decisions about where to store data in a distributed network.
• Types of Data Distribution:
• Centralized, Partitioned, Replicated, and Hybrid strategies.
89
 Data Distribution Strategy
• Centralized
• All data stored at a single site.
• Disadvantages:
• Data is not readily accessible from remote sites.
• High data communication costs.
• Database failure if the central system fails.
• Partitioned
• Database divided into partitions or fragments.
• Each partition is stored at a specific site.
• Advantage:
• Data is closer to local users and more accessible.

90
 Data Distribution Strategy (contd.)
• Replicated
• Full copies of the database stored at multiple sites.
• Advantage:
• Maximizes local access.
• Disadvantage:
• Synchronization problems during updates.
• Hybrid
• Combines partitioned and replicated strategies.
• Strategy:
• Critical data stored at multiple sites, non-critical at one site.
91
 File Organization
• File Organization Definition
• Refers to the physical arrangement of records on storage
devices.
• Factors influencing selection:
• Physical characteristics of storage devices.
• Operating systems and available file management software.
• User requirements for storing and accessing data.

92
Criteria for Selecting File Organization
• Fast data retrieval
• High throughput for transactions
• Efficient use of storage space
• Protection from data loss
• Minimized need for reorganization
• Security from unauthorized use

93
 File Organization Methods
• Sequential Files
• Records stored in sequence, one after another.
• Storage Media:
• Magnetic tape.
• Disadvantages:
• Slow access:
• All preceding records must be read before the last one.

94
 File Organization Methods (contd.)
• Direct or Random Files
• Records stored without a specific sequence.
• Key-based Access:
• A key value determines record location.
• Direct access to specific records without reading preceding ones.
• Problem:
• Synonym issue, where the same address is assigned to
multiple records.

95
 File Organization Methods (contd.)
• Indexed Sequential Files
• Records stored in ascending or descending order based on
a key.
• Index Maintenance:
• An index file stores key values and corresponding disk addresses.
• The index is updated when records are added or deleted.
• Access Methods:
• Supports sequential and direct access.
• Requires more storage space and is slower than direct access due
to index searches.

96
 Indexes
• Definition:
• An index is a table used to determine the location of rows in
a table, speeding up sorting and searching.
• Purpose:
• Improves database performance by reducing access time.
• Indexes can be created on primary keys, secondary keys,
and foreign keys.

97
 Integrity Constraints
• Definition:
• Integrity refers to the correctness and consistency of data.
• Purpose:
• Ensures high-quality data within the database.
• Integrity Constraints:
• • Rules designed to keep data consistent and correct.
• • Act as checks on incoming data.
• • DBMS provides mechanisms to enforce integrity.
98