АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ

КАФЕДРА ИНЖЕНЕРНОЙ КИБЕРНЕТИКИ

 

 

 

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

 

Методические указания к выполнению расчетно-графических работ

для студентов всех форм обучения

специальности 5B070200 – Автоматизация и управление

 

 

 

Алматы 2009 

СОСТАВИТЕЛИ: Ешпанова М.Д., Ибраева Л.К., Сябина Н.В. Методические указания к выполнению расчетно-графических работ для студентов всех форм обучения специальности 5B070200 – «Автоматизация и управление». – Алматы: АУЭС, 2010 – 27 с.

 

Рассматриваются вопросы разработки проекта базы данных, его реализации  и разработки интерфейса пользователя: системный анализ моделируемой предметной области; разработка концептуальной модели; преобразование концептуальной схемы в реляционную; реализация реляционной модели в среде MS SQL Server 2005; разработка клиентского приложения с помощью выбранного механизма доступа (BDE или ADO).

 

 

1 Расчетно-графическая работа. Системный анализ моделируемой предметной области. Разработка концептуальной модели

 

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

 

1.1 Системный анализ предметной области

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

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

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

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

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

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

Системный анализ должен заканчиваться:

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

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

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

- кратким описанием алгоритмов решения задач;

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

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

 

1.2 Пример описания предметной области

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

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

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

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

Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN).

В библиотеке ведется картотека читателей. На каждого читателя в картотеку заносятся следующие сведения: фамилия, имя, отчество;  домашний адрес; телефон (будем считать, что у нас два телефона — рабочий и домашний); дата рождения.

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

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

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

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

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

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

1)     Принимать новые книги и регистрировать их в библиотеке.

2)     Относить книги к одной или к нескольким областям знаний.

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

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

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

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

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

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

Читатель должен иметь возможность решать следующие задачи:

1)   Просматривать системный каталог, то есть перечень всех областей знаний, книги по которым есть в библиотеке.

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

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

4)  Для выбранного автора получить список книг, которые числятся в библиотеке.

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

 

1.3  Концептуальная модель предметной области «Библиотека»

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

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

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

Концептуальное проектирование, прежде всего, связано с попыткой представления семантики (смысла) предметной области в модели базы данных. Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. В настоящий момент модель Чена «Сущность - Связь», или «Entity - Relationship», стала стандартом при концептуальном моделировании баз данных. Общепринятым стало ее сокращенное название - ER-модель. Для удобства вместо термина «сущность» будем использовать термин «объект» (объектное множество).

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

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

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

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

Между сущностями «Книги» и «Экземпляры» существует связь «один-ко-многим» (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах. При этом если в библиотеке нет ни одного экземпляра дайной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности «Книги», то, по крайней мере, один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности «Экземпляры», то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны «Экземпляры» связь тоже обязательная.

Теперь необходимо определить, как в нашей системе будет представлен читатель. Естественно предложить ввести для этого объектное множество «Читатели», каждый экземпляр которой будет соответствовать конкретному читателю. В библиотеке каждому читателю присваивается уникальный номер читательского билета, который будет однозначно идентифицировать нашего читателя. Номер читательского билета будет ключевым атрибутом сущности «Читатели». Кроме того, в сущности «Читатели» должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач, этими атрибутами будут: «Фамилия Имя Отчество», «Адрес читателя», «Телефон домашний» и «Телефон рабочий». Почему мы ввели два отдельных атрибута под телефоны? Потому что звонить по этим телефонам нужно в разное время, чтобы застать читателя, поэтому администрации библиотеки будет важно знать, к какому типу относится данный телефон. В описании нашей предметной области существует ограничение на возраст наших читателей, поэтому в сущности «Читатели» надо ввести обязательный атрибут «Дата рождения», который позволит нам контролировать возраст наших читателей.

Из описания предметной области мы знаем, что каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации нам надо провести связь между сущностями «Читатели» и «Экземпляры». А почему не между сущностями «Читатели» и «Книги»? Потому что читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А как же узнать, какая книга у данного читателя? А это можно будет узнать по дополнительной связи между сущностями «Экземпляры» и «Книги», и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому мы в любой момент можем однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями «Читатели» и «Экземпляры» установлена связь «один-ко-многим», и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.

Теперь нужно отразить последний объект, который связан с системным каталогом. Системный каталог содержит перечень всех областей знаний, сведения по которым содержатся в библиотечных книгах. Мы можем вспомнить системный каталог в библиотеке, с которого мы обычно начинаем поиск нужных нам книг, если мы не знаем их авторов и названий. Название области знаний может быть длинным и состоять из нескольких слов, поэтому для моделирования системного каталога мы введем объектное множество «Системный каталог» с двумя атрибутами: «Код области знаний» и «Название области знаний». Атрибут «Код области знаний» будет ключевым атрибутом сущности.

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

Концептуальная модель предметной области «Библиотека» представлена на рисунке 1.

 

Рисунок 1 - Концептуальная  модель предметной области «Библиотека»

 

1.4 Задание к расчетно-графической работе 

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

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

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

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

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

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

1.4.7   Оформить пояснительную записку по работе. Пояснительная записка по работе должна содержать все указанные пункты и оформляется по стандарту.

 

 

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

 

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

 

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

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

2.1.1 Преобразование объектных множеств и атрибутов

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

2.1.2 Преобразование отношений

Преобразование отношений выполняется по следующим правилам:

а) отношение «один-к-одному» преобразуется путем помещения одного из объектных множеств в качестве атрибутов в таблицу второго объектного множества. Его выбор определяется потребностями конкретного приложения;

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

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

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

 

2.2 Преобразование концептуальной схемы для модели «Библиотека»

В соответствии с рассмотренными правилами для модели «Библиотека» преобразуем вначале объектные множества. Получим следующие реляционные таблицы:

КНИГИ (Шифр_книги, Автор, Название, Место_издания, Год_издания, Издательство). Поскольку шифры книг являются  уникальными, в качестве ключа этой таблицы может быть использован шифр книги.

ЭКЗЕМПЛЯРЫ (Инвентарный_номер, Наличие, Дата_взятия, Дата_возврата). Здесь также ключом может быть инвентарный номер экземпляра.

ЧИТАТЕЛИ (Номер_читательского_билета, ФИО, Дата_рождения, Телефон_рабочий, Телефон_домашний). У каждого читателя индивидуальный номер читательского билета, его и выбираем ключом таблицы.

СИСТЕМ_КАТАЛОГ (Код_области знаний, Наименование_области_ знаний). Ключ таблицы – первое поле.

Рассмотрим преобразование отношений. Так как объектные множества КНИГИ и ЭКЗЕМПЛЯРЫ связаны отношением «один-ко-многим», ключ таблицы КНИГИ должны разместить в таблице ЭКЗЕМПЛЯРЫ в качестве внешнего ключа. Тогда структура таблицы ЭКЗЕМПЛЯРЫ будет иметь вид:

ЭКЗЕМПЛЯРЫ (Инвентарный_номер, Наличие, Дата_взятия, Дата_возврата, Шифр_книги).

Объектные множества КНИГИ и СИСТЕМ_КАТАЛОГ связаны отношением «один-ко-многим». Создадим таблицу пересечений СВЕДЕНИЯ с полями, являющимися ключами исходных таблиц (эти поля образуют составной ключ таблицы):

СВЕДЕНИЯ (Шифр_книги, Код_области_знаний).

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

КНИГИ (Шифр_книги, Автор, Название, Место_издания, Год_издания, Издательство);

ЧИТАТЕЛИ (Номер_читательского_билета, ФИО, Дата_рождения, Телефон_рабочий, Телефон_домашний);

СИСТЕМ_КАТАЛОГ (Код_области знаний, Наименование_области_знаний);

ЭКЗЕМПЛЯРЫ (Инвентарный_номер, Наличие, Дата_взятия, Дата_возврата, Шифр_книги);

СВЕДЕНИЯ (Шифр_книги, Код_области_знаний), внешние ключи - поле Шифр_книги – ключ таблицы КНИГИ и Код_области_знаний – ключ таблицы СИСТЕМ_КАТАЛОГ.

В таблице ЭКЗМЕМПЛЯРЫ поле «Шифр_книги» является внешним ключом, ссылающимся на ключ таблицы КНИГИ.

 

2.3 Задание к расчетно-графической работе

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

-   преобразуйте объектные множества и атрибуты, определите первичные ключи;

-   преобразуйте отношения, определите внешние ключи;

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

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

2.3.2   В качестве среды реализации выберите MS SQL Server.

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

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

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

2.3.6   Выполните поиск информации в базе данных, чтобы получить ответы на поставленные вопросы. Запросы должны охватывать широкий круг вопросов моделируемой области (отмеченных в РГР №1).

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

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

 

 

3 Расчетно-графическая работа. Разработка клиентского приложения

 

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

 

3.1 Механизмы доступа к данным

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

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

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

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

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

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

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

Наиболее популярными среди универсальных механизмов доступа к данным можно назвать следующие: Open Database Connectivity (ODBC); OLE DB; ActiveX Data Objects (ADO); Borland Database Engine (BDE).

Универсальные механизмы ODBC, OLE DB и ADO фирмы Microsoft представляют собой по существу промышленные стандарты. Что касается механизма доступа к данным BDE фирмы Borland, то он так и не стал промышленным стандартом, однако до недавнего времени применялся довольно широко, так как до выхода Delphi 5 был практически единственным универсальным механизмом доступа к данным, поддерживаемым средствами разработки Borland на уровне компонентов и классов.

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

а) ODBC (Open Database Connectivity) — широко распространенный программный интерфейс фирмы Microsoft, удовлетворяющий стандартам ANSI и ISO для интерфейсов обращений к базам данных (Call Level Interface, CLI). Для доступа к данным конкретной СУБД с помощью ODBC, кроме собственно клиентской части этой СУБД, нужен ODBC Administrator (приложение, позволяющее определить, какие источники данных доступны для данного компьютера с помощью ODBC, и описать новые источники данных) и ODBC-драйвер для доступа к этой СУБД. ODBC-драйвер представляет собой динамически загружаемую библиотеку (DLL), которую клиентское приложение может загрузить в свое адресное пространство и использовать для доступа к источнику данных. Для каждой используемой СУБД нужен собственный ODBC-драйвер, так как ODBC-драйверы используют функции клиентских API, разные для различных СУБД.

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

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

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

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

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

Среди OLE DB-провайдеров для разных источников данных имеется специальный провайдер Microsoft OLE DB Provider for ODBC Drivers. Этот провайдер использует не API клиентской части какой-либо СУБД, а интерфейс ODBC API, поэтому он применяется вместе с ODBC-драйвером для выбранной СУБД.

Отметим, что ADO становится все более популярным способом доступа к данным, так как входит в состав таких широко используемых продуктов, как Microsoft Office 2000 и Microsoft Internet Explorer 5.0, а также включен в ядро операционных систем семейства Windows 2000.

в) BDE (Borland Database Engine) — универсальный механизм доступа к данным, применяемый в средствах разработки фирмы Borland (а именно — Delphi и C++Builder), а также в некоторых других продуктах, например Corel Paradox, Corel Quattro Pro, Seagate Software Crystal Reports.

BDE — это наследник библиотеки Paradox Engine, созданной для Borland Pascal и Borland C++ с целью предоставить приложениям, разработанным с их помощью, доступ к таблицам СУБД Paradox. Вскоре после создания Paradox Engine компанией Borland было разработано несколько библиотек-драйверов под общим названием SQL Links. Эти библиотеки расширили функциональность BDE, позволив применять имевшийся в Paradox Engine набор функций для доступа к данным dBase, ODBC-источников, а также наиболее популярных серверных СУБД. Позже к этому набору были добавлены библиотеки для доступа к Access и FoxPro.

Механизм Borland Database Engine широко использовался при создании приложений с базами данных с помощью Borland Pascal 7.0 и Borland C++ 4.5 и 5. Затем средства разработки Borland были преобразованы в средства быстрой разработки приложений (Rapid Application Development, RAD), и большинство вызовов BDE API оказалось инкапсулировано в компонентах доступа к данным библиотеки Visual Components Library (VCL). BDE был фактически единственным механизмом доступа к данным в Delphi и C++Builder, поддерживаемым на уровне компонентов, классов, а также визуальных компонентов для редактирования данных, вплоть до 5-й версии обоих продуктов — Delphi и C++Builder.

Физически BDE представляет собой набор библиотек доступа к данным, реализующих BDE API — набор функций для манипуляции данными, вызываемых из приложения. Эти функции, в свою очередь, могут обращаться к функциям клиентского API (в случае, например, Oracle, Informix, IB Database) или ODBC API (Access 2000, Microsoft SQL Server 7.0, любые ODBC-источники), а также непосредственно манипулировать файлами некоторых СУБД (dBase, Paradox).

Для доступа к базе данных с помощью BDE на компьютере, содержащем клиентское приложение, должны быть установлены библиотеки BDE общего назначения, а также BDE-драйвер для данной СУБД. В случае серверных СУБД такие драйверы носят название SQL Links. Эти драйверы содержат BDE API — стандартный набор функций, созданных на основе функций клиентских API соответствующих СУБД. Использование рассматриваемых механизмов доступа описано в [10, 15, 16, 17].

 

3.2 Задание на расчетно-графическую работу

Выбор программного обеспечения для разработки приложения произвольный по желанию студента (С++ или Delphi).       

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

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

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

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

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

 

Приложение А

Задания к расчетно-графическим работам

 

Таблица А.1 – Варианты заданий

№

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

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

1

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

Какие товары имеют продажную цену более 200$?  Какие из них имеют закупочную цену менее 150$? Какие товары           произведены в Индии? Кто их изготовители? Кто из продавцов продал товары ценой более 500$? Даты этих продаж? Какова зарплата этих продавцов?  Сколько сделок  оформил торговый агент в Латинской Америке? Сколько наличного количества каждого товара с указанием средней стоимости и текущей цены осталось на указанную дату?

2

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

Сколько клиентов в банке? Какой процент  обладателей текущих счетов банка составляют его служащие? Сколько кассиров имеют в банке сберегательные  счета? Сколько менеджеров? Сколько кассиров не имеют таких счетов? Как связаться с клиентом банка? Сколько женщин открыли текущие счета 5 декабря  2010 года? У кого из  клиентов есть и текущие, и сберегательные счета? У скольких клиентов несколько текущих счетов? Сколько юридических лиц являются клиентами банка?       

3

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

 

В каком конструкторском бюро спроектированы выбранные детали? Если в детали обнаружен брак, то можно ли проследить, где она спроектирована и где  произведена? Какое количество деталей А235 находится на указанном складе? Кто работал над проектом детали А245? Адрес конструкторского бюро, где проектировалась деталь В205. Адреса заводов-изготовителей.

Продолжение таблицы А.1

4

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

Сколько сотрудников в каждой из указанных групп?  Сколько вакансий (с учётом сотрудников, находящихся в отпуске по уходу за ребенком, т.е. с указанием даты, до которой ставка свободна)? Сколько пенсионеров? Сколько профессор на каждой кафедре? Кто из сотрудников работает на неполную ставку? Кто работает более чем на одной ставке?  Заработная плата технического персонала (по категориям).

5

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

Какой максимальный объем памяти возможен у IBM PC, у Macintosh II? У кого из служащих в кабинете есть Macintosh? У кого стоит компьютер с серийным номером 4538842?  Какова его оперативная память? Кто является администратором в аудитории А402? Какое программное обеспечение установлено в бухгалтерии? Перечень компьютеров, установленных для индивидуального использования.

6

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

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

 

Продолжение таблицы А.1

7

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

 

Какие станции транслируют программу “Своя игра”? Какие коммерческие объявления компания показала более трех раз в течение одного часа на одной станции? Когда это было? Какая плата назначена за трансляцию каждого из этих коммерческих объявлений? Когда транслировались футбольные матчи? Был ли показан теннисный турнир с участием Анны Курниковой?

8

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

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

9

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

Сколько посадочных мест в Боинге-727? Сколько у него двигателей? Какой средний возраст Боингов-727 нашего авиапарка? Кто главный механик, ответственный за обслуживание самолета номер 1388?  Какая компания создала этот самолет? Список членов экипажа, выполнявших  рейс на Стамбул в прошлый понедельник.

10

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

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

Продолжение таблицы А.1

11

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

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

12

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

 

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

13

Регистратура поликлиники ведет учет списка лечащих врачей с указанием квалификации и специализации; ведение медицинских карт пациентов.

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

14

Адвокатская контора осуществляет ведение списка адвокатов; ведение списка клиентов; ведение архива законченных дел.

 

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

Продолжение таблицы А.1

15

Регистратура больницы ведет учет поступления пациентов (по отделениям и палатам);  учёт проведённого лечения; учёт платных услуг с выдачей счетов на оплату; ведение архива выписанных пациентов.

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

16

Фирма занимается продажей и арендой жилых и нежилых помещений: осуществляет ведение списков жилых и нежилых помещений, предназначенных для аренды и/или продажи; поддерживает архив проданных и сданных в аренду помещений; производит поиск вариантов в соответствии с требованиями клиента.

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

17

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

 

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

18

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

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

Продолжение таблицы А.1

19

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

 

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

20

База данных школы должна осуществлять: ведение списка учеников и учителей; ведение списка классных руководителей и количества учеников в классах; ведение расписания занятий; учет посещаемости и успеваемости учеников.

 

Необходимо предусмотреть: составление табелей; составление расписаний экзаменов по классам, для отдельных преподавателей; проверка корректности расписания экзаменов (уникальность комбинации "время – дата – аудитория"; подсчёт по результатам экзаменов итоговых значений (количество оценок '5', '4', '3', '2', количество неявок, средний балл по классу); получение списка экзаменов на текущую дату.

21

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

Необходимо предусмотреть: оформление заказов по столам; выписку счетов клиентам; учёт заказов и выписанных счетов; подведение финансовых итогов дня (по типам блюд и в целом по ресторану); анализ результативности работы официантов (для начисления бонусов); анализ объёмов выручки по дням недели и по месяцам.

22

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

Составление зачётных и экзаменационных ведомостей;  составление расписаний экзаменов по группам, кафедрам, для отдельных преподавателей; проверка корректности расписания экзаменов (уникальность комбинации «время – дата – аудитория»; между экзаменами в одной группе должно пройти не менее трёх дней); подсчёт итоговых значений по результатам зачётов и экзаменов (количество оценок '5', '4', '3', '2', количество неявок, средний балл по группе); получение списка экзаменов на текущую дату.

 

Продолжение таблицы А.1

23

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

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

24

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

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

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

25

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

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

26

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

Необходимо предусмотреть: получение списка клиентов по мастерам; выдачу информации о предоставляемых услугах; подведение финансовых итогов по выполнению заказов в целом и по мастерам; анализ объемов выполненных заказов по месяцам и кварталам; подбор мастера и типа изделия в соответствии с требованиями клиентов.

  

Окончание таблицы А.1

27

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

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

28

База данных телеателье должна осуществлять: ведение списка мастеров и их специализации; ведение списка клиентов; учёт данных о принятых заказах и их выполнении; ведение списка типов выполняемых работ и цен на них.

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

29

База данных транспортных касс (выбрать вид транспорта) должна осуществлять: ведение списка рейсов и билетов на них с указанием класса; учёт забронированных мест; ведение архива пассажиров за последний месяц.

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

30

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

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

 

Список литературы 

1 Джоунс Э., Стивенз Р., Плю Р., Гарретт Р., Кригель А. Функции SQL. Справочник программиста. – М.: Диалектика, 2006.

2 Дейт К.Дж. Введение в системы баз данных. — М.: Издательский дом «Вильямс», 2008.

3 Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. — М.: Издательский дом «Вильямс», 2003.

4 Кузнецов С.Д. Основы баз данных. — 1-е изд. — М.: «Интернет-университет информационных технологий - ИНТУИТ.ру», 2005.

5 Харрингтон Дж. Разработка баз данных. – М.: ДМК Пресс, 2005.

6 Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. - Базы данных. Учебник для вузов. – М.: Корона-Принт, 2004.

7 SQL Server 2005. Реализация и обслуживание. //Серия: Учебный курс Microsoft SQL. – СПб.: Питер, Русская редакция, 2007. 

8 Хансен Г., Хансен Д. Базы данных: разработка и управление. – М.: ЗАО «Издательство БИНОМ», 1999.                        

9 Плю Р., Стефенс Р.,  Райан К. Освой самостоятельно SQL за 24 часа. – М.: Издательский дом «Вильямс», 2000.                                                              

10 Кандзюба С.П., Громов В.Н. Delphi 6/7. Базы данных и приложения. – СПб: ООО «ДиаСофтЮП», 2002.

11 Григорьев Ю. А., Ревунов Г. И. Банки данных. – М.: Изд. МГТУ им. Н. Э. Баумана, 2002.

12      Харрингтон Д. Проектирование реляционных баз данных просто и доступно. – М.: Изд. «Лори», 2000.

13   Иванова Г.С. Технология программирования. - М.: Изд-во МГТУ им. Н.Э.Баумана, 2002.

14   Мандел Т. Разработка пользовательского интерфейса. – М.: ДМК Пресс, 2001.

15   Фленов В. Библия Delphi. – СПб.: БХВ-Петербург, 2008.

16   Архангельский А.Я. C++ Builder 6. Справочное пособие. Книга 1. Язык С++. – М.: Бином-Пресс, 2002.

17   Архангельский А.Я. C++ Builder 6. Справочное пособие. Книга 2. Классы и компоненты. – М.: Бином-Пресс, 2002.

 

Содержание 

1 Расчетно-графическая работа. Системный анализ моделируемой

предметной области. Разработка концептуальной модели                                        3

2 Расчетно-графическая работа. Реализация разработанного проекта

в среде выбранной СУБД                                                                                           10

3 Расчетно-графическая работа. Разработка клиентского приложения           13

Приложение А                                                                                                    18

Список литературы                                                                                            26