База данных "Учет внебюджетных образовательных услуг" (курсовая: программа (база данных Access) и пояснительная записка)


СОДЕРЖАНИЕ

ВВЕДЕНИЕ    3
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ    4
2. ПРОЕКТНАЯ ЧАСТЬ    9
2.1. Постановка задачи    9
2.2. Логическая модель системы    11
2.3. Концептуальная модель системы    15
2.4. Структура БД системы    17
2.5. Формы    22
2.6. SQL запросы    24
2.7. Отчеты    27
ЗАКЛЮЧЕНИЕ    29
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ    30

 

Введение

 

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

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

Целью данной работы является разработка информационной системы с использованием СУБД для автоматизации учета внебюджетных образовательных услуг. Для достижения поставленной цели в работе используется СУБД Microsoft Access 2003. Выбор СУБД обусловлен тем, что программный комплекс Access входит  в пакет Microsoft Office и, таким образом, доступен всем пользователям, у кого установлен этот пакет.

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

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

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

- реализовать информационную систему в СУБД Microsoft Access 2003.

 

2. Проектная часть

2.1. Постановка задачи

 

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

-  ввод, хранение и обработка договоров на оказание образовательных услуг;

-  учет учащихся (клиентов);

-  учет оплаты договоров;

-  учет преподавателей (сотрудников);

-  составление расписания;

-  формирование отчётов по результатам выполнения вышеперечисленных  функций.

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

-  рассмотреть теоретическую основу разработки БД;

-  спроектировать логическую и концептуальные схемы БД;

-  создать неизбыточную реляционную БД с контролем целостности данных;

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

-  разработать запросы для извлечения соответствующих данных, хранящихся в БД;

-  разработать отчеты о результатах обращения к соответствующим данным, хранящимся в БД.

Проектируемая информационная система должна отвечать следующим требованиям:

- функциональность - система обеспечивает максимально полное выполне­ние всех указанных выше функций;

- информативность - формируемая системой отчетность содержит достаточ­ное количество информации для представления объективной картины состояния дел в учете оплаты образовательных услуг;

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

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

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

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

- ОС Windows 2000 и выше (рекомендуется Windows XP);

- установленная СУБД Microsoft Access;

- оперативная память 64 Мб и выше;

- для хранения программы c исходной БД потребуется около 10 Мб на жестком диске (в зависимости от объема входящей информации размер рабочей базы данных может изменяться);

- набор стандартных средств ввода/вывода (клавиатура, мышь, монитор);

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

 

2.2. Логическая модель системы

 

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

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

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

Рассмотрим процесс оплаты внебюджетных образовательных услуг.

  1. Клиент (учащийся) заключает договор на оказание определенных образовательных услуг. Договор регистрируется в журнале договоров, где указывается порядковый номер договора, дата заключения договора, наименование, адрес и другая контактная информация клиента, суть оказываемой услуги, длительность услуги по времени, то есть ее количественное измерение, а также стоимость услуги.
  2. На основании поступившего договора директор образовательного учреждения определяет, в какой класс или группу определить учащегося. В классы  набирают учащихся, желающих получить второе высшее образование. При этом, некоторые предметы им могут перезачтены в зависимости от первого полученного ими высшего образования и получаемого второго высшего. Поэтому стоимость второго высшего образования варьируется индивидуально и, соответственно, отдельно рассчитывается стоимость предоставления услуг по каждой конкретной дисциплине. Также организация предоставляет услуги по прохождению краткосрочных курсов по специальностям, связанным с программным обеспечением компьютера. Клиенты, желающие проходить краткосрочные курсы, объединяются в группы соответствующей тематики.
  3. Статистика оказания дополнительных платных показывает, что спрос на них никогда не превышает предложения, то есть, всегда находится нужный сотрудник, имеющий свободное время для оказания услуги. Это определяется несколькими факторами, такими как:

- специфичность услуг;

- большой штат учреждения;

- многопрофильность многих сотрудников;

- возможность объединить желающих при большом спросе в группы;

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

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

При построении логических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). Для построения ER-диаграмм используют различные программные продукты. Мы использовали для построения ER-диаграммы процесса оплаты дополнительных услуг программу Microsoft Visio 10, которая, на наш взгляд, является одной из наиболее простых в использовании. Инфологическая модель системы представлена на рис. 1.

Рис. 1. Логическая модель системы

На рисунке прямоугольные области означают сущности. В СУБД Microsoft Access этим сущностям будут соответствовать таблицы. PK (primary key) – первичный ключ, FK1, FK2, … , FKN – (foreign key) – внешние ключи. Внешний ключ обеспечивает связь родительской и дочерней таблиц.

Между двумя сущностям, например, А и В возможны четыре вида связей. Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

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

 

2.3. Концептуальная модель системы

 

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

Как видно на рис. 2, данная модель связаны с конкретной средой разработки – СУБД Microsoft Access 2003, которая предлагает вышеуказанные типы данных (рис. 3).

 

Рис. 2. Концептуальная модель системы

 

Рис. 3. Типы данных  СУБД Microsoft Access

 

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

 

Рис. 4. Размер поля числового типа в СУБД Microsoft Access

 

Также можно выбирать и формат поля (рис. 5).

 

Рис. 5. Формат поля числового типа в СУБД Microsoft Access

 

2.4. Структура БД системы

 

Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства). В БД мы используем 8 таблиц: Учащиеся, Преподаватели, Дисциплины, Договора, Оплата, Аудитории, Классы, Расписание. Эти таблицы связаны между собой средствами поддержания целостности, заданными на физическом уровне, то есть на уровне структуры БД.

Например, при добавлении нового объекта в таблицу Договора, надо обязательно указать внешний ключ к таблице Учащиеся. Если данный ключ не указан или ключа с таким значением в таблице Учащиеся не существует, то запись в таблицу Договора не будет добавлена. На рис. 6 изображена  структура таблицы Преподаватели. В этой таблице хранятся данные о сотрудниках (преподавателях) образовательного учреждения.

1) Поле Номер_преп – это поле первичного ключа таблицы автоинкрементального типа (то есть счетчик).

2) Поле ФИО – текстовое поле с ФИО сотрудника.

3) Поле Адрес – адрес сотрудника.

4) Поле Телефон – домашний телефон сотрудника.

 

Рис. 6. Структура таблицы Преподаватели

 

На рис. 7 изображена структура таблицы Учащиеся. В этой таблице хранятся данные о заказчиках услуг образовательного учреждения.

1) Поле Номер_уч – первичный ключ автоинкрементального типа.

2) Поле ФИО – ФИО клиента.

3) Поле Адрес – адрес сотрудника.

4) Поле Телефон – телефон клиента.

5) ИНН – ИНН клиента. Поле ИНН не может выступать в качестве первичного ключа, потому что у некоторых людей нет ИНН. Тогда в поле ИНН проставляется 0, то есть значения этого поля могут быть не уникальными, что противоречит требованиям к первичному ключу. Если клиентом выступает организация, название организации следует указывать в поле ФИО, что сделано для упрощения структуры БД и исключения лишних таблиц и индексов.

6) Номер_класс – внешний ключ к таблице Классы.

 

Рис. 7. Структура таблицы Учащиеся

 

На рис. 8 изображена структура таблицы Дисциплины. В этой таблице хранятся данные о внебюджетных образовательных услугах (дисциплинах).

1) Поле Номер_дисц – поле первичного ключа типа счетчик.

2) Поле Дисциплина – название услуги.

3) Поле Цена – цена 1 часа оказания услуги. Тип поля – денежный.

4) Номер_преп – внешний ключ к таблице Преподаватели.

 

Рис. 8. Структура таблицы Дисциплины

 

На рис. 9 изображена структура таблицы Договора. В этой таблице хранится информация о заключенных договорах.

1) Поле Номер_договора – поле первичного ключа числового типа.

2) Поле Дата – дата подписания договора.

3) Поле Номер_уч – внешний ключ к таблице Учащиеся.

4) Поле Номер_дисц – внешний ключ к таблице Дисциплины.

5) Поле Количество – количество услуг по договору (в часах).

 

Рис. 9. Структура таблицы Договора

 

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

1) Поле Номер_счета_фактуры –первичный ключ числового типа.

2) Поле Номер_договора – внешний ключ к таблице Договора.

3) Поле Дата – дата оплаты услуг по соответствующему договору.

 

Рис. 10. Структура таблицы Оплата

 

На рис. 11 изображена структура таблицы Расписание. Это основная таблица, которая имеет внешние ключи ко многим таблицам.

1) Поле Номер_занятия – поле первичного ключа типа счетчик.

2) Поле День – дата учебного дня.

3) Поле Номер_ауд – внешний ключ к таблице Аудитории.

4) Поле Номер_дисц – внешний ключ к таблице Дисциплины.

5) Поле Номер_класс – внешний ключ к таблице Классы.

6) Начало – начало занятия.

7) Конец – конец занятия.

 

Рис. 11. Структура таблицы Расписание

 

База данных "Учет внебюджетных образовательных услуг"

Рис. 12. Схема данных БД

 

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

 

2.5. Формы

 

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

На рис. 13 представлена форма для просмотра и добавления информации об учащихся.

 

Рис. 13. Форма для просмотра и добавления информации о клиентах

 

Для навигации используются встроенные средства Microsoft Access 2003 – кнопки в самом низу формы. Кнопка со звездочкой предназначена для открытия нового бланка для заполнения. После заполнения бланка соответствующей (корректной) информацией, следует просто закрыть форму или перейти на другую запись, и новая запись будет добавлена в БД.  Запись не будет добавлена в 3 случаях: неправильно заполнено поле первичного ключа; неправильно указан внешний ключ; запись с таким первичным ключом уже существует в таблице.  Соответственно следует просматривать, добавлять и редактировать информацию о преподавателях (рис. 14).

 

Рис. 14. Форма для просмотра информации о преподавателях

 

На рис. 15 представлена форма для просмотра и добавления информации о дисциплинах.

 

Рис. 15. Форма для просмотра информации о дисциплинах

 

На рис. 16 представлена главная форма программы с выпадающим списком и кнопкой.

 

Рис. 16. Главная форма программы

 

В раскрывающемся списке содержится расписание на текущий день (рис. 17).

 

Рис. 17. Расписание на текущий день

 

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

 

Рис. 18. Вызов подчиненной формы

 

2.6. SQL запросы

 

Для отбора требуемых данных используем SQL запросы. Запросы - эти объекты служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняют такие операции как отбор данных, их сортировку и фильтрацию.

С помощью запросов можно выполнять преобразования данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнения таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое. Запросы в СУБД Access можно создавать несколькими способами – с помощью мастера, с помощью конструктора – с использованием элементов визуального конструирования или полностью вручную. Запрос «Расписание» выдает расписание на текущую дату:

 

SELECT День, Номер_ауд, Дисциплины.Дисциплина, Классы.Класс, Начало, Конец

FROM (Расписание INNER JOIN Дисциплины ON Расписание.Номер_дисц=Дисциплины.Номер_дисц AND Расписание.День = Date()) INNER JOIN Классы ON Расписание.Номер_класс=Классы.Номер_класс

 

Результат выполнения запроса представлен на рис. 19.

 

Рис. 19. Результат выполнения запроса «Расписание»

 

Следующий запрос выдает преподавателей соответствующих дисциплин, причем отсортированных по ФИО:

SELECT ФИО, Дисциплина

FROM Преподаватели INNER JOIN Дисциплины ON Преподаватели.Номер_преп=Дисциплины.Номер_преп

ORDER BY ФИО;

Результат выполнения запроса представлен на рис. 20.

 

Рис. 20. Результат выполнения запроса «Преподаватели дисциплин»

 

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

SELECT (Дисциплины.Цена * Договора.Количество) AS Стоимость_услуги

FROM Дисциплины INNER JOIN Договора ON (Договора.Номер_дисц =Дисциплины.Номер_дисц AND Договора.Номер_договора = 10784);

 

Результат выполнения запроса «Расчет оплаты» представлен на рис. 21.

 

Рис. 21. Результат выполнения запроса «Расчет оплаты»

 

Так, в данном случае была рассчитана стоимость 50 часов преподавания дисциплины «Теория и практика БД» в рамках получения второго высшего образования. Все краткосрочные курсы одинаковы по длительности (10 часов), однако стоимость одного часа преподавания соответствующего курса совпадает со стоимостью часа преподавания такой же дисциплины в рамках второго высшего образования.

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

 

SELECT Sum(Дисциплины.Цена*Договора.Количество) AS Прибыль

FROM (Договора INNER JOIN Оплата ON Договора.Номер_Договора=Оплата.Номер_договора) INNER JOIN Дисциплины ON Договора.Номер_дисц=Дисциплины.Номер_дисц

WHERE (((Договора.Номер_Договора)=Оплата.Номер_Договора) And

((Договора.Номер_дисц)=Дисциплины.Номер_дисц));

 

Результат выполнения запроса «Расчет оплаты» представлен на рис. 22.

 

Рис. 22. Результат выполнения запроса «Прибыль всего»

 

2.7. Отчеты

 

Отчет состоит из данных, полученных из таблицы или запроса, а также данных макета отчета — надписей, заголовков и рисунков. Таблица или запрос с данными для отчета называются также источником записей отчета. Перед началом создания отчета необходимо определиться с тем, какие сведения в него будут включены. В числе выбранных полей должны быть те поля, которые будут сгруппированы, или поля, по которым будет подводиться итог. Если все нужные поля находятся в одной таблице, в качестве источника записей нужно использовать эту таблицу. Если данные находятся в разных таблицах, в качестве источника записей используется запрос — он, возможно, уже существует в базе данных; в противном случае придется создать запрос специально для отчета. Группировка позволяет организовать записи в группы, например по региону или по продавцу. Группы можно вкладывать друг в друга, что позволит легко выявить связи между группами и быстро найти нужные сведения. Группировка также используется для подсчета итоговых и процентных показателей. Отчет по расписанию представлен на рис. 23. Это отчет с группировкой по классам.

 

Рис. 23. Отчет по расписанию

 

 

Заказать курсовую

 

Добавить комментарий


Защитный код
Обновить