Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Информационная система "Учёт комплектующих и ремонта оборудования"

Информационная система "Учёт комплектующих и ремонта оборудования"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 27.12.2012
Размер файла 2,6 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

1

80

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

Содержание

Введение

1 Постановка задачи

2 Теоретические основы баз данных и СУБД

2.1 Общие понятия баз данных и СУБД

2.2 Реляционная модель данных

2.3 Архитектура СУБД

2.4 Методология проектирования

3 Проектирование БД

3.1 Семантический анализ

3.2 Логическое проектирование. ER-диаграммы

3.2.1 Проектирование БД с помощью программы Erwin

3.2.2 Нормализация БД

3.3 Физическое проектирование. Выбор сервера

3.3.1 Создание базы данных «Учёт комплектующих и ремонта оборудования» на сервере InterBase

4 Структура и функциональные возможности информационной системы

4.1 Выбор инструментальной среды (реализация информационной системы)

4.2 Структура программной системы

5 Тестирование системы

Заключение

Список, используемой литературы

Приложение А

Приложение Б. Руководство пользователя/администратора ИС «Учёт комплектующих и ремонта оборудования»

Введение

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

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

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

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

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

В данной дипломной работе проведена разработка информационной системы «Учет комплектующих и ремонта оборудования».

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

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

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

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

Повысить общую производительность системы;

Снизить стоимость аппаратного обеспечения и коммуникационные расходы;

Повысить уровень непротиворечивости данных.

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

В качестве серверной части использовалась СУБД Borland Interbase 6.5 Server Edition для одного пользователя, работающую под управлением Windows. Выбор именно этого сервера обусловлен следующими фактами:

· Поддерживает архитектуру клиент-сервер.

· Поддерживает процедурное расширение языка SQL.

· Не сложен в установке и настройке.

· Компактен.

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

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

Она имеет встроенную поддержку языка структурированных запросов (SQL).

Delphi - язык и среда программирования, относящаяся к классу RAD- (Rapid Application Development _ «Средство быстрой разработки приложений») средств CASE - технологии.

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

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

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

база данные информационный программный

1. Постановка задачи

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

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

паспортизация и учёт оборудования предприятия;

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

учет движения внутри производства (передача оборудования в другие подразделения);

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

учет и планирование проведения ремонтных работ.

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

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

2. Теоретические основы баз данных и СУБД

2.1 Общие понятия баз данных и СУБД

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

Формально можно дать другое определение:

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

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

Таблица 1 - Преимущества и недостатки СУБД

Преимущества систем управления базами данных

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

Контроль над избыточностью данных

Непротиворечивость данных

Больше полезной информации при том же объёме хранимых данных

Совместное использование данных

Поддержка целостности данных

Повышенная безопасность

Применение стандартов

Повышение эффективности с ростом масштабов системы

Возможность нахождения компромисса при противоречивых требованиях

Повышение доступности данных и их готовности к работе

Улучшение показателей производительности

Упрощение сопровождения системы за счёт независимости от данных

Улучшенное управление параллельной работой

Развитые службы резервного копирования и восстановления

Сложность

Размер

Стоимость СУБД

Дополнительные затраты на аппаратное обеспечение

Затраты на преобразование

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

Более серьёзные последствия при выходе системы из строя

Доступ к БД осуществляется с помощью СУБД. Для этого предусмотрен язык определения данных(Data Definition Language - DDL), с помощью которого пользователи могут определять структуру БД, а также язык управления данными(Data Manipulation Language - DML), с помощью которого пользователи могут вставлять, удалять и извлекать данные из базы.

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

В любой полномасштабной СУБД должны быть реализованы следующие службы, предложенные в своё время Коддом:

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

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

Системный каталог является одним из фундаментальных компонентов СУБД. Он содержит “данные о данных”, или метаданные. Каталог должен быть доступен пользователям. Служба IRDS (Information Resource Dictionary System)- это новый стандарт ISO, который определяет методы доступа к словарю данных. При этом допускается их совместное использование и передача из одной системы в другую.

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

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

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

5. Службы восстановления. СУБД должна предоставлять средства обновления базы данных на случай какого-либо ее повреждения или разрушения.

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

7. Поддержка обмена данными. СУБД должна обладать способностью к интеграции с коммуникационным программным обеспечением.

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

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

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

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

Ш Первое поколение:

1. Иерархическая модель.

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

Ш Третье поколение:

1.Объектно-реляционные СУБД.

2.Объектно-ориентированные СУБД.

В настоящее время самым распространённым программным обеспечением обработки данных являются реляционные СУБД[1,2].

2.2 Реляционная модель данных

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

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

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

Доктор И.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «12 правилами Кодда», требует введения сложной терминологии и выходит за рамки дипломной работы. Тем не менее, можно назвать некоторые правила Кодда для реляционных систем. Чтобы считаться реляционной по Кодду, система управления базами данных должна:

Представлять всю информацию в виде таблиц.

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

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

Поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение.

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

Различать в таблицах неопределенные значения (nulls), нулевые значения и пропуски в данных.

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

Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица.

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

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

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

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

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

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

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

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

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

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

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

2.3 Архитектура СУБД

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

При реализации многопользовательских СУБД используются следующие типовые архитектурные решения:

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

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

Достоинство архитектуры «файл - сервер» - обеспечение высокого уровня защиты данных от несанкционированного доступа. Недостатки архитектуры «файл-сервер»:

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

ь перегрузка трафика сети;

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

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

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

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

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

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

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

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

Эта архитектура весьма естественно отображается на архитектуру открытых систем.

Трехуровневая архитектура.

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

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

* Значительные накладные расходы на администрирование клиентской части приложений.

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

1. Уровень пользовательского интерфейса, который располагается на компьютере конечного пользователя (клиент).

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

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

Как показано на рисунке 1 , клиент отвечает только за пользовательский интерфейс и, возможно, выполняет некоторую очень простую обработку данных, например, проверку введенной информации, поэтому клиентская часть приложения может быть построена с использованием так называемого «тонкого» клиента. Основные прикладные алгоритмы теперь реализованы на отдельном уровне - на сервере приложений, который физически связан с клиентом и сервером базы данных посредством локальной (Local Area Network-LAN) или распределенной (Wide Area Network - WAN) вычислительной сети. При этом предполагается, что один сервер приложений может обслуживать множество клиентов.

Рисунок 1 - Трехуровневая архитектура

Трехуровневая архитектура имеет многие преимущества перед одно- и двух - уровневыми моделями. Ниже перечислены некоторые из них.

§ «Тонкий» клиент, для которого требуется менее дорогостоящее аппаратное обеспечение.

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

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

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

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

Такая архитектура применяется также в сочетание с мониторами обработки транзакций.

Мониторы обработки транзакций (ТР). Программа, которая управляет обменом данных между клиентами и серверами для создания единообразной вычислительной среды, которая требуется, в частности, для оперативной обработки транзакций (Oh-Line Transaction Processing - OLTP). Применение ТР - мониторов обеспечивает значительные преимущества: маршрутизацию транзакций, поддержку распределенных транзакций, уравновешивание нагрузки, мультиплексирование соединений и повышение надежности[1].

2.4 Методология проектирования

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

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

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

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

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

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

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

Процедура разработки БД включает в себя следующие этапы:

I Концептуальное проектирование базы данных

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

2. Определение типов сущностей.

3. Определение типов связей.

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

5. Определение доменов атрибутов.

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

7. Обоснование необходимости использования понятий расширенного моделирования.

8. Проверка модели на отсутствие избыточности.

9. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

II Логическое проектирование базы данных (для реляционной модели)

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

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

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

4. Проверка отношений с помощью правил нормализации.

5. Проверка соответствия отношений требованиям пользовательских транзакций.

6. Определение требований поддержки целостности данных.

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

8. Создание и проверка глобальной логической модели данных.

9. Слияние локальных логических моделей данных в единую глобальную модель данных.

10. Проверка глобальной логической модели данных.

11. Проверка возможностей расширения модели в будущем.

12. Обсуждение глобальной логической модели данных с пользователем.

III Физическое проектирование базы данных (с использованием реляционной СУБД)

1. Перенос глобальной логической модели данных в среду целевой СУБД.

2. Проектирование базовых отношений в среде целевой СУБД.

3. Проектирование отношений, содержащих производные данные.

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

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

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

9. Определение требований к дисковой памяти.

10. Разработка пользовательских представлений.

11. Разработка механизмов защиты.

12. Анализ необходимости введения контролируемой избыточности.

13. Организация мониторинга и настройка функционирования операционной системы[2].

3. Проектирование БД

3.1 Семантический анализ

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

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

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

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

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

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

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

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

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

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

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

1

80

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

Рисунок 2 - Типы ремонтно-технического обслуживания

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

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

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

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

o уникальный шифр (код) оборудования;

o инвентарный номер оборудования;

o подразделение, в котором установлено оборудование;

o местоположение оборудования в подразделении;

o изготовитель;

o дата производства;

o дата ввода в эксплуатацию;

o дата последнего капитального ремонта;

o дата последнего технического обслуживания.

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

3.2 Логическое проектирование. ER-диаграммы

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

o Из каких отношений должна состоять база данных;

o Какие атрибуты должны быть у этих отношений;

o Какие ограничения должны быть наложены на атрибуты и отношения базы данных, чтобы обеспечить её целостность.

Реляционная модель сама по себе не удобна для работы при проектировании базы данных. Вместо неё используются различные семантические модели, наиболее распространённой из которых является ER -модель или модель «сущность-связь». Основными компонентами ER -модели являются:

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

E Связь - ассоциация двух или более сущностей.

E Атрибут - именованная характеристика сущности.

Существуют различные стандартные методологии разработки диаграмм «сущность-связь», например, IDEFIX, IE, DM, в каждой из которых принята своя нотация для изображения сущностей и связей. Метод IDEF1, разработанный Т. Рэмей (T.Ramey), основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE- средств, в частности, ERwin.

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

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

Рисунок 3 - . Атрибуты и первичные ключи

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

Согласно задачам, поставленным перед дипломной работой, проект информационной системы должен быть подготовлен с использованием программной системы ERWin.

Выбор инструмента не случаен, так как на нынешний момент ERWin является наиболее мощным средством для разработки структуры данных, как на логическом, так и на физическом уровне[4].

3.2.1 Проектирование БД с помощью программы ERWin

Начиная разработку ER-диаграммы, необходимо определить её некоторые общие свойства, такие как Name, Author,Target Server и Version.

Для удобства разработки у диаграммы были определены два отображения (Format=> Stored Display Setting… =>New…): режим сущностей и режим атрибутов с разной степенью детализации. Для перехода из режима сущностей в режим атрибутов достаточно щёлкнуть по соответствующей закладке в нижней части схемы (рисунок 4).

Рисунок 4 - Закладки хранимых отображений

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

Таблица 2 - Сущности объектной области

Сущность

Атрибут

Ключ

Имя домена

Тип

логическое физическое

Справочник типов оборудования

тип

код типа оборудования

t_tip_obor_id

число

наименование

наименование типа оборудования

t_tip_obor_name

строка

Справочник оборудования

оборудование

код оборудования

t_obor_id

число

наименование

наименование оборудования

t_obor_name

строка

тип

код типа оборудования

t_tip_obor_id

число

Справочник подразделений

подразделение

код подразделения

t_podrazdelenie_id

число

наименование

наименование подразделения

t_podrazdelenie_name

строка

краткое наименование

краткое наименование подразделения

t_podrazd_short_name

строка

телефон

телефон подразделения

t_telephone

число

адрес

адрес подразделения

t_adress

строка

Оборудование _Подразделения

подразделение

код подразделения

t_podrazdelenie_id

число

инвентарный номер

инвентарный номер оборудования

t_obor_invent_id

число

оборудование

код оборудования

t_obor_id

число

дата производства

дата производства оборудования

t_production_ date

дата

дата ввода в эксплуатацию

дата ввода в эксплуатацию оборудования

t_vvod_v_exsp_date

дата

дата последнего капремонта

дата последнего капремонта оборудования

t_kaprem_last_date

дата

дата последнего тех. обслуживания

дата последнего тех. обслуживания оборудования

t_TO_last_date

дата

местоположение

местоположение оборудования

t_mestopologenie

строка

изготовитель

код изготовителя

t_izgotovitel_id

число

Изготовитель

изготовитель

код изготовителя

t_izgotovitel_id

число

наименование

наименование изготовителя

t_izgotovitel_ name

строка

Оборудование _Обслуживание

инвентарный номер

инвентарный номер оборудования

t_obor_invent_id

число

подразделение

код подразделения

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены