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

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

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

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

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

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

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

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

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

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

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

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

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

Блюдо Вид Рецепт Порций Дата Р Продукт Калорийность Вес (г) Поставщик Город Страна Вес (кг) Стоимость ($) Дата П
Лобио Закуска Лом. 158 1/9/94 Фасоль 3070 200 "Хуанхэ" Пекин Китай 250 0.37 24/8/94
Лук 450 40 "Наталка" Киев Украина 100 0.52 27/8/94
Масло 7420 30 "Лайма" Рига Латвия 70 1.55 30/8/94
Зелень 180 10 "Даугава" Рига Латвия 15 0.99 30/8/94
Харчо Суп ... 144 1/9/94 Мясо 1660 80 "Наталка" Киев Украина 100 2.18 27/8/94
Лук 450 30 "Наталка" Киев Украина 100 0.52 27/8/94
Томаты 240 40 "Полесье" Киев Украина 120 0.45 27/8/94
Рис 3340 50 "Хуанхэ" Пекин Китай 75 0.44 24/8/94
Масло 7420 15 "Полесье" Киев Украина 50 1.62 27/8/94
Зелень 180 15 "Наталка" Киев Украина 10 0.88 27/8/94
Шашлык Горячее ... 207 1/9/94 Мясо 1660 180 "Юрмала" Рига Латвия 200 2.05 30/8/94
Лук 450 40 "Полесье" Киев Украина 50 0.61 27/8/94
Томаты 240 100 "Полесье" Киев Украина 120 0.45 27/8/94
Зелень 180 20 "Даугава" Рига Латвия 15 0.99 30/8/94
Кофе Десерт ... 235 1/9/94 Кофе 2750 8 "Хуанхэ" Пекин Китай 40 2.87 24/8/94

Рис. 4.1. Данные, нужные для сотворения базы данных "Питание Введение в проектирование реляционных баз данных - доклад"

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

Блюдо Вид Рецепт Порций Дата Р Продукт Калорийность Вес (г) Поставщик Город Страна Вес (кг) Стоимость ($) Дата П
Лобио Закуска Лом. 158 1/9/94 Фасоль 3070 200 "Хуанхэ" Пекин Китай 250 0.37 24/8/94
Лобио Закуска Лом 108 1/9/94 Лук 450 40 "Наталка" Киев Украина 100 0.52 27/8/94
Лобио Закуска Лом 108 1/9/94 Масло 7420 30 "Лайма" Рига Латвия 70 1.55 30/8/94
Лобио Закуска Лом 108 1/9/94 Зелень 180 10 "Даугава" Рига Латвия 15 0.99 30/8/94
Харчо Суп ... 144 1/9/94 Мясо 1660 80 "Наталка" Киев Украина 100 2.18 27/8/94
Харчо Суп ... 144 1/9/94 Лук 450 30 "Наталка" Киев Украина 100 0.52 27/8/94
Харчо Суп ... 144 1/9/94 Томаты 240 40 "Полесье" Киев Украина 120 0.45 27/8/94
Харчо Суп ... 144 1/9/94 Рис 3340 50 "Хуанхэ" Пекин Китай 75 0.44 24/8/94
Харчо Суп ... 144 1/9/94 Масло 7420 15 "Полесье" Киев Украина 50 1.62 27/8/94
Харчо Суп ... 144 1/9/94 Зелень 180 15 "Наталка" Киев Украина 10 0.88 27/8/94
Шашлык Горячее ... 207 1/9/94 Мясо 1660 180 "Юрмала" Рига Латвия 200 2.05 30/8/94
Шашлык Горячее ... 207 1/9/94 Лук 450 40 "Полесье" Киев Украина 50 0.61 27/8/94
Шашлык Горячее ... 207 1/9/94 Томаты 240 100 "Полесье" Киев Украина 120 0.45 27/8/94
Шашлык Горячее ... 207 1/9/94 Зелень 180 20 "Даугава" Рига Латвия 15 0.99 30/8/94
Кофе Десерт ... 235 1/9/94 Кофе 2750 8 "Хуанхэ" Пекин Китай 40 2.87 24/8/94

Рис. 4.2. Универсальное отношение "Питание"

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

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

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

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

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

По аналогичным причинам нельзя ввести и новый продукт (к примеру, Баклажаны), который предлагает имеющийся поставщик (к примеру, "Полесье"). Как ввести новое блюдо, если в нем употребляется новый продукт (Крабы)?

4. Аномалии удаления Введение в проектирование реляционных баз данных - доклад . Оборотная неувязка появляется по мере надобности удаления всех товаров, поставляемых данным поставщиком либо всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике.

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

Блюда

Блюдо Вид
Лобио Закуска
Харчо Суп
Шашлык Горячее
Кофе Десерт
... ...

Рецепты

Блюдо Рецепт
Лобио Ломаную очищ
... ...

Расход

Блюдо Порций Дата_Р
Лобио 158 1/9/94
Харчо 144 1/9/94
Шашлык 207 1/9/94
Кофе 235 1/9/94
... ... ...

Продукты

Продукт Калор.
Фасоль 3070
Лук 450
Масло 7420
Зелень 180
Мясо 1660
... ...

Состав

Блюдо Продукт Вес (г)
Лобио Фасоль 200
Лобио Лук 40
Лобио Масло 30
Лобио Зелень 10
Харчо Мясо 80
... ... ...

Поставщики

Поставщик Город Страна
"Полесье" Киев Украина
"Наталка" Киев Украина
"Хуанхэ" Пекин Китай
"Лайма" Рига Латвия
"Юрмала" Рига Латвия
... ... ...

Поставки

Поставщик Город Продукт Вес (кг) Стоимость ($) Дата_П
"Полесье" Киев Томаты 120 0.45 27/8/94
"Полесье" Киев Масло 50 1.62 27/8/94
"Полесье" Киев Лук 50 0.61 27/8/94
"Наталка" Киев Лук 100 0.52 27/8/94
... ... ... ... ... ...

Рис Введение в проектирование реляционных баз данных - доклад. 4.3. Преобразование универсального дела "Питание" (1-ый вариант)

Включение . Обычным добавлением строк (Поставщики; "Няринга", Вильнюс, Литва) и (Поставки; "Няринга", Вильнюс, Огурцы, 40) можно ввести информацию о новеньком поставщике. Аналогично можно ввести данные о новеньком продукте (Продукты; Баклажаны, 240) и (Поставки; "Полесье", Киев, Баклажаны, 50).

Удаление . Удаление сведений о неких поставках либо блюдах Введение в проектирование реляционных баз данных - доклад не приводит к потере сведений о поставщиках.

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

Не считая того, повторяющиеся текстовые данные (такие как заглавие блюда "Рулет из телячей грудинки с сосисками и гарниром из разноцветного пюре" либо продукта "Колбаса столичная Введение в проектирование реляционных баз данных - доклад сырокопченая") значительно наращивают объем хранимых данных.

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

Блюда

БЛ Блюдо Вид
1 Лобио Закуска
2 Харчо Суп
3 Шашлык Горячее
4 Кофе Десерт
... ... ...

Рецепты

Блюдо Рецепт
Лобио Ломаную Введение в проектирование реляционных баз данных - доклад очищ
... ...

Расход

Блюдо Порций Дата_Р
Лобио 158 1/9/94
Харчо 144 1/9/94
Шашлык 207 1/9/94
Кофе 235 1/9/94
... ... ...

Продукты

ПР Продукт Калор.
1 Фасоль 3070
2 Лук 450
3 Масло 7420
4 Зелень 180
5 Мясо 1660
... ... ...

Состав

БЛ ПР Вес (г)
1 1 200
1 2 40
1 3 30
1 4 10
2 5 80
... ... ...

Поставщики

ПОС Поставщик Город Страна
1 "Полесье" Киев Украина
2 "Наталка" Киев Украина
3 "Хуанхэ" Пекин Китай
4 "Лайма" Рига Латвия
5 "Юрмала" Рига Латвия
... ... ... ...

Поставки

ПОС ПР Вес (кг) Стоимость ($) Дата_П
1 6 120 0.45 27/8/94
1 3 50 1.62 27/8/94
1 2 50 0.61 27/8/94
2 2 100 0.52 27/8/94
... ... ... ... ...

Рис. 4.4. Преобразование универсального дела "Питание" (2-ой вариант)

О нормализации, многофункциональных и неоднозначных зависимостях

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

Как указывалось в п. 3.1, любая таблица в реляционной БД удовлетворяет условию, в согласовании с которым в позиции на скрещении каждой строчки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть огромного количества таких значений. Неважно какая таблица, удовлетворяющая этому условию Введение в проектирование реляционных баз данных - доклад, именуется нормализованной (см. таблицы рис. 4.2 – 4.4). Практически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы (см. рис. 4.1), даже не допускаются в реляционной БД.

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

Сейчас в дополнение к 1НФ можно найти последующие уровни нормализации – вторую нормальную форму (2НФ ), третью нормальную форму (3НФ ) и т.д. По существу, таблица находится в 2НФ, если она Введение в проектирование реляционных баз данных - доклад находится в 1НФ и удовлетворяет, не считая того, некому дополнительному условию, сущность которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, кроме этого, удовлетворяет еще другому дополнительному условию и т.д.

Таким макаром, любая обычная форма является в неком смысле более ограниченной Введение в проектирование реляционных баз данных - доклад, да и более желательной , чем предыдущая. Это связано с тем, что "(N+1)-я обычная форма" не обладает некими непрезентабельными особенностями, характерным "N-й обычной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й обычной форме, состоит в исключении этих непрезентабельных особенностей. В п Введение в проектирование реляционных баз данных - доклад. 4.3 мы выявляли непрезентабельные особенности таблицы рис. 4.2 и для их исключения делали "интуитивную нормализацию".

Теория нормализации основывается на наличии той либо другой зависимости меж полями таблицы. Определены два вида таких зависимостей: многофункциональные и неоднозначные.

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

К примеру, в таблице Блюда (рис. 4.4) поля Введение в проектирование реляционных баз данных - доклад Блюдо и Вид функционально зависят от ключа БЛ, а в таблице Поставщики рис. 4.3 поле Страна функционально находится в зависимости от составного ключа (Поставщик, Город). Но последняя зависимость не является функционально полной, потому что Страна функционально зависит и от части ключа – поля Город.

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

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

Обучение

Дисциплина Педагог Учебник
Информатика Шипилов П.А. Форсайт Р. Паскаль для всех
Информатика Шипилов П.А. Уэйт М. и др. Язык Си
Информатика Голованевский Г.Л. Форсайт Р. Паскаль для всех
Информатика Голованевский Г.Л. Уэйт М. и др. Язык Си
... ... ...

Рис. 4.5. К иллюстрации неоднозначных зависимостей

Для примера разглядим таблицу "Обучение" (рис. 4.5). В ней есть неоднозначная Введение в проектирование реляционных баз данных - доклад зависимость "Дисциплина-Преподаватель": дисциплина (в примере Информатика) может может читаться несколькими педагогами (в примере Шипиловым и Голованевским). Есть и другая неоднозначная зависимость "Дисциплина-Учебник": при исследовании Информатики употребляются учебники "Паскаль для всех" и "Язык Си". При всем этом Педагог и Учебник не связныфункциональной зависимостью, что приводит к Введение в проектирование реляционных баз данных - доклад возникновению избыточности (для добавление еще 1-го учебника придется ввести в таблицу две новых строчки). Дело улучшается при подмене этой таблицы на две: (Дисциплина-Преподаватель и Дисциплина-Учебник).

Процедура нормализации

Как уже говорилось, нормализация – это разбиение таблицы на несколько, владеющих наилучшими качествами при обновлении, включении и удалении данных. Сейчас можно дать Введение в проектирование реляционных баз данных - доклад и другое определение: нормализация – это процесс поочередной подмены таблицы ее полными декомпозициями до того времени, пока они все не будут находиться в 5НФ. На практике же довольно привести таблицы к НФБК и с большой гарантией считать, что они находятся в 5НФ. Очевидно, данный факт нуждается в проверке, но пока Введение в проектирование реляционных баз данных - доклад не существует действенного метода таковой проверки. Потому остановимся только на процедуре приведения таблиц к НФБК.

Эта процедура основывается на том, что единственными многофункциональными зависимостями в хоть какой таблице должны быть зависимости вида K->F, где K – первичный ключ, а F – некое другое поле. Заметим, что это следует из Введение в проектирование реляционных баз данных - доклад определения первичного ключа таблицы, в согласовании с которым K->F всегда имеет место для всех полей данной таблицы. "Один факт в одном месте" гласит о том, что не имеют силы никакие другие многофункциональные зависимости. Цель нормализации состоит конкретно в том, чтоб избавиться от всех этих "других" многофункциональных зависимостей, т Введение в проектирование реляционных баз данных - доклад.е. таких, которые имеют другой вид, чем K->F.

Если пользоваться рекомендацией п. 4.5 и подменить на время нормализации коды первичных (наружных) ключей на начальные ключи, то, по существу, следует разглядеть только два варианта:

1. Таблица имеет составной первичный ключ вида, скажем, (К1,К2), и включает также поле F, которое функционально находится Введение в проектирование реляционных баз данных - доклад в зависимости от части этого ключа, к примеру, от К2, но не от полного ключа. В данном случае рекомендуется сформировать другую таблицу, содержащую К2 и F (первичный ключ – К2), и удалить F из начальной таблицы:

Поменять T(K1,K2,F), первичный ключ (К1,К2), ФЗ К2->F на T Введение в проектирование реляционных баз данных - доклад1(K1,K2), первичный ключ (К1,К2), и T2(K2,F), первичный ключ К2.

2. Таблица имеет первичный (вероятный) ключ К, не являющееся вероятным ключом поле F1, которое, естественно, функционально находится в зависимости от К, и другое неключевое поле F2, которое функционально находится в зависимости от F1. Решение тут, по существу, то Введение в проектирование реляционных баз данных - доклад же самое, что и до этого – формируется другая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из начальной таблицы:

Поменять T(K,F1,F2), первичный ключ К, ФЗ F1->F2 на T1(K,F1), первичный ключ К, и T2(F1,F2), первичный ключ F1.

Для Введение в проектирование реляционных баз данных - доклад хоть какой данной таблицы, повторяя применение 2-ух рассмотренных правил, практически во всех практических ситуациях можно получить в конечном счете огромное количество таблиц, которые находятся в "конечной" обычной форме и, таким макаром, не содержат каких-то многофункциональных зависимостей вида, хорошего от K->F.

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

Пример 4.1 . Применим рассмотренные правила для полной нормализации универсального дела "Питание Введение в проектирование реляционных баз данных - доклад" (рис. 4.2).

Шаг 1 . Определение первичного ключа таблицы.

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

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П.

Шаг 2 . Выявление полей, функционально зависящих от части состваного ключа.

Поле Вид функционально зависит только от поля Блюдо, т Введение в проектирование реляционных баз данных - доклад.е.

Блюдо->Вид.

Аналогичным образом можно получить зависимости:

Блюдо->Рецепт(Блюдо, Дата_Р)->ПорцийПродукт->Калорийность(Блюдо, Продукт)->ВесГород->Страна(Поставщик, Город, Дата_П)->Стоимость

Шаг 3 . Формирование новых таблиц.

Приобретенные многофункциональные зависимости опредляют состав таблиц, которые можно сформировать из данных универсального дела:

Блюда (Блюдо , Вид)Рецепты (Блюдо , Рецепт)Расход (Блюдо Введение в проектирование реляционных баз данных - доклад, Дата_Р , Порций)Продукты (Продукт , Калорийность)Состав (Блюдо, Продукт , Вес (г))Городка (Город , Страна)Поставки (Поставщик, Город, Дата_П , Вес (кг), Стоимость).

Шаг 4 . Корректировка начальной таблицы.

После выделения из состава универсального дела обозначенных выше таблиц, там остались только сведения о поставщиках, для хранения которых целенаправлено сделать таблицу

Поставщики (Поставщик, Город Введение в проектирование реляционных баз данных - доклад ),

т.е. использовать часть начального первичного ключа, потому что другие его части уже ничего не определяют.

Таким макаром, процедура поочередной нормализации позволила получить проект, наилучший, чем приведен на рис. 4.3.

Пример 4.2 . Для улучшения проекта, приведенного на рис. 4.4, необходимо найти первичные ключи таблиц и выявить, нет ли в Введение в проектирование реляционных баз данных - доклад таблицах полей, зависящих только от части этих ключей. Такое поле есть исключительно в одной таблице. Это поле Страна в таблице Поставщики. Выделяя его вкупе с ключем Город в таблицу Страны, получим проект, приведенный на рис. 3.2.

Процедура проектирования

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

1. Представить каждый стержень (независимую суть) таблицей базы данных (базисной таблицей) и специфицировать первичный ключ этой базисной таблицы.

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

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

4. Представить каждое обозначение, которое не рассматривалось в прошлом пт, как базисную таблицу с наружным ключом, идентифицирующим обозначаемую суть. Специфицировать связанные с каждым таким наружным ключом ограничения.

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

6. Для того чтоб исключить в проекте ненамеренные нарушения каких-то принципов нормализации, выполнить описанную в п. 4.6 функцию нормализации.

7. Если в процессе нормализации было произведено разделение каких-то таблиц, то следует видоизменять инфологическую модель базы данных и повторить перечисленные шаги.

8. Указать Введение в проектирование реляционных баз данных - доклад ограничения целостности проектируемой базы данных и дать (если это нужно) короткое описание приобретенных таблиц и их полей.

На рис. 4.6 показан синтаксис предложения, предлагаемого для регистрации принимаемых проектных решений.

Рис. 4.6. Синтаксис описания проектных решений

Для примера приведем описания таблиц "Блюда" и "Состав":

Сделать ТАБЛИЦУ Блюда *( Стержневая суть ) ПЕРВИЧНЫЙ Введение в проектирование реляционных баз данных - доклад КЛЮЧ ( БЛ ) ПОЛЯ ( БЛ Целое, Блюдо Текст 60, Вид Текст 7 ) ОГРАНИЧЕНИЯ ( 1. Значения поля Блюдо должны быть уникальными; при нарушении вывод сообщения "Такое блюдо уже есть". 2. Значения поля Вид должны принадлежать набору: Закуска, Суп, Горячее, Десерт, Напиток; при нарушении вывод сообщения "Можно только Закуска, Суп, Горячее, Десерт, Напиток");Сделать ТАБЛИЦУ Состав *( Связывает Блюда и Введение в проектирование реляционных баз данных - доклад Продукты ) ПЕРВИЧНЫЙ КЛЮЧ ( БЛ, ПР ) Наружный КЛЮЧ ( БЛ ИЗ Блюда NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ) Наружный КЛЮЧ ( ПР ИЗ Продукты NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ) ПОЛЯ ( БЛ Целое, ПР Целое, Вес Целое Введение в проектирование реляционных баз данных - доклад ) ОГРАНИЧЕНИЯ ( 1. Значения полей БЛ и ПР должны принадлежать набору значений из соответственных полей таблиц Блюда и Продукты; при нарушении вывод сообщения "Такового блюда нет" либо "Такового продукта нет". 2. Значение поля Вес должно лежать в границах от 0.1 до 500 г. );

Рассмотренный язык описания данных, основанный на языке SQL [5], позволяет дать комфортное Введение в проектирование реляционных баз данных - доклад и полное описание хоть какой сути и, как следует, всей базы данных. Но такое описание, как и хоть какое подробное описание, не отличается наглядностью. Для заслуги большей иллюстративности целенаправлено дополнять проект инфологической моделью, но наименее массивной, чем рассмотренная в главе 2.

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

Рис. 4.7. Инфологическая модель базы данных "Питание", построенная при помощи языка "Таблицы-связи"

Разные советы и советы

Векторы . Представляйте векторы по столбцам, а не по строчкам. К примеру, диаграмму продаж продуктов x, y, ... за последние годы лучше представить в виде:

Продукт МЕСЯЦ КОЛ-ВО-–––– ––––––– –––––– x Введение в проектирование реляционных баз данных - доклад ЯНВАРЬ 100 x ФЕВРАЛЬ 50 ... ... ... x ДЕКАБРЬ 360 y ЯНВАРЬ 75 y ФЕВРАЛЬ 144 ... ... ... y ДЕКАБРЬ 35 ... ... ...

а не так, как показано ниже:

Продукт КОЛ-ВО КОЛ-ВО КОЛ-ВО ЯНВАРЬ ФЕВРАЛЬ ... ДЕКАБРЬ ––––– ––––––– ––––––– ––––––– x 100 50 ... 360 y 75 144 ... 35 ... ... ... ... ...

Одна из обстоятельств таковой советы состоит в том, что при всем этом существенно проще записываются обобщенные (параметризованные) запросы. Разглядите, к примеру Введение в проектирование реляционных баз данных - доклад, как смотрится сопоставление сведений из диаграммы продаж продукта i в месяце с номером m со сведениями для продукта j в месяце с номером n, где i, j, m и n – характеристики.

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

ЛИТЕРАТУРА
  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 с.


vvedenie-vo-vvedenie-v-filosofiyu.html
vvedenie-vzyat-s-kursogo-po-trpp.html
vvedenie-znakomstvo-s-predmetom-i-osnovnimi-ponyatiyami-uchebnoj-disciplini-osnovi-nauchnih-issledovanij.html