- •Учебно-методические указания по подготовке, оформлению и защите курсовой работы по дисциплине «Базы данных»
- •080500 «Бизнес-информатика»
- •Общие положения
- •Порядок выполнения и защиты курсовой работы
- •Ознакомление с требованиями, предъявляемыми к курсовой работе
- •Выбор темы курсовой работы
- •Подготовка курсовой работы
- •Защита курсовой работы
- •Критерии оценки курсовой работы
- •Структура и содержание курсовой работы по дисциплине «базы данных»
- •Содержание раздела «Введение»
- •Содержание раздела «Описание предметной области проектирования».
- •Содержание раздела «Проектирование базы данных (информационного обеспечения)».
- •Накладная № на поставку товаров
- •Содержание раздела «Машинная реализация в среде субд ms access ».
- •Основные требования к оформлению курсовой работы
- •Рекомендуемые источники информации
Содержание раздела «Проектирование базы данных (информационного обеспечения)».
Раздел «проектирования базы данных» начинается с анализа входных и выходных информационных потоков по отношению к базе данных.
Входной информацией являются первичные данные, которые вносятся пользователем или поступают через сканирующие устройства (считывание штрих-кодов). В базе данных входная информация представлена в справочниках и оперативных документах. При оценке входной информации следует пользоваться результами анализа документооборота (см. Таблица 4), ограничениями ПО, информационными потребностями пользователя. Студент анализирует реквизитный состав входных данных. Рекомендуется отдельно представлять нормативно-справочную информацию и информацию оперативных документов. Нормативно-справочная входная информация может быть представлена в таблице, образец — Таблица 6.
Таблица 6. Входная информация (база данных Склад):
Наименование справочника |
Реквизиты |
Справочник товаров |
Код товара |
Наименование товара |
|
Цена учетная (продажная) |
|
Единица измерения |
|
Код склада |
|
Наименование склада |
|
Справочник складов |
Код склада |
Наименование склада |
Информация по оперативным документам может быть также оформлена в таблице, но рекомендуется представить формы входных документов. Впоследствии это поможет студенту при разработке электронных форм документов. Пример входного оперативного документа (с реквизитами) представлен на Рисунок 1
Накладная № на поставку товаров
от
(дата)
Контрагент
(наименование контрагента)
Сумма по накладной (в руб.)
Наименование товара |
Цена поставки |
Единица измерения |
Количество |
|
|
|
|
|
|
|
|
|
|
|
|
Дата выдачи отчета 05.05.12
Рисунок 1. Форма входного документа
Выходная информация формируется в результате обработки исходных данных и может быть представлена как:
стандартные отчеты (заданной структуры);
данные для аналитических отчетов.
Выходную информацию также рекомендуется представлять в виде формы выходного документа (см. Рисунок 2).
Товарные потоки контрагента ООО «Солнышко»
Месяц |
Стоимость в рублях нарастающим итогом |
||
Поставка |
Отпуск |
Баланс (Поставка-Отпуск) |
|
Январь |
10000 |
|
10000 |
Февраль |
10000 |
5000 |
5000 |
Март |
12000 |
15000 |
-3000 |
Апрель |
20000 |
25000 |
-5000 |
Май |
25000 |
25000 |
0 |
Июнь |
50000 |
30000 |
20000 |
Дата выдачи отчета 05.07.12
Рисунок 2. Форма выходного документа
По завершению данного этапа работы, студент владеет всей информацией, необходимой для формирования модели данных: структуры данных, необходимые для поддержки операций автоматизируемой предметной области; реквизитный состав (определяется реквизитным составом входных справочников и документов), а также ограничения и требования предметной области.
Моделирование данных начинается с определения информационных объектов предметной области. Информационные объекты предметной области с атрибутным составом рекомендуется представить в таблице (образец — Таблица 7).
Таблица 7. Описание информационных объектов (база данных Склад)
Информационный объект |
Атрибуты |
Товар |
Код товара |
Наименование товара |
|
Цена продажи |
|
Единица измерения |
|
Код склада |
|
Наименование склада |
|
Поставка на склад |
№ накладной поставки |
Дата поставки |
|
Код контрагента |
|
Наименование контрагента |
|
Стоимость по накладной |
|
Код товара |
|
Наименование товара |
|
Единица измерения |
|
Цена поставщика |
|
Количество поставлено |
|
Единица измерения |
|
Цена продажи |
|
Количество отпущено |
При приведении объектов к третьей нормальной форме (нормализации) студент должен последовательно отразить этапы анализа: определение функциональных зависимостей, выделение ключей, приведение к 3НФ. Необходимо представить комментарии по каждому информационному объекту (сущности), которые покажут понимание студентом выполняемой работы. Пример приведения сущности к 3НФ с комментариями представлен ниже.
Пример описания нормализации сущности (база данных Склад):
Рисунок 3. Анализ функциональных зависимостей сущности Поставка на склад
Комментарии к Рисунок 3:
Так как № накладной поставки уникален для контрагента, то конкретному номеру накладной может соответствовать несколько контрагентов и несколько дат поставки (в соответствии с ограничениями). Поэтому, рассматриваем функциональную зависимость от группы атрибутов: № накладной поставки, Код контрагента. Для каждого № накладной, относящегося к конкретному контрагенту, существует единственная дата поставки и единственная сумма по накладной. Следовательно, Дата поставки и Сумма по накладной функционально зависимы от № накладной поставки, Кода контрагента.
Функциональные зависимости Наименования контрагента от Кода контрагента, Наименования товара, Единицы измерений от Кода товара рассматривались выше.
Для каждого № накладной, относящегося к конкретному контрагенту, существует несколько кодов товаров (ограничения), поэтому рассматриваем функциональную зависимость как зависимость от группы атрибутов: № накладной поставки, Код контрагента, Код товара. Для каждого товара, относящегося к конкретному № накладной, для конкретного контрагента существует единственная Цена поставщика и единственное значение атрибута Количество поставлено. Следовательно, Цена поставщика и Количество поставлено функционально-зависимы от № накладной поставки, Код контрагента, Кода товара.
Данная сущность не удовлетворяет требованиям третьей нормальной форме: присутствуют зависимости от части ключа (от разных ключей). Так, Дата поставки и Сумма по накладной зависят от № накладной поставки, Кода контрагента, а Цена поставщика и Количество поставлено зависят от № накладной поставки, Кода контрагента, Кода товара.
Следуя правилам приведения к третьей нормальной форме, формируем новые сущности, находящиеся в третьей нормальной форме (Рисунок 4).
Рисунок 4. Сущность Поставка товаров в 3НФ
Атрибут Сумма по накладной является вычисляемым, потому в сущность Поставка товаров не включается (Рисунок 5).
Рисунок 5. Сущность Спецификация поставки в 3 НФ
При построении информационно-логической модели студенту рекомендуется проанализировать связи между каждой парой объектов (сущностей). Результаты анализа прокомментировать.
Рисунок 6. Связь между сущностями
Комментарии к Рисунок 6:
Одному контрагенту соответствует несколько поставок на склад, каждая поставка принадлежит одному контрагенту. Связь один-ко-многим. Связующий реквизит — код контрагента.
Информационно-логическая модель строится по результатам попарного анализа связей сущностей. Модель может быть построена в инструментальной среде (например, MS Visio), что не является обязательным условием (см. Рисунок 7).
Рисунок 7. Информационно-логическая модель
В завершающей части проектирования студент представляет таблицу соответствия сущностей таблицам, с привязкой атрибутов к типам данных и полям таблиц, которые будут реализованы в среде выбранной системы управления базами данных, например, MS Access (см. Таблица 8).
Таблица 8. Таблица соответствия сущностей таблицам
Сущность |
Таблица |
Атрибуты сущности |
Поля таблицы |
Тип данных |
Товар |
Товар |
Код товара |
КодТовара |
Текстовый, 2 |
Наименование товара |
Товар |
Текстовый, 20 |
||
Цена продажи |
ЦенаПродажи |
Денежный |
||
Единица измерения |
ЕдИзм |
Текстовый, 5 |
||
Код склада |
КодСклада |
Текстовый, 1 |
По завершению проектирования, студент представляет результаты работы руководителю, который должен подтвердить соответствие проекта исходным требованиям.
