The Architectural Logic Of Database Systems

The Architectural Logic of Database Systems

If we look back to pre-database systems and the data units which were in use, we will establish a hierarchy starting with the concept of 'field' used to build 'records' which were in turn used to build higher data units such as 'files'. The file was considered to be the ultimate data unit of information processing and data binding 'monolith'. Moreover, pre database systems were designed with one or more programming languages in mind and this in effect restricted independent develop ment and modelling of the applications and associated storage structures. Database systems came along not to turn the above three units into outmoded concepts, but rather to extend them further by establishing a higher logical unit for data description and thereby offer high level data manipulation functions. It also becomes possible for computer professionals and other users to view all information processing needs of an organisation through an integrated, disciplined and methodical approach. So, database systems employ the concepts field, record and file without necessarily making them transparent to the user who is in effect offered a high level language to define data units and relation ships, and another language to manipulate these. A major objective of database systems is to allow logical manipulations to be carried out independent of storage manipulations and vice versa.

The Architectural Logic of Database Systems

Architecture of a Database System

Architecture of a Database System presents an architectural discussion of DBMS design principles, including process models, parallel architecture, storage system design, transaction system implementation, query processor and optimizer architectures, and typical shared components and utilities.