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

Реферат

CК Раскрыть особенности внешнего (финансового) анализа

Банк рефератов / Бухгалтерский учет и аудит

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

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

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

1 Оглавление. О главление. 3 Теоретическая часть. 4 Р еляционная модель данных 4 Проектирование реляционных БД на основе принципов нормализац ии и семантическое моделирование баз данных 6 П роектирование реляционных баз данных с использованием 7 п ринципов нормализации 7 В торая нормальная форма 8 Т ретья нормальная форма 10 Н ормальная форма Бойса-Кодда 11 Ч етвертая нормальная форма 12 П ятая нормальная форма 13 С емантическое моделирование данных, ER-диаграммы 14 С емантические модели данных 14 Семантическая модель Entity-Relationship (Сущность-Свя зи) 15 С пециальная часть. 19 Оп исание предметной области. 19 Ан ализ предметной области и определение сущностей, связей, атрибутов. 19 Ди аграммы сущность – связь. 22 С остав 22 Товар 22 Ди аграмма сущность - связь. 25 По строение первичного реляционного отношения. 26 Пр оведение нормализации исходного реляционного отношения. 27 П ервая нормальная форма. 27 Вторая нормальная форма. 29 Т ретья нормальная форма. 29 BCNF - нормальная форма Бойса-Кодда. 29 Ч етвертая нормальная форма. 29 Ре ляционное отношение в четвертой нормальной форме. 30 Сх ема данных. 32 П риложение. 33 Список использованной литературы. 36 24 Теоретическая часть. Реляционная модель данных К огда в предыдущих разделах мы говорили об основных понятиях реляционны х баз данных, мы не опирались на какую-либо конкретную реализацию. Эти рас суждения в равной степени относились к любой системе, при построении кот орой использовался реляционный подход. Другими словами, мы использовал и понятия так называемой реляционной модели данных. Модель данных описы вает некоторый набор родовых понятий и признаков, которыми должны облад ать все конкретные СУБД и управляемые ими базы данных, если они основыва ются на этой модели. Наличие модели данных позволяет сравнивать конкрет ные реализации, используя один общий язык. Хотя понятие модели данных яв ляется общим, и можно говорить о иерархической, сетевой, некоторой семан тической и т.д. моделях данных, нужно отметить, что это понятие было введен о в обиход применительно к реляционным системам и наиболее эффективно и спользуется именно в этом контексте. Попытки прямолинейного применени я аналогичных моделей к дореляционным организациям показывают, что рел яционная модель слишком "велика" для них, а для постреляционных организа ций она оказывается "мала". Общая характеристика Н аиболее распространенная трактовка реляционной модели данных, по-види мому, принадлежит Дейту, который воспроизводит ее (с различными уточнени ями) практически во всех своих книгах. Согласно Дейту, реляционная модел ь состоит из трех частей, описывающих разные аспекты реляционного подхо да: структурной части, манипуляционной части и целостной части. В структ урной части модели фиксируется, что единственной структурой данных, исп ользуемой в реляционных БД, является нормализованное n-арное отношение. По сути дела, в предыдущих двух разделах этой лекции мы рассматривали им енно понятия и свойства структурной составляющей реляционной модели. В манипуляционной части модели утверждаются два фундаментальных механи зма манипулирования реляционными БД - реляционная алгебра и реляционно е исчисление. Первый механизм базируется в основном на классической тео рии множеств (с некоторыми уточнениями), а второй - на классическом логиче ском аппарате исчисления предикатов первого порядка. Далее мы рассмотр им эти механизмы более подробно, а пока лишь заметим, что основной функци ей манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называетс я реляционным, если он обладает не меньшей выразительностью и мощностью , чем реляционная алгебра или реляционное исчисление. Целостность сущности и ссылок Н аконец, в целостной части реляционной модели данных фиксируются два баз овых требования целостности, которые должны поддерживаться в любой рел яционной СУБД. Первое требование называется требованием целостности с ущностей. Объекту или сущности реального мира в реляционных БД соответс твуют кортежи отношений. Конкретно требование состоит в том, что любой к ортеж любого отношения должен быть отличим от любого другого кортежа эт ого отношения, т.е. другими словами, любое отношение должно обладать перв ичным ключом. Как мы видели в предыдущем разделе, это требование автомат ически удовлетворяется, если в системе не нарушаются базовые свойства о тношений. Второе требование называется требованием целостности по ссы лкам и является несколько более сложным. Очевидно, что при соблюдении но рмализованности отношений сложные сущности реального мира представля ются в реляционной БД в виде нескольких кортежей нескольких отношений. Н апример, представим, что нам требуется представить в реляционной базе да нных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количес тво сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотруд ника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника ) и СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при прави льном проектировании соответствующей БД в ней появятся два отношения: О ТДЕЛЫ (ОТД_НОМЕР, ОТД_КОЛ) (первичный ключ - ОТД_НОМЕР) и СОТРУДНИКИ (СОТР_НОМ ЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ) (первичный ключ - СОТР_НОМЕР). Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что но мер отдела является собственным свойством сотрудника, а лишь для того, ч тобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДН ИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором корте же отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поск ольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первично го ключа). Говорят, что отношение, в котором определен внешний ключ, ссылае тся на соответствующее отношение, в котором такой же атрибут является пе рвичным ключом. Требование целостности по ссылкам, или требование внешн его ключа, состоит в том, что для каждого значения внешнего ключа, появляю щего в ссылающемся отношении, в отношении, на которое ведет ссылка, долже н найтись кортеж с таким же значением первичного ключа, либо значение вн ешнего ключа должно быть полностью неопределенным (т.е. ни на что не указы вать). Для нашего примера это означает, что если для сотрудника указан ном ер отдела, то этот отдел должен существовать. Ограничения целостности су щности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостно сти сущности достаточно гарантировать отсутствие в любом отношении ко ртежей с одним и тем же значением первичного ключа. С целостностью по ссы лкам дела обстоят несколько более сложно. Понятно, что при обновлении сс ылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при уда лении кортежа из отношения, на которое ведет ссылка? Здесь существуют тр и подхода, каждый из которых поддерживает целостность по ссылкам. Первый подход заключается в том, что запрещается производить удаление кортежа , на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиес я кортежи, либо соответствующим образом изменить значения их внешнего к люча). При втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически ст ановится неопределенным. Наконец, третий подход (каскадное удаление) сос тоит в том, что при удалении кортежа из отношения, на которое ведет ссылка , из ссылающегося отношения автоматически удаляются все ссылающиеся ко ртежи. В развитых реляционных СУБД обычно можно выбрать способ поддержа ния целостности по ссылкам для каждой отдельной ситуации определения в нешнего ключа. Конечно, для принятия такого решения необходимо анализир овать требования конкретной прикладной области. Проектирование реляционных БД на основе принципов нормал изации и семантическое моделирование баз данных При проектировании базы данных решаются две основные проблемы: · Ото бражение объектов предметной области в абстрактные объекты модели дан ных таким образом, чтобы это отображение не противоречило семантике пре дметной области и было по возможности лучшим (эффективным, удобным и т.д.). Часто эту проблему называют проблемой логического проектирования баз данных. Обеспечение эффективного выпол нения запросов к базе данных, т.е. рациональное расположение данных во вн ешней памяти, создание полезных дополнительных структур (например, инде ксов) с учетом особенностей конкретной СУБД. Эту проблему называют пробл емой физического проектирования баз данных. В случае реляционных баз данных трудно представить какие-либо общие реце пты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Например, при работе с СУБД Ingres можно выбирать один из п редлагаемых способов физической организации отношений, при работе с System R следовало бы прежде всего подумать о кластеризации отношений и требуем ом наборе индексов и т.д. Поэтому мы ограничимся вопросами логического п роектирования реляционных баз данных, которые существенны при использ овании любой реляционной СУБД. Более того, мы не будем касаться очень важного аспекта проектирования - о пределения ограничений целостности (за исключением ограничения первич ного ключа). Дело в том, что при использовании СУБД с развитыми механизмам и ограничений целостности (например, SQL-ориентированных систем) трудно пр едложить какой-либо общий подход к определению ограничений целостност и. Эти ограничения могут иметь очень общий вид, и их формулировка пока отн осится скорее к области искусства, чем инженерного мастерства. Самое бол ьшее, что предлагается по этому поводу в литературе, - это автоматическая проверка непротиворечивости набора ограничений целостности. Поэтому будем считать, что пробл ема проектирования реляционной базы данных состоит в обоснованном при нятии решений о том, из каких отношений должна состоять БД и какие атрибу ты должны быть у этих отношений. Заметим, что мы намеренно упрощаем проблему логического п роектирования, чтобы иметь возможность представить наиболее общие иде и. Более конкретные методы и алгоритмы можно найти в разных статьях этог о журнала. Проектирование реляционных баз данных с использованием принципов нормализации С начала мы рассмотрим классический подход, при котором весь процесс прое ктирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отнош ений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования произв одится некоторый набор схем отношений, обладающих лучшими свойствами. П роцесс проектирования представляет собой процесс нормализации схем от ношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая. Каждой нормальной форме соответ ствует некоторый определенный набор ограничений, и отношение находитс я в некоторой нормальной форме, если удовлетворяет свойственному ей наб ору ограничений. Примером является ограничение первой нормальной форм ы: значения всех атрибутов отношения должны быть атомарными (еще раз отм етим, что понятие первой нормальной формы и ее свойства отличаются некот орой тавтологичностью, поскольку являются следствиями основных опреде лений реляционных категорий). Поскольку требование первой нормальной ф ормы является базовым требованием классической реляционной модели дан ных, мы будем считать, что исходный набор отношений уже соответствует эт ому требованию. В теории реляционных баз данных обычно выделяется следую щая последовательность нормальных форм: · пер вая нормальная форма (1NF); вторая нормальная форма (2NF); третья нормальная форма (3NF); нормальная форма Бойса-Кодда (BCNF) (правильнее было бы считать эту нормальн ую форму третьей, однако по историческим причинам третья ступень оказал ась занятой к моменту изобретения BCNF, из-за чего она и получила нестандарт ное название); четвертая нормальная форма (4NF); пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). О сновные свойства нормальных форм: · каж дая следующая нормальная форма в некотором смысле улучшает свойства пр едыдущей; при переходе к следующей нормаль ной форме свойства предыдущих нормальных форм сохраняются. В основе классического процесса проектирования лежит метод нормализаци и, который опирается на декомпозицию (на основе проекции) отношения, нахо дящегося в предыдущей нормальной форме, в два или более отношения, удовл етворяющих требованиям следующей нормальной формы. Наиболее важные на практике нормальные формы отношений основываются н а фундаментальном в теории реляционных баз данных понятии функциональ ной зависимости. Для дальнейшего изложения нам потребуются несколько о пределений. Определение 1: Функциональная зависимость (functional dependence - FD). В отношении R атрибут Y функционально зависит от атрибута X (X и Y мо гут быть составными атрибутами, т.е. реально состоять из нескольких атом арных атрибутов) в том и только в том случае, если каждому значению X соотв етствует в точности одно значение Y: R.X -> R.Y. З амечание: Термин "функциональная зависимость" не случаен, поскольку в то чности соответствует математическому понятию функции. Определение 2: Полная функциональная зависимость. Функциональная зависимость R.X -> R.Y называется полной, если атрибу т Y не зависит функционально от любого точного подмножества X (точным подм ножеством множества X называется любое его подмножество, не совпадающее с X). Определение 3: Транзитивная функ циональная зависимость. Функциональная зависимость R.X -> R.Y н азывается транзитивной, если существует такой атрибут Z, что имеются фун кциональные зависимости R.X -> R.Z и R.Z -> R.Y. Определение 4: Возможный ключ (alternative key). Возможн ым ключом отношения называется его атомарный или составной атрибут, зна чения которого полностью функционально определяют значения всех остал ьных атрибутов отношения. Определение 5: Неключевой атрибут. Неключев ым атрибутом называется любой атрибут отношения, не входящий в состав пе рвичного ключа. Определение 6: Взаимно независимые атрибуты. Два или более атрибута называются взаимно независимыми, если ни од ин из этих атрибутов не является функционально зависимым от других атри бутов. Вторая нормальная форма Рассмотрим следующий пример схе мы отношения: СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НО МЕР, СОТР_ЗАДАН) Первичный ключ: СОТР_НОМЕР, ПРО_НОМЕР Фу нкциональные зависимости: СОТР_НОМЕР -> СОТР_ЗАРП СОТР _ НОМЕР -> ОТД _ НОМЕР ОТД _ НОМЕР -> СОТР _ ЗАРП СОТР _ НОМЕР , ПРО _ НОМЕР -> СОТР _ ЗАДАН К ак видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, П РО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части п ервичного ключа, т.е. атрибута СОТР_НОМЕР. В результате, мы не сможем встав ить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудни ка, который еще не выполняет никакого проекта (первичный ключ не может со держать неопределенное значение). При удалении кортежа мы не только разр ушаем связь данного сотрудника с данным проектом, но утрачиваем информа цию о том, что он работает в некотором отделе. При переводе сотрудника в др угой отдел мы будем вынуждены модифицировать все кортежи, описывающие э того сотрудника, или получим несогласованный результат. Такие неприятн ые явления называются аномалиями схемы отношения. Они устраняются путе м нормализации. Определение 7. Вторая нормальная форма. Отн ошение R находится во второй нормальной форме (2NF) в том и только в том случа е, когда находится в 1NF и каждый неключевой атрибут полностью зависит от п ервичного ключа. Можно произвести следующую декомпозицию отношения СОТ РУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-П РОЕКТЫ: СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР) Пе рвичный ключ: СОТР_НОМЕР Фу нкциональные зависимости: СОТР_НОМЕР -> СОТР_ЗАРП СОТ Р _ НО МЕР -> ОТД _ НОМЕР ОТД _ НОМЕР -> СОТР _ ЗАРП СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН) Пе рвичный ключ: СОТР_НОМЕР, ПРО_НОМЕР Функциональная зависимость: СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН К аждое из этих двух отношений находится в 2NF, и в них устранены отмеченные в ыше аномалии (легко проверить, что все упомянутые выше операции выполняю тся без проблем). Третья нормальная форма Рассмотрим еще раз отношение СО ТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимост ь СОТР_НОМЕР СОТР_ЗАРП является транзитивной; она является следствием (в смысле математической логики) функциональных зависимостей СОТР_НОМЕР ОТД_НОМЕР и ОТД_НОМЕР СОТР_ЗАРП. Другими словами, заработная плата сотруд ника на самом деле является характеристикой не сотрудника, а отдела, в ко тором он работает (это не очень естественное предположение, но достаточн ое для примера). В результате, мы не сможем занести в базу данных информаци ю, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать не определенное значение). При удалении кортежа, описывающего последнего с отрудника данного отдела, мы лишимся информации о заработной плате отде ла. Чтобы согласованным образом изменить заработную плату отдела, мы буд ем вынуждены предварительно найти все кортежи, описывающие сотруднико в этого отдела. Т.е. в отношении СОТРУДНИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации. Определение 8. Третья нормальная ф орма. Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут н етранзитивно зависит от первичного ключа. Эквивалентным определением (доказательство эквивален тности мы оставляем читателю) является следующее: Определение 9. Третья нормальная форма (альтернативное оп ределение). Отношение R находится в третьей нормальной фор ме (3NF) в том и только в том случае, если все неключевые атрибуты R взаимно нез ависимы и полностью зависят от первичного ключа. Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТ ДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ: СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР ) Первичный ключ: СОТР_НОМЕР Функциональная зависимость: СОТР_НОМЕР -> ТД_НОМЕР ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП) Первичный ключ: ОТД_НОМЕР Функциональная зависимость: ОТД_НОМЕР -> СОТР_ЗАРП Каждое из этих двух отношений на ходится в 3NF и свободно от отмеченных аномалий. На практике третья нормальная форма схем отношений являе тся достаточной в большинстве случаев и приведением к третьей нормальн ой форме процесс проектирования реляционной базы данных обычно заканч ивается. Однако иногда полезно продолжить процесс нормализации. Нормальная форма Бойса-Кодда Р ассмотрим следующий пример схемы отношения: СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_И МЯ, ПРО_НОМЕР, СОТР_ЗАДАН) В озможные ключи (обратите внимание, что на этой стадии нормализации во вн имание принимаются существование возможных ключей): СОТР_НОМЕР, ПРО_НОМЕР СОТР _ ИМЯ , ПРО _ НОМЕР Функциональные зависимости: СОТР_НОМЕР -> СОТР_ИМЯ СОТР _ НОМЕР -> ПРО _ НОМЕР СОТР _ ИМЯ -> СОТР _ НОМЕР СОТР _ ИМЯ -> ПРО _ НОМЕР СОТР _ НОМЕР , ПРО _ НОМЕР -> СОТР _ ЗАДАН СОТР _ ИМЯ , ПРО _ НОМЕР -> СОТР _ ЗАДАН В этом примере мы предполагаем, что личность сотрудника полностью опреде ляется как его номером, так и именем (это снова не очень жизненное предпол ожение, но достаточное для примера). Независимо от того, какой из возм ожных ключей выбран в качестве первичного ключа, эта схема находится в 3NF. Однако тот факт, что имеются функциональные зависимости атрибутов отно шения от атрибута, являющегося частью первичного ключа, приводит к анома лиям. Например, для того, чтобы изменить имя сотрудника с данным номером с огласованным образом, нам потребуется модифицировать все кортежи, вклю чающие его номер. Определение 10. Детерминант. Детерминантом называется любой атрибут, от которого полностью функционально зависит некоторый другой атрибут. Определение 11. Нормальная форма Бойса-Кодда. Отношение R находится в нормальной форме Бойс а-Кодда (BCNF) в том и только в том случае, если каждый детерминант является во зможным ключом. Замечание: Легко заметить, что ес ли в отношении имеется только один возможный ключ (являющийся первичным ключом), то это определение становится эквивалентным определению треть ей нормальной формы. Очевидно, что это требование не в ыполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомп озицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ: СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ) Возможные ключи: СОТР_НОМЕР СОТР _ ИМЯ Функциональные зависимости: СОТР_НОМЕР -> СОТР_ИМЯ СОТР _ ИМЯ -> СОТР _ НОМЕР СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН) Возможный ключ: СОТР_НОМЕР, ПРО_НОМЕР Функциональные зависимости: СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН В озможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ на ходятся в BCNF, и им не свойственны отмеченные аномалии. Четвертая нормальная форма Р ассмотрим пример следующей схемы отношения: ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН) О тношение ПРОЕКТЫ содержит номера проектов, для каждого проекта - список сотрудников, которые могут выполнять проект, и список заданий, предусмат риваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания. Каждый кортеж отношения связыва ет некоторый проект с сотрудником, участвующим в этом проекте, и задание м, который сотрудник выполняет в рамках данного проекта (мы предполагаем , что любой сотрудник, участвующий в проекте, выполняет все задания, преду смотренные этим проектом). По причине сформулированных выше условий еди нственным возможным ключом отношения является составной атрибут ПРО_Н ОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов. Следователь но, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостаткам и: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько зада ний в нем предусмотрено. Определение 12. Многозначная завис имость. В отношении R (A, B, C) существует многозначная зависимо сть (multi-valued dependence - MVD) R.A ->-> R.B в том и только в том случае, если множество значений B, соо тветствующее паре значений A и C, зависит только от A и не зависит от С. В отношении ПРОЕКТЫ существуют следующие две многознач ные зависимости: ПРО_НОМЕР ->-> ПРО_СОТР ПРО _ НОМЕР ->-> ПРО _ ЗАДАН Н етрудно показать, что в общем случае в отношении R (A, B, C) существует многозна чная зависимость R.A ->-> R.B в том и только в том случае, когда существует многоз начная зависимость R.A ->-> R.C. Поэтому далее мы употребляем обозначение A ->-> B | C в т ом смысле, что одновременно существуют MVD A ->-> B и A ->-> C. Дальнейшая нормализация отноше ний, подобных отношению ПРОЕКТЫ, основывается на следующей теореме: Теорема Фейджина О тношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и то лько в том случае, когда существует MVD A ->-> B | C. Под проецированием без потерь п онимается такой способ декомпозиции отношения, при котором исходное от ношение полностью и без избыточности восстанавливается путем естестве нного соединения полученных отношений. Определение 13. Четвертая нормальн ая форма. Отношение R находится в четвертой нормальной фор ме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A "" B все остальные атрибуты R функционально зависят от A. В нашем примере можно произвести декомпозицию отношени я ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ: ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТ Р) ПРОЕКТЫ - ЗАДАНИЯ ( ПРО _ НОМЕР , ПРО _ ЗАД АН ). О ба эти отношения находятся в 4NF и свободны от отмеченных аномалий. Пятая нормальная форма В о всех рассмотренных до этого момента нормализациях производилась дек омпозиция одного отношения в два. Иногда это сделать не удается, но возмо жна декомпозиция в большее число отношений, каждое из которых обладает л учшими свойствами. Рассмотрим, например, отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР , ОТД_НОМЕР, ПРО_НОМЕР) Пр едположим, что один и тот же сотрудник может работать в нескольких отдел ах и в каждом отделе принимать участие в нескольких проектах. Первичным ключом этого отношения является полная совокупность его атрибутов, отс утствуют функциональные и многозначные зависимости. Поэтому отношение находится в 4NF. Однако в нем могут сущес твовать аномалии, которые можно устранить путем декомпозиции в три отно шения. Определение 14. Зависимость соединения. Отн ошение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без по терь путем соединения своих проекций на X, Y, ..., Z. Определение 15. Пятая нормальная форма. Отношение R находится в пятой нормальной форме (норм альной форме проекции-соединения - PJ/NF) в том и только в том случае, когда люб ая зависимость соединения в R следует из существования некоторого возмо жного ключа в R. Введем следующие имена составны х атрибутов: СО = СОТР_НОМЕР, ОТД_НОМЕР СП = СОТР _ НОМЕР , ПРО _ НОМЕР ОП = ОТД _ НОМЕР , ПРО _ НОМЕР П редположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ существует завис имость соединения: * (СО, СП, ОП) Н а примерах можно легко показать, что при вставках и удалениях кортежей м огут возникнуть проблемы. Их можно устранить путем декомпозии исходног о отношения в три новых отношения: СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМ ЕР) СОТРУДНИКИ - ПРОЕКТЫ ( СОТР _ НОМЕР , ПРО _ НОМ ЕР ) ОТДЕЛЫ - ПРОЕКТЫ ( ОТД _ НОМЕР , ПРО _ НОМЕР ) П ятая нормальная форма - это последняя нормальная форма, которую можно по лучить путем декомпозиции. Ее условия достаточно нетривиальны, и на прак тике 5NF не используется. Заметим, что зависимость соединения является обо бщением как многозначной зависимости, так и функциональной зависимост и. Семантическое моделирование данных, ER-диаграммы Ш ирокое распространение реляционных СУБД и их использование в самых раз нообразных приложениях показывает, что реляционная модель данных дост аточна для моделирования предметных областей. Однако проектирование р еляционной базы данных в терминах отношений на основе кратко рассмотре нного нами механизма нормализации часто представляет собой очень слож ный и неудобный для проектировщика процесс. При этом проявляется ограниченн ость реляционной модели данных в следующих аспектах: · Мод ель не предоставляет достаточных средств для представления смысла дан ных. Сематика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относ ится к упоминавшейся нами проблеме представления ограничений целостно сти. Для многих приложений трудно мод елировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится прои зводить насилие над собой, чтобы описать предметную область в виде одной (возможно даже ненормализованной) таблицы. Хотя весь процесс проектирования происходит на основе учета зависимос тей, реляционная модель не предоставляет каких-либо средств для предста вления этих зависимостей. Несмотря на то, что процесс проектирования начинается с выделения некот орых существенных для приложения объектов предметной области ("сущност ей") и выявления связей между этими сущностями, реляционная модель данны х не предлагает какого-либо аппарата для разделения сущностей и связей. Семантические модели данных П отребности проектировщиков баз данных в более удобных и мощных средств ах моделирования предметной области породили направление семантическ их моделей данных. При том, что любая развитая семантическая модель данн ых, как и реляционная модель, включает структурную, манипуляционную и це лостную части, главным назначением семантических моделей является обе спечение возможности выражения семантики данных. Прежде, чем мы коротко рассмотри м особенности одной из распространенных семантических моделей, остано вимся на их возможных применениях. Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в тер минах семантической модели производится концептуальная схема базы дан ных, которая затем вручную преобразуется к реляционной (или какой-либо д ругой) схеме. Этот процесс выполняется под управлением методик, в которы х достаточно четко оговорены все этапы такого преобразования. Менее часто реализуется автоматизированная компиляция концептуальной схемы в реляционную. Известны два подхода: подход, основа нный на явном представлении концептуальной схемы как исходной информа ции для компиляции, и подход, ориентированный на построение интегрирова нных систем проектирования с автоматизированным созданием концептуал ьной схемы на основе интервью с экспертами предметной области. И в том, и в другом случае в результате производится реляционная схема базы данных в третьей нормальной форме (более точно следовало бы сказать, что автору неизвестны системы, обеспечивающие более высокий уровень нормализации ). Наконец, третья возможность, которая еще не вышла (или толь ко выходит) за пределы исследовательских и экспериментальных проектов , - это непосредственная работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических моделях данных. При этом снова рассмат риваются два варианта: обеспечение пользовательского интерфейса на ос нове семантической модели данных с автоматическим отображением констр укций в реляционную модель данных (это задача примерно такого же уровня сложности, как автоматическая компиляция концептуальной схемы базы да нных в реляционную схему) и прямая реализация СУБД, основанная на какой-л ибо семантической модели данных. Наиболее близко ко второму подходу нах одятся современные объектно-ориентированные СУБД, модели данных котор ых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы). Семантическая модель Entity-Relationship (Сущность-Связи) Д алее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных - модель "Сущность-Связи" (часто ее называют кратко ER-моделью). На использовании разновидносте й ER-модели основано большинство современных подходов к проектированию б аз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. (оригинальная статья Чена опубликована в третьем номере нашего жур нала). Моделирование предметной области базируется на использовании гр афических диаграмм, включающих небольшое число разнородных компоненто в. В связи с наглядностью представления концептуальных схем баз данных ER- модели получили широкое распространение в системах CASE, поддерживающих а втоматизированное проектирование реляционных баз данных. Среди множес тва разновидностей ER-моделей одна из наиболее развитых применяется в си стеме CASE фирмы ORACLE. Ее мы и рассмотрим. Точнее говоря, мы сосредоточимся на структурной части это й модели. Основные понятия и определения О сновными понятиями ER-модели являются сущность, связь и атрибут. Сущность - это реальный или предс тавляемый объект, информация о котором должна сохраняться и быть доступ на. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некото рого конкретного экземпляра этого типа. Для большей выразительности и л учшего понимания имя сущности может сопровождаться примерами конкретн ых объектов этого типа. Ниже изображена сущность (точнее, тип сущности) АЭРОПОРТ с примерными объектами Шереметьево и Хитроу: Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование в некотором роде аналогич но требованию отсутствия кортежей-дубликатов в реляционных таблицах или требованию иде нтифицируемости объектов (object identity) в объектно-ориен тированных системах ). Связь - это графически изображае мая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущн остями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых с ущностей), на каждом из которых указывается имя конца связи, степень конц а связи (сколько экземпляров данной сущности связывается), обязательнос ть связи (т.е. любой ли экземпляр данной сущности должен участвовать в дан ной связи). Связь представляется в виде линии, связывающей две сущнос ти или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи с сущностью используются трехточечный вход в прямоугольник сущности, е сли для этой сущности в связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только оди н экземпляр сущности. Обязательный конец связи изображается сплошной л инией, а необязательный - прерывистой линией. Как и сущность, связь - это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания. В изображенном ниже примере связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с имене м "для" позволяет связывать с одним пассажиром более одного билета, приче м каждый билет должен быть связан с каким-либо пассажиром. Конец сущност и с именем "имеет" означает, что каждый билет может принадлежать только од ному пассажиру, причем пассажир не обязан иметь хотя бы один билет. Лаконичной устной тракто вкой изображенной диаграммы является следующая : · Каж дый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА; Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ. Н а следующем примере изображена рекурсивная связь, связывающая сущност ь ЧЕЛОВЕК с ней же самой. Конец связи с именем "сын" определяет тот факт, что у одного отца может быть более чем один сын. Конец связи с именем "отец" озн ачает, что не у каждого человека могут быть сыновья. Лаконичной устной трактовкой изображенной диаграммы явл яется следующая : · Каж дый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА; Каждый ЧЕЛОВЕК может являться от цом для одного или более ЛЮДЕЙ ("ЧЕЛОВЕКОВ"). А трибутом сущности является любая деталь, которая служит для уточнения, и дентификации, классификации, числовой характеристики или выражения со стояния сущности. Имена атрибутов заносятся в прямоугольник, изображаю щий сущность, под именем сущности и изображаются малыми буквами, возможн о, с примерами. Пример: Уникальным идентификатором сущности является атрибут , к омбинация атрибутов , комбинация связей или ко мбинация связей и атрибутов , уникально отлича ющая любой экземпляр сужности от других экземпляров сущности того же типа . Как и в реляционных схемах баз да нных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень б лизко соответствует смыслу реляционных нормальных форм. Заметим, что фо рмулировки нормальных форм ER-схем делают более понятным смысл нормализа ции реляционных схем. Мы приведем только очень краткие и неформальные оп ределения трех первых нормальных форм. В первой нормальной форме ER-схемы устраняются повторяющи еся атрибуты или группы атрибутов, т.е. производится выявление неявных с ущностей, "замаскированных" под атрибуты. Во второй нормальной форме устаняются атрибуты, зависящи е только от части уникального идентификатора. Эта часть уникального иде нтификатора определяет отдельную сущность. В третьей нормальной форме устраняются атрибуты, зависящ ие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты яв ляются основой отдельной сущности. Мы остановились только на самых основных и наиболее очеви дных понятиях ER-модели данных. К числу более сложных элементов модели отн осятся следующие: · Под типы и супертипы сущностей . Как в языках программирования с развитыми типовыми системами (например, в языках объектно-ориентирован ного программирования), вводится возможность наследования типа сущнос ти, исходя из одного или нескольких супертипов. Интересные нюансы связан ы с необходмостью графического изображения этого механизма. Связи "many-to-many". Иногда бывает необходимо связыв ать сущности таким образом, что с обоих концов связи могут присутствоват ь несколько экземпляров сущности (например, все члены кооператива сообщ а владеют имуществом кооператива). Для этого вводится разновидность свя зи "многие-со-многими". Уточняемые степени связи. Иногда бывает п олезно определить возможное количество экземпляров сущности, участвую щих в данной связи (например, служащему разрешается участвовать не более , чем в трех проектах одновременно). Для выражения этого семантического о граничения разрешается указывать на конце связи ее максимальную или об язательную степень. Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связ и "один-ко-многим"), что при удалении опорного экземпляра сущности (соответ ствующего концу связи "один") нужно удалить и все экземпляры сущности, соо тветствующие концу связи "многие". Соответствующее требование "каскадно го удаления" можно сформулировать при определении сущности. Домены. Как и в случае реляционной модели данных, бывает полезна возможность определения потенциально допустимо го множества значений атрибута сущности (домена). Эти и другие более сложные элементы модели данных "Сущность-Связ и" делают ее существенно более мощной, но одновременно несколько усложня ют ее использование. Конечно, при реальном использовании ER-диаграмм для п роектирования баз данных необходимо ознакомиться со всеми возможностя ми. Специальная часть. Описание предметной области. В данной курсовой работе будет описана и разработана база данных по учет у товара в организации, занимающееся торгово-закупочной деятельностью более конкретно: мясопродуктов и сопутствующих им товаров. В данной базе данных необходимо хранить следующую информацию: · Информация о месте и времени при обретения товара, эта информация необходима для того, чтобы всегда можно было быстро найти поставщика и обратиться к нему в случае каких-либо про блем с товаром; Информация о составе товара; Информация о сотрудниках, работающих и отвечающих за товар, а также расп исание их работы; Информация о перемещении товара со склада; Далее все эти пункты будут рассмотрены более подробно. Анализ предметной области и определение сущностей, связ ей, атрибутов. Сущность (entity) - это объект, который может быть идентифициров ан неким способом, отличающим его от других объектов. Анализируя предметную область, можно выделить следующие сущности: Таблица 1. Сущности. Сущность Описание Товар В данной сущности должна хранится общая инф ормация о товаре, такая как его наименование, код товара, некоторая физич еская характеристика а также связь с другими сущностями. Состав Каждый товар состоит из нескольких частей. Они могут приобретаться отдельно, поэтому здесь необходимо хранить дат ы приобретения, а также информацию о ветеринарном освидетельствовании. Ветеринарное освидетельство вание Здесь необходимо храни ть информацию о дате, когда было пройдено ветеринарное освидетельствов ание. Персонал Информация о людях, работающих на данной орг анизации, такая как ФИО, должность, день рождения, оклад и их расписание. Расписание Расписание работы персонала. Местоположение Физическое положение товара, наименование склада и дата поступления. А также история перемещения товара. Покупатель В данной сущности будет хранится информаци я о покупателе, такая как его наименование, код покупателя, юридический а дрес и ИНН, а также связь с другими сущностями. Время Время работы персонала в конкретный день Атрибут - это функци я, отображающая набор сущностей в набор значений или в декартово произве дение наборов значений. Сущность фактически представляет из себя множество атрибутов , которые описывают свойства всех ч ленов данного набора сущностей. В данном отношении можно выделить следу ющие атрибуты: Таблица 2. Атрибуты. Су щность Атрибут Описание Товар Код товара Код товара. Наименование Некоторое текстовое обозначе ние. Состав Дата приобретения Дата поступления данной части, дата приобретения партии состоит из даты прио бретения и какой то части. Поставщик Наименовани е поставщика, у которого был приобретен товар. Дата Дата ветеринарног о освидетель-ствования. Ветеринарное освидетельствова ние Дата Дата прохождения. Код товара Наименование товара прошедшее вет .освидетельствование Персонал Ф.И.О. Фамилия, имя и отчество сотрудника Должность Должность со трудника. Табельный номер. День рождения Таб № ДР ЗП Заработная плата сотрудника, согл асно должности. Расписание Таб № Таб. № сотрудника Код товара Код товара за к оторый несет ответственность сотрудник Время День День недели. Начало Время начала работы сотрудника Конец Время окончания работы сотрудника Местоположение Дата перемещения Дата прибытия товара на склад Склад Склад, на котором находится товар Покупатель Наименование покупателя Некоторое текстовое пояснени е Код покупателя Код покупателя Характеристики Юридич еский адрес, ИНН, Связь (relationship) - это ассоциация, установленная меж ду несколькими сущностями. Таблица 3. Связи. Сущность Связь Сущность Описание Состав принадлежит Товар Каждый товар состоит из нескольких частей. Персонал Работает с Товар С определенным товаром может работать несколько человек: экспеди торы, грузчики. Товар находится Местоположение Товар не находится статически на одном складе, он может пе ремещаться по складпм. Доступ к информации о его перемещениях должен осу ществляться из сущности «Товар». Товар Продается Покупатель Чтобы знать, какой покупатель прио бретает данный товар, необходимо просматривать сущность «Покупатель». т овар прошло Вет. освидетель- ствование Данная связь необх одима для просмотра, когда товар прошло ветеринарное освидетельствова ние. С остав прошло Вет. освидетель- ствование П ерсонал Работает по Расписание Данная связь позволяет просмотреть расписание работы конкретно го человека. Диаграммы сущность – связь. Состав - принадлежит – товар. Каждый товар состоит из нескольких частей. Эта связь вида много к одному (n : 1) , так как «товар» всегда состоит из частей. Сущнос ть «Состав» имеет обязательный класс принадлежности, так как «товар» об язательно состоит из «состав», в свою очередь, сущность «состав» имеет н еобязательный класс принадлежности, т. к. «состав» не обязательно входят в «товар». Состав Товар Товар – находится – Местоположение. Товар не находится статически на одном складе, он может перемещаться по складам. Доступ к информации о его перемещениях должен осуществляться из сущности «товар». Эта связь вида много к одному (n : 1) , т ак как «товар» может несколько раз перемещаться по складам. Сущность «то вар» имеет обязательный класс принадлежности, так как «товар» обязател ьно находится в каком-то «Местоположении», в свою очередь, сущность «Мес тоположение» является зависимой от сущности «товар», так как в случае ис чезновения товара (списывания) удаляется и история о его перемещениях. Товар – прошло – Ве т.освидетельствование . Данная связь необходима для просмотра , когда товар прошло вет.свидетельст во . Эта связь вида один ко многим (1 : n ) , так ка к «товар» может несколько раз подвергаться «вет.освидетельствование» . Сущност ь «вет.освидетельствование» имеет обязательный кл асс принадлежности , так как «товар» обязатель но проходит «вет.освидетельствование». Со став – прошло – Вет.освидетельствование. Данная связь необходима для п росмотра, когда товар проходил вет.освидетельствование. Эта связь вида один ко многим (1 : n ) , так как «состав» может несколь ко раз подвергаться «вет.освидетельствование». Сущность «вет.освидете льствование» имеет обязательный класс принадлежности. так как «Состав » обязательно проходит «вет.освидетельствование». Время – принадлежит – Расписание . Эта связь вида много к одному ( n : 1), так как «персонал» может работать несколько разделённых промежутк ов времени в течение одного д ня . С ущность «Расписание» имеет обязательный класс принадлежности , так как обязательно есть пр омежуток времени , в течение которого человек работает . Сущность «время» также имеет об язательный класс принадлежности. Товар– продается – покупатель . Чтобы зна ть , какой покупател ь приобретает данный товар , необходимо просма тривать сущность «Покупатель» . Эта связь вида много к одному (n : 1) , так как «покупатель» представляется как множество контрагентов . Сущнос ть «товар» имеет обязательный класс принадлеж ности, так как хотя бы один товар продается . В свою очередь , сущность «покупат ель» имеет необязательный класс принадлежности , т . к . «товар» не обязательно покупается «покупателем». 31 Диаграмма сущность - связь. Построение первичного реляционного отношения. Реляционная модель данных позволяет достаточно наглядно представить т аблицы базы данных. Здесь будут приведены первичные таблицы, которые в д альнейшем будут улучшены, или доказано, что они не нуждаются в дальнейше м улучшении. Товар Код.товара Составные части Код.товара Д ата приобретения Вет.свидетельство Код во Персонал Таб. № Ф.И.О. Расписани е Код расп. Время Код время Код расп. Местоположение Ко д мест Код.товара Покупатель Код пок упателя Наименование В этих отношениях больше атрибутов, чем было описано выше, так как пришло сь добавить некоторые ключевые атрибуты, такие как Код во , Код мест и другие. При использовании универсального отношения возникает несколько пробл ем: 1. Избыточность . Данные практически некоторых столбцов многократно повторяются. Повторяются и некоторые наборы данных. Потенциальная противоречиво сть (аномалии обновления) . Вследствие избыточности можно заменить одного проживающего или работающего другим и если не изменить фамилию в других строках то получается противоречивость. Аномалии включения . В БД не может быть зап исан проживающего или работающего, если они не занимают какую-нибудь до лжность. Аномалии удаления . Обратная проблема воз никает при необходимости убрать одну из должностей в вузе или в общежити и, которую решили убрать из вакансий, этим мы удаляем любые сведения о тех людях, которые занимают эти должности. При нормализации данные аномалии должны исчезнуть. Проведение нормализации исходн ого реляционного отношения. Необходимо, чтобы полученная база данных находилась в четвертой нормал ьной форме. Для этого поэтапно нужно привести отношение к этой форме. Первая нормальная форма. Определение первой нормальной формы: отношение находит ся в 1 НФ, если значения всех его атрибутов атомарно. После проведения анализа исходного отношения становится видно, что в целом отношение отвечает условиям 1 НФ. Анализируя далее отношение видим, что значение атрибута Персонал ( Должность ) не является атомарны м, так как один сотрудник может занимать несколько должностей. Поэтому н еобходимо составить таблицу должностей. Также необходимо составить та блицу видов должностей, так как должностей не много и они часто повторяю тся, а в случае изменения названия должности придется сканировать всю та блицу, чтобы изменить эти названия. В результате была изменена таблица «персонал» и добавлены таблицы «вид должности» и «занимаемые должности». Эти таблицы были прив едены к следующему виду: Персонал Таб. № Фамилия Имя Вид должности Код вида должности Занимаемые должности Таб. № Анализируя далее отношение видим, что значение атрибута С остав ( поставщик ) необходимо вывести в отдельное отношени е, так как в случае изменения названия поставщика придется сканировать в сю таблицу, чтобы изменить эти названия. В результате была изменена таблица «состав» и добавлена таблица «поста вщики». Эти таблицы были приведены к следующему виду: Состав Код.товара Дата приобретения Физ.хар. Поставщики Код поставщика Н азвание поставщика Адрес ИНН Проанализировав полученное отношение, становится видно, что оно находи тся в первой нормальной форме, так как значения всех атрибутов атомарно. Вторая нормальная форма. Определение второй нормальной формы: Отношение находит ся во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функциональ но полно зависит от ключа. В полученном ранее отношении есть только один составной кл юч: Занимаемые должности ( Таб. №; Код вида должности ). Однако здесь видно, что отношение функционально п олно зависит от обоих ключей. Из всего выше сказанного видно, что отношение находится во второй нормал ьной форме. Третья нормальная форма. Определение третьей нормальной формы: Отношение находи тся в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзити вно зависит от первичного ключа. Последовательно проанализировав все зависимости видим, ч то отношение находится во второй нормальной форме, так как нет нетранзит ивных зависимостей. BCNF - нормальная форма Бойса-Кодда. Определение нормальной формы Бойса-Кодда: Отношение нах одится в BCNF, если оно находится во 3НФ и в ней отсутствуют зависимости атриб утов первичного ключа от неключевых атрибутов. Так как в данном отношении есть только один составной ключ, то отношение находится в нормальной форме Бойса-Кодда. Четвертая нормальная форма. Определение четвертой нормальной формы: Отношение нахо дится в 4NF если оно находится в BCNF и в нем отстутсвуют многозначные зависим ости, не являющиеся функциональными зависимостями. Последовательно проанализировав все зависимости, видим, ч то отношение находится в четвертой нормальной форме, так как в нем нет мн огозначных зависимостей. Таким образом, мы получаем следующее отношение. Реляционное отношение в четверт ой нормальной форме. Товар Код.товара Состав Код.товара Д ата приобретения Поставщик и Ко д поставщика Название поставщика Тех. обслуживан ие Код ТО Вид неисправности Код неиспра вности Персонал Таб. № Вид должности Код вида до лжности Занимаемые должности Таб. № Расписание Код расп. Время Код время Код расп. Местополо жение Ко д мест Инв. № Сеть Код Сеть Принадлежность сети Код принадл ежности 32 Схема данных. 33 Приложение. После всей проделанной выше работы необходимо реализовать полученное отношение при помощи какого-либо приложения. Мною был выбран Microsoft Access , так как он был специально разработан специально для этого и с помо щью него можно реализовать все функции работы с полученной базой данных. Разработанное приложение состоит из нескольких таблиц, оп исанных выше, а также форм, введенных для удобства доступа к данным. Далее будет приведен вид этих форм. Рисунок 1. Форма ввода сотру дников. Данная форма предназначена для ввода сотрудников предприятия. Рисунок 2. Состав оборудования. Рисунок 3. История перемещений компьют ера по отделам. Рисунок 4. Список должностей , занимаемых сотрудниками. Рисунок 5. Расписание работы компьютера. Рисунок 6. компьютеры , входящие в сеть. Список использованной литературы. 1. Журнал «СУБД» №1 1995, Кузнецов С.Д. « Ошибка! Недопустимый объект гиперссылки. ». Журнал «СУБД» №2 1995, Кузнецов С.Д. « Ошибка! Недопуст имый объект гиперссылки. » Журнал «СУБД» №3 1995, Кузнецов С.Д. « Ошибка! Недопустимый объект гиперссылки. 3» Журнал «СУБД» №4 1995, Кузнецов С.Д. « Ошибка! Недопустимый объект гиперссылки. 4» Журнал «СУБД» №1 1996, Кузнецов С.Д. « Ошибка! Недопустимый объект гиперссылки. 5» Журнал «СУБД» №2 1996, Кузнецов С.Д. « Ошибка! Недопустимый объект гиперссылки. 6» Журнал «СУБД» №3 1996, Кузнецов С.Д. « Ошибка! Недопустимый объект гиперссылки. 7»
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

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

Обратите внимание, реферат по бухгалтерскому учету и аудиту "CК Раскрыть особенности внешнего (финансового) анализа", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

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


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