|
|
Лекции и практики (1). Курс лекций и материалы для практических занятий
!
Если какое-либо ограничение целостности может быть включено в структуру БД (на языке DCL), то его надо реализовать именно так.
СУБД проверяет выполнение ограничений целостности при каждой операции модификации данных, если эта операция может нарушить целостность данных. Если ограничения целостности включены в схему БД, они проверяются автома- тически и нельзя внести в базу ошибочные данные. Если же перенести провер- ку ограничений целостности в программу, то гарантировать их соблюдение нельзя. Программа, во-первых, может содержать ошибки, во-вторых, её можно "обойти", обратившись к БД напрямую с помощью команд языка DML.
Необходимо обратить особое внимание на поля таблиц, для которых до- мен определён как список возможных значений. Это ограничение целостности можно реализовать в виде: CHECK(<поле> IN (<список значений>)).
Но такой подход имеет следующий недостаток: добавление нового значе- ния в список потребует изменения схемы отношения (команда ALTER TABLE). Можно поступить до-другому: вынести этот список значений в отдельное от- ношение. Например, список типов образования (начальное, неполное среднее,
среднее, средне-специальное, незаконченное высшее, высшее) для таблицы СОТРУДНИКИ. Таблица ТИПЫ ОБРАЗОВАНИЯбудет состоять из одного по- ля Название типа, определённого как первичный ключ. Тогда поле Образова-ниетаблицы СОТРУДНИКИстанет внешним ключом.
Определение списка значений позволяет гарантировать правильность вводимых данных и правильность поиска. Если не ограничивать значения поля, то оператор может ввести данные произвольным образом, например: 'незакон- ченное высшее', 'незаконч. высшее', 'н. высш.' и т.д. Человек понимает, что это одно и то же, а для СУБД это разные значения, и учесть все возможные комби- нации в условии поиска очень сложно.
Если какое-либо ограничение целостности (ОЦ) нельзя реализовать сред- ствами DCL, то возможны следующие способы его реализации:
С помощью процедурных объектов БД. Чаще всего для этой цели использу- ются триггеры (trigger). Триггер – это процедура БД, которая привязана к конкретной таблице и вызывается автоматически при наступлении опреде- лённого события (добавления, удаления или модификации данных этой таб- лицы). Процедура триггера пишется на том языке, который поддерживается выбранной СУБД (например, PL/SQL для Oracle, Visual Basic для MS SQL Server). Триггер пишется программистом и выполняет те действия, которые обусловлены предметной областью. Например, триггер может осуществлять проверку "возраст принимаемого на работу сотрудника не может быть менее 16-и лет" или присваивать полю "Дата заказа" текущую дату при добавлении нового заказа. Если триггер диагностирует нарушение ограничений целост- ности, он выдаст сообщение об ошибке и команда модификации данных не будет выполнена (произойдёт автоматический откат, rollback).
Программно (т.е. через приложение). Для большей гарантии соблюдения ОЦ желательно проектировать программу так, чтобы внесение изменений в дан- ные и проверка ОЦ выполнялись в одном единственном месте.
Вручную. Ручная процедура обязательно должна быть описана в документа- ции (в руководстве пользователя).
Из всех вышеперечисленных способов самым надёжным является ис- пользование триггеров, т.к. триггеры запускаются автоматически и при внесе- нии изменений в данные вручную, и при программной обработке. Но триггеры сильно замедляют работу БД. Для увеличения эффективности работы можно комбинировать указанные методы реализации ОЦ.
Аномалии модификации данных
После составления концептуальной (логической) схемы БД необходимо проверить её на отсутствие аномалий модификации данных. Дело в том, что при неправильно спроектированной схеме БД могут возникнуть аномалии вы- полнения операций модификации данных. Эти аномалии обусловлены ограни- ченностью структуры РМД (отсутствием агрегатов и проч.).
Рассмотрим эти аномалии на примере отношения со следующими атри- бутами (атрибуты, входящие в ключ, выделены подчёркиванием):
ПОСТАВКИ(Номер поставки, Название товара, Цена товара, Количество, Датапоставки,Названиепоставщика,Адреспоставщика)
Различают три вида аномалий: аномалии обновления, удаления и добав- ления. Аномалия обновления может возникнуть в том случае, когда информа- ция дублируется. Другие аномалии возникают тогда, когда две и более сущно- сти объединены в одно отношение. Например:
Аномалия обновления: в отношении ПОСТАВКИона может возникнуть, если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во все кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы.
Аномалия удаления: при удалении записей обо всех поставках определён- ного поставщика все данные об этом поставщике будут утеряны.
Аномалия добавления: в нашем примере она возникнет, если с поставщи- ком заключен договор, но поставок от него ещё не было. Сведения о таком поставщике нельзя внести в таблицу ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и название товара) и другие обязательные атрибуты.
Для решения проблемы аномалии модификации данных при проектиро- вании реляционной БД проводится нормализация отношений.
Нормализация отношений
В рамках реляционной модели данных Э.Ф. Коддом был разработан ап- парат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы.
Декомпозицией схемы отношения R называется замена её совокупно- стью схем отношений Аi таких, что
∪
R Ai ,
i
и не требуется, чтобы отношения Аi были непересекающимися. Декомпозиция отношения не должна приводить к потере зависимостей между атрибутами сущностей. Для декомпозиции должна существовать операция реляционной ал- гебры, применение которой позволит восстановить исходное отношение.
Покажем нормализацию на примере отношения КНИГИ(табл. 9.1):
Id– идентификатор (первичный ключ),
Code– шифр рубрики (по ББК – библиотечно-библиографической класси- фикации),
Theme– название рубрики (по ББК),
Title– название книги,
Author– автор(ы),
Editor– редактор(ы),
Type– тип издания (учебник, учебное пособие, сборник и.т.п.),
Year– год издания,
Pg– количество страниц.
Введём понятие простого и сложного атрибута. Простой атрибут – это атрибут, значения которого атомарны (т.е. неделимы). Сложный атрибут мо- жет иметь значение, представляющее собой конкатенацию нескольких значе- ний одного или разных доменов. Аналогом сложного атрибута может быть аг- регат или повторяющийся агрегат данных.
Таблица 9.1. Исходное отношение КНИГИ
ID
|
Code
|
Theme
|
Author
|
Title
|
Editor
|
Type
|
Year
|
Pg
|
20
|
22.18
|
МК
|
Бочков С.
|
Язык программи- рования СИ
|
Садчиков
П.
|
учебник
|
1990
|
384
|
Субботин Д.
|
Седов П.
|
10
|
22.18
|
МК
|
Джехани Н.
|
Язык АДА
|
Красилов
А.
|
учебник
|
1988
|
552
|
Перминов
О.
|
35
|
32.97
|
ВТ
|
Соловьев Г.
|
Операционные
системы ЭВМ
|
|
учебное
пособие
|
1992
|
208
|
Никитин В.
|
11
|
32.81
|
Кибер- нетика
|
Попов Э.В.
|
Общение с ЭВМ на естественном
языке
|
Некрасов А.
|
учебник
|
1982
|
360
|
44
|
32.97
|
ВТ
|
|
ПУ для ПЭВМ
|
Витенберг
Э.
|
спра-
вочник
|
1992
|
208
|
89
|
32.973
|
ЭВМ
|
Коутс Р.
|
Интерфейс «чело- век-компьютер»
|
Шаньгин В.
|
учебник
|
1990
|
501
|
Влейминк
И.
| |
|
|
Скачать 1.01 Mb.