Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Реализация билетов через розничные кассы» (1. АНАЛИТИЧЕСКАЯ ЧАСТЬ)

Содержание:

ВВЕДЕНИЕ

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

Все это обуславливает актуальность автоматизации деятельности авиакомпании.

Цель работы – проектирование базы данных для автоматизации деятельности кассы авиакомпании.

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

1. Изучить основные этапы разработки баз данных.

2. Осуществить разработку базы данных.

3. Подготовить отчеты и формы.

Объектом исследования является авиакомпания. Предметом исследования является его деятельность – продажа билетов на разные направления.

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Выбор комплекса задач автоматизации

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

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

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

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

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

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

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

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

1.2. Характеристика существующих бизнес-процессов

Опишем основные функции, которые должна выполнять данная система:

  1. Ведение базы данных клиентов с подробными данными о них (ФИО, адрес, паспортные данные, телефонный номер и др.);
  2. Ведение базы данных всех произошедших операций купли-продажи (данные о клиенте, истории его перелетов и т.д.);
  3. Ведение справочников (клиенты, рейсы, пункты назначения, пункты отправления и т.д.);
  4. Получение аналитической и статистической информации (данные по количеству оставшихся билетов, отчет по продажам за месяц, продажи по клиентам);
  5. Получение справочной информации в печатном виде (счет-фактура, накладная, клиенты, отчеты по продажам).

Задачи проектирования:

  1. Максимально упростить и ускорить процедуру продажи билетов.
  2. Обеспечить все бизнес-операции возможностью сопроводить их необходимыми документами.
  3. Создать гибкую систему статистических отчетов.
  4. Обеспечить при необходимости возможность автоматического резервирования БД.
  5. Запретить некорректные действия пользователя.
  6. Обеспечить целостность информации в базе данных.
  7. Обеспечить приемлемую безопасность данных на случай несанкционированного доступа.
  8. Минимизировать затраты системных ресурсов, необходимых для нормальной работы АРМ.
  9. Программное обеспечение должно функционировать на IBM-совместимых персональных компьютера и должно работать под управлением операционных систем семейства WIN32 (Windows’95, Windows’98, Windows’2000 Windows’XP, Windows NT и т.д.).

1.3. Характеристика документооборота, возникающего при решении задачи

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

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

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

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

1.4. Обоснование проектных решений по информационному обеспечению

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

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

Для работы кассы авиакомпании нужна следующая информация:

а) сведения о количестве мест:

  • Самолет;
  • Класс;
  • Стоимость билета.

б) расписание:

  • номер;
  • самолет;
  • аэропорт отправления;
  • время отправления;
  • аэропорт прибытия;
  • время прибытия.

в) отправления:

  • номер;
  • самолет;
  • дата.

г) операции:

  • номер кассы;
  • самолет;
  • клиент;
  • класс;
  • операция;
  • к возврату.

д) сведения о клиентах:

  • номер паспорта;
  • фамилия;
  • имя;
  • отчество;
  • дата рожденья;
  • контактный телефон.

Клиент

Операции

Расписание

Отправления

Места

Рисунок 1. Концептуальная модель данных

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

Таблица 1

Атрибуты сущностей

Сущность

Ключ

Атрибуты

Клиенты

Первичный

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

Фамилия

Имя

Отчество

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

Контактный телефон

Места

Первичный

Самолет

Количество мест первого класса

Стоимость 1-го класса

Количество мест 2-го класса

Стоимость 2-го класса

Количество мест 3-го класса

Стоимость 3-го класса

Операции

Первичный

первичный

Самолет

Клиент

Класс

Операция

Номер кассы

К возврату

Расписание

Первичный

№п/п

Самолет отправления

Время отправления

Аэропорт прибытия

Время прибытия

Отправления

Первичный

№ п/п

Самолет

дата

1.5. Обоснование проектных решений по программному обеспечению

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

Access является системой управления реляционной базой данных, включающей все необходимые инструментальные средства для создания локальной базы данных, общей базы данных в локальной сети с файловым сервером или создания приложения пользователя, работающего с базой данных на SQL – сервере. Диспетчером данных, выполняющим загрузку и сохранение данных в базе данных пользователя и системных базах данных, является ядро базы данных Microsoft Jet. Access построена на основе усовершенствованной версии ядра базы данных Microsoft Jet 4.0. Эта версия имеет высокую производительность и улучшенные сетевые характеристики.

Jet 4.0 обеспечивает поддержку двухбайтового представления символов Unicode, позволяющего использовать символы нескольких национальных алфавитов. Чтобы скомпенсировать возрастающий объём памяти, применяется сжатие данных, сохраняемых в формате Unicode. Для лучшей совместимости Microsoft Jet 4.0 и Microsoft SQL Server и соответствия языка SQL спецификации ANSI SQL 92 были внесены изменения в реализацию Microsoft Jet 4.0 SQL. Ядро Jet 4.0 имеет встроенную поддержку интерфейсов OLE DB, благодаря которой Microsoft Access может быть использован в качестве универсальной основы разработки клиентских приложений Microsoft SQL Server.

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

- технология клиент/сервер, для реализации которой в Access включены средства создания проекта – приложения, работающего в качестве клиента баз данных SQL – сервера. Подключение к серверу реализуется с помощью нового интерфейса OLE DB без использования ядра баз данных Microsoft Jet. В Microsoft SQL Server 7.0 этот интерфейс является базовым. Благодаря этому Access становится универсальной основой для построения клиентских приложений, работающих с SQL – сервером;

- Internet – технология, позволяющая эффективно распространять и получать доступ к разнородной информации в глобальных и корпоративных сетях. Эта технология обеспечивает унифицированный доступ к данным различных приложений в разнородных сетях. Для реализации Internet технологии в Access включены новые интерактивные средства конструирования Web – страниц доступа к данным в базах данных Access SQL – серверов. При этом Web – браузер используется как универсальный интерфейс для доступа и работы с информацией из внешней среды вне зависимости от аппаратно – программной платформы компьютера пользователя и компьютера – источника информации. Страницы могут использоваться подобно формам Access – для ввода и редактирования данных или подобно отчётам Access – для отображения иерархически сгруппированных записей.

Paradox. Если вам нужна мощная 32-разрядная система разработки с объектно-ориентированным языком, новейшие средства работы с OLE и впечатляющая среда разработки, то Paradox как раз то, что требуется. Он включает все необходимые инструментальные средства для создания локальной базы данных, общей базы данных в локальной сети с файловым сервером или создания приложения пользователя, работающего с базой данных на SQL – сервере.

Новейшая редакция СУБД Paradox for Windows компании Borland - пакет Paradox 7 - это существенно улучшенный продукт, в полной мере использующий особенности Windows, более простой в употреблении и предоставляющий более мощные средства разработки.

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

Paradox 7 способен выступать как в роли OLE-клиента, так и в роли OLE-сервера, что позволяет на более высоком уровне осуществлять интеграцию между Paradox и другими OLE-программами, особенно офисными комплектами типа Microsoft Office и Perfect Office фирмы Novell. Например, можно использовать язык программирования ObjectPAL для выполнения процедур и доступа к свойствам OLE-серверов, таких, как Microsoft Word. Кроме того, теперь и Paradox представляет собой OLE-сервер, и OLE-клиенты, например Microsoft Excel или Visual Basic, могут обращаться к процедурам и свойствам, предоставляемым Paradox.

В СУБД Paradox 7, как и в других инструментах разработки Borland (Visual dBase, Delphi и C++), используются система Borland Database Engine (BDE) и базовые программные средства промежуточного уровня производства самой компании. BDE с помощью SQL Links связывается с интерфейсом InterBase API и тем самым реализует в Paradox функциональность модели клиент-сервер.

Приложения, перемещенные в среду клиент-сервер, перенимают все преимущества и отличительные черты реляционных СУБД. InterBase поддерживает декларируемую целостность ссылок, внешние связи, хранимые процедуры, триггеры, крупные двоичные объекты, обновляемые окна просмотра и расширенный набор функций SQL. Приложения могут осуществлять одновременный доступ к нескольким устройствам; кроме этого, полностью поддерживаются возможности начала/принятия/отказа от транзакций. InterBase Server поддерживает протокол двухфазной фиксации транзакций (two-phase commit), в том числе и в случае одновременной работы с несколькими базами данных. Наличие специальных библиотек позволяет разрабатывать приложения-клиенты с использованием Embedded SQL и Dynamic SQL.

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

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

Visual FoxPro – это среда, позволяющая разработчикам создавать приложения по обработке информации. Язык Visual FoxPro принадлежит к так называемой xBASE – группе, ведущей свою историю от первых версий dBASE. Помимо Visual FoxPro, в эту группу входят Clipper, FoxBase и некоторые другие продукты.

Основной задачей приложений по обработке информации является поддержка одной или нескольких таблиц с данными, хранящимися на жестком диске компьютера. В мире xBASE таблицы часто называют DBF – файлами, так как они по большей части имеют расширение DBF(DataBaseFile). Таблицы представляют собой один или несколько столбцов для хранения однотипной информации. Обычно столбцы называют полями.

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

Возможность обработки формы или объекта во время исполнения программы вместо новой генерации и компиляции приводит к огромной разнице программирования на предыдущих версиях FoxPro и Visual FoxPro. Форма может быть модифицирована непосредственно во время работы Вашего приложения посредством обращения к её свойствам.

Недостатки: отдельные файлы таблиц довольно часто могут терять индексы, физически портиться, кроме того, при изменении каскада таблиц нельзя прерывать это изменение иначе может нарушиться ссылочность данных; программисту приходится изучать еще и язык СУБД, помимо встроенного языка; при переносе программ необходимо на клиентской машине установить сам Visual FoxPro, чтобы он мог прописать свои библиотеки и драйвера для работы с dbf-файлами; хотя FoxPro взаимодействует с другими продуктами Microsoft, подчас реализация этого взаимодействия запаздывает.

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

2. ПРОЕКТНАЯ ЧАСТЬ

2.1. Информационная модель и её описание

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

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

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

Рис.6. Информационная модель задачи

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

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

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

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

2.3. Характеристика результатной информации

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

  • Посадочная ведомость;
  • Отчет за период с группировкой по маршрутам.

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

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

Номер рейса

Бортовой номер

Марка самолета

Вид самолета

ФИО клиента

Номер билета

Полный номер паспорта

Место прописки клиента

Вес багажа

Форма 2. Форма выходного документа задачи с результатом вывода отчета по доходам аэрофлота за определенный период с группировкой по маршрутам.

Название рейса

Количество проданных билетов

Выручка по рейсам

2.4. Общие положения (дерево функций и сценарий диалога)

Главные функции можно разделить на три класса:

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

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

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

Рис.3. Функции системы

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

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

Рис.4. Сценарий диалога программы

2.5. Характеристика базы данных

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

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

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

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

Построенная датологическая модель БД, с учетом особенностей MS ACCESS, выглядит следующим образом:

Таблица 2

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

Имя поля

Тип данных

Описание

№ паспорта

текстовый

Идентификатор

Фамилия

Текстовый

Фамилия пассажира

Имя

Текстовый

Имя пассажира

Отчество

текстовый

Отчество пассажира

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

Дата/время

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

Контактный телефон

текстовый

Контактный телефон клиента

Таблица 3

Таблица «Места»

Имя поля

Тип данных

Описание

самолет

числовой

Номер рейса

Кол. Мест 1-го кл.

числовой

Стоимость мест 1кл

денежный

Стоимость билета на места 1 класса

Кол-во мест 2-го кл

числовой

Стоимость мест 2-го кл

денежный

Стоимость билета на места 2 класса

Кол-во мест 3кл

числовой

Стоимость мест 3кл.

денежный

Стоимость билета на места 3 класса

Таблица 4

Таблица «Операции»

Имя поля

Тип данных

Описание

самолет

числовой

Номер рейса

Клиент

текстовый

класс

текстовый

операция

текстовый

Номер кассы

Числовой

К возврату

денежный

Таблица 5

Таблица «Расписание»

Имя поля

Тип данных

Описание

№ п/п

Счетчик

самолет

Счетчик

Аэропорт отправления

Дата\время

Время отправления

Текстовый

Аэропорт прибытия

Числовой

Время прибытия

Числовой

Таблица 6

Таблица «Отправления»

Имя поля

Тип данных

Описание

№ п/п

числовой

Самолет

числовой

Дата

Дата /время

Связь между таблицами выглядит следующим образом:

Рис.5. Связь между таблицами

2.6. Структурная схема пакета (дерево вызова программных модулей)

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

  • Модуль «авторизация»
  • Модуль «Меню»
  • Модуль «Справочники»
  • Модуль «Ввод данных
  • Модуль «Печать»
  • Модуль «Настройки»

Структурная схема пакета представлена на рисунке 6.

Рис. 6. Схема связи программных модулей

2.7. Описание программных модулей

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

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

Схема определения типа пользователя приведена на рис. 7.

Рис. 7. Схема технологического процесса определения типа пользователя

2.8. Контрольный пример реализации проекта и его описание

Курсовая работаMS Access 2003

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

курсовая работа по програмированию

дипломная работа по програмированию

лабораторная работа по програмированию

контрольная работа по програмированию

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

  1. РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.
  2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
  3. ГОСТ 34.602-89. Информационная технология.
  4. ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
  5. РД IDEF0 2000. Методология функционального моделирования.
  6. Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008.
  7. Введение в системы баз данных – СПб: Издательский дом "Вильямс", 2000. - 848 с.;
  8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: «Финансы и статистика», 2000
  9. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем – М.: ИНТУИТ.ру, 2005
  10. Данелян Т.Я. Организация и функционирование больших информационных систем. -М.: МЭСИ, 2007
  11. Ивлиев М.К., Порошина Л.А. Автоматизация оперативного и бухгалтерского учета товаров, 1997.
  12. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
  13. Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2005 г - 656 стр.
  14. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
  15. Разработка программного обеспечения - СПб : "Питер", 2004 г - 592 стр.