Министерство  образования и науки Украины

Харьковский национальный университет радиоэлектроники 
 
 
 
 
 

Кафедра информатики 
 
 

Пояснительная записка

к КУРСОВОЙ РАБОТЕ

по курсу  « Базы данных и информационные системы  »

на тему « Информационная система Деканата » 
 
 
 
 
 

   Выполнила:                                                       Проверила:

   ст. гр. Инф-03-3                                                доц. Алисейко Е.В.

   Фёдорова  Т.Н. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Харьков

2005

ПОСТАНОВКА  ЗАДАЧИ

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

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

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

РЕФЕРАТ

    Пояснительная записка к курсовой работе: 45 стр., 19 рис., 1 таблица,

3 раздела, 3 приложения, 8 источников.

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

    Практическая  реализация выполнена с использованием СУБД MS ACCESS. Приведены программы построения отношений и запросов в среде реляционных моделей с использованием языка SQL2.

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

    Ключевые  слова и выражения: метод, предметная область, объект, модель данных, реляционная модель данных, база данных, информационная система, СУБД ACCESS, SQL2, отношение, функциональная зависимость, первичный ключ, потенциальный ключ, внешний ключ, нормализация, нормальная форма Бойса-Кодда, запрос, таблица, форма, отчет. 
 
 
 

СОДЕРЖАНИЕ

 
 
 
 
 
 
 
 
 
 
 
 

ВВЕДЕНИЕ

    История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных – Conference of Data System Languages ( CODASYL ), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.

    В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э.Ф.Коддом, который  является создателем реляционной модели данных.

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

    Первый  этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ типа PDP11, разных моделях HP. Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках и запускались как обычные числовые программы. Мощные операционные системы обеспечивали возможность условно параллельного выполнения всего множества задач. Эти системы можно было отнести к системам распределенного доступа, потому что база данных была централизованной, хранилась на устройствах внешней памяти одной центральной ЭВМ, а доступ к ней поддерживался от многих пользователей-задач.

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

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

    Четвертый этап характеризуется появлением новой  технологии доступа к данным – интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Интернета, например Microsoft Internet Explorer или Netscape Navigator. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языке Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятия. Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной архитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиентского программного обеспечения. Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения.

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

1 АНАЛИЗ ПРЕДМЕТНОЙ  ОБЛАСТИ

    1.1 Построение инфологической модели  предметной области методом.

    Первым  шагом проектирования является общая  постановка задачи, анализ предметной области и построение инфологической модели предметной области. Модель данных «сущность-связь», или ER-модель (от английских entity -сущность и relationship - связь) предложена в 1976 П. Ченом и с тех пор неоднократно подвергалась пересмотру и модификации как малоэффективная модель в проектировании баз данных, однако диаграмма, строящаяся при проектировании с помощью модели данных «сущность-связь», полезна при проектировании даталогической схемы.

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

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

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

    «Концептуальное понимание» ПО так же, как «концептуальное  понимание» соответствующей РБД должны описываться некоторым формализованным образом. Средством такого описания служат инфологические модели. Термин «инфологическая модель» может быть применен как к моделированию данных, так и к моделированию собственно предметной области (ПО). Различие здесь может быть весьма существенным, хотя иногда эти два уровня моделирования «сливаются» в один. В информационно-логических моделях акцент делается на «устройстве» ПО и «логике» ее функционирования, тогда как информационные аспекты играют лишь вспомогательную роль. Инфологические модели данных (ИЛМД) предназначены для решения куда более скромных задач, сводящихся к построению эффективной в некотором смысле совокупности хранимых данных и процессов их обработки. Для «семантически окрашенного» структурирования данных в моделях данных используется два основных вида абстракций - обобщение и агрегация.