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

БлюдоВидРецептПорцийДата РПродуктКалорийностьВес (г)ПоставщикГородСтранаВес (кг)Цена ($)Дата ПЛобиоЗакускаЛом.1581/9/94Фасоль3070200"Хуанхэ"ПекинКитай2500.3724/8/94ЛобиоЗакускаЛом1081/9/94Лук45040"Наталка"КиевУкраина1000.5227/8/94ЛобиоЗакускаЛом1081/9/94Масло742030"Лайма"РигаЛатвия701.5530/8/94ЛобиоЗакускаЛом1081/9/94Зелень18010"Даугава"РигаЛатвия150.9930/8/94ХарчоСуп...1441/9/94Мясо166080"Наталка"КиевУкраина1002.1827/8/94ХарчоСуп...1441/9/94Лук45030"Наталка"КиевУкраина1000.5227/8/94ХарчоСуп...1441/9/94Томаты24040"Полесье"КиевУкраина1200.4527/8/94ХарчоСуп...1441/9/94Рис334050"Хуанхэ"ПекинКитай750.4424/8/94ХарчоСуп...1441/9/94Масло742015"Полесье"КиевУкраина501.6227/8/94ХарчоСуп...1441/9/94Зелень18015"Наталка"КиевУкраина100.8827/8/94ШашлыкГорячее...2071/9/94Мясо1660180"Юрмала"РигаЛатвия2002.0530/8/94ШашлыкГорячее...2071/9/94Лук45040"Полесье"КиевУкраина500.6127/8/94ШашлыкГорячее...2071/9/94Томаты240100"Полесье"КиевУкраина1200.4527/8/94ШашлыкГорячее...2071/9/94Зелень18020"Даугава"РигаЛатвия150.9930/8/94КофеДесерт...2351/9/94Кофе27508"Хуанхэ"ПекинКитай402.8724/8/94Рис. 4.2. Универсальное отношение "Питание"

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

Доклад

Компьютеры, программирование

Другие доклады по предмету

Компьютеры, программирование

Сдать работу со 100% гаранией

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

Цели проектирования

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

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

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

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

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

При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации) [2, 3, 4, 6, 8, 9, 10]. Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет пассажир, преподаватель дисциплина, студент сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.

Далее будут рассматриваться вопросы, связанные с проектированием отдельных реляционных предметных БД.

Основная цель проектирования БД это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирования БД, мы начнем обсуждение вопросов проектирования с рассмотрения причин, которые заставили Кодда создать основы теории нормализации.

Универсальное отношение

Предположим, что проектирование базы данных "Питание" (рис. 3.2) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.

Этот вариант таблицы "Питание" не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы рис. 4.1 множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных.

БлюдоВидРецептПорцийДата РПродуктКалорийностьВес (г)ПоставщикГородСтранаВес (кг)Цена ($)Дата ПЛобиоЗакускаЛом.1581/9/94Фасоль3070200"Хуанхэ"ПекинКитай2500.3724/8/94Лук45040"Наталка"КиевУкраина1000.5227/8/94Масло742030"Лайма"РигаЛатвия701.5530/8/94Зелень18010"Даугава"РигаЛатвия150.9930/8/94ХарчоСуп...1441/9/94Мясо166080"Наталка"КиевУкраина1002.1827/8/94Лук45030"Наталка"КиевУкраина1000.5227/8/94Томаты24040"Полесье"КиевУкраина1200.4527/8/94Рис334050"Хуанхэ"ПекинКитай750.4424/8/94Масло742015"Полесье"КиевУкраина501.6227/8/94Зелень18015"Наталка"КиевУкраина100.8827/8/94ШашлыкГорячее...2071/9/94Мясо1660180"Юрмала"РигаЛатвия2002.0530/8/94Лук45040"Полесье"КиевУкраина500.6127/8/94Томаты240100"Полесье"КиевУкраина1200.4527/8/94Зелень18020"Даугава"РигаЛатвия150.9930/8/94КофеДесерт...2351/9/94Кофе27508"Хуанхэ"ПекинКитай402.8724/8/94Рис. 4.1. Данные, необходимые для создания базы данных "Питание"

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

БлюдоВидРецептПорцийДата РПродуктКалорийностьВес (г)ПоставщикГородСтранаВес (кг)Цена ($)Дата ПЛобиоЗакускаЛом.1581/9/94Фасоль3070200"Хуанхэ"ПекинКитай2500.3724/8/94ЛобиоЗакускаЛом1081/9/94Лук45040"Наталка"КиевУкраина1000.5227/8/94ЛобиоЗакускаЛом1081/9/94Масло742030"Лайма"РигаЛатвия701.5530/8/94ЛобиоЗакускаЛом1081/9/94Зелень18010"Даугава"РигаЛатвия150.9930/8/94ХарчоСуп...1441/9/94Мясо166080"Наталка"КиевУкраина1002.1827/8/94ХарчоСуп...1441/9/94Лук45030"Наталка"КиевУкраина1000.5227/8/94ХарчоСуп...1441/9/94Томаты24040"Полесье"КиевУкраина1200.4527/8/94ХарчоСуп...1441/9/94Рис334050"Хуанхэ"ПекинКитай750.4424/8/94ХарчоСуп...1441/9/94Масло742015"Полесье"КиевУкраина501.6227/8/94ХарчоСуп...1441/9/94Зелень18015"Наталка"КиевУкраина100.8827/8/94ШашлыкГорячее...2071/9/94Мясо1660180"Юрмала"РигаЛатвия2002.0530/8/94ШашлыкГорячее...2071/9/94Лук45040"Полесье"КиевУкраина500.6127/8/94ШашлыкГорячее...2071/9/94Томаты240100"Полесье"КиевУкраина1200.4527/8/94ШашлыкГорячее...2071/9/94Зелень18020"Даугава"РигаЛатвия150.9930/8/94КофеДесерт...2351/9/94Кофе27508"Хуанхэ"ПекинКитай402.8724/8/94Рис. 4.2. Универсальное отношение "Питание"

Почему проект БД может быть плохим?

Начинающий проектировщик будет использовать отношение "Питание" (рис. 4.2) в качестве завершенной БД. Действительно, зачем разбивать отношение "Питание" на несколько более мелких отношений (см. например, рис. 3.2), если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:

1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов, некоторые из которых намного больше рецепта "Лобио" (см. рис. 2.3). И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню.

2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с продуктом кофе, то у поставщика "Хуанхэ" появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк.

3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить стр

Похожие работы

1 2 3 4 > >>