Разработка АРМ для авиаоператора

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

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

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

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

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

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

Дипломный проект

Разработка АРМ для авиаоператора

Оглавление

  • Введение
  • Глава 1. Анализ предметной области и средств разработки
    • 1.1 Описание предметной области
    • 1.2 Анализ аппаратных и программных средств для разработки программного продукта
    • 1.3 Техническое задание
  • Глава 2. Разработка АРМ авиаоператора
    • 2.1 Моделирование предметной области
    • 2.2 Физическая реализация базы данных
    • 2.3 Тестирование программного продукта
    • 2.4 Инструкция пользователя
      • 2.4.1 Краткое описание возможностей
      • 2.4.2 Уровень подготовки пользователя
      • 2.4.3 Порядок загрузки данных и проверка работоспособности
      • 2.4.4 Описание операций выполняемых информационной системой
  • Заключение
  • Список использованных источников
  • Приложение

Введение

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

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

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

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

Цель - разработать АРМ для авиаоператора.

Задачи:

Описать предметную область.

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

Разработать техническое задание.

Построить модели предметной области.

Реализовать физическую схему базы данных.

Протестировать программный продукт.

Разработать инструкцию пользователя.

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

Глава 1. Анализ предметной области и средств разработки

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

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

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

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

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

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

Таким образом, основными задачами, стоящими перед проектируемой БД, являются:

1. В системе должна быть функция регистрации пассажира.

2. Система должна предоставлять данные об имеющихся рейсах.

3. Данные в системе должны регулярно обновляться.

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

5. Система должна сопоставлять расписание с фактическими вылетами самолетов по различным направлениям.

6. Интерфейс должен быть доступным и понятным пользователю.

7. К системе должно быть разработана инструкция для пользователя.

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

ѕ блокировка БД, файла, записи;

ѕ идентификация станции, установившей блокировку;

ѕ обновление информации после блокировки;

ѕ контроль за временем и повторением обращения;

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

Кроме того СУБД MS Access входит в пакет программ Microsoft Office, и имеет хорошо организованные связи с такими программами как Excel, Word. Данное взаимодействие обеспечивает потенциальную возможность увеличения функциональных способностей MS Access. Наличие в составе MS Access языка программирования высокого уровня VisualBasic позволяет создавать макрокоманды и процедуры для более гибкого обращения с данными.

В настоящее время MS Access является признанным стандартом для создания и ведения сравнительно малых БД. Он позволяет импортировать в свой формат большинство файлов БД реляционного типа и экспортировать их далее. Обладает удобным для пользователя - непрограммиста интерфейсом и ведёт развёрнутый диалог с комментариями. MS Access обладает высокими характеристиками производительности, предоставляет своим пользователям достаточно широкие функциональные возможности для реализации потребностей и дальнейшего развития ИС. [9]

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

В состав комплекса должны следующие технические средства:

- Серверы БД;

- ПК пользователей;

- ПК администраторов.

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

Серверы БД, серверы приложений и сервер системы формирования отчетности должны быть объединены одной локальной сетью, с пропускной способностью не менее 100 Мбит.

Требования к техническим характеристикам серверов БД:

- процессор - 2 х Intel Xeon 3 ГГц;

- объем оперативной памяти - 16 Гб;

- дисковая подсистема - 4 х 146 Гб;

- устройство чтения компакт-дисков (DVD-ROM);

- сетевой адаптер - 100 Мбит.

Требования к техническим характеристикам ПК пользователя и ПК администратора:

- процессор - Intel Pentium 1.5 ГГц;

- объем оперативной памяти - 256 Мб;

- дисковая подсистема - 40 Гб;

- устройство чтения компакт-дисков (DVD-ROM);

- сетевой адаптер - 100 Мбит.

База данных - это единое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями.

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

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

В MS Access в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных на уровне ядра (что предотвращает несовместимые операции обновления или удаления данных). Кроме того, таблицы в Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. MS Access поддерживает все необходимые типы полей, в том числе текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Если в процессе специальной обработки в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.[8]

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

Таким образом, примем во внимание, что разрабатываемая база данных физически реализована в Microsoft Office 2010, поэтому, минимальные системные требования, которые устанавливает фирма производитель для Microsoft Access следующие:

ѕ операционная система: Microsoft Windows XP Professional с пакетом обновлений 3 (SP3) 3 или более поздняя версия;

ѕ процессор: Pentium III 500 MHz и выше; 1 гигагерц (ГГц), необходимых для Outlook с диспетчером контактов.

ѕ память: 256 MB RAM (минимум); 512 МБ, рекомендуется для графических возможностей, мгновенного поиска Outlook, коммуникатор и некоторые расширенные функции.

ѕ дисковое пространство: 2 гигабайта (ГБ) свободного места на диске, часть этого объема будет освобождена после установки, когда исходный установочный файл будет удален.

ѕ дисплей: Super VGA (1024 Ч 768) или более высокое разрешением.

ѕ указывающее устройство: Microsoft Mouse, Microsoft IntelliMouse или совместимое указывающее устройство.

ѕ доступ к сети Интернет: если загрузка компонентов Microsoft Office 2010 проводится через Интернет, для успешной активации МАК-ключом потребуется широкополосное подключение, обеспечивающее скорость передачи данных 128 Кбит/с и выше..

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

1.3 Техническое задание

Исходным документом для создания АРМ авиаоператора является Техническое задание (ТЗ), которое позволяет:

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

ѕ заказчику -- осознать, что именно ему нужно;

ѕ обеим сторонам -- представить готовый продукт;

ѕ исполнителю -- спланировать выполнение проекта и работать по намеченному плану;

ѕ заказчику -- требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;

ѕ исполнителю -- отказаться от выполнения работ, не указанных в ТЗ;

ѕ заказчику и исполнителю -- выполнить попунктную проверку готового продукта (приёмочное тестирование -- проведение испытаний);

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

На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим стандартом техническое задание должно содержать следующие разделы:

1. Введение.

2. Основания для разработки.

3. Назначение разработки.

4. Требования к программе или программному изделию.

5. Требования к программной документации.

6. Технико-экономические показатели.

7. Стадии и этапы разработки.

8. Порядок контроля и приемки.

Настоящее ТЗ распространяется на разработку АРМ авиаоператора предназначенного для сбора и хранения информации о билетах и рейсах. Предполагается, что данная система облегчит работу авиаоператора, повысить оперативность и качество работы.

В приложении 1 представлено техническое задание для создания приложения «АРМ авиаоператора».

В первой главе было рассмотрено описание предметной области, и проведен анализ аппаратных и программных средств, для разработки программного продукта. Так же нами было создано техническое задание, для создания АРМ авиаоператора.

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

Глава 2. Разработка АРМ авиаоператора

2.1 Моделирование предметной области

Для создания модели программного продукта используется нормализация отношений инфологическая и даталогическая модель. [4]

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

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

На рисунке 2.1 представлена разработанная инфологическая модель предметной области «АРМ авиаоператора», содержащая сущности:

1. Багаж.

2. Льготы.

3. Пассажир.

4. Билет.

5. Рейсы.

6. Вылеты.

7. Экипаж.

8. Пилот.

9. Самолет.

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

Рисунок 2.1 - Инфологическая модель предметной области «АРМ авиаоператора»

Нормализация отношений на основе построенной инфологической модели выделяет следующие отношения:

1. Багаж (Код Багажа, Вес, СерНомПаспорта).

2. Льготы (Тип Льгот, Описание, Размер).

3. Пассажир (СерНомПаспорта, ФИО, Тип, Тип Льгот).

4. Билет (Код Билета, Номер места, Цена, Дата вылета, Дата прилета, СерНомПаспорта, Код Рейса).

5. Рейсы (Код Маршрута, Направление, Расстояние, Время вылета, Время прибытия, Код Самолета).

6. Самолет (Код Самолета, Модель, Кол-во мест, Скорость, Высота, КапРемонт).

7. Экипаж (Код Экипажа, Группа доступа).

8. Пилот (Код Пилота, ФИО, Дата рождения, Адрес, Телефон, Код Экипажа).

9. Вылеты (Код Вылета, День вылета, Код Маршрута, Код Экипажа, Код Самолета).

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

Ниже в таблицах 2.1 - 2.9 представлена даталогическая модель предметной области «АРМ авиаоператора».

Таблица 2.1 - Структура таблицы «Багаж»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Багажа

Счетчик

Длинное целое

NOT NULL

+

Вес

Числовой

СерНомПаспорта

Текстовый

50

+

Таблица 2.2 - Структура таблицы «Льготы»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Тип Льгот

Счетчик

Длинное целое

NOT NULL

+

Описание

Поле МЕМО

Размер

Денежный

Процентный

Таблица 2.3 - Структура таблицы «Пассажир»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

СерНомПаспорта

Текстовый

50

NOT NULL

+

ФИО

Текстовый

50

Тип

Текстовый

50

Тип Льгот

Числовой

Длинное целое

+

Таблица 2.4 - Структура таблицы «Билет»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Билета

Счетчик

Длинное целое

NOT NULL

+

Номер места

Числовой

4

Цена

Денежный

Дата вылета

Дата/время

Краткий формат даты

Дата прилета

Дата/время

Краткий формат даты

СерНомПаспорта

Текстовый

50

+

Код Маршрута

Числовой

Длинное целое

+

Таблица 2.5 - Структура таблицы «Рейсы»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Маршрута

Счетчик

Длинное целое

NOT NULL

+

Направление

Текстовый

50

Расстояние

Числовой

Длинное целое

Время вылета

Текстовый

10

Время прилета

Текстовый

10

Код Самолета

Числовой

Длинное целое

+

Таблица 2.6 - Структура таблицы «Самолет»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Самолета

Числовой

Длинное целое

NOT NULL

+

Модель

Текстовый

50

Количество мест

Числовой

Длинное целое

Скорость

Текстовый

5

Высота

Текстовый

15

КапРемонт

Логический

Да/Нет

Таблица 2.7 - Структура таблицы «Экипаж»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Экипажа

Числовой

Длинное целое

NOT NULL

+

Группа доступа

Числовой

Длинное целое

Таблица 2.8 - Структура таблицы «Пилот»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Пилота

Счетчик

Длинное целое

NOT NULL

+

ФИО

Текстовый

50

Дата рождения

Дата/время

Краткий формат даты

Адрес

Текстовый

100

Телефон

Текстовый

10

Код Экипажа

Числовой

Длинное целое

+

Таблица 2.9 - Структура таблицы «Вылеты»

Наименование поля

Тип данных

Длина

Допустимое значение

Первичный ключ

Внешний ключ

Код Вылета

Счетчик

Длинное целое

NOT NULL

+

День вылета

Текстовый

11

Код Самолета

Числовой

Длинное целое

+

Код Маршрута

Числовой

Длинное целое

+

Код Экипажа

Числовой

Длинное целое

+

На основе представленных выше моделей можно перейти к разработке и реализации БД.

2.2 Физическая реализация базы данных

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

Нами была разработана база данных в СУБД MS Access 2010. Структура базы данных следующая:

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

2. Каждая таблица имеет несколько полей.

3. В каждой таблице имеется определенное количество записей.

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

Основные задачи:

1. Обеспечение хранения в БД всей необходимой информации.

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

3. Сокращение избыточности и дублирования данных.

4. Обеспечение целостности базы данных.

Рассмотрим физическую схему реляционной базы данных «АРМ авиаоператора» в MS Access представленную на рисунках 2.2 - 2.13.

Рисунок 2.2 - Таблица «Багаж» в режиме конструктора

Рисунок 2.3 - Столбцы данных таблицы «Багаж»

Рисунок 2.4 - Таблица «Льготы» в режиме конструктора

Рисунок 2.5 - Столбцы данных таблицы «Льготы»

Рисунок 2.6 - Таблица «Пассажиры» в режиме конструктора

Рисунок 2.7 - Столбцы данных таблицы «Пассажиры»

Рисунок 2.8 - Таблица «Билет» в режиме конструктора

Рисунок 2.9 - Столбцы данных таблицы «Билет»

Рисунок 2.10 - Таблица «Рейсы» в режиме конструктора

Рисунок 2.11- Столбцы данных таблицы «Рейсы»

Рисунок 2.12 - Таблица «Самолет» в режиме конструктора

Рисунок 2.13 - Столбцы данных таблицы «Самолеты»

Рисунок 2.14 - Таблица «Экипаж» в режиме конструктора

Рисунок 2.15 - Столбцы данных таблицы «Экипаж»

Рисунок 2.16 - Таблица «Пилот» в режиме конструктора

Рисунок 2.17 - Столбцы данных таблицы «Пилот»

Рисунок 2.18 - Таблица «Вылеты» в режиме конструктора

Рисунок 2.19 - Столбцы данных таблицы «Вылеты»

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

Рисунок 2.20 - Схема данных предметной области «АРМ авиаоператора»

2.3 Тестирование программного продукта

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

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

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

На рисунке 2.21 представлено функциональное тестирование АРМ авиаоператора.

Рисунок 2.23 - Функциональное тестирование АРМ авиаоператора

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

На рисунке 2.22 представлено интеграционное тестирование АРМ авиаоператора.

Рисунок 2.22 - Интеграционное тестирование АРМ авиаоператора

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

На рисунке 2.23 представлено стресс-тестирование АРМ авиаоператора.

Рисунок 2.23 - Стресс-тестирование АРМ авиаоператора

2.4 Инструкция пользователя

2.4.1 Краткое описание возможностей

Для работы с АРМ используется простой, интуитивно понятный интерфейс. Последовательность работ с объектами формы определяется доступностью командных кнопок, АРМ авиаоператора обладает следующими функциями:

1. Просмотр, редактирование, добавление и удаление информации о клиентах, экипаже, самолетах.

2. Поиск необходимой информации.

3. Вывод информации, о количестве купленных билетов.

4. Вывод информации, о количестве вылетов.

2.4.2 Уровень подготовки пользователя

Пользователь, работающий в АРМ должен обладать следующими знаниями:

1. Знать соответствующую предметную область;

2. Иметь основные знания о ПК.

3. Иметь представление о работе с БД.

4. Иметь опыт работы в среде современных операционных систем семейства Microsoft Windows.

5. Иметь опыт работы с современным офисным пакетом Microsoft Office.

ѕ Пользователь обязан изучить настоящее Руководство.

Квалификация пользователя должна позволять:

ѕ формировать отчеты;

ѕ искать необходимую информацию в БД;

ѕ осуществлять анализ данных.

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

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

1. Необходимо на Рабочем столе найти и запустить файл «Airport»

2. После того, как откроется «Airport» можете приступать к работе.

3. Если же после установки вы не захотите работать в приложении «Airport» нажмите кнопку «Выйти из программы».

В случае если приложение «Airport» не запускается, то следует обратиться в службу поддержки.

2.4.4 Описание операций выполняемых информационной системой

Пользовательский интерфейс АРМ авиаоператора реализован следующим образом:

1. Главное окно приложения содержит кнопки быстрого доступа к режимам работы. На форме имеются несколько видов работы с приложением, а также кнопки, позволяющие выйти из приложения (Рис. 2.24).

Рисунок 2.24 - Главное окно приложения

Пользователь приложения может выполнять следующие задачи:

- выбор необходимой таблицы;

- добавление и удаление записей;

- поиск необходимой информации;

- вывод отчетной информации.

2. При нажатии на кнопку «Покупка билета», пользователю открывается новая форма Билет, представленная на рисунке 2.25, после чего можно продолжать работу.

Рисунок 2.25 - Форма Билет

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

Рисунок 2.26 - Кнопки навигации

3. Для добавления новой информации о билете необходимо нажать на кнопку «Добавление информации о пассажире», представленную на рисунке 2.27.

Рисунок 2.27 - Кнопка «Добавление информации о пассажире»

Далее открывается пустая форма, в которую вносятся данные о проданном билете (Рисунок 2.28).

Рисунок 2.28 - Ввод новых данных

Результат добавления информации о Клиенте представлен в таблице на рисункет2.29

Рисунок 2.29 - Окно результата добавления новой информации

4. Если в приложении необходимо просмотреть информацию о пассажире, то необходимо нажать на кнопку «Информация о пассажирах», расположенной в окне Главной формы (Рисунок 2.30).

Рисунок 2.30 - Кнопка «Кнопка Печать»

После чего появляется диалоговое окно с сообщением о вводе фамилии пассажира, представленной на рисунке 2.31

Рисунок 2.31 - Окно ввода параметра поиска

Результат выполнения запроса по поиску пассажира по определенной фамилии представлен на рисунке 2.32 .

Рисунок 2.32 - Окно результата поиска пассажира

Чтобы закрыть приложение, необходимо нажать на кнопку, которая представлена на рисунке 2.33

Рисунок 2.33 - Нажатие кнопки «Выход из программы»

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

Заключение

На примере базы данных «АЭРОПОРТ» мы познакомились с инструментом разработки баз данных Microsoft Access. С его помощью можно быстро создавать деловые приложения для различных сфер деятельности человека. В то же время СУБД Access имеет архитектурные ограничения (например, максимальный размер базы данных не более одного гигабайта), которые не позволяют использовать этот инструмент для управления большими промышленными распределенными базами данных. Для таких целей применяются клиент-серверные СУБД Oracle, IBM DB2, Microsoft SQL Server, Sybase и ряд других.

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

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

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

В данной работе разработана база данных, реализующая базу данных аэропорта.

В процессе выполнения курсовой работы были закреплены знания, полученые при изучении дисциплины «Организация баз данных и знаний». Были изучено такие пункты:

анализ предметной области;

построение концептуальной модели предметной области;

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

организация базы данных;

разработка прикладной программы;

наполнение и сопровождение базы данных;

подготовка программной документации.

В процессе организации БД проведен до необходимого уровня абстракций анализ предметной области, построены концептуальная и реляционная модель БД, произведена нормализация реляционной БД. Оформляя пояснительную записку, были ознакомлены с государственными стандартами ДСТУ 3008-95. При разработке механизма функционирования приложения использованы такие средства Delphi 6.0 работы с базами данных как синхронизация содержимого наборов данных, поиск по части составного ключа и др. Была освоена и закреплена работы с такими прикладными программами:

Borland Delphi 6.0;

DataBase Desktop 7.0;

BDE administrator 5.01;

Microsoft Word;

Были закреплены знания в области программирования, в частности были использованы такие языки программирования, как Object Pascal и SQL.

Список использованных источников

1. Агальцов В.П. Базы данных. В 2-х т.Т. 2. Распределенные и удаленные базы данных.-- М.: ФОРУМ: ИНФРА-М, 2011.

2. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2010. - СПб.: БХВ - Петербург, 2012.

3. Бойко В.В., Савинков В. М. Проектирование баз данных информационных систем.- М.: Финансы и статистика, 2014.

4. Голицина О.Л. Базы данных: Учебное пособие. -- М.: ФОРУМ: ИНФРА-М, 2012.

5. Дейт К. Дж. Введение в системы баз данных, 6-е издание. - К.; М.; СПб.: Издательский дом "Вильямс", 2013.

6. Дубнов, П. Ю. Access. Проектирование баз данных / П.Ю. Дубнов. - М. : ДМК, 2011.

7. Золотова С.И.: Практикум по Access. - М.:: Финансы и статистика, 2011.

8. Избачков Ю.С., Петров В.Н. Информационные системы: Учебник для вузов. 2-е изд. - СПб.: Питер, 2014.

9. Карпова Т.С.: Базы данных: модели, разработка, реализация. - СПб.: Питер, 2009

10. Крамм Р. Программирование в Access для чайников. К.: Диалектика, 2012.

11. Кузин А.В., Демин В.М. Разработка баз данных в системе Microsoft Access-- М.: ФОРУМ: ИНФРА-М, 2013.

12. Михелёв В.М.: Базы данных и СУБД. - Белгород: БелГУ, 2014.

13. Перегудов Ф.И. Информационные системы для руководителей.- М.: Финансы и статистика, 2013.

14. Петров В.Н., Информационные системы.- М.: Союз, 2014.

15. Проектирование баз данных. СУБД Microsoft Access: Учебное пособие для вузов / Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова. - М.: Горячая линия-Телеком, 2010

16. Советов Б.Я.: Базы данных: теория и практика. - М.: Высшая школа, 2010.

17. Сорокин А.В. - Разработка базы данных; - Изд-во: Питер; - 2010

18. Тимошок Т.В.: Microsoft Access. Самоучитель. - М.: Вильямс, 2011

19. Фуфаев Э.В.: Базы данных. - М.: Академия, 2011

20. Харитонова И.А. Самоучитель Access . СПб. : Питер, 2012.

Приложение

Техническое задание на разработку АРМ для авиаоператора

Разделы технического задания:

1.Общие сведения;

2.Назначение и цели адаптации системы;

· Назначение системы;

· Цели адаптации системы;

3.Характеристика объектов адаптации;

4.Требования к системе;

· Требования к системе в целом;

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

· Требования к видам обеспечения;

5.Состав и содержание работ по адаптации системы;

6.Порядок контроля и приемки системы;

7.Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8.Требования к документированию;

9.Источники разработки;

1.Общие сведения:

1.1.Наименование системы:

АРМ для авиаоператора.

1.2.Основания для проведения работ:

Работа выполняется на основании договора №5 от 16.06.2015г.

1.3.Наименование организаций - Заказчика и Разработчика:

1.3.1.Заказчик

Заказчик: Аэропорт;

Адрес фактический: г. Ейск;

Телефон/Факс: 2-18-29;

1.3.2.Разработчик

Разработчик: компания «Консалтинговый центр»;

Адрес фактический: ул. Мира,13, г. Ейск;

Телефон/Факс: 89615142575

1.4.Порядок оформления и предъявления заказчику результатов работ:

Работы по разработке АРМ авиаоператора сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта.

2.Назначение и цели конфигурирования системы:

2.1.Назначение системы:

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

2.2.Цели создания системы:

АРМ авиаоператора создается с целью:

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

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

ь Качественной работы с клиентами. Уменьшение риска ошибок при редактировании и добавлении информации о пассажирах.

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

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

· Время сбора и первичной обработки исходной информации;

· Время, затрачиваемое на информационно-аналитическую деятельность.

3.Характеристика объектов автоматизации:

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

4.Требования к системе:

4.1.Требования к системе в целом

4.1.1.Требования к структуре и функционированию системы

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

1. В системе должна быть функция добавления нового клиента;

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

3. Возможность поиска (фильтрации) по базе данных необходимой информации.

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

5. Производить формирование отчетов относительно полученной ранее информации.

6. Осуществлять подготовку выходных документов.

7.Данные в системе должны регулярно обновляться.

8.Интерфейс должен быть доступным и понятным пользователю.

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

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

4.1.1.1 Перечень подсистем, их назначение и основные характеристики

В состав АРМ для авиаоператора должны входить следующие подсистемы:

- Подсистема информации о пассажирах, самолетах, рейсах, экипаже.

- Подсистема хранения данных.

- Подсистема формирования отчетности.

4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

Требования не предъявляются.

4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами

Требования не предъявляются.

4.1.1.4 Требования к режимам функционирования системы

Для АРМ для авиаоператора определен следующий режим функционирования:

- Нормальный режим функционирования;

В нормальном режиме функционирования системы:

- клиентское программное обеспечение и технические средства пользователей и администратора системы обеспечивают возможность функционирования в течение рабочего дня (с 09:00 до 18:00) пять дней в неделю;

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

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

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

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

4.1.1.5 Требования по диагностированию системы

АРМ для авиаоператора должно предоставлять инструменты диагностирования основных процессов системы, трассировки и мониторинга процесса выполнения программы.

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

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

4.1.1.6 Перспективы развития, модернизации системы

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

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

- добавления новых таблиц в базу данных;

- автоматического обновления записей в базу данных;

- изменения полей в таблицах;

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

- изменения схемы данных;

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

4.1.2.Требования к численности и квалификации персонала системы и режиму его работы

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

4.1.3.Требования к надежности

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

1. Организация бесперебойного электропитания технических средств;

2. Использование лицензированного программного обеспечения;

3. Регулярное выполнение рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 года об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПК, и оргтехники, и сопровождению программных средств;

4. Регулярное выполнение требований ГОСТ 51188-98. Защита информации, испытание программных средств на наличие вирусов;

5. Предварительное обучение пользователей и обслуживающего персонала.

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

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

4.1.4.Требования к эргономике и технической эстетике

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

1. Интерфейсы подсистем должен быть типизированы.

2. Должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя.

3. Должен использоваться шрифт Times New Roman.

4. Размер шрифта должен быть: 14пт.

5. Цветовая палитра должна быть: без использования красного и синего цвета фона.

6. Для наиболее частых операций должны быть предусмотрены «горячие» клавиши.

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

4.1.5.Требования по сохранности информации при авариях

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

4.1.6. Требования к защите информации от несанкционированного доступа

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

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

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

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

4. Разграничение прав доступа пользователей и администраторов Системы должно строиться по принципу «что не разрешено, то запрещено».

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

4.2.Требования к функциям, выполняемым системой

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

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

- проверка реквизитов электронных документов;

- обеспечение регламентации допустимых операций;

- предоставление оперативной информации и установленной отчетности о проводимых операциях;

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

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

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

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

- осуществление поиска документов в системе;

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

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

4.3.Требования к видам обеспечения

4.3.1.Требования к информационной и программной совместимости

Системные программные средства, используемые программой, должны быть представлены:

1. Лицензионной локализованной версией операционной системы платформы-Windows;

2. Microsoft Access 07-2013.

3. Microsoft Word 07-2013.

4.3.2.Требования к техническому обеспечению

В состав технических средств должен входить ПК, включающий в себя:

1. Процессор Pentium-3.0Hz,не менее.

2. Оперативная память объемом 2 Гбайт, не менее.

3. Жесткий диск объемом 500 Гбайт, не менее.

4. Устройство чтения компакт-дисков (DVD-ROM).

5. Сетевой адаптер - 100 Мбит.

5.Состав и содержание работ по созданию системы

Стадии и этапы разработки по созданию АРМ авиаоператора:

Стадии разработки

Разработка должна быть проведена в три стадии:

1.Разработка технического задания.

2.Рабочее проектирование.

3.Внедрение.

Этапы разработки

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

1.Разработка технического задания.

2.Согласование технического задания.

3.Утверждение технического задания.

На стадии рабочего проектирования должны быть выполнены следующие этапы:

1.Разработка программы.

2.Разработка программной документации.

3.Испытания программы.

На стадии внедрение должны быть выполнены следующие этапы:

1.Подготовка программы.

2.Передача программы.

Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

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

2.Определение и уточнение требований к техническим средствам.

3.Определение требований к программе.

4.Определение стадий, этапов и сроков разработки программы и документации на нее.

5.Согласование и утверждение технического задания.

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

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

1.Необходимо проверить точность следования всем алгоритмам.

2.Проверить реакцию системы при вводе некорректных значений.

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

4.Проверить возможности поиска необходимых данных.

5.Проверить возможности сортировки необходимых данных.

6.Проверить возможности фильтрации необходимых данных.

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

Таблица 1 Календарный план

Стадии разработки

Этапы работ

Содержание работ

Время выполнения

Техническое задание

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

Построение математической модели и детальное рассмотрение предметной области.

15.02.2013-15.03.2013

Разработка технического задания

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

15.03.2013-15.04.2013

Утверждение технического задания

Согласование и утверждение технического задания.

15.04.2013-15.05.2013

Разработка проекта

Проектирование и разработка программы

Программирование и отладка.

15.05.2013- 15.06.2013

Создание документации

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

15.06.2013-15.07.2013

Тестирование

Корректировка программы, выявление недочетов.

15.07.2013-15.08.2013

Внедрение

Подготовка и сдача программного продукта заказчику

Сдача проекта заказчику. Оформление соответствующей документации.

15.08.2013- 15.09.2013

6.Порядок контроля и приемки системы

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

Таблица 2 Требования к качеству

...

Код

Показатель


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

  • Рассмотрение инфологической и даталогической модели базы данных кинотеатров города. Разработка базы данных в программе MS Access. Описание структуры приложения и интерфейса пользователя. Изучение SQL-запросов на вывод информации о кинотеатре и о фильме.

    курсовая работа [1,1 M], добавлен 04.09.2014

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

    дипломная работа [1009,2 K], добавлен 01.05.2015

  • Создание автоматизированной информационной системы отдела приема объявлений и рекламы в группе газет "Из рук в руки": предметная область, разработка программного обеспечения и реализация; построение инфологической и даталогической моделей базы данных.

    курсовая работа [9,8 M], добавлен 11.01.2012

  • Цели проектирования базы данных "Аэропорт": обработка информации о рейсах, расписании самолетов и билетах. Анализ предметной области. Принцип работы модели. Особенности реализации информационной системы. Среда программирования клиентского приложения.

    лабораторная работа [2,4 M], добавлен 07.01.2014

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

    дипломная работа [4,2 M], добавлен 22.04.2015

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

    дипломная работа [2,8 M], добавлен 25.01.2013

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

    курсовая работа [675,2 K], добавлен 16.09.2017

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

    дипломная работа [326,9 K], добавлен 02.10.2013

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

    курсовая работа [501,7 K], добавлен 02.12.2014

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

    курсовая работа [989,7 K], добавлен 09.12.2014

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

    курсовая работа [291,3 K], добавлен 21.05.2013

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

    курсовая работа [406,2 K], добавлен 21.02.2016

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

    курсовая работа [2,1 M], добавлен 14.02.2011

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

    дипломная работа [225,0 K], добавлен 18.05.2013

  • Анализ деятельности гостиницы. Структурный анализ бизнес-процесса на основе IDEF0-модели. Особенности построения инфологической и даталогической модели данных. Аспекты проектирования базы данных гостиницы с использованием программного языка Delphi.

    курсовая работа [1,6 M], добавлен 15.02.2014

  • Разработка информационно-аналитической системы агентства недвижимости. Обоснование выбора архитектуры базы данных и СУБД. Моделирование потоков данных (DFD диаграмм). Проектирование инфологической модели данных с использованием модели "сущность-связь".

    дипломная работа [5,4 M], добавлен 06.06.2013

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

    курсовая работа [2,8 M], добавлен 30.11.2011

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

    курсовая работа [1,5 M], добавлен 03.07.2012

  • Разработка логической и физической моделей базы данных предприятия и описание атрибутов. Порядок создания справочников и реквизитов базы данных на основе программы "1С:Предприятие 8.2", назначение связей таблиц. Пример сгенерированных SQL-кодов.

    курсовая работа [2,7 M], добавлен 02.12.2015

  • Порядок сбора данных с помощью программного обеспечения "ПРОЛОГ". Языки программирования VBA и HTML, их характерные особенности. Web-сервера Apache, принцип работы серверной системы. Реализация сбора данных и разработка сайта с показаниями приборов.

    дипломная работа [4,4 M], добавлен 24.09.2014

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