рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

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

Введение в проектирование реляционных баз данных - раздел Программирование, Введениев Проектирование Реляционных Баз Данных Цели Проектированиятолько Не...

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

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

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

Поэтому прикладное проектирование до сих пор привлекает некоторыхразработчиков.

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

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

Так называемый, чистый проект БД Каждый фактв одном месте можно создать, используя методологию нормализацииотношений.

И хотя нормализация должна использоваться на завершающей проверочнойстадии проектирования БД, мы начнем обсуждение вопросов проектирования срассмотрения причин, которые заставили Кодда создать основы теориинормализации.Универсальное отношениеПредположим, что проектирование базы данных Питание рис. 3.2 начинается с выявления атрибутов и подбора данных, образец которых часть блюдизготовленных и реализованных 1 9 94 г. показан на рис. 1.Этот вариант таблицы Питание не является отношением, так какбольшинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо,Вид, Рецепт хотя он и большой , Порций и Дата Р остальные же поля таблицы рис.4.1 множественные.

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

Наиболее просто это сделать с помощью простогопроцесса вставки, результат которой показан на рис. 2. Однако такоепреобразование приводит к возникновению большого объема избыточных данных. Блюдо Вид Рецепт Порций Дата Р Продукт Калорийность Вес г Поставщик Город Страна Вес кг Цена Дата П Лобио Закуска Лом. 94 Фасоль 200 Пекин Китай 250 0.37 24 8 94 Лук 40 Киев Украина 94 Масло 30 Рига Латвия 94 Зелень 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- gt F, где K первичный ключ, а F некоторое другое поле. Заметим, что это следует изопределения первичного ключа таблицы, в соответствии с которым K- gt F всегдаимеет место для всех полей данной таблицы.

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

Цель нормализации состоит именно в том, чтобы избавиться от всех этих других функциональных зависимостей, т.е. таких, которые имеют инойвид, чем K- gt F.Если воспользоваться рекомендацией п. 4.5и подменить на время нормализации коды первичных внешних ключей на исходныеключи, то, по существу, следует рассмотреть лишь два случая 1. Таблица имеет составной первичный ключ вида, скажем, К1,К2 , и включаеттакже поле F, которое функционально зависит от части этого ключа, например, отК2, но не от полного ключа.

В этом случае рекомендуется сформировать другуютаблицу, содержащую К2 и F первичный ключ К2 , и удалить F из первоначальнойтаблицы Заменить T K1,K2,F , первичный ключ К1,К2 , ФЗ К2- gt F на T1 K1,K2 , первичный ключ К1,К2 , и T2 K2,F , первичный ключ К2.2. Таблица имеет первичный возможный ключ К, не являющееся возможнымключом поле F1, которое, конечно, функционально зависит от К, и другоенеключевое поле F2, которое функционально зависит от F1. Решение здесь, посуществу, то же самое, что и прежде формируется другая таблица, содержащая F1и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы Заменить T K,F1,F2 , первичный ключ К, ФЗ F1- gt F2 на T1 K, F1 , первичный ключ К, и T2 F1,F2 , первичный ключ F1.Для любой заданной таблицы, повторяя применение двух рассмотренных правил,почти во всех практических ситуациях можно получить в конечном счете множествотаблиц, которые находятся в окончательной нормальной форме и, такимобразом, не содержат каких-либо функциональных зависимостей вида, отличного отK- gt F. Для выполнения этих операций необходимо первоначально иметь в качествевходных данных какие-либо большие таблицы например, универсальныеотношения . Но нормализация ничего не говорит о том, как получить эти большиетаблицы.

В следующей главе будет рассмотрена процедура получения таких исходныхтаблиц, а здесь приведем примеры нормализации.Пример 4.1. Применим рассмотренные правила для полной нормализацииуниверсального отношения Питание рис. 4.2 .Шаг 1. Определение первичного ключа таблицы.

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

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

Тогда в качестве первичного ключа отношения Питание можно использовать следующий набор атрибутов Блюдо, Дата Р, Продукт, Поставщик, Город, Дата П.Шаг 2. Выявление полей, функционально зависящих от части состваногоключа.Поле Вид функционально зависит только от поля Блюдо, т.е. Блюдо- gt Вид.Аналогичным образом можно получить зависимости Блюдо- gt Рецепт Блюдо, Дата Р - gt ПорцийПродукт- gt Калорийность Блюдо, Продукт - gt ВесГород- gt Страна Поставщик, Город, Дата П - gt Цена Шаг 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-значений равными друг другу и т.п.ЛИТЕРАТУРА Атре Ш. Структурный подход к организации баз данных.

М. Финансы и статистика, 1983. 320 с. Бойко В.В Савинков В.М. Проектирование баз данных информационных систем.М. Финансы и статистика, 1989. 351 с. Дейт К. Руководство по реляционной СУБД DB2. М. Финансы и статистика, 1988. 320 с. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М. Мир, 1991. 252 с. Кириллов В.В. Структуризованный язык запросов SQL . СПб. ИТМО, 1994. 80 с. Мартин Дж. Планирование развития автоматизированных систем.

М. Финансы и статистика, 1984. 196 с. Мейер М. Теория реляционных баз данных. М. Мир, 1987. 608 с. Тиори Т Фрай Дж. Проектирование структур баз данных. В 2 кн М. Мир, 1985. Кн. 1. 287 с. Кн. 2. 320 с. Ульман Дж. Базы данных на Паскале. М. Машиностроение, 1990. 386 с. Хаббард Дж. Автоматизированное проектирование баз данных.М. Мир, 1984. 294 с. Цикритизис Д Лоховски Ф. Модели данных.

М. Финансы и статистика, 1985. 344 с.

– Конец работы –

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

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Введение в проектирование реляционных баз данных

Что будем делать с полученным материалом:

Если этот материал оказался полезным для Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Еще рефераты, курсовые, дипломные работы на эту тему:

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

Общее понятие о базах данных. Основные понятия систем управления базами данных. Модели данных. 10
Сетевые технологии обработки данных Компоненты вычислительных сетей... Принципы организации и основные топологии вычислительных сетей Принципы... Сетевой сервис и сетевые стандарты Средства использования сетевых сервисов...

КУРС ЛЕКЦИЙ ПО ИНФОРМАТИКЕ Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — СУБД
ГОУ ВПО ВОЛОГОДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Факультет промышленного менеджмента...

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

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

Лекция 1 Цели и задачи водохозяйственного проектирования 1.Введение в водохозяйственное планирование к проектирование
Лекция Цели и задачи водохозяйственного проектирования... Вопросы Введение в водохозяйственное планирование к проектирование...

Объекты базы данных. Язык определения данных
На сайте allrefs.net читайте: "Объекты базы данных. Язык определения данных"

Проектирование базы данных для учета и анализа качества воздуха на рабочих местах МПКО
База данных, таблица, запрос, форма, первичный ключ, функциональная зависимость, нормализация, информация, данные, пользователь.Объектом… Назначение данной базы данных состоит в регистрации, корректировке, хранении и… The objective of work creation of a database for the account and the analysis of parameters of quality of air on…

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

Пример проектирования базы данных "Библиотека"
ББК 32.973 Рис. 1. Макет аннотированной каталожной карточки Для ведения библиотечных каталогов, организации поиска требуемых изданий и библиотечной… В ней используется цифро-буквенные индексы ступенчатой структуры. Каждый из девяти классов 1. Марксизм-ленинизм 2. Естественные науки 3. Техника. Технические науки 4. Сельское и лесное…

0.035
Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • По категориям
  • По работам
  • База данных должна содержать следующие элементы данных Спроектировать базу данных... Для Excel... подготовить таблицу и заполнить ее данными с использованием стандартной формы по тематике задания не менее строк...
  • Использование электронной таблицы как базы данных. Сортировка и фильтрация данных в Microsoft Excel 97 Существуют ограничения, накладываемые на структуру базы данных: • первый ряд базы данных должен содержать неповторяющиеся имена полей; • остальные… Сортировка - это упорядочение данных по возрастанию или по убыванию. Проще… Это средство отображает подмножество данных, не перемещая и не сортируя данные. При фильтрации базы отображаются…
  • Проектирование логической структуры базы данных АБИС В библиотечном деле сложилась следующая ситуация - автоматизация в библиотечном деле существенно отставала в своем развитии от НТИ, и к началу… С другой стороны, подавляющая часть библиотек, пережив кризисные годы, начала… Самое же главное, что в последние годы активно ведется проектирование корпоративных библиотечных систем, в рамках…
  • Проектирование базы данных "Диспетчеризация аудиторного фонда" Каждый семестр составляется учебное расписание, при составлении которого приходится учитывать огромное количество факторов Учебный план ,размеры и… Документы теряются, возникает бедлам и бестолковщина. Расписание исправляется,… Таким образом можно сделать вывод, что такая база нужна, полезна и многофункциональна.РАЗРАБОТКА ПРЕДМЕТНОЙ ОБЛАСТИ.…
  • Tеория проектирования удаленных баз данных Компьютеры могут соединяться друг с другом непосредственно либо через узлы связи. Внутри здания или в пределах небольшой территории ЛВС позволяет… ЛВС позволяет многим пользователям одновременно работать с одним файлом,… ЛВС позволяет быстро копировать файлы любого размера с одной машины на другую без использования дискет. Доступ к…