Создание базы данных автомобилестроительного предприятия в виде настольного приложения на языке Java

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

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

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ ПОСТАВЛЕННОЙ ЗАДАЧИ

1.1 Общая характеристика предметной области и анализ объекта исследования

1.2 Постановка и развернутое описание решаемой задачи

1.3 Исследование потоков данных

1.4 Перечень задач, подлежащих решению

1.5 Средства решения поставленной задачи

ГЛАВА 2. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОЕКТА БАЗЫ ДАННЫХ

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

2.2 Определение логической структуры реляционной базы данных

2.3 Нормализация проекта базы данных

2.4 Реализация проекта базы данных в среде СУБД

2.5 Реализация защиты базы данных

ГЛАВА 3. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОГРАММНОЙ ЧАСТИ ПРОЕКТА

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

3.2 Разработка и описание алгоритмов

3.3 Разработка интерфейса пользователя

3.4 Разработка форм входных и выходных данных

3.5 Тестирование программных средств

3.6 Разработка сопроводительных документов

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЯ



ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

Решение задач посредством СУБД приводит к созданию информационных систем (ИС).

По сферам применения различают два основных класса ИС: информационно-поисковые системы (ИПС) и системы обработки данных (СОД).

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

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

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

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

· определить участников событий и пересечение их интересов;

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

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

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

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

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



ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ ПОСТАВЛЕННОЙ ЗАДАЧИ

1.1 Общая характеристика предметной области и анализ объекта исследования

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

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

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

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

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

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

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

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

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

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

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

· работник предприятия - лицо, которое может просматривать информацию о деятельности предприятия, личные данные работников и т.п.

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

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

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

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



1.2 Постановка и развернутое описание решаемой задачи

инфологический графический интерфейс программный

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

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

2. Разработать логическую схему базы данных;

3. Разработать специфическую для системы управления реляционными базами данных (СУРБД) MicrosoftAccess структуру базы данных;

4. Разработать реляционную базу данных автомобилестроительного предприятия в СУРБД MicrosoftAccess в соответствии с разработанной структурой;

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

6. Реализовать функции добавления, удаления и редактирования базы данных через графический интерфейс пользователя;

7. Реализовать функцию выполнения SQL-запросов, вводимых пользователем, а также функции сортировки и фильтрации.

1.3 Исследование потоков данных

В приложении базы данных потоки данных можно разделить на 2 типа.

Первый тип -- данные, которые были введены непосредственно в БД. Можно сказать, что такие данные не изменяются в процессе пользования проектом. Это, например, данные, используемые SQL-запросами, формы поиска и т.д.

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

Второй тип потоков данных -- данные, непосредственно введенные в базу данных в процессе ее редактирования.

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

1.4 Перечень задач, подлежащих решению

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

Разработка концептуальной модели локальной базы данных;

Разработка проекта СУБД в соответствии с техническим заданием;

Реализация проекта и разработка технической документации.

На стадии разработки концептуальной модели базы данных необходимо выполнить следующие этапы:

· определение цели создания ИИС;

· установление состава пользователей БД;

· разработка концептуальной модели БД;

· разработка технического задания на проектирование локальных СУБД;

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

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

· поставка материалов и комплектующих изделий;

· проектирование конструкции новых изделий;

· проектирование технологических процессов изготовления продукции;

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

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

· разработка нормативной базы (потребность в трудовых и материальных ресурсах, основных и вспомогательных материалах и др.);

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

· управление сбытом и др.

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

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

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

· определение месторасположения потенциальных пользователей и, в конечном итоге, определение архитектуры ЛВС.

Конечной задачей разработки концептуальной модели является установление оптимального состава таблиц базы данных. На данном этапе создания многопользовательских баз данных оптимальный состав таблиц определяется сначала исходя из потребностей каждого пользователя ИИС, а затем каждая таблица может быть подвергнута процедуре нормализации. После определения состава таблиц базы данных и состава пользователей ИИС можно приступить к разработке технического задания на проектирование СУБД. В техническом задании необходимо:

· обосновать выбор архитектуры ЛВС и архитектуры баз данных;

· обосновать выбор программной системы для разработки СУБД;

· разработать требования к формам выходных документов, предоставляющих необходимую информацию для каждого пользователя БД;

· разработать требования к созданию пользовательского интерфейса с учетом задач каждого пользователя;

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

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

Для этого целесообразно воспользоваться программной системой управления проектами, например MicrosoftProject.

Применение этой системы целесообразно не только для определения потребности в ресурсах; она позволяет эффективно руководить всем ходом выполнения работ по проектированию СУБД.

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

На стадии разработки проекта СУБД в соответствии с техническим заданием необходимо выполнить следующие задачи:

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

Разработка оптимального состава и структуры таблиц базы данных;

Установление логических связей между таблицами;

Разработка необходимого числа запросов для реализации поставленной задачи;

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

Разработка форм пользовательского интерфейса;

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

Реализация проекта разработанной СУБД сводится к следующим задачам:

· заполнение таблиц баз данных информацией об объектах;

· проверка функционирования СУБД при выполнении поставленных задач;

· разработка инструкций для пользователей;

· сдача системы заказчику.

1.5 Средства решения поставленной задачи

Для решения поставленной задачи использовалась программа из пакета приложений MicrosoftOfficeпод названием MicrosoftOfficeAccess, или просто MicrosoftAccess.

MicrosoftAccess -- реляционная система управления базами данных корпорации (СУРБД) от компании Microsoft. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VisualBasicforApplications (VBA), в самой среде Access можно писать приложения, работающие с базами данных. MicrosoftAccess-- мощная СУБД, включающая сотни инструментов, которые интуитивно понятны и позволяют быстро начать работу. В распоряжении пользователей - обширная библиотека профессионально созданных шаблонов приложений, мастера, облегчающие процесс создания таблиц, форм, запросов и отчетов, а также множество справочных ресурсов. Также Access предоставляет функцию использования данных, находящихся в других местах, включая программы пакета MicrosoftOffice, SQL Server, SharePointServices и документы XML, HTML, XPS и PDF.

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

Еще одним дополнительным достоинством Access является интеграция с Excel, Word и другими программами пакета Office. Данные, созданные в разных приложениях, входящих в этот пакет, легко импортируются и экспортируются из одного приложения в другое.

Для реализации запросов к таблицам базы данных применялся язык SQL (StructuredQueryLanguage - «структурированный язык запросов»).

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

В начале 70-х годов в компании IBM была разработана экспериментальная СУБД System R на основе языка SEQUEL (StructuredEnglish QUEryLanguage -«структурированный английский язык запросов»), который можно считать непосредственным предшественником SQL. Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. В 1981 году IBM объявила о своем первом программном продукте, основанном на SQL, - SQL/DS. Чуть позже к ней присоединилась компания Oracle, а также другие производители. Первый стандарт языка SQL был принят Американским национальным институтом стандартизации (ANSI) в 1987 (так называемый SQL level 1) и несколько уточнен в 1989 году (SQL level 2). Дальнейшее развитие языка поставщиками СУБД потребовало принятия в 1992 нового расширенного стандарта (ANSI SQL-92 или просто SQL-2). В настоящее время ведется работа по подготовке третьего стандарта SQL, который должен включать элементы объектно-ориентированного доступа к данным.

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

В SQL определены два подмножества языка:

· SQL-DDL (DataDefinitionLanguage) - язык определения структур и ограничений целостности баз данных. Сюда относятся команды создания и удаления баз данных; создания, изменения и удаления таблиц; управления пользователями и т.д.

· SQL-DML (DataManipulationLanguage) - язык манипулирования данными: добавление, изменение, удаление и извлечение данных, управления транзакциями.

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

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

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

Следует также отметить, что в отличие от «теоретической» терминологии, используемой при описании реляционной модели (отношение, атрибут, кортеж), в литературе при описании SQL часто используется терминология «практическая» (таблица, столбец, строка соответственно).

Java -- объектно-ориентированный язык программирования, разработанный компанией SunMicrosystems (в последующем приобретенной компанией Oracle). Приложения Java обычно компилируются в специальный байт-код, поэтому они могут работать на любой виртуальной Java-машине (JVM) вне зависимости от компьютерной архитектуры. Дата официального выпуска - 23 мая 1995 года. Программы на Java транслируются в байт-код, выполняемый виртуальной машиной Java (JVM) -- программой, обрабатывающей байтовый код и передающей инструкции оборудованию как интерпретатор.

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

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

· применение технологии трансляции байт-кода в машинный код непосредственно во время работы программы (JIT-технология) с возможностью сохранения версий класса в машинном коде;

· широкое использование платформенно-ориентированного (native) кода в стандартных библиотеках;

· аппаратные средства, обеспечивающие ускоренную обработку байт-кода (например, технология Jazelle, поддерживаемая некоторыми процессорами фирмы ARM).

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

Внутри Java существуют несколько основных семейств технологий:

· Java SE -- JavaStandardEdition, основное издание Java, содержит компиляторы, API, JavaRuntimeEnvironment; подходит для создания пользовательских приложений, в первую очередь -- для настольных систем;

· Java EE -- JavaEnterpriseEdition, представляет собой набор спецификаций для создания программного обеспечения уровня предприятия;

· Java ME -- JavaMicroEdition, создана для использования в устройствах, ограниченных по вычислительной мощности, например в мобильных телефонах, КПК, встроенных системах;

· JavaFX -- технология, являющаяся следующим шагом в эволюции Java как RichClientPlatform; предназначена для создания графических интерфейсов корпоративных приложений и бизнеса;

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

Язык Java активно используется для создания мобильных приложений для операционной системыAndroid. При этом программы компилируются в нестандартный байт-код, для использования их виртуальной машиной Dalvik. Для такой компиляции используется дополнительный инструмент, а именно SoftwareDevelopmentKit, который предназначен для x86-машины под операционной системой Linux. Его разработали представители компании Google.

Следующие успешные проекты реализованы с привлечением Java (J2EE) технологий: RuneScape, Amazon, eBay,Yahoo!, LinkedIn.

Следующие компании в основном фокусируются на Java (J2EE) технологиях: SAP, IBM, Oracle. В частности, СУБД Oracle включает JVM как свою составную часть, обеспечивающую возможность непосредственного программирования СУБД на языке Java, включая, например, хранимые процедуры.

Программы, написанные на Java, имеют репутацию более медленных и занимающих больше оперативной памяти, чем написанные на языке Си. Тем не менее, скорость выполнения программ, написанных на языке Java, была существенно улучшена с выпуском в 1997--1998 годах так называемого JIT-компилятора в версии 1.1 в дополнение к другим особенностям языка для поддержки лучшего анализа кода (такие как внутренние классы, упрощенные логические вычисления и т. д.). Кроме того была произведена оптимизация виртуальной машины Java -- с 2000 года для этого используется виртуальная машина HotSpot. По состоянию на февраль 2012 года, код Java 7 приблизительно лишь в 1.8 раза медленнее кода, написанного на языке Cи.



ГЛАВА 2. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОЕКТА БАЗЫ ДАННЫХ

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

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

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

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

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

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

Схема 1 - Трехуровневая модель ANSI/SPARC

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

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

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

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

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

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

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

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

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

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

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

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ	Представление аналитика
сущности атрибуты связи
ЛОГИЧЕСКИЙ УРОВЕНЬ	Представление программиста
записи элементы данных связи между записями
ФИЗИЧЕСКИЙ УРОВЕНЬ	Представление администратора
индексы методы доступа группирование данных

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

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

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

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



2.2 Определение логической структуры реляционной базы данных

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

Таблица 2 - Функциональные зависимости атрибутов

Документ	Наименование реквизита	Обозначение реквизита	Функциональные зависимости
Автомобиле-строительное предприятие	Персонал Код работника Фамилия Имя Отчество Цех Должность Специализация Квалификация Производство Код изделия Тип изделия Цех Объем партии Стадия изготовления Испытания Продукция Код продукции Тип продукции Количество на складе Цена за единицу	Персонал Код_раб Фамилия Имя Отчество Цех Должность Специализация Квалификация Производство Код_изд Тип_изд Цех Объем_партии Стадия_изготов Испытания Продукция Код_прод Тип_прод На_складе Цена



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

2.3 Нормализация проекта базы данных

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

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

· исключение некоторых типов избыточности;

· устранение некоторых аномалий обновления;

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

· упрощение процедуры применения необходимых ограничений целостности.

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

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

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

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

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

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

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

3. Третья нормальная форма (3НФ). Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме и отсутствуют транзитивные функциональные зависимости не ключевых атрибутов от ключевых.

4. Четвертая нормальная форма (4НФ). Переменная отношения находится в четвертой нормальной форме, если она находится в нормальной форме Бойса-Кодда и не содержит нетривиальных многозначных зависимостей.

5. Пятая нормальная форма (5НФ). Переменная отношения находится в пятой нормальной форме (иначе - в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.

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

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

Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.

7. Шестая нормальная форма (6НФ).Введена К.Дейтом в его книге как обобщение пятой нормальной формы для темпоральной базы данных. Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Иными словами, переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.

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

Также БД находится и во второй нормальной форме, т.к. она находится в первой нормальной форме, а каждый неключевой атрибут таблицы функционально полно зависит от ключа этой таблицы. Например, значение атрибута Фамилия в таблице Персонал полностью зависит от ключа этой таблицы Код_раб. Таким образом, база данных автомобилестроительного предприятия представлена во второй нормальной форме, что гарантирует достаточную производительность выполнения SQL-запросов и целостность данных при модификации таблиц посредством графического интерфейса.



2.4 Реализация проекта базы данных в среде СУБД

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

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

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

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

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

Персонал Производство

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

Продукция

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

Схема 3 - Описание атрибутов и типов данных



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

2.5 Реализация защиты базы данных

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

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

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

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

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

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

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

При работе в многопользовательской среде большое значение приобретает понятие «пользователь базы данных» - владелец определенного набора объектов БД.

Пользователи системы могут быть разделены на классы. В системе любого размера всегда имеются суперпользователи- пользователи, которые автоматически имеют большинство (или все) привилегий и могут передать свой статус суперпользователя кому-нибудь с помощью привилегии или группы привилегий. Для обозначения пользователя, имеющего такие привилегии, чаще всего используется термин «администратор базы данных».

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

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

Процесс управления пользователями можно разбить на три главных этапа:

· сначала необходимо создать учетную запись пользователя в БД;

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

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

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

С БД могут работать многие пользователи. Однако не всем пользователям следует разрешать выполнять любые действия. Поэтому пользователям предоставляются привилегии. Привилегия -это право пользователей на выполнение определенных операций над объектами некоторого типа.

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

· системные привилегии;

· объектные привилегии.

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

Объектные привилегии связаны с конкретным объектом БД. Объектная привилегия логически состоит из трех частей:

· объект, к которому применяется привилегия;

· разрешенные привилегией операции;

· пользователь, которому дана привилегия.

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

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

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

· разрешение выполнять запросы в таблице;

· разрешение выполнять вставку новой строки в таблице;

· разрешение выполнять обновление значений полей в таблице;

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

· разрешение определить внешний ключ.

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

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

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

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



ГЛАВА 3. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОГРАММНОЙ ЧАСТИ ПРОЕКТА

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

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

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

Начиная с версии Java 1.2, датированной 1998 годом, Swing входит в состав JavaRuntimeEnvironment.

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

Структура переходов между вкладками в разработанном проекте отображена на схеме 4.



Схема 4 - Структура вкладок в программном проекте

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

3.2 Разработка и описание алгоритмов

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

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

bFilter.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {

if (! filterFlag) {

String field = cbSortFilter.getSelectedItem().toString();

sql = "select * from " + TABLE_NAME + " where " + field + " " + tfFilter.getText() + " order by " + field + " ";

if (rbSortAsc.isSelected()) {

sql += "asc";

} else {

sql += "desc";

};

try {

state.execute(sql);

rs = state.getResultSet();

createTable();

filterFlag = true;

bFilter.setText("<html><h3><center>Снять фильтр</center></h3></html>");

bAddRow.setEnabled(! filterFlag);

bRemoveRow.setEnabled(! filterFlag);

bSaveRow.setEnabled(! filterFlag);

bSort.setEnabled(! filterFlag);

bCustomSQL.setEnabled(! filterFlag);

table.setRowSelectionInterval(0, 0);

} catch (SQLException ex) {

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

}

} else {

sql = "select * from " + TABLE_NAME + " order by Код_раб";

try {

state.execute(sql);

rs = state.getResultSet();

createTable();

filterFlag = false;

bFilter.setText("<html><h3>Фильтровать</h3></html>");

bAddRow.setEnabled(! filterFlag);

bRemoveRow.setEnabled(! filterFlag);

bSaveRow.setEnabled(! filterFlag);

bSort.setEnabled(! filterFlag);

bCustomSQL.setEnabled(! filterFlag);

table.setRowSelectionInterval(0, 0);