Лекция 1. Общие сведения

Показана "табличная" суть базы данных на примере процесса автоматизации табличных расчетов. Введены необходимые понятия и определения. Приведена классификация баз данных и систем управления базами данных. Отмечено, что теория баз данных имеет три основных составляющих: теория создания, теория использования и теория работы (функционирования) баз данных. С позиций реализации баз данных выделено три составляющих: реализация собственно базы данных (система связанных таблиц), интерфейса пользователя и алгоритма приложения.

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

Считается, что понятие "база данных" (БД), а тем более – "система управления базами данных" (СУБД) достаточно сложно в усвоении. Оно значительно упрощается, если понять "физическую сущность" процессов, происходящих в изучаемом программном продукте.

Следует помнить, что многие программные продукты являются средством автоматизации соответствующих ручных процедур, которые просты в понимании. В частности, база данных (при так называемом традиционном подходе к проектированию) служит инструментом автоматизации расчетов, в которых входные и выходные данные представлены в виде системы таблиц с большим числом строк и столбцов в каждой.

Такие расчеты имеют место в процессах проектирования различных процессов, технологий, устройств, блоков; в управлении производством; в курсовых и дипломных проектах.

Подтвердим сказанное простым конкретным примером. Начнем с ручного расчета.

Пример 1.1.

Задание. Имеется склад материалов (M1, М2, М3), снабжающий производство, выпускающее изделия И1, И2. Каждое из изделий состоит из деталей Д1, Д2 и ДЗ, количество которых в изделиях (входимость) известно. Известны и нормы расхода материалов на каждую деталь. Задан – на протяжении месяца – ежедневный план выпуска изделий, который склад должен обеспечить материалами. Длительность технологического цикла (производства) изделий td – 3 дня. Рекомендуется создать страховой запас материалов на складе на один день. Склад периодически заказывает материалы поставщикам. Время τ выполнения заказа г по первому и третьему материалам – 2 дня, по второму – I день. Поставки материалов производятся по первому и третьему материалам – каждый третий день, по второму – каждый четвертый день.

Необходимо ежедневно на протяжении месяца определить (решить задачи):

1) запуск материалов под план производства;

2) заказы па материалы;

3) поставки материалов;

4) движение материалов на складе по дням.

Исходные данные получены из различных источников.

Решение. Поскольку исходные данные получены из разных источников, целесообразно упорядочить их в табличной форме. Вид таблиц может быть различным.

Пусть данные упорядочены в виде системы таблиц: "Материалы", "Детали", "Изделия", "Нормы" (расхода), "Входимость", "План" (выпуска изделий) (табл. 1.1 –1.6).

Таблица I. /

Материалы

Шифр материала	Катанке материала	Единица измерения
Ml	Сталь	кг
М2	Чугун	кг
М3	Железо	кг

Таблица 1.2

Детали

Шифр детали	Катание детали	Единица измерения
Д!	Втулка	шт.
Д2	Фланец	шт.
Д3	Палец	шт.

Таблица 1.3

Изделие

Шифр изделии	Наименование изделия	Единица измерения
И1	Изделие 1	шт.
И2	Изделие 2	шт.

Таблица 1.4

Нормы

Шифр материала	Шифр детали	Единица измерения	Норма расхода
Ml	Д1	кг/шт	2,1
Ml	Д2	кг/шт	1,8
М2	Д1	кг/шт	3,4
М2	Д3	кг/шт	4,3
М3	Д2	кг/шт	1,5
М3	Д3	кг/шт	3,7

Таблица 1.5

Входимость

Шифр детали	Шифр изделия	Единица измерения	Количество
Д1	И1	шт/изд	7
Д2	И1	шт/изд	9
Д2	И2	шт/изд	8
Д3	И2	шт/изд	5

Таблица 1.6

План

Дата	Шифр изделия	Количество изделий
1	И1	7
2	И1	11
3	И1	8
4	И1	9
5	И1	12
6	И1	13
7	И1	9
8	И1	8
9	И1	7
10	И1	9
11	И1	14
12	И1	11
13	И1	8
14	И1	4
15	И!	7
16	И!	5
17	И!	8
18	И1	9
19	И1	10
20	И1	14
21	И1	17
22	И1	12
23	HI	1 1
24	И!	10
25	И1	8
1	И2	5
2	И2	12
3	И2	8
4	И2	7
5	И2	4
6	И2	3
7	И2	15
8	И2	4
9	И2	8
10	И2	7
11	И2	4
12	И2	20
13	И2	25
14	И2	14
15	И2	11
16	И2	10
17	И2	15
18	И2	5
19	И2	7
20	И2	10
21	И2	8
22	И2	4
23	И2	12
24	И2	15
25	И2	18

Структура (совокупность элементов и их связей) приведенных таблиц является линейной.

Однако система исходных таблиц может быть представлена иначе. Например, вместо таблиц "Детали" и "Нормы" может быть построена одна таблица "Детали-Нормы" (табл. 1.7).

Детали-Нормы

Таблица 1.7

Шифр детали	Незнание детали	Единица измерения	Норма расхода материалов (Ml. М2, М3)
Д1	Втулка	шт.	2,1; 2,4: 0
Д2	Фланец	шт.	1,8; 0; 1,5
Д3	Палец	шт.	0; 4,3; 3,7

Нетрудно видеть, что в последнем столбце таблицы "Детали- Нормы" используются списки. Данные такого рола носят название неатомарных. Все остальные данные таблиц являются атомарными.

Возможен и другой вариант организации таблиц "Материалы", "Детали", "Нормы" в виде одной таблицы "Материалы-Детали- Нормы" (табл. 1.8).

Таблица 1.8

Материалы-Детали-Нормы

Шифр материала	Название материала	Единица измерения	Детали			Норма расхода
			Шифр детали	Название детали	Единица измерения
Ml	Сталь	кг	Д1	Втулка	шт.	2,1
		кг	Д2	Фланец	шт.	1,8
		кг	Д3	Палец	шт.	0
М2	Чугун	кг	Д1	Втулка	шт.	3,4
		кг	Д2	Фланец	шт.	0
		кг	Д3	Пален	шт.	4,3
М3	Железо	кг	Д1	Втулка	шт.	0
		кг	Д2	Фланец	шт.	1,5
		кг	ДЗ	Палец	шт.	3,7

В последней таблице имеет место "таблица в таблице". Таблицы "Детали-Нормы" и "Материалы-Детали-Нормы" обладают нелинейной структурой.

Заметим, что в ручном режиме переход от таблиц с линейной структурой к таблицам с нелинейной структурой и наоборот никаких затруднений нс вызывает. Структуру исходных таблиц определяет пользователь, исходя из удобства работы.

Отметим также уязвимость (нарушение целостности данных) "ручных" таблиц с большим числом столбцов и строк: при заполнении таблиц в столбец с числовыми данными по ошибке могут быть записаны символьные данные.

Чтобы уменьшить число таких ошибок, при заполнении подобных таблиц часто накладывают линейку на выбранную строку.

Одновременно акцентируем внимание на технологии формирования системы исходных таблиц:

• создание структуры полей ("шапки") таблицы;

• определение столбцов для связи таблиц в последующих вычислениях (например, столбец "Шифр материала" для таблиц "Материалы" и "Нормы"), хотя явно связи не задаются;

• заполнение таблиц данными.

Снова отметим, что по ошибке в столбце "Нормы" может быть вписано значение, отсутствующее в одноименном столбце таблицы "Материалы" (нарушение ссылочной целостности).

Для получения результатов расчета можно использовать систему таблиц с любой структурой. Для определенности воспользуемся таблицами с линейной структурой. Приступим к решению задач примера.

Задача 1. Специфицированной потребностью (нормой) называют количество материала М., необходимого для одного изделия Иk, если учитывать только деталь Д.

(1.1)

где Н и В – норма и входимость, соответственно.

Для материала Ml, детали Д1 и изделия И1

(1.2)

Количество материала Mik для одного изделия

(1.3)

Для первого материала и первого изделия

(1.4)

В базах данных вычисления вида (1.3) называют агрегированными по сравнению с выражением (1.1). Функцией агрегации здесь является сумма.

Нетрудно видеть, что вычисления (1.1)-(1.4) являются фактически матричными вычислениями вида

которые в числовой форме имеют вид

Если ежедневный план выпуска– текущий день, то ежедневный запуск (потребность в материалах, называемая потребностью в укрупненной номенклатуре), в матричной форме имеет вид

(1.5)

а в числовом виде для первого дня

(1.6)

Перейдем к решению других задач. Задачи 2 и 3 отличаются лишь сдвигом во времени на величину r, поэтому рассмотрим решение лишь третьей задачи.

Задача 3. Величину поставки можно рассчитывать различными способами. Произведем расчет, исходя из средней ежедневной потребности в материалах МС, необходимой для выполнения плана

(1.7)

где Т – количество дней в месяце (в данном случае – 25). Операция (1.7) в базах данных также относится к операциям агрегации с усреднением в качестве функции агрегации.

Очевидно

(1.8)

Тогда величина поставки

(1.9)

или

(1.10)

Ежедневные поставки для первого и третьего материалов (i = 1, i = 3)

(1.11)

для второго материала

(1.12)

Задача 4. Расчет запасов З(t) материалов ведется по формуле

(1.13)

где (t), |t| – моменты и интервалы времени, соответственно. Иными словами, запасы З(t) отличаются от запасов в начале дня. Отметим, что новый запас данного дня становится старым запасом следующего дня.

Очевидно

(1.14)

В общем виде

(1.15)

На этом ручной расчет закончен.

Очевидно, что при небольшом количестве таблиц, столбцов и строк в каждой из них возможен ручной расчет, технология которого не вызывает особых затруднений.

Однако часто задачи содержат более десяти таблиц, в которых свыше 15 столбцов и 20 000 строк. При этом исходные данные могут оперативно изменяться и требуется постоянная корректировка результатов. Электронные таблицы (Excel) здесь использовать неудобно, поскольку связь и целостность данных таблиц обеспечить сложно, да и количество строк в таблице не должно превышать 16 000.

В этом случае без баз данных нс обойтись.

На первый взгляд, технология работы с БД нс должна вызывать осложнений. По-прежнему следует:

• сформировать структуру ("шапку") для всех таблиц;

• определить связи таблиц;

• заполнить их данными.

Для сравнения рассмотрим результаты компьютерной реализации примера 1.1 с использованием, в частности, СУБД Access.

Компьютерная таблица "Детали" (рис. 1.1) полностью совпадает с ручной таблицей "Детали" (см. табл. 1.2).

Схема связей таблиц, созданная до работы БД, показана в явном виде на рис. 1.2.

Следует отмстить, что связи в СУБД Access могут быть заданы и в процессе формирования запросов (выполнения расчетов). Однако предпочтительнее делать это до расчетов, что надежно обеспечит целостность данных:

1) при заполнении подчиненных таблиц компьютер не внесет данные с внешними ключами, отсутствующими в главной таблице (ссылочная целостность);

Рис. 1.1. Таблица "Детали базы данных" в СУВД Access

Рис. 1.2. Схема связей таблиц

2) если не обеспечить ссылочную целостность данных до использования БД, то при ошибочном заполнении компьютер (в процессе запроса) может и не создать связи между таблицами.

Таким образом, выявилось первое ограничение работы с БД.

Из рис. 1.2 видно также, что таблицы имеют линейную структуру.

Заполнение БД данными может быть осуществлено прямо в таблицу (рис. 1.1) или через форму (рис. 1.3), как аналог наложения линейки на строку таблицы при вводе данных в ручном режиме. Вид форм может быть различным. В частности, он может полностью копировать расположение столбцов ручного документа, из которого заимствуются данные для базы данных.

Выходные данные (результаты расчетов) оформляются в виде запросов или отчетов (если к запросам необходимы пояснения).

Сформируем запрос на визуальном языке QBE, не требующем знания программирования.

Запрос, представленный на рис. 1.4, реализует выражение (1.1).

Хотя запрос строится с применением языка QBE, компьютер автоматически формирует оператор на языке SQL, являющимся основным языком работы баз данных.

Рис. 1.3. Форма для заполнения таблицы "Детали"

Рис. 1.4. Расход (неагрегированный) материала на одно изделие

SELECT Primen. [Шифр изделия], Material.[Шифр материала], [Normy]![Норма расхода]*[Primen]![Количество] AS Расход1, Primen. [Шифр детали]

FROM Material INNER JOIN (Normy INNER JOIN Primen ON Νormy.[Шифр детали] = Primen.[Шифр детали]) ON Material.[Шифр материала] = Normy. [Шифр материала]

ORDER BY Primen.[Шифр изделия];

Запрос на рис. 1.5 характеризует агрегированные потребности в в материалах на одно изделие (выражение (1.3)).

SELECT [Primen].[Шифр изделия], [Material].[Шифр материала], Sum([Normy]![HopMa расхода]* [Primen]! [Количество]) AS Расход2

FROM Material INNER JOIN (Normy INNER JOIN Primen ON [Normy].[Шифр детали] = [Primen].[Шифр детали]) ON [Material].[Шифр материала]=[Normy].[Шифр материала]

Рис. 1.5. Расход (агрегированный) материала на одно изделие

Рис. 1.6. Расход материалов на выполнение плана (запуск)

GROUP BY [Primen].[Шифр изделия], [Material].[Шифр материала]

ORDER BY [Primen].[Шифр изделия];

Запрос (рис. 1.6) на основе выражения (1.5) позволяет видеть ежедневные плановые затраты материалов.

Запрос на рис. 1.7 определяет поставки в соответствии с выражениями (1.11)-(1.12)

SELECT Zapusk. Дата, Zapusk.[Шифр материала], llf([Zapusk]! [Шифр материала]="М2",llf([Zapusk]![Дата] Mod 4)=0,[Postavka_sum]![Среднее]*4,0),llf{([Zapusk]![Дата] Mod 3)=0,[Postavka_sum]![Среднее]*3,0)) AS Поставка, llf([Zapusk]![Шифр материала] = "M2", Ilf ({[Zapusk]! [Дата] Mod 3)=0,[Postavka_sum]![Среднее]*4,0),llf(([Zapusk]![Дата] Mod 3)=1,[Postavka_sum]![Среднее]*3,0)) AS Заказы

Рис. 1.7. Поставка материалов

Рис. 1.8. Изменение запасов материалов на складе

FROM Zapusk INNER JOIN Postavka_sum ON Zapusk.[Шифр материала] = Postavka_sum.[Шифр материала];

Нетрудно видеть присутствие в SQL-запросе программного оператора условного перехода

llf([Zapusk]![Шифр материала]="М2"...,

вводимого дополнительно в процессе запроса. Это говорит об ограниченных возможностях языка QBE.

Запрос на рис. 1.8 изменения запасов материалов формируется уже из нескольких предварительных запросов. Автоматизация их выполнения может быть достигнута либо использованием макросов (как в данном случае), либо написанием программы на языке VBA.

Таким образом, еще раз подтвержден факт, что за простоту языка QBE приходится "платить" резким ограничением его возможностей.

На рис. 1.9 показан отчет об изменении запасов материалов. Нетрудно видеть его отличие от запроса (рис. 1.8), на основе которого построен отчет.

На рис 1.10 представлены графики изменения запасов материалов, построенные на основе соответствующего запроса. Отметим, что они несут больше информации, чем таблицы. Более того, можно воспользоваться графиками для принятия решений о выборе величины поставок в выражении (1.10).

Таким образом, при традиционном подходе имеется прямая аналогия процедур ручного расчета с помощью систем таблиц и компьютерного расчета с использованием БД. Хотя при современном подходе эта аналогия имеет завуалированный вид, она позволяет лучше понять процессы, имеющие место в БД.

Рис. 1.9. Отчет о движении материалов на складе

Рис. 1.10. График движения запасов материалов на складе

Напомним, что при ручных операциях особых сложностей не возникает. Они начинаются при обращении к СУБД, поскольку любая из них имеет систему структурных ограничений.

Структуры различных СУБД имеют как общие, так и специфические свойства. Общие структурные свойства определяет модель данных (МД). Она не зависит от содержания конкретной БД и отвечает на вопрос "Каковы общие структурные элементы и как они связаны между собой?".

Известны иерархические, сетевые, реляционные, объектно-ориентированные и объектно-реляционные МД. В настоящее время наиболее широко используются реляционные и объектно-реляционные (гибридные) БД. Имеется тенденция к переходу к объектно-ориентированным МД.

В реляционных МД структурными элементами являются таблицы, а связи между ними осуществляются через ключи. В таблицах выделяют строки (записи) и столбцы (поля), которые и участвуют в различных преобразованиях. Для реляционных МД характерны следующие ограничения.

1. Ячейка (пересечение столбца и строки) должна быть атомарна. В нее не допускается помещать данные в виде списков, подтаблиц и т. д. Атомарность достигается использованием так называемой первой нормальной формы.

2. Линейная структура таблиц. Если структура нелинейна, проводят соответствующее преобразование, называемое нормализацией (построение второй и третьей нормальных форм).

3. Отсутствует наследование таблиц: нельзя получить из какой- либо таблицы другую путем удаления одних и добавления новых полей. Можно лишь формировать новые таблицы-запросы.

Названные ограничения отсутствуют в объектно-ориентированных и расширенных объектно-реляционных моделях данных.

Различия СУБД одной модели данных (в частности, реляционных) могут иметь место по таким характеристикам.

1. По объему хранимых данных – СУБД Access – до 1 Гбайта, СУБД InterBase – до 10 Гбайт, СУБД Oracle – свыше 10 Гбайт. Другими характеристиками могут быть предельное количество столбцов, строк, количество символов в поле.

2. По назначению – СУБД Access, Paradox, FoxPro изначально предназначались для локального варианта, тогда как СУБД SyBase, Informix, SQL Server, Interbase, Oracle – для работы в сети (удаленного варианта).

3. По обеспечению целостности данных, т. е. противодействию внесения неверных данных (например, возраст 1 000 лет) с помощью специальных программ-триггеров – в СУБД Access эти программы являются встроенными, тогда как в СУБД InterBase такие программы вводятся разработчиком БД.

4. По ориентации на уровень пользователя – СУБД Access предназначена прежде всего для начинающих пользователей, практически не знающих языков программирования. Для работы используется визуальный язык программирования QBE, который предполагает у СУБД наличие развитого интерфейса.

Вместе с тем возможности такой СУБД при использовании только языка QBE, как показано ранее, резко ограничиваются.

Так, в примере 1.1 реализация выражений (1.11) и (1.12) требует простейшего программирования (Ilf <условие>; <результат, если условие выполнено>; <результат, если условие не выполнено>).

Сказанное относится и к выражениям (1.13)-(1.15), для реализации которых необходимо программирование либо при помощи макросов, либо с применением алгоритмического языка Visual Basic for Applications (VBA).

В то же время СУБД InterBase рассчитана на так называемых "продвинутых" пользователей, которые знакомы с языками программирования SQL и Object Pascal. Для этой СУБД реализация выражений вида (1.11)-(1.15) не вызывает затруднений.

Таким образом, прикладные примеры для начинающих пользователей проиллюстрированы на СУБД Access (гл. 15), а для "продвинутых" – на СУБД InterBase в среде программного продукта Delphi (гл. 15).

Возможно и далее перечислять ограничения СУБД, однако целесообразнее провести системное рассмотрение процесса работы с базами данных, опираясь на соответствующий набор строгих определений.