МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ
РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение высшего образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
БАЗЫ ДАННЫХ
Методические рекомендации
к выполнению курсовой работы
Санкт-Петербург
2021
Составители: В. А. Галанина, Л. А. Решетов
Рецензент – кандидат технических наук О. Л. Балышева
Приводятся методические рекомендации к выполнению курсовой
работы по проектированию реляционной базы данных.
Дается описание основных этапов построения базы данных, начиная с этапа построения информационной модели предметной области
и заканчивая программной реализацией.
Приводится описание правил оформления курсовой работы и содержание пояснительной записки.
Приводится перечень примерных тем курсовой работы.
Приведенные материалы соответствуют ФГОС и рабочим программам дисциплин соответствующих направлений и специальностей.
Рекомендовано для студентов, обучающихся по следующим направлениям и специальностям: 090303, 270301,270502, но могут
быть полезны и для студентов других направлений и специальностей.
Публикуется в авторской редакции.
Компьютерная верстка Ю. В. Умницыной
Подписано к печати 00.00.00. Формат 60 × 84 1/16.
Усл. печ. л. 0,0. Тираж 50 экз. Заказ № 000.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
© Санкт-Петербургский государственный
университет аэрокосмического
приборостроения, 2021
ВВЕДЕНИЕ
Данные методические рекомендации содержат методические
и практические рекомендации к курсовому проектированию по
дисциплине «Базы данных». Курсовое проектирование является
завершающим этапом в изучении данной дисциплины. В ходе выполнения курсовой работы студенты получают практические навыки реализации технологий проектирования реляционной модели
данных, принципов разработки структуры представления данных
в реляционных базах данных; методов и средств обработки данных,
хранящихся в базе данных (БД);
Проектирование БД начинается с изучения и анализа объекта,
для которого создаётся БД. Поэтому до начала создания БД нужно ясно представить, какая информация должна присутствовать
в базе данных, что она характеризует, и каким образом организуются связи между информационными массивами. Необходимо
четко осознать и сформулировать цель создания базы данных, ее
назначение и определить порядок ее использования. В пособии рассматриваются все этапы проектирования базы данных на примере
небольшой фирмы.
Базой для реализации курсового проектирования является комплекс лабораторных работ, который студенты выполняли в предыдущем семестре и соответствующие методические рекомендации
[1].
3
1. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ
Проектирование базы данных независимо от области ее использования включает ряд обязательных этапов, важнейшими из которых являются следующие:
1. Построение информационной модели предметной области.
2. Построение инфологической модели (ER-диаграммы).
2.1. Определение объектов (сущностей) предметной области –
источников данных, которые должны быть включены в базу данных
2.2. Определение атрибутов каждой сущности
2.3. Выявление связей между сущностями
2.4. Определение типа каждой выделенной связи (один-кодному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность
включения каждого экземпляра сущности в связь
2.5. Построение ER-диаграмм, отображающих выявленные связи
3. Формирование реляционной базы данных по ER-диаграммам
3.1. Определение ключевых полей таблиц
3. 2. Нормализация базы данных
4. Выбор СУБД.
5. Программирование базы данных.
Разработка объектов базы данных (таблицы, формы, запросы,
отчеты)
6. Разработка пользовательского интерфейса.
Рассмотрим более подробно каждый из этих этапов.
2. ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ
ПРЕДМЕТНОЙ ОБЛАСТИ
Этап построения информационной модели предметной области
является наиболее ответственным и важным этапом во всем процессе проектирования БД. Под предметными областями понимаются конкретные реальные объекты, системы или процессы, информацию о которых необходимо хранить, обрабатывать и выдавать по
запросу пользователя. Информационные модели являются особым
видом моделей систем, предназначенных для информационного
описания и последующего компьютерного моделирования. От того,
насколько корректно будет построена эта модель зависит эффективность функционирования всей базы данных при дальнейшем ее
использовании.
4
Процесс создания информационной модели начинается с определения концептуальных требований будущих пользователей БД.
В соответствии с терминологией ANSI/SPARC представление отдельного пользователя называется внешним представлением. Таким образом, внешнее представление – это содержимое базы данных, каким видит его определенный пользователь (то есть для этого пользователя внешнее представление и есть база данных) [3].
Для создания внешнего представления пользователей проводится так называемое предпроектное обследование предприятия
для которого проектируется база данных. Во всем процессе разработки базы данных значение этого этапа трудно переоценить. Поэтому подходить к этому этапу необходимо весьма серьезно. При
этом усилия разработчика должны быть направлены в основном на
структуризацию данных, с которыми работают будущие пользователи БД и выявление взаимосвязей между ними. В течение этого
этапа разработчику необходимо получить ответ на следующие вопросы:
1. какие отделы предполагается включить в состав разрабатываемой базы данных;
2. какие рабочие места в этих отделах подлежат автоматизации;
3. какие функциональные обязанности сотрудников на этих местах предполагается автоматизировать;
4. с какими документами эти сотрудники работают;
5. на какие запросы к проектируемой БД эти сотрудники должны получать ответы.
Ответ на первый вопрос обычно может быть получен при беседах
с представителями руководства фирмы или специальным работником , выделенным для этих целей. Результатом на данном этапе является структурная схема предприятия с указанием отделов и их
описанием (номер отдела, название, количество сотрудников, руководитель, телефон и т. д.).
Ответы на следующие вопросы получаются непосредственно
в отделах с помощью опроса сотрудников. Основная цель на данном
этапе состоит в том, чтобы получить общую и как можно более полную картину структуры базы данных, которую потом, возможно,
все же придется уточнять при построении инфологической модели.
При этом следует иметь в виду, что внесение изменений в уже спроектированную базу данных представляет собой гораздо более сложную задачу, нежели проектирование на первоначальном этапе.
На каждом рабочем месте необходимо тщательно расспрашиваться сотрудника, какие функциональные обязанности он вы5
полняет. Например, если вам предстоит автоматизировать рабочее
место менеджера по сопровождению договоров с клиентами, то вы
должны задать примерно следующие вопросы:
• сопровождением договоров какого вида он занимается (с покупателем или поставщиком)
• тип договора (предоставление услуг, аренда, поставка продукции);
• на какой стадии (подготовка, согласование или исполнение);
• ответственные за исполнение договора как со стороны организации, так и со стороны контрагента и т. д.
• порядок согласования договоров службами компании.
порядок учета и хранения заключенных договоров с возможностью
быстрого поиска оригиналов необходимых документов;
• типовая форма договора, прошедшая юридическую экспертизу, на основе которой может быть составлен проект любого договора;
Проанализировав типовую форму договора, необходимо зафиксировать, какие данные включаются в договор и откуда эти данные
поступают (вносятся непосредственно менеджером или берутся из
других источников).
По результатам опроса строится таблица, включающая все данные, необходимые для работы с договором на данном рабочем месте.
Заключительным этапом опроса является выяснение перечня
запросов к БД, например
• по указанному контрагенту собираются все действующие обязательства за период. Отчет содержит:
– сумму всех обязательств;
– исполненные платежи (стоимость выполненных поставок);
– дебиторскую задолженность (стоимость непоставленных товаров);
• график платежей по дням на основании срока действия договора и условий оплаты;
• отчет по неисполненные финансовым обязательствам, срок
действия которых истек;
• текущие данные об исполнении договоров:
– по подразделению, за которым числятся договоры (по центрам
финансовой ответственности);
– по ответственным исполнителям;
– по статьям планирования;
и т. д.
6
Аналогичные опросы необходимо провести во всех остальных
подразделениях предприятия. Результатом должен быть набор таблиц, которые содержат всю необходимую информацию, которая
должна содержаться в базе данных.
Следующим этапом проектирования БД является этап структурирования полученных данных и создание непосредственно инфологической модели.
3. ПОСТРОЕНИЕ ИНФОЛОГИЧЕСКОЙ МОДЕЛИ.
(ER–ДИАГРАММА)
Рассмотрим построение инфологической модели базы данных
на примере.
Предположим, что перед нами стоит задача разработать базу
данных по заказу некоторой оптовой торговой фирмы
При разработке ER-моделей мы используем построенную ранее
информационную модель предметной области. Из этой модели мы
выделяем:
1. Список сущностей предметной области.
2. Список атрибутов сущностей.
3. Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей,
атрибутов и связей является итерационным. Разработав первый
приближенный вариант диаграмм, мы уточняем их, опрашивая
экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:
• Хранить информацию о покупателях.
• Печатать накладные на отпущенные товары.
• Следить за наличием товаров на складе.
Выделим все существительные в этих предложениях – это будут
потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):
• Покупатель – сущность.
• Накладная – сущность.
• Товар – сущность
• (?)Склад – а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
• (?)Наличие товара – это, скорее всего, атрибут, но атрибут
какой сущности?
7
Сразу возникает очевидная связь между сущностями – «покупатели могут покупать много товаров» и «товары могут
продаваться многим покупателям». Первый вариант диаграммы приведен на рис. 1.
Задав дополнительные вопросы менеджеру, мы выяснили, что
фирма имеет несколько складов. Причем, каждый товар может
храниться на нескольких складах и быть проданным с любого
склада.
Куда поместить сущности «Накладная» и «Склад» и с чем их
связать? Как связаны эти сущности между собой и с сущностями
«Покупатель» и «Товар»? Будем рассуждать следующим образом.
Покупатели покупают товары, получая при этом накладные,
в которые внесены данные о количестве и цене купленного товара.
Каждый покупатель может получить несколько накладных.
Каждая накладная обязана выписываться на одного покупателя.
Каждая накладная обязана содержать несколько товаров (не
бывает пустых накладных). Каждый товар, в свою очередь, может
быть продан нескольким покупателям через несколько накладных.
Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных.
Таким образом, после уточнения, диаграмма будет выглядеть
следующим образом (рис. 2).
Следующим шагом к построению ER-диаграммы является определение атрибутов выделенных сущностей.
Проведя опрос сотрудников фирмы, было выяснено следующее:
• Каждый покупатель является юридическим лицом и имеет
наименование, адрес, банковские реквизиты.
• Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
• Каждая накладная имеет уникальный номер, дату выписки,
список товаров с количествами и ценами, а также общую сумму
ПОКУПАТЕЛЬ
Покупать
ТОВАР
Быть проданным
Рис. 1. Связь «ПОКУПАТЕЛЬ» – «ТОВАР»
8
ПОКУПАТЕЛЬ
Получать
Выписываться на
НАКЛАДНАЯ
Содержать
Выписываться с
Выписывать
ТОВАР
Содержаться
СКЛАД
Храниться на
Хранить
Рис 2. Диаграмма СУЩНОСТЬ-СВЯЗЬ
накладной. Накладная выписывается с определенного склада и на
определенного покупателя.
• Каждый склад имеет свое наименование.
Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
• Юридическое лицо – термин риторический, мы не работаем
с физическими лицами. Не обращаем внимания.
• Наименование покупателя – явная характеристика покупателя.
• Адрес – явная характеристика покупателя.
• Банковские реквизиты – явная характеристика покупателя.
• Наименование товара – явная характеристика товара.
• (?)Цена товара – похоже, что это характеристика товара.
Отличается ли эта характеристика от цены в накладной?
• Единица измерения – явная характеристика товара.
• Номер накладной – явная уникальная характеристика накладной.
• Дата накладной – явная характеристика накладной.
• (?)Список товаров в накладной – список не может быть
атрибутом. Вероятно, нужно выделить этот список в отдельную
сущность.
• (?)Количество товара в накладной – это явная характеристика, но характеристика чего? Это характеристика не просто «товара», а «товара в накладной».
9
• (?)Цена товара в накладной – опять же это должна быть не
просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше – это одно и то же?
• Сумма накладной – явная характеристика накладной. Эта
характеристика не является независимой. Сумма накладной равна
сумме стоимостей всех товаров, входящих в накладную.
• Наименование склада – явная уникальная характеристика
склада.
В ходе дополнительной беседы с менеджером удалось прояснить
различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем.
Цена одного и того же товара в разных накладных, выписанных
в разное время, может быть различной. Таким образом, имеется две
цены – цена товара в накладной и текущая цена товара.
С возникающим понятием «Список товаров в накладной»
все довольно ясно.
Сущности «Накладная» и «Товар» связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали
ранее, должна быть расщеплена на две связи типа один-ко-многим.
Для этого требуется дополнительная сущность. Этой сущностью и
будет сущность «Список товаров в накладной». Связь ее с сущностями «Накладная» и «Товар» характеризуется следующими
фразами :
– «каждая накладная обязана иметь несколько записей из списка товаров в накладной»,
– «каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную»,
– «каждый товар может включаться в несколько записей из
списка товаров в накладной»,
– « каждая запись из списка товаров в накладной обязана быть
связана ровно с одним товаром».
Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами сущности « Список товаров в накладной».
Точно также поступим со связью, соединяющей сущности
«Склад» и «Товар». Введем дополнительную сущность «Товар на
складе». Атрибутом этой сущности будет «Количество товара
на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму (рис. 1.6).
10
ПОКУПАТЕЛЬ
Номер покупателя
Наименование
покупателя
Адрес
Банковские
реквизиты
НАКЛАДНАЯ
Номер накладной
Дата накладной
Сумма накладной
ТОВАР
Номер товара
Наименование товара
Единица измерения
Текущая цена
СКЛАД
Номер склада
Наименование склада
СПИСОК ТОВАРА
Количество товара
Цена товара
ТОВАР НА СКЛАДЕ
Количество товара
на складе
Рис. 3. ER-диаграмма (логический уровень)
Разработанный пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной
диаграмме можно построить физическую диаграмму, которая уже
будут учитываться такие особенности СУБД, как допустимые типы и
наименования полей и таблиц, ограничения целостности и т. п. Физический вариант диаграммы обычно называется схемой данных.
4. ФОРМИРОВАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ
ПО ER-ДИАГРАММАМ
После того, как построена ER-диаграмма ее необходимо трансформировать в реляционную модель данных.
Алгоритм преобразования ER-диаграммы в реляционную модель (схему) следующий:
1. Каждая простая сущность (объект на ER-диаграмме) превращается в таблицу. Имя сущности становится именем таблицы (таблицы-сущности).
11
2. Каждый атрибут становится возможным столбцом с тем же
именем; при этом необходимо выбирать более точный формат представления данных.
3. Компоненты уникального идентификатора сущности (уникальные атрибуты объекта) превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый.
4.1. Нормализация базы данных
Для правильного проектирования модели данных применяется
метод нормализации отношений. Нормализация основана на понятии функциональной зависимости атрибутов отношения. Напомним несколько важных моментов из теории нормализации,
которые необходимо будет отразить в пояснительной записке
к курсовому проекту. Более подробно с данной тематикой можно
ознакомиться в [2].
Рассмотрим несколько искусственный прием, который, однако
позволит описать процесс нормализации. Предположим, что мы
проектируем базу данных, в которой должны храниться сведения
о сотрудниках какого-либо предприятия и о проектах, в которых
эти сотрудники участвуют. В результате построения инфологической модели мы определили всего одну сущность СОТРУДНИКИ (что,
конечно, неверно, но для примера удобно). Реляционная таблица
(отношение) для этой сущности представлена на рис. 4.
Построим функциональные зависимости для отношения:
СОТРУДНИКИ (Н_СОТР, ФАМ, Н_ОТД, ТЕЛ, Н_ПРО, ПРОЕКТ,
Н_ЗАДАН)
где
Н_СОТР – табельный номер сотрудника
ФАМ – фамилия сотрудника
Н_СОТР
ФАМ
Н_ОТД
ТЕЛ
Н_ПРО
ПРОЕКТ
Н_ЗАДАН
1
Иванов
1
11-22-33
1
Космос
1
2
Петров
1
11-22-33
1
Космос
2
1
3
3
Иванов
1
Сидоров
Сидоров
2
2
11-22-33
33-22-11
33-22-11
2
1
2
Климат
Космос
Климат
Рис. 4. Отношение СОТРУДНИКИ
12
1
3
2
Н_ОТД – номер отдела, в котором числится сотрудник
ТЕЛ – телефон сотрудника
Н_ПРО – номер проекта, над которым работает сотрудник
ПРОЕКТ – наименование проекта, над которым работает сотрудник
Н_ЗАДАН – номер задания, над которым работает сотрудник
Так как каждый сотрудник в каждом проекте выполняет ровно
одно задание, то в качестве потенциального ключа отношения необходимо взять пару атрибутов {Н_СОТР, Н_ПРО}. На рис. 4 ключевые атрибуты выделены курсивом.
Вообще говоря, даже одного взгляда на таблицу СОТРУДНИКИ
достаточно, чтобы увидеть, что данные хранятся в ней с большой
избыточностью. Во многих строках повторяются фамилии сотрудников, номера телефонов, наименования проектов. Кроме того,
в данном отношении хранятся вместе независимые друг от друга
данные – и данные о сотрудниках, и об отделах, и о проектах, и о
работах по проектам. Пока никаких действий с отношением не производится, это не страшно. Но как только состояние предметной
области изменяется, то, при попытках соответствующим образом
изменить состояние базы данных, возникает большое количество
проблем. Эти проблемы получили название аномалии редактирования [].
В отношении СОТРУДНИКИ можно привести следующие примеры функциональных зависимостей:
Зависимость атрибутов от ключа отношения:
{Н_СОТР, Н_ПРО}
ФАМ
Н_ОТД
{Н_СОТР, Н_ПРО}
{Н_СОТР, Н_ПРО}
ТЕЛ
{Н_СОТР, Н_ПРО}
ПРОЕКТ
{Н_СОТР, Н_ПРО}
Н_ЗАДАН
Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:
Н_СОТР
ФАМ
Н_СОТР
Н_ОТД
Н_СОТР
ТЕЛ
Зависимость наименования проекта от номера проекта:
Н_ПРО
ПРОЕКТ
Зависимость номера телефона от номера отдела:
Н_ОТД
ТЕЛ
13
Необходимо заметить, что приведенные функциональные зависимости не выведены из внешнего вида отношения, приведенного
в таблице на рис. 4. Эти зависимости отражают взаимосвязи, обнаруженные между объектами предметной области и являются дополнительными ограничениями, определяемыми предметной областью.
Таким образом, функциональная зависимость – семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Например,
зная табельный номер сотрудника, можно определить его фамилию,
по номеру отдела можно определить телефон. Функциональная зависимость задает дополнительные ограничения на данные, которые могут храниться в отношениях. Для корректности базы данных
(адекватности предметной области) необходимо при выполнении
операций модификации базы данных проверять все ограничения,
определенные функциональными зависимостями.
Не смотря на явную некорректность построения таблицы на рис.
4, очевидно, что отношение СОТРУДНИКИ находится в Первой Нормальной Форме (1НФ), поскольку оно является плоской таблицей.
Теперь посмотрим, как обстоит дело со Второй Нормальной
Формой. Напомним определение 2НФ:
Отношение R находится во второй нормальной форме (2НФ)
тогда и только тогда, когда отношение находится в 1НФ и нет
неключевых атрибутов, зависящих от части сложного ключа.
Очевидно, что, если потенциальный ключ отношения является
простым, то отношение автоматически находится во 2НФ.
Отношение СОТРУДНИКИ не находится во 2НФ, так как есть атрибуты, зависящие от части сложного ключа:
Зависимость атрибутов, характеризующих сотрудника, от табельного номера сотрудника является зависимостью от части сложного ключа {Н_СОТР, Н_ПРО}:
Н_СОТР
ФАМ
Н_СОТР
Н_ОТД
Н_СОТР
ТЕЛ
Зависимость наименования проекта от номера проекта является
зависимостью от другой части сложного ключа:
Н_ПРО
ПРОЕКТ
Для того, чтобы устранить зависимость атрибутов от части
сложного ключа, нужно произвести декомпозицию отношения на
несколько отношений. При этом те атрибуты, которые зависят
от части сложного ключа, выносятся в отдельное отношение.
14
Отношение СОТРУДНИКИ декомпозируем на три отношения – СОТРУДНИКИ_ОТДЕЛЫ, ПРОЕКТЫ, ЗАДАНИЯ.
Отношение
СОТРУДНИКИ_ОТДЕЛЫ(Н_СОТР,ФАМ,Н_ОТД,ТЕЛ)
рис. 5.
Функциональные зависимости:
Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:
Н_СОТР
ФАМ
Н_СОТР
Н_ОТД
Н_СОТР
ТЕЛ
Зависимость номера телефона от номера отдела:
Н_ОТД
ТЕЛ
Отношение ПРОЕКТЫ(Н_ПРО,ПРОЕКТ)рис. 6.
Функциональные зависимости:
Н_ПРО
ПРОЕКТ
Отношение ЗАДАНИЯ (Н_СОТР, Н_ПРО, Н_ЗАДАН):
Функциональные зависимости:
Н_ЗАДАН
{Н_СОТР, Н_ПРО}
Проанализируем полученные отношения и увидим, что они находятся во 2НФ. Действительно, отношения СОТРУДНИКИ_ОТДЕЛЫ
и ПРОЕКТЫ имеют простые ключи, следовательно автоматически
находятся во 2НФ, отношение ЗАДАНИЯ имеет сложный ключ, но
единственный неключевой атрибут Н_ЗАДАН функционально зависит от всего ключа {Н_СОТР, Н_ПРО}.
Н_СОТР
ФАМ
Н_ОТД
ТЕЛ
1
Иванов
1
11-22-33
2
Петров
1
11-22-33
3
Сидоров
2
33-22-11
Рис. 5. Отношение СОТРУДНИКИ_ОТДЕЛЫ
Н_ПРО
ПРОЕКТ
1
Космос
2
Климат
Рис. 6. Отношение ПРОЕКТЫ
15
Н_СОТР
Н_ПРО
Н_ЗАДАН
1
1
1
1
2
1
2
1
2
3
1
3
3
2
2
Рис. 7. Отношение ЗАДАНИЯ
Фамилии сотрудников и наименования проектов теперь хранятся без избыточности. Если сотрудник сменит фамилию или проект
сменит наименование, то такое обновление будет произведено в одном месте.
Если по проекту временно прекращены работы, но требуется,
чтобы сам проект сохранился, то для этого проекта удаляются соответствующие кортежи в отношении ЗАДАНИЯ, а данные о самом
проекте и данные о сотрудниках, участвовавших в проекте, остаются в отношениях ПРОЕКТЫ и СОТРУДНИКИ_ОТДЕЛЫ.
Тем не менее, часть аномалий разрешить не удалось.
В отношение СОТРУДНИКИ_ОТДЕЛЫ нельзя вставить кортеж ,
например такой (4,Пушников,1,33-22-11), так как при этом получится, что два сотрудника из 1-го отдела (Иванов и Пушников)
имеют разные номера телефонов, а это противоречит модели предметной области. В этой ситуации можно предложить два решения,
в зависимости от того, что реально произошло в предметной области. Другой номер телефона может быть введен по двум причинам –
по ошибке человека, вводящего данные о новом сотруднике, или
потому что номер в отделе действительно изменился. Тогда можно
написать триггер, который при вставке записи о сотруднике проверяет, совпадает ли телефон с уже имеющимся телефоном у другого
сотрудника этого же отдела. Если номера отличаются, то система
должна задать вопрос, оставить ли старый номер в отделе или заменить его новым. Если нужно оставить старый номер (новый номер
введен ошибочно), то кортеж с данными о новом сотруднике будет
вставлен, но номер телефона будет у него будет тот, который уже
есть в отделе (в данном случае, 11-22-33). Если же номер в отделе
действительно изменился, то кортеж будет вставлен с новым номером, и одновременно будут изменены номера телефонов у всех со16
трудников этого же отдела. И в том и в другом случае не обойтись
без разработки громоздкого триггера.
Причина данной аномалии опять таки состоит в том, что после
проведенных преобразований сохранилась избыточность данных
порожденная тем, что в одном отношении хранится разнородная
информация (о сотрудниках и об отделах). Чтобы база данных,
основанная на такой модели, работала правильно необходима
разработка дополнительного программного кода в виде триггеров.
Кроме того, можно заметить, что в полученных отношениях
одни и те же номера телефонов повторяются во многих кортежах
отношения. Поэтому если в отделе меняется номер телефона, то
такие изменения необходимо одновременно выполнить во всех местах, где этот номер телефона встречаются, иначе отношение станет некорректным. Таким образом, обновление базы данных одним
действием реализовать невозможно. Необходимо опять написать
триггер, который при обновлении одной записи корректно исправляет номера телефонов в других местах.
И, наконец, при удалении некоторых данных по-прежнему может произойти потеря другой информации. Например, если удалить сотрудника Сидорова, то будет потеряна информация о том,
что в отделе номер 2 находится телефон 33-22-11.
Таким образом можно сделать следующий вывод: при переходе
ко второй нормальной форме отношения стали почти адекватными предметной области. Остались трудности в разработке базы данных, связанные с необходимостью написания триггеров, поддерживающих целостность базы данных. Эти трудности теперь связаны только с одним отношением СОТРУДНИКИ_ОТДЕЛЫ.
Для преодоления указанных аномалий необходима Третья Нормальная Форма (3НФ).
Отношение R находится в третьей нормальной форме (3НФ)
тогда и только тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно независимы.
Отношение СОТРУДНИКИ_ОТДЕЛЫ не находится в 3НФ, так как
имеется функциональная зависимость неключевых атрибутов (зависимость номера телефона от номера отдела):
ТЕЛ
Н_ОТД
Для того, чтобы устранить зависимость неключевых атрибутов,
нужно произвести декомпозицию отношения на несколько отношений. При этом те неключевые атрибуты, которые являются зависимыми, выносятся в отдельное отношение.
17
Отношение СОТРУДНИКИ_ОТДЕЛЫ декомпозируем на два отношения – СОТРУДНИКИ, ОТДЕЛЫ.
Отношение СОТРУДНИКИ (Н_СОТР, ФАМ, Н_ОТД):
Функциональные зависимости:
Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:
Н_СОТР
ФАМ
Н_СОТР
Н_ОТД
Н_СОТР
ТЕЛ
Отношение ОТДЕЛЫ (Н_ОТД, ТЕЛ):
Функциональные зависимости:
Зависимость номера телефона от номера отдела:
Н_ОТД
ТЕЛ
Обратим внимание на то, что атрибут Н_ОТД, не являвшийся
ключевым в отношении СОТРУДНИКИ_ОТДЕЛЫ, становится потенциальным ключом в отношении ОТДЕЛЫ. Именно за счет этого
устраняется избыточность, связанная с многократным хранением
одних и тех же номеров телефонов.
Проанализировав полученные отношения, можно сделать вывод о том, что все обнаруженные аномалии обновления устранены. Реляционная модель, состоящая из четырех отношений СОТРУДНИКИ, ОТДЕЛЫ, ПРОЕКТЫ, ЗАДАНИЯ, находящихся в третьей
нормальной форме, является адекватной описанной модели предметной области, и требует наличия только тех триггеров, которые
поддерживают ссылочную целостность. Такие триггеры являются
стандартными и не требуют больших усилий в разработке.
Н_СОТР
ФАМ
Н_ОТД
1
Иванов
1
3
Сидоров
2
2
Петров
1
Рис. 8. Отношение СОТРУДНИКИ
Н_ОТД
ТЕЛ
1
11-22-33
2
33-22-11
Рис. 9. Отношение ОТДЕЛЫ
18
Итак, алгоритм нормализации (т. е. алгоритм приведения отношений к 3НФ) описывается следующим образом.
Шаг 1 (Приведение к 1НФ). На первом шаге задается одно или
несколько отношений, отображающих понятия предметной области. По модели предметной области (не по внешнему виду полученных отношений!) выписываются обнаруженные функциональные зависимости. Все отношения автоматически находятся
в 1НФ.
Шаг 2 (Приведение к 2НФ). Если в некоторых отношениях
обнаружена зависимость атрибутов от части сложного ключа, то
проводим декомпозицию этих отношений на несколько отношений следующим образом: те атрибуты, которые зависят от части
сложного ключа выносятся в отдельное отношение вместе с этой
частью ключа. В исходном отношении остаются все ключевые
атрибуты:
Исходное отношение:. R(K1,K2,A1,…,An,B1,…,Bm)
Ключ: K1,K2- сложный.
Функциональные зависимости:
(K1,K2) (A1,…,An,B1,…,Bm) зависимость всех атрибутов от
ключа отношения.
(K1) (A1,…,An) – зависимость некоторых атрибутов от части
сложного ключа.
Декомпозированные отношения:
R1(K1,K2,B1,…,Bm) – остаток от исходного отношения. Ключ
K1,K2 .
R2(K1,A1,…,An) – атрибуты, вынесенные из исходного отношения вместе с частью сложного ключа. Ключ K1.
Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена зависимость некоторых неключевых атрибутов от других
неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты, которые зависят других неключевых атрибутов выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости:
Исходное отношение: R(K,A1,…,An,B1,…,Bm).
Ключ: K.
Функциональные зависимости:
K
(A1,…,An,B1,…,Bm) – зависимость всех атрибутов от ключа отношения.
(A1,…,An) (B1,…,Bm) – зависимость некоторых неключевых
атрибутов других неключевых атрибутов.
19
Декомпозированные отношения:
R1(K,A1,…,An) – остаток от исходного отношения. Ключ K.
R2(A1,…,An,B1,…,Bm) – атрибуты, вынесенные из исходного отношения вместе с детерминантом функциональной зависимости.
Ключ A1,…,An.
Замечание. На практике, при создании логической модели данных, как правило, не следуют прямо приведенному алгоритму нормализации. Опытные разработчики обычно сразу строят отношения в 3НФ. Кроме того, основным средством разработки логических
моделей данных являются различные варианты ER-диаграмм, рассмотренных выше. Особенность этих диаграмм в том, что они сразу
позволяют создавать отношения в 3НФ. Тем не менее, приведенный
алгоритм важен по двум причинам.
Во-первых, этот алгоритм показывает, какие проблемы возникают при разработке слабо нормализованных отношений.
Во-вторых, как правило, модель предметной области никогда
не бывает правильно разработана с первого шага. Эксперты предметной области могут забыть о чем-либо упомянуть, разработчик
может неправильно понять эксперта, во время разработки могут
измениться правила, принятые в предметной области, и т. д. Все
это может привести к появлению новых зависимостей, которые
отсутствовали в первоначальной модели предметной области. Тут
как раз и необходимо использовать алгоритм нормализации хотя
бы для того, чтобы убедиться, что отношения остались в 3НФ и логическая модель не ухудшилась.
Так как при выполнении курсовой работы используется инфологическая модель в виде ER-диаграммы, то вероятнее всего все отношения будут находиться в 3НФ.
Тем не менее, в тексте пояснительной записки необходимо привести все функциональные зависимости и убедиться, что все отношения базы данных находятся в 3НФ.
Если говорить о практическом использовании нормальных
форм высших порядков (Бойса-Кодда НФ, 4НФ, 5НФ), то можно
заметить следующее – выбор степени нормализации отношений зависит от характера запросов, с которыми чаще всего обращаются
к базе данных. В рамках курсового проекта будет достаточно использовать 3НФ.
В курсовой работе необходимо привести все имеющиеся
функциональные зависимости и продемонстрировать, что спроектированная база данных находится, как минимум, в 3НФ.
20
5. ВЫБОР СУБД
Выбор СУБД осуществляется на основании таких критериев,
как тип модели данных и ее адекватность потребностям данной
предметной области, характеристики производительности, набор
функциональных возможностей, удобство и надежность СУБД
в эксплуатации, стоимость СУБД и сопутствующего программного
обеспечения.
При выполнении курсовой работы предлагается использовать СУБД Access, но может быть использована и другая СУБД.
В этом случае необходимо обосновать выбор СУБД и реализовать
базу данных под управлением выбранной СУБД с выполнением
все требований, в частности, требований к виду пользовательского
интерфейса(см. п.).
6. ПРОГРАММИРОВАНИЕ БАЗЫ ДАННЫХ
СРЕДСТВАМИ СУБД ACCESS
6.1. Разработка схемы данных
Разработка схемы данных начинается с построения таблиц в соответствии с реляционной моделью, разработанной ранее. Строятся базовые таблицы и таблицы связи. В таблицах-связях для атрибутов, являющихся внешними ключами обязательно использовать
подстановку из соответствующих таблиц.
Дополнительные сведения о построении таблиц в СУБД Access
Процесс создания таблиц в СУБД Access подробно описан в [].
Но некоторые вопросы, которые могут пригодиться при выполнении курсового проекта, остались не рассмотренными.
Создание вычисляемого текстового поля
Пусть у нас есть таблица сотрудников, в которой имеются поля
Фамилия, Имя, Отчество (рис. 10). И пусть для какого-либо другого объекта базы данных требуется представить данные о сотрудниках в виде фамилии и инициалов.
Рис. 10. Исходная таблица
21
Для создания текстовой строки с фамилией и инициалами необходимо несколько раз последовательно применить операцию конкатенации следующей структуры
Фамилия & пробел & Инициал & точка & Инициал & точка
Для этого выполним следующие действия:
1. Создаем новое поле ФИО
2. В столбце Тип данных выбираем Вычисляемый.
3. В появившемся окне создаем выражение Фамилия & “ “ &.
4. Теперь прейдём к формированию инициалов. Используем
функцию Left категории Текстовые, которая возвращает первые
length символов.
• В строке выражения устанавливаем курсор в место планируемой вставки и вносим с клавиатуры символы “ “ &
• Далее, первом списке выбираем раздел Встроенные функции.
• Во втором списке выбираем Текстовые.
• Выбираем функцию Left . Дважды щелкаем мышью. Будет добавлен шаблон функции Left(«string»; «lenght». Укажем для фун-
Рис. 11.Создание вычисляемого текстового поля
22
Рис. 12. Таблица с вычисляемым текстовым полем
кии Left значения параметров «Имя» и «1» соответственно. Добавим символ точка “.”, затем символ &. Еще раз вызовем функцию
Left, но теперь в качестве параметров укажем «Отчество» и «1».
И, наконец, добавим еще раз символ “.” (рис. 11).
Результат формирования вычисляемого текстового поля приведен на рис. 12.
В курсовой работе необходимо предусмотреть использование
нескольких (более 2-х) вычисляемых числовых и/или текстовых
полей в таблицах.
Многозначные поля
В некоторых случаях при построении таблицы оказывается необходимым создание атрибута, содержащего многозначные значения. Классическая
реляционная модель, как известно, не позволяет атрибуту иметь
несколько значений в одном поле. Но из соображений удобства и
целесообразности в СУБД Access, начиная с версии Access 10,
такая возможность предусмотрена.
Пусть каждый сотрудник может иметь несколько номеров служебных телефонов для связи. Тогда, при создании поля Телефон
нужно использовать Мастер подстановки, выполнить все шаги
мастера и на последнем шаге установить флажок Разрешить несколько значений. На рис. 13. показан пример заполнения поля
Телефон несколькими значениями.
Рис. 13. Заполнение многозначного поля
23
Замечание. При создании многозначных полей необходимо
иметь в виду, что к таким полям невозможно будет обращаться с запросом на выборку по тому атрибуту, для которого вы разрешили
многозначность!
Задание ограничений на таблицы.
В Access имеется удобная возможность проверки вводимых значений на соответствие заданным ограничениям. Например, при
вводе даты продажи в таблицу продаж имеет смысл задать ограничение на вводимую дату. Так, дата продажи не может быть раньше
(или позже) текущей даты.
Для того, чтобы задать условие проверки, открываем соответствующую таблицу (в режиме таблицы), на вкладке Поле выбираем кнопку Проверка (рис. 14) и выбираем третью по счету команду
Правило проверки . Задаем правило проверки (рис. 15). Нажимаем
ОК. После этого еще раз нажимаем кнопку Проверка и выбираем
четвертую по счету команду Сообщение о проверке. В открывшееся
окошко вносим текст, например «Дата введена неверно» .
Нажимаем ОК. Теперь, при попытке ввести дату, отличную от
текущей, будет выдаваться сообщение (рис. 16).
Отметим, что указанный способ контроля даты отличается от
задания значения даты По умолчанию. Во втором случае пользователь может легко исправить текущую дату на любую другую.
Рис. 14. Выбор режима проверки поля
24
Рис. 15. Задание правила проверки значения поля
Рис. 16. Результат введения неправильной даты
В курсовой работе необходимо предусмотреть использование
нескольких (более 2-х) полей с проверкой на вводимые значения.
25
6.2. РАЗРАБОТКА ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ
Диалоговые приложения пользователя баз данных, прежде
всего, должны обеспечивать удобный графический интерфейс для
работы с документами предметной области. Основным средством
создания такого интерфейса являются формы. Формы, адекватные
формам первичных документов, позволяют выполнять загрузку
справочных, плановых и оперативно-учетных данных, в любой момент просматривать и редактировать содержимое ранее введенных
в базу данных документов.
Формы могут использоваться и для оформления документов на
компьютере, например, накладных на отгрузку товара, счетов на
оплату в соответствии с договорами и т. д. В процессе оформления
документа может выполняться и ввод его в базу данных. Кроме
того, может быть предусмотрена распечатка подготовленного документа средствами отчетов.
При разработке форм, обеспечивающих загрузку взаимосвязанных таблиц базы данных, следует иметь в виду требования к последовательности загрузки записей в таблицы в соответствии со схемой данных и установленными параметрами поддержания целостности.
В соответствии с этими требованиями можно рекомендовать
в практических приложениях предусмотреть сначала ввод в базу
справочных данных, а затем данных плановых и оперативно-учетных документов. Это связано с тем, что таблицы с плановыми и оперативно-учетными данными в схеме данных являются подчиненными по отношению к таблицам справочных данных, которые, как
правило, находятся на верхнем уровне.
Рекомендации к разработке форм
Перед тем, как приступить к созданию форм в курсовом проекте, необходимо определиться с их количеством и примерным содержанием. Очевидно, что для нормальной эксплуатации базы данных
для любой предметной области следует иметь, как минимум четыре
группы форм:
Для работы с базовыми таблицами (справочниками)
– добавление записей в таблицы
– удаление записей из таблиц
– поиск записей в таблицах.
Для организации поиска записей в базе данных через форму следует использовать всплывающее модальное окно [4].
26
Для работы с таблицами-связями
– занесение записей в таблицы по факту выполнения соответствующих действий (продажа, покупка и т. д.)
– обновления полей в таблицах
– создание новых таблиц
– вызов необходимых запросов для получения требуемых сведений
Формы для получения необходимых документов (отчетов)
Эти формы должны соответствовать виду требуемого документа
(накладная, платежный документ и пр.)
Кнопочные формы, которые должны обеспечить «логику»
работы пользователя, позволяя переключаться между всеми группами форм.
Дополнительные сведения о формах в Access 10-13
Выше был рассмотрен пример проверки значения поля при воде
данных в таблицу. Если на основании этой таблицы построить форму и через нее осуществлять ввод данных, то заданная проверка
будет также работать. В то же время в некоторых случаях удобнее
пользоваться ограничнием не на поля таблицы, а на поля формы.
Рассмотрим случай ввода данных в подчиненную форму, например форму Продажи (см. пример из [1]). В этой форме необходимо
контролировать значения поля Количество, так как мы не можем
продать товар, если его остаток на складе в результате этой продажи будет меньше страхового запаса.
Для того чтобы осуществить эту проверку нам потребуются три
таблицы Товар, Клиенты и Продажи. Строим форму на основе этих
трех таблиц, выбирая необходимые поля в следующем порядке:
Клиенты – КодКлиента, ИмяКлиента, Телефон;
Продажи –КодПродажи, Дата продажи, Наименование, Количество;
Товары – КодТовара, Остаток, Страховой запас.
Открываем форму в режиме Конструктора. Затем у полей КодКлиента, КодТовара, Остаток, Страховой запас в свойствах поля
«Вывод на экран» на вкладке Макет зададим значение «Нет».
В свойствах поля Количество на вкладке Данные в строке Правило проверки пишем
< [Остаток]- [Страховой запас ],
а в строке Сообщение
«Недостаточно товара на складе!».
27
Рис. 17. Результат действия ограничений
на значение поля формы
Теперь, при попытке некорректного ввода количества продаваемого товара, появится сообщение и ввод нужно будет отменить
(рис. 17).
В курсовой работе необходимо предусмотреть ограничения
на значения полей таблиц и/или форм в соответствии с требованиями, предъявляемыми к вводу и корректировке данных в разрабатываемой БД.
Вычисляемые поля в формах
Вычисления в форме могут осуществляться как в каждой записи формы, так и для группы записей при формировании итоговых
величин. Вычисляемые величины отображаются в поле формы, но,
в отличии от создаваемых в таблице вычисляемых полей, не сохраняются в таблице. Для сохранения результатов вычислений в таблице базы данных требуется подготовки макроса.
Чтобы произвести вычисления на основе данных каждой записи формы, необходимо создать элемент управления Вычисляемое
поле, источником данных которого является выражение для расчета.
Пусть необходимо подсчитать и отобразить в форме величину
НДС каждого товара в денежном выражении и итоговую сумму.
28
Рис. 18. Форма с вычисляемыми полями в режиме конструктора
Рассмотрим процесс создания вычисляемого поля на примере формы Сумма_Продаж из [1]. Откроем эту форму в режиме конструктора. Создадим вычисляемое поле Сумма НДС и запишем в него
выражение:
=[Сумма]*[Ставка_НДС]. (Предполагается, что ставка НДС
известна)
Создадим еще одно вычисляемое поле Итоговая сумма и с помощью Построителя выражений запишем в него формулу (рис. 18):
= [Сумма]+[Сумма_НДС]
Вычисление итоговых значений в форме
Вычисление итоговых значений в форме выполняется в примечании формы с помощью встроенных статистических функций, записываемых в выражениях в вычисляемых элементах управления.
Для расчета среднего значения цены всех товаров запишите
в вычисляемый элемент управления выражение (рис. 19):
= Avg ([Сумма]).
После перехода в режим просмотра в форме отображаются результаты расчетов (рис. 20).
29
Рис. 19. Форма с вычисляемыми итоговыми значениями
в режиме конструктора
Рис. 20. Форма с вычисляемыми полями
30
В курсовой работе необходимо использовать не менее 2-х полей, вычисляемых для каждой записи в формах, и столько же для
вычисления итоговых значений.
Проектирование интерфейса для ввода и корректировки
документов
Ввод и корректировка справочных данных могут быть осуществлены через простые формы с макетом в столбец или табличный,
в которых для проверки значений в полях заданы ограничения.
Для ввода и корректировки данных плановых и оперативноучетных документов пользователю нужно разработать удобный
экранный интерфейс, который позволит минимизировать операции по вводу данных и контролировать их достоверность и корректность. При этом необходимо ограничиваться вводом только
идентификаторов и количественных показателей. Справочные
данные (наименования, нормативы, цены, тарифные ставки и
т. п.) не могут вводиться с этих документов, а должны только отображаться в форме из ранее созданных таблиц справочной информации.
При этом поля таблиц справочной информации должны использоваться в таких формах только для отображения. Поэтому целесообразно защитить их от непроизвольных изменений при работе
с формой. Сделать это можно следующим образом: выделите поле
(можно выделить несколько полей) и откройте окно свойств. В окне
свойств на вкладке Данные в строке Блокировка выберите «Да».
После установки этого свойства поле будет доступно только для
чтения.
Если необходимо установить режим, при котором возможно
только добавление новых записей в базу данных и запрещен просмотр существующих записей, необходимо открыть свойства формы и на вкладке Данные в строке Ввод данных выбрать значение
«Да».
Чтобы пользователю было удобно работать с базой данных, вы
можете создать так называемую форму навигации, которая связывает воедино созданные формы БД. В Access 2010 форма навигации
пришла на смену главной кнопочной форме (которая применялась
в предыдущий версиях) и представляет собой аналог навигационного меню в виде вкладок на веб-сайтах.
Чтобы организовать навигацию в вашей БД, выберите на ленте
вкладку Создание, затем нажмите на панели Формы кнопку Нави31
гация – откроется выпадающий список с возможными вариантами
навигационных форм (рис. 21).
Первые три варианта используются в БД с небольшим количеством форм, а последние три варианта – если форм в базе довольно
много и есть необходимость разбить их на категории. Для этого необходимо первоначально продумать структуру пользовательского
интерфейса и определить:
• какие категории можно выделить в создаваемой БД (Товар,
Клиенты, Продажи и т. д.)
• ответы на какие запросы должна выдавать БД по каждой категории (просмотр, редактирование, занесение информации и т. д.);
• какие пункты меню пользователя должны находиться на первом уровне, а какие на следующих уровнях с учетом подчиненности соответствующих форм;
Рассмотрим следующий пример создания навигационных форм
для варианта Горизонтальные вкладки, 2 уровня. При выборе этого варианта появится пустая форма с заготовками вкладок для
первого и второго уровней (рис. 22).
Вначале заполним список категорий, т. е. первый уровень навигации:
1. Выполняем двойной щелчок на первой пустой заготовке «Создать» и вводим названия Клиенты
Рис. 21. Варианты навигационных форм
32
Рис. 22. Пустая форма навигации с 2-мя уровнями
2. Щелкаем в любом месте формы – появится следующая заготовка «Создать». Вводим аналогичным образом название Товары,
Поставщики (рис. 23)
Теперь создадим второй уровень навигации для категории Клиенты:
1. Выделяем категорию Клиенты.
2. Из списка объектов БД перетаскиваем нужную форму (например Клиенты_просмотр) во вторую строку навигационной формы.
3. Отпускаем кнопку мыши – появляется вкладка с названием
этой формы .
Рис. 23. Ввод категорий первого уровня
33
Рис. 24. Добавление формы Клиенты_просмотр
во второй уровень навигации
4. Переименовываем вкладку на Просмотр – дважды щелкаем
на вкладке и вводим требуемое название (рис. 24).
Аналогичным образом создаем все необходимые для работы БД
вкладки.
В курсовой работе интерфейс пользователя можно разработать как с помощью навигационных форм, так и с помощью кнопочных форм. Интерфейс должен обеспечивать возможность переключения между различными рабочими местами (если курсовая
работа выполняется группой (не более 3-х человек)). Далее, для
каждого рабочего места выстраивается своя система меню в соответствии с функциональными обязанности сотрудника.
Параметры запуска БД
После того, как разработан пользовательский интерфейс и закончены все работы по проверке корректности работы БД, необходимо сделать так, чтобы начальная форма интерфейса вызывалась
сразу при запуске БД. Кроме того, нужно задать и другие параметры БД – заголовок, иконку и т. д. Для этой цели в Access предусмотрен специальная область настройки Параметры приложений в разделе Текущая база данных диалогового окна Параметры
Access (рис. 25).
В поле Заголовок приложения следует указать заголовок окна
БД (например, Отдел_Продаж) и выбрать в выпадающем списке
Форма просмотра созданную форму навигации (например, Нача34
Рис. 25. Установка параметров запуска базы данных
ло_работы). Кроме того, можно задать дополнительные параметры
запуска БД:
• Значок приложения – дает возможность указать путь к файлу
иконки (ICO-файлу), которая будет отображаться в левом верхнем
углу окна Access слева от заголовка. Чтобы этот же значок выводился во всех окнах форм и отчетов, нужно дополнительно установить флажок Значок форм и отчетов.
• Строка состояния – позволяет установить, будет ли после запуска БД отображаться ее окно и строка состояния соответственно.
• Параметры окна документа – позволяет определить, как будут отображаться объекты БД: в виде вкладок или в виде обычных
перемещаемых окон.
Следующий набор опций применяется для того, чтобы запретить конечным пользователям изменять объекты БД (т. е. опции
закрывают доступ к конструкторам). Когда приложение находится на этапе разработки, то все эти опции включены. Но когда разработка завершена и база данных устанавливается на компьютеры
пользователей, рекомендуется их отключить. К данным опциям относятся:
• Область навигации – позволяет скрыть/отобразить панель сосписком объектов БД.
• Полный набор меню Access – позволяет скрыть/отобразить
основные меню Access, используемые при работе с объектами базы
данных.
• Контекстное меню (по умолчанию) — предназначена для отключения/включения стандартных контекстных меню Access.
Все изменения, внесенные в перечисленные выше параметры,
вступают в силу после перезапуска базы данных.
Примечание. Можно обойти установленные ограничения – для
этого при запуске БД удерживайте нажатой клавишу Shift.
35
7. СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
К КУРСОВОЙ РАБОТЕ
Пояснительная записка к курсовой работе должна иметь следующую структуру:
1. Титульный лист установленного образца.
2. Содержание
3. Введение.
Во введении описывается назначения разрабатываемой базы
данных и актуальность ее разработки.
4. Описание Информационной модели предметной области.
В этом разделе приводится описание предприятия, для которого
разрабатывается БД, его структура, описание подразделений и рабочих мест, автоматизация которых является целью данной курсовой работы. Приводится описание функциональных обязанностей
соответствующих работников, перечень и формы входных и выходных документов, с которыми они работают, перечень регламентированных запросов к БД, на которые предполагается получить ответы. Итогом этого раздела является постановка задачи курсового
проектирования.
5. Разработка ER-диаграммы.
В этом разделе необходимо описать все выделенные во 2-ой части
объекты БД, определить сущности и связи между ними. Привести
структуру таблиц (с указанием имен атрибутов, типом, первичными и внешними ключами, провести их нормализацию с помощью
построения функциональных зависимостей до 3НФ или показать,
что предлагаемая БД находится в 3НФ.
6. Программирование объектов базы данных.
В данном разделе требуется привести описание процесса создания таблиц, форм, запросов, отчетов и т. д. с иллюстрацией экранных форм (если БД разрабатывается с помощью СУБД Access)
или SQL – запросов (если используется другая СУБД).
7. Разработка интерфейса пользователя.
В данном разделе приводится описание структуры интерфейса,
состав и взаимосвязь уровней, скриншоты работы с использованием разработанного интерфейса по решению всех сформулированных в части 2 задач.
8. Заключение.
В этот разделе делаются выводы о проделанной работе.
9. Библиографический список.
36
8. ОФОРМЛЕНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
К КУРСОВОЙ РАБОТЕ
По объему пояснительная записка к курсовой работе должна
быть не менее 20 страниц печатного текста. Шрифт текста – Times
New Roman, размер шрифта – 14 пт, междустрочный интервал –
полуторный. В списке литературы не менее 3 источников.
Пояснительная записка к курсовому проекту печатается на бумаге формата А4 (210 × 297 мм). Для разворотных таблиц и рисунков допускается формат А3 (297 × 420 мм). Заголовки таблиц, названия схем допускается печатать через одинарный интервал.
Напечатанный текст должен иметь поля следующих размеров:
– верхние и нижние – 25 мм;
– правые – 10 мм;
– левые – 25 мм.
Абзацный отступ (“красная строка”) равен 1,25 мм. Заголовки
глав отделяются от текста сверху двойным интервалом (т. е. двумя
пустыми строками), снизу – одинарным интервалом. Заголовки параграфов отделяются от текста одинарным интервалом (т. е. одной
пустой строкой).
Основной текст печатается строчными (маленькими) буквами,
заглавными буквами (прописными, большими) печатаются аббревиатуры, а также слова “ВВЕДЕНИЕ”, “ЗАКЛЮЧЕНИЕ” и “ПРИЛОЖЕНИЕ”, которые располагаются по центру листа. Названия
глав печатаются полужирным начертанием шрифта.
В тексте должна быть соблюдена соподчинённость глав, параграфов и пунктов. Нумерация глав и параграфов выполняется
арабскими цифрами, которые отделяются от названий точкой; номер параграфа состоит из цифры, обозначающей номер главы, и
цифры обозначающей его порядковый номер в составе главы, отделённых друг от друга точкой. Знак § не ставится. Если параграфы
состоят из нумерованных пунктов, их нумерация состоит из трёх
разделённых точками цифр.
Нумерация таблиц и рисунков сквозная или разбитая по главам
(локальная, номер рисунка – последняя цифра, первая цифра – номер главы, если же глава разбита на разделы, то номер главы и через точку, номер раздела).
Следует обратить внимание на положение на странице названий
таблиц (сверху – справа) и рисунков (снизу – посередине), причём
перед названием после номера обязательно ставится точка и название печатается с заглавной буквы.
37
Каждая глава пояснительной записки к курсовому проекту начинается с новой страницы.
Страницы пояснительной записки нумеруются от титульного
листа и до последнего, цифра 1 на титульном листе не ставится.
Приложения нумеруются арабскими цифрами (без значка №) и
должны иметь названия.
Пояснительная записка к курсовому проекту должна быть переплетена или заключена в папку.
Пояснительная записка оформляется в соответствии с требованиями, сформулированными выше, защищается и выкладывается
в личный кабинет студента.
График сдачи этапов курсовой работы на 202Х год
Этап
Название
Дата выполнения
Баллы
1
Построение схемы базы данных
9.03.2Х
20
38
2
Создание объектов базы даннных
16.03.2Х
10
3
Разработка запросов к базе данных
06.04.2Х
25
4
Разработа интерфейса к базе данных
18.05.2Х
15
5
Защита курсовой работы
25.05.2Х
10
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Галанина В. А., Решетов Л. А. Базы данных: лабораторный
практикум. СПб.: ГУАП, 2018. 91 с.
2. Галанина В. А. Базы данных. Введение в теорию реляционных баз данных; учебное пособие. СПб.: ГУАП, 2008. 108 с.
3. Дейт К. Введение в системы баз данных. К.; М.; Спб; Издат.
Дом «Вильямс». 2005. 1328 с.
4. Бекаревич, Ю. Б., Пушкина Н. В. Самоучитель Microsoft
Access 2013. СПб.: БХВ-Петербург, 2014. 464 с..
5. ГОСТ 7.1–84. Библиографическое описание документа. Общие требования и правила составления.
39
ПРИЛОЖЕНИЕ
Примерные темы для курсовой работы
1. Проектирование БД для работника склада (варианты: склад
торговой организации, занимающейся сбытом как продукции собственного производства, так и продукции внешних поставщиков;
склад оптовой торговой организации; склад готовой продукции;
склад сырья и материалов и др.)2. Проектирование БД для библиотеки ВуЗа.
3. Проектирование БД для управления работой компьютерных
аудиторий учебного заведения.
4. Проектирование БД спортивной школы.
5. Проектирование БД центра детского творчества.
6. Проектирование БД коммерческого учебного центра.
7. Проектирование БД для учета домашних финансов.
8. Проектирование БД для домашней библиотеки.
9. Проектирование БД для районной библиотеки.
10. Проектирование БД для домашней видеотеки.
11. Проектирование БД для пункта проката видеофильмов.
12. Проектирование БД кинотеатра.
13. Проектирование БД драматического театра.
14. Проектирование БД для домашней аудиотеки.
15. Проектирование БД тренера спортивной команды.
16. Проектирование БД агентства по аренде квартир.
17. Проектирование БД риэлтерского агентства.
18. Проектирование БД для учета услуг, оказываемых юридической консультационной фирмой.
19. Проектирование БД для автосервисной фирмы.
20. Проектирование БД для автозаправочной станции.
21. Проектирование БД центра по продаже автомобилей.
22. Проектирование БД таксомоторного парка.
23. Проектирование БД по подсистеме «Кадры» (варианты: для
ВУЗа, школы, промышленного предприятия, торговой фирмы, софтверной фирмы и т. п.).
24. Проектирование БД службы знакомств.
25. Проектирование базы данных туристического агентства.
26. Проектирование БД районной поликлиники. Подсистема
«Работа с пациентами».
27. Проектирование БД районной поликлиники. Подсистема
«Учет льготных лекарств».
40
28. Проектирование БД районной поликлиники. Подсистема
«Планирование и учет работы медицинского персонала».
29. Проектирование БД районной поликлиники. Подсистема
«Учет пациентов».
30. Проектирование базы данных больницы. Подсистема «Работа с пациентами».
31. Проектирование базы данных больницы. Подсистема «Лекарственное обеспечение».
32. Проектирование базы данных аптеки.
33. Проектирование базы данных гостиницы. Подсистема «Работа с клиентами».
34. Проектирование базы данных дачного кооператива.
35. Проектирование базы данных Издательства. Подсистема
«Работа с авторами».
36. Проектирование базы данных Издательства. Подсистема
«Служба маркетинга».
37. Проектирование базы данных Учета расчетов с клиентами
в банке.
38. Проектирование базы данных строительной фирмы.
Помимо выше приведенных тем студенты могут предложить
свою предметную область.
41
СОДЕРЖАНИЕ
ВВЕДЕНИЕ..............................................................................
3
1. Этапы проектирования базы данных........................................
4
2. Построение информационной модели предметной области...........
4
3. Построение инфологической модели. (ER–диаграмма)................
7
4. Формирование реляционной модели данных
по ER-диаграммам....................................................................
11
5. Выбор СУБД.........................................................................
21
6. Программирование базы данных средствами СУБД Access..........
21
6.2. Разработка интерфейса пользователя.....................................
26
7. Содержание пояснительной записки к курсовой работе...............
36
8. Оформление пояснительной записки к курсовой работе..............
37
Библиографический список........................................................
39
Приложение. Примерные темы для курсовой работы.....................
40
