All large databases use a DBMS


The terms “database” and “database management system” (DBMS for short) can perhaps be best understood by looking at a method for managing data, often referred to as a “file system”, which was established in the 1960s and 1970s partly still used today. This is characterized by a static assignment of programs and the data that they require.

Example: At the school, master data of the students such as first name, surname, date of birth are required at various points, e.g. in the secretariat, in the library and at the institution (person) that divides courses. All use different programs and manage their own student file.

The problems that arise here can be seen:

  1. Data redundancy, i.e. the same data is saved multiple times.
  2. Risk of data inconsistency, i.e. if changes are made, contradictions can arise due to the multiple stored data. If a student leaves school, he is deleted with program I in the secretariat, but with III it is still divided into courses. (It should even have happened that such fictional students then also received grades.
  3. Inflexible to changes, in short, changes to the data structure require changes to the programs, additional tasks require new data organization, as this was geared to the old objective. Queries across multiple databases can hardly be carried out in this system (for example, a query about the library data and the course division: "Do students in advanced German courses read more classical literature?").
  4. Data protection problems and data security, users or programs have full access to at least the data assigned to the program. (For example, the library program could delete all borrowers, i.e. student data, due to a malfunction.)
  5. Difficult compliance with standards, i.e. databases are stored in different places in different formats and are not easily exchangeable. For example, the student data in the secretariat can be in a format that the library program does not understand, so that this data has to be entered there separately.

These problems are to be avoided with the concept of the database and the DBMS. The DBMS centrally manages all data of a company, an institution, a project, etc. Redundancies and inconsistencies can be avoided in this way, different standards are no longer necessary.

The data are organized according to their logical connections and not according to the requirements of special applications. The DBMS provides users, that can be people, but also programs, with the data in a form that they can use. If an application changes, the data organization no longer has to be changed, but only a new "external view" of the data has to be created. Data security and data protection can be guaranteed more easily. Through his specific view, a user only has access to data that is “allowed” for him. The DBMS can help avoid errors by means of specific controls when entering, deleting and changing data. For example, it is not possible to assign courses to a fictitious student, i.e. a student who does not exist in the student sub-database. One speaks here of maintaining data integrity.

What has been said above makes it clear that there are very different views of a database. It makes sense to distinguish between three levels:

  1. External view, as already explained above, this is how the data is presented to the user.
  2. Logical overall view, the logical relationships and dependencies of the data are described here. The abstraction that leads from the real world to this logical overall view is also known as the conceptual model.
  3. Internal view, the implementation of the data on a computer system is described here. It is about questions such as: which data are grouped into units (data records) on a mass storage device and how is it (quickly) accessed (search tree, hash table, etc.)

Ideally, the three levels are completely independent of each other, i.e. that e.g. a different internal organization of the data should not change anything in the conceptual model. The connections are created through transformations, which of course would have to be designed differently in the event of changes on one level.

In an ANSI definition of this 3-level model, a distinction is also made between three entities (possibly persons) who are responsible for the individual levels: application administrator, company administrator and database administrator. To what extent such a strict differentiation makes sense and is actually practiced remains to be seen. What is important, however, is that there are users who have access to the database at the external level, and an entity that creates a conceptual model of the company and one that takes care of the internal organization of the data.