Р абочее м есто

3-й корпус,

1025 123123

О м ГУ

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

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

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

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

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

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

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

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

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

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

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

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

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

2.Физический сбой. Во время работы СУБД возникает аварийная ситуация, причиной которой может быть как ошибка в СУБД или ОС, так и сбой оборудования, и т.д. При этом СУБД может не успеть выполнить операции по преобразованию структуры БД, и многие данные могут быть потеряны. Что должна уметь СУБД?

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

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

1.3.3Мобильность прикладного программного обеспечения

Определение 1.2 Прикладной программой в БД зовется программа пользователя, взаимодействующая с БД посредством СУБД.

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

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

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

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