Основы проектирования реляционных баз данных

Автор: Пользователь скрыл имя, 09 Марта 2013 в 10:59, лекция

Краткое описание

Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение "Стоимость авиабилета 128". Здесь "128" – данное, а "Стоимость авиабилета" – его семантика.

Оглавление

Глава 1. Что такое базы данных и СУБД
1.1. Данные и ЭВМ
1.2. Концепция баз данных
1.3. Архитектура СУБД
1.4. Модели данных
Глава 2. Инфологическая модель данных "Сущность-связь"
2.1. Основные понятия
2.2. Характеристика связей и язык моделирования
2.3. Классификация сущностей
2.4. О первичных и внешних ключах
2.5. Ограничения целостности
2.6. О построении инфологической модели
Глава 3. Реляционный подход
3.1. Реляционная структура данных
3.2. Реляционная база данных
3.3. Манипулирование реляционными данными
Глава 4. Введение в проектирование реляционных баз данных
4.1. Цели проектирования
4.2. Универсальное отношение
4.3. Почему проект БД может быть плохим?
4.4. О нормализации, функциональных и многозначных зависимостях
4.5. Нормальные формы
4.6. Процедура нормализации
4.7. Процедура проектирования
4.8. Различные советы и рекомендации
Глава 5. Пример проектирования базы данных "Библиотека"
5.1. Назначение и предметная область
5.2. Построение инфологической модели
5.3. Проектирование базы данных
Литература
Предметный указатель

Файлы: 1 файл

Kniga_Kirillov.doc

— 859.00 Кб (Скачать)

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Создатели ОГРАНИЧИВАЕТСЯ

                  ОБНОВЛЕНИЕ Создатели.Код_создателя  КАСКАДИРУЕТСЯ)

   ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ

                  ОБНОВЛЕНИЕ Издания.Код_издания  КАСКАДИРУЕТСЯ)

   ВНЕШНИЙ КЛЮЧ ( Код_языка  ИЗ Языки

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Языки ОГРАНИЧИВАЕТСЯ

                  ОБНОВЛЕНИЕ Языки.Код_языка КАСКАДИРУЕТСЯ)

           ПОЛЯ ( Код_создателя Целое, Код_издания  Целое )

    ОГРАНИЧЕНИЯ ( Значения  полей Код_создателя, Код_издания  и

                  Код_языка должны принадлежать набору значений

                  соответствующих полей таблиц  Создатели, Издание

                  и Языки; при нарушении вывод  сообщения "Такого

                  автора нет" или "Такого  издания нет" или "Такого

                  языка нет");

 

СОЗДАТЬ ТАБЛИЦУ Размещение *( Связывает  Места и Переплеты )

 ПЕРВИЧНЫЙ КЛЮЧ ( Код_места, Номер_переплета  )

   ВНЕШНИЙ КЛЮЧ ( Код_места  ИЗ Места

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Места ОГРАНИЧИВАЕТСЯ

                  ОБНОВЛЕНИЕ Места.Код_места КАСКАДИРУЕТСЯ)

   ВНЕШНИЙ КЛЮЧ ( Номер_переплета  ИЗ Переплеты

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Переплеты КАСКАДИРУЕТСЯ

                  ОБНОВЛЕНИЕ Переплеты.Ном_переплета КАСКАДИРУЕТСЯ)

           ПОЛЯ ( Код_места Целое, Номер_переплета  Целое,

                  Дата_размещения Дата, Дата_изъятия  Дата )

    ОГРАНИЧЕНИЯ ( Значения  полей Код_места и Номер_переплета

                  должны принадлежать набору значений  соответствующих

                  полей таблиц Переплеты и Места;  при нарушении вывод

                  сообщения "Такого переплета  нет" или "Такого места  нет" );

 

СОЗДАТЬ ТАБЛИЦУ Выдача *( Связывает  Читатели и Переплеты )

 ПЕРВИЧНЫЙ КЛЮЧ ( Ном_билета, Ном_переплета )

   ВНЕШНИЙ КЛЮЧ ( Ном_билета  ИЗ Читатели

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Читатели КАСКАДИРУЕТСЯ

                  ОБНОВЛЕНИЕ Читатели.Ном_билета  КАСКАДИРУЕТСЯ)

   ВНЕШНИЙ КЛЮЧ ( Ном_переплета  ИЗ Переплеты

                  NULL-значения НЕ ДОПУСТИМЫ

                  УДАЛЕНИЕ ИЗ Переплеты КАСКАДИРУЕТСЯ

                  ОБНОВЛЕНИЕ Переплеты.Ном_переплета  КАСКАДИРУЕТСЯ)

           ПОЛЯ ( Ном_билета Целое, Ном_переплета  Целое, Дата_выдачи Дата,

                  Срок Целое, Дата_возврата Дата )

    ОГРАНИЧЕНИЯ ( Значения  полей Ном_билета и Ном_переплета  должны

                  принадлежать набору значений  соответствующих полей таблиц

                  Читатели и Переплеты; при нарушении  вывод сообщения

                  "Такого читателя нет" или "Такого переплета нет" );


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

  • функционально зависит от полного первичного ключа, а не от его части (если ключ составной);
  • не имеет функциональной зависимости от другого неключевого поля.
  • Сущности Авторы, Составители, Редакторы, Художники и Переиздания, не имеющие неключевых полей, безусловно нормализованы. Нормализованы и сущности Создатели, Характеры, Заглавия, Вид_издания и Аннотации, состоящие из несоставного ключа и единственного неключевого поля.

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

Наконец, анализ сущностей Издания, Переплеты, Места, Читатели и Языки, показал, что единственной "подозрительной" сущностью является стержень Языки, имеющий два функционально связанных неключевых поля: Язык и Сокращение.

Поле Язык стало неключевым из-за ввода цифрового первичного ключа  Код_языка, заменяющего текстовый  возможный ключ Язык. Это позволило уменьшить объем хранимых данных в таблице Переводчики, затраты труда на ввод множества текстовых значений и возможной противоречивости, которая часто возникает из-за ввода в разные поля ошибочных дубликатов (например, "Английский", "Англиский", "Анлийский", "Англйский" и т.п.). Если мы вспомним рекомендации п. 4.5 о замене на время нормализации цифровыз заменителей первичных ключей (Код_языка) на исходный ключ (Язык) или воспользуемся формулировкой НФБК, то окажется, что таблица Языки – нормализована.

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

ЛИТЕРАТУРА

  1. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.
  2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.
  3. Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.
  4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с.
  5. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.
  6. Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.
  7. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.
  8. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.
  9. Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990. – 386 с.
  10. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.
  11. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.

Информация о работе Основы проектирования реляционных баз данных