Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление (специальность) Информатика и вычислительная техника

Кафедра Информационных систем и технологий

Выпускная квалификационная работа (бакалаврская работа)

Разработка автоматизированной информационной системы склада производственной компании

Ст. препод. А.С. Тучкова

Н. контролер доцент к.т.н. с.н.с. О.Л . Куляс

Разработал ПО-32 А.В. Мартынов

Самара 2017

Введение

Для принятия обоснованных и эффективных решений в производственной деятельности, в управлении экономикой и в политике современный специалист должен уметь с помощью компьютеров и средств связи получать, накапливать, хранить и обрабатывать данные, представляя результат в виде наглядных документов. В современном обществе информационные технологии развиваются очень стремительно, они проникают во все сферы человеческой деятельности.

Целью данной дипломной работы является разработка удалённой базы данных и приложения-клиента для доступа к электронным источникам, содержащихся на жёстком диске сервера предприятия в виде файлов и пакетов фалов (текстовых документов различных типов, гипертекста HTML, исполняемых файлов и др.). Архитектура клиент-сервер, используемая при реализации поставленной задачи на данный момент, является наиболее прогрессивной. Она даёт возможность разделить задачу на две подзадачи: разработка собственно удалённой базы данных, физически расположенной на сервере и управляемой СУБД, и приложения, осуществляющего доступ к данной базе данных при помощи SQL-запросов и располагающееся на рабочих станциях пользователей сети. При такой реализации нагрузка также распределяется между сервером и рабочими станциями, что позволяет увеличить скорость работы программы.

Для управления базой данных была выбрана СУБД InterBase 6.0 фирмы Borland. Для разработки клиентской части приложения использовалась среда программирования Java, предоставляющая удобные средства для быстрого и наглядного создания подобных приложений.

Разработанная в ходе дипломной работы база данных позволяет увеличить скорость поиска и доступа пользователя к необходимым источникам информации, позволяет упорядочить и систематизировать их. А это в свою очередь может повлиять на производительность труда пользователя, которому не надо тратить большое количество времени на поиск необходимой информации.

Практическая значимость работы состоит в том, что полученные теоретические и научно-методические результаты могут быть использованы и внедрены в работу любой производственной организации, у которой среди всех бизнес-процессов имеется процесс хранения товара (т.е. склад). Разработанные рекомендации и методики представляют практический интерес для сотрудников и руководителей, занятых в сфере хранения товара.

Таким образом, тема данной работы является актуальной с практической точки зрения.

Целью выпускной квалификационной работы является разработка автоматизированной информационной системы склада производственной компании.

В соответствии с поставленной целью необходимо решить следующие задачи:

· проанализировать теоретические аспекты работы с базами данных, х проектирования и создания;

· рассмотрение методов моделирования баз данных;

· разработка основных критериев, которым должна соответствовать система;

· разработка базы данных посредством языка программирования высокого уровня;

· анализ полученных результатов.

Объектом исследования является прототип металлургического завода, основной вид деятельности которого - производство металлических деталей для различных отраслей.

Предметом исследования является база данных производственной организации.

Теоретической основой для написания выпускной квалификационной работы составили труды отечественных авторов, таких как: Иванова О. В., Щавелёва Л. В., Горбань А. Н., Боровиков В. П., а также зарубежных авторов: Ф. Уоссерман, Паркер Д. Б., Кэнту М. и другие.

В этих книгах рассказывается о теоретических принципах и аспектах работы с базами данных. Рассматриваются различные инструментарии и методы их проектирования и создания. Обсуждается классический подход к проектированию БД, а также рассмотрены основные подходы и направления развития языков высокого уровня.

Работа состоит из введения, трёх разделов, заключения, списка использованных источников и двух приложений.

В первом разделе раскрываются теоретические аспекты работы с базами данных, рассказывается об основных понятиях и методологиях.

Во втором разделе проводится проектирование инфологической модели создаваемой базы данных.

В третьем разделе описывается практическая часть создания базы данных склада производственной организации посредством языка JavaScript.

1. Теоретические основы работы с базами данных

1.1 Основные понятия систем баз данных

Система баз данных - это компьютеризированная система хранения записей, т. е. компьютеризированная система, основное назначение которой - хранить информацию, предоставляя пользователям средства её извлечения и модификации.

Преимущества системы с базой данных по сравнению с традиционным методом ведения учёта:

1) компактность;

2) скорость;

3) низкие трудозатраты;

4) актуальность;

5) централизованное управление данными;

6) независимость данных.

Система баз данных включает в себя четыре основных компонента: данные, аппаратное обеспечение, программное обеспечение (в частности систему управления базами данных, или СУБД) и пользователи.

Системы баз данных бывают однопользовательские и многопользовательские. Однопользовательская система - это система, в которой одновременно к базе данных может получить доступ не более одного пользователя, а многопользовательская система - это такая система, в которой к базе данных могут получить доступ сразу несколько пользователей.

В общем случае данные в базе данных являются интегрированными и разделяемыми. Под понятием интегрированности данных подразумевается возможность представить базу данных как объединение нескольких отдельных файлов данных полностью или частично исключающих избыточность хранения информации. Под понятием разделимости данных подразумевается возможность использования отдельных элементов, хранимых в базе данных несколькими различными пользователями.

К аппаратному обеспечению системы относят следующее:

1) Тома вторичной (внешней) памяти, используемые для хранения информации, а также соответствующие устройства ввода-вывода, контроллеры устройств, каналы ввода-вывода и т. д.

2) Аппаратный процессор (или процессоры) вместе с основной (первичной) памятью, предназначенные для поддержки работы программного обеспечения системы баз данных.

Между собственно физической базой данных и пользователями системы располагается уровень программного обеспечения, который можно называть по-разному: менеджер базы данных, сервер базы данных или система управления базами данных (СУБД). Все запросы пользователя на доступ к базе данных обрабатываются СУБД. Все имеющиеся средства добавления файлов (или таблиц), выборки и обновления в этих файлах или таблицах также предоставляются СУБД. Основная задача СУБД - предоставить пользователю базы данных возможность работать с ней, не вникая в детали на уровне аппаратного обеспечения.

Пользователей можно разделить на три большие и отчасти перекрывающиеся группы. Первая группа - прикладные программисты, которые отвечают за написание прикладных программ, использующих базу данных. Прикладные программисты получают доступ к базе данных посредством выдачи соответствующего запроса к СУБД. Вторая группа - конечные пользователи, которые работают с системой баз данных непосредственно через рабочую станцию или терминалы. Конечный пользователь может получить доступ к базе данных, применяя одно из интерактивных приложений или же интерфейс, интегрированный в программное обеспечение самой СУБД. Третья группа - администраторы базы данных (АБД). Они отвечают за администрирование базы данных и всей системы баз данных в соответствии с требованиями, устанавливаемыми администратором данных.

База данных - это некоторый набор перманентных (постоянных) данных, используемых прикладными системами какого-либо предприятия, организации.

База данных представляет собой совокупность связанных данных конкретной предметной области.

Сущность - любой отличимый объект, который может быть представлен в базе данных. Кроме собственно основных сущностей, существуют ещё и связи между ними, которые объединяют эти основные сущности. В реляционных базах данных и основные сущности, и связи между ними представляются с помощь таблиц. Связь можно понимать, как связь особого типа.

Сущности (а значит, и связи) имеют некоторые свойства, соответствующие тем данным о них, которые мы желаем записать. В общем случае свойства могут быть как простыми, так и сложными, причём настолько, насколько это потребуется.

Независимость может быть реализована на двух уровнях: физическом и логическом. Независимость баз данных может быть определена как иммунитет прикладных программ к изменениям способа хранения данных и используемых методов доступа. Среди прочего для независимости данных требуется строгое разделение между моделью данных и её реализацией.

Системы баз данных обычно поддерживают транзакции или логические единицы работы. Основное преимущество транзакций заключается в том, что они гарантируют атомарность выполняемых действий, несмотря на возможные сбои системы, имевшие место до завершения выполнения транзакции.

диск сервер база данные

1.2 Архитектура системы баз данных

Под архитектурой системы понимают совокупность ее основных функциональных компонентов, а также средств обеспечения их взаимодействия друг с другом, пользователями и системным персоналом. Одно из наиболее важных функций систем баз данных, оказавших решающее влияние на формирование сложившегося в наши дни подхода к архитектуре является обеспечение возможностей абстракции данных. Абстракции данных, предоставляемые системой служат средством поддержки независимости способов ведения БД различными группами пользователей (это свойство системы называется независимостью данных). В системах обычно имеют дело с уровнями абстракции и часто эти уровни выстраиваются в некоторую иерархию. Функциональный компонент системы, механизмы, которые служат для поддержки некоторого уровня абстракции называется архитектурным уровнем. В результате простейшего анализа в системе можно выделить 2 основных уровня абстракции: логический и физический. Понятно, что введение каждого дополнительного уровня существенно усложняет реализации и эксплуатацию системы и снижает ее производительность, но часто дополнительные уровни необходимы что бы обеспечить:

1. адекватные способы видения системы для различных групп персонала.

2. создать инструментарий, удовлетворяющий потребностям пользователей.

3. представить систему в привычных для конкретной группы пользователей терминов.

4. изменять некоторые характеристики системы, не затрагивая других.

Любой архитектурный уровень располагает внутренними и (возможно, внешними интерфейсами). Интерфейс называется внутренним, если он обеспечивает взаимодействие механизмов данного уровня с другими системными компонентами. Интерфейс называется внешним, если он обеспечивает взаимодействие механизмов данного уровня с пользователями и системным персоналом. Архитектурный уровень называется управляемым (неуправляемым), если он располагает (не располагает) внешним интерфейсом. Концепция многоуровневой архитектуры служит основой современной технологии создания БД. Первой научной работой, содержащей идеи многоуровневой архитектуры считается опубликованный в 1975 году отчет рабочей группы по базе данных комитета по планированию стандартов американского национально института стандартов. В отчете была предложена следующая обобщенная трехуровневая модель архитектуры, которая изображена на рисунке 1.1

Рис. 1.1 - Трехуровневая модель архитектуры

1.3 Реляционная модель

Внешняя модель описывается с помощью внешней схемы. Одни и те же данные могут интересовать с совершенно разных точек зрения. Например, завхоза данные о стульях интересуют с точки зрениях их исправности, а бухгалтера с точки зрениях стоимости. Соответственно различные точки зрения на данные порождают различные языки и внешние модели. 1 язык может «обслуживать несколько моделей» и одной модели может соответствовать несколько языков, поэтому на схеме предметных областей не столько же, сколько внешних моделей.

Концептуальный уровень служит для поддержки единого взгляда на единую базу данных и общего для всех его приложений. Концептуальная схема описывает совокупность всех записей. Третий уровень - внутренний (физический), его механизмы служат для поддержки представления о БД в среде хранения. Это единственны архитектурный уровень, в котором БД представлена в полностью материализованном виде. Отображение концептуально-внутреннее определяет соответствие между моделью данных и хранимой базой данных, т.е. указывает как концептуальные записи и поля отображаются в их реальной копии. Если структура хранения БД изменится, то отображении концептуально-внутреннее должно измениться так, что концептуальная схема оставалась неизменной (это ответственность администратора). Отображение внешнее концептуальное определяет соответствие между конкретной внешней моделью и моделью данных, различные внешние модели могут и пересекаться.

Типичная алгоритм управления в управлениях данной схемы:

1. Пользователь выдает запрос на доступ, используя конкретный подъязык данных.

2. СУБД воспринимает запрос и интерпретирует его

3. СУБД обследует по очереди внешнюю схему, отображение внешне-концептуальное, концептуальную схему, отображение концептуально-внутреннее и определяет структуру хранения

4. СУБД выполняет необходимые операции над хранимой БД

Построение БД по этой схеме, предполагает, что интерфейс пользователя является границей, за которой пользователь ничего не видит. В частности, одним из признаков хорошей базы данных написанной в АКСЦЕСС является то, что все свои задачи пользователь решает только через формы и не обращается к конструкторам.

Стоит также отметить, что построение реляционной модели данных основывается на том понимании, что любой набор данных может быть представлен в виде отношения, оформляемого, но форме таблицы (таблица 1.1), где данные представляются атрибутами и значениями на пересечении соответствующего атрибута с записью (кортежем).

Таблица 1.1 Пример отношения в реляционной модели

ИДФ должности	Полное наименование	Краткое наименование
1	Генеральный директор	Ген. Дир.
2	Главный бухгалтер	Гл. бух
3	Инспектор	Инсп.

Под термином "Отношение" понимается множество данных, объединенных в совокупность записей (кортежей) и описанных заголовком, содержащим множество атрибутов.

В представленном выше примере вся совокупность значений должностей и заголовочная часть с именованными атрибутами, по которым размещаются значения, называется отношением. В терминах формальной логики отношение в общем виде может быть представлено следующим образом:

R{A,T},i={1..n}

В данном представлении под A, понимается атрибут, описывающий одну характеристику данных, а под T- тип данных, которому должны соответствовать представляемые в отношении данные. Представленный выше пример является неформальным изложением отношения. В его заголовке не указаны типы данных, которыми описываются представляемые в теле отношения сведения.

Обычно заголовок отношения, где указываются наименования атрибутов и их типов, называют схемой отношения, а совокупность взаимосвязанных схем отношений называется схемой данных. Заголовок отношения содержит стандартизированные типы данных или типы, произведенные из стандартизированных типов, а множество значений, связанных с конкретным атрибутом стандартного или производного типа данных, именуется доменом.

Под термином "Домен" в теории баз данных понимается допустимое множество поименованных значений одного типа имеющих определенный смысл.

Из данного определения следует, что домен характеризуется следующими свойствами:

* домен несет определенную смысловую нагрузку, что выражается в понимании смысла описываемых данных, который обычно совпадает с понимаем данных в предметной области;

* домен определяется простым или производным от простого типа данных, что позволяет воспользоваться простыми логическими операциями над данными;

* домен может содержать логическое условие, которое выделяет определенное подмножество данных, допустимое для этого домена.

Тело отношения строится из множества записей, которые в терминах реляционной алгебры называются кортежами и представляют сведения, существующие в предметной области в рамках рассматриваемого объекта или группы взаимосвязанных объектов.

Таким образом, согласно определению кортежа, в него входят все возможные данные, подчиняющиеся правилам, определенным отдельными доменами. При этом каждый элемент данных кортежа соответствует только одному домену и подчиняется всем свойствам, которые определяются этим доменом.

Описание кортежей использует ряд важных свойств, некоторые из которых представлены ниже:

каждый кортеж содержит только одно значение для каждого из атрибутов, характеризующих отношение;

для компонентов кортежа, аналогично элементам домена, не предполагается какое-либо упорядочивание;

каждое подмножество кортежей представляется тоже кортежем.

Объединяя домены и кортежи, можно сформировать отношение, которое в общем виде определяется следующим образом;

R[<Заголовок>]{<Список кортежей >}.

Заголовок отношения представляется разделенным запятыми списком атрибутов. Также важным является тот факт, что второй параметр отношения, при правильном представлении, обозначается термином "Тело", содержащим множество кортежей. Но для упрощения неформального общения и упрощения изложения термин "Тело" заменяют термином "Кортеж", подразумевая, что все кортежи формируют тело отношения. В дополнение к пониманию терминов "Кортеж", "Домен" и "Тело" в теории реляционных баз данных устанавливается ограничение, по которому все кортежи одного отношения относятся к одному и тому же типу кортежа, а он (тип кортежа) должен быть точно таким же, как он определен в заголовке отношения. Таким образом, все правила для представления данных, определенные в заголовке, распространяются на все кортежи отношения.

Учитывая описанные выше определения отношения, кортежа и домена, можно сформулировать основные свойства отношения. Для примера свойств отношения рассмотрим отношение информации о сотрудниках организации, включающее атрибуты кортежей, по ФИО сотрудника, его должности и должностному окладу. Эти атрибуты будут составлять заголовок отношения, формируя домены для отношения. Каждый атрибут заголовка содержит не только название атрибута, но и его тип (таблица 1.2) который определяет возможные типы хранимых данных по их представлению, обработке и ограничениям.

Таблица 1.2 Пример отношения "Сотрудники"

Табельный номер integer	ФИО сотрудника: character	Должность: character	Оклад: Float
1	Иванов Иван Иванович	Генеральный директор.	25000
2	Петров Петр Петрович	Главный бухгалтер	20000
3	Литвин Татьяна Сергеевна	Инспектор	10000

Любое отношение в реляционной базе данных характеризуется следующими свойствами.

1. Каждый кортеж содержит только одно значение соответствующего типа по каждому атрибуту (отношение нормализовано).

Каждому атрибуту в представленном примере в рамках каждого кортежа поставлено в соответствие только одно значение, что видно на пересечении выделенного домена "ФИО сотрудника" и кортежа с ФИО "Петров Петр Петрович". Отношение, которое соответствует этому свойству, является нормализованным, т.е. находится в данном случае в первой нормальной форме, 1НФ.

2. Атрибуты не являются упорядоченными по какому-либо правилу.

Ранее было определено, что компоненты кортежа не являются упорядоченными, а поскольку кортеж должен однозначно соответствовать атрибутам заголовка, то и эти атрибуты также не являются упорядоченными. Нужно понимать, что человек, представляя структуры данных, всегда применяет определенные правила упорядочивания атрибутов и кортежей, но важно помнить, что такое упорядочивание не является важным и не учитывается при работе с реляционными базами данных. Поэтому понятия "Первый атрибут" или "Второй атрибут" к объектам реляционной модели неприменимы, а также не может идти речь о термине "Следующий атрибут" или "Предыдущий атрибут".

Такая ситуация дает определенную жесткость в работе с базами данных, улучшая качество программного кода обработки данных, что зачастую не всегда очевидно при программировании с меньшей жесткостью.

3. Кортежи не являются упорядоченными по какому-либо правилу.

Данное свойство следует из того, что тело отношения представляется

множеством, которое по математическим правилам не является упорядоченным. Поскольку реляционные отношения подчиняются правилам работы с математическими множествами, то и применяется математический аппарат работы с множествами.

Конечно, представляя отношение на бумаге, человек попытается его каким-либо образом упорядочить, чтобы легче было обрабатывать. Однако такое отражение отношения не является правилом и является всего лишь представлением отношения. Само же отношение остается неупорядоченным, и представив его в другом порядке расположения кортежей, само отношение не изменить и к нему можно будет применить те же операторы обработки, что и для отношения с другим упорядоченным представлением. Из этого следует, что для реализации в базах данных упорядоченное представление отношения не имеет никакого смысла, а значит, любое отношение в базах данных является неупорядоченным.

4. В отношении отсутствуют дубликаты кортежей.

Это свойство отношения следует из понимания того, что тело отношения представляется множеством, а любое множество, с учетом его математического представления, не содержит дубликатов. Из этого следует, что, взяв любой кортеж, представленный всеми используемыми в отношении атрибутами, невозможно будет найти ни одного кортежа точно с такими же значениями атрибутами.

В то же время, это свойство иллюстрирует различия между отношением и таблицей. Понимая, что таблица данных является физической реализацией отношений в базе данных, там можно разместить записи с одинаковыми значениями, если, конечно, не обеспечить на уровне программной логики построения базы данных такую возможность, а отношение, по определению, никогда не содержит дубликатов кортежей.

Зачастую, когда нет необходимости отражать значения, описываемые в отношении (тело отношения), в реляционной модели ограничиваются только указанием заголовка отношения с про писание наименования самого отношения или только наименованием отношения. Такие представления реляционной модели данных являются фильтрованными отображениями, которые применяются в специализированных средствах моделирования структур баз данных, как, например, в IBM InfoSphere Data Architect (рис. 1.2)

Рис. 1.2 - Пример реляционной модели данных

Основными сведениями, содержащимися в реляционной модели данных, являются наименования отношений (сущностей), атрибутов и типов атрибутов, которыми описывают отношения. Дополнительно в реляционной модели отражаются связи между отношениями (сущностями), которые дают возможность отобразить взаимодействие элементов тел связанных отношений. Каждый из указанных компонентов реляционной модели обладает рядом вспомогательных характеристик, которые уточняют.

Отсутствие в визуализации модели типов атрибутов и прочих характеристик не значит, что они не определены или их нет. Это всего лишь означает, что модель данных представлена для необходимости рассмотрения только указанных параметров, а все остальные характеристики зафиксированы в скрытых компонентах модели. Например, другим вариантом представления может быть случай, показанный на рисунке 1.3



Рис. 1.3 - Пример расширенного представления реляционной модели данных

В данном представлении, помимо наименования отношений (сущностей) и атрибутов, отображены типы данных, которые характеризуют тело отношения, хотя само тело в данных моделях не представляется. Нужно учитывать, что модель данных (модель базы данных) в специализированных средствах моделирования ориентирована на дальнейшее представление в виде структуры базы данных и указание тел отношений является нецелесообразным. В связи с этим в моделях баз данных, как правило, тела отношений не показываются. Если же модель строится именно для отражения операций с отношениями, в полном понимании этого термина, то все отношения должны представляться с телами, иллюстрирующими возможные значения, которые впоследствии будут храниться в таблицах базы данных.

Такое разделение зачастую вносит некоторую путаницу в корректность использования той или иной модели данных (модели базы данных), что требует более точного описания их использования. Так, модель данных в виде отношений используется, когда необходимо проиллюстрировать возможные операции над данными отношений и понимать правильность интерпретации в модели предметной области, представленной объектами с их возможными экземплярами. Модель данных в виде сущностей и связей (ЕЛ-модель) используется для формирования логической (инфологической) модели базы данных без указания конкретных значений данных и направлена на дальнейшее представление в форме структуры базы данных. Модель в виде таблиц и связей строится на физическом уровне, отражая особенности представления и обработки данных на уровне СУБД.

2. Проектирование базы данных

2.1 Методология проектирования баз данных

В процессе разработки базы данных как составной части информационной системы разработчикам необходимо пройти ряд этапов, многие из которых описаны в предыдущих разделах и будут рассматриваться далее. Эти этапы составляют методологию разработки базы данных, формируя максимально полное описание технологий представления, хранения и обработки данных компьютерными системами.

Под методологией проектирования понимают процесс описания разрабатываемой системы, регламентируемый конечным количеством определенных этапов, законов и правил разработки отдельных компонентов, и нотаций, определяющих форматы представления разрабатываемых элементов.

Для разработки баз данных также существует методология проектирования, которая затрагивает ряд этапов, от анализа предметной области и документов до описания процедур обработки и представления данных. Разработка базы данных основывается на предварительном анализе предметной области, на выделенных основных и вспомогательных функциях, а также описании окружения каждой функции. Использование этой информации дает разработчику обоснование использования при моделировании необходимых сущностей и представления в них нужных атрибутов, организуя между сущностями правильные связи.

Выделяемые в разработке базы данных подходы: классический (от документов) и функционально-объектный (от функций и объектов), -- реализуют единую методологию проектирования базы данных, определяя, в зависимости от выбранного подхода, ключевой элемент анализа - документ или объект соответственно.

Развитие классического подхода при проектировании реляционной базы данных основывается на том факте, что основным элементом работы пользователя в предметной области является документ, содержащий необходимую информацию, которую целесообразно хранить в базе данных с последующим представлением в электронных и бумажных документах. Этот подход практически никак не учитывает особенности работы с данными в рамках отдельных функций пользователя информационной системы, для которой разрабатывается база данных. Разработчики вспоминали о функциональной полезности базы данных только в момент разработки процедур обработки данных и реализации программного приложения.

Таким образом, классический подход позволяет создать неделимую информационную систему, что было хорошо для функциональных систем, включающих тесно связанные задачи, решаемые пользователем. Создание комплексных многофункциональных систем приводило к дублированию информации, излишней сложности структуры базы данных, большим временным откликам системы на потребности пользователя.

В результате решения этих проблем был сформулирован функционально-объектный подход к разработке базы данных, который, в большей степени, поддерживается объектно-ориентированными системами управления базами данных, но также может быть реализован и в рамках классических реляционных СУБД.

Основу функционально-объектного подхода к разработке базы данных составляет осознание потребностей пользователей системы в выполнении отдельных функциональных задач, которые, как из кирпичиков, составляют комплексную функциональную среду деятельности пользователя. Этот подход, выделяя отдельные функции предметной области и разделяя их на основные и вспомогательные, дает возможность разработчику подходить к процессу проектирования, рассматривая функции в виде самостоятельных блоков (черный ящик) и объединяя их в "строение", именуемое "информационная система". В результате использования данного подхода процесс проектирования информационной системы представляется последовательностью, показанной на рисунке 2.1

Рис. 2.1 - Процесс разработки информационной системы

Переходя к процессу моделирования базы данных, разработчик должен рассмотреть функциональные структуры данных, которые фактически представляют собой модели базы данных, ориентированные на работу одной конкретной функции предметной области. Естественно, что нет смысла создавать для единой информационной системы множество отдельных моделей баз данных под каждую функцию, если это не предусмотрено особыми требованиями к реализации информационной системы.

Если рассматривать этот процесс в рамках использования инструментальных средств разработки баз данных (например, IBM InfoSphere Data Architect), то создается одна область моделирования логической модели базы данных и в рамках этой модели для каждой функции создастся отдельная диаграмма. В результате получается, что все созданные в рамках одной диаграммы сущности будут доступны для других диаграмм этой же логической модели базы данных. Аналогично данный процесс представляется в других средствах моделирования баз данных с возможным изменением названий отдельных элементов, например: в СА ERWin Data Modeler для построения диаграмм по функциям используются элементы, называемые "рабочая область".

Дальнейший процесс моделирования данных предполагает использование объектов предметной области в качестве элементов для создания сущностей, а атрибуты, описывающие выделенные объекты, являются атрибутами соответствующих сущностей. В результате процесса моделирования структур данных для функций разработчик получает модель базы данных, которую можно в дальнейшем реализовывать в СУБД (рис. 2.2)

Рис. 2.2 - Процесс моделирования базы данных при функционально-объектном подходе

В данном процессе, в отличие от классического подхода, основу составляет ключевая сущность, которая соответствует основному объекту выбранной функции предметной области, информацию о котором необходимо хранить в базе данных. В результате рассмотрения атрибутивного состава ключевой сущности могут образоваться объектные атрибуты, которые в предметной области представляются самостоятельными объектами. Такие атрибуты должны в модели базы данных представляться в виде отдельных сущностей, связанных с сущностью, из которой они выделены. Этот процесс анализа атрибутов и выделения новых сущностей продолжается до тех пор, пока во вновь выделяемых сущностях не останутся только простые атрибуты.

Однако, независимо от выбранного подхода к разработке базы данных, реализации моделей баз данных будет идентичной, и все различия подходов представляются особенностями определения элементов моделей баз данных и правилами в процессах создания таких моделей. В функционально-объектном подходе разработчик обладает знаниями о функциях, реализуемых в предметной области, и объектах, которые являются основными (ключевыми) для каждой функции. Применяя методики анализа объектов, он формирует необходимые сущности и модели баз данных для каждой отдельной функции, объединяя их в рамках единой модели базы данных предметной области.

Если рассмотреть эти два подхода, то несложно увидеть, что процессы разработки базы данных практически не отличаются друг от друга. Это позволяет говорить, что методология разработки почти не изменилась при смене подхода и, после анализа предметной области, когда разработчик подходит к рассмотрению структур данных, этапность методологии проектирования требует анализа моделей данных, определения связей и применения соответствующих нотаций для представления структур данных.

Нотаций для представления моделей базы данных достаточно большое количество, и направлены они на представление структур данных, ориентированное на дальнейшее использование в СУБД и соответствующих реализациях информационных систем. Особенно важно правильно выбрать нотацию моделирования базы данных, когда речь идет о выборе подхода к реализации программного приложения: процедурное (транзакционное) или объектно-ориентированное приложение. Особых различий в подходах моделирования здесь не наблюдается, но представление моделей баз данных будет различным, учитывая необходимость связывания элементов и структур данных с объектными элементами программного приложения.

2.2 Инфологическое моделирование системы

В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений:

· представление предметной области в том виде, как она реально существует;

· как ее воспринимает человек (имеется в виду проектировщик базы данных);

· как она может быть описана с помощью символов.

Схемы данных, используемые для описания предметной области, изображены на рисунке 2.3

Рис. 2.3 - Трехуровневая модель ANSI/SPARC

Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.

Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

Концептуальное проектирование- сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

обследование предметной области, изучение ее информационной структуры;

выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, действиями над информационными объектами;

моделирование и интеграция всех представлений;

По окончании данного этапа получается концептуальная модель, инвариантная к структуре базы данных. Часто она представляется в виде модели «сущность-связь».

Логическое проектирование - преобразование требований к данным в структуры данных. В итоге получается СУБД-ориентированная структура базы данных и спецификация прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.

Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.

Различие уровней представления данных на каждом этапе проектирования представлено в таблице 2.1

Таблица 2.1 Уровни представления данных

Концептуальный уровень: сущности атрибуты связи	Представление аналитика
Логический уровень: записи элементы данных связи между записями	Представление программиста
Физический уровень: индексы методы доступа группирование данных	Представление администратора

Информационно-логическая модель - ориентированная на человека и не зависящая от типа СУБД модель предметной области, определяющая совокупности информационных объектов, их атрибутов и отношений между объектами, динамику изменений предметной области, а также характер информационных потребностей пользователей.

Информационно-логическая схема базы данных металлургического предприятия изображена на рисунке 2.4

Рис. 2.4 - Информационно-логическая схема базы данных

Информационно-логическая схема металлургического предприятия отражает связи между отдельными компонентами информационной системы, что позволяет полностью контролировать производственный процесс.

Для реализации базы данных металлургического предприятия было необходимо создать следующие таблицы:

· Персонал - таблица, содержащая информацию о рабочем персонале предприятия;

· Производство - таблица, отражающая текущий процесс производства на предприятии;

· Продукция - таблица, содержащая в себе данные о готовой продукции, произведенной предприятием и хранящейся на складе.

Атрибуты таблиц и типы данных, соответствующие значениям полей этих атрибутов для каждой из таблиц, указаны ниже в таблицах.

Таблица 2.2 Персонал

Код_раб	Числовой
Фамилия	Текстовый
Имя	Текстовый
Отчество	Текстовый
Цех	Текстовый
Должность	Текстовый
Специализация	Текстовый
Квалификация	Текстовый

Таблица 2.3 Производство

Код_изд	Числовой
Тип_изд	Текстовый
Цех	Текстовый
Объем_партии	Числовой
Стадия_изготов	Текстовый
Испытания	Логический

Таблица 2.4 Продукция

Код_прод	Числовой
Тип_прод	Текстовый
На_складе	Числовой
Цена	Числовой

Данные таблицы полностью описывает типы значений атрибутов таблиц в соответствии с требованиями к базе данных.

Также была составлена ER-диаграмма, которая представлена на рисунке 2.5

Рис. 2.5 - ER-диаграмма системы

3. Проектирование и создание производственной базы данных

3.1 Обоснование выбора среды разработки

При выборе среды реализации сравнивают программные продукты и пользуются различными средствами разработки приложений. Использование возможностей средств разработки приложений позволяет автоматизировать процесс разработки. Инструментальные средства позволяют:

· создавать интерфейс, используя стандартные компоненты;

· передавать управление процессам, в зависимости от состояния системы;

· создавать оболочки для баз данных, как и сами базы данных;

· разрабатывать более надежные программы путем обработки исключительных ситуаций возникающих при некорректной работе программы.

Современные средства разработки характеризуются параметрами:

1. поддержка объектно-ориентированного стиля программирования;

2. возможность использования CASE-технологий, как для проектирования разрабатываемой системы, так и для разработки моделей реляционных баз данных;

3. использование визуальных компонентов для наглядного проектирования интерфейса;

4. поддержка БД.

Выше перечисленными свойствами обладают языки программирования:

· Visual Fox Pro;

· JavaScript;

· Visual C++.

Каждое из этих средств содержит весь спектр современного инструментария, который был перечислен ранее. Главное отличие состоит в области использования рассматриваемых средств.

Для реализации дипломного проекта была выбрана JavaScript. При решении поставленной задачи оптимально использовать для представления информационных материалов язык JavaScript, который является языком высокого уровня и позволяет быстро и эффективно создавать приложения.

JavaScript - это продукт Borland International для быстрого создания приложений. Высокопроизводительный инструмент визуального построения приложений включает в себя настоящий компилятор кода и предоставляет средства визуального программирования, несколько похожие на те, что можно обнаружить в Microsoft Visual Basic или в других инструментах визуального проектирования. В основе Delphi лежит язык Object Pascal, который является расширением объектно-ориентированного языка Pascal.

JavaScript производит небольшие по размерам (до 15-30 Кбайт) высокоэффективные исполняемые модули (.exe и .dll). С другой стороны, небольшие по размерам и быстро исполняемые модули означают, что требования к клиентским рабочим местам существенно снижаются - это имеет немаловажное значение и для конечных пользователей.

Преимущества JavaScript по сравнению с аналогичными программными продуктами.

- быстрота разработки приложения;

- высокая производительность разработанного приложения;

- низкие требования разработанного приложения к ресурсам компьютера;

- наращиваемость за счет встраивания новых компонентов и инструментов в среду JavaScript;

- возможность разработки новых компонентов и инструментов собственными средствами JavaScript (существующие компоненты и инструменты доступны в исходных кодах);

- удачная проработка иерархии объектов.

Система программирования JavaScript рассчитана на программирование различных приложений и предоставляет большое количество компонентов для этого.

К тому же работодателей интересует прежде всего скорость и качество создания программ, а эти характеристики может обеспечить только среда визуального проектирования, способная взять на себя значительные объемы рутинной работы по подготовке приложений, а также согласовать деятельность группы постановщиков, кодировщиков, тестеров и технических писателей. Возможности JavaScript полностью отвечают подобным требованиям и подходят для создания систем любой сложности.

Язык программирования Java - это полностью объектно-ориентированный язык, который в отношении синтаксиса многое унаследовал от C++. Конечно, преимущества Java далеко не исчерпываются межплатформенностью. Язык Java в синтаксическом отношении проще и логичнее, чем C++. Java как платформа предоставляет в распоряжение программистов большое количество библиотек (пакетов), в которых содержится большое количество описаний классов и интерфейсов на все случаи жизни. С их помощью можно создавать стопроцентные приложения Java с возможностью обращения к базам данных, поддержкой передачи почтовых сообщений, с клиентской частью, которой необходим только web-браузер, или наоборот, с клиентской частью, обладающей изощренным интерфейсом.

Java - это очень элегантный и красивый язык. И всё же, стоит, отметить, Java - это не идеальный язык во многих ситуациях. Простой пример - если вы попытаетесь создать только на Java приложение, активно работающее с 3D-графикой, скорее всего, вы обнаружите, что работать такое приложение будет не очень быстро. Можно прийти к выводу, что для работы с 3D-графикой лучше использовать код, написанный на языке с более развитыми низкоуровневыми возможностями (например, на C++). Однако интегрировать такой код с кодом на Java вам будет очень сложно. Поскольку возможности для обращения к API компонентов, созданных на других языках, в Java очень ограничены, говорить о реальном межъязыковом взаимодействии на основе Java не приходится.

Однако, для поставленных нами задач, именно JavaScript всё же будет оптимальным решением.

3.2 Разработка структуры системы

В ходе разработки приложения базы данных металлургического предприятия был использован язык Java как средство разработки графического интерфейса пользователя.

Для реализации использовалась библиотека Swing, являющийся частью библиотеки JFC (JavaFoundationClasses), представляющей собой набор библиотек для создания графических оболочек. Компоненты Swing разработаны для одинаковой кроссплатформенной работы.

Начиная с версии Java 1.2, датированной 1998 годом, Swing входит в состав JavaRuntimeEnvironment.(JRE) - минимальная реализация виртуальной машины, необходимая для исполнения Java-приложений, без компилятора и других средств разработки. Состоит из виртуальной машины и библиотеки Java-классов. JRE распространяется компанией Oracle свободно.

При открытии вкладки открывается таблица базы данных, соответствующая этой таблице, и дальнейшая работа производится только с этой таблицей до момента, пока не произойдет переключение вкладки.

Возьмем типичную операцию фильтрации, реализованную в приложении базы данных металлургического предприятия:

// Действие для кнопки фильтрации.

addActionListener(new ActionListener() {void actionPerformed(ActionEvent e) {(! filterFlag) {field = cbSortFilter.getSelectedItem().toString();= "select * from " + TABLE_NAME + " where " + field + " " + tfFilter.getText() + " order by " + field + " ";(rbSortAsc.isSelected()) {+= "asc";

} else {+= "desc";

};{.execute(sql);= state.getResultSet();();= true;.setText("<html><h3><center>Снять фильтр</center></h3></html>");.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setRowSelectionInterval(0, 0);

} catch (SQLException ex) {.showMessageDialog(null, "Неверный запрос. Проверьте синтаксис.", "Ошибка!", JOptionPane.ERROR_MESSAGE);

}

} else {= "select * from " + TABLE_NAME + " order by Код_раб";{.execute(sql);= state.getResultSet();();= false;.setText("<html><h3>Фильтровать</h3></html>");.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setEnabled(! filterFlag);.setRowSelectionInterval(0, 0);

} catch (SQLException ex) {

}

}

}

});

В данной операции проходит фильтрация записей таблицы в соответствии с условием. Сначала с помощью логической переменной производится проверка, выполнена ли операция фильтрации: если она уже выполнена, код блокирует выполнение других операций с таблицей и при нажатии кнопки отменяет действие фильтра, а также возвращает исходный вид таблицы. Если же фильтр не включен, производится его инициализация. Выполняется запрос на выборку записей, удовлетворяющих условию, введенному пользователем в поле JTextField по выбранному в компоненте JComboBox полю. Затем таблица пересоздается в соответствии с количеством записей, полученных после выполнения запроса на фильтрацию. Конечным этапом выполнения запроса является вывод в таблицу записей, полученных в результате фильтрации, в соответствии с типом сортировки, определяемым выбранной пользователем JRadioButton.

3.3 Разработка интерфейса базы данных

При помощи библиотеки Swing была создана экранная форма, на которой в дальнейшем были помещены 3 вкладки, каждая вкладка соответствует одной таблице базы данных. Вкладки имеют одинаковую структуру.

Помимо таблицы, на каждой вкладке находятся кнопки навигации по таблице, кнопки модификации данных, компоненты для реализации сортировки и фильтрации, а также элементы, отвечающие за выполнение вводимых пользователем SQL-запросов.

Окно приложения отображено на рисунке 3.1

Рис. 3.1 - Экранная форма приложения

Интерфейс приложения выполнен в соответствии с требованиями эргономики и является стандартным для настольных приложений, реализующих доступ к базам данных.

Формами входных данных является табличный компонент, т.к. он позволяет редактировать все свои ячейки, кроме тех, которые отвечают за отображение первичного ключа, который, по сути, является счетчиком. Впоследствии внесенные в табличный компонент изменения можно сохранить с помощью кнопки «Сохранить запись». Помимо этого, к формам входных данных можно отнести компонент выбора поля для сортировки/фильтрации, поле ввода условия выборки для фильтрации и текстовую область для ввода пользовательских SQL-запросов для выполнения. Также к форме входных данных можно отнести добавление записи с пустыми значениями не ключевых атрибутов и заполненным полем первичного ключа.

Окно приложения отображено на рисунке 3.2

Рис. 3.2 - Процесс редактирования поля таблицы Производство

Формой выходных данных также являются табличные компоненты, т.к. после каких-либо изменений в таблице базе данных соответствующий ей табличный компонент отображает произведенные изменения.

В любом программном продукте, реализующем работу с базой данных, для каждой операции манипулирования данными требуется проводить тестирования на 3 типа вводимых данных: допустимые, недопустимые и граничные.

Например, проведем тестирование поля На_складе таблицы Продукция базы данных металлургического предприятия.

Тип поля На_складе и в базе данных, и в табличном компоненте является полем Integer, т.е. имеет целочисленный тип.

Попробуем ввести в ячейку табличного компонента данные строкового типа, т.е. данные, недопустимые для этого поля. При попытке завершить редактирование ячейки приложение не позволит нам продолжить и сохранить изменения в этой ячейке из-за несоответствия типов введенных данных и данных, указанных для этого поля.

Окно приложения отображено на рисунке 3.3

Рис. 3.3 - Результат применения фильтра для таблицы Производство

Попробуем ввести допустимое значение в эту же ячейку, т.е. целое число. Т.к. типы введенных данных и данных, специфических для поля, совпадают, то значение в ячейке табличного компонента сохранится. Впоследствии эти изменения можно будет внести непосредственно в базу данных с помощью кнопки «Сохранить запись».

Окно приложения отображено на рисунке 3.4.

Рис. 3.4 - Выполнение SQL-запроса пользователя

На скриншотах показаны примеры работы с созданной базой данных, что говорит о её работоспособности. Стоит отметить эргономичный интерфейс, в котором нет лишних кнопок, при этом меню является интуитивно понятным даже для среднего пользователя.

Заключение

Использование информационных систем в нашем мире имеет глобальный характер.

Информационные системы дают возможность систематизировать информационные ресурсы общества. Исследования показывают, что грамотное пользование информационных ресурсов значительно экономит природные ресурсы нашей планеты.

Базы данных позволяют оптимизировать и, в первую очередь, автоматизировать информационные процессы. Во многих развитых странах основная часть работоспособного населения принимает участие в обработке, хранении и передаче информационных продуктов и услуг.

В процессе выполнения дипломного проекта была исследована предметная область металлургического предприятия, реализованы этапы проектирования базы данных, построены информационно-логическая и логическая схемы данных, составлена структура базы данных, соответствующая СУБД Microsoft Access. Стоит отметить, что программа достаточно универсальна и может использоваться на любом предприятии другой отрасли.

В ходе разработки базы данных были изучены такие языки, как SQL и Java, а также изучена методика проектирования баз данных и их создание в СУБД Microsoft Access.

В результате выполнения ВКР было получено приложение базы данных металлургического предприятия в виде настольного приложения на языке Java. Таким образом можно сказать о том, что были выполнены следующие задачи:

· проанализированы теоретические аспекты работы с базами данных, их проектирования и создания;

· разработаны основные критерии, которым должна соответствовать система;

· разработана база данных посредством языка программирования высокого уровня;

В завершении стоит также отметить, что использование БД обеспечивает надежное хранение большого количества данных и легкое манипулирование ими. При этом БД обеспечивают экономные затраты памяти компьютерных систем.