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

Данные и модели данных

Существует и другой, не менее важный, подход к пониманию данных и баз данных. Слово данные (data) происходит от латинского слова давать , откуда следует, что данные на самом деле являются заданными фактами, из которых можно логически получить другие факты. (Получение дополнительных фактов из заданных фактов - это в точности то, для чего используется СУБД, обслуживая запросы пользователя.) Заданный факт , в свою очередь, соответствует тому, что в логике называется истинным высказыванием. Например, высказывание Поставщик с номером S1 находится в Лондоне вполне может быть таким истинным высказыванием. Отсюда следует, что база данных в действительности есть набор подобных истинных высказываний [1.2].

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

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

В ячейке 72 находятся две бутылки вина Zinfandel, выпущенные компанией Rafanelli в 1995 году, которые будут готовы к употреблению в 2003 году.

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

Некоторые бутылки вина Zinfandel будут готовы к употреблению в 2003 году.

(Точнее, Некоторые бутылки вина Zinfandel в некоторой ячейке, произведенные некоторым производителем в некотором году, будут готовы к употреблению в 2003 году. )

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

Высказывание в логике - это нечто, что может быть недвусмысленно оценено как истина или ложь. Например, Вильям Шекспир написал Гордость и предубеждение - это высказывание (как видно, ложное).

Модель данных- это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину, с которой взаимодействует пользователь. Упомянутые объекты позволяют моделировать структуру данных, а операторы - поведение данных.

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

Реализация (implementation) заданной модели данных - это физическое воплощение на реальной мащине компонентов абстрактной мащины, которые в совокупности составляют эту модель.

Короче говоря, модель - это то, что пользователи должны знать, а реализация - это то, чего пользователи не должны знать.

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

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

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

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

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

1.4. Назначение баз данных

Почему используются системы с базами данных? Какие преимущества получает пользователь при работе с ними? В некоторой степени ответ зависит от того, о какой системе идет речь - однопользовательской или многопользовательской (точнее будет

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

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

Компактность. Нет необходимости в создании и ведении многотомных бумажных картотек.

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

Низкие трудозатраты. Нет необходимости в утомительной работе над картотекой вручную. Механическую работу машины всегда выполняют лучше.

Актуальность. В случае необходимости под рукой в любой момент имеется точная свежая информация.

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

Администрирование данных и администрирование базы данных

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