Реферат: Е. П. Балакина Рекомендовано редакционно-издательским

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ПУТЕЙ СООБЩЕНИЯ (МИИТ)

___________________________________________________________

Кафедра «Управление и информатика в технических системах»


М.А. Васильева

Е.П. Балакина


Рекомендовано редакционно-издательским

советом университета в качестве методических указаний

к курсовому проектированию

для студентов специальности

«Управление и информатика в технических системах»


Москва – 2007


УДК 681.3.06


В-19


Васильева М.А. Балакина Е.П. Методические указания к курсовому проектированию по дисциплине «Информационное обеспечение систем управления».- М.:МИИТ, 2007. –32с.

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

Предназначено для студентов специальности «Управление и информатика в технических системах».


©Московский государственный

университет путей сообщения

(МИИТ), 2007
^ Цель курсового проекта
Целью курсового проекта является изучение методов и закрепление знаний в проектировании локальных реляционных баз данных в среде программирования DELPHI и системе управления базами данных Paradox.

^ ЗАДАНИЕ НА КУРСОВОВОЙ ПРОЕКТ
В данном курсовом проекте разрабатывается локальная реляционная база данных (БД) в среде программирования DELPHI и системе управления базами данных (СУБД) Paradox по заданной теме. Проектирование БД проводится с помощью метода «Сущность-связь». Проверка построенной модели БД осуществляется с помощью метода нормализации отношений. Пояснительная записка должна содержать пункты по проектированию БД (см. раздел 3), пункты по разработке БД в среде программирования DELPHI (текст программы доступа к БД, разработка интерфейса программы) и демонстрацию выполняемых функций и реализаций запросов в виде рисунков. Пояснительная записка оформляется по ГОСТу «Правила оформления технической документации и НИР» - 2000г.

^ Понятие реляционной модели данных
Реляционная модель данных основывается на математических принципах, которые вытекают из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, а впервые опубликованы - в 1970 г. [1]. Тогда же появились первые прототипы реляционных систем управления базами данных (СУБД), но долгое время считалось невозможным добиться эффективной реализации таких систем. Постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.

Техническая статья "Реляционная модель данных для больших разделяемых банков данных" доктора Е.Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. Доктор Кодд определил 12 правил реляционной модели (которые называют 12 правилами Кодда).

12 правил Кодда

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

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

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

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

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

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

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

Вставка, обновление и удаление - СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление

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

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

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

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

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

Кодд предложил применение реляционной алгебры в СУРБД, для разбиения данных в связанные наборы. Он организовал свою систему БД вокруг теории, основанной на наборах данных [1].

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

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

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

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

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

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

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

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

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

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

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

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

Сущность - некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных, имеющий определенный набор свойств - атрибутов. Сущности могут быть как физические (реально существующие объекты: например, СТУДЕНТ, атрибуты - № зачетной книжки, фамилия, его факультет, специальность, № группы и т.д.), так и абстрактные (например, ЭКЗАМЕН, атрибуты - дисциплина, дата, преподаватель, аудитория и пр.). Для сущностей различают ее тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр - конкретными значениями свойств.

Атрибуты сущности бывают:

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

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

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

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

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

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

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

Существует несколько типов связей между двумя сущностями: это связи "один- к- одному", "один –ко- многим" и "многие- ко- многим".

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

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

Диаграмма "сущности-связи" (Entity-Relationship diagrams, или ER diagram) служит для описания схемы базы на концептуальном уровне проектирования. Метод был предложен в 1976 г. Питером Пин Шань Ченом (Peter Pin Shan Chen) [2].

В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм "сущность-связь" исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями [3].

Рассмотрим последовательность действий, которые необходимо провести, чтобы построить ER-диаграмму по нотации Баркера:

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

В выписанном списке требований к БД, подчеркнуть все существительные. Это будут будущие сущности.

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

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

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

Полученная диаграмма называется ER-диаграммой. После написания ER –диаграммы требуется ее анализ с последующим уточнением, если потребуется. Если на ER-диаграмме присутствуют связи «многие – ко - многим», то такую связь нужно разделить на две «один – ко многим» с помощью дополнительной сущности.

Если необходимо, строится уточненная ER-диаграмма, в которой отсутствуют связи «многие – ко - многим». Полученная схема является прототипом будущей БД: сущности являются таблицами, атрибуты – полями. Все связи можно реализовать стандартными средствами СУБД.

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

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

В рамках реляционной модели данных Э.Ф. Коддом были разработаны принципы нормализации отношений .

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

Первая нормальная форма (1НФ) связана с понятиями простого и сложного атрибутов. Простой атрибут - это атрибут, значения которого атомарны (т.е. неделимы). Сложный атрибут может иметь значение, представляющее собой объединение нескольких значений одного или разных доменов. В первой нормальной форме устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.

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

Вторая нормальная форма (2НФ) применяется к отношениям с составными ключами (состоящими из двух и более атрибутов) и связана с понятиями функциональной зависимости. Если в любой момент времени каждому значению атрибута A соответствует единственное значение атрибута B, то B функционально зависит от A (AB). Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального ключа. Эта часть уникального ключа определяет отдельную сущность.Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа (ПК).

Третья нормальная форма (3НФ) связана с понятием транзитивной зависимости. Пусть A, B, C - атрибуты некоторого отношения. При этом AB и BC, но обратное соответствие отсутствует, т.е. C не зависит от B или B не зависит от A. Тогда говорят, что C транзитивно зависит от A (AC). В третьей нормальной форме устраняются атрибуты, которые зависят от атрибутов, не входящих в уникальный ключ. Эти атрибуты являются основой отдельной сущности. Отношение находится в 3НФ, если оно находится во 2НФ и не имеет атрибутов, не входящих в ПК и находящихся в транзитивной зависимости от ПК [4].

Существуют также нормальная форма Бойса-Кодда (НФБК), 4НФ и 5НФ.

НФБК стоит особняком от всех НФ. Для того, чтобы отношение находилось в НФБК не нужно, чтобы оно было в 3НФ. Если в отношении имеется несколько потенциальных ключей, то оно не подходит под формулировку 3НФ, т.к. не все атрибуты зависят только от первичного ключа, они могут зависеть и от потенциальных ключей. Для таких отношений и была задумана НФБК, которая гласит: отношение находится в НФБК в том случае, если все атрибуты находятся в функциональной зависимости от потенциального ключа. Например, в отношении определены следующие атрибуты: №п/п, № зачетной книжки, ФИО студента, оценка. В данном отношении определен ПК - №п/п. Атрибуты ФИО и оценка зависят как от ПК, так и от № зачетной книжки. Следовательно данное отношение не находится в 3НФ, оно находится в НФБК, т.к. атрибут № зачетной книжки может быть выбран в качестве ПК, т.е. является потенциальным ключом.

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

Моделирование структуры базы данных при помощи алгоритма нормализации имеет серьезные недостатки: методика нормализации предполагает первоначальное размещение всех атрибутов проектируемой предметной области в одном отношении, что является очень неестественной операцией. Интуитивно разработчик сразу проектирует несколько отношений в соответствии с обнаруженными сущностями. Даже если совершить насилие над собой и создать одно или несколько отношений, включив в них все предполагаемые атрибуты, то совершенно неясен смысл полученного отношения. Невозможно сразу определить полный список атрибутов. Пользователи имеют привычку называть разными именами одни и те же вещи или наоборот, называть одними именами разные вещи. Для проведения процедуры нормализации необходимо выделить зависимости атрибутов, что тоже очень нелегко [4].

В реальном проектировании структуры базы данных применяются другой метод - так называемое семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опирающееся на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм "сущность-связь (ER)" c построением концептуальной модели базы данных. Обычно проектирование с помощью ER-диаграмм позволяет построить БД, нормализованную до 3НФ или НФБК. Нормализацию удобно применять для проверки ER-модели.

^ СПИСОК ЗАДАНИЙ
БД «Аптека».

Описание предметной области. База данных создаётся для информационного обслуживания посетителей аптеки. В аптеку города поступает ассортимент лекарств со склада каждые 7 дней. Аптека предлагает услуги по продаже лекарств и их бронированию. Срок бронирования лекарств - 3 дня. В справочной аптеки можно получить информацию о лекарствах, находящихся в аптеке: название, форма выпуска, срок годности, аннотация, цена, изготовитель.

Готовые запросы

Выдавать данные о лекарствах;

Предоставлять покупателям возможность бронирования лекарств, сроком на 3 дня;

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

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

Выполнять поиск лекарства по названию, форме выпуска, изготовителю;

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

^ БД «Поликлиника».

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

Готовые запросы:

Выдавать сводную информацию обо всех врачах поликлиники;

Выдавать сводную информацию о пациентах;

Выдавать информацию о записи пациента к врачу;

Выдавать информацию о приеме врачей на указанную дату;

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

^ БД «ВУЗ».

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

Готовые запросы:

Выдавать информацию о студенте по № зачетной книжки, по ФИО;

Выдавать список предметов, читаемых данной кафедрой;

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

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

^ БД «Складской учет»

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

Готовые запросы:

Выдавать ассортимент товара, находящегося на складе сейчас;

Выдавать ассортимент товара, заказанного данным магазинов;

Показывать список продаж за указанный период времени;

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

БД «Отдел кадров»

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

^ Готовые запросы:

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

Выдавать информацию о должностях сотрудников.

Выдавать информацию о предыдущих местах работы сотрудников.

Находить сотрудников по ФИО.

БД «Кафедра»

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

Готовые запросы:

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

Выдавать информацию о НИР;

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

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

^ БД «Больница»

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

Готовые запросы:

Выдавать сведения о мед.работниках;

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

Выдавать сведения о пациентах;

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

Выдавать нахождение пациентов по палатам.

БД «Контора адвоката»

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

Готовые запросы:

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

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

Выдавать список свободных адвокатов по выбранной услуге;

Выдавать содержание Дела по его номеру.

БД «Архив»

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

Готовые запросы:

Выдавать список Дел по ФИО осужденного;

Выдавать список дел, которые вел данный следователь;

Находить Дела по содержанию;

Выдавать список Дел по данной статье преступления (по характеру преступления).

БД «Продажа билетов»

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

Готовые запросы:

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

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

Выдавать информацию о цене билета на данный сеанс и данный фильм.

Выдавать информацию о кратком содержании, задействованных актерах и режиссерах данного фильма;

Продавать билет на выбранный сеанс данного фильма;

Отражать продажи по сеансам (например, в виде диаграммы).

^ БД «Магазин обуви»

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

Готовые запросы:

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

Выдавать ассортимент обуви по отделам, сезону;

Выдавать информацию об данной обуви (цена, страна изготовитель);

Продавать выбранный товар;

Показывать продажи за выбранный период времени (например, в виде диаграммы).

БД «Библиотека»

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

Готовые запросы:

Выдавать список книг по названию;

Выдавать список трудов данного автора (учитывать труды, выполненные в соавторстве);

Выдавать список книг по данной тематике;

Выдавать список книг данного издательства;

Выдавать местонахождение данной книги.

БД «Издательство»

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

^ Готовые запросы:

Выдавать список трудов данного автора (учитывать труды, выполненные в соавторстве);

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

Выдавать информацию о данном авторе;

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

^ БД «Автосервис»

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

Готовые запросы:

Выдавать список услуг, предлагаемых автосервисом с ценой;

Выдавать список машин, находящихся в автосервисе;

Выдавать информацию о данной машине (оказываемые услуги);

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

Рассчитывать стоимость услуг для клиентов.

^ БД «Транспортная компания»

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

Готовые запросы:

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

Выдавать список транспорта, занятого на данном маршруте;

Выдавать список вариантов проезда по данному маршруту (морской и т.д.);

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

Показывать грузооборот по данному маршруту.



^ БД «Туристическое бюро»

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

Готовые запросы:

Выдавать список стран;

Выдавать список городов;

Покупать путевку в выбранное место с расчетом ее стоимости;

Показывать весь ассортимент путевок в данное место;

Выбирать путевку по содержанию, по цене и т.д.

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

БД «ГАИ»

Описание предметной области. БД создается для информационного обслуживания работников ГАИ. В БД находятся автомобили, зарегистрированные по данному адресу. Некоторые из них угнаны.

^ Готовые запросы:

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

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

Выдавать информацию об автомобиле (прошлые автовладельцы, аварии и т.д.) по номеру двигателя;

Выдавать список угнанных автомобилей;

Выдавать список автомобилей, попавших в аварию в данный период времени;

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

БД «Гостиница»

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

^ Готовые запросы:

Предоставлять (и бронировать) посетителям номер в гостинице в зависимости от потребностей посетителя (количество мест и т.д.);

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

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

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

^ БД «Строительная компания»

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

Готовые запросы:

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

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

Показывать работу, проводимую данной бригадой;

Показывать список работ, проводимых у данного заказчика;

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

БД «Компания по услугам связи»

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

Готовые запросы:

Показывать список услуг;

Показывать список тарифов и цену за единицу услуги;

Показывать список абонентов по данному тарифу;

Показывать список самых распространенных тарифов;

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

^ БД «Школа»

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

Готовые запросы:

Показывать список учащихся данного класса;

Показывать классного руководителя данного класса;

Показывать занятость данного учителя;

Показывать успеваемость данного ученика;

Показывать список учеников, учащихся без троек (можно в % отношении в виде диаграммы);

БД «Детский сад»

Описание предметной области. БД создается для информационного обслуживания администрации детского сада. В сад ходят дети с 2 до 7 лет. Тем, кому меньше 3 лет в сентябре ходят в ясли. В каждой группе имеется 2 воспитателя (один -утром, другой -вечером) и нянечка. Детей в группе не больше 15 человек. С детьми проводятся занятия музыки, физкультуры и рисования в отдельных комнатах по 2 раза в неделю. Обязательно с детьми 2 раза в день гуляют.

Готовые запросы:

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

Показывать список детей данного возраста;

Показывать занятость данного педагога;

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

Показывать % отношение мальчиков и девочек в данной группе (например, в виде диаграммы);

Находить название (№) группы по ФИО ребенка.

^ БД «Кондитерская фабрика»

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

Готовые запросы:

Показывать список магазинов, заказывающих данный товар;