Разработка базы данных по предметной области «Столовая гимназии №8»

Содержание

I. Аналитическая часть

1.1 Описание предметной области «Столовая гимназии № 8»

1.1.1 Список вопросов, на которые должна отвечать информационная система

1.1.2 Описание первичных документов

1.1.3 Описание результатных документов

1.2 Определение логической структуры данных

1.2.1 Выявление функциональной зависимости

1.2.2 Требования нормализации

1.2.3 Тип связи информационных объектов

II. Построение информационно-логической модели базы данных

2.1 Построение матрицы смежности ИЛМ

2.2 Логическая модель предметной области

2.3 Построение физической модели

2.4 Разработка приложения Заключение Список литературы

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

Целью курсового проекта является исследование возможности создания автоматизированной системы для формирования документов, с разработкой приложения в виде автоматизированной системы «Школьное питание».

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

Для создания базы данных необходимо решить следующие задачи:

1. Провести системный анализ предметной области, выявить основные требования к ИС;

2. Построить информационно-логическую модель базы данных;

3. Реализовать информационно-логическую модель с использованием СУБД (создать базу данных по информационно-логической модели);

4. Создать пользовательский интерфейс;

5. Провести тестирование и отладку программы.

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

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

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

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

І. Аналитическая часть

1.1 Описание предметной области «Столовая гимназии № 8»

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

Родители заключают договор со школой. Классный руководитель передаёт договоры завучу ответственному за организацию питания школы, а тот в свою очередь передаёт их в МАУ «Стандарты питания». В конце месяца классный руководитель составляет табель посещаемости класса. На основе договора и табеля посещаемости МАУ «Стандарты питания» составляет ведомость взаиморасчёта и передаёт её школе. Согласно ведомости родители перечисляют деньги на свой лицевой счёт и банк перечисляет их МАУ «Стандарты питания».

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

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

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

· справочную информацию о ценах каждого типа питания;

· справочную информацию для табелей посещаемости.

1.1.1 Список вопросов, на которые должна отвечать информационная система

Созданная база данных должна отвечать на следующие вопросы:

· сколько учеников питается по каждому типу питания;

· в какие дни питался каждый из учеников;

· задолженность каждого ученика за требуемый промежуток времени;

· печать отчётов и других документов.

1.1.2 Описание первичных документов

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

Рисунок 1.1 Форма документа Договор Рисунок 1.2 Форма документа Акт о расходовании средств на питание

1.1.3 Описание результатных документов

Основными выходными документами при работе с базой данных являются табели посещаемости и индивидуальные ведомости взаиморасчёта. Также может потребоваться отчёт по типам питания. В таблицах 1.1−1.3 представлены формы выходных документов.

Таблица 1.1 Табель посещаемости

Индивидуальная ведомость взаиморасчёта составляется раз в месяц на весь для каждого ученика (см. таблицу 1.2).

Таблица 1.2 Индивидуальная ведомость взаиморасчёта

Отчёт по типам питания составляется на весь класс, и форма отчёта представлена таблицей 1.3.

Таблица 1.3 Отчёт по типам питания

1.2 Определение логической структуры данных

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

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

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

Справочной информацией предметной области Столовая гимназии № 8 являются справочники: food, table_inf.

Учетной информацией являются pupil, visit и pay.

Реквизит — простейшая структурная единица информации.

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

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

1.2.1 Выявление функциональной зависимости

Таблица 1.4 Функциональные зависимости реквизитов объекта pupil

Таблица 1.5 Функциональные зависимости реквизитов объекта food

Таблица 1.6 Функциональные зависимости реквизитов объекта table_inf

Таблица 1.7 Функциональные зависимости реквизитов объекта visit

Таблица 1.8 Функциональные зависимости реквизитов объекта pay

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

pupil (number_ls, name_p, number_food, reason_priv, class).

food (number_food, name_f, cost_f).

table_inf (class, teach_name, dir_name, school_name).

visit (number_ls, date, visit).

pay (number_ls, month, year, sum)

1.2.2 Требования нормализации

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

· информационный объект должен содержать уникальный идентификатор — первичный ключ;

· все не ключевые реквизиты должны быть взаимонезависимы;

· все ключевые реквизиты, должны быть функционально независимы;

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

· каждый описательный реквизит должен зависеть от ключа нетранзитивно, т. е. не должен зависеть через другой промежуточный реквизит. (2)

1.2.3 Тип связи информационных объектов

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

Рисунок 1.4 ER-диаграмма Существуют три типа связей: 1:1, 1: М, М: N.

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

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

Связь М: Mв реляционной модели данных не реализуется. Ее необходимо преобразовать в связь 1: М введением дополнительного объекта «связки». Объект связка является подчиненным в связях 1: М.

II. Построение информационно-логической модели базы данных

2.1 Построение матрицы смежности ИЛМ

Матрица смежности — квадратная матрица по числу информационных объектов. Матрица заполняется по строкам. Элемент матрицы на пересечении строки и столбца равен 1, если информационный объект, стоящий в строке, связан с информационным объектом, стоящим в столбце, отношением один ко многим, тип функциональной связи во внимание не принимается (3) (4). Таблица 2.1 соответствует матрице смежности для ИО ИЛМ предметной области «Столовая гимназии № 8».

Алгоритм расположения ИО по уровням иерархии:

1. Вычислить итоговые суммы элементов матрицы по столбцам.

2. Выделить ИО столбцов, для которых итоговая сумма равна 0.

3. Удалить строки матрицы смежности соответствующие ИО текущего уровня иерархии.

4. Для перехода к следующему уровню иерархии следует повторить пункт 2−3.

Таблица 2.1 Матрица смежности

Цифрами обозначены ИО: 1 — food, 2 — table_inf, 3 —pupil, 4 —visit, 5 — pay.

2.2 Логическая модель предметной области

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

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

Для связи используется вторичный ключ или ключ связи. Он обычно обозначается, как FK.

Рисунок 2.1 Логическая модель предметной области

2.3 Построение физической модели

Параметры каждой таблицы базы данных указаны ниже.

«pupil»

«food»

«table_inf»

«visit»

«pay»

2.4 Разработка приложения

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

Форма «Добавление ученика». Данная форма строится с помощью встроенного в Microsoft Access мастера форм по созданной ранее таблице «pupil». Внешний вид формы «Добавление ученика» в конструкторе и в режиме формы после некоторых преобразований показан на рисунках 2.2 и 2.3 соответственно.

Рисунок 2.2 Вид формы «Добавление ученика» в конструкторе форм Рисунок 2.3 Вид формы «Добавление ученика» в режиме формы Для поля «Тип питания» было произведено преобразование в поле со списком. Источником строк для этого объекта являются значения поля «name_f» таблицы «food». Для источника строк был создан следующий запрос (Рис 2.4):

Рисунок 2.4 Запрос для источника строк поля «Тип питания»

Был создан аналогичный запрос для источника строк полей со списком «Класс». Он продемонстрирован на рисунке 2.5.

Рисунок 2.5 Запрос для источника строк поля «Класс»

Кнопка «Добавить запись» позволяет поместить текущую запись в таблицу «pupil».

Форма «Типы питания» строится с помощью встроенного в Microsoft Access мастера форм по созданному заранее запросу. Внешний вид формы «Возврат билета» в конструкторе и в режиме формы после некоторых преобразований показан на рисунках 2.6 и 2.7 соответственно.

Рисунок 2.6 Вид формы «Типы питания» в режиме конструктора Рисунок 2.7 Вид формы «Типы питания»

Форма «Добавление класса» строится аналогично запросу «Типы питания» и показана на рисунках 2.8 и 2.9 соответственно.

Рисунок 2.8 Вид формы «Добавление класса» в режиме конструктора Рисунок 2.9 Вид формы «Добавление класса»

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

Рисунок 2.10 Вид формы «Посещение» в режиме конструктора Рисунок 2.11 Вид формы «Посещение»

Форма «Оплата» строится аналогично формы «Посещение» и представлена на рисунках 2.12 и 2.13.

Рисунок 2.12 Вид формы «Оплата» в режиме конструктора Рисунок 2.13 Вид формы «Оплата»

Для приложения кроме форм были созданы отчеты по заранее сформированным запросам.

1. Для отчёта по типам питания создан запрос, изображенный на рисунке 2.14.

Рисунок 2.14 Запрос по типам питания Отчет по данному запросу после некоторых преобразований принимает вид (рис 2.15 и 2.16):

Рисунок 2.15 Вид отчета по типам питания в режиме конструктора Рисунок 2.16 Вид отчета по типам питания

2. Для индивидуальной ведомости взаиморасчёта составим три запроса. Первый запрос, представленный на рисунке 2.17, вычисляет сумму уплаченную учениками за всё время питания.

Рисунок 2.17 Запрос для вывода суммы оплаченной учениками.

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

Рисунок 2.18 Запрос для вычисления итогового долга Третий запрос отбирает записи за определённую дату и для определённого класса. Также требуется рассчитать количество дней, которые ученик питался за текущий месяц, вычислить его задолженность за месяц и итоговый баланс (рис. 2.19).

Рисунок 2.19 Запрос для вывода индивидуальной ведомости

Индивидуальная ведомость взаиморасчета после некоторых преобразований примет следующий вид (рис 2.20 и 2.21).

Рисунок 2.20 Вид индивидуальной ведомости взаиморасчета в режиме конструктора Рисунок 2.21 Вид индивидуальной ведомости взаиморасчета

3. Для табеля посещаемости был построен запрос (рис. 2.22) для отбора учеников определённого класса и выбора дат, когда ученик питался.

Рисунок 2.22 Запрос для табеля посещаемости Табель посещаемости после некоторых преобразований примет следующий вид (рис 2.23 и 2.24).

Рисунок 2.23 Вид табеля посещаемости в режиме конструктора Рисунок 2.24 Вид табеля посещаемости После создания всех нужных форм и отчетов можно приступить к разработке приложения. Приложение СУБД Access разрабатывается как комплекс взаимосвязанных объектов. Наиболее часто приложения СУБД Access используют интерфейс в виде кнопочной формы, соответствующей меню и подменю предоставляемых функций обработки, а также специальные панели инструментов. Для построения кнопочной формы приложения следует разработать иерархическую структуру взаимосвязи объектов базы данных. На рисунке 2.25 представлена схема приложения.

Рисунок 2.25 Иерархическая структура приложения

Для построения кнопочной формы служит Диспетчер кнопочных форм. В нём необходимо создать две формы: «Отчёты» (рис 2.26), на которой расположены переходы на ранее созданные нами отчеты, и «Ввод данных» (рис 2.27), на которой расположены переходы на формы «Ввод ученика», «Добавление класса», «Изменение типов питания», «Посещение» и «Оплата».

Рисунок 2.26 Вид кнопочной формы «Отчёты»

Рисунок 2.27 Вид кнопочной формы «Ввод данных»

После создания кнопочной формы определим параметры запуска приложения через Настройки Access — Текущая база данных (Рис 2.28).

база данных access интерфейс Рисунок 2.28 Окно параметров запуска приложения После определения всех параметров приложение создано.

Заключение

В ходе работы над данным курсовым проектом была изучена предметная область «Столовая гимназии № 8», освоены принципы создания информационной системы, созданы информационная система для заданной предметной области и пользовательский интерфейс для этой системы. Созданная база данных позволяет в минимальные сроки произвести максимум обработки данных. Она легка в использовании, благодаря удобному интерфейсу.

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

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

1. Диго, С. М. Базы данных. Москва: Финансы и статистика, 2005.

2. Лобова О. Е., Вершинина Г. Н. Бурунин О.А. Методическое пособие по проектированию баз данных. Сочи: б.н., 2008.

3. Лобова О. Е. Базы данных: методтческие указания по выполнению курсового проекта. Сочи: СГУТиКД, 2006.

4. Куни Л. У. Кух К. MS Access 2007. Москва-СПб-Киев: Диалектика, 2007.

5. Назаров С. В. Программирование в пакетах MS Office. Москва: Финансы и статистика, 2007.