Relational databases, Relational data model - Databases: design

Relational databases

It is incorrect to assume that only relational databases are used in information systems. Often you can see the implementation of databases based on the hierarchical, network, relational and other models. However, most information systems are based on relational databases, the foundation of which was laid by E. Codd in the late 1960s, defining the basic rules and operations that should be applied in the implementation of such databases. Many database models that can be found in information systems, one way or another are based on the principles of relational databases and use various additional tools to improve the work with certain types of data, for example, with geographic data, real-time data (streaming data), multidimensional data, etc.

The basis in relational databases is the relational data model, built on the basis of relational algebra, which forms the basic rules for working with data in the relevant databases.

Relational Data Model

The construction of a relational data model is based on the understanding that any data set can be represented in the form of a relationship that is formatted, but the form of the table (Figure 1.12), where the data is represented

attributes and values ​​at the intersection of the corresponding attribute with the record (tuple).

Fig. 1.12. An example of a relation in a relational model


The term Relation we mean a set of data combined in a set of records (tuples) and described by a header containing a set of attributes.

In the example above, the entire collection of job values ​​and the header part with the named attributes, over which the values ​​are placed, is called a relation. In terms of formal logic, the relation in general form can be represented as follows:

R {A, T}, i = {1..n} (11)

In this view, A means an attribute describing one characteristic of the data, and by T - the type of data that the data represented in relation to must match. The example above is an informal statement of the relationship. Its header does not specify the data types that describe the information presented in the body of the relationship.

Typically, the relationship header, where the names of the attributes and their types are specified, is called a relationship scheme, and the set of interrelated relationship schemes is called a data schema. The relationship header contains standardized data types or types derived from standardized types, and a set of values ​​associated with a specific attribute of a standard or derived data type is referred to as a domain.

Water by the term Domain in the theory of databases we mean an admissible set of named values ​​of one type having a certain meaning

From this definition it follows that the domain has the following properties:

• The domain carries a certain semantic load, which is expressed in understanding the meaning of the data described, which usually coincides with the understanding of data in the domain;

• The domain is defined simply or derived from a simple data type, which allows you to use simple logical operations on data;

• A domain can contain a logical condition that allocates a specific subset of data that is valid for this domain.

The body of the relation is constructed from a set of records, which in terms of relational algebra are called tuples and represent information existing in the domain in the framework of the object or group of interrelated objects.

Thus, according to the definition of a tuple, it includes all possible data that obey the rules defined by individual domains. Each element of the tuple data corresponds to only one domain and obeys all properties that are defined by this domain.

The tuple description uses a number of important properties, some of which are presented below:

each tuple contains only one value for each of the attributes that characterize the relation;

for components of a tuple, similar to domain elements, no ordering is assumed;

every subset of tuples is represented as a tuple.

By combining domains and tuples, you can form a relation that is generally defined as follows:

R [& lt; Header & gt;] {& lt; List of Tuples & gt;}. (1.2)

The relationship header is represented as a comma-separated list of attributes. Also important is the fact that the second parameter of the relation, when correctly represented, is denoted by the term Body & quot ;, which contains a plurality of tuples. But to simplify informal communication and simplify the presentation, the term Body is replaced by the Tuple & quot ;, meaning that all tuples form a relationship body. In addition to understanding the terms Tuple & quot ;, Domain and Body in the theory of relational databases, a restriction is established according to which all tuples of the same relation refer to the same type of tuple, and it (the tuple type) should be exactly the same as it is defined in the relationship header. Thus, all rules for the representation of data, defined in the header, apply to all relationship tuples.

Given the definitions of the relation, tuple and domain described above, we can formulate the basic properties of the relation. For an example of relationship properties, consider the ratio of information about employees of the organization, including the attributes of tuples, but the full name of the employee, his position and salary. These attributes will form the header of the relationship, forming domains for the relationship. Each header attribute contains not only the name of the attribute, but also its type (Figure 1.13), which defines possible types of stored data by their representation, processing and constraints.

Fig. 1.13. Sample Employee Relationships

Any relationship in a relational database is characterized by the following properties:

1. Each tuple contains only one value of the corresponding type for each attribute (the ratio is normalized).

Each attribute in the presented example within the tuple is assigned only one value, which is visible at the intersection of the selected domain employee's name and a tuple with a name "Petrov Petrov Petrovich". The ratio that corresponds to this property is normalized, i.e. is in this case in the first normal form, 1NF.

2. Attributes are not ordered by any rule.

Previously, it was determined that the components of the tuple are not ordered, and since the tuple must match the attributes of the header unambiguously, these attributes are also not ordered. It should be understood that a person, when presenting data structures, always applies certain rules for ordering attributes and tuples, but it is important to remember that such an ordering is not important and is not taken into account when working with relational databases. Therefore, the concepts First Attribute or Second Attribute to relational model objects are not applicable, and there can be no question of the term Next attribute or Previous attribute .

This situation gives a certain rigidity in working with databases, improving the quality of the program data processing code, which is often not always obvious when programming with less rigidity.

3. Tuples are not ordered by any rule.

This property follows from the fact that the body of the relationship is represented

a set that is not ordered by mathematical rules. Since relational relations obey the rules of working with mathematical sets, then the mathematical apparatus of working with sets is applied.

Of course, when presenting a relationship on paper, a person will try to arrange it in some way to make it easier to process. However, this reflection of the relationship is not the rule and is just a representation of the relationship. The relation itself remains unordered, and presenting it in another order of tuple arrangement, the relation itself does not change, and the same processing operators can be applied to it as for the relation with another ordered representation. From this it follows that for realization in databases an ordered representation of the relationship makes no sense, which means that any relation in the databases is unordered.

4. There are no duplicates of tuples in relation to.

This property of the relationship follows from the understanding that the body of the relation is represented by a set, and any set, taking into account its mathematical representation, does not contain duplicates. From this it follows that by taking any tuple represented by all used with respect to attributes, it will be impossible to find a single tuple with exactly the same attribute values.

At the same time, this property illustrates the differences between the relationship and the table. Realizing that the data table is the physical implementation of relationships in the database, you can place records with the same values ​​there, unless, of course, you provide such an opportunity at the level of the program logic for building a database, and the relation, by definition, never contains duplicate tuples.

Often, when there is no need to reflect the values ​​described in relation to (the relationship body), in the relational model, they are limited only by indicating the header of the relationship with the naming of the relationship itself or only the relationship name. Such representations of the relational data model are filtered mappings that are used in specialized tools for modeling database structures, such as in IBM InfoSphere Data Architect (Figure 1.14).

Fig. 1.14. An example of a relational data model


The basic information contained in the relational data model is the names of the relationships (entities), attributes, and attribute types that describe the relationship. In addition, the relational model reflects the relationships between the relationships (entities) that make it possible to display the interaction of the elements of the bodies of the related relations. Each of these components of the relational model has a number of auxiliary characteristics that clarify.

Vila representation and processing of body elements of the relationship. Although these characteristics are not explicitly visualized in the data model, they are taken into account when representing relationships in their entirety, taking into account the representation of the relationship body.

The data model presented in the example uses a display filter that takes into account the need to display the name of the relationship (entity), the attributive composition of each relationship, and the relationship between the relations. The absence in the visualization of the model of attribute types and other characteristics does not mean that they are not defined or do not exist. It just means that the data model is presented to consider only the specified parameters, and all other characteristics are fixed in the hidden components of the model. For example, another variant of the representation may be the case shown in Fig. 1.15.

Fig. 1.15. An example of an extended representation of the relational data model


In this view, in addition to the name of the relationship (s) and attributes, the data types that characterize the relationship body are displayed, although the body itself does not appear in these models. It should be borne in mind that the data model (database model) in specialized modeling tools is oriented to a further representation in the form of a database structure and indicating the bodies of relations is inappropriate. In this connection, in the database models, as a rule, the bodies of relations are not shown. If the model is built specifically to reflect operations with relationships, in the full sense of the term, then all relationships must be represented with bodies that illustrate possible values ​​that will later be stored in the database tables.

Such a separation often introduces some confusion in the correctness of using a particular data model (database model), which requires a more accurate description of their use. Thus, a data model in the form of relationships is used when it is necessary to illustrate possible operations on relationship data and to understand the correctness of interpretation in the domain model represented by objects with their possible instances. The data model in the form of entities and links (ELE model) is used to form a logical (infologic) database model without specifying specific data values ​​and is aimed at further presentation in the form of a database structure. The model in the form of tables and links is built on the physical level, reflecting the features of data representation and processing at the DBMS level. The result is a representation of the relational data model in three basic variants (Table 1.3).

Table 13

Variants of representation of relational data models

View type




A model with a reflection of the name of the relationship, attribute composition, links




Data type

Used to simulate a logical data structure for a subsequent transition to a physical layer

A model with header and body reflections with possible data

The ratio



Data type



Used to represent the possible values ​​of data and, if necessary, to analyze possible operations on relationships and data in relationships

A model with mapping of physical data representation structures to DBMS



Data type


Used to display a representation of the structure that will be implemented at the physical level in the DBMS


Note: This section discusses the presentation forms of the database model, which is reflected in three options. It should be borne in mind that the modeling of the database is based on the implementation of modeling levels, and therefore there is an interpretation of the data models in accordance with these levels, which are represented by other types of relational models, as will be discussed later. In this regard, we should not take the list of models presented above as exhaustive, realizing that there may be other representations and other types of models.

Also We Can Offer!

Other services that we offer

If you don’t see the necessary subject, paper type, or topic in our list of available services and examples, don’t worry! We have a number of other academic disciplines to suit the needs of anyone who visits this website looking for help.

How to ...

We made your life easier with putting together a big number of articles and guidelines on how to plan and write different types of assignments (Essay, Research Paper, Dissertation etc)