VIII Международная студенческая научная конференция Студенческий научный форум - 2016
КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
КомментарииПолная версия работы доступна во вкладке "Файлы работы" в формате PDF
1. РАЗРАБОТКА ИНФОРМАЦИОННОЙ МОДЕЛИ СИСТЕМЫ
1.1 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ СИСТЕМЫ
Проектирование базы данных для любой автоматизированной системы разделяется на следующие этапы:
- определение требований к базе данных;
- концептуальное проектирование базы данных;
- выбор средств реализации базы данных;
- логическое проектирование;
- физическое проектирование.
В качестве CASE-средства проектирования базы данных был выбран пакет Visual Paradigm 7.2, используемый и для проектирования всей системы в целом. Пакет Visual Paradigm 7.2 позволяет полностью описать всю логическую структуру базы данных [1,6].
1.2 ПОСТРОЕНИЕ ER-МОДЕЛИ БАЗЫ ДАННЫХ
ER-модель - модель данных, позволяющая описывать концептуальные схемы на основе диаграмм сущность-связь (ER-диаграмм)
Модель базы данных описывают с помощью одной или нескольких ER-диаграмм, содержащих сущности, атрибуты и связи.
Сущность определяется как объект, событие или концепция, информация о котором должна сохраниться. Сущности имеют наименование, несущее четкое смысловое значение. Каждый экземпляр сущности на диаграмме уникален.
Атрибут хранит информацию об определенном свойстве сущности и имеет четкое смысловое значение. Атрибут или группа атрибутов, которые однозначно идентифицируют экземпляры сущности, называются первичным ключом (англ. primary key).
Связь описывает логическое соотношение между сущностями. Связь сущности с другими сущностями определяет ее тип: различают два типа сущностей - зависимые и независимые.
Можно установить следующие связи между сущностями: идентифицирующая связь один ко многим, связь многие ко многим, неидентифицирующая связь один ко многим и связь один к одному.
Связь многие ко многим существует только на логическом уровне. При переходе на физический уровень это отношение должно быть преобразовано за счет добавления новой зависимой сущности, связанной идентифицирующими связями один ко многим с сущностями, находящимися в исходном отношении.
Сущности, имеющие связь один к одному, можно объединить в одну. При физической реализации базы данных две таблицы могут использоваться вместо одной по соображениям конфиденциальности, для удобства, для экономии дискового пространства, из семантических соображений.
Идентифицирующая связь устанавливается между независимой и зависимой сущностями, при этом зависимая сущность не может существовать самостоятельно - экземпляр зависимой (дочерней) сущности определяется только через отношение к сущности, которая его идентифицирует (родительской сущности). При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав ключевых атрибутов дочерней сущности. В дочерней сущности новые атрибуты помечаются как внешний ключ (англ. foreign key).
В случае не идентифицирующей связи внешний ключ не входит в состав первичного ключа дочерней сущности.
Проектируемая система работает с одной базой данных, хранящей информацию об оборудовании, специалистах и заказах, создаваемых пользователем.
В результате построения логической схемы базы данных проектируемой системы были выделены следующие сущности:
1) Оборудование - содержит информацию о оборудовании: инвентарный номер, который присваивается оборудованию при постановке на учёт, серийный номер (уникальный номер оборудования), гарантийный срок (время функционирования оборудования), дата приёма, производитель, дата введения в эксплуатацию;
2) Модель оборудования - содержит информацию о модели оборудования: код модели, название модели оборудования;
3) Специалист - содержит информацию о специалисте: табельный номер, фамилию, имя и отчество специалиста, логин, пароль, должность, которую он занимает на предприятии, задача (работа, которую выполняет специалист в определённый период времени);
4) Отдел - содержит информацию о отделе: код отдела, название отдела;
5) Заказ - наряд - содержит информацию о заказ-наряде: код заказ-наряда, дата начала обслуживания, время на обслуживание, причины поломки, признак, номер заказ-наряда, дата заказ-наряда ;
6) График - содержит информацию о графике: код графика, год;
7) Вид ремонта - содержит информацию о виде ремонта: код вида ремонта, название вида ремонта;
Перечень видов работ - содержит список видов работ.
Проектируемая система имеет следующие основные связи между сущностями:
1) отношение «Модель оборудования - Оборудование» имеет идентифицирующую связь один ко многим;
2) отношение «Отдел - Оборудование» имеет идентифицирующую связь один ко многим;
3) отношение «Оборудование - График» имеет идентифицирующую связь один ко многим;
4) отношение «Оборудование - Заказ-наряд» имеет идентифицирующую связь один ко многим;
5) отношение «Заказ-наряд - Перечень видов работ» имеет идентифицирующую связь один ко многим;
6) отношение «Вид ремонтов - График» имеет идентифицирующую связь один ко многим;
7) отношение «Отдел - Специалист» имеет идентифицирующую связь один ко многим;
8) отношение «Специалист - Заказ-наряд» имеет идентифицирующую связь один ко многим.
ER-диаграмма базы данных проектируемой системы изображена на рисунке 1.
Теперь нужно проверить, находится ли полученная схема отношений в третьей нормальной форме (3НФ). Если схема отношений не находится в 3НФ, то ее нужно нормализовать для минимизации избыточности данных и устранения потенциальной противоречивости данных.Отношение находится в первой нормальной форме (1НФ), если значения всех атрибутов атомарные, то есть значение атрибута не должно быть множеством или повторяющейся группой. Из схемы отношений видно, что она находится в 1НФ.
Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и нет частичной функциональной зависимости неключевых атрибутов от ключа (зависимость не ключевых атрибутов от части ключа). Из схемы отношений видно, что ни один из неключевых атрибутов функционально полно не зависит от ключа, следовательно схема отношений находится в 2НФ.
Отношение находится в 3НФ, если оно находится в 2НФ, и отсутствуют транзитивные зависимости не ключевых атрибутов от ключа. Между атрибутами A и C есть транзитивная зависимость, если выполняется совокупность условий:
Если хотя бы одно из условий не выполняется, то транзитивной зависимости между атрибутами A, B, C нет. Причем атрибуты A, B, C могут быть составными.
Анализируя атрибуты, можно сделать вывод, что транзитивная зависимость отсутствует, т.е. отношение находится в 3НФ. Следовательно, представленные схемы отношений являются окончательными схемами отношений.
1.3 ВЫБОР ПРОГРАММНЫХ СРЕДСТВ РЕАЛИЗАЦИИ СИСТЕМЫ
Выбор программных средств играет большое значение для проектируемой системы, поскольку определенные на этом этапе программные продукты, средства разработки и технологии непосредственным образом окажут влияние на распространяемость разработанной системы: чем более распространенными будут используемые при разработке и требуемые для функционирования системы технологии, тем шире круг потенциальных потребителей системы, имеющих возможность ей воспользоваться. Кроме того, выбор среды разработки непосредственно влияет на стоимость и простоту процесса разработки системы [2,6].
1.3.1 ВЫБОР ОПЕРАЦИОННОЙ СИСТЕМЫ
Операционная система определит в дальнейшем не только варианты пользовательского интерфейса, дружественность по отношению к пользователю, критичность к ошибкам, но и задаст, уже на этапе проектирования системы, ограничения в выборе программных средств, с помощью которых будет создаваться система, поэтому, важной составляющей разработки любого программного продукта является выбор операционной системы (ОС) - платформы, на которой он будет разработан. В настоящее время наиболее известными операционными системами для современных компьютеров являются:
- Microsoft Windows 95/98/NT/2000/7;
- операционная система OS/2.
Операционная система OS/2 используется для работы с большими базами данных и в других областях, где стабильность операционной системы важнее совместимости с существующими прикладными программами. В настоящий момент количество стандартных прикладных программ для OS/2 достаточно ограничено, поэтому ее использование нецелесообразно.
Для работы системы необходима многозадачная операционная система. Среди многозадачных OC на данный момент выделяется линейка Windows фирмы Microsoft, обладающая легкостью освоения и большими возможностями наиболее распространенной является Windows XP, которая кроме этого является наиболее надежной в линейке. Тем более что среда программирования Visual Studio 2010, используемые для создания программного комплекса, поддерживается данной операционной системой.
Объектно-ориентированное программирование .Net Framework и C# полностью базируются на объектно-ориентированных принципах, что очень удобно при разработке сложных программ. В плане дизайна - библиотека классов организована с очень понятным интерфейсом. Также данная платформа обладает независимостью языка - языки С#, J#, C++ обладают возможность взаимодействия, так как компилируются в общий язык.
Расширение круга поддерживаемых операционных систем позволит пользователям автоматизированной системы устанавливать систему на различные типы систем, не ограничивая себя выбором определенной ОС, что является крайне важным фактором в распростроняемости системы и ее востребованности [3,4,6].
1.3.2 Выбор средств разработки
Для реализации системы были использованы языки программирования: C#.NET и Object Pascal. Среда программирования - Visual Studio 2008, которая сочетает в себе возможности структурного и объектно-ориентированного программирования Интегрированный отладчик имеет много новых свойств, включая удаленную и многопроцессорную отладку, просмотр кода центрального процессора, инспекторов, усовершенствованные точки прерывания, отладчик специфических подменю и закрепленных окон.
Дизайнер форм в Visual Studio интуитивно понятен и прост в использовании. Несмотря на всю важность «Дизайнера форм», местом, где программисты проводят основное время, является редактор. Логика является основой программы, а редактор является местом ее преобразования в программный код (рисунок 2).
Данный язык значительно облегчает разработку интерфейсной части программы и предоставляет пользователю возможность удобства в наборе, редактировании и форматировании текста. Кроме того, компилятор языка обеспечивает удобство разработки, а также высокое качество и надежность исполняемого кода.
Кроме того, для разработки приложения используется .NET-ориентированный язык, что является наиболее простым решением для создание программного обеспечения ПК, поэтому для наиболее лучшего взаимодействия Visual Studio является наиболее оптимальным для создания автоматизированной системы.
2. Разработка физической модели БД
2.1 Физические модели
Для перехода от логической модели к физической необходимо определить физические характеристики хранимых записей: типа значений и объема требуемой для хранения значений памяти. Таким образом, физическая модель данных ориентированная на конкретную СУБД.
На физическом уровне основными компонентами физической базы данных являются физические блоки, хранимые записи, указатели, данные переполнения и промежутки между блоками. Взаимосвязи между хранимыми записями, возникающие в результате их группирования или использования индексных структур, могут также рассматриваться как часть физической структуры. Результатом физического проектирования является полностью готовая к внедрению структура базы данных.
Логический уровень позволяет давать сущностям семантические имена более понятные специалистам предметной области. На физическом уровне объекты БД необходимо называть так, как того требуют ограничения СУБД (например, словами, состоящими из латинских букв и символов «_», без использования специальных символов).
Учитывая выбранные в разделе 1.1.2 средства разработки, рассмотрим физическую реализацию структуры баз данных для СУБД.
Описание данных, хранимых в таблицах удаленной базы данных Access, можно представить в виде таблиц 2.1 - 2.10.
В таблице 2.1 представлена структура таблицы оборудование, хранящей данные об оборудовании, используемом на предприятии. В таблице приведены важные поля.
Таблица 2.1 - Структура таблицы «Оборудование»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Id_equ |
Уникальный идентификатор (серийный номер) |
Int(16) |
Автоинкремент, первичный ключ |
|
Inv_numb |
Инвентарный номер |
Int(10) |
|
|
War_per |
Гарантийный срок |
integer |
|
|
Date_adm |
Дата приёма |
datetime |
|
|
manufact |
Производитель |
Varchar(10) |
|
|
Date_comm |
Дата введения в эксплуатацию |
datetime |
|
|
Depart_id |
Идентификатор отдела |
Int(6) |
Внешний ключ |
|
Model_id |
Идентификатор модели |
Int(6) |
Внешний ключ |
Таблица 2.2 - Структура таблицы «Модель оборудования»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
model_id |
Идентификатор модели |
Int(6) |
Автоинкремент, первичный ключ |
|
name |
Наименование модели |
Varchar(15) |
|
Таблица 2.3 - Структура таблицы «Специалист»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Empl_numb |
Уникальный идентификатор |
Int(6) |
Автоинкремент, первичный ключ |
|
FIO |
Фамилия, имя, отчество специалиста |
Varchar(30) |
|
|
login |
Логин специалиста |
Varchar(10) |
|
|
parol |
Пароль специалиста |
Int(5) |
|
|
post |
Должность специалиста |
Varchar(15) |
|
|
task |
Задача, которую выполняет специалист |
Varchar(255) |
|
|
Depart_id |
Идентификатор отдела |
Int(6) |
Внешний ключ |
Таблица 2.4 - Структура таблицы «Отдел»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Depart_id |
Уникальный идентификатор |
Int(6) |
Автоинкремент, первичный ключ |
|
name |
Наименование отдела |
Varchar(15) |
|
Таблица 2.5 - Структура таблицы «График»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Sched_id |
Уникальный идентификатор |
Int(6) |
Автоинкремент, первичный ключ |
|
year |
Год, в которым необходимо ремонтировать оборудование |
integer |
|
|
Kind_serv_id |
Идентификатор вида техобслуживания |
Int(6) |
Внешний ключ |
Таблица 2.6 - Структура таблицы «Вид техобслуживания»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Kind_serv_id |
Идентификатор вида техобслуживания |
Int(6) |
Автоинкремент,первичный ключ |
|
Name_serv |
Название вида техобслуживания |
Varchar(10) |
|
Таблица 2.7 - Структура таблицы «Заказ-наряд»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Purch_id |
Уникальный идентификатор |
Int(6) |
Автоинкремент, первичный ключ |
|
Date_serv |
Дата начала обслуживания |
datetime |
|
|
Time_serv |
Время обслуживания |
integer |
|
|
Rias_fail |
Причины поломки оборудования |
Varchar(20) |
|
|
Sign |
Признак поломки |
boolean |
|
|
Numb_pur_ord |
Номер заказ_наряда |
Int(5) |
|
|
Date_pur_ord |
Дата заказ-наряда |
datetime |
|
|
Performer. Empl_numb |
Идентификатор исполнителя, табельный номер |
Int(6) |
Внешний ключ |
|
Customer. Empl_numb |
Идентификатор заказчика, табельный номер |
Int(6) |
Внешний ключ |
|
Observer. Empl_numb |
Идентификатор наблюдателя, табельный номер |
Int(6) |
Внешний ключ |
|
Inv_numb |
Идентификатор оборудования |
Int(6) |
Внешний ключ |
|
Sched_id |
Идентификатор графика |
Int(6) |
Внешний ключ |
Таблица 2.8 - Структура таблицы «Вид работ»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Work_id |
Уникальный идентификатор |
Int(6) |
Автоинкремент, первичный ключ |
|
Name_work |
Наименование работы |
Varchar(15) |
|
Таблица 2.9 - Структура таблицы «Вид работ_Заказ-наряд»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Work_id |
Идентификатор вида работы |
Int(6) |
Внешний ключ |
|
Purch_id |
Идентификатор заказ наряда |
Int(6) |
Внешний ключ |
Таблица 2.10 - Структура таблицы «График_оборудование»
|
Название поля |
Описание |
Тип поля |
Дополнительно |
|
Shed_id |
Идентификатор графика |
Int(6) |
Внешний ключ |
|
Inv_numb |
Идентификатор оборудования |
int(6) |
Внешний ключ |
|
month |
Планируемый месяц проведения |
integer |
|
Представленная на рисунке 3 физическая модель базы данных была построена на основе логической модели базы данных (раздел 1.1.2), а также диаграммы сущностных классов (раздел 1.1.3).
2.2 Выбор и обоснование комплекса технических средств
2.2.1 Расчет необходимого объем внешней памяти
Проведем расчет необходимой внешней памяти для системы по формуле:
VВП = VОС + VFrame + Vпрогр. + VБД , (2.1)
где VОС - объем внешней памяти, занимаемый операционной системой, МБ;
VFrame - объём внешней памяти, занимаемый средой исполнения Net Framework;
Vпрогр. - объём внешней памяти, занимаемый программой после установки, МБ;
VБД - объём внешней памяти, занимаемый локальной базой данных, МБ.
Для расчета примем, что программа функционирует в операционной системе Windows 7, которой необходимо VОС = 4096 ГБ внешней памяти, среда исполнения Net Framework VFrame= 35 МБ, Vпрогр = 3 МБ.
Расчет размера локальной БД представлен в таблице 2.11.
Таблица 2.11 - Оценка размеров таблиц для случая максимального заполнения.
|
Таблица |
Длина записи, байт |
Макс. число записей |
Размер, МБ |
|
Пользователи |
65568 |
5 |
0,312653 |
|
Внесённые записи |
24 |
60 |
0,002144 |
|
Объем хранимых данных |
|
0,31479 |
|
VВП = 4096 МБ + 35 МБ +3 МБ + 0,31479 МБ = 4134,31479 МБ.
Таким образом, объем дискового пространства, требуемого для работы системы, составит чуть более 4 ГБ, и даже минимальная конфигурация распространенных сейчас ЭВМ будет обеспечивать требуемые ресурсы долговременной памяти.
2.2.2 РАСЧЕТ НЕОБХОДИМОГО ОБЪЕМА ОПЕРАТИВНОЙ ПАМЯТИ
Проведем расчет необходимой оперативной памяти по формуле:
VОП = VОС + VAIR +Vпрогр. , (2.2)
Для работы ОС Windows 7 необходимо в среднем VОС = 1ГБ оперативной памяти, среде исполнения Net Framework VFrame = 27 МБ, программе Vпрогр. = 12 МБ.
VОП = 1024 МБ + 27 Мб + 12 МБ = 1063 МБ.
То есть в качестве подходящего объема оперативной памяти целесообразно принять 1,5 ГБ.
2.2.3 МИНИМАЛЬНЫЕ ТРЕБОВАНИЯ К КОМПЛЕКСУ ТЕХНИЧЕСКИХ СРЕДСТВ
На основе выполненных расчётов занимаемой памяти и исходя из основного назначения программы, сформулируем основные требования к КТС:
- IBM PC - совместимый компьютер с тактовой частотой процессора 1 ГГц и более;
- объем оперативной памяти не менее 1,5 ГБ;
- жесткий диск объемом не менее 5 ГБ;
- монитор с разрешением не ниже 1024x600 пикселей;
- видеокарта с памятью объемом 64MБ с поддержкой 16 млн. цветов;
- манипулятор мышь.
Требования к программному обеспечению:
- тип операционной системы: для Windows-систем - Microsoft Windows NT (Windows XP и выше);
- установленная среда для запуска приложений Net Framework версии не ниже 3.0 [5].
ЗАКЛЮЧЕНИЕ
Таким образом, становится понятно, что в России на данный момент идёт привыкание к базам данных и их развитие, путём перехода отраслей на компьютерные базы данных вместо привычной рукописной документации.
Именно поэтому тема является важной, а сами ФБД - преимущественное направление развития, так как они позволяют наиболее кратко и понятно размещать данные и быстро находить нужные.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. http://edu.dvgups.ru/METDOC/ITS/STRPRO/INF_TEH_STR/METOD/SULDIN/frame/6.htm
2. http://orloff.am.tpu.ru/data_base/kr1/infomodel.htm
3. http://www.dissercat.com/content/razrabotka-metoda-vybora-sredstv-realizatsii-algoritmov-analiza-posledovatelnykh-potokov-dan
4. http://www.dissercat.com/content/razrabotka-metoda-vybora-sredstv-realizatsii-algoritmov-analiza-posledovatelnykh-potokov-dan
5. http://bibliofond.ru/view.aspx?id=470099
6. https://ru.wikipedia.org/wiki/Википедия