Introduction to Database Management and Architecture
Introduction to Informatics Engineering
ICI-104
The Limitations of Physical File Management
Traditional physical file management methods are often insufficient for managing organizational information due to several drawbacks:
- Space Consumption: Physical files occupy significant storage space.
- Slow Search: Searching through physical files can be a slow and tedious process.
- Complex Updates: Updating and optimizing physical files is complicated.
- Data Scatter: Files can be scattered across different departments, leading to inconsistencies, redundancies, and incomplete information.
- Security Challenges: Implementing and maintaining robust security measures for physical files can be complex and may yield unreliable results.
The Rise of Databases
Databases emerged as a solution to address the limitations of physical file management. A database is an integrated collection of related data, coupled with management applications that can be accessed concurrently by multiple users and programs.
Key Features of Databases:
- Centralized data control
- Data integrity
- Minimized data duplication
- Data and application independence
- Concurrent data access
- Cost-effective storage and maintenance
- Versatile relationship representation
- Robust security measures
- Easy modification, upgrade, and optimization
Database Evolution
The evolution of databases can be categorized into three distinct stages:
Stage 1: Sequential File Organization
This stage was characterized by the use of simple, sequentially organized files. Software primarily focused on executing input and output commands for peripherals and storage devices. Data organization within application programs was rudimentary, relying on basic encoding techniques. Sequential files on tapes were the primary storage medium. Data dependence in programs was minimal.
Stage 2: Recognition of File Dynamics
This stage acknowledged the evolving nature of files and storage devices. Efforts were made to shield programmers from the impact of hardware variations. These variations did not affect the logical structure of data as long as the content and basic structure of registers remained unchanged. However, designs were still application-specific, resulting in significant data redundancy. Data structures were primarily sequential, including indexed sequential and direct access methods. The relationship between physical and logical organization was weak.
Stage 3: Enhanced Database Characteristics
This stage focused on improving database features, including facilitating data evolution without incurring high maintenance costs. Data managers gained control over data organization, ensuring optimal structure for general users without requiring extensive knowledge of the management system. Data migration became easier, and effective procedures for data security, integrity, and confidentiality were implemented. This allowed companies to adopt database management systems for various applications. Database designs aimed to address a wider range of problems, incorporating data description languages and command languages for programmers and users.
Database Structure and Architecture
Data Objects in a Database
A database stores information about various data objects, including entities, relationships between entities, indexes, queries, forms, and reports. Each entity has a set of attributes (fields) and specific content. Index files can be created to enable quick access to records within each entity.
Database Management Systems (DBMS)
Database Management Systems (DBMS) are software programs that manage databases. A key characteristic of a DBMS is its ability to work with multiple databases, such as stores, libraries, and calendars. It’s important to distinguish between the database (information or entities) and the DBMS (software that manages the database). However, the term “database” is often used to refer to both the DBMS and the database itself. For example, Oracle and Access are often referred to as databases when they are actually DBMS that create, modify, and update databases.
Three-Level Database Architecture
Database architecture is typically divided into three levels:
External Level
This level is used by individual users, including programmers and end-users. Each user interacts with the database using a specific language. Developers may use more specialized languages, while end-users typically use query languages designed for ease of use. Examples include Visual Basic or C as host languages, Access and SQL as sub-languages, and DBSE as an architectural language.
Conceptual Level
The conceptual level presents a comprehensive view of all information within the database. This presentation may differ from how individual users perceive the data. It provides an overview of the data as it is stored, not as it is perceived by users. This is due to users’ conceptual limitations, language constraints, or the limitations of the tools being used. The conceptual level is defined by a conceptual schema, which defines each record type (entity). The conceptual schema should be independent of data storage representations like pointers and indexes. If the conceptual schema is developed independently of the data, the external schema based on it will also be data-independent.
Internal Level
The internal level is a low-level representation of the entire database, consisting of multiple occurrences of various record types. It is one step removed from the physical level and does not handle data as fixed registers. The internal view is defined by an internal schema, which specifies the types of stored records, associated indexes, field representations, physical record sequence, and other details.