ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.03.2021
Просмотров: 1588
Скачиваний: 23
106
элем
возможные
варианты
допустимых
для
использован
.
Исполь
опи
аксиса
ограничений
ключевые
слова
имеют
след
сл
.
Ограни
т
о
указания
у
атрибута
како
тых
(
нео
группы
атрибутов
,
для
котор
ми
в
данн
ачения
(
есл
арушают
уник
бра
одн
м
й
й
л
вне
та
.
Ограничение
так
Тип
бы
вне
До
т
Огр
о
атр
реа
т
UP
нар
при
таблицы
,
предназначенной
для
ента
,
а
вертикальная
черта
разделяет
ия
элементов
зуемые
при
сании
синт
ы
ующий
см
буе
чение
NOT
NULL
–
тре
обязательног
го
-
либо
конкретного
значения
,
т
.
е
.
не
допускает
в
столбце
пус
пределенных
)
значений
.
Ограничение
UNIQUE
означает
,
что
значение
атрибута
или
ых
указано
это
ограничение
,
должны
быть
уникальны
н
ой
таблице
.
При
этом
для
данных
атрибутов
допускаются
NULL
-
з
и
не
указано
ограничение
ается
,
что
они
не
н
NOT NULL
),
счит
альности
строк
таблицы
.
Ограничение
PRIMARY
KEY
означает
,
что
столбец
или
группа
столбцов
о
зуют
первичный
ключ
таблицы
.
То
есть
значения
столбца
или
комбинация
значений
столбцов
должны
быть
уникальными
в
таблице
и
для
них
не
допустимы
NULL
-
значения
.
Ограничение
PRIMARY
KEY
эквивалентно
овременно у
использованию
ограничени
NOT
NULL
и
UNIQUE
.
Ограничения
FOREIGN
KEY
и
REFERENCES
определяют
внешни ключ
таблицы
.
Ограничение
REFERENCES
…
д я
столбца
определяет
простой
шний
ключ
,
т
.
е
.
ключ
,
состоящий
из
одного
атрибу
FOREIGN
KEY
…
REFERENCES
…
для
таблицы
может
определять
как
простой
,
и
составной
внешний
ключ
,
т
.
е
.
ключ
,
состоящий
из
нескольких
атрибутов
.
ы
столбцов
внешнего
ключа
и
столбцов
,
на
которые
он
ссылается
,
должны
ть
одинаковыми
.
Столбец
или
группа
столбцов
,
на
которые
ссылается
шний
ключ
,
должны
иметь
ограничения
PRIMARY
KEY
или
UNIQUE
.
пустимо
внешнему
ключу
ссылаться
на
атрибуты
той
же
самой
аблицы
.
аничение
внешнег
ключа
нарушается
,
если
значения
составляющих
его
ибутов
в
какой
-
либо
строке
таблицы
не
совпадают
со
значениями
атрибутов
,
которые
он
ссылается
,
ни
в
одной
из
строк
на
родительской
таблицы
.
Ссылочная
спецификация
определения
внешнего
ключа
определяет
кцию
сис емы
на
попытку
совершения
действий
при
выполнении
команд
DATE
и
DELETE
над
родительской
таблицей
,
которые
могут
привести
к
ушению
согласованности
значений
внешнего
и
родительского
ключей
.
Приведем
несколько
примеров
,
иллюстрирующих
использование
веденных
выше
видов
ограничений
.
Запрос
SQL
для
создания
СТУДЕНТЫ
хранения
индивидуальной
информации
о
студентах
.
107
CREATE
TABLE
СТУДЕНТЫ
(
КОД
_
СТУД
INTEGER
PRIMARY
KEY
,
ФИО
CHAR
(
20
)
NOT
NULL
,
ДАТА
_
РОЖД
DATE
NOT
NULL
,
АДРЕС
CHAR
(
60
)
(
5
C
L
,
а
а
н
о
столбец
СТЬ
,
пред
н
ПАСПОРТ
CHAR
(
15
)
NOT
NULL UNIQUE
,
СТИПЕНДИЯ
NUMERIC
(
4
),
КУРС
INTEGER CHECK
(
КУРС
>
0
AND
КУРС
<=
6
),
ФАКУЛЬТЕТ
CHAR
0
)
FOREIGN
KEY REFERENCES
ФАКУЛЬТЕТЫ
ON
UPDATE
ASCADE
ON
DELETE
SET
NUL
СТАРОСТА
INTEGER FOREIGN
KEY REFERENCES
СТУДЕНТЫ
ON
DELETE
SET
NULL
);
В
этом
запросе
все
ограничения
указываются
в
описании
столбцов
(
ограничения
столбца
).
Эти
ограничения
имеют
следующий
смысл
:
•
для
столбца
КОД
_
СТУД
установлено
ограничение
первичного
ключа
PRIMARY
KEY
,
эквивалентное
паре
ограничений
NOT
NULL
и
UNIQUE
;
•
для
столбц
ПАСПОРТ
установлено
ограничение
NOT
NULL
,
требующее
обязательного
указания
значения
поля
,
и
ограничение
UNIQUE
,
требующее
уникальности
его
значений
(
это
поле
фактически
является
альтернативным
ключом
);
•
для
столбц
КУРС
установлено
ограничение
CHECK
,
задающее
допустимый
диапазон
его
з ачений
;
•
столбец
ФАКУЛЬТЕТ
объявлен
внешним
ключом
(
FOREIGN
KEY
),
ссылающимся
(
REFERENCES
)
на
одн именный
таблицы
Ф
,
причем
при
обновлении
в
этой
табл
АКУЛЬТЕТЫ
ице
указанного
родительского
ключа
,
должны
каскадно
обновляться
соответствующие
значения
поля
ФАКУЛЬТЕТ
и
в
таблице
СТУДЕНТЫ
(
ON
UPDATE
CASCADE
),
а
при
удалении
записи
о
факультете
в
таблице
ФАКУЛЬТЕТ
соответствующие
значения
в
таблице
должны
СТУДЕНТЫ
должны
устанавливаться
в
NULL
;
•
столбец
СТАРОСТА
также
объявлен
внешним
ключом
,
ссылающимся
на
первичный
ключ
самой
таблицы
СТУДЕНТЫ
,
при
этом
,
при
удалении
из
таблицы
записи
о
студенте
,
на
которого
была
хотя
бы
одна
ссылка
,
как
на
старосту
,
эта
ссылка
должна
устанавливаться
в
NULL
.
Другой
пример
SQL-
запроса
для
создания
таблицы
УСПЕВАЕМО
назначе ной
для
хранения
результатов
сдачи
студентами
экзаменов
по
конкретным
дисциплинам
.
108
CREATE TABLE
УСПЕВАЕМОСТЬ
(
КОД
_
СТУД
INTEGER
,
КОД
_
ДИСЦ
INTEGER
,
ОЦЕНКА
INTEGER
NOT
NULL
,
_
О
,
Д
_
ВНЕШН
_
КЛ
FOREIGN
KEY
(
КОД
_
СТУД
)
REFERENCES
СТУДЕНТЫ
ON
UPDATE
CASCADE
ON
DELETE
NO
ACTION
),
CONSTRAINT
FOREIGN
KEY
(
КОД
_
ДИСЦ
)
CONSTRAINT
ОЦЕНКА
_
ОГР
CHECK
(
ОЦЕНКА
>=2
AND
ОЦЕНКА
<=5));
•
о
,
н
Д
_
ДИСЦ
м
,
все
попытки
обновления
значения
кода
дисциплины
в
этой
•
ести
значение
атрибута
ОЦЕНКА
,
л
ДАТА
_
СДАЧИ
DATE
NOT
NULL
,
CONSTRAINT
УСП
_
ПЕРВ КЛ
PRIMARY
KEY
(
К Д
_
СТУД КОД
_
ДИСЦ
),
CONSTRAINT
КОД
_
СТУ
КОД
_
ДИСЦ
_
ВНЕШН
_
КЛ
REFERENCES
ДИСЦИПЛИНЫ
,
В
этом
запросе
кроме
ограничений
столбцов
используются
и
ограничения
таблицы
.
Поясним
эти
ограничения
:
•
для
столбцов
ОЦЕНКА
и
ДАТА
_
СДАЧИ
запрещено
использование
NULL
-
значений
,
то
есть
система
должна
требовать
обязательного
ввода
действительных
значений
оценки
и
даты
сдачи
экзамена
;
граничение
таблицы
УСП
_
ПЕРВ
_
КЛ
объявляет
составной
атрибут
{
КОД
_
СТУД
,
КОД
_
ДИСЦ
}
первичным
ключом
отношения
;
•
ограничение
таблицы
КОД
_
СТУД
_
ВНЕШН
_
КЛ
объявляет
столбец
КОД
_
СТУД
внешним
ключом
,
ссылающимся
на
одноименный
первичный
ключ
таблицы
СТУДЕНТЫ
,
причем
,
при
обновлении
значения
кода
студента
в
родительской
таблице ссылающиеся
на
их
(
если
они
есть
)
значения
столбца
КОД
_
СТУД
таблицы
УСПЕВАЕМОСТЬ
должны
каскадно
обновляться
,
а
попытки
удаления
записи
о
студенте
в
таблице
СТУДЕНТЫ
при
наличии
ссылающихся
на
него
записей
в
таблице
УСПЕВАЕМОСТЬ
должны
отвергаться
(
спецификация
NO
ACTION
);
•
ограничение
КОД
_
ДИСЦ
_
ВНЕШН
_
КЛ
объявляет
столбец
КО
внешним
ключом
,
ссылающимся
на
одноименный
первичный
ключ
таблицы
ДИСЦИПЛИНЫ
,
приче
родительской
таблице
,
или
удаления
какой
либо
записи
из
этой
таблицы
,
в
случае
наличия
хотя
бы
одной
ссылки
на
это
обновляемое
или
удаляемое
значение
кода
дисциплины
,
должны
отвергаться
(
по
умолчанию
действует
опция
NO
ACTION
);
и
,
наконец
,
ограничение
ОЦЕНКА
_
ОГР
устанавливает
допустимый
диапазон
значений
этого
поля
.
Любая
попытка
вв
ежащего
вне
диапазона
2 ÷ 5,
также
будет
отвергнута
системой
.
10.
Проектирование
базы
данных
Предыдущий
раздел
был
посвящен
вопросам
представления
в
базе
данных
и
одного
з
важных
видов
информации
о
предметной
области
–
ограничений
целостности
данных
.
В
частности
,
были
рассмотрены
такие
важные
виды
ограничений
целостности
,
как
ограничения
потенциальных
ключей
и
ограничения
ссылочной
целостности
.
Эти
,
одни
из
важнейших
видов
ограничений
целостности
,
являются
,
однако
,
частными
случаями
представ
ных
разного
рода
отношений
(
зависимостей
)
между
сущностя
информа
темы
ительно
,
ограничение
иа
со
что
одного
атрибута
(
атрибутов
)
однозначно
опред
ения
други атрибутов
в
отношении
.
О аничени
них
ключе
вает
на
зависим
значения
атрибутов
одного
отношения
от
значе
тов
другог
отношения
.
Несомненно
,
одной
ейших
с
их
задачи
проектирования
базы
данны
вляется
но
боле
е
представление
в
ней
разнообразны
отноше
висимост
сущностям
предметной
области
и
обеспечение
зма
поддер
мых
в
системе
данных
в
процессе
ее
в
,
соответств
щем
этим
отношениям
.
этой
зрения
изложенной
в
предыдущем
разделе
информации
меха
поддержа
ных
там
ограничений
цел
лучшим
об
кретной
сово
шений
.
просов
,
связанных
с
тем
,
каки
данных
.
Как
уже
яет
собой
набор
норм
ного
материала
,
долж
едметной
области
,
вообще
гово
отношений
,
впло
о
т ы
эквивалентными
критериев
,
позв
ской
структуры
базы
ления
в
базе
дан
тной
ми
предме
тенц
области
ключа
ционной
сис
в
том
,
.
Действ
значения
по
льного
стоит
еляют
знач
х
гр
е
внеш
й
указы
ость
ний
атрибу
о
что
из
важн
оставляющ
х
я
возмож
а
е
адекватно
х
ний
(
з
ей
)
между
и
механи
жания
храни
функционирования
состоянии
ую
С
точки
о
низме
ния
описан
остности
недостаточно
для
того
,
чтобы
ответить
на
вопрос
–
как
наи
разом
представить
данную
предметную
область
в
виде
кон
купности
базовых
(
хранимых
)
реляционных
отно
е
во
Темой
данного
раздела
является
рассмотрени
м
образом
можно
построить
«
хорошую
»
реляционную
базу
говорилось
выше
,
реляционная
база
данных
представл
ализованных
таблиц
-
отношений
.
Исходя
из
уже
изучен
но
быть
ясно
,
что
одна
и
та
же
информация
о
пр
ря
,
может
быть
представлена
с
помощью
различных
наборов
ть
до
того
,
чт
вся информация
може
б ть
представлена
с
помощью
одной
нормализованной
супертаблицы
.
Очевидно
,
что
такие
различные
формы
логической
структуры
базы
данных
не
будут
полностью
с
точки
зрения
удобства
и
эффективности
использования
содержащейся
в
ней
информации
,
возможности
поддержания
данных
в
целостном
состоянии
.
Задача
проектирования
базы
данных
заключается
в
выборе
наиболее
оптимальной
структуры
базовых
отношений
.
Материалы
данного
раздела
как
раз
и
посвящены
выяснению
оляющих
выбирать
«
лучшие
»
варианты
логиче
110
данн
с
помощью
10.
ть
ависимость
между
з че
с
о
т
ф
а
,
являющейся
его
функ
,
ачно
определяют
значен
ения
функциональной
зависимости
ых
,
а
также
определению
методов
,
позволяющих
осознанно
формальных
,
эквивалентных
с
точки
зрения
информационного
содержимого
базы
данных
преобразований
оптимизировать
логическую
структуру
ее
отношений
.
При
решении
указанных
вопросов
одним
из
фундаментальных
понятий
теории
реляционных
баз
данных
является
понятие
функциональной
зависимости
.
1.
Функциональная
зависимос
Функциональная
зависимость
(Functional Dependency)
является
связью
типа
многие
-
к
-
одному
между
множествами
значений
атрибутов
внутри
отношения
.
Отношение
,
при
этом
понимается
в
смысле
переменной
отношения
,
что
подразумевает
,
что
такого
рода
зависимость
между
значениями
атрибутов
имеет
место
при
любых
конкретных
состояниях
данного
отношения
.
Если
говорить
неформально
,
то
функциональная
з
на ниями
атрибутов
состоит
в
том
,
что
значение
одного
атрибута
(
возможно
оставного
)
однозначно
определяет
значение
другого
атрибута
.
В
отличие
от
бычной
ма ематической
зависимости
аргумента
от
ункции
,
когда
значение
ргумента
однозначно
определяет
само
значение
переменной
цией
,
в
реляционной
модели
функциональная
зависимость
одного
атрибута
от
другого
определяет
факт
соответствия
каждому
определенному
значению
одного
атрибута
отношения
строго
определенного
значения
другого
атрибута
,
не
определяя
само
значение
зависимого
атрибута
.
Такого
рода
зависимость
между
атрибутами
отношения
нам
уже
знакома
.
Например
значения
атрибутов
,
являющихся
ключом
отношения
,
всегда
однозн
ия
всех
остальных
атрибутов
отношения
.
Более
строгая
формулировка
определ
имеет
следующий
вид
.
Пусть
R
является
переменной
отношения
,
а
X
и
Y –
произвольными
подмножествами
множества
атрибутов
отношения
R.
Говорят
,
что
значение
Y
функционально
зависит
от
значения
X,
тогда
и
только
тогда
,
когда
для
любого
допустимого
значения
отношения
R
каждое
значение
X
связано
в
точност
одними
и
с
значением
Y.
Символиче ки
функциональная
зависим
с
ость
обозначается
X
→
Y.
Эта
я
,
ляет
Y
или
Y
функционально
запись
читаетс
как
X
функционально
опреде
зависит
от
X
.