5.Разработка интерфейса. На этом этапе проектируются экранные формы и отчеты для ввода и представления информации.

6.Разработка дополнительных модулей обработки информации. При необходимости создаются дополнительные процедуры или запросы для обработки и поиска информации, хранящейся в БД.

7.Тестирование и отладка информационной системы. На этом этапе происходит актуализация БД (ее заполнение реальной информацией), отладка дополнительных модулей обработки информации.

8.Внедрение. На этом этапе разрабатывается документация по использованию спроектированной информационной системы, обучение персонала, устранение ошибок.

9.Эксплуатация.

Первые три этапа относятся к так называемому «бумажному» проектированию, т. е. выполняются без использования компьютера, хотя существуют специальные программные средства (caseтехнологии, не относящиеся к СУБД, например, ERwin или Rational Rose), которые позволяют автоматизировать эти операции. От того, насколько правильно и тщательно выполнены первые три шага, зависит успех всей разработки рассматриваемой БД.

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

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

1.2.Категории баз данных

ВБД имеется два различных уровня описания и представления данных: физический и логический.

7

На физическом уровне принята следующая терминология.

1.Поле – наименьшая единица памяти, обрабатываемая СУБД.

2.Физическая запись – упорядоченная совокупность фикси-

рованного количества полей. Две физические записи однотипны, если совпадают по составу полей.

3.Файл – совокупность однотипных записей.

4.Блок – размер памяти, передаваемой из внешнего запоминающего устройства в оперативно-запоминающее устройство

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

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

На логическом уровне принята следующая терминология.

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

2.Логическая запись – фиксированная совокупность элементов данных. Две логические записи однотипны, если состоят из одинаковых совокупностей элементов данных.

3.Отношение – совокупность всех однотипных логических записей. Обычно (для простых СУБД) соответствует файлу.

4.Схема БД – совокупность отношений с установленными связями и ограничениями целостности.

Пример логического уровня представлен на рис. 1.1.

Рис. 1.1. Пример логического уровня

8

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

1)не может быть двух сотрудников с одним и тем же табельным номером;

2)не может быть так, чтобы один и тот же инвентарный номер соответствовал различному оборудованию.

Эти поля являются первичными ключами. Запись из отношения «Сотрудники» нельзя удалить, если с ней связана запись из отношения «Рабочее место». То же самое справедливо и для отношения «Оборудование».

Пример физического уровня представлен на рис. 1.2.

Сотрудники

Рис. 1.2. Пример физического уровня

В обязательном порядке должны быть проиндексированы ключевые поля записей:

•индексные файлы для табельного номера сотрудника в первом файле;

•индексные файлы для инвентарного номера сотрудника во втором файле;

•индексные файлы для табельного и инвентарного номеров

втретьем файле.

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

9

1.3.Требования к базе данных

1.3.1.Неизбыточность и непротиворечивость данных

Если каждое приложение работает со своей системой файлов,

ане с единой БД, то в рамках одной прикладной области неизбежно дублирование данных. Следствием этого будет противоречивость: в одном приложении информация была изменена, а в другом – нет. Например, в отделе кадров сотрудника уволили, а в бухгалтерии он еще числится и получает зарплату; причина этого в том, что единственная связь между отделами – это бумажная документация,

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

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

приложение или пользователь.

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

1.3.2. Защита данных от программных и аппаратных сбоев

Все виды защиты данных должны обеспечиваться СУБД.

Сбои бывают двух видов: логические и физические.

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

максимально простым. Ситуация называется ошибкой II рода. Физический сбой. Во время работы СУБД возникает аварий-

ная ситуация, причиной которой может быть как ошибка в СУБД или операционной системы, так и сбой оборудования и т. д. При этом

10