ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

16 Декабря 2018

Динамические структуры в реляционных базах данных

Dynamic structures in relational databases
Дата подачи статьи: 2015-02-05
УДК: 519.68
Статья опубликована в выпуске журнала № 2 за 2015 год. [ на стр. 95-97 ][ 02.06.2015 ]
Аннотация:В разработке приложений для работы с базами данных есть ряд проблем. Основная причина проблем приложений баз данных лежит в неоптимизированных SQL-запросах и хранимых процедурах. Чтобы добиться хорошей производительности, нужно правильно составлять SQL-запросы, создавать (или удалять) дополнительные индексы, в определенных случаях денормализовывать базу данных, перекладывать часть логики на триггеры и хранимые процедуры. Необходимо поддерживать согласованными методы структурирования алгоритмов, методов структурирования использующихся в этих алгоритмах данных и методов структурирования (построения схем хранения) этих данных в базах данных, основанных на реляционной модели. Работа посвящена генерации и манипулированию в РСУБД структурами данных, чьи компоненты в языках программирования связаны явными указателями. Рассмотрена специфическая, относительно простая структура данных – линейный однонаправленный связный список.
Abstract:There is a set of problems in the development of applications for work with databases. The principal cause of these problems is in non-optimized SQL queries and stored procedures. To achieve good productivity, it is necessary to make SQL queries correctly, create (or delete) additional indexes, denormalize a database (in certain cases), shift a part of logic on triggers and stored procedures. It is necessary to maintain agreed algorithms structuring methods, structuring methods of data used in these algorithms and structuring methods (storage schemes construction) for these data in databases based on a rel a-tional model. This paper is devoted to generation and a manipulation data structures in relational databases whose compo-nents in programming languages are connected by explicit indexes. The author considers a specific, rather simple data stru c-ture. It is a linear unidirectional coherent list. Lists as trees are among the most basic data models used in computer programs. In a sense, lists are simple forms of trees because one can think of a list as a binary tree where every left child is a leaf. How-ever, lists also present some aspects that are not special cases of what we have learned about trees. For instance, we shall talk about operations on lists such as pushing and popping that have no common analog for trees.
Авторы: A.A. Poltavtsev ( ) - Tver State Technical University, Tver, Russia, Ph.D
Ключевые слова: структурирование данных, ограничения целостности, типы данных, абстракции данных, разработка баз данных, реляционная база данных, модель данных
Keywords: data structuring, integrity constraints, data type, data abstraction, database design, relational database, data model
Количество просмотров: 2747
Версия для печати
Выпуск в формате PDF (4.84Мб)
Скачать обложку в формате PDF (0.35Мб)

Размер шрифта:       Шрифт:

There are close analogies between algorithms structuring methods and data structuring methods. As with all analogies, there are distinctions. However comparison of methods for programs structuring and data structuring can explain problems.

An elementary unstructured statement is r-value assignment to a variable. Its corresponding member in data structures is the scalar, unstructured type. Both are the atomic building blocks for composite statements and data types.

The simplest structures obtained using enumeration or sequencing are a compound statement and a structure record. Both consist of a finite (usually small) number of explicitly enumerated components which may be different from each other. If all components are identical, they do not need to be written out individually. For this case we use FOR statement and ARRAY structure to indicate replication by a known finite factor. A choice among two or more elements is expressed by the conditional or the CASE statement and by extensions of record types, respectively.

A repetition by an initially unknown (and potentially infinite) factor is implemented by WHILE and REPEAT statements. The corresponding data structure is the SEQUENCE (file), the simplest kind which allows constructing infinite cardinality.

The question is whether a data structure that corresponds to the PROCEDURE statement in a similar way exists. Naturally, the most interesting and novel property of procedures in this respect is recursion. Values of such a recursive data type should contain one or more components belonging to the same base type, in analogy to a procedure containing one or more calls to itself. Data type definitions should be directly or indirectly recursive as procedures.

The parallelism of corresponding programs and data structures is shown in the Table [1].

Use of data structures corresponding to algorithm simplifies software creation and increases its quality.

The “array”, “record”, and “set” structures were introduced as fundamental data structures [2]. They are called fundamental because they constitute building blocks to form more complex structures. They also appear most frequently in practice. In these structures definition the range of values assumed by these variables is fixed, as well as their storage pattern. Hence, variables declared in this way are said to be STATIC.

Construction Pattern

Program Statement

Data Type

atomic element




compound statement


repetition (i=1_n)





union (variant record)





procedure statement

recursive data

general graph


structure linked by pointers

However, there are many problems which involve far more complicated information structures. The problems are that not only the values but also data structures change during computation. They are called DYNAMIC structures. Naturally, the components of such structures are at some level of resolution are static, i.e. of one of the fundamental data types.

The characteristic property of dynamic structures which clearly distinguishes them from fundamental structures (arrays, records, sets) is their ability to vary in size. Hence, it is impossible to assign a fixed amount of storage for a recursively defined structure.

In programming languages we use pointers for this purpose. The system itself responds for these pointers.

In databases where a relational model considers data as relations and links are implemented only using explicit data, there is a need to create more general data structures in addition to applied domain data. These general data structures should provide an opportunity to manipulate links to applied domain data.

The problem of mapping complex data structures in a database model is mentioned firstly by RDB founder. Unfortunately, it still has no unequivocal decision [3]. The most informative reviews can be found in [4, 5].

The simplest way to connect (to establish interrelation) the set of elements is arranging them in the form of a list or a queue. In this case, each element requires only one connection (link) to address to its descendant.

Knuth [6] is still a fundamental source on list data structures. While it is hard to trace the origins of very basic notions such as “list” or “stack,” the first programming language which used lists as a part of its data model was IPL-V (Newell et al. [7]). Although among the early list-processing languages only Lisp (McCarthy et al. [8]) has survived so far. Lisp, by the way, stands for “LISt Processing”.

The use of stacks in run-time implementation of recursive programs is discussed in detail in Aho, Sethi and Ullman [9]. Aho [10] surveys a number of algorithms involving matching of character strings.

When implementing a storage scheme of a linear unidirectional coherent list in relational database, it is necessary to provide performance of all typical operations with it: construction, insert/removal from a head/ end of the list, an insert/removal of intermediate elements.

Insertion: it is simply to insert an element after the specified one or before it which is more complicated. Removal: to remove an element which is before a specified one or an element which is specified itself that is more complicated. List traverse: the most often executable operation with this structure. It is used when it is necessary to apply the same operation to all list elements. Search of an element with a specified key: it is carried out by consecutive search of elements.

The simplest operation is an insertion of an element into the head of the list. It is necessary to insert an element specifying that its descendant is an element in the head of the list. Given operation is the elementary form of list creation: to create a list it is enough to repeat it a necessary number of times. Thus the order of elements sequence appears inverse to the order of their insertion: the element in a head of the list will be the last inserted. It is often not comprehensible and it is required to insert elements in the end of the list. The drawback of this approach is that the first element is generated by the algorithm distinct from other elements insert algorithm.

In programming languages to work with the list it is offered to have (and to store) an additional pointer in a list head (besides list structure). From these considerations in [11] it is offered to have a field “type” in the list storage table. This field should show whether the given element is the list head or not. The field accepts the following values: the first element of the list is 1, the last element of the list is 2, and the average is 0. If the list has only one element, then the given field value is 3.

In my opinion, an introduction of such a field brings redundancy to a database and it is a violation of relational approach principles. To determine a head of the list it is enough to organize operations with the list, so that the element with the smallest number (or the greatest) will be in a head of the list.

It is also necessary to distinguish two variants of using list structure: a) when the element number is synthetically entered data that is necessary only for implementation and b) when the element number has an applied sense (for example, it should be controlled by the information system programs developer). In first case it is possible to use autoincremental type for “element number” attribute.

Relations for list structure storage:

a) list_1 ((id int IDENTITY(1,1)NOT NULL (PK), next_id int NULL (FK id),

data char(1) NOT NULL)

b) list (id int NOT NULL (PK), next_id int NULL (FK id), data char(1) NOT NULL)

Further, there are some SQL scripts examples for basic lists operations:

1. List formation by inserting an element in the end of the list:


--1. first element insertion ('c')

insert into list_1 (data) values ('c');

--2. subsequent element insertion

DECLARE @prev_id int;

select @prev_id = MAX(id) from list_1

insert into list_1 (data) values ('d');

DECLARE @next_id int;

select @next_id = MAX(id) from list_1

UPDATE list_1

set next_id = @next_id

WHERE id = @prev_id


--1. first element insertion (11,'c')

--insert into list (id, data) values (11,'c')

--2. subsequent element insertion (12,'d')

DECLARE @prev_id int;

SELECT @prev_id = id FROM list WHERE next_id IS NULL

DECLARE @ins_id int;

--SET @ins_id = 12;

insert into list (id,data,next_id) values (15,'g',NULL)

UPDATE list SET next_id = @ins_id WHERE id = @prev_id

2. Inserting an element to the head of the list:

a) DECLARE @first_id int;

select @first_id = MIN(id) from list_1


insert into list_1 (id,data,next_id) values (@first_id - 1,'a',@first_id)


b) DECLARE @prev_id int;

SELECT @prev_id = MIN(id) FROM list

DECLARE @ins_id int;

SET @ins_id = @prev_id-1;

insert into list (id,data,next_id) values (@ins_id,'a',@prev_id)

3. Inserting an element between elements of the list:

a) DECLARE @prev_data char(1);

SET @prev_data = 'e';

DECLARE @next_data char(1);

SET @next_data = 'f';

DECLARE @next_id int;

SELECT @next_id = id FROM list_1 WHERE data = 'f';

insert into list_1 (data,next_id) values ('z',@next_id)

SELECT @next_id = id FROM list_1 WHERE data = 'z';

UPDATE list_1 SET next_id = @next_id WHERE data = 'e'

b) DECLARE @prev_id int;

SET @prev_id = 13;

DECLARE @next_id int;

SET @next_id = 14;

DECLARE @max_id int

select @max_id = MAX(id) FROM list

insert into list (id,data,next_id) values (@max_id+1,'z',@next_id)

UPDATE list SET next_id = (@max_id+1) WHERE id = @prev_id

Naturally, it would be better to form these scripts (and other necessary) as stored procedures. This can allow a reliable storage of all functionality in the database server.

Data models are the abstractions used to describe problems. Data structures are the programming-language constructs used to represent data models. Algorithms are the techniques used to obtain solutions by manipulating data as represented by the abstractions of a data model, by data structures. When a data model of the language in which we are writing a program lacks a built-in representation for the data model of the problem at hand, we must represent the needed data model using the abstractions supported by the language. For this purpose, we study data structures which are methods for representing abstractions in the data model of a programming language, they are not an explicit part of that language. Different programming languages may have strikingly different data models.

This paper showed how a relational theory can be applied to clarify the meaning of certain constructs that are widely used to undertake logical modeling. In particular, we focused on the relationship construct which is central to many modeling methodologies, but seemingly difficult to use in a clear and unambiguous way. We considered relational structures and SQL operations on lists which are an important data model representing sequences of elements. Stacks and queues are important special types of lists.


1.     Wirth N. Algorithms and Data Structures. Prentice/Hall Int. Publ., 1986, 288 p.

2.     Cormen T.H., Leiserson Ch.E., Rivest R.L. Introduction to Algorithms. MIT Press and McGraw-Hill Publ., 2009, 1312 p.

3.     Date C.J. SQL and Relational Theory, 2nd Ed. O'Reilly Media Publ., 2011, 448 p.

4.     Celko J. Trees and Hierarchies in SQL for Smarties. Morgan Kaufman Publ., 2004, 225 p.

5.     Poltavtseva М. Derevya i grafy v relyatsionnoy baze dannykh [Trees and graphs in a relational database]. LAP LAMBERT Academic Publ., 2012, 196 p.

6.     Knuth D.E.  The Art of Computer Programming. Vol. I. Fundamental Algorithms. Addison-Wesley Publ., Reading, Mass, 1968.

7.     Newell A., Tonge F.M., Feigenbaum E.A., Green B.F., Mealy G.H. Information Processing Language-V Manual. Prentice-Hall Publ., Englewood Cliffs, New Jersey, 1961.

8.     McCarthy J. LISP 1.5 Programmer’s Manual. MIT Computation Center and Research Laboratory of Electronics Publ., Cambridge, Mass, 1962.

9.     Aho A.V., Sethi R., Ullman J.D. Compilers: Principles, Techniques, and Tools. Addison-Wesley Publ., Reading, Mass, 1986.

10.  Aho A.V. Algorithms for finding patterns in strings. Handbook of Theoretical Computer Science. Vol. A: Algorithms and Complexity. J. Van Leeuwen (Ed.), MIT Press, Cambridge, Mass, 1990.

11.  Gladkov М., Shibanov S. Complex structures in relational databases. Otkrytye sistemy [Open systems]. 2004, no. 2, pp. 62–67 (in Russ.).

Постоянный адрес статьи:
Версия для печати
Выпуск в формате PDF (4.84Мб)
Скачать обложку в формате PDF (0.35Мб)
Статья опубликована в выпуске журнала № 2 за 2015 год. [ на стр. 95-97 ]

Назад, к списку статей

Хотите оценить статью или опубликовать комментарий к ней - зарегистрируйтесь