Читайте также:
|
До сего момента предполагалось, что при достижении пятой нормальной формы дальнейшая декомпозиция не только бессмысленна, но и просто вредна. Однако, с чисто формальной точки зрения, она остается возможной, и декомпозиция отношения в V НФ будет полной, если все проекции будут иметь общий ключ. Рассмотрим, что может выиграть, а что проиграть разработчик при работе с подобными информационными моделями, которые иногда неофициально называют «перенормализованными».
Рассмотрим упоминавшееся выше отношение «Студенты».
Отношение «Студенты»
| № зач. | Груп-па | ФИО Студента | Дата рожд. |
| Петров | 01.10.80 | ||
| Иванов | 14.05.79 | ||
| Сидоров | 17.08.80 |
Его можно представить как набор следующих проекций. (Можно привести и другие варианты).
Отношение «Студенты 1» Отношение «Студенты 2»
| № зач. | ФИО Студента | № зач. | Группа | Дата рожд. | |
| Петров | 01.10.80 | ||||
| Иванов | 14.05.79 | ||||
| Сидоров | 17.08.80 |
Совершенно очевидно, что такая декомпозиция ничего не дает разработчику для упрощения задачи, одновременно добавляя программистам головной боли при разработке приложений из– за необходимости синхронной обработки нескольких таблиц. Одновременно с этим возрастает сложность получения конечных отчетов, причиной чего являются лишние операции соединения таблиц. Однако, можно подобрать примеры, в которых необходимость «перенормализации» можно хотя бы попытаться обосновать.
Введем в отношение «Студенты» атрибут Факультет.
Отношение «Студенты»
| № зач. | Груп-па | ФИО Студента | Дата рожд. | Факультет |
| Петров | 01.10.80 | Мехмат | ||
| Иванов | 14.05.79 | Мехмат | ||
| Кузнецов | 10.08.77 | Машфак | ||
| Сергеев | 24.05.79 | Машфак | ||
| Андреев | 22.12.78 | Машфак | ||
| Сидоров | 17.08.80 | Машфак |
Если дополнительно ввести предположение, что подготовка данных о студентах ведется на каждом факультете отдельно и при этом взаимодействия данных между различными факультетами нет или почти нет, то можно предложить следующую декомпозицию.
Отношение «Студенты Мехмата»
| № зач. | Груп-па | ФИО Студента | Дата рожд. | Факультет |
| Петров | 01.10.80 | Мехмат | ||
| Иванов | 14.05.79 | Мехмат |
Отношение «Студенты Машфака»
| № зач. | Груп-па | ФИО Студента | Дата рожд. | Факультет |
| Кузнецов | 10.08.77 | Машфак | ||
| Сергеев | 24.05.79 | Машфак | ||
| Андреев | 22.12.78 | Машфак | ||
| Сидоров | 17.08.80 | Машфак |
В пользу такого решения можно привести следующие аргументы.
· Время поиска записи в таблице для всех СУБД пропорционально[3] объему таблицы. Если нет острой необходимости обрабатывать всю базу данных одновременно (например, при анализе уникальности номера зачетки), то подобная декомпозиция позволит заметно ускорить работу приложений. Это соображение актуально для аппаратного и программного обеспечения, выпущенного в 80-х годах (системы на базе 8086, 80286 и пр.). Современные персональные ЭВМ и разработанные для них СУБД позволяют обрабатывать сотни тысяч записей с приемлемой скоростью.
· В случае, если подготовка данных ведется в деканатах факультетов, расположенных в разных зданиях, становится невозможным использовать для организации доступа к данным доступные и дешевые технологии Ethernet. С учетом того, что сводные отчеты могут собираться с достаточно большим периодом, становится целесообразной такая организация работы, при которой на факультетах работают независимые банки данных, а исходные данные для получения сводных отчетов по университету передаются на «центральный» компьютер с помощью сменных носителей (в простейшем случае – с помощью дискет). Такое решение может, несмотря на усложнение сценария работы, оказаться дешевле, чем организация многоуровневой сети большой протяженности. Однако следует отметить, что бурное развитие в последнее время технологий удаленного доступа (прежде всего Internet и Intranet) может в ближайшее время снять этот довод.
Рассмотрим следующую задачу. Для проведения спартакиады университета необходимо отслеживать вид спорта, которым занимается студент и его спортивный разряд.
Отношение «Студенты»
| № зач. | Груп-па | ФИО Студента | Дата рожд. | Факультет | Вид спорта | Разряд |
| Петров | 01.10.80 | Мехмат | Лыжи | I | ||
| Иванов | 14.05.79 | Мехмат | ||||
| Кузнецов | 10.08.77 | Машфак | ||||
| Сергеев | 24.05.79 | Машфак | Волейбол | КМС | ||
| Андреев | 22.12.78 | Машфак | ||||
| Сидоров | 17.08.80 | Машфак |
Очевидно, что в подавляющем большинстве записей поля Вид спорта и Разряд не будут заполнены. Более того, даже заполненные значения будут использоваться лишь одной из подзадач, решаемых банком данных. Если представить себе еще несколько подобных задач, решенных аналогичным образом, то может возникнуть ситуация, когда большая часть таблицы занята пустыми значениями, которые хранятся ради единственной, к тому же редко используемой задачи. С появлением многогигабайтных жестких дисков перерасход дискового пространства уже перестал быть проблемой, однако неоправданный рост объема таблицы снижает производительность работы, особенно в локальной сети. Тогда приведенная ниже декомпозиция может оказаться оправданной.
Отношение «Студенты»
| № зач. | Груп-па | ФИО Студента | Дата рожд. | Факультет |
| Петров | 01.10.80 | Мехмат | ||
| Иванов | 14.05.79 | Мехмат | ||
| Кузнецов | 10.08.77 | Машфак | ||
| Сергеев | 24.05.79 | Машфак | ||
| Андреев | 22.12.78 | Машфак | ||
| Сидоров | 17.08.80 | Машфак |
Отношение «Спортивные разряды»
| № зач. | Вид спорта | Разряд |
| Лыжи | I | |
| Волейбол | КМС |
Разумеется, при таком представлении данных возникают проблемы, сходные с аномалиями обработки данных, хотя и имеющие другую природу. Расплатой за экономию объема является усложнение приложений, работающих с этой информационной моделью.
Дата добавления: 2015-07-19; просмотров: 46 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Четвертая нормальная форма. | | | Пример проектирования БД. |