Помощь в написании студенческих работ
Антистрессовый сервис

Разработка автоматизированной информационной системы киноцентра «Пирамида» и внешнего приложения к ней

КурсоваяПомощь в написанииУзнать стоимостьмоей работы

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

Разработка автоматизированной информационной системы киноцентра «Пирамида» и внешнего приложения к ней (реферат, курсовая, диплом, контрольная)

Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Камчатский государственный университет имени Витуса Беринга»

КУРСОВАЯ РАБОТА по дисциплине «Базы данных»

Тема: Разработка автоматизированной информационной системы киноцентра «Пирамида» и внешнего приложения к ней Выполнил студент

2 курса, группы ПМб-12

Овчинников Владислав Альбертович Научный руководитель:

старший преподаватель кафедры информатики Малежикова Айна Александровна

ВВЕДЕНИЕ

1. АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА КИНОЦЕНТРА «ПИРАМИДА»

1.1 Понятие автоматизированной системы

1.2 Общие требования к АИС киноцентра «Пирамида»

2. ПРОЕКТИРОВАНИЕ АИС

2.1 Концептуальное проектирование

2.2 Логическое проектирование

2.3 Физическое проектирование

2.3.1 Запросы к БД

2.3.2 Экранные формы

2.3.3 Отчеты

3. ВНЕШНЕЕ ПРИЛОЖЕНИЕ КИНОЦЕНТРА «ПИРАМИДА»

3.1 Основы разработки внешних приложений в Delphi

3.2 Создание внешнего приложения к АИС киноцентра «Пирамида»

3.3 Руководство пользователя

ЗАКЛЮЧЕНИЕ

СПИСОК ИСТОЧНИКОВ

ПРИЛОЖЕНИЯ

ВВЕДЕНИЕ

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

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

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

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

Темой данной курсовой работы является разработка автоматизированной информационной системы киноцентра «Пирамида» и внешнего приложения к ней.

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

Предмет исследования — разработка база данных автоматизированной информационной системы киноцентра «Пирамида» и внешнего приложения к ней.

Целью исследования является проектирование и разработка автоматизированной информационной системы киноцентра «Пирамида» и внешнего приложения к ней.

Задачи исследования:

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

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

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

создание внешнего приложения в Delphi 7.

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

1. АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА КИНОЦЕНТРА «ПИРАМИДА»

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

Система управления базами данных (СУБД) — это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями [9; 19].

СУБД — средство, которое выполняет основные функции:

описывает структуру информации;

определяет правила доступа к информации;

вводит, хранит и проверяет информацию;

производит поиск информации по запросу;

выполняет различные виды сортировки;

формирует выходные формы [18, 96].

Автоматизированная информационная система — совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала) [2; 12; 14].

1.2 Общие требования к АИС киноцентра «Пирамида»

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

сведение к минимуму всевозможных ошибок, обусловленных человеческим фактором;

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

Исходя из этого, автоматизированная информационная система киноцентра «Пирамида» выполняет следующие задачи:

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

составление необходимых отчетов;

вывод информации по сеансам в указанном пользователем АИС временном промежутке;

позволяет обновлять, добавлять и удалять данные.

2. ПРОЕКТИРОВАНИЕ АИС Одним из важных жизненных этапов жизненного цикла является проектирование базы данных. Оно начинается по завершении анализа всех требований к проекту, выдвигаемых со стороны предприятия-заказчика. В данной курсовой работе используется разбиение этого процесса на три этапа:

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

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

Физическое проектирование — принятие решения о том, как логическая модель будет физически реализована (с помощью таблиц) в базе данных, создаваемой с использованием выбранной СУБД [5, 148].

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

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

Этапами концептуального проектирования являются:

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

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

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

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

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

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

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

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

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

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

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

Автоматизированная информационная система киноцентра «Пирамида» имеет 7 объектов:

Кинотеатр. Свойства: Код, Адрес, ФИО директора, Название.

Персонал. Свойства: Код, ФИО, Должность, Дата рождения, Место жительства, Паспортные данные, Телефон, Зарплата.

Билет. Свойства: Код, Цена.

Фильм. Свойства: Код, Название, Режиссер, Страна, Год, Хронометраж.

Сеанс. Свойства: Код, Дата, Время.

Зал. Свойства: Название, Вместимость.

Бронь. Свойства: Код, ФИО клиента.

2.2 Логическое проектирование Логическое проектирование базы данных — конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учета используемой СУБД и прочих физических условий реализации [5, 58].

Логическое проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (например, предполагается использование некоторой реляционной СУБД). Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения [5, 60].

Этапы логического проектирования являются следующими:

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

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

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

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

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

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

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

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

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

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

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

Обсуждение глобальной логической модели данных с пользователями [5; 17].

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

Связи бывают четырех видов:

1)"один-к-одному" - любому экземпляру одной сущности соответствует только один экземпляр другой сущности, и наоборот;

2)"один-ко-многим" - любому экземпляру первой сущности соответствует 0, 1 или несколько экземпляров второй сущности, но любому экземпляру второй сущности соответствует только один экземпляр первой сущности;

3)"многие-к-одному" - любому экземпляру первой сущности соответствует только один экземпляр второй сущности, но любому экземпляру второй сущности соответствует 0, 1 или несколько экземпляров первой сущности;

4)"многие-ко-многим" - любому экземпляру первой сущности соответствует 0, 1 или несколько экземпляров второй сущности, и любому экземпляру второй сущности соответствует 0, 1 или несколько экземпляров первой сущности.

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

Кинотеатр. Ключевой атрибут — Код. Связь: Кинотеатр-Персонал. Тип связи: 1: M. (В одном кинотеатре работает множество персонала) Персонал. Ключевой атрибут — Код. Связь: Персонал — Билет. Тип связи: 1: M. (Один кассир продает множество билетов) Билет. Ключевой атрибут — Код.

Фильм. Ключевой атрибут — Код. Связь: Билет — Фильм. Тип связи: 1: M. (На один фильм продается множество билетов) Сеанс. Ключевой атрибут — Код. Связь: Билет — Сеанс. Тип связи: 1: M. (На один сеанс продается множество билетов) Зал. Ключевой атрибут — Название. Связь: Билет — Зал. Тип связи: 1: M. (На один зал приходится множество билетов) Бронь. Ключевой атрибут — Код. Связь: Билет — Бронь. Тип связи: 1: M. (Один клиент может забронировать множество билетов) Для визуального представления связей в таблице часто используют так называемую ER-диаграмму (приложение Б).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица «Кинотеатр»

Название атрибута

Тип данных

Код

Счетчик

Адрес

Текстовый (50)

ФИО директора

Текстовый (30)

Название

Текстовый (10)

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

Название атрибута

Тип данных

Код

Счетчик

ФИО

Текстовый (30)

Должность

Текстовый (20)

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

Дата/время

Место жительства

Текстовый (100)

Паспортные данные

Текстовый (100)

Телефон

Текстовый (10)

Зарплата

Денежный

Место работы

Числовой

Таблица «Билет»

Название атрибута

Тип данных

Код

Счетчик

Цена

Денежный

Место

Текстовый (30)

Фильм

Числовой

Сеанс

Числовой

Зал

Текстовый (30)

Бронь

Числовой

Продавец

Числовой

Таблица «Фильм»

Название атрибута

Тип данных

Код

Счетчик

Название

Текстовый (50)

Режиссер

Текстовый (50)

Страна

Текстовый (50)

Год

Числовой

Хронометраж (мин)

Числовой

Таблица «Сеанс»

Название атрибута

Тип данных

Код

Счетчик

Дата

Дата/время

Время

Числовой

Таблица «Зал»

Название атрибута

Тип данных

Название

Текстовый (30)

Вместимость

Числовой

Таблица «Бронь»

Название атрибута

Тип данных

Код

Счетчик

ФИО клиента

Текстовый (50)

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

2.3.1 Запросы к БД

Запросы — это объект базы данных, который служит для извлечения данных из таблиц и предоставления их пользователю в удобном виде [13; 16].

В данной БД представлены следующие запросы:

Сотрудники от, А до Я — вывод списка текущих сотрудников в алфавитном порядке.

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

Билет с бронью — выводит список забронированных билетов.

Запрос на создание таблицы Архив_проданных_билетов, а также связанные с этой таблицей запросы на добавление в неё новых записей, а также на удаление дубликатов.

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

Запросы в режиме конструктора находятся в приложении Г.

2.3.2 Экранные формы Форма в БД — это структурированное окно, которое можно представить так, чтобы оно повторяло форму бланка. Формы создаются из набора отдельных элементов управления. Источником данных для формы являются записи таблицы или запроса[9;10;12].

Форма предоставляет возможности для:

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

Изменения данных.

Печати.

Создания сообщений[10,175].

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

2.3.3 Отчеты

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

Отчеты позволяют выбрать из баз данных нужную пользователю информацию, оформить ее в виде документа, перед выводом на печать просмотреть на экране [9; 10].

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

В данной БД представлены следующие отчеты:

Составной отчет, основанный на таблице Билет.

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

Отчеты можно увидеть в приложении Д.

3. ВНЕШНЕЕ ПРИЛОЖЕНИЕ КИНОЦЕНТРА «ПИРАМИДА»

3.1 Основы разработки внешних приложений в Delphi

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

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

Системы управления базами данных содержат в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (Application Programming Interface, API) для доступа к данным этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов базы данных, а в случае серверных СУБД инициируют передачу запросов серверу баз данных и получение от сервера результатов. Библиотеки, содержащие API для доступа к данным серверной СУБД, обычно входят в состав её клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения [11, 114].

В последнее время Windows-версии клиентского программного обеспечения наиболее популярных серверных СУБД, в частности Microsoft SQL Server, Oracle, Informix, содержат также СОМ-серверы, предоставляющие объекты для доступа к данным.

Использование клиентского API (или клиентских СОМ-объектов) является естественным и эффективным способом манипулирования данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только конкретной СУБД, так как клиентские АРI и объектные модели не подчиняются каким-либо стандартам и различны для разных СУБД.

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

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

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

невозможность использования функциональности, специфичной для конкретной СУБД;

снижение производительности приложений;

усложнение процедуры поставки приложения.

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

К универсальным механизмам доступа к данным относятся:

ODBC — Open Database Connectivity.

OLE DB — Object Linking and Embedding Database.

ADO — ActiveX Data Objects.

BDE — Borland Database Engine [11; 16].

OLE DB и ADO — часть универсального механизма доступа к данным фирмы Microsoft (Microsoft Universal Data Access), позволяющая осуществить доступ как к реляционным, так и к нереляционным источникам данных, таким как файловая система, данные электронной почты, многомерные хранилища данных и др.

Итак, приложение, использующее базы данных, может применять следующие механизмы доступа к данным:

непосредственный вызов функций клиентского API или обращение к СОМ-объектам (Component Object Model) клиентских библиотек;

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

непосредственное обращение к интерфейсам OLE DB;

применение ADO (или применение классов, инкапсулирующих обращение к объектам ADO);

применение ADO+OLE DB+ODBC;

применение BDE+SQL Links (или применение классов, инкапсулирующих обращение к функциям BDE);

применение BDE+ODBC Link+ODBC [11; 16].

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

Компанией Microsoft был предложен механизм доступа к данным ActiveX Data Objects (ADO), построенный на использовании интерфейсов OLE DB. ADO — это набор библиотек, содержащих СОМ-объекты, реализующие прикладной программный интерфейс для доступа к данным и используемые в клиентских приложениях. Технология ADO использует библиотеки OLE DB, предоставляющие низкоуровневый интерфейс для доступа к данным.

ADO становится всё более популярным способом доступа к данным, так как включена в ядро операционных систем семейства Windows, и входит в состав таких популярных продуктов, как MS Office и MS Internet Explorer.

Согласно терминологии ADO любой источник данных (база данных, электронная таблица, файл) называется хранилищем данных, с которым приложение взаимодействует при посредстве провайдера [11, 130].

Приложение обращается к данным не напрямую, а через объект OLE DB, который «умеет» работать с разнообразными данными. Технология ADO включает в себя набор объектов и механизмов, обеспечивающих взаимодействие объектов с данными и приложениями. Очень важную роль играют провайдеры ADO, координирующие работу приложений с хранилищами данных различных типов.

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

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

В технологии ADO используются объекты-перечислители, источники данных, сессии, транзакции, наборы рядов, команды [11; 16].

Объекты-перечислители выполняют поиск объектов ADO, осуществляющих доступ к источнику данных.

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

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

Объект-команда объединяет текстовую команду и механизмы обработки команд. Команды позволяют использовать для работы с данными язык SQL.

Для применения технологии ADO в Delphi 7 предназначены семь компонентов, расположенных на закладке ADO палитры компонентов:

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

ADOTable используется для доступа к таблице с помощью механизма ADO.

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

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

RDSConnection управляет механизмом, который позволяет клиенту получать доступ к объектам, расположенным в другом адресном пространстве или на другом компьютере [8; 11; 16].

Класс TADOConnection обеспечивает соединение с данными, доступ к которым реализуется через ADO-объекты. Компоненты ADOConnection используют для доступа к данным OLE DB-провайдеры.

Компоненты ADOCommand и ADODataSet связываются с источником данных посредством объекта ADOConnection, указывая ссылку на него как значение свойства Connection.

Для идентификации соединения необходимо определить значение свойства ConnectionString (строка соединения) компонента ADOConnection, которое может основываться на указании datalink-файла или строки соединения. Если в качестве значения свойства ConnectionString указано имя datalink-файла, то настройку соединения можно выполнять автономно от приложения (например, указывая имя базы данных Microsoft SQL Server на текущем персональном компьютере).

3.2 Создание внешнего приложения к АИС киноцентра «Пирамида»

Для того чтобы разработать в Delphi приложение для просмотра объектов базы данных MS Access, используя механизм ADO, нужно:

1. Открыть Delphi, создать приложение и разместить на форме три компонента:

ADOTable с закладки ADO;

DataSource с закладки Data Access;

BDGrid с закладки Data Controls.

2. Связать компоненты между собой:

установить значение свойства DataSource компонента DBGrid1 в DataSource1;

в свойстве DataSet компонента DataSource1 указать ADOTable1.

3. Задать параметры соединения компонента ADOTable1:

в свойстве ConnectionString нажать кнопку с многоточием, в окне редактора параметров соединения установить переключатель в положение Use Connection String и нажать кнопку Build; в появившемся окне на вкладке Поставщик данных выбрать свойство Microsoft Jet 4.0 OLE DB Provider;

перейдти на вкладку Подключение, указать путь к БД, ввести имя пользователя и при необходимости задать пароль;

нажать кнопку Проверить подключение;

после завершения проверки подключения перейти на вкладку Дополнительно и поставить галочки напротив свойств ReadWrite, Share Deny None;

выбрать вкладку Все и проверить сделанные установки. При необходимости изменить значение, выбрать нужную строчку, нажать кнопку Изменить значение, в появившемся окне выбрать значение и нажать ОК;

нажать два раза ОК;

в свойстве TableName компонента ADOTаble1 указать нужную таблицу;

в свойстве Active установить значение true.

Если всё сделано правильно, то после задания таблицы компонент DBGrid1 заполнится данными.

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

Для осуществления в дальнейшем операций поиска, сортировки и фильтрации нам нужно сначала поместить на форму как минимум два компонента Edit. Пусть первый будет называться Edit1 и служить для ввода в него названия выбранного пользователем приложения поля таблицы, а второй — Edit2 — для выбранных значений этого поля. Также для удобства пользователя можно поместить на форму два компонента Label и назвать их соответствующе «Поле» и «Значение».

Для осуществления поиска поместим на форму компонент Button и припишем ему программный код вида:

if Form1. ADOTable1.Locate (Form1.Edit1.Text, Form1. Edit2.Text, [loCaseInsensitive]) =true

then ShowMessage ('Finding!');

Для применения фильтрации, а также снятия её, поместим на форму два компонента Button. Первый назовем «Фильтр», присвоим ему следующий код:

Form1.ADOTable1.Filter:=Form1. Edit1. Text+' = '+QuotedStr (Form1. Edit2. Text);

Form1.ADOTable1. Filtered:=true;

Второй назовем «Снять фильтр», он будет содержать этот код:

Form1.ADOTable1. Filtered:= false;

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

Form1.ADOTable1. Sort:=Form1.Edit1.Text+' ASC';

Второй же будет отвечать за сортировку по убыванию. Ему будет соответствовать этот код:

Form1.ADOTable1. Sort:=Form1.Edit1.Text+' DESC';

Также можно осуществить возможность выбора таблиц для отображения и работы. Для этого поместим на форму компонент MainMenu и откроем его редактор и создадим соответствующие таблицам базы данных пункты меню. Затем нажав на форме на один из пунктов этого меню, например пункт выбора таблицы «Персонал», откроем описание метода Click и введем:

ADOTable1.Active:=False;

ADOTable1.TableName:='Персонал';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Такие же операции проделаем и для других пунктов меню, код для них аналогичен.

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

if Form1. CloseQuery then Form1. Close;

Код внешнего приложения находится в приложении Ж.

3.3 Руководство пользователя При запуске программы появляется форма приложения, с уже открытой таблицей «Билет» (Рис. 1).

Рис. 1

Для работы с какой-либо другой таблицей требуется открыть соответствующий пункт главного меню и выбрать нужную (Рис. 2).

Рис. 2

Для управлениями записями выбранной таблицы используется компонент DBNavigator (Рис. 3).

Рис. 3

Описание кнопок компонента в порядке слева направо:

Переход к первой записи.

Переход к предыдущей записи.

Переход к следующей записи.

Переход к последней записи.

Добавить запись.

Удалить запись.

Изменить запись.

Сохранить изменения.

Не сохранять изменения.

Обновить.

Для осуществления поиска нужно ввести в поле «Поле» название того поля значений, где пользователь хочет провести поиск, затем ввести в поле «Значение» искомые данные и нажать кнопку «ПОИСК» (Рис. 4). В случае успеха появится окно «Finding!».

Рис. 4

Для применения фильтрации нужно ввести в поле «Поле» названия поля, по которому будет применяться фильтрация, а в поле «Значение» — искомое значение и нажать кнопку «ФИЛЬТР» (Рис. 5). Для снятия фильтра нужно соответственно нажать кнопку «СНЯТЬ ФИЛЬТР».

Рис. 5

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

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСТОЧНИКОВ Балтер Э. Microsoft Office Access 2007: профессиональное программирование — М.: «Вильямс», 2009. — С. 1296.

Бекаревич Ю., Пушкина Н. MS Access 2007 за 30 занятий. — СПб: ВНV, 2009.

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

Грох М., Стокман Д., Пауэлл Г. Microsoft Office Access 2007. Библия пользователя. — М.: «Диалектика», 2009. — 1200 с.

Дейт К. Дж.

Введение

в системы баз данных, 6-е изд.: Пер. с англ. — К., М., СПб.: Издательский дом «Вильямс», 2009. — 848 с.

Дженнингс Р. Использование Microsoft Access 2010. — М: Издательский дом «Вильямс», 2010. — 1312 с.

Джон Кауфельд, Microsoft Office Access 2003 для «чайников»: Пер. с англ. — М.: 2009. — 320 c.

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

Корнеев И.К., Машурцов В. А. Информационные технологии в управлении. — М.: ИНФРА-М, 2009. — 158 с.

Леонтьев В. П. Новейшая энциклопедия персонального компьютера 2009. — М.: ОЛМА-ПРЕСС, 2009. — 134 с.

Лори Ульрих Фуллер, Кен Кук Access 2010 для чайников = Access 2010 For Dummies. — М.: «Диалектика», 2010. — 384 с.

Лори Ульрих Фуллер, Кен Кук, Джон Кауфельд, Microsoft Office Access 2007 для «чайников»: Пер. с англ. — М.: 2009. 384 с.

Майкл Грох, Джозеф Стокман, Гэвин Пауэлл Microsoft Office Access 2007. — М.: «Диалектика», 2009. — 1200 с.

Mакарова Н. В. Информатика: Практикум по технологии работы на компьютере. Учебное пособие — М.: Финансы и статистика, 2009. — 576 с.

Мартин Дж. Планирование развития автоматизированных систем. — М.: Финансы и статистика, 2009. — 196 с.

Симонович С. В. Информатика: Базовый курс. — СПб.: Питер, 2009. — 640 c.

Фуллер Л.У., Кук К. Access 2010 для чайников. — М.: «Диалектика», 2010. — 384 с.

Фуллер Л.У., Кук К., Кауфельд Д., Microsoft Office Access 2007 для «чайников»: Пер. с англ. — М.: «Диалектика», 2009. — 384 с.

Хомоненко А.Д., Циганков В. М. Базы данных: Учебник для вузов / Под ред. А. Д. Хомоненко. — М.: Корона, 2009. — 421 с.

Элисон Балтер Microsoft Office Access 2007: профессиональное программированиеМ.: «Вильямс», 2009. — 1296 с.

Приложение, А — Аннотация Аннотация Курсовая работа изложена на 55 листах машинописного текста, содержит 21 рисунок, 7 таблиц, список используемых источников включает 20 ресурсов.

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

Объект исследования — разработка автоматизированных информационных систем и внешних приложений к ним.

Практический результат — разработанная автоматизированная информационная система киноцентра «Пирамида» и внешнее приложение к ней.

Область применения — киноцентр «Пирамида».

Annotation

Course work is presented on 55 sheets of typewritten text, comprises 21 figure, 7 tables, a list of sources used includes 20 resources.

Aim of the course is to develop information help system for cinemacenter «Piramida» and program for it.

Object of research — development of automated information systems and programs for it.

Bottom line — an automated information system for cinemacenter «Piramida» and external application to it was developed.

Scopecinemacenter «Piramida».

Приложение Б — ER-диаграмма

Приложение В — Схема данных и таблицы Схема данных

Таблица «Кинотеатр»

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

Таблица «Билет»

Таблица «Фильм»

Таблица «Сеанс»

Таблица «Зал»

Таблица «Бронь»

Приложение Г — Запросы в режиме конструктора Запрос «Сотрудники от, А до Я»

Запрос «Билет Запрос на выборку»

Запрос «Билеты с бронью»

Запрос «Запрос на создание»

Приложение Д — Формы Главная кнопочная форма — страница 1

Главная кнопочная форма — страница 1

Форма «Билет»

Форма «Фильм»

Форма «Персонал»

Приложение Е — Отчеты Отчет «Зал»

Отчет «По датам»

Приложение Ж — Код внешнего приложения

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DB, ADODB, StdCtrls, ExtCtrls, DBCtrls, Grids, DBGrids, Menus;

type

TForm1 = class (TForm)

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

Label1: TLabel;

Label2: TLabel;

Edit1: TEdit;

Edit2: TEdit;

Button1: TButton;

Label3: TLabel;

Button2: TButton;

Button3: TButton;

Button4: TButton;

Button5: TButton;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

Label4: TLabel;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

N10: TMenuItem;

procedure Button1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

procedure Button4Click (Sender: TObject);

procedure Button5Click (Sender: TObject);

procedure N4Click (Sender: TObject);

procedure N5Click (Sender: TObject);

procedure N6Click (Sender: TObject);

procedure N7Click (Sender: TObject);

procedure N8Click (Sender: TObject);

procedure N9Click (Sender: TObject);

procedure N10Click (Sender: TObject);

procedure N3Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1. Button1Click (Sender: TObject);

begin

if Form1. ADOTable1.Locate (Form1.Edit1.Text, Form1. Edit2.Text, [loCaseInsensitive]) =true

then ShowMessage ('Finding!');

end;

procedure TForm1. Button2Click (Sender: TObject);

begin

Form1.ADOTable1. Sort:=Form1.Edit1.Text+' ASC';

end;

procedure TForm1. Button3Click (Sender: TObject);

begin

Form1.ADOTable1. Sort:=Form1.Edit1.Text+' DESC';

end;

procedure TForm1. Button4Click (Sender: TObject);

begin

Form1.ADOTable1.Filter:=Form1. Edit1. Text+' = '+QuotedStr (Form1. Edit2. Text);

Form1.ADOTable1. Filtered:=true;

end;

procedure TForm1. Button5Click (Sender: TObject);

begin

Form1.ADOTable1. Filtered:= false;

end;

procedure TForm1. N4Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Кинотеатр';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Кинотеатр» ';

end;

procedure TForm1. N5Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Персонал';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Персонал» ';

end;

procedure TForm1. N6Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Билет';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Билет» ';

end;

procedure TForm1. N7Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Фильм';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Фильм» ';

end;

procedure TForm1. N8Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Сеанс';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Сеанс» ';

end;

procedure TForm1. N9Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Зал';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Зал» ';

end;

procedure TForm1. N10Click (Sender: TObject);

begin

ADOTable1.Active:=False;

ADOTable1.TableName:='Бронь';

ADOTable1.Active:=True;

DataSource1.DataSet:=ADOTable1;

DBGrid1.DataSource:=DataSource1;

Label4.Caption:='Таблица «Бронь» ';

end;

procedure TForm1. N3Click (Sender: TObject);

begin

if Form1. CloseQuery then Form1. Close;

end; end.

Показать весь текст
Заполнить форму текущей работой