Database approach vs. file processing

• Characteristics of the Database Approach distinguish it from programming with files.
• With file processing, users define and implement files for specific software applications.
• In a database, data names/labels are defined once and reused in queries, transactions, and applications.
• The key characteristics of a database approach are self-describing nature, insulation between programs and data, data abstraction, support for multiple views, and data sharing with multi-user transaction processing.

Self-Describing Nature

• A DBMS catalog stores descriptions of the database structure and constraints (e.g., data structures/types, storage format, constraints).
• This description of the database is called meta-data.
• Meta-data allows DBMS software to work with different database applications.

Insulation Between Programs and Data

• This is called program-data independence.
• Allows changes to data structures and storage without altering the DBMS access programs.
• Data file structure is stored in the DBMS catalog separately from access programs.

Data Abstraction

• A data model, is a type of Data Abstraction, which hides storage details, presents users with a conceptual view of the database, and uses logical concepts such as objects, properties, and their interrelationships.
• It hides storage & implementation details to provide a clear view.

Support of Multiple Views

• Each user can have a different view of the database describing data of interest.
• For example, a COURSE_PREREQUISITES view lists course names, numbers, and prerequisites.

Sharing of Data and Multi-User Transaction Processing

• Allows multiple concurrent users to retrieve from and update a database.
• Concurrency control within the DBMS is needed to prevent interference and ensure transaction execution or abortion is correct.

Database Users

• Users are divided into "Actors on the Scene" and "Workers Behind the Scene".

Actors on the Scene

• These users directly use/control database content, design, develop, and/or maintain database applications.
• Database administrators authorize access, coordinate use, acquire resources, control use, and monitor operational efficiency.
• Database designers define content, structure, constraints, functions, and transactions. They communicate with end-users to understand needs.
• System analysts assess end-user needs and develop specifications, while application programmers implement these as programs and must be familiar with DBMS capabilities to accomplish tasks.
• There are various end-users, which include: casual, naïve/parametric, sophisticated, and standalone users.
• Casual end users access the database occasionally when needed.
• Naive/Parametric end-users are common, and they use pre-defined functions; examples are bank tellers/university secretaries.
• Sophisticated end users include analysts, scientists, and engineers familiar with the systems who use software packages closely with the database.
• Stand-alone mostly maintain personal databases using packaged programs like a scientist creating a database for their experiments; these users can become sophisticated.

Workers Behind the Scene

• DBMS system designers & implementers design/implement DBMS modules & interfaces as a software package.
• Tool developers create software packages for database modeling/design, system design, and performance enhancements.
• Operators and maintenance personnel (system administrators) manage hardware and software environments.

Advantages of Using DBMS Approach

• Reduces data redundancy and cuts down on development and maintenance work.
• Facilitates data sharing, ensures consistency, and restricts unauthorized access.
• Storage structures and search techniques (indexes) are provided for query processing efficiency.
• Provides backup and recovery services, multiple user interfaces, represents complex relationships, enforces integrity constraints, and offers high-level tools for easy data interaction.

When Not To Use a DBMS

• Main inhibitors are high initial investment and overhead for generality, security, concurrency control, recovery, and integrity tasks.
• It might not be needed if the database and applications are simple, well-defined, with no expectation of change, stringent real-time requirements, or no multi-user access needed.
• No benefits if the database system cannot handle data complexity, or user's require operations the DBMS doesn't support.