Автоматизация учета студентов в ВУЗе

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Автоматизация учета студентов в ВУЗе

Автоматизация учета студентов в ВУЗе

Пояснительная записка __ с., __ рис., __ табл., __ источника, __ прил.

В данном курсовом проекте объектом исследования является процесс учета студентов в ВУЗе.

Объектом автоматизации является доступ и хранение информации о студентах.

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

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

Содержание

Введение

1 Описание учета студентов в ВУЗе

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

3 Концептуальное проектирование СУБД

3.1 Разработка схемы объект-отношение

3.2 Обоснование выбора модели данных

3.2.1 Типы моделей данных

3.2.2 Иерархическая модель данных

3.2.3 Сетевая модель данных

3.2.4 Реляционная модель данных

3.3 Нормализация таблиц

3.3.1 Выделение функциональных зависимостей

3.3.2 Описание нормальных форм

3.3.3 Описание РМД

4 Программная реализация СУБД

4.1 Описание таблиц

4.2 Описание реализованных запросов к БД

4.3 Описание разработанных форм

4.4 Описание сформированных отчетов

4.5 Описание макросов

5 Уровни доступа к СУБД

Выводы

Приложение А. Техническое задание

Приложение Б. Заполненные таблицы

Приложение В. Руководство пользователю

Список используемых источников

Перечень обозначений, символов, единиц, сокращений и терминов

БД - База данных

СБД - Система базы данных

ПП - Программный продукт

SQL - Select Query Language

СМД - Сетевая модель данных

РМ - Реляционная модель данных

ИМ - Иерархическая модель данных

УС - Учет студентов

Введение

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

- надежно хранить информацию;

- изменять (добавлять, удалять, обновлять) информацию;

- уменьшить время доступа к необходимой информации;

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

Таким образом, СУБД очень хорошо подходят для хранения и систематизации любой информации на работе.

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

Предметная область курсового проекта - обработка информации о студентах ВУЗа, представление информации о специальностях, местах жительства студентов, о родителях и т.д. Базу данных могут использовать как сотрудники ВУЗа, так и сами студенты.

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

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

1 Описание учета студентов в ВУЗе

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

Для разработки такой базы нам необходимо знать такую информацию о студентах: ФИО, контактный телефон, домашний адрес (включая область, город (поселок и т.д.) и индекс, т.к. студент может быть иногородним), пол, форма обучения (очная/заочная), № зачетки, год рождения. Если, допустим, невозможно связаться со студентом (долго не было в ВУЗе, изменились контактные данные и т. д.) или о чём-то необходимо сообщить их родителям, то нам потребуется их информация, а именно: ФИО мамы и ее контактные данные, а также ФИО и контактная информация папы. Если нет родителей, то указываем контактные данные родственников (близких).

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

Если студент является иногородним и проживает в общежитии, то следует учесть адрес того общежития, куда заселен, телефон, ФИО коменданта.

Так как каждый год студент заселяется и выселяется из общежития, необходимо учитывать дату заселения и выселения. Также студента могут селить каждый год в разные комнаты, и для этого следует содержать информацию о номере комнаты (например, комната № 2.713, где 2- номер самого общежития, 7- этаж, 13- № комнаты на этом этаже), типе комнаты (женский/мужской) и количеству мест в этой комнате.

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

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

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

В целом, база данных должна:

· содержать необходимую информацию о студентах;

· обеспечивать возможность выполнять запрос, поиск, изменение и систематизацию данных БД;

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

· иметь необходимые запросы и формы для обработки хранимой информации;

· предусматривать архивацию данных и сохранность хранимой в БД информации.

3 Концептуальное проектирование СУБД

В нашей базе данных было выбрано 6 объектов: «Студент», «Группа», «Специальность», «Факультет», «Комната» и «Общежитие».

Рассмотрим свойства каждого из этих объектов и отношения, которыми связаны объекты. Главным объектом является «Студент», который имеет 11 свойств: ФИО, год рождения, домашний адрес, контактный телефон, пол, ФИО мамы, контактная информация мамы, ФИО папы и его контактная информация, форма обучения, № зачетки. Этот объект связан отношением «учится в…» с объектом «Группа». Также он объект связан отношением «проживает в …» с объектом «Комната».

Следующий наш объект - «Группа» имеет 2 свойства: год набора и буква и связан отношением «принадлежит к …» с объектом «Специальность».

Объект «Специальность»- 3 свойства: полное название, краткое название и шифр; связан отношением «относится к…» с объектом «Факультет».

Объект «Факультет» характеризуется свойствами: полное название, краткое название, Ф.И.О. декана, № телефона деканата.

Объект «Комната» имеет 3 свойства: тип комнаты, количество мест и № комнат и связан отношением «принадлежит к…» с объектом «Общежитие».

К «Общежитию» относятся 3 свойства: адрес, ФИО коменданта, номер телефона общежития.

Отношение «Проживает в…» обладает свойствами дата заселения и дата выселения.

В данной схеме используются 2 связи: один ко многим () и многие ко многим (). Между объектами «Студент» и «Группа» выбрана связь , потому что каждый студент учится только в одной на данный момент группе, а группа содержит много студентов.

Между «Группой» и «Специальностью» выбрано отношение : одна группа принадлежит к одной специальности, в свою очередь к одной специальности может принадлежать несколько групп. Аналогичная связь связывает объекты «Специальность» и «Факультет»- к одному факультету может относиться много различных специальностей; одна специальность относится к одному факультету. Рассмотрим связь между объектами «Комната» и «Общежитие»: т.к. каждая комната принадлежит одному общежитию, а общежитие содержит множество комнат. В итоге получаем отношение . Между объектом «Студент» и «Комната» получаем отношение , т.к. один студент может проживать в разное время в разных комнатах, а в одной комнате может проживать несколько студентов. На рис.3.1 показана схема «Объект отношения».

3.2 Обоснование выбора модели данных

3.2.1 Типы моделей данных

БД может быть основана на одной модели или на совокупности нескольких моделей. Любую модель данных можно рассматривать как объект, который характеризуется своими свойствами (параметрами), и над ней, как над объектом, можно производить какие-либо действия.

Любая модель должна обеспечивать такие операции над БД:

- поиск указанного элемента базы;

- переход от одних данных к другим;

- движение по записям;

Существуют три основных типа моделей данных - реляционная, иерархическая и сетевая.

3.2.2 Иерархическая модель данных

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

Узел - информационная модель элемента, находящегося на данном уровне иерархии.

Свойства иерархической модели данных:

- несколько узлов низшего уровня связано только с одним узлом высшего уровня;

- иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине;

- каждый узел имеет свое имя (идентификатор);

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

Пример реализации иерархической модели данных для разрабатываемой БД представлен на рисунке 3.2.

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

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

3.2.3 Сетевая модель данных

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

Основной структурой в сетевых моделях данных является «сеть». При таком представлении существует несколько входов в сеть - неоднозначность доступа к данным.

Особенности такого представления: один или несколько узлов могут иметь больше одного родителя; время доступа изменяется в зависимости от исходного входа. Время доступа в сетевой структуре может быть больше, чем в иерархической структуре.

Схема сетевой модели данных для данной БД показана на рисунке 3.3.

Рис. 3.3 - Схема сетевой модели данных

К достоинствам СМД относят:

- возможность создания произвольных связей (например, растения произрастают на закрепительном участке, и закрепительный участок имеет растения);

- эффективную реализацию с точки зрения затрат времени и памяти.

Недостатки такие:

- сложность и жесткость схемы;

- сложность в установлении и проверке целостности данных.

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

3.2.4 Реляционная модель данных

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

- реляционная модель является более простой моделью, чем сетевая;

- схема данных позволяет представить структуру в виде таблиц (после некоторых преобразований);

- в настоящее время реляционные базы данных являются более

распространенными, чем сетевые;

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

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

- реляционная МД нагляднее представляет структуру данных.

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

Для проектируемой БД реляционная модель представлена на рисунке 3.4.

3.3 Нормализация таблиц

3.3.1 Выделение функциональных зависимостей

Функциональная связь - связь вида один ко многим в одной таблице.

Пусть R - отношение, в котором существуют подмножества множества атрибутов х и у. Тогда х>у (у функционально зависит от х) тогда и только тогда, когда для каждого допустимого значения R каждое значение х связано только с одним у. Если совпадение по х, то и по у.Если х - потенциальный ключ, то все атрибуты этого отношения всегда функционально от него зависят. На рисунке 3.5 изображена схема функциональных зависимостей.

Рис.3.5 - Схема функциональных зависимостей таблиц

3.3.2 Описание нормальных форм

Докажем, что спроектированная БД нормализована до третей нормальной формы. Так как, по определению, если БД находится в третьей нормальной форме, то она находится и в первой и во второй нормальных формах, то докажем сперва, что данная БД находится в первой нормальной форме.

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

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

Повторяющимися являются поля, содержащие одинаковые по смыслу значения.

Так как разрабатываемая БД удовлетворяет этим ограничениям, то она находится в первой нормальной форме.

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

Итак, ограничениям, накладываемым второй нормальной формой, разрабатываемая БД удовлетворяет.

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

Все таблицы данной БД удовлетворяют этому условию, следовательно, БД находится в третьей нормальной форме.

3.3.3 Описание РМД

Объекты данной предметной области предоставляются в виде таблиц, свойства становятся атрибутами либо полями. Таблиц и полей с одинаковыми названиями быть не может. В каждой таблице выделяется свойство, которое является ключевым. В каждой таблице первичным ключом будет первичное поле (#). По правилу построения РМД, ключевое поле из таблицы, объект которой связан с другим объектом отношением , добавляется в таблицу, которое соответствует отношению «много» (). Таких связей получается 5. «Студент» связан с объектом «Группа» отношением , значит, первичным ключом у нас является код группы (# КГр) и подсоединяем его к таблице «Студент», где записываем внешний ключ (КГр #). Аналогичным образом мы проделываем остальные таблички:

· таблицу «Специальность», где первичный ключ (счетчик) (#КСп), соединяем стрелочкой с таблицей «Группа» (КСп # );

· «Факультет» (#КФ) соединяем с таблицей «Специальность», где внешним ключом будет (КФ#);

· таблицу «Общежитие» (первичный ключ(#КО)) соединяем с «Комната» (КО#);

· «Студент» (#КСт) соединяем с «Проживает» (КСт #).

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

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

Таким образом, после рассмотрения приведенных выше моделей данных для разработанной в пункте 3 схемы «объект-отношение» была выбрана реляционная модель, которая проста и понятна для пользователя и отвечает требованиям изучаемого курса.

4 Программная реализация СУБД

4.1 Описание таблиц

Таблица «Студент» - справочник студентов.

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

ФИО - фамилия, имя и отчество студента, тип текстовый, размер 50 символов, поле обязательное, индексированное, допускаются совпадения.

№ зачетки - содержит номер зачетки, тип текстовый, размер 10 символов, содержит маску ввода: 00\/000, условие на значение:>0, если вводится неправильное значение, выводится сообщение об ошибке ”Некорректный ввод”; поле обязательное, индексированное, совпадения не допускаются.

Дата рождения - содержит дату рождения, тип дата/время, имеет краткий формат даты, маска ввода 00.00.0000;0;_, условие на вводимое значение <Now()-365*16 (т.е. студенту должно быть не меньше 16 лет), если вводится неправильное значение, выводится сообщение об ошибке, обязательное поле, индексированное, допускаются повторения.

Домашний адрес - содержит адрес проживания студента, тип текстовый, размер 50 символов, поле обязательное, индексированное, допускаются совпадения.

Контактный телефон - содержит номер телефона, тип текстовый, размер 20 символов, содержит маску ввода: 0\-000\-000\-00\-00;;_ . Поле необязательное, индексированное, не допускаются совпадения.

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

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

ФИО матери - фамилия, имя, отчество матери студента, тип текстовый, размер 50 символов, поле обязательное, индексированное, допускаются совпадения.

ФИО отца - фамилия, имя, отчество отца студента, тип текстовый, размер 50 символов, поле обязательное, индексированное, допускаются совпадения.

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

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

Группа- код группы, тип числовой, размер поля - длинное целое, обязательное поле, поле со списком, тип источника - таблица или запрос: SELECT Группа.[Код группы], Группа.[Название группы] FROM Группа ORDER BY [Название группы];.

Таблица «Группа» содержит информацию о группах, в которых учатся студенты.

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

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

Год набора - тип дата/время, размер 20 символов, маска ввода- 00.00.0000;0;_, обязательное и индексированное поле, совпадения допускаются, условие назначения: >Date()-(5*365). Если вводится неправильное значение, то выводится сообщение об ошибке.

Буква - тип текстовый, размер 5 символов, обязательное и индексированное поле, совпадения допускаются. Если вводится неправильное значение, то выводится сообщение об ошибке. Поле со списком, тип источника строк - список значений, источник строк - а; б; в; г; -;.

Специальность- код специальности, тип числовой, обязательное поле, размер поля - длинное целое. Тип источника строк -таблица или запрос, источник строк- SELECT Специальность.[Код специальности], Специальность.[Краткое название] FROM Специальность ORDER BY [Краткое название].

Таблица «Специальность» справочник специальностей факультетов.

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

Полное название - тип текстовый, размер 50 символов, обязательное и индексированное поле, совпадения не допускаются.

Краткое название - тип текстовый, размер 10 символов, необязательное поле, без повторений.

Шифр - тип текстовый, размер 20 символов, содержит маску ввода: 0000000.0.00;. Обязательное и индексированное поле, без повторений.

Факультет - код факультета, тип числовой, обязательное поле, размер поля - длинное целое. Тип источника строк - таблица или запрос, источник строк- SELECT Факультет.[Код факультета], Факультет.[Краткое название] FROM Факультет ORDER BY [Краткое название];

Таблица «Факультет» содержит информацию о всех факультетах ВУЗа.

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

Полное название - тип текстовый, размер 50 символов, обязательное и индексированное поле, совпадения не допускаются.

Краткое название - тип текстовый, размер 10 символов, необязательное поле, без повторений.

ФИО декана - тип текстовый, размер 50 символов, поле обязательное, индексированное, не допускаются совпадения.

№ телефона деканата - тип текстовый, размер 20 символов, маска ввода: 000\-00\-00; поле обязательное, индексированное, совпадения не допускаются.

Таблица «Комната» содержит информацию о комнатах общежития.

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

Количество мест - тип числовой, размер 5 символов, обязательное и индексированное поле, совпадения допускаются. Значение по умолчанию: 0, условие на значение: >0, если вводится неправильное значение, то выдается ошибка.

Тип - тип текстовый, размер 10 символов, обязательное и индексированное поле, совпадения допускаются. Поле со списком, тип источника строк - список значений, источник строк - мужская; женская; семейная.

№ комнаты - тип числовой, содержит маску ввода: 0”.”000, обязательное поле, индексированное, совпадения допускаются. Значение по умолчанию: 0, условие на значение: >0, если вводится неправильное значение, то выдается ошибка.

Общежитие- код общежитие, тип числовой, обязательное поле, размер поля - длинное целое. Тип источника строк - таблица или запрос, источник строк: SELECT Общежитие.[Код общежития] FROM Общежитие ORDER BY [Код общежития];

Таблица «Общежитие» содержит информацию о общежитиях, которые принадлежат ВУЗу.

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

Адрес - тип текстовый, размер 50 символов, поле обязательное, индексированное, не допускаются совпадения.

Телефон - тип текстовый, размер 20 символов, маска ввода: 000\-00\-00; поле обязательное, индексированное, совпадения не допускаются.

ФИО Коменданта- тип текстовый, размер 50 символов, поле обязательное, индексированное, не допускаются совпадения.

Таблица «Проживает» - дополнительная таблица, созданная для исключения связи «многие-ко-многим». Таблица содержит информацию о дате заселения (выселения) студентов в (из) общежитие (ия).

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

Студент - код студента, тип числовой, обязательное поле, размер поля- длинное целое. Подстановка из таблицы «Студент», отображается поле «Студент» таблицы «Студент».

Комната - код комнаты, тип числовой, обязательное поле, размер поля- длинное целое. Тип источника строк - таблица или запрос, источник строк: SELECT Комната.[Код комнаты], Комната.[№ комнаты] FROM Комната ORDER BY [№ комнаты];

Дата заселения - тип дата/время, размер 20 символов, маска ввода- 00.00.0000;0;_, обязательное и индексированное поле, совпадения допускаются.

Дата заселения - тип дата/время, размер 20 символов, маска ввода- 00.00.0000;0;_, обязательное и индексированное поле, совпадения допускаются.

4.2 Описание реализованных запросов к БД

В данном КП были реализованы следующие запросы к БД:

Запрос1 является запросом на выборку.

Осуществляется поиск повторений для таблицы «Студент».

Вид в режиме SQL:

SELECT Студент.Группа, Студент.ФИО

FROM Студент

WHERE (((Студент.Группа) In (SELECT [Группа] FROM [Студент] As Tmp GROUP BY [Группа] HAVING Count(*)>1 )))

ORDER BY Студент.Группа;

Результат выполнения запроса 1 представлен на рисунке 4.2.1

Рис. 4.2.1- Результат выполнения запроса 1

Запрос 2 является запросом на создание таблицы.

Создается новая таблица, куда вносится новая информация.

Вид в режиме SQL:

SELECT Студент.ФИО, Общежитие.[Код общежития] INTO New

FROM Студент INNER JOIN (Общежитие INNER JOIN (Комната INNER JOIN Проживает ON (Комната.[Код комнаты] = Проживает.Комната) AND (Комната.[Код комнаты] = Проживает.Комната)) ON Общежитие.[Код общежития] = Комната.Общежитие) ON Студент.[Код студента] = Проживает.Студент

WHERE (((Общежитие.[Код общежития])=2));

Результат выполнения запроса 2 представлен на рисунке 4.2.2

Рис. 4.2.2- Результат выполнения запроса 2

Запрос 3 является запросом на добавление.

Выполняется заполнение архива.

Вид в режиме SQL:

INSERT INTO Архив ( ФИО, №Зачетки, [Дата рождения], [Домашний адресс], [Контактный телефон], Пол, [Форма обучения], [ФИО матери], [ФИО отца], [Контактная информация отца], [Контактная информация матери], Группа )

SELECT Студент.ФИО, Студент.№Зачетки, Студент.[Дата рождения], Студент.[Домашний адрес], Студент.[Контактный телефон], Студент.Пол, Студент.[Форма обучения], Студент.[ФИО матери], Студент.[ФИО отца], Студент.[Контактная информация отца], Студент.[Контактная информация матери], Студент.Группа

FROM Студент

WHERE (((Студент.[Дата рождения])<Now()-365*25));

Результат выполнения запроса 3 представлен на рисунке 4.2.3

Рис. 4.2.3- Результат выполнения запроса 3

Запрос 4 является запросом на удаление.

Выполняется очистка всей информации в архиве.

Вид в режиме SQL:

DELETE Архив.*

FROM Архив;

Результат выполнения запроса 4 представлен на рисунке 4.2.4

Рис. 4.2.4- Результат выполнения запроса 4

Запрос 5 является запросом на удаление.

Осуществляется удаление старых записей.

Вид в режиме SQL:

DELETE Студент.ФИО, Студент.№Зачетки, Студент.[Дата рождения]

FROM Студент

WHERE (((Студент.[Дата рождения])<Now()-365*25));

Результат выполнения запроса 5 представлен на рисунке 4.2.5

Рис. 4.2.5- Результат выполнения запроса 5

4.3 Описание разработанных форм

Форма «Главная» ( см. рисунок 4.3.1).

Форма «Главная» запускается при запуске программы. Форма имеет три кнопки выбора пользователей - «Гость», «Пользователь» и «Администратор». При нажатии кнопки «Гость», форма «Главная» закрывается и запускается форма «Вход», кнопки «Пользователь» - «Главная» закрывается, запускается «Введите пароль», кнопки «Администратор» - «Главная» закрывается, запускается «Введите пароль». Об этих формах подробно чуть позже. Также находится кнопка «Выход», при нажатии которой закрывается форма и происходит выход из программы. В центре формы - текст с выбором уровня доступа к базе данных. Под кнопками выводятся текущие дата и время.

Рис. 4.3.1- Форма «Главная» в режиме «Вид»

Форма «Гость» ( см. рисунок 4.3.2).

При открытии кнопки «Гость», «Главная» форма закрывается и открывается форма «Вход» Слева появляются 3 кнопки, из которых кнопка «Студенты» является активной, т.к. гость может только просматривать данные о студентах ВУЗа. Какие либо изменения он вносит не может.

Рис. 4.3.2- Форма «Вход» при открытии кнопки «Гость»

Форма «Пользователь» ( см. рисунок 4.3.3).

Это форма запускается при нажатии кнопки «Пользователь» в форме «Главная». Сверху находится надпись «Введите пароль». Внизу - поле для ввода пароля. Справа- кнопки «ОК» (при нажатии этой кнопки: если введённый в поле пароль верный - закрытие формы «Пользователь» и запуск формы «Вход» с доступными для пользователя опциями; если же пароль неверный, то выводится сообщение о неверности пароля, и после нажатия кнопки «ОК» в этом сообщении, пользователю предлагается повторить ввод пароля) и «Отмена» (при нажатии этой кнопки поле «Пользователь» закрывается и запускается поле «Главная»).

Рис. 4.3.3- Форма «Пользователь» в режиме «вид»

Форма «Администратор» (рисунок 4.3.4).

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

Рис. 4.3.4- Форма «Администратор» в режиме «вид»

Форма «Студенты ВУЗа» (рисунок 4.3.5)

Источником данных является таблица «Студенты». Форма «Студенты ВУЗа» позволяет осуществить прокрутку информации студентов, которые числятся в ВУЗе.

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

Рис. 4.3.5- Форма «Студенты ВУЗа» в режиме «вид»

Форма «Общежития ВУЗа» (рисунок 4.3.6)

Источником данных является таблица «Общежития». Форма «Общежитиия ВУЗа» позволяет осуществить прокрутку информации общежитий, принадлежащих ВУЗу. Данная форма имеет следующие кнопки управления элементами: кнопки движения к первой и к последней записи, кнопки передвижения по списку, добавление, сохранение и удаление общежития, выход из этой формы, а также кнопку просмотр отчета.

Рис. 4.3.6- Форма «Общежития ВУЗа» в режиме «вид»

Форма «Архив» (рисунок 4.3.7)

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

Рис. 4.3.7- Форма «Архив» в режиме «вид»

Форма «Проживающие в общежитиях» (рисунок 4.3.8)

Источником данных является таблица «Проживает». Эта форма содержит кнопки управления, которые позволяют осуществить прокрутку информации проживающих в общежитиях, принадлежащих ВУЗу. Данная форма имеет следующие кнопки управления элементами: кнопки движения к первой и к последней записи, кнопки передвижения по списку, добавление, сохранение, удаление и поиск проживающего. Форма содержит кнопку «Заявление на проживание», где студент может заполнить заявления на проживание в общежитии. Также находится кнопка «Выход».

Рис. 4.3.8- Форма «Проживающие в общежитиях» в режиме «вид»

Форма «Группы» (рисунок 4.3.9)

Источником данных является таблица «Группы».Эта форма содержит кнопки управления, которые позволяют осуществить прокрутку информации проживающих о группах специальностей ВУЗа. Данная форма имеет следующие кнопки управления элементами: кнопки движения к первой и к последней записи, кнопки передвижения по списку, добавление, сохранение, удаление. Форма содержит кнопку «Студенты группы», где указаны студенты той или иной группы. Имеется кнопка «Выход».

Рис. 4.3.9- Форма «Группы» в режиме «вид»

Форма «Комнаты» (рисунок 4.3.10)

Источником данных является таблица «Комнаты». Эта форма содержит кнопки управления, которые позволяют осуществить прокрутку информации проживающих о комнатах общежитий ВУЗа. Данная форма имеет следующие кнопки управления элементами: кнопки движения к первой и к последней записи, кнопки передвижения по списку, добавление, сохранение, удаление и поиск той или иной комнаты. Форма содержит кнопку «Проживающие этой комнаты», где можно увидеть проживающего в той комнате, которую вы ввели.

Рис. 4.3.10- Форма «Комнаты» в режиме «вид»

4.4 Описание сформированных отчетов

Отчет «Студенты ВУЗа»

Отчет создан с помощью мастера.Выводится вся информация о студента ВУЗа: ФИО, домашний адрес, № зачетки, контактный телефон, пол, дата рождения, форма обучения, ФИО мамы, ФИО папы, контактная информация о матери и отца. Данный отчет состоит из 8 страниц. Вид отчета в режиме вид представлен на рисунке 4.4.1.

Студенты

ФИО Борисова Т.Н.

Дата рождения 12.12.1212

№Зачетки 08/222

Контактный телефон 8-093-672-65-23

Домашний адрес г.Донецк, ул. Пролетарская

Пол женский

Форма обучения очная

ФИО матери Пупкина О.Е.

ФИО отца Пупкин Б.А.

Контактная информация отца ОАО ДМЗ, автослесарь, 8-093-456-78-32

Контактная информация матери ОАО ДМЗ, бухгалтер, 8-067-678-09-87

Группа ИС07А

ФИО Вольмар П.Р.

Дата рождения 11.09.1990

№Зачетки 07/467

Контактный телефон 8-063-676-87-79

Домашний адрес г. Торез, ул. Берегового

Пол мужской

Форма обучения очная

ФИО матери Вольмар Е.Е.

ФИО отца Вольмар Р.Г.

Контактная информация отца НК "Garage", ди-джей,8-098-678-89-90

Контактная информация матери с/к "Красотка", парикмахер,8-050-012-45-

Группа ПО07А

23 января 2009 г.Страница 1 из 8

Рис. 4.4.1 - Отчет в режиме вид

Отчет «Заявление на поселение в общежитие»

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

Вид отчета в режиме вид представлен на рисунке 4.4.2.

Заявление на поселение в общежитие

Прошу поселить меня, ________________________________,

(Ф.И.О.)

проживающего(ую) в___________________________,

(домашний адрес)

в общежитие. С правилами проживания и размером оплаты ознакомлен. Обязуюсь их нарушать правила и своевременно вносить оплату.

____________ ____________

Дата подпись

Рис. 4.4.2 - Отчет в режиме вид

Отчет «Архив»

Отчет создан с помощью мастера.

Выводится вся информация о студентах, которым более 25 лет.

Вид отчета в режиме вид представлен на рисунке 4.4.3.

Рис. 4.4.3 - Отчет в режиме вид

4.5 Описание макросов

1) Макрос: «Печать отчета»

Название: Печать

Назначение: Печать отчета

Макрокоманда: Печать.

Функционирование макроса: при запуске макроса осуществляется печать отчёта.

2) Макрос: «Архивирование»

Назначение: Архивация устаревших данных.

Имя макроса: Заполнение архива.

Функционирование макроса: Запускается макрос «Архив» в результате чего происходит добавление в архив устаревших данных. Макрос основан на запросах «Заполнение архива» (добавление устаревших данных в Архив)

3) Макрос: «Архивирование»

Назначение: Архивация устаревших данных.

Имя макроса: Очистка архива.

Функционирование макроса: Запускается макрос «Архивирование» в результате чего происходит удаление информации из текущих таблиц. Макрос основан на запросах «Очистка архива» (удаление устаревших данных из текущих таблиц).

5) Макрос: «Autoexec»

При запуске Access автоматически запускается Главная форма.

5 Уровни доступа к СУБД

Описание групп пользователей

В разработанной СУБД выполнены три уровня доступа: гость, пользователь и администратор.

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

Пользователь может зайти в базу лишь под паролем «1». Данный доступ отличается от предыдущего доступа тем, что пользователю позволяется вносить и корректировать изменения в базе, но «Архив» студентов остается закрытым.

Администратор может зайти в базу под паролем «2». Имеет полный доступ ко всей базе. Права администратора неограниченны. Он может редактировать структуры таблиц, изменять и удалять любые данные. Далее - более подробно о правах пользователей.

Гость

Как сказано ранее, этот пользователь заходит в базу без пароля и не имеет в ней никаких прав на изменение данных - лишь их просмотр и печать на принтере. На всех формах кнопки «Добавить запись», «Сохранить запись» и «Удалить запись» недоступны. Кнопки «Архив» в форме «Вход» так же недоступны. Область действий - просмотр данных из базы и распечатка их на принтере.

Пользователь

Для входа в базу под правами пользователя необходимо знать пароль. Права Пользователя отличаются от прав предыдущего пользователя лишь тем, что он имеет доступ к кнопке «Общежития.

Администратор

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

Выводы

За время создания курсового проекта и написания пояснительной записки была досконально изучена предметная область проекта; разработана концептуальная модель БД: объект-отношение; выбрана реляционная модель для создания эффективной БД

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

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

Разрабатываемая база позволяет получить всю необходимую информацию о студентах ВУЗа.

Приложение А

Техническое задание

А 1 Общие сведения

Полное наименование курсового проекта (КП) “База данных «Автоматизация учета студентов»”. Условное обозначение БД.

КП проектируется студенткой третьего курса Государственного университета информатики и искусственного интеллекта, факультета Автоматизированных систем управления (АСУ), группы САУ-06 Гололобовой Анастасией Сергеевной.

Задание выдано кафедрой программного обеспечения интеллектуальных систем (ПОИС) по дисциплине " Организация баз данных и знаний".

А.2 Этапы разработки и сроки выполнения

Сроки выполнения приведены в таблице А.1.

Таблица А.1 График выполнения курсового проекта

А 3 Назначение и цели создания проекта

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

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

А 3.1 Сведения об объекте автоматизации

Объектом автоматизации данного курсового проекта является процесс анализа, обработки, поиска, удаления и учета информации о студентах в ВУЗе.

А 3.2 Сведения об условиях эксплуатации КП

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

А 4 Требования к проекту

А 4.1 Требования к КП в целом

КП в целом должен:

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

- обеспечить не избыточность, компактность, целостность хранимых данных.

А 4.2 Требования к задачам и функциям КП

Проектируемый программный продукт должен реализовывать следующие задачи:

- иметь систему помощи, т.е. выдавать корректные сообщения при ошибках, возникающих в процессе работы;

- позволять получать информацию по определённым запросам пользователя. (запросы на выборку, на добавление и удаление записей в архиве, запросы для создания пользовательских форм и отчетов). А так же:

хранить информацию о студентах;

хранить информацию о группе;

хранить информацию о специальности;

хранить информацию о факультете;

хранить информацию об общежитии;

хранить информацию о комнате;

корректный выбор информации по какой-либо характеристике;

поиск по ключевым словам.

А 4.3 Требования к видам обеспечения

А 4.3.1 Требования к программному обеспечению

К программному обеспечению (ПО) предъявляются следующие требования:

- монитор типа SVGA;

- операционная система- Microsoft Windows 98 и выше;

- установленная прикладная программа Access 2003 из программного пакета Microsoft Office.

А 4.3.2 Требования к техническому обеспечению

Техническое обеспечение должно удовлетворять следующим требованиям:

- тип компьютера- INTEL 5x 86;

- объем памяти RAM 16Мб;

А 4.3.3 Требования к организационному обеспечению

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

- наличие технического задания;

- пояснительной записки, включающей приложения.

Приложение Б

ЗАПОЛНЕННЫЕ ТАБЛИЦЫ

Приложение В

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЮ

В.1 Инсталляция

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

В.2 Начало работы с программой

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

Михеева В., Харитонова И. Наиболее полное руководство Microsoft Access 2000 - СПб.: БВХ - Санкт-Петербург, 2000. - 1088с.:ил.