Реферат: Разработка СУБД Оперативный учет производственной деятельности промышленного предприятия

--PAGE_BREAK--<img width=«42» height=«90» src=«dopb262336.zip» alt=«Подпись: Находится в» v:shapes="_x0000_s1131" v:dpi=«96»><img width=«558» height=«324» src=«dopb262337.zip» v:shapes="_x0000_s1078 _x0000_s1079 _x0000_s1080 _x0000_s1081 _x0000_s1082 _x0000_s1083 _x0000_s1084 _x0000_s1085 _x0000_s1086 _x0000_s1087 _x0000_s1088 _x0000_s1089 _x0000_s1090 _x0000_s1091 _x0000_s1092 _x0000_s1093 _x0000_s1094 _x0000_s1095 _x0000_s1096 _x0000_s1097 _x0000_s1098 _x0000_s1099 _x0000_s1100 _x0000_s1101 _x0000_s1102 _x0000_s1103 _x0000_s1104 _x0000_s1105 _x0000_s1106 _x0000_s1107 _x0000_s1108 _x0000_s1109 _x0000_s1110 _x0000_s1111 _x0000_s1112 _x0000_s1113 _x0000_s1114 _x0000_s1115 _x0000_s1116 _x0000_s1117 _x0000_s1118 _x0000_s1119 _x0000_s1120 _x0000_s1121 _x0000_s1122 _x0000_s1123 _x0000_s1124 _x0000_s1125 _x0000_s1126 _x0000_s1127 _x0000_s1128 _x0000_s1129 _x0000_s1130 _x0000_s1132 _x0000_s1133 _x0000_s1134 _x0000_s1135 _x0000_s1136 _x0000_s1137 _x0000_s1138 _x0000_s1139 _x0000_s1140 _x0000_s1141 _x0000_s1142"> 
Рисунок 4.2 — Сетевая модель данных
Анализируя схему, видим, что все элементы связаны друг с другом. Любой элемент может быть выражен через другие элементы. С одной стороны это хорошо, но с другой плохо: на формирование типов связи не накладываются особые ограничения, что приводит при выполнении основных операций над данными к негативным для проектируемой БД ситуациям. Например, в дополнительной таблице появятся записи, которые не имеют родительских записей в основной таблице.
Поэтому недостатком СМД является высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в СМД ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями. Таким образом, для разработанной в пункте 3 схемы объект-отношение данную модель данных применять нежелательно.
Достоинством СМД является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с ИМД сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей.
4.3 Реляционная модель данных Реляционная модель данных некоторой предметной области представляет собой набор отношений (двумерных таблиц), изменяющихся во времени.
В общем случае можно считать, что реляционная БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД Microsoft Access в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули.
Достоинство РМД заключается в простоте, понятности и удобстве физической реализации на ЭВМ. С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного объекта, информация о котором храниться в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Переход от схемы объект – отношение к реляционной модели данных осуществляется следующим образом: все объекты схемы объект – отношение это определенные таблицы название полей которых являются свойствами объектов, если отношение имеет свойства то оно также является таблицей в полученной реляционной модели данных
Для проектируемой базы данных реляционная модель представлена на рисунке 4.3.
<shape id="_x0000_i1026" type="#_x0000_t75" o:allowoverlap=«f»><imagedata src=«62200.files/image007.png» o: croptop=«7782f» cropbottom=«5339f» cropleft=«2510f» cropright=«3691f» grayscale=«t»><img width=«434» height=«249» src=«dopb262338.zip» v:shapes="_x0000_i1026">
Рисунок 4.3 — Реляционная модель данных
Таким образом, после рассмотрения приведенных выше моделей данных для разработанной в пункте 3 схемы объект-отношение была выбрана РМД, которая проста и понятна для пользователя и отвечает требованиям изучаемого курса.

5 ОБОСНОВАНИЕ ВЫБОРА СУБД Основы современной информационной технологии составляют базы данных (БД – это структурированная определенным образом совокупность данных, относящихся к конкретной задаче ) и системы управления базами данных (СУБД представляет собой комплекс инструментальных средств, программных и языковых, реализующих централизованное управление БД и обеспечивающих доступ к данным (изменения, добавления, удаления, резервного копирования и т.д. ), роль которых как единого средства хранения, обработки и доступа к большим объемам информации постоянно возрастает. Быстрое развитие потребностей применений БД выдвигает новые требования к СУБД: естественные и эффективные представления в БД разнообразных отношений между объектами предметных областей (например, пространственно-временных с обеспечением визуализации данных); СУБД должна обеспечивать поиск, модификацию и сохранность данных, а также оперативный доступ (время отклика), защиту целостности данных от аппаратных сбоев и программных ошибок, разграничение прав и защита от несанкционированного доступа, поддержка совместной работы нескольких пользователей с данными.
Этим требованиям отвечают многие современные СУБД, в том числе и Access. МА включает в себя традиционные технологии и возможности реляционных СУБД, предоставляет средства создания базы нормализованных данных и форм для диалоговой работы с ней и удобным графическим интерфейсом. С построением базы нормализованных данных тесно связана разработка и эффективная реализация задач пользователя. Для рения многих задач достаточно использовать такие объекты Access, как формы, запросы, отчеты. Эти объекты легко создаются в диалоговом режиме. Для реализации целостного приложения пользователя в некоторой предметной области возникает необходимость в создании макросов и модуле на языке Visual Basic for Applications (VBA). Механизм обработки событий, возникающих в процессе диалоговой работы с данными, позволяет объединять в приложении пользователя отдельные запросы, формы и отчеты и получать нестандартные рения в практических приложениях пользователя.
Программа Microsoft Access 2000 является реляционной СУБД, которая может функционировать под управлением операционных систем Windows 95/98/Me, Windows NT, Windows XP, и позволяет реализовать поставленную цель. Обеспечивает удобство работы пользователя: имеется возможность создания пользовательских интерфейсов при использовании Visual Basic для приложений, автоматизация разработки различных объектов. Для построения и выполнения запросной функции в Access 2000 очень удобным и доступным является язык запросов по образцу QBE, поддерживаемый мощным интерфейсом пользователя, а также встроенный язык запросов SQL, который является удобным языком управления базами данных.
Программа Microsoft Access 2000 имеет небольшой объем вспомогательного программного обеспечения, вследствие чего предъявляет меньше требований к памяти, чем программы Microsoft Access поздних версий. Кроме того, для проектирования требуемой БД нет необходимости в использовании возможностей более поздних программ Office или других фирм производителей. Вполне достаточно средств, предоставляемых пользователю Microsoft Access 2000.

6 ОПИСАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ РЕЛЯЦИОННОЙ
БАЗЫ ДАННЫХ
6.1 Схема Данных
Схема данных, отражает логическое представление реляционной модели данных для проектируемой БД.
Построить иную концептуальную модель для данной БД таким образом, чтобы она отвечала специфике предметной области и в информационном плане сохраняла все возможности приведенной выше модели без добавления новых объектов, практически невозможно.
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пуст.
Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее не ключевых полей не зависит функционально от любого другого не ключевого поля.

Рисунок 6.2 – Таблица данных в 1НФ
Назв. предприятия
С 80
Дата открытия предприятия D10
Назв. Города
C20
Назв. Типа предпр C30
Назв. Цеха C15
Кол-во рабочих N4
Дата ввода в строй D8
Дата посл реконструкции D8
Месяц С8
Кол-во изделий N6
Цена N5
Назв. Изделия C20
Представим функциональные зависимости для таблицы в 1НФ:
<img width=«170» height=«242» src=«dopb262339.zip» v:shapes="_x0000_s1159">    <img width=«113» height=«54» src=«dopb262340.zip» v:shapes="_x0000_s1145 _x0000_s1160 _x0000_s1164">       <img width=«30» height=«22» src=«dopb262341.zip» v:shapes="_x0000_s1162 _x0000_s1166"> <img width=«113» height=«54» src=«dopb262342.zip» v:shapes="_x0000_s1146 _x0000_s1161 _x0000_s1165">   <img width=«31» height=«12» src=«dopb262343.zip» v:shapes="_x0000_s1163 _x0000_s1167">         <img width=«146» height=«254» src=«dopb262344.zip» v:shapes="_x0000_s1154">
<img width=«134» height=«122» src=«dopb262345.zip» v:shapes="_x0000_s1149">

 Рисунок 6.3 – Функциональные зависимости для 1НФ

Предприятие
Название предприятия
Дата открытия
Тип
Город
<img width=«12» height=«39» src=«dopb262346.zip» v:shapes="_x0000_s1144">
Цех
Название цеха
С15
Количество рабочих
N4
Дата ввода в строй
D8
Дата последней реконструкции D8
Месяц выпуска изделия
Количество изделий
Цена изделия
Название изделия
Рисунок 6.4 – Таблицы данных во 2НФ
После представления таблиц во 2НФ, представим шапки таблиц в 3НФ:
Месяц
Кол-во изделий
Цена изделия
Код цеха#
Код изделия#
Выпуск                                                     Тип
#Код типа
Название типа
Предприятие
#Код предпр
Название предприятия
Дата открытия
КГ#
КТ#
 
Изделие
#Код изделия
Название изделия
Цех
#Код
цеха
Название цеха
Кол-во рабочих
Дата ввода в строй
Дата последней реконструкции
Код предприятия#

 Город
#Код города
Название города
Рисунок 6.5 – Таблицы данных в 3НФ
6.2 Описание и обоснование полей таблиц
В проектируемой базе данных реализовано шесть таблиц. Ниже для каждой таблицы приведены описание, обоснование полей, ограничения на входную информацию, необходимые маски ввода, используемые подстановки. Все примеры заполненных таблиц приведены в приложении В.
Таблица «Предприятие» (таблица 6.2.1):
1.      Код предприятия
-Ключ: первичный ключ;
-Счетчик;
-Длинное целое;
-Размер: 3;
-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.
2. Название предприятия
— Текстовое;
— Размер 80;
— Обязательное поле, так как название предприятия – это главная особенность, по которой можно различать предприятия;
— Пустых строк нет, так как не может быть предприятие без названия;
— Совпадения не допускаются, так как у двух разных предприятий не должно быть одинаковых названий;
3. Дата открытия предприятия
— Тип дата;
— Размер 10;
— Обязательное поле, так как у каждого предприятия есть дата открытия;
-Совпадения допускаются, так как разные предприятия могут быть открыты в один и тот же день;
-Маска: 00.00.0000;
-Значение по умолчанию =Date();
-Условие на значения <=Date(), так как предприятие не может открыться позже, чем в день рассмотрения его деятельности.
4. Город
-Тип длинное целое;
-Размер 2;
-Обязательное поле, так как каждое предприятие находится в каком-либо городе;
-Совпадения допускаются, так как разные предприятия могут находиться в одном городе;
-Подстановка: из таблицы «Город», поле «Название города»;
-Внешний ключ.
5. Тип
-Тип длинное целое;
-Размер 2;
-Обязательное поле, так как у каждого предприятия есть свой тип;
-Совпадения допускаются, так как разные предприятия могут иметь один и тот же тип;
-Подстановка: из таблицы «Тип», поле «Название типа»;
-Внешний ключ.

Таблица 6.2.1 «Предприятие»
Предприятие
#Код предприятия
Название предприятия
Дата открытия
Город
Тип
1
Шахтуглесервис
25.06.1956
Шахтерск
Частное
2
Азовмаш
24.05.1985
Мариуполь
ООО
3
Азовсталь
13.02.1991
Краматорск
Государственное
4
ДМЗ
12.03.1985
Донецк
ОАО
Таблица «Город» (таблица 6.2.2):
1.     Код города
-Ключ: первичный ключ;
-Счетчик;
-Длинное целое;
-Размер: 3;
 -Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.
2.     Название города
— Текстовое;
— Размер 20;
— Обязательное поле, так как город не может быть без названия;
— Пустых строк нет, так как город не может иметь пустое название;
— Совпадения не допускаются, так как разные города не могут иметь одно и то же название.
Таблица 6.2.2 «Город»
Город
#Код города
Название города
1
Донецк
2
Шахтерск
3
Мариуполь
4
Краматорск

Таблица «Тип» (таблица 6.2.3):
1. Код типа
-Ключ: первичный ключ;
-Счетчик;
-Длинное целое;
-Размер: 3;
-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.
2. Название типа
— Текстовое;
— Размер 30;
— Обязательное поле, так как тип не может быть без названия;
— Пустых строк нет, так как тип не может иметь пустое название;
— Совпадения не допускаются, так как разные типы не могут иметь одно и то же название.
Таблица 6.2.3 «Тип»
Тип
#Код типа
Название типа
1
Государственное
2
Частное
3
ООО
4
ОАО
Таблица «Изделие» (таблица 6.2.4):
1. Код города
-Ключ: первичный ключ;
-Счетчик;
-Длинное целое;
-Размер: 3;
-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.
2. Название изделия
— Текстовое;
— Размер 20;
— Обязательное поле, так как изделия не может быть без названия;
— Пустых строк нет, так как тип не может иметь пустое название;
— Совпадения не допускаются, так как разные изделия не могут иметь одно и то же название.
Таблица 6.2.4 «Изделие»
Изделие
#Код изделия
Название изделия
1
Шайбы
2
Чайники
3
Болты
4
Бочки
5
Двигатели
6
Сковородки
7
Столы
8
Кровати
9
Компьютеры
    продолжение
--PAGE_BREAK--
еще рефераты
Еще работы по информатике