This series of articles describes a brain wave model that is significantly different from traditional models. I strongly recommend those who have just joined to start reading from the first part.

In 1970, Edgar Codd published an article (Codd, 1970), in which he described the basics of the relational data storage model. Practical implementation all modern relational databases have become this model. The formalization of the model led to the creation of the relational calculus and relational algebra.

The main element of the relational model is a tuple. A tuple is an ordered set of elements, each of which belongs to a specific set or, in other words, has its own type. The set of tuples homogeneous in structure forms a relation.

All this looks a little more clearly in terms used in databases (figure below). A relationship is a table of data. A tuple is a table row. What type of tuples a relation contains, or, equivalently, what the format of the rows in a table is, is determined by the title of the relation or table. Each of the columns in the table forms a domain. The values ​​that domain elements can take are called attributes. Table rows are a collection of attributes that correspond to domains.

Example relationship (Zaborov)

The rows of a table can be identified by their attributes, that is, by what values ​​the elements of the tuple take. The very content of a tuple makes it different from the others. But it may turn out that some strings will match in their attributes. The coincidence itself is not scary, but it no longer allows such a set of attributes to be used to uniquely identify tuples in a relation. To make the identification unambiguous, enter such a key field, which for each line takes on a unique value. Such a key can carry a semantic load, or it can simply be an artificially generated number.

The collection of all relationships defines the database. Each relation stores its own logical piece of information. To obtain specific information, it may be necessary to correlate information from different relationships. Codd described eight basic relational algebra operations for manipulating tuples:

• Union;
• Intersection;
• Subtraction;
• Cartesian product;
• Sample;
• Projection;
• Compound;
• Division.

A wonderful property of relational algebra is its closedness, that is, operations on relations are specified in such a way that the result itself is a relation. That is, having several tables and performing the appropriate operations on them, we will also get a table as a result.

The meaning of many operations coincides with the corresponding operations from set theory. A general idea of ​​their essence is given in the figure below.

An example of operations on tuples (Zaborov)

It is important that different relationships can contain domains of the same type. This means that if two tuples contain the same domains, inside them the same attributes, then we can talk about a certain connection between tuples containing these attributes. In other words, if different rows of the same table in one of the columns have the same values, then we can talk about a certain relationship between these rows. Or if different tables have columns (domains) with the same meaning, then rows with the same values in these columns are linked.

The projection operation allows one to obtain a relationship consisting of a part of the elements of the original relationship, limiting the set of domains used. Selection or selection allows you to obtain relations containing only those tuples whose fields satisfy the selection conditions. For example, you can select only those tuples whose specified domains have target values attributes.

The totality of all operations on relations allows you to extract any information of interest from the database and form it in the form of a relation (table) with predetermined properties (title).

The relational data model did not arise by chance, but was a consequence of the need to operate with large amounts of diverse data. It turned out that such a data storage structure and operations defined in this structure are convenient for solving a wide range of applied problems. It can be assumed that a similar successful solution could have been groped by nature as a result of natural selection.

The system of identifiers, concepts and event memory we are describing is very similar to the relational model in many ways. A number of analogies can be cited:

• A neuron operates on information from several dendritic segments, each of which is tuned to data of a certain type. Dendritic segments of the same type can be associated with a specific domain;
• Combinations of concepts that describe information specific to the dendritic segment correspond to attributes found in the domain;
• The concepts used by the bark zone and the identifiers that define the packet structure specific to this zone determine the structure of the domains (header);
• Usage general concepts in projection of information between zones, corresponds to the use of common domains in different respects;
• The set of cortex areas that form the brain corresponds to the set of relationships that form the database;
• The associativity, between memories, corresponds to the connection through the common attributes of the various tuples;
• The distribution of memory across cortex zones corresponds to how one event can generate several tuples in different relationships, united by a single unique key;
• A wave describing the current state of the brain can act as an analogue of a query to a database. Just as the result of an operation on relationships is a relation, so the brain's response can be a set of associatively related descriptions combined in one wave picture.

Of course, there is no exact match between our brain model and relational systems. The architecture of the brain is much richer, since it solves not only the tasks of storing and retrieving data, but also a lot of other functions combined with this. However, even the existing similarities make it possible to better understand the essence of information processes originating in the cortex.

Relational data model

The relational model is based on the set-theoretic concept of a relationship. In mathematical disciplines, there is a concept ʼʼ attitude ʼʼ (relation), the physical representation of which is table ... Hence the name of the model - relational .

In relation to a database, the concepts "relational database" and "tabular database" are synonymous. Relational databases are the most widespread in the world. Almost all database products created since the late 1970s are relational.

In 1970, papers appeared discussing the use of various tabular data models. The most significant of these was an article by an employee of a firm IBM dr E.F. Codd (A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), where he first applied term "relational data model" ... The System R project was developed in a research laboratory at IBM Corporation. This project was conceived with aim prove the practicality of the relational model. Relational DBMS refers to DBMS second generation.

Goals creating a relational data model:

1. Providing more high degree data independence.

2. Build a solid foundation to address data consistency and redundancy issues.

3. Extension of data management languages ​​by including operations on sets.

Commercial systems based on the relational data model began to appear in the late 70s and early 80s. Today there are several hundred types of different relational DBMSs.

The relational model is a convenient and most common form of data representation in the form tables (relationship ). Every relationship has name and consists of named attributes (columns) of data. One of the basic advantages of the relational model is its uniformity... All data is stored in tables in which each row has the same format. Each row in the table represents some real-world object or relationship between objects.

The basic concepts by which the relational model is defined are as follows:

1. relational database - a set of normalized relations;

2. attitude - file, a flat table consisting of columns and rows; a table in which each field is atomic;

3. domain - aggregate permissible values, from which the value of the corresponding attribute of a certain relation is taken. From a programming point of view, domain - ϶ᴛᴏ data type;

4. universe - a set of values ​​for all fields or a set of domains;

5. cortege - record, table row;

6. cardinality - the number of rows in the table;

7. attributes – named fields, table columns;

8. degree of attitude - the number of fields (columns);

9. relationship diagram - an ordered list of attribute names;

10. relational database schema - a set of relationship schemes;

11. primary key - a unique identifier with non-repeating records - a column or a subset of columns that uniquely identify rows.

A primary key that includes more than one column is commonly referred to as plural , or combined , or composite , or super key .

Object Integrity Rule states that the primary key should not be completely or partially empty.

The relationship between these concepts is illustrated in Fig. 4.5.

№	Full name	Year of birth	Position	Department
1.	Ivanov I. I.		Head department.	22
2.	S. S. Sidorov		Prof.	22
3.	Andreeva G.G.		Prof.	22
4.	Tsvetkova S. S.		Assistant professor
5.	Kozlov K.K.		Assistant professor	22
6.	Petrov P. P.		Art. Rev.	22

		Attributes

rice. 4.5. Basic concepts of the relational data model.

Sometimes different columns are selected as the primary key in a table. A dedicated key is a key that is explicitly listed with the relational schema. Otherwise, one speaks of an implicit key, or a possible key, or a candidate key.

12. external key - ϶ᴛᴏ a column or subset of columns from one table that can serve as a primary key for another table. The foreign key of a table is a reference to the primary key of another table. Since the purpose of building a database is to store all data, if possible, in one instance, then if a certain attribute is present in several relations, then its presence usually reflects a certain relationship between the rows of these relations.

Foreign keys implement relationships between database tables.

A foreign key, like a primary key, can be a combination of columns. In practice, a foreign key will always be composite if it refers to a composite primary key of another table. The number of columns and their data types in the primary and foreign keys must match.

In case a table is related to several other tables, it can have several foreign keys.

Each relational table possesses the following properties:

Has a name ĸᴏᴛᴏᴩᴏᴇ differs from the names of all other tables;

Data in table cells must be structurally indivisible. It is unacceptable that a table cell contains more than one piece of information. For example, the number and series of the passport should be located in different columns of the table;

All columns in the table are homogeneous, ᴛ.ᴇ. all elements in a column have the same type (numeric, character, etc.) and length;

Each column has a unique name;

There are no identical rows in the table;

The order of rows and columns must be arbitrary, regardless of their reordering, the relationship will remain the same, and therefore have the same meaning.

The basic concepts of the relational data model are concepts and types. Classification and features of the category "Basic concepts of the relational data model" 2017, 2018.

In mathematical disciplines, the concept of "table" corresponds to the concept of "relation" (relation). The table reflects the real world object - essence, and each of its lines reflects a specific instance of the entity. Each column has a name unique to the table.

Strings have no names, their order is not defined, and the number is not logically limited. One of the main advantages of the RMD is its uniformity (each row of the table has the same format). It is up to the user to decide whether the respective entities are homogeneous. This solves the problem of model suitability. The main elements of the RMD are shown in Fig. 17.

A relationship is a two-dimensional table containing some data.

The essence- an object of any nature, data about which is stored in the database.

Attributes- properties that characterize the entity (columns). The degree of relationship is the number of columns.

Relationship diagram- a list of attribute names, for example EMPLOYEE (No., full name, year of birth, position, department).

Domain– a set of values ​​of the attributes of a relation (data type). Strictly speaking, domain there is potentially possible set of values.

Domain properties: a domain is a set, although in general its values ​​cannot be simply enumerated. Thus, properties are inherited from the set:

Limitation: domain has a border, data is divided into possible and impossible. As with a set, this does not mean that the number of elements is finite.

Uniqueness: you can compare some elements with others and avoid duplicates. For one single domain, this goes without saying.

Domain concept helps correctly simulate subject area

Domain and attributes. A tributes must be linked to domains, or "defined on a domain." Multiple attributes can be specified on the same domain.

Atomicity of values: attribute values ​​should be simple, atomic, not compound.

Naturalness of domains. D Omenas should be meaningful. It is more useful to treat a domain as a certain group of parameters for describing a subject area, to a certain semantic concept.

As a rule, many subject areas are already sufficiently formalized, and have ready-made concepts and reference books.

Limit unnecessary comparisons between attributes - the main purpose of domains.

Tuple- table row.

Cardinality (power)- the number of rows in the table.

	Full Name	Year of birth	Position	Department code
	Ivanov I.I.
	Petrov P.P.		Professor
	Sidorov S.S.
	Vasiliev V.V.
	Vovkin V.V.		teacher
	Stepanov S.S.		Professor

Figure 17. Elements of the relational model

The concept of a database is closely related to such concepts of structural elements as a field, record, file (table),

field , - an elementary unit of the logical organization of data, which corresponds to an indivisible unit of information - an attribute. The following are used to describe the field. specifications :

name , for example. Surname, Name, Patronymic, Date of birth;

type of , for example, character, numeric, calendar;

length , for example, 15 bytes, and the maximum will be determined possible amount characters

accuracy , for numeric data, such as two decimal places to display the fractional part of a number.

Recording- a set of logically related fields. A record instance is a separate record implementation that contains specific values ​​for its fields.

File(table) - a set of instances of records of one structure.

A table in a relational data model can be viewed as a class of objects of the same type .

Thus, for objects of the same class, the set of properties will be the same, although the values ​​of these properties for each object, of course, may be different.

Data types allowed in the relational data model.

Basic data types used in data models:

Short Integer - short integer;

Long Integer - long integer;

Float - real number (floating decimal point number);

Double - real number (floating decimal point) double precision;

Text - text data type;

Logical - logical (yes / no);

Data - temporary. The value is defined as a date with a specified separator in the specified format;

Blob - large binary objects (binary large object - BLOB), which can store data of unlimited size. Fields of this type allow you to store dimensionless arbitrary binary information.

Key element (primary key) of data is an element that can be used to determine the values ​​of other data elements. Two or more data values ​​can uniquely identify an object.

Primary key– it is an attribute that uniquely identifies relationship strings. A multi-attribute primary key is called a composite primary key. The primary key cannot be completely or partially empty (null).

Practical meaning the primary key is obvious: a domain object is uniquely described using a set of table attributes. The primary key captures the most important thing in an object, its unique essence. The rest of the fields can be called “just attributes”.

The keys that can be used as primary are called potential or alternativekeys.

External key - serves to link tables. These are values ​​from one table, by which you can unambiguously link to another. More precisely, for a relationship, a foreign key is a set of predefined attributes

External key - it is an attribute (s) of one table that can serve as the primary key of another table. It is a reference to the primary key of another table (Figure 18).

Figure 18. Relationship link

Relationship STUDENT (name, group, specialty) and SUBJECT (Name Pr, Clock) related attitude STUDENT_PREDMET (full name, name of pr, assessment) where foreign keys Full name and Name_Pr form a composite key.

A relational data model is a logical data model created by Edgar Codd that describes:

• data structures in the form of (time-varying) sets of relationships;
• set-theoretic operations on data: union, intersection, difference, and cartesian product;
• special relational operations: selection, projection, join and division;
• special rules to ensure data integrity.

Edgar Frank "Ted" Codd - (23 August 1923 - 18 April 2003) - British scientist, whose work laid the foundations of the theory of relational databases. While at IBM, he created a relational data model. In 1970 he published A Relational Model of Data for Large Shared Data Banks, which is considered the first work on the relational data model.

A relational data model is a way of looking at data, that is, a prescription for a way to represent data (through tables) and for a way to work with such a view (through operators). It deals with three aspects of data: structure (objects), data integrity and processing (statements).

In 2002, Forbes magazine ranked the relational data model as one of the most important innovations of the past 85 years.

The goals of creating a relational data model:

• providing a higher degree of independence from data;
• creating a solid foundation for solving semantic issues and problems of data consistency and redundancy;
• extension of data management languages ​​by including operations on sets.

Data structure in a relational data model

The relational data model provides for a data structure, the required objects of which are:

attitude;

attribute;

domain;

tuple;

degree;

cardinality;

primary key.

A relationship is a flat (two-dimensional) table made up of columns and rows:

An attribute is a named column of a relationship.

A domain is a set of valid values ​​for one or more attributes.

A tuple is a relationship string.

The degree is determined by the number of attributes it contains

Cardinality is the number of tuples that a relation contains.

A primary key is a unique identifier for a table.

Correspondence between formal terms of the relational data model and informal ones:

• relation (formal term) - table (informal term);
• attribute - column;
• a tuple is a string or record;
• degree - the number of columns;
• cardinal number - number of lines;
• primary key is a unique identifier;
• domain is a general set of valid values.

Relationships and their implementation in the relational data model

Attitude R on multiple domains D1 , D 2 , …, D n is a subset of the Cartesian product of these domains:

R ⊆ D 1 × D 2 × ... × D n

Example 1. Domains defined: D1 - many names of teachers, D2 - many audiences, D3 - many study groups, D4 - many academic disciplines. Record the relationship: 1) assigning teachers to training courses; 2) the schedule of classes in groups.

1) assignment of teachers to training courses:

R ⊆ D 1 × D 4 .

This attitude defines a multitude of teachers leading a multitude of academic disciplines.

2) the schedule of classes in groups:

R ⊆ D 2 × D 3 × D 4 .

This attitude defines a multitude of classrooms in which classes are taught in a multitude of disciplines for a multitude of learning groups.

Relationship properties:

• unique name of the relationship;
• unique name of the attribute;
• no identical tuples;
• tuples are not ordered from top to bottom;
• attributes are not ordered from left to right;
• all attribute values ​​are atomic (normalized ratio).

Thus, a relational database is a set of normalized relationships. In order to move on to the types of relationships, we introduce the concept of a relationship variable. A relationship variable is a named object whose value can change over time. A relationship variable at different times is different database tables that have different rows but the same columns.

Relationship types:

• named relation;
• basic attitude;
• derived relation;
• expressed attitude;
• view;
• snapshots;
• the result of the request;
• intermediate result.

A named relation is a relation variable defined in a DBMS (database management system) through the operator CREATE(CREATE TABLE, CREATE BASE RELATION, CREATE VIEW, CREATE SNAPSHOT).

A base relationship is a named relationship that is not derived. The existence of the underlying relationship is independent of the existence of other relationships.

A derived relationship is a relationship that is defined through other named relationships. The derived relation depends on the existence of other - basic - relations.

An expressible relation is a relation that can be obtained from a set of named relations by means of some kind of relational expression. Each named relation is an expressible relation, but not vice versa. Examples of expressed relationships are base relationships, views, snapshots, intermediate and final results. The set of all expressed relations is the set of all basic and all derived relations.

A view is a named derived relation. Presented in the database as a definition. The view is not stored in the physical memory of the database management system (DBMS), but is formed using other named relations.

Snapshots are the same as a view, but physically saved and periodically refreshed.

The result of the query is an unnamed derived relation. The DBMS does not ensure the persistence of query results. To save the result of a query, you can assign it to a named relation.

An intermediate result is an unnamed derived relation that is the result of a subquery nested within a larger expression.

Relationship Keys in the Relational Data Model

Relationship keys can be as follows:

• super key;
• potential key;
• primary key;
• external key;
• surrogate key.

Relationship key is a subschema of the original relationship schema, consisting of one or more attributes, for which the condition of uniqueness of values ​​in relationship tuples is declared. When declaring the schema of the underlying relationship, multiple key declarations can be specified.

The relationship key can be simple or compound. A simple key is a key that contains at most one attribute. Composite key-key consisting of two or more attributes.

A superkey is an attribute or set of attributes that uniquely identifies a tuple of a given relationship. It can include additional attributes. The superkey does not have the property of non-redundancy.

A potential key is a subset of the attributes of a relationship that satisfies the requirements of uniqueness and non-redundancy. It has the following properties. Uniqueness: There are no two different rows in the table with the same values ​​in our potential key. Non-redundancy: you cannot remove one of the columns from the key so that it does not lose its uniqueness. There can be more than one potential key in a relationship.

The primary key (PK) is one of the potential keys of the relationship, chosen as the primary key. One and only one primary key can be declared. Primary key attributes cannot be Null.

A foreign key (FK) is a key that is declared in a base relationship, which at the same time refers to the primary of the same or some other underlying relationship.

A surrogate key is a service attribute added to the existing informational attributes of a relationship. The purpose of a surrogate key is to serve as the primary key of a relationship. The value of this attribute is generated artificially.

Example 2. There is a network of pharmacies database. It contains the "Pharmacies" table, which contains all the pharmacies of the chain, and there is the "Preparations" table. In addition, there is an "Availability" table, which records the availability of drugs at each pharmacy. The availability table contains the following fields: "Pharmacy" (it contains drugstore identifiers), "Drug" (it contains drug identifiers), "Quantity". A problem arises: if a certain amount of the drug arrives at the pharmacy, you may not notice that the same drug is already contained in a certain amount in the same pharmacy and make a new entry in the table in which the pharmacy and the drug will be repeated. How can this problem be avoided at the key level?

Solution. You can declare a composite key consisting of a pharmacy ID and a drug ID as the primary key of the "Availability" table. Then in the table it is impossible to repeat the combination of the pharmacy and the device in different records. The primary key can be not only simple, but also composite.

Data Integrity in a Relational Data Model

Relational integrity concepts:

• determinant NULL;
• integrity of entities;
• referential integrity;
• corporate integrity constraints.

NULL qualifier. A Null value denotes the fact that the value is undefined. Null is not of any data type and can be present among the values ​​of any attribute defined on any data type. A two-place "arithmetic" operation with Null yields Null. Comparison with Null yields UNKNOWN.

Integrity of entities. The requirement for entity integrity means that the primary key must fully identify each entity, and therefore no null values ​​are allowed in any primary key value. The attribute value must be atomic.

Referential integrity. The requirement of referential integrity is that for each foreign key value that appears in the relation-value tuple of the referenced relation variable, or in the relation value of the relational variable pointed to by the reference, there must be a tuple with the same primary key value, or the value the foreign key must be completely undefined. There are rules for removing a tuple from a referenced relationship.

Referential integrity: deleting a tuple. There are three approaches to removing a tuple from a referenced relationship.

1. Delete restriction – Delete: Restrict.
2. Cascade delete – Delete: Cascade.
3. Setting a NULL value, transferring a foreign key value to an undefined state - Delete: Set NULL.

Limit deletion. It is forbidden to delete a tuple for which there are links. First, you need to either remove the referencing tuples or change their foreign key values ​​accordingly.

Cascade deletion. When you delete a tuple from a referenced relationship, all referenced tuples are automatically removed from the referenced relationship.

Setting the value to NULL. When a referenced tuple is deleted, the foreign key value is automatically completely undefined in all referenced tuples.

Example 3. There is a news portal database. It contains a table "Headings" (politics, economics, sports, etc.), there is a table "Author" (surnames and names of authors). There is a table "Texts", in which in each record about the text of the news there are fields "Heading" (with identifiers of headings from the corresponding table) and "Author" (with identifiers of headings from the corresponding table). What methods can be used to ensure that the referential integrity of the data is observed when deleting a category and author?

Solution. The first way: to prohibit the deletion of a category or author from the corresponding tables, if the "Texts" table contains links to this category or to this author. Second way: ask automatic deletion from the "Texts" table of records in which this heading or this author appears. The third way: if a category or an author is deleted from the corresponding tables in the referencing tuples of the "Texts" table, the identifier values ​​of this category or this author become undefined (NULL).

How it's done at the language level SQL queries- in the material SQL ALTER TABLE - modify a database table .

Corporate integrity constraints are additional rules for maintaining data integrity that are defined by users or database administrators.

Relational databases and the SQL language

Relational data model.

The relational data model was proposed by the mathematician E.F. Codd E.F. in 1970. RMD is the most widely used data model and the only one of the three main data models for which a theoretical basis has been developed using set theory.

The RMD is based on the concept of a relation that is a subset of the Cartesian product of domains. A domain is a set of values ​​that an element can take (for example, a set of integers). A subset of the Cartesian product of domains is called a relationship.

The elements of a relationship are called tuples. The elements of a tuple are commonly referred to as attributes. A relationship contains information about entities of the same type. Each tuple of a relationship corresponds to one instance of an entity.

Properties of relations.

The relationship has two main properties:

• - the relation should not have the same tuples, since this set;
• - the order of the tuples in the relation is irrelevant.

It is convenient to represent the relation as a table, where the row is a tuple, the column corresponds to the domain (Fig. 3, students relation).

Domain 1. Domain 2 ... ... ... domain 3 (key). .domain 4. ... .. .domain 5

A relational database is a database that is divided into logically coherent segments called tables, and within the database, these tables are related to each other. A relational database allows you to divide your data into logical, smaller and more manageable chunks, which provide an optimal view of the data and the ability to organize multiple levels of data access.

Fig. 3. An example of a tabular representation of a relationship

Characterization of the relational data model.

Although the concept of a relational data model was first introduced by the founder relational approach Edgar Codd, the most common interpretation of the relational data model, apparently belongs to the famous popularizer of Codd's ideas Christopher Date, who reproduces it (with various refinements) in almost all of his. According to Data's interpretation, the relational model consists of three parts that describe different aspects of the relational approach: the structural part, the manipulation part, and the integral part.

In the structural part of the model, it is fixed that the only generic data structure used in relational databases is the normalized n -ary relation. The concepts of domains, attributes, tuples, title, body, and relation variable are defined. In fact, in the two previous sections of this lecture, we examined precisely the concepts and properties of the structural component of the relational model.

The manipulation part of the model defines two fundamental mechanisms for manipulating relational databases - relational algebra and relational calculus. The first mechanism is based mainly on classical set theory (with some clarifications and additions), and the second - on the classical logical apparatus of the first-order predicate calculus. We will consider these mechanisms in more detail in the next lectures, but for now we will just note that the main function of the manipulation part of the relational model is to provide a measure of relativity of any particular language of relational databases: a language is called relational if it has no less expressiveness and power than relational algebra or relational calculus.

Basic principles of the relational approach.

The current relational approach to building information systems is the most common. The advantages of the relational approach include:

• 1. the presence of a small set of abstractions that make it relatively easy to model most of the common subject areas and allow precise formal definitions, while remaining intuitive;
• 2.the presence of a simple and at the same time powerful mathematical apparatus, based mainly on the theory of sets and mathematical logic and providing a theoretical basis for the relational approach to database organization;
• 3. the possibility of non-navigational data manipulation without the need to know the specific physical organization of databases in external memory.

• 1. Rule of information. All information in the database should be presented exclusively at the logical level and in only one way - in the form of values ​​contained in tables.
• 2. The rule of guaranteed access. Logical access to each and every item of data (atomic value) in a relational database must be provided by using a combination of table name, primary key, and column name.
• 3. Rule of support for invalid values. A true relational database must support invalid values ​​that differ from a zero-length character string, string whitespace characters and from zero or any other number and are used to represent missing data regardless of the type of that data.
• 4. Rule of a dynamic catalog based on the relational model. The description of the database at the logical level must be presented in the same form as the master data so that users with the appropriate rights can work with it using the same relational language that they use to work with the master data.
• 5. Rule of a comprehensive data sublanguage. The relational system can support different languages ​​and modes of interaction with the user (for example, question and answer mode). However, there must be at least one language whose operators can be represented as strings of characters according to some well-defined syntax and which fully supports the following elements:
  • · Data definition;
  • · Definition of views;
  • · Data processing (interactive and software);
  • · Conditions of integrity;
  • · Identification of access rights;
  • · Transaction boundaries (start, end and cancel).
• 6. Rule for updating views. All views that are theoretically upgradeable should be upgradeable.
• 7. The rule of adding, updating and deleting. The ability to work with a relation as a single operand should exist not only when reading data, but also when adding, updating, and deleting data.
• 8. Rule of independence of physical data. Application programs and utilities for working with data should at the logical level remain intact with any changes in the way data is stored or methods of access to it.
• 9. The rule of independence of logical data. Data applications and utilities must logically remain intact when any changes are made to the underlying tables that theoretically allow the data contained in those tables to remain intact.
• 10. The rule of independence of integrity conditions. It must be possible to define integrity conditions specific to a particular relational database in a sublanguage of the relational database and store them in a directory rather than in an application program.
• 11. Rule of independence of distribution. A relational database management system should not depend on the needs of a particular client.
• 12. The rule of uniqueness. If there is a low-level language in the relational system (processing one record at a time), then it should not be possible to use it in order to bypass the rules and integrity conditions expressed in the relational language high level(processing multiple records at a time).