1.2. Файлы операционной системы

Файлы и сегодня применяются для хранения данных разнообразной структуры: документов, текстов программ и т.д. Эти файлы обычно создаются и модифицируются с помощью различных текстовых редакторов. Структура текстовых файлов с точки зрения операционной системы проста: это последовательность записей, содержащих строки текста. Файлы с текстами программ используются как входные тексты компиляторов, которые в свою очередь формируют файлы, содержащие объектные модули. С точки зрения файловой системы, объектные файлы также обладают очень простой структурой - последовательность записей или байтов. Система программирования накладывает на эту структуру более сложную и специфичную для этой системы структуру объектного модуля. При этом логическая структура объектного модуля неизвестна файловой системе, эта структура поддерживается системой программирования. Тоже можно сказать и о файлах - образах выполняемых программ. Логическая структура таких файлов остается известной только программе, их порождающей (редактору связей или компоновщику) и загрузчику операционной системы. Та же ситуация с файлами, содержащими графическую и звуковую информацию.

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

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

Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем. При этом существуют

1. приложения, для которых вполне достаточно файлов

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

3. приложения, для которых нужны базы данных.

1.3. Пример базы данных.

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

1. Выдавать списки товаров на складе

2. Выдавать список поставщиков

3. Отражать перемещение товаров от поставщика на склад и в магазин со склада

4. Для каждого поставщика должна быть возможность получения сведений об истории закупок у него товаров, общей сумме закупок за определенный период

5. Необходимо иметь возможность получить общую сумму стоимости товара по цене продажи и по цене закупа на складе

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

Акт приема		684
Поставщик		Тесса ООО
От		16.04.2003

Наименование	Вес,кг	Кол-во	Цена закупочная	Цена продажная
Груша "Анжу"	18	512	635,00р.	645,00р.
Груша "Пэкхем"г	18	448	630,00р.	640,00р.
Груша "Конференс"	12	240	570,00р.	585,00р.
Виноград "Red Globe" красный	8.2	96	515,00р.	510,00р.
Редис	2.5	20	190,00р.	200,00р.

Из рассмотрения этого документа можно сделать вывод, что по каждому факту прибытия товара от поставщика следует хранить следующую информацию:

1. Номер документа

2. Имя поставщика

3. Дата поставки

4. Перечень товаров с указанием их количесва, цены закупа и цены продажи

Перечень поставляемых товаров представляет пример набора данных. Каждая строка этого перечня образует отдельную запись. Будем называть записью упорядоченную совокупность полей, содержащих некоторые значения. В частности, в приемном акте значения полей представлены элементами строки (записи), относящимся к разным колонкам. Так, первая запись состоит из пяти полей, имеющих следующие значения: Груша "Анжу"; 18; 512; 635,00; 645,00. Видно, что значением поля может быть не только число, но и цепочка символов. Заголовок колонки, например Вес,кг, называется именем поля. Поле Кол-во последовательно принимает значения:

512

448

240

96

20

Значения любого поля заключены в пределах некоторого множества величин, определяющего тип поля. Так, Кол-во является полем целого типа, поскульку в него можно заносить только целые числа, Цена закупочная – поле действительного типа, а поле Наименование – поле строчного типа.

Попробуем разобраться, какие наборы данных нужно создать для отражения информации из приемного акта.

Имена, адреса и прочие реквизиты поставщиков должны храниться в наборе данных, который мы будем называть ПОСТАВЩИКИ. Имена и типы полей этого набора данных:

ПОСТАВЩИКИ:

НОМЕР_ПОСТ Целый

ИМЯ Строковый

АДРЕС Строковый

ИНН Строковый

На каждого поставщика в этом наборе данных заведена одна запись. Поле НОМЕР_ПОСТ введено искусственно, каждой записи соответсвует ее уникальный номер. Это может оказаться необходимым, чтобы, в случае, когда имеются два поставщика из разных городов с одним именем, была бы возможность их различать. Будем называть возможным ключом такой набор полей, по значениям которого можно однозначно найти требуемую запись. В наборе данных ПОСТАВЩИКИ очевидно нельзя в качестве возможного ключа использовать поле ИМЯ по упомянутой выше причине. Поэтому возможным ключом следует выбрать совокупность полей ИМЯ и АДРЕС, т. к. невероятно, чтобы у двух фирм с одинаковым названием был бы и одинаковый адрес. Другим возможным ключом является поле НОМЕР_ПОСТ. Еще одно поле, подходящее на роль возможного ключа – ИНН (идентификационный номер налогоплательщика), т. к. он присваивается государственными органами и является уникальным в рамках всей страны. Правда, иностранные поставщики могут не иметь такого реквизита. Таким образом, в наборе данных ПОСТАВЩИКИ имеются три возможных ключа. На практике удобно из них выбрать один, по возможности минимальный по количеству полей, который получит название первичный ключ. В качестве такового выберем НОМЕР_ПОСТ.

В нашей системе необходимо иметь и набор данных, в котором будут содержаться сведения о товарах.

ТОВАРЫ:

НОМЕР_ТОВАРА Целый

НАЗВ Строковый

ОПИСАНИЕ Строковый

Необходимо также определить совокупность наборов данных, в которой будет записываться содержимое приемных актов. Вообще говоря, можно сохранить приемный акт, оформив его в виде одной записи набора данных. В таком наборе данных количество полей в записях должно быть переменным, т. к. перечни товаров в разных приемных актах могут содержать разное количество товаров. Проблемы, связанные с переменностью количества полей, можно разрешить путем усложнения программ работы с наборами данных. Но можно выбрать более простой путь. Вся информация из приемного акта может заноситься в два набора данных – ЗАГОЛОВКИ_ПРИЕМ_АКТ и СОДЕРЖАНИЕ_ПРИЕМ_АКТ. В первом хранится информация, не зависящая от товаров, получаемых по приемному акту, например, название поставщика, дата поставки и т. д. Во втором – информация о поставляемых товарах. Вот примерная структура этих наборов данных:

ЗАГОЛОВКИ_ПРИЕМ_АКТ:

НОМЕР_ПРИЕМ_АКТ Целый

НОМЕР_ПОСТ Целый

ДАТА Временной тип

СОДЕРЖАНИЕ_ПРИЕМ_АКТ:

НОМЕР_ПРИЕМ_АКТ Целый

НОМЕР_ТОВАРА Целый

ВЕС Действительный

КОЛ_ВО Целый

ЦЕНА_ЗАКУП Действительный

ЦЕНА_ПРОД Действительный

В зависимости от наших потребностей хотелось бы иметь две возможности: из набора данных СОДЕРЖАНИЕ_ПРИЕМ_АКТ выбирать строки одного приемного акта либо из всех приемных актов выбрать строки, соответсвующие одному товару (для сравнения цен на один товар от разных поставщиков). Следовательно, надо иметь возможность доступа к этому набору данных как по номеру приемного акта НОМЕР_ПРИЕМ_АКТ так и по товару НОМЕР_ТОВАРА. Что касается набора данных ПОСТАВЩИКИ, то для него надо иметь возможность поиска записи по имени поставщика ИМЯ и по номеру поставщика НОМЕР_ПОСТ. Для того, чтобы получить общую сумму, на которую были поставлены товары одним из поставщиков, система должна будет уметь выбирать все записи о поставках товаров этим поставщиком и посчитать соответствующую сумму.

Кроме того, нам может пригодиться набор данных, в котором будут отражаться текущие остатки товаров на складе. Ясно, что они определяются тем, какие и сколько товаров были получены от поставщиков и какие и сколько товаров были отправлены в магазины. Вот примерная структура такого набора данных:

ОСТАТКИ:

НОМЕР_ТОВАРА Целый

КОЛ_ВО Целый

Если мы попытаемся использовать файлы операционной системы для реализации нашего проекта базы данных, то потребуется выделить по файлу для каждого из соответсвующих наборов данных, приведенных выше. При работе с этими файлами придется в виде подпрограмм реализовать поиск нужных записей по ключевым полям, вставку новых записей, изменение полей записей, вычеркивание записей. В этом в принципе нет большой проблемы. Однако проблема может возникнуть, если мы попытаемся в рамках файлов решить задачу поддержки целостности данных. Например, мы может потребовать от системы, чтобы она следила за содержимым поля НОМЕР_ПОСТ из набора данных ЗАГОЛОВКИ_ПРИЕМ_АКТ и не допускала вставки в этот набор данных записей со значением поля НОМЕР_ПОСТ, отсутсвующем в наборе данных ПОСТАВЩИКИ. Это так называемая ссылочная целостность. (Такое требование означает, что поставку могут осуществить только фирмы, сведения о которых заранее занесены в набор данных ПОСТАВЩИКИ.) Другой пример: в файле ОСТАТКИ данные должны изменяться всякий раз, как только выполняется ввод нового акта приемки (и документа, соответсвующего факту отправки товара в магазин - этот документ по структуре аналогичен акту приемки и здесь особо не рассматривается, хотя помнить о нем надо).

При решение такой задачи требуется поддержка знаний о том, как один набор данных связан с другим набором, т. е. система обязана знать нечто большее, чем просто данные в файлах. Эти добавочные знания называются метаданные. Для решения этой и подобных проблем система должна будет содержать метаданные, в которые входят знания о структуре и смысле каждого поля каждого набора данных (например, поле НОМЕР_ПОСТ в файле ЗАГОЛОВКИ_ПРИЕМ_АКТ и поле НОМЕР_ПОСТ в файле ПОСТАВЩИКИ означают одно и то же). Также система должна “понимать”, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию в другом файле, чтобы их общее содержимое было согласованным. Например, если вводится новый приемный акт о приходе товара от поставщика, то необходимо добавить записи в файл ОСТАТКИ (или модифицировать имеющиеся там записи), чтобы отразить новые значения фактических остатков соответсвующих товаров на складе.

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

Но это еще не все, что обычно требуют от СУБД. Представим себе алгоритм, с помощью которого можно получить общую сумму, на которую были куплены товары у поставщика по имени X. Понятно, что подобные этому алгоритмы придется программировать многократно. Каждый из подобных алгоритмов представляет собой некоторую нетривиальную последовательность циклических действий над содержимым записей нескольких наборов данных. Было бы гораздо проще, если бы СУБД позволяла сформулировать запрос, освобождая программиста от необходимости описывать алгоритм в явном виде на некотором языке программирования. Языки, которые позволяют это сделать называются языками запросов к базам данных. Например, на языке SQL наш запрос можно было бы выразить в форме:

SELECT SUM(КОЛ_ВО* ЦЕНА_ЗАКУП)

FROM СОДЕРЖАНИЕ_ПРИЕМ_АКТ, ЗАГОЛОВКИ_ПРИЕМ_АКТ

WHERE

СОДЕРЖАНИЕ_ПРИЕМ_АКТ. НОМЕР_ПРИЕМ_АКТ =

ЗАГОЛОВКИ_ПРИЕМ_АКТ.НОМЕР_ПРИЕМ_АКТ

AND ЗАГОЛОВКИ_ПРИЕМ_АКТ. НОМЕР_ПОСТ = …

Таким образом, при формулировании запроса, СУБД позволит не задумываться о том, как будет выполняться этот запрос. Среди ее метаданных будет содержаться информация о том, что поле НОМЕР_ПОСТ является ключевым для файла ПОСТАВЩИКИ, а НОМЕР_ПРИЕМ_АКТ - для файла ЗАГОЛОВКИ_ПРИЕМ_АКТ, и система сама воспользуется этим.

Однако всего перечисленного все еще не достаточно для “возведения” нашей системы в “ранг” баз данных. Представим, что в нашей информационной системе выполняется операция ввода нового приемного акта о приходе товаров. Следуя требованиям согласованного изменения файлов, система вставила новую запись в файл СОДЕРЖАНИЕ_ПРИЕМ_АКТ и собиралась модифицировать запись файла ОСТАТКИ, но в этот момент произошло аварийное выключение питания. Очевидно, что после перезапуска системы ее база данных будет находиться в рассогласованном состоянии – строка в СОДЕРЖАНИЕ_ПРИЕМ_АКТ имеется но соответсвующая ей корректировка файла ОСТАТКИ не произведена. “Настоящие” СУБД берут заботу о таких несогласованностях на себя, в результате чего прикладная система не обязана заботиться о корректности состояния базы данных.

Наконец, представим себе, что мы хотим обеспечить параллельную (для нескольких операторов) работу с нашей базой данных. Если опираться только на использование файлов, то для обеспечения корректности на все время модификации любого из файлов доступ других пользователей к этому файлу должен быть блокирован. Таким образом, ввод приемного акта может затормозить ввод документа о передачи товаров со склада в магазин, даже если в этих документах речь идет о разных товарах. Ведь при выполнении обоих операций потребуется модифицировать файо ОСТАТКИ. Настоящие СУБД обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным.

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