47184 (571950), страница 2
Текст из файла (страница 2)
Если А ->В и ВС ->D, то АС -* D.
Доказательство
Из А -> В следует АС -> ВС (теорема 5). ВС -> D (условие), поэтому АС—> D по теореме 3.
Вторая и третья нормальные формы отношений
Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных функциональных зависимостей.
Неполная функциональная зависимость - это две зависимости:
-
вероятный ключ отношения функционально определяет некоторый неключевой атрибут,
-
часть вероятного ключа функционально определяет этот же неключевой атрибут.
Отношение, не соответствующее 2НФ, характеризуется избыточностью хранимых данных.
Например:
Т4 | |||
Магазин | Изделие | Цена | План_1999_г. |
Салют | М22 | 50 | 200 |
Салют | К14 | 40 | 100 |
АТЭ | М22 | 50 | 300 |
АТЭ | Т62 | 60 | 100 |
Функциональные зависимости отношения Т4:
Избыточность иллюстрируется тем фактом, что цена изделия указывается столько раз, сколько магазинов продают это изделие (изделие М22 в Т4). Переход к 2НФ и соответственно устранение отмеченной избыточности данных связано с созданием двух отношений вместо исходного отношения Т4.
Т41 | ||
Магазин | Изделие | План_1999_г. |
Салют Салют АТЭ АТЭ | М22 К14 М22 Т62 | 200 100 300 100 |
Т42 | |
Изделие | Цена |
М22 К14 Т62 | 50 40 60 |
Отношение соответствует ЗНФ, если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные функциональные зависимости (ФЗ).
Алгоритм получения отношений в ЗНФ обладает следующими свойствами:
-
сохраняет все первоначальные функциональные зависимости, т.е. зависимость, справедливая в R, справедлива и в одном из производных отношений. Это гарантирует получение осмысленных отношений с легко интерпретируемой структурой;
-
обеспечивает соединение без потерь, т.е. значения исходного отношения R могут быть восстановлены из проекций отношения R с помощью операции соединения;
-
результат декомпозиции в ЗНФ обычно содержит меньше значений атрибутов, чем исходное отношение R (происходит уменьшение избыточности).
-
Разработать информационную систему для учета затрат на производство продукции
Данная задача необходима для планово-экономического отдела предприятия. Ее цель показать затраты на производство с учетом материальных и трудовых ресурсов. Результаты задачи показывают насколько выгодно для предприятия выполнение данного заказа изготовления продукции. Данные о необходимой информации поступают из следующих отделов участвующих в процессе обработки информации:
-
финансовый;
-
отдела материалов;
-
комплектующий отдел;
-
расчетный отдел;
-
др.
Необходимость или периодичность выполнения данной задачи зависит от количества выполняемых заказов. Другими словами, она необходима при выполнении любого заказа, выполняемого на предприятии.
Приведенные входные данные имеют укрупненный вид.
Входные таблицы:
-
Сводная таблица учетов заказов.(Costs)
Наименование поля | Идентификация | Тип данных |
Код записи (ключевое) | ID | Счетчик |
Код заказа | KodZak | Текстовое |
Дата | Data | Дата/Время |
Затраты на материалы | Materials | Денежный |
Затраты на всп. материалы | SumMaterials | Денежный |
Накладные расходы | Overheads | Денежный |
Полуфабрикаты/комплектующие | SemiProducts | Денежный |
-
Таблица учета работы над заказом специалистов (MainManufacture)
Наименование поля | Идентификация | Тип данных |
Код записи (ключевое) | ID | Счетчик |
Код заказа | ID_costs | Числовое-целое |
Код рабочего | WorkerID | Числовое-целое |
Заработная плата | Zarpl | Денежный |
-
Таблица учета работы над заказом групп работников (SubManufacture)
Наименование поля | Идентификация | Тип данных |
Код записи (ключевое) | ID | Счетчик |
Код заказа | ID_Costs | Числовое-целое |
Количество работников | Kolvo | Числовое-целое |
Средняя заработная плата | AvrZarpl | Денежный |
-
Таблица работников-специалистов (WorkersList)
Наименование поля | Идентификация | Тип данных |
Код записи (ключевое) | ID | Счетчик |
Табельный номер | TabNo | Числовое-целое |
Фамилия, И.О. | FIO | Текстовое |
Построим схему данных.
MainManufacture |
ID |
ID_costs |
WorkerID |
Zarpl |
C
| ||||||||||
I | ||||||||||
K | ||||||||||
Data | ||||||||||
Materials | ||||||||||
SumMaterials | ||||||||||
O
| ||||||||||
SemiProducts |
Как видно из таблиц, все они имеют ключевые поля (ID) которые указывают на уникальность записи в любой из таблиц. Так, в таблицах 2 и 3 существуют поля ID_Costs, которые указывают на определенный заказ. Данное условие было необходимо, поскольку уникальным ключом таблицы COSTS является номер заказа и дата его запуска. Данные поля вместе представляют довольно большое поле-ключ, что будет создавать в других таблицах избыточность информации. Следовательно, довольно таки удобнее ввести одно уникальное поле, которое и будет служить ключом для связки таблиц. Тоже самое касается и Таблицы WorkersList. Как правило, уникальным может быть и табельный номер работника, но есть случаи, когда он не уникален: например, табельные номера каждый раз начинаются с начала в новом отделе, либо это поле имеет буквенно-цифровой вид, что приводит к увеличению обработки информации, поскольку компьютерная техника работает быстрей с цифрами, чем с символами.
Представим данные таблиц на примере.
Costs.
ID | KodZak | Data | Materials | SubMaterials | overheads | SemiProducts |
1 | 11-1 | 01.01.2003 | 10 000,00 грн. | 8 000,00 грн. | 2 000,00 грн. | 3 000,00 грн. |
2 | 22-2 | 01.10.2003 | 12 000,00 грн. | 7 500,00 грн. | 2 200,00 грн. | 3 500,00 грн. |
3 | 33-3 | 01.11.2003 | 12 250,00 грн. | 8 800,00 грн. | 2 300,00 грн. | 3 300,00 грн. |
MainManufacture
ID | ID_Costs | WorkerID | Zarpl |
1 | 1 | 1 | 300,00 грн. |
2 | 1 | 2 | 310,00 грн. |
3 | 2 | 3 | 325,00 грн. |
4 | 2 | 2 | 315,00 грн. |
5 | 3 | 1 | 300,00 грн. |
6 | 3 | 3 | 320,00 грн. |
SubManufacture
ID | ID_Costs | Kolvo | AvrZarpl |
1 | 1 | 5 | 200,00 грн. |
2 | 2 | 7 | 250,00 грн. |
3 | 3 | 10 | 180,00 грн. |
4 | 1 | 6 | 175,00 грн. |
WorkersList
ID | TabNo | FIO |
1 | 123 | Иванов И.И. |
2 | 124 | Петров П.П. |
3 | 125 | Сидоров С.С. |
В ходе работы были созданы запросы, которые, основываясь на данные таблиц рассчитывают промежуточные данные для сводного отчета.