Data Base Management

This document, written by Mike O'Connell for Digital Equipment Corporation, aims to clarify the distinction between File Management and true Data Base Management (DBM), addressing confusion in the industry regarding systems labeled as "Data Base Management."

The first chapter reviews File Management, defining a file as a collection of related data records. It highlights that traditional File Management systems do not inherently understand the logical relationships between records or files; this understanding must be explicitly coded into application programs. It describes three file organization methods:

• Sequentially Organized Files: Accessed by physical order.
• Relatively Organized Files: Allow random access by record position.
• Keyed Files: Retrieved based on a key field's content, implemented using either:
  • Hashing: Converts a key into a relative record number for fast retrieval but can suffer from "synonym problems."
  • Indexing (ISAM): Uses an ordered index to locate data records, enabling retrieval by key content and sequential access in logical order. Indexed files support "generic keys" (partial key matching) and "approximate keys" (finding closest values), capabilities generally not available with hashing. Multiple Key ISAM extends this to multiple key fields.

The second chapter discusses Popular "Data Base Management Systems", which the author argues are often enhanced File Management systems rather than true DBM. These systems typically employ "Master Files" (keyed for access) that point to "Detail Files" (containing actual data). While they allow access by multiple key fields, they often use hashing for Master Files, leading to performance issues if synonyms are frequent, and lack the generic/approximate key features of indexed files. Critically, these systems place more responsibility on the user for managing Master Files compared to ISAM's automated index management.

The third chapter defines True Data Base Management. Introduced in the 1960s, DBM treats data as a corporate asset. Its key characteristics include:

• Protection and security for data.
• A single, unified copy and description of data for the entire organization, eliminating redundancy.
• Separation of data definitions from application programs, allowing independent modification.
• Explicit definition of logical relationships between records within the database, removing the need for application programs to hard-code these relationships.

The evolution from File Management to DBM involves:

1. Separating data definitions from programs.
2. Consolidating all data definitions into a machine-readable Schema, providing an objective description of the entire data asset.
3. Adding data structure definitions (relationships) to the Schema.
4. Consolidating physical data files into a single Data Base, managed by the DBM system based on the Schema.
5. Introducing Sub-schemas, which define an application program's specific view of (and access to) a subset of the data base, allowing for subjective data organization and format manipulation.

A new role, the Data Base Administrator (DBA), emerges to manage the company's data asset, including Schema and Sub-schema creation and data access control. The document discusses classic data base structures (sequential, tree, network) and highlights Codasyl's contributions to standardizing DBM. Codasyl systems use a flexible, two-level "set" structure (owner and member records) to define complex relationships, allowing DBAs to define relationships without structural constraints and make physical storage changes without affecting application programs.

In conclusion, the author stresses the importance of selecting the appropriate tool: robust File Management systems can solve many problems, but true Data Base Management is crucial for others. Mismatching the solution to the problem leads to inefficiency and increased costs.