Информационное обеспечение систем управления
Скачать 3.02 Mb.
|
Первая нормальная форма отношения (1НФ). Отношение в первой нормальной форме должна удовлетворять следующим требованиям.
Для удовлетворения первого условия отношение должно иметь хотя бы один первичный ключ (такое поле, в котором все значения уникальны). Исходные таблицы ЗАКАЗ_1 и ЗАКАЗ_2 имеют естественный простой первичный ключ – Номер_заказа. После появления первых СУБД число полей в записи было ограниченным, поэтому разработчики старались в одно поле занести несколько “порций” данных. Например, в поле “лицевой счёт квартиросъёмщика” включали код треста, код ЖЭУ, номер дома и номер квартиры, например: 06.35.196.077. Чтобы выбирать нужные данные из такого поля необходим его сложный анализ с выделением подстрок. Язык СУБД с помощью функций анализа строк в принципе позволяет реализовать такой анализ. Но это будет сильно тормозит выполнение запросов, да и писать такие запросы не просто. Поэтому приведённый лицевой счет квартиросъемщика следовало бы разбить на четыре атомарных поля. В предложенных таблицах также присутствуют не атомарные поля: в ЗАКАЗ_1 – это Состав_заказа, а в ЗАКАЗ_2 Товар_1 Товар_3. Второе требование постулирует отсутствие повторяющихся групп полей. Поскольку покупатель может заказать несколько товаров, то такую группу в ЗАКАЗ_2 разработчик ввел. Она состоит из трех полей Товар_1 Товар_3. Он жёстко ограничил число товаров, заказываемых за один раз. При такой структуре таблицы всё было бы в порядке до тех пор, пока агент не заказал бы больше трех видов товара за раз. Кроме того, при такой структуре сложно определить, какое количество каждого из товаров было продано. Пришлось бы проверять столбцы каждого из товаров и затем суммировать результаты. Также непросто создать отчёт со списком покупателей, которые покупали определённый товар. Почти все отчёты требовали бы сложного программирования, больших затрат времени и служили бы потенциальным источником ошибок. А как формировать SQL запросы? Если при таком подходе увеличивать число полей, скажем, до 20, а в среднем покупатели покупают по 2 – 3 товара, то 90 % таблицы будет “пустым”. Это не рационально. Есть примеры СУБД, которые позволяют число полей делать переменным, это дополнительные трудности при программировании. В dBASE подобных СУБД такого механизма никогда не было. Первая нормальная форма требует заменять повторяющиеся поля одним полем, создавая при этом несколько записей по одной на каждый товар. Для выполнения второго и третьего требований 1НФ разобьем наши таблицы на два новых отношения. В первом будем хранить данные о заказанных товарах; во втором – данные о заказчиках этих товаров. Подобное разбиение должно быть обратимым, т.е. новые таблицы должны быть взаимосвязаны. Такая связь должна обеспечивать выборку для каждого заказчика его заказанные товары в данном заказе. Для связи таблиц выберем поле Код_агента. Кроме того, на основании четвертого требования 1НФ и удобства дальнейших рассуждений перегруппируем столбцы в новых таблицах.
В таблице ЗАКАЗЧИКИ не будет повторяющихся записей (есть первичный ключ Код_агента), в таблице ЗАКАЗАННЫЕ_ТОВАРЫ нет повторяющихся групп полей, в обеих таблицах поля атомарны. Следовательно, схема базы данных находится в 1НФ. В ЗАКАЗАННЫЕ_ТОВАРЫ поле Номер_заказа не является уже простым первичным ключом, который однозначно идентифицирует каждую запись. Но здесь есть составной ключ, в который входят поля Код_агента + Код_товара + Дата_заказа. На бланке заказа обычно номер заказа не заполняется, поэтому в дальнейшем не будем использовать данное поле. Обсудим аномалии обновления отношений ЗАКАЗАННЫЕ_ТОВАРЫ и ЗАКАЗЧИКИ. Аномалия вставки ситуация, когда вы не можете добавить данные в таблицу из-за наличия искусственной зависимости между полями этой таблицы. Предположим, необходимо добавить новый товар (поля Код_товара, Имя_товара и Цена). Структура отношения ЗАКАЗАННЫЕ_ТОВАРЫ не позволит сделать этого до тех пор, пока вы не добавите заказ этого товара. То же ограничение существует и для полей Фирма и Директор отношения ЗАКАЗЧИКИ. Нельзя добавить новую фирму пока не появится представитель этой фирмы. Но было бы гораздо лучше, если бы новые товары создавались до появления новых заказов этих товаров. Аномалия удаления — случай, противоположный аномалии вставки. Это ситуация, когда удаление одних данных приводит к непреднамеренной потере других. Например, если заказ с номером 100 в таблице ЗАКАЗАННЫЕ_ТОВАРЫ единственный для определенного товара, и он будет удален, то сам факт того, что когда-то у нас был этот товар, будет потерян. То же самое произойдет, если вы удалите последнего агента (потеряем данные о фирме). Аномалия обновления ситуация, когда обновление одного значения требует обновления нескольких записей. При изменении, например, цены товара в отношении ЗАКАЗАННЫЕ_ТОВАРЫ нужно будет корректировать все записи, в которых есть этот товар. Дополнительный риск, связанный с этой аномалией, заключается в том, что сохранение избыточных данных позволяет обновить один элемент, а не все, и это приведет к несоответствию данных в таблице. Вторая нормальная форма отношения (2НФ). Отношение имеет эту форму, если выполняются следующие условия.
Другими словами, 2НФ требует наличия функциональной зависимости каждого не ключевого поля от полного набора полей сложного первичного ключа. В данном случае функциональная зависимость понимается как однозначное отображение (не обязательна взаимно однозначность), т.е. в отношениях между значениями полей допустимы, например, структуры рис. 4.1 a), b), c), но не допустима структура d). Из определения следует, что понятие 2НФ применимо только к отношениям, имеющим составной первичный ключ. Р  ис. 4.1. Иллюстрация функциональной зависимости. В примере таблица ЗАКАЗАННЫЕ_ТОВАРЫ не находится в 2НФ, т.к. поле Имя_товара однозначно определяется только одним полем составного ключа, а именно: Код_товара. Для приведения этой таблицы к 2НФ выделим из него отношение, которое будет содержать только данные о товарах. Получим две новые таблицы ЗАКАЗ и ТОВАРЫ, которые свяжем по полю Код_товара.
Все отношения, имеющие простой первичный ключ, автоматически удовлетворяют второму условию 2НФ. Поэтому таблица ЗАКАЗЧИКИ находится в 2НФ. Следовательно, таблицы ЗАКАЗЧИКИ, ЗАКАЗ и ТОВАРЫ представляют логическую структуру базы данных во 2НФ. Третья нормальная форма отношения (3НФ). Отношение находится в этой форме, если удовлетворяются следующие условия.
Сведение отношения к 3НФ предполагает расчленение его на несколько более простых взаимосвязанных отношений с выделением в отдельные таблицы зависимых полей. В таблице ЗАКАЗЧИКИ поля Директор и Адрес однозначно определяется полем Фирма. Для приведения этой таблицы к 3НФ разобьём ее на два отношения так, а для их связи введем новое поле Код_фирмы. Мы могли бы реализовать связь по полю Фирма. Но если оно имеет большую длину (например, С30), то для экономии дисковой памяти есть смысл ввести дополнительное поле Код_фирмы с типом С3, что и было сделано.
В таблице ЗАКАЗ поле Сумма является производным, его можно вычислить как произведение полей Кол-во и Цена. После удаление этого поля, окончательная схема базы данных в 3НФ будет иметь следующий вид.
В схеме первичные ключи выделены жирным шрифтом и подчеркиванием, а внешние ключи – подчеркиванием. Существует ряд дополнительных нормальных форм, которые, по крайней мере, по мнению теоретиков, должны входить в состав модели нормализации. К данным нормальным формам относятся следующие. Нормальная форма Бойса-Кодда. Она рассматривается лишь как вариант третьей нормальной формы и предназначена для анализа ситуаций с множеством перекрывающихся ключей-кандидатов, а именно: существует более одного ключа-кандидата; все ключи-кандидаты являются сложными ключами (то есть состоят из нескольких столбцов); каждый ключ-кандидат имеет в своем составе, по крайней мере, один столбец, входящий в состав другого ключа-кандидата. Чаще всего речь идет о ситуациях, когда в принципе применимы любые решения, но при этом использование данной нормальной формы не находит логического обоснования за пределами академического сообщества. Четвертая нормальная форма. Она предназначена для анализа многозначных зависимостей, в которых один столбец составного первичного ключа зависит от другого столбца этого первичного ключа. Такие ситуации достаточно редки, и обычно не вызывают реальных проблем. Пятая нормальная форма. Она применяется при анализе декомпозиций отношений с потерями и без потерь. По существу, бывают ситуации, в которых вы можете разбить одно отношение на несколько различных отношений, однако вам не удастся в дальнейшем логически вернуть его к первоначальному виду. Данные ситуации достаточно редки и представляют интерес только в научном плане. Шестая нормальная форма (нормальная форма доменного ключа). Она достигается только, если в таблице гарантируется отсутствие аномалий модификации (modification anomalies), то есть при изменении данных в одном месте происходит корректное изменение данных во всех остальных местах без риска возникновения несогласованностей с другими данными системы. Условия данной нормальной формы практически не достижимы в реальном мире. Технология “Универсального отношения”, как правило, даёт такую логическую структуру БД, при которой каждое отношение содержит данные или о “сущности” или о “связи”. Так отношения ЗАКАЗЧИКИ, ФИРМА и ТОВАРЫ – это “сущности”, а отношение | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие:
 | «Учебно-методический комплекс дисциплины «Информационное обеспечение систем управления» | | Пояснительная записка «Современная организация и технология документационного обеспечения управления». Он связан с курсами «Документоведение», «Информационное... |
| Исследование систем управления процесс определения организационной... Место исследований систем управления в комплексе дисциплин по теории и практке управления |  | Программное обеспечение для отладки систем управления упругими объектами Целью данной работы является разработка программного обеспечения для лабораторного стенда для изучения систем управления упругими... |
| Рабочая программа дисциплины «Информационное обеспечение, базы данных» Факультет информационных систем и технологий Кафедра Прикладной математики и вычислительной техники | | Учебная программа по дисциплине " информационное обеспечение управления " Изучение теоретических, методических и практических вопросов разработки, внедрения и совершенствования информационного обеспечения... |
| Российской Федерации Самарский государственный архитектурно-строительный... Информационные системы” являются информационные системы и сети, их математическое, информационное и программное обеспечение, способы... | | Рабочая программа дисциплины «Архитектура ЭВМ и вычислительных систем»... «Автоматизированные системы обработки информации и управления» (по отраслям) и 230105 «Программное обеспечение вычислительной техники... |
| Исследование систем управления Целью работы является рассмотрение частных методов исследования систем управления, а именно эксперимент, наблюдение и опрос | | Примерная тематика рефератов по курсу «Исследование систем управления» Современный менеджмент и необходимость исследования систем управления социально-экономической организацией |
| Организационно-правовое обеспечение правовой деятельности Информационное обеспечение организации и проведения внеучебной работы | | Исследование систем управления Специальности: «Менеджмент организации» «Исследование систем управления» является ведущей,в учебном процессе среди смежных дисциплин |
| Реферат по дисциплине "Избирательное право" тема: Информационное... Информационное обеспечение выборов. Правовое регулирование предвыборной агитации в РФ | | Информационное обеспечение управления В настоящее время классификационные схемы (классификаторы) строятся не только на основе соподчинения понятий (метод иерархии), но... |
| Курсовая работа По дисциплине «Базы данных» Программное обеспечение для создания систем управления базами данных | | Рабочая программа учебной дисциплины «исследование систем управления» Студенты научатся методам планирования эксперимента и организации исследования систем управления и научатся использовать приобретенные... |
