Главная страница
Навигация по странице:

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

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

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

  • Глава 2. Определение логической структуры данных

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

  • Глава 3. Построение информационно-логической модели базы данных 3.1 Построение матрицы смежности ИЛМ

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


    Скачать 0.67 Mb.
    Название1. 2 Список вопросов, на которые должна отвечать информационная
    Дата04.05.2022
    Размер0.67 Mb.
    Формат файлаdocx
    Имя файлаКурсовая работа готовая.docx
    ТипРеферат
    #511289


    СОДЕРЖАНИЕ




    Введение...................................................................................................................2

    Глава 1. Аналитическая часть................................................................................4

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

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

    система......................................................................................................................4

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

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

    Глава 2. Определение логической структуры данных.........................................8

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

    2.2 Требования нормализации..............................................................................10

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

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

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

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

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

    3.4 Разработка приложения..................................................................................17

    Заключение.............................................................................................................32

    Список использованных источников...................................................................33



    Введение



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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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


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


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

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

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

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

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



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


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


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


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

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


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

    Фамилия ученика

    Даты посещения

    Рыбьяков Андрей

    10.05.13

    11.05.13

    12.05.13


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

    Фамилия ученика

    Кол-во посещений

    Долг на месяц

    Оплачено

    Баланс

    Рыбьяков Андрей

    12

    325

    200

    125


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

    Фамилия ученика

    Тип питания

    Причина льготы

    Рыбьяков Андрей

    завтрак




    Иванцов Василий

    льготный завтрак

    Потеря кормильца

    Иванов Иван

    завтрак и обед




    Сидоров Сидр

    не питается




    Глава 2. Определение логической структуры данных


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



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

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

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

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

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

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

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

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

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

    Имя поля

    Подпись поля

    Функциональные зависимости

    number_ls

    №ЛС



    name_p

    ФИО

    number_food

    № питания

    reason_priv

    Причина льготы

    class

    Класс


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

    Имя поля

    Подпись поля

    Функциональные зависимости

    number_food

    № питания



    name_f

    Название

    cost_f

    Цена


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

    Имя поля

    Подпись поля

    Функциональные зависимости

    class

    Класс



    teach_name

    ФИО учителя

    dir_name

    ФИО директора

    school_name

    Название школы


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

    Имя поля

    Подпись поля

    Функциональные зависимости

    number_ls

    № ЛС



    date

    Баланс конец

    visit

    Зачислено


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

    Имя поля

    Подпись поля

    Функциональные зависимости

    number_ls

    ЛС



    month

    Месяц

    year

    Год

    sum

    Сумма оплаты


    После исследования предметной области выделим следующие информационные объекты:
    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)


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



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

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

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

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

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

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



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



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


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

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

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

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


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

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

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

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

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

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


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

    ИО

    1

    2

    3

    4

    5

    ИО текущего уровня

    1







    1










    2







    1










    3










    1

    1




    4



















    5



















    0 уровень

    0

    0

    2

    1

    1

    1,2

    1 уровень

    -

    -

    0

    1

    1

    3

    2 уровень







    -

    0

    0

    4,5

    Цифрами обозначены ИО: 1 — food, 2 — table_inf, 3 —pupil, 4 —visit, 5 - pay.
    3.2 Логическая модель предметной области
    Логическая структура реляционной базы данных является адекватным отображением полученной информационно-логической модели предметной области. Для канонической модели не требуется дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура реляционной таблицы определяется реквизитным составом соответствующего информационного объекта, где каждый столбец (поле, атрибут) соответствует одному из реквизитов. Ключевые реквизиты образуют уникальный ключ реляционной таблицы. Для каждого столбца таблицы задается тип, размер данных и другие свойства. Топология проекта схемы данных практически совпадает с топологией информационно – логической модели. Логическая модель необходима для выявления связей между сущностями.

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

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


    Рисунок 2.1 Логическая модель предметной области
    3.3 Построение физической модели
    Параметры каждой таблицы базы данных указаны ниже.
    «pupil»

    Имя поля

    Ключевое поле

    Обязательное поле

    Тип данных

    Размер поля

    Подпись поля

    number_ls

    Да

    Да

    Текстовый

    20

    №ЛС

    name_p

    Нет

    Нет

    Текстовый

    20

    ФИО

    number_food

    Нет

    Нет

    Текстовый

    20

    № питания

    reason_priv

    Нет

    Нет

    Текстовый

    20

    Причина льготы


    «food»

    Имя поля

    Ключевое поле

    Обязательное поле

    Тип данных

    Размер поля

    Подпись поля

    number_food

    Да

    Да

    Текстовый

    20

    № питания

    name_f

    Нет

    Нет

    Текстовый

    25

    Название

    cost_f

    Нет

    Нет

    Денежный




    Цена

    class

    Нет

    Нет

    Текстовый

    20

    Класс


    «table_inf»

    Имя поля

    Ключевое поле

    Обязательное поле

    Тип данных

    Размер поля

    Подпись поля

    class

    Да

    Да

    Текстовый

    20

    Класс

    teach_name

    Нет

    Нет

    Текстовый

    20

    ФИО учителя


    «visit»

    Имя поля

    Ключевое поле

    Обязательное поле

    Тип данных

    Размер поля

    Подпись поля

    number_ls

    Да

    Да

    Текстовый

    20

    № ЛС

    day

    Да

    Нет

    Текстовый

    20

    Дата

    visit

    Нет

    Нет

    Текстовый

    20

    Посещение


    «pay»

    Имя поля

    Ключевое поле

    Обязательное поле

    Тип данных

    Размер поля

    Подпись поля

    number_ls

    Да

    Да

    Текстовый

    18

    № ЛС

    month

    Да

    Да

    Текстовый

    20

    Месяц

    year

    Да

    Да

    Текстовый

    20

    Год

    sum

    Нет

    Нет

    Текстовый

    20

    Сумма оплаты



    3.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 Вид отчета по типам питания


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




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


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


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

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


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


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


    1. Для табеля посещаемости был построен запрос (рис. 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.





    написать администратору сайта