Проектирование автоматизированного рабочего места

1. сделать ввод информации простым и понятным для пользователя приложения;
2. быстро находить в базе данных требуемую информацию;
3. хранить данные в виде, который не приведет к чрезмерному разрастанию базы данных;
4. упростить разработку и сопровождение программного обеспечения.
5. Таким образом, основной целью процесса проектирования БД состоит в получении такого проекта, который будет удовлетворять требованиям:
6. корректность схемы БД;
7. обеспечение ограничений (на объемы внешней памяти и другие ресурсы вычислительной системы);
8. эффективность функционирования (соблюдение ограничений на время реакции системы на запрос и обновление данных);
9. защита данных (от аппаратных и программных сбоев и несанкционированного доступа);
10. простота и удобство эксплуатации;
11. гибкость, т.е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей.

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

 

Рис.2.2 Этапы проектирования БД

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

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

Рассмотрим основные подходы к созданию инфологической модели предметной области:

1. функциональный подход к проектированию БД. Этот метод реализует принцип «от задач» и применяется тогда, когда известны функции некоторой группы лиц или комплекса задач, для обслуживания информационных потребностей которых создается рассматриваемая БД.
2. предметный подход к проектированию БД. Этот метод применяется в тех случаях, когда у разработчиков есть четкое представление о самой ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена.
3. проектирование с использованием метода «сущность – связь». Метод «сущность – связь» является комбинацией двух предыдущих и обладает достоинствами обоих.

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

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

Сущность – это  объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, «Сотрудники» или «Автомобиль»), так и абстрактные (например, «Экзамен» или «Диагноз»).

Для сущностей различают  тип сущности и экземпляр. Тип  характеризуется именем и списком  свойств, а экземпляр конкретными  значениями свойств.

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

Для каждой сущности выбираются свойства (атрибуты).

1. Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
2. Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
3. Однозначные и многозначные атрибуты (могут иметь соответственно одно или несколько значений для каждого экземпляра сущности).
4. Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).

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

1. тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям рассматриваемой предметной области;
2. характеристики производительности системы;
3. запас функциональных возможностей для дальнейшего развития ИС;
4. степень оснащенности системы инструментарием для персонала администрирования данными;
5. удобство и надежность СУБД в эксплуатации;
6. стоимость СУБД и дополнительного программного обеспечения.

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

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

Физическое проектирование БД – данный этап заключается в связывании логической структуры БД и физической среды хранения для наиболее эффективного размещения данных. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам «физической» БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL). Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.

Одной их важнейших составляющих проекта базы данных является разработка средств защиты БД. Защита данных имеет  два аспекта: защита от сбоев и  защита от несанкционированного доступа. Для защиты от сбоев разрабатывается стратегия резервного копирования. Для защиты от несанкционированного доступа каждому пользователю доступ к данным предоставляется только в соответствии с его правами доступа.[12]

 

 

5. Общее описание базы данных реализованной системы

 

2.5.1 Описание предметной области

 

В качестве предметной области  выбран склад завода мобильных зданий «Сава-сервис».

Целью данной дипломной  работы является проектирование автоматизированного рабочего места (АРМ). В качестве предметной области выбрано складское помещение завода «Сава-сервис».

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

Функции заведующего складом состоят в следующем.

1. Учёт поступающих и расходуемых деталей.
2. Учёт готовой продукции.
3. Создание входящих и выходящих документов.

Исходя из этого, для автоматизации процесса учета и движения товара по заводу была создана АРМ «Сава-сервис». Разработанное приложение предоставляет возможность заведующему складом повысить производительность труда при выполнении повторяющихся операций по обработке информации: регистрации поступившего товара; учету товара на складе; учету движения товара на заводе. Позволяет ускорить и качественно улучшить процесс движения товара по заводу.

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

 

2.5.2 Технические требования

 

Минимальные технические  требования к конфигурации рабочих  станций работающих с автоматизированной информационной системой «Сава-сервис»:

Требования к оборудованию:

• процессор Pentium 166 МГц;
• оперативной памяти 32 МБ;
• свободного места на жестком диске 350 МБ;

Требования к программному обеспечению:

• операционная система Microsoft Windows Me/2000/XP.

 

 

 

 

 

 

 

 

2.5.3 Описание структуры БД

 

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

Сущности:

1. Склад;
2. Запас;
3. Фирма;
4. Агент;
5. Приходная накладная;
6. Расходная накладная.

Атрибуты сущностей  представлены в таблице 2.2.

Пометка РК рядом с  атрибутом значит, что атрибут  является первичным ключом (Primary Key), а FK означает, что атрибут является внешним ключом (Foreign Key).

 

Таблица 2.2

Описание таблиц

Сущность	Атрибуты сущности
1	2
Склад	1. Код_т (РК)
	2. Наим_т
	3. Ст_ед
	4. Инвентарный номер
1	2
Запас	1. Код_т (РК)
	2. Кол_во
	3. Ед_из
	4. Испорчено
Фирма	1. Код_ф (РК)
	2. Наим_ф
	3. ИНН
	4. Улица
	5. Дом
	6. Телефон
Агент	1. Код_аг (РК)
	2. Фамилия
	3. Имя
	4. Отчество
Приходная накладная	1. Ном_пнак (РК)
	2. Код_пост
	3. Код_ф
	4. Код_т
	5. Дата получения
	6. Получено
	7. Статус
Расходная накладная	1. Ном_рнакл (РК)
	2. Код_зак
	3. Код_ф
	4. Код_т
	5. Дата выдачи
	6. Выдано
	7. Статус

 

Рис.2.3 Инфологическая модель базы данных

 

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

База данных состоит  из 6 таблиц.

Описание таблиц:

Таблица «Склад» содержит информацию о запчастях хранящихся на складе. Модель таблицы приведена в таблице 2.3.

 

 

 

Таблица 2.3

Склад