Содержание

Введение

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

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

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

В процессе разработки БД «Сессия» необходимо преодолеть следующие задачи:

1. 
   Осуществить анализ предметной области (ПО), запросов пользователей и документов, отражающих события и процессы, протекающие в сессионное время. Результатом этого анализа являются списки объектов предметной области, перечни их свойств или атрибутов, определение связей между объектами и описание структуры ПО сдачи сессии в виде диаграммы. Для каждого из атрибутов указываются ограничения на их возможные значения, определяемые структурой ПО.
   
2. 
   Разработать концептуальную модель базы данных, которая описывает объекты и связи ПО на формальном уровне. Ее разработка ведется на втором этапе и основывается на инфологической модели (выделение сущностей, атрибутов сущностей, ключей и связей), полученной на первом этапе. В процессе разработки осуществляется выбор типа модели данных, и определяются ее элементы. Каждая СУБД поддерживает только одну из моделей. Выбор модели данных и выбор СУБД тесно взаимосвязаны.
   
3. 
   Преобразовать в физическую модель данных, которая определяет способ размещения данных непосредственно на машинном носителе, учи­тывает распределение данных, методы доступа и способы индек­сирования. В современных прикладных программных средствах этот уровень организации обеспечивается автоматически без вме­шательства пользователя. Пользователь, как правило, оперирует в прикладных программах и универсальных программных средст­вах представлениями СУБД на организацию данных. Таким образом, основная задача проектирования заключается в создании инфологической модели ПО и концептуальной БД.
   
4. 
   Реализовать БД [2].
   

Для решения поставленных выше задач нужно разработать БД, которая позволила бы:

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

1. 
   поиск заданного студента по фамилии или номеру зачетной книжки;
   
2. 
   выборка всех данных об успеваемости заданного студента за текущий учебный год и за все время обучения;
   
3. 
   выборка всех неуспевающих студентов;
   
4. 
   средний балл по каждому предмету;
   
5. 
   расчет количества студентов по группам;
   
6. 
   средняя оценка по предметам и группам.
   

3. 
   автоматизировать обработку информации при следующих бизнес- операциях:
   

1. 
   прием нового студента;
   
2. 
   коррекция данных о студенте и его успеваемости;
   
3. 
   формирование личной ведомости успеваемости;
   
4. 
   выводить следующие документы на печать:
   
5. 
   ведомость средней успеваемости факультета;
   
6. 
   список студентов по группам;
   
7. 
   ведомость успеваемости студентов по группам и предметам.
   

При проектировании и эксплуатации БД «Сессия» она должна отвечать следующим требованиям:

1. 
   адекватность отображения предметной области университета, в частности эффективности учебного процесса (полнота, целостность, непро­тиворечивость, актуальность данных);
   
2. 
   возможность использования базы данных разными катего­риями пользователей; обеспечение высокой эффективности доступа;
   
3. 
   дружественность интерфейса;
   
4. 
   обеспечение секретности и конфиденциальности;
   
5. 
   обеспечение взаимной независимости программ и данных;
   
6. 
   обеспечение надежности БД; защита данных от случайного и преднамеренного разрушения; возможность быстрого и пол­ного восстановления данных в случае сбоев в системе.
   

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

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

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

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

В жизненном цикле БД одним из наиболее важных этапов яв­ляется этап проектирования, от результатов которого зависит эф­фективность дальнейшего использования БД «Сессия» в решении задач предметной области. Главная задача, которая решается в процессе проектирования, это организация данных: интегрирование, структурирование и определение взаимосвязей. Способ организа­ции данных определяется логической моделью, которая отражает основные сущности ПО и их взаимосвязи. Различные формы пред­ставления связей между объектами породили существование раз­личных логических моделей данных, например: иерархическую, сетевую, реляционную. Наибольшую популярность к середине 1980-х годов приобрела реляционная модель в силу ее простоты и математической обоснованности. Как следствие большинство современных СУБД поддерживают эту модель [2].

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

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

Данная информационная система «Сессия» использует лишь необходимые информационные элементы, что делает ее не слишком большая по объему, поэтому использование реляционной модели представления данных наиболее целесообразное.

1 Анализ предметной области

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

Предметная область - это часть реального мира, данные о которой мы хотим отразить в базе данных [4]. Например, в качестве предметной области можно выбрать бухгалтерию какого-либо предприятия, отдел кадров, банк, магазин и т.д. Предметная область бесконечна и содержит как существенно важные понятия и данные, так и малозначащие или вообще не значащие данные. Так, если в качестве предметной области выбрать учет товаров на складе, то понятия "накладная" и "счет-фактура" являются важными понятиями, а то, что сотрудница, принимающая накладные, имеет двоих детей - это для учета товаров неважно. Однако, с точки зрения отдела кадров данные о наличии детей являются необходимыми. Таким образом, важность данных зависит от выбора предметной области.

Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений [5].

1.1 Положение о промежуточной аттестации студентов

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

Учебный год делится на два семестра, каждый из которых заканчивается экзаменационной сессией.

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

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

Промежуточная аттестация осуществляется в форме: экзамена, зачета, контрольной работы, коллоквиума, тестирования.

1.1.1 Общие положения

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

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

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

Экзамены и зачеты проводятся в строгом соответствии с утвержденными рабочими программами дисциплин и программами практик.

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

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

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

Ведущим преподавателям дисциплин предоставлено право освобождать студентов от зачетов до сессии и от экзаменов в период сессии по результатам рубежного контроля и научной работы, если предварительная оценка знаний по дисциплине "отлично" [1].

1.1.2 Допуск к экзаменационной сессии

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

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

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

Студенты допускаются к экзамену по дисциплине при условии выполнения ими всех работ, предусмотренных учебной программой данной дисциплины. При невыполнении всего объема работ преподаватель вправе не допустить студента до экзамена, о чем в ведомости делается запись "не допущен" и ставится подпись преподавателя [1].

1.1.3 Проведение экзаменов и зачетов

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

Расписание экзаменов доводится до сведения преподавателей и студентов не позднее, чем за две недели до начала сессии. Расписание составляется с таким расчетом, чтобы перерыв между экзаменами по каждой дисциплине был не менее 3 дней. Экзамены в период сессии могут проводиться в воскресные дни, профессорско-преподавательский состав привлекается в выходные дни в соответствии с трудовым кодексом РФ. Расписание экзаменов утверждается проректором по учебной работе.

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

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

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

Зачеты по курсовым проектам (работам) проводятся в порядке защиты на заседаниях комиссии, созданной кафедрой, с участием руководителя проекта (работы).

Студенты, сдававшие, но не сдавшие в сессию экзамены по трем и более дисциплинам отчисляются из университета.

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

1.1.4 Оценка знаний, умений, навыков

Знания, умения, навыки студентов оцениваются оценками: "отлично", "хорошо", "удовлетворительно", "неудовлетворительно", "зачтено", "незачтено". Эти оценки проставляются в аттестационную ведомость. Оценки "неудовлетворительно" и "незачтено" в зачетную книжку студентов не проставляются.

При выставлении оценки могут быть применены рекомендательные критерии:

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

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

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

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

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

Результаты сдачи зачетов оцениваются отметкой "зачтено". Зачеты с дифференцированными оценками "отлично", "хорошо", "удовлетворительно", "неудовлетворительно" проставляются по курсовым проектам (работам), практикам, по специальным дисциплинам и по другим дисциплинам, установленным методическими комиссиями по специальностям и указанным в учебных планах [1].

1.1.5 Документация экзаменационной сессии

Ведение документации экзаменационной сессии возлагается на деканаты. Основными документами о результатах сдачи экзаменов и зачетов являются:

1. 
   аттестационная ведомость;
   
2. 
   аттестационный лист;
   
3. 
   зачетная книжка студента;
   
4. 
   учебная карточка студента.
   

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

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

Аттестационные ведомости для проставления результатов зачетов преподаватели получают в деканате за неделю до начала сессии.

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

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

Заполненные аттестационные ведомости экзаменатор сдает в деканат лично в день экзамена или, с разрешения декана, не позднее 12 часов следующего после проведения экзамена дня.

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

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

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

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

Ввод данных по итогам сессии в подсистему "Деканат" осуществляется в течение экзаменационной сессии и заканчивается в течение трех дней после проведения последнего экзамена.

1.1.6 Подведение итогов сессии

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

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

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

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

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


Рисунок 1 – Диаграмма потоков данных системы учета успеваемости студентов

2 Инфологическое проектирование

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

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

Процесс построения инфологической модели состоит из следующих шагов:

– определение сущностей;

– определение зависимостей между сущностями;

– задание первичных и альтернативных ключей;

– определение атрибутов сущностей;

– приведение модели к требуемому уровню нормальной формы.

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

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

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

Атрибут – поименованная характеристика сущности [5].

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

Атрибуты сущности студенты:

• 
  номер зачетной книжки;
  
• 
  ФИО студента;
  
• 
  год рождения
  
• 
  адрес;
  
• 
  факультет;
  
• 
  специальность;
  
• 
  курс;
  
• 
  староста.
  

Эта сущность отводится для хранения основных сведений о студентах.

Сведения могут быть как неизменяемые за весь период ведения автоматизированной информационной системы (АИС) (ФИО студента, год рождения, номер зачетной книжки) так и изменяемые (адрес, факультет, специальность и курс). Может возникнуть ситуация совпадения ФИО студентов, поэтому существует необходимость включения атрибута «номер зачетной книжки», который и станет ключом (ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности) в сущности «студенты». Нет необходимости знать этот код для работы с базой данных. Так как он служит только для внутренних целей, то его можно скрыть от пользователей.

Атрибуты сущности ведомость:

• 
  номер зачетной книжки;
  
• 
  семестр;
  
• 
  дисциплина;
  
• 
  форма отчетности;
  
• 
  оценка.
  

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

Для того чтобы связать все вышеперечисленные элементы ER-диаграммы используют связь.

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

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

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

Нормализация выполняется поэтапно. Первые три шага были описаны доктором Э.Ф. Коддом в статье "Дальнейшая нормализация реляционной модели базы данных" в 1972г [5].

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

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

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

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

Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

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

Если в отношении имеется много функциональных зависимостей, 4НФ не устраняет избыточность, то применяют пятую нормальную форму (ЗНФ).

Разложение отношений из 4НФ в пятую нормальную форму должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.

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

3 Выбор СУБД

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

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

СУБД имеет следующие компоненты:

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

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

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

Группа реляционных СУБД представлена на рынке программных продуктов очень широко. Это, например, такие системы, как Paradox, R:base, Clarion, Oracl, MS Access, MS Visual FoxPRO.

Одним из наиболее распространенных программных продуктов является Oracle.

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

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

Встраивание в СУБД Oracle JavaVM, полномасштабная поддержка серверных технологий (Java Server Pages, Java-сервлеты, модули Enterprise JavaBeans, интерфейсы прикладного программирования CORBA), привело к тому, что Oracle на сегодняшний день является стандартом СУБД для Internet.

Еще одной составляющей успеха СУБД Oracle является то, что она поставляется практически для всех существующих на сегодня операционных систем. Работая под Sun Solaris, Linux, Windows или на другой операционной системе с продуктами Oracle не будет возникать никаких проблем в работе. СУБД Oracle одинаково хорошо работает на любой платформе. Таким образом, компаниям, начинающим работу с продуктами Oracle не приходится менять уже сложившееся сетевое окружение. Существует лишь небольшое количество отличий при работе с СУБД, обусловленных особенностями той или иной операционной системы. В целом же это всегда та же самая безопасная, надежная и удобная СУБД Oracle.

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

Не менее известной является СУБД Access.

СУБД Access входит в пакет Microsoft Office, что во многом определяет ее популярность. Сегодня используется третья версия пакета. По сравнению с более ранними версиями изменений произведено очень мало, они практически ограничились введением типа полей OLE и гиперссылками, внедренными в 1996 году во 2 версию. Все остальные изменения Access связаны с изменением базовой ОС Windows, библиотеки которой Access использует, не имея собственных, что делает его СУБД с самым низким быстродействием.

Разработка приложения в Access начинается с создания таблиц в режиме конструктора таблиц или путем импорта из электронных таблиц или файлов баз данных. Мастера таблиц создают таблицы по американским стандартам и потому мало применимы. Очень легко создаются поля с возможностью выбора одного данного из предлагаемого списка, т.е. поля подстановки. Для внедрения графики существуют две возможности – поля OLE, хранящие графику непосредственно в базе данных, что увеличивает объем приложения и понижает его быстродействие, и введение гиперссылок на внешние файлы, что затрудняет переносимость приложения, но не влияет на быстродействие.

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

Экранные формы и отчеты создаются в основном по мастерам, а затем доводятся вручную в режиме конструктора. Формы, также, как и Visual Fox Pro, состоят из отдельных элементов интерфейса (кнопок, переключателей, надписей и т.д.), каждый из которых необходимо описать при создании приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для отображения и редактирования данных используются формы, отчеты, запросы и программы. Чтобы создавать формы, отчеты и запросы, применяются конструкторы. Поэтому эти компоненты часто называют конструкторскими объектами. Формы и отчеты являются составными объектами, так как они состоят из более мелких объектов (таких, как поля, кнопки, диаграммы, рамки, OLE-компоненты и т. п.), которые называются объектами интерфейса.

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

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

Запросы являются средством выборки данных из одной или нескольких таблиц. В Visual FoxPro для создания запроса можно использовать как конструктор запросов, так и язык Structured Query Language (SQL). Результаты выполнения запроса могут отображаться в форме, выводиться в виде отчетов и диаграмм или сохраняться в таблице.

Программы, написанные на языке Visual FoxPro, являются объектно-ориентированными. С помощью них обрабатываются события в форме, создаются объекты, осуществляются различные вычисления и управление базой данных. Для удобства работы можно объединить программы в библиотеки.

Чтобы создавать формы в Visual FoxPro, можно использовать не только базовые классы, но и создавать собственные, например, определить класс форм, в котором задан определенный цвет фона и стандартный набор кнопок для управления данными. Чтобы стандартизировать разработку, полезно иметь один или несколько пользовательских классов для каждого базового класса. Классы, созданные в Visual FoxPro, хранятся в библиотеках классов.

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

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

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

По сравнению с предыдущими версиями расширен список объектов, которые можно хранить в полях типа General, внедрен принцип «перетащи и брось» для объектов приложения, добавлены мастера выходных документов.

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

• 
  Обеспечение приложениям доступа к таким средствам независимых разработчиков, как программы чтения с экрана, устройства распознавания голоса и автоматические средства тестирования.
  
• 
  Обеспечение простого доступа к данным Visual FoxPro для клиентов, не основанных на Visual FoxPro.
  
• 
  Построение взаимодействующих приложений и компонентов благодаря возможностям представления данных Visual FoxPro в формате XML и импорта данных в формате XML в таблицы Visual FoxPro.
  
• 
  Контроль действий пользователя с помощью кода, исполняемого при открытии, закрытии или изменении базы данных.
  
• 
  Создание веб-служб на основе протокола SOAP и подписка на них.
  
• 
  Сокращение времени написания кода благодаря эффективной расширенной языковой поддержке при вводе с клавиатуры.
  
• 
  Просмотр процедур, функций и методов в исходном коде, а также быстрый переход к ним.
  
• 
  Закрепление окон для таких широко распространенных средств, как Command (Команда), Data Session (Сеанс данных) и Debug (Отладка).
  
• 
  Создание программ установки собственных приложений с применением специально разработанной для Visual FoxPro версии хорошо известной программы InstallShield® Express.
  
• 
  Сокращение времени написания исходного кода благодаря поддержке закладок и ярлыков, средств поиска и преобразования регистра букв.
  
• 
  Снижение времени разработки благодаря созданию библиотек классов для повторно используемого кода, форм и управляющих элементов.
  
• 
  Построение компонентов для высокомасштабируемых n-уровневых приложений с распределенными транзакциями с помощью служб COM+ операционной системы Windows 2000.
  
• 
  Построение быстродействующих веб-приложений, управляемых базой данных, с помощью Visual FoxPro и служб IIS (Internet Information Services – информационные службы Интернета) в Windows NT 4.0 или Microsoft Windows 2000.
  
• 
  Построение настольных и совместно используемых приложений, совместимых с SQL Server 2000, и осуществление непосредственной миграции кода к SQL Server 2000 без изменения кода [8].
  

Из вышеприведенного сравнения различных СУБД Visual FoxPro по своим возможностям и эксплуатационным характеристикам превосходит другие среды разработки систем управления реляционными базами данных. Поэтому именно она будет использоваться для реализации базы данных «Тепличное хозяйство».

Наглядное представление вышесказанного представлено в таблице 3.1.
Таблица 3.1-Критерии выбора СУБД

СУБД Характеристика	Visual FoxPro	Access	Oracle
Интеграция с другими прикладными программами	1	3	2

Продолжение таблицы 3.1

СУБД	Visual FoxPro	Access	Oracle
ХАРАКТЕРИСТИКА
3 Интеграция объектно-ориентированного языка программирования Xbase и SQL	1	3	2
4 Требования к аппаратным ресурсам ЭВМ	2	1	3
5 Уровень объектной модели	1	2	3
6 Быстродействие системы	1	3	2
7 Простота использования	2	1	3
8 Исправление ошибок кода программы	1	2	3
9 Динамическое изменение созданного приложения	1	2	3
10Защита информации	2	3	1
11 Поддержание целостности данных	1	3	2
12 Отсутствие избыточности данных	1	2	3
13 Гибкое управление доступа к данным	1	2	3
14 Пользовательский масштаб созданного приложения	2	3	1
15 Многоплатформенность	1	2	3
16 Создание приложений масштаба предприятия	1	3	2

4 Даталогическое проектирование

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

Рисунок 2 - ER-диаграмма

Данные в таблицах Microsoft Visual FoxPro сохраняются в определенном формате, который называется типом данных. Типы данных могут быть классифицированы по четырем категориям: числовые (numeric), символьные (character), даты (date) и BLOB.

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

Ниже рассмотрены все возможные типы в FoxPro.

Charaсter – символьный тип. Позволяет хранить любой текст. Отводится 1 байт на символ, то есть хранится только код каждого символа без обозначения, каким шрифтом его отображать, какого размера и цвета. Максимальная длина поля – 254 символа.

Float – вещественный тип данных для хранения дробных чисел отводится 8 байт.

Numeric – целый тип данных для хранения действительных чисел. Отводит 8 байт.

Integer – целый тип данных для хранения действительных чисел. Отводит 4 байта.

Double – вещественный тип данных для хранения дробных чисел. Двойная точность. Позволяет хранить значения с большим количеством знаков после запятой. Отводится 8 байт.

Date – тип данных для хранения календарных дат, но без текущего времени.

DateTime – тип данных для хранения календарных дат и текущего времени.

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

Logical – Логический тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

Memo – специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда. Содержит ссылку на текстовое поле, хранящееся в отдельном файле с расширением fpt.

General – содержит ссылку на OLE-объект. Отводит 4 байта.

Varchar-символьный тип, Позволяет хранить любой текст, но не допускаются пробелы. Отводится 1 байт на символ. Максимальная длина поля-254.

Varbinary-двоичный тип. Позволяет хранить значения в десятичном виде

Ниже в таблицах формально описаны объекты предметной области тепличного хозяйства и их свойства. Здесь объект базы данных представляется в виде таблицы с набором полей определенного типа и свойств.
Таблица 4.1- Студенты

Имя поля	Тип	Ширина	Ключ
Номер зачетной книжки	Numeric	5	Primary
ФИО студента	Character	40	Regular
Год рождения	Numeric	4
Адрес	Character	45
Факультет	Character	25
Специальность	Character	20
Курс	Numeric	1
Староста	Character	10

Таблица 4.2- Ведомость

Имя поля	Тип	Ширина	Ключ
Номер зачетной книжки	Numeric	5	Primary
Семестр	Numeric	2
Дисциплина	Character	20
Форма отчетности	Character	10
Оценка	Character	10

5 Физическое проектирование

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

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

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

Рисунок 5.1- Целостная связь данных
В VFP существует два формата отображения содержимого таблицы: в виде таблицы и в виде формы.

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

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

1. 
   настройка параметров формы;
   
2. 
   определение среды окружения, т.е. выбор используемых в форме таблиц и установка связей между ними;
   
3. 
   размещение в форме объектов;
   
4. 
   настройка свойств размещенных объектов.
   

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

1. 
   нажать кнопку Command Button (Кнопка) на панели инструментов Form Controls (Элементы управления формы) и щелкнуть мышью в месте предполагаемого размещения создаваемой кнопки;
   
2. 
   открыть окно свойств созданного объекта;
   
3. 
   кнопка может содержать текст или графическое изображение. При создании кнопки, содержащей текст, скорректировать свойство Caption (Надпись), разместив в поле ввода значения текст, который будет отображаться на кнопке;
   
4. 
   при создании кнопки, содержащей графическое изображение, для задания изображения, размещаемого на кнопке, воспользоваться свойством picture. Нажать кнопку, расположенную справа от поля ввода значения свойства. В результате откроется диалоговое окно Open (Открыть), используя которое, можно выбрать файл на диске, содержащий изображение. После выбора файла нажать кнопку ОК для перенесения изображения на кнопку;
   
5. 
   кнопка размещена в форме. Теперь необходимо, используя автоматически вызываемый при нажатии кнопки метод объекта click (Нажатие), определить действия, выполняемые при нажатии этой кнопки;
   
6. 
   установить курсор на метод click (Нажатие) и щелкнуть мышью. На экране откроется окно процедур;
   
7. 
   ввести команды, которые должны выполняться при нажатии данной кнопки.
   

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

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

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

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

Подробно о каждом пункте меню.

Вкладка «Информация о студентах» (рисунок 5.3) содержит подпункты «Успеваемость студентов», «Перечень студентов» и «Старосты групп», которые вызывают формы для просмотра и редактирования информации о каждой из предложенных тем. Примеры форм представлены на рисунках 1, 2 и 3, соответственно, в приложении А.



Рисунок 5.3- Строка меню
При нажатии вкладки «Документация» идет вызов таблиц, отражающих следующие темы запросов: «Зачетная книжка студента» (рисунок 5.4) содержит информацию об успеваемости студента за все годы его обучения); «Неуспевающие студенты» (рисунок 5.5) (содержит перечень студентов, которые не допущены до сессии, либо сдавшие экзамен с отметкой «неудовл.») ; «Количество оценок по дисциплине» (содержит количество «5», «4», «3» по заданной дисциплине.

Используя пункт меню «Отчеты на печать», вызывается форма, с помощью которой, можно вывести на печать любой из представленных в ней отчетов. Для этого нужно нажать кнопку напротив названия необходимого отчета (рисунок 5.6). Примеры отчетов представлены в Приложении А.

Рисунок 5.4 – Пункт «Зачетная книжка студента»

Рисунок 5.5 – Пункт «Неуспевающие студенты»



Рисунок 5.6 – Пункт меню «Отчеты на печать»

Заключение

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

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

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

В процессе устранения избыточности данных в БД «Сессия» была достигнута 3НФ, о чем свидетельствует тот факт, что все не ключевые столбцы созданных таблиц зависят от первичного ключа таблиц, но остаются независимы друг от друга.

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

На этапе даталогического проектирования все объекты предметной области и их свойства были формально представлены в виде таблицы с набором полей определенного типа и свойств.

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

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

1. 
   Устав ОГУ. – О. : OSU.RU, 1999-2010. – Режим доступа: http://www.osu.ru/doc/467. – 08.12.2010.
   
2. 
   Проектирование баз данных СУБД Microsoft Access [Текст] : учеб. пособие для вузов / Н. Н. Гринченко [и др.] . - Москва : Горячая линия-Телеком, 2004. - 240 с. : ил. - Библиогр.: с. 236.. - ISBN 5-93517-193-7.
   
3. 
   Проектирование реляционных баз данных [Текст] : учеб. пособие для вузов / Ю. В. Полищук, С. И. Сормов, Т. А. Черных . - Оренбург : ГОУ ОГУ, 2008. - 133 с. - Библиогр.: с. 132. - ISBN 978-5-7410-0816-4.
   
4. 
   Системы управления базами данных и знаний: Справ.изд. / под ред. А. Н.Наумова . - М. : Финансы и статистика, 1991. - 352С : ил.
   
5. 
   Основы использования и проектирования баз данных [Текст] : учеб. пособие для вузов / В. М. Илюшечкин . - М. : Высшее образование, 2009. - 214 с. : ил.. - (Основы наук). - Глоссарий : с. 208-211. - ISBN 978-5-9692-0253-5.
   
6. 
   Использование Oracle 8 тм/8 i тм [Текст] : пер. с англ. / В. Пейдж [и др.] .- Спец. изд.. - М. : Вильямс, 1999. - 1024 с. : ил. - Предм. указ.: с. 1019-1022.
   
7. 
   Программирование в среде СУБД FoxPro 2.0 [Текст] : построение систем обработки данных / А.А. Попов. - М. : МарТ, 1996. - 352 с. : ил.
   

Приложение А

(справочное)

Рисунок 1- Успеваемость студентов


Рисунок 2 – Перечень студентов




Рисунок 3 – Старосты групп


Рисунок 4 – Запрос «Ведомость успеваемости факультета»

Рисунок 5 – Запрос «Ведомость успеваемости группы и семестра»