Реферат: Введение в проектирование реляционных баз данных - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

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

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 89 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Введение в проектирование реляционных баз данных Цели проектиро ван ия Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных . Чаще всего администратор баз данных (даже если это группа лиц ) практически не в состоянии охватить и осмыслить все информацио нные требования сотруднико в организации ( т.е . будущих пользователей системы ). Поэтому инф ормационные системы больших организаций содержат несколько десятков БД , нередко распределенны х между несколькими взаимосвязанными ЭВМ разл ичных подразделений . (Так в больших городах создается н е одна , а несколько овощных баз , расположенных в разных районах .) Отдельные БД могут объединять все дан ные , необходимые для решения одной или нес кольких прикладных задач , или данные , относящи еся к какой-либо предметной области (например , финансам , студента м , преподавателям , кулин арии и т.п .). Первые обычно называют прикладными БД , а вторы е – предметными БД (соотносящимся с предметами организации , а не с ее информационными приложениями ). (Первые можно сравнить с базами материальн о-технического снабжения или отдыха , а вт орые – с овощными и обувными базами .) Предметные БД позволяют обеспечить поддер жку любых текущих и будущих приложений , по скольку набор их элементов данных включает в себя наборы элементов данных прикладных БД . Вследствие этого предметные БД соз дают основу для обработки неформализованн ых , изменяющихся и неизвестных запросов и приложений (приложений , для которых невозможно заранее определить требования к данным ). Так ая гибкость и приспосабливаемость позволяет с оздавать на основе предметных БД дос т аточно стабильные информационные системы , т.е . системы , в которых большинство изменений можно осуществить без вынужденного переписыв ания старых приложений. Основывая же проектирование БД на тек ущих и предвидимых приложениях , можно существ енно ускорить созд ание высокоэффективной информационной системы , т.е . системы , структура которой учитывает наиболее часто встречающиеся пути доступа к данным . Поэтому прикладное проектирование до сих пор привлекает некот орых разработчиков . Однако по мере роста ч исла прилож е ний таких информационных систем быстро увеличивается число прикладных БД , резко возрастает уровень дублирования данных и повышается стоимость их ведения. Таким образом , каждый из рассмотренных подходов к проектированию воздействует на результаты проектиров ания в разных направ лениях . Желание достичь и гибкости , и эффе ктивности привело к формированию методологии проектирования , использующей как предметный , так и прикладной подходы . В общем случае пр едметный подход используется для построения п ервоначальной и н формационной структуры , а прикладной – для ее совершенствования с целью повышения эффективности обработки данных. При проектировании информационной системы необходимо провести анализ целей этой сист емы и выявить требования к ней отдельных пользователей (со трудников организации ) [ 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. Преобразование универсального отношения "Питание " (первый вар иант ) Включение . Простым добавлением строк (Пост авщики ; "Няринга ", Вильнюс , Литва ) и (Поставки ; "Няринга ", Вильнюс , Огурцы , 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. П реобразование универс ального отношения "Питание " (второй вариант ) О нормализации , функциональных и многозначных зависимостях Нормализация – это разбиение таблицы на дв е или более , обладающих лучшими свойствами при включении , изменении и удалении данных . Ок ончательная цель нормализации сводитс я к получению такого проекта базы данных , в котором каждый факт поя вляется лишь в одном месте , т.е . исключена избыточность информации . Это дел ается не столько с целью экономии памяти , сколько для исключения возможной пр о тиворечивости хранимых данных . Как указывалось в п . 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). В ней есть многозначная зависимость "Дисциплина-Преп одаватель ": дисциплина (в примере Информатика ) м ожет может читаться несколькими преподавателями (в примере Шип иловым и Голованевским ). Есть и другая многозначная зависимость " Дисциплина-Учебник ": при изучении Информатики испол ьзуются учебники "Паскаль для всех " и "Язык Си ". При этом Преподаватель и Учебник не связныфункциональной зависимостью , что приводи т к появ л ению избыточности (для добавление еще одного учебника придется вв ести в таблицу две новых строки ). Дело улучшается при замене этой таблицы на две : (Дисциплина-Преподаватель и Дисциплина-Учебник ). Процедура нормали зации Как уже говори лось , нормализация – эт о разбиение та блицы на несколько , обладающих лучшими свойст вами при обновлении , включении и удалении данных . Теперь можно дать и другое определ ение : нормализация – это процесс последовате льной замены таблицы ее полными декомпозициям и до тех пор , пока все о ни не будут находиться в 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 на T1(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. Для любой зада нной таблицы , повторяя применение двух рассмо тренных правил , почти во всех практических ситуациях можно получить в конечном счете множество таблиц , которые находятся в "ок ончательной " нормальной форме и , таким об разом , не содержат каких-либо функциональных з ависимостей вида , отличного от 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 до 50 0 г . ); Рассмотренный язы к описания данных , основанный на языке 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 с.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
На Дерибасовской встретились две дамы:
- Сарочка, ты ничего не замечаешь?
- Нет, а что?
- Я была в косметическом салоне.
- И шо, таки было закрыто?
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru