Geum.ru

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

Вид материалаДиплом

Содержание


Упражнения и вопросы для самоконтроля
5. НАЗНАЧЕНИЕ КЛЮЧЕВЫХ ПОЛЕЙ 5.1. Задача назначения ключевых полей в заполненных реляционных таблицах
Подобный материал:
1   ...   12   13   14   15   16   17   18   19   ...   28

Упражнения и вопросы для самоконтроля




  1. Сформулируйте проблемы нормализации заполненных реляционных таблиц.
  2. Каким образом можно представить модель реляционной таблицы?
  3. Каким образом можно представить модель информации табличного вида?
  4. В чем сходство и различие между моделью реляционной таблицы и моделью информации табличного вида?
  5. Приведите примеры реальных таблиц с подзаголовками.
  6. Приведите примеры реальных таблиц с заголовками в области данных.
  7. Опишите алгоритм избавления от сложных атрибутов.
  8. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
  9. Опишите алгоритм избавления от заголовков внутри таблицы.
  10. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
  11. Приведите примеры реальных таблиц с заголовками в первом столбце.
  12. Опишите алгоритм избавления от заголовков в первом столбце таблиц.
  13. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
  14. Приведите примеры реальных таблиц, которые не удовлетворяют требованиям ко второй нормальной форме.
  15. Опишите алгоритм выявления функциональной зависимости в заполненных реляционных таблицах.
  16. Опишите алгоритм исключения функциональной зависимости в заполненных реляционных таблицах.
  17. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
  18. Приведите примеры реальных таблиц, которые не удовлетворяют требованиям к третьей нормальной форме.
  19. Опишите алгоритм приведения заполненных реляционных таблиц к третьей нормальной форме.
  20. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
  21. Приведите примеры реальных таблиц, которые не удовлетворяют требованиям к четвертой нормальной форме.
  22. Опишите алгоритм приведения заполненных реляционных таблиц к четвертой нормальной форме.
  23. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?



5. НАЗНАЧЕНИЕ КЛЮЧЕВЫХ ПОЛЕЙ

5.1. Задача назначения ключевых полей в заполненных реляционных таблицах



В работе [7] обоснована актуальность проблемы преобразования информации табличного вида в таблицы базы данных (БД), выполнена неформальная постановка задачи такого преобразования. Основными аспектами постановки задачи являются: формирование реляционных таблиц на основе информации, представленной в табличной форме, назначение ключевых полей в таблицах, формирование связей между таблицами. Каждый аспект задачи нетривиален, нуждается в формализованном подходе к его решению и зависит от множества факторов. Здесь рассмотрена одна из составляющих задачи преобразования – назначение ключевых полей.

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

Полностью автоматизировать процесс назначения первичного ключа невозможно, так как при анализе отношения на предмет выбора атрибута или совокупности атрибутов, удовлетворяющих требованиям предъявляемых к первичному ключу, необходимо учитывать не только уникальность значений атрибута, но и семантику данных, что требует вмешательства разработчика БД. В соответствии с [14] первичный ключ должен удовлетворять требованиям уникальности и минимальности.

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

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

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