Преподаватель который помогает студентам и школьникам в учёбе.

Проектирование БД для контроля сессионной успеваемости студентов ВУЗа

Содержание:

Введение

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

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

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

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

Постоянное увеличение объемов информации и усложнения спектра применения баз данных привело к появлению систем управления базами данных (СУБД).

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

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

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

Предметом исследования проектирование БД для контроля сессионной успеваемости студентов ВУЗа

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

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

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

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

- определить понятие и функции СУБД;

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

- привести основные тенденции развития СУРБД;

- провести проектирование БД для контроля сессионной успеваемости студентов ВУЗа.

При разработке данной курсовой работы использовались публикации следующих авторов: Буракова П.В.; Петрова В.Ю.; Шандаров Е.С.; Кузнецова С.Д.; Хайдарова К.А.; Баженова И.Ю и многих других, а также информация с различных интернет источников.

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

1. РЕЛЯЦИОННАЯ БАЗА ДАННЫХ

1.1 Этапы проектирования и разработка реляционной модели данных

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

Базовом понятием реляционной модели является отношение (“relation”) то есть понятие взаимосвязи одних объектов с другими. В 1970 году своей статье Э. Ф. Кодд показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида.

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

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

К числу достоинств реляционного подхода можно отнести [3 c. 53-54]:

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

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

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

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

Для манипулирования данными в реляционной базе данных Кодд ввел и систему операций над отношениями, в разработанной им модели данных, названной реляционной алгеброй.

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

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

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

Кодд показал логическую эквивалентность реляционной алгебры и реляционного исчисления. Это означает, что любой запрос, который можно сформулировать при помощи реляционного исчисления, также можно сформулировать, пользуясь реляционной алгеброй, и наоборот [3 c. 92].

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

Жизненный цикл включает в себя следующие этапы:

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

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

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

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

К основным объектам базы данных относятся:

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

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

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

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

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

Отношения находятся в первой нормальной форме (1НФ) если во всех допустимых отношениях каждый кортеж содержит только одно значение для каждого из атрибутов.

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

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

Отношения находятся в третьей нормальной форме (3НФ) если они находятся во второй нормальной форме и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых атрибутов.

Дополнительная третья нормальная форма (нормальная форма Бойса — Кодда) это такое состояние отношение, когда все нетривиальные и неприводимые зависимости слева в качестве детерминанта потенциальный ключ.

Отношения находятся в четвертой нормальной форме (4НФ), если оно находится в третьей нормальной форме и в нём отсутствуют нетривиальные многозначные зависимости.

Отношения находятся в пятой нормальной форме (5НФ), если каждое нетривиально зависимое соединение в них определяется потенциальными ключами этих отношений.

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

1.2 Язык управления реляционными базами данных

Появление языка SQL связанно с необходимостью проверки, разработанной доктором Е.Ф. Коддом реляционной модели базы данных. Для этого компания IBM организовала исследовательский проект - System/R. Целями данного проекта были: разработка реляционной СУБД, а также разработка простого языка для получения и управления данными, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования [5, с.4].

В рамках данного проекта разрабатывались и опробовались разные языки запросов, один из которых получил название SEQUEL (Structured English Query Language — «структурированный английский язык запросов»). Позже язык SEQUEL по юридическим соображениям был переименован в SQL.

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

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

Работа над официальным стандартом языка SQL началась в 1982 году [14] в рамках комитета ANSI. В 1986 году был утвержден первый вариант стандарта ANSI, а в 1987 году этот стандарт был утвержден и ISO.

В 1989 году стандарт претерпел незначительные изменения, но именно этот вариант получил название SQL-1 или SQL-89. За время разработки стандарта (1982–1989 гг.) были созданы, представлены на рынке и активно использовались несколько различных СУБД, в которых в том или ином виде был реализован некоторый диалект языка SQL. [5, 14].

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

Работа над стандартизацией продолжалась и далее. Появился стандарт SQL-1999 или SQL3. Вторая часть носит название SQL/Foundation и является основой стандарта. Вводится система типов языка, формулируются правила определения функциональных зависимостей и возможных ключей, определяются синтаксис и семантика основных операторов SQL. Третью часть занимает уточненная по сравнению с SQL-92 спецификация SQL/CLI. В четвертой части специфицируется SQL/PSM - синтаксис и семантика языка определения хранимых процедур (стандарт синтаксиса триггеров и процедур). Наконец, в пятой части - SQL/Bindings - определяются правила связывания SQL для стандартных версий языков программирования FORTRAN, COBOL, PL/1, Pascal, Ada, C и MUMPS.

2003 год ознаменовался появлением стандарта SQL-2003, в котором были введены расширения для работы с XML-данными, оконные функции (применяемые для работы с OLAP-базами данных), генераторы последовательностей и основанные на них типы данных.

Стандарт SQL-2006 вышедшей в 2006 году увеличивал функциональность работы с XML-данными. Появилась возможность совместно использовать в запросах SQL и XQuery.

SQL-2008 Улучшены возможности оконных функций, устранены некоторые неоднозначности стандарта SQL-2003

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

Каждый язык программирования состоит из двух основных частей:

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

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

Наиболее общим в синтаксисах языков программирования является выделение среди всех лексем (минимальных единиц языка, имеющих самостоятельный смысл) служебных (зарезервированных) слов и правила записи операторов - "предложений" из лексем [27].

Язык, в терминах которого дается описание языка SQL, называется метаязыком. Синтаксические определения обычно задают с помощью специальной металингвистической символики, называемой Бэкуса-Науэра формулами (БНФ) [28].

Зарезервированные слова являются постоянной частью языка SQL и имеют фиксированное значение. Слова в операторе размещаются также в соответствии с установленными синтаксическими правилами.

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

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

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

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

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

В настоящее время СУБД используются следующие основные диалекты языка SQL:

PL/SQL используется в СУБД Oracle, InterBase/Firebird;
Transact-SQL реализован в СУБД Microsoft SQL, Sybase ASE;
Informix-SQL в СУБД Informix;
Jet SQL в Microsoft Access;
PL/pgSQL в СУБД PostgreSQL.

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

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

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

2. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

2.1 Функции СУБД

Системы управления реляционными базами данных обладают следующими функциями [3]:

- управление хранилищами данных (размещением данных на физических носителях);

- кэширование данных (размещение данных в быстродействующей памяти);

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

- поддержка стандарта языка SQL;

- управление транзакциями;

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

- обеспечение защиты и контроля над доступом к данным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 Архитектура и основные виды СУБД

На заре развития реляционных СУБД комитет ANSI-SPARC предложил трехуровневую организацию архитектуры СУБД. Во многом данная архитектура схожа с архитектурой реляционной модели данных, но включает лишь три уровня:

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

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

- физический (внутренний) уровень.

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

Исходя из предложенной архитектуры и функции СУБД, выделяются следующие компоненты СУБД [13 c.27-28]:

- ядро СУБД;

- интерпретатор языка SQL, а в некоторых реализациях СУБД и компилятор языка SQL;

- модули управления внешней и внутренней памятью;

- набор различных утилит.

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

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

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

Модуль управления буферами оперативной памяти предназначен для решения задач эффективной буферизации, которая используется практически для выполнения всех остальных функций СУБД [22].

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

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

На сегодняшний момент файл-серверные СУБД являются уже устаревшими. В данных СУБД данные располагаются на выделенном файл-сервере. Доступ к данным осуществляется с локальных станций, объединенных в общую сеть. Данная архитектура содержит ряд недостатков [22]:

- при выполнении операций добавления и изменения данных СУБД осуществляет блокировку целых файлов;

- высокая нагрузка на вычислительную сеть;

- низкое обеспечение надежности и безопасности данных.

К файл-серверным СУБД относятся: MS Access, dBase, Paradox, FoxPro, Visual FoxPro.

Клиент-серверные СУБД являются развитием технологии файл-серверных СУБД с одним отличием, управлением базами данных осуществляется сервером монопольно, а клиентские приложения получаю лишь результаты своих запросов. Данная реализация очень требовательна к вычислительным ресурсам сервера, но дает несомненный выигрыш в экономии нагрузки на сеть передачи данных и ресурсам рабочих станций. К тому же увеличивается надежность и безопасность операций с базами данных. Особенно выигрышна данная архитектура в базах данных, в которых будут преобладать частые операции поиска, так как при выполнении данной операции запросы поступают на сервер, затем на сервере осуществляются все необходимые дополнительные запросы и передает клиенту уже конечный результат, который тот в свою очередь передают прикладному процессу пользователя [22]. Примером СУБД данного вида могут служить следующие системы: DB2, MS SQL Server, MySQL, PostgreSQL, Firebird, Interbase, Sybase, Oracle, ЛИНТЕР.

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

- скорость работы гораздо выше, чем у других видов СУБД;

- отсутствие выделенного сервера;

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

- низкая требовательность к ресурсам компьютера.

При этом одним из существенных недостатков данного рода СУБД является ориентированность на те или иные языки программирования.

Примеры данного вида СУБД: MS SQL Server Compact, SQLite, MySQL, ScimoreDB, TurboDB, VistaDB OpenEdge, BerkeleyDB, Firebird, Sav Zigzag.

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

3. ПРОЕКТИРОВАНИЕ ДЛЯ КОНТРОЛЯ СЕССИОННОЙ УСПЕВАЕМОСТИ СТУДЕНТОВ ВУЗА, В MICROSOFT ACCESS

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

Затем реализуем реляционную модель третей нормальной формы в схеме данных.

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

Например, для заполнения таблицы «Студент» была создана форма «Сведения о студенте».

Рисунок 1 - Форма «Сведения о студенте»

Так же данные можно вводить непосредственно в таблицу, но это не всегда удобно.

При вводе данных в таблицы в Microsoft Access нужно быть предельно внимательным, так как можно не заметив изменить какие-либо важные данные (Access не выдает при этом ни каких предупреждений). И хорошо, если это заметите сразу. Потом найти ошибку будет гораздо труднее.

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

Рисунок 2 - Пример ввода данных непосредственно в таблицу

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

Рисунок 3 - Каскадное отображение таблиц

В Access используется каскадное отображение таблиц. Например, открыв таблицу «Ведомость» и нажав на значок «+» слева, мы увидим связь с результатами сдачи студентами этой дисциплины.

Рисунок 4 - Каскадное отображение таблицы «Ведомость»

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

В таком виде удобно исправлять неверные связи. Возможность же править данные при каскадном отображении делает MS Access ещё более привлекательным для создания сложных комплексов автоматизированного учета данных.

Рисунок 5 - «Каскад» из нескольких связей

Единственным «недостатком» такого рода изображения можно считать большой объём места на экране, заминаемое «полной» схемой.

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

Рисунок 6 - Мастер запросов

Проверим их работоспособность согласно задания

Рисунок 7 - Запрос

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

Рисунок 8 - Конструктор запросов

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

Чтобы войти в режим SQL в access нужно в поле конструктора запроса нажать правой кнопкой и в появившемся окне нажать “Режим SQL”.

Рисунок 9 - Пример SQL-запроса

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

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

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

Кнопка «Список студентов» выводит для просмотра форму «Список студентов», с возможностью редактирования и добавления данных.

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

Если нажать на номер студента будет выведена форма с данными о успеваемости студента без возможности редактирования содержимого. Редактирование успеваемости производится через специальную форму «Ведомость».

Рисунок 12 - «Ведомость»

В верхнем левом углу формы находится ссылка «Новый студент», которая вызывает чистую форму «Студент» для добавления учащихся.

Рисунок 13 - Добавление нового студента

Эта же форма вызывается если нажать кнопку новый студент в Главной форме или щелкнуть на номере в конце списка студентов формы «Список студентов».

Рисунок 14 - Редактирование данных об успеваемости студентов

Так же на Главной форме присутствуют кнопки «Список предметов» и «Новый Предмет». Они действуют так же как и кнопки студента, только показывают и изменяют соответственно данные об изучаемых предметах.

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

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

Рисунок 15 - Результат вывода отчета «Ведомость»

данная база модель запрос

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

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

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

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

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

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

Можно использовать средства сетевой безопасности для разграничения доступа, для этого нужно выполнить сетевую установку MS Access.Access является системой баз общего назначени. Модель защиты разработана на основе рабочей группы. Каждая РГ определяет единую технологию работы совокупности пользователей. Информация о каждой рабочей группе хранится в соответствующем файле РГ (system.mdw), который автоматически создается при установке системы. Информация о размещении этого файла хранится в системном реестре. Созданные группы постоянны для любой базы данных одного компьютера. А разрешения для групп устанавливаются отдельно для каждой базы данных.является весьма гибкой и универсальной системой, предъявляющей достаточно умеренные требования к техническому обеспечению. Поэтому на сегодняшнем этапе эта СУБД удобна для работы практически на всех иерархических уровнях управления производством - от отрасли в целом до отдельного предприятия.

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

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

Новые записи не сохраняются. Если подобная ошибка не повторяется, это говорит не об отсутствии проблемы, а о ненадежности приложения.

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список использованной литературы

«Теоретические основы построения баз данных» [Электронный ресурс]. URL: http://www.online-academy.ru/demo/access/
Coronel C., Morris S., Rob P. Database Systems: Design, Implementation, and Management. Course Technology, 2019. 1054 p.
Базы данных. [Электронный ресурс]. URL: https://sites.google.com/site/gosyvmkss12/bazy-dannyh/08-osnovnye-komponenty-subd-i-ih-vzaimodejstvie-tipy-i-struktury-dannyh
Веретенникова Е.Г., Патрушина С.М., Савельева Н.Г. Информатика: Учебное пособие. Серия «Учебный курс», –М., 2018.
Гуде С.В., Ревин С.Б. Информационные системы. Учебное пособие. –М., 2017.
Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. – М., 2019.
Е.С. Шандаров. Системы управления базами данных: конспект лекций: Томск, 2018
Информатика: Учебник для вузов/Козырев А.А. – СПб., 2018.
Информатика: Учебник для вузов/Острейковский В.А., М: Высшая школа, 2018.
Информатика: Учебник/Каймин В.А., 2-е изд. перераб. и доп. – М: Инфра-М., 2020.
Информатика: Учебник/Под ред. Н.В.Макаровой, 3-е изд., перераб. и доп. – М.: Финансы и информатика, 2019.
Мейер Д. Теория реляционных баз данных: пер. с англ. – М., 2016.
Основы систем баз данных. М.: Финансы и статистика, 2016. ‑ 334с.
Перспективы развития СУБД. [Электронный ресурс]. URL: http://www.pd-web.net/bazy-i-banki-dannyh-v-ekonomike/53-perspektivy-razvitiya-subd/
Ревунков Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов//Под ред. В.Н.Четверикова. – М., 2017.
Родионов Д. «Exodus и Genesis. Развитие СУБД следующего поколения» [Электронный ресурс]. URL: http://danil.ws/exodusgenesis-kak-odno-iz-napravlenij-razvitiya-subd-sleduyushhego-pokoleniya/
С.Д. Кузнецов. «Объектно-реляционные СУБД» [Электронный ресурс]. URL: http://citforum.ru/database/articles/manifests/art_28_3_3.shtml
С.Д. Кузнецов. «Основы современных баз данных» [Электронный ресурс]. URL: http://citforum.ru/database/osbd
Токмаков, Г. П. Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML: учебное пособие / Г. П. Токмаков. - Ульяновск: УлГТУ, 2018. - 192 с.
Фаронов В.В., Шумаков П.В. Руководство разработчика баз данных. – М.: Нолидж, 2019.
Фундаментальные основы информатики: социальная информатика.: Учебное пособие для вузов / Колин К.К. – М.: Академ.проект: Деловая книга Екатеринбург, 2019.
Перспективы развития СУБД. [Электронный ресурс]. URL: http://www.pd-web.net/bazy-i-banki-dannyh-v-ekonomike/53-perspektivy-razvitiya-subd/
Хайдаров К.А. «Введение в системы управления базами данных» [Электронный ресурс]. URL: http://bourabai.ru/dbt/dbms/index.htm
История развития СУБД [Электронный ресурс]. URL: http://do.bti.secna.ru/lib/book_it/istor_razv.html
С.Д. Кузнецов. «Тенденции в мире систем управления базами данных» [Электронный ресурс]. URL: http://citforum.ru /database/articles/art_25.shtml
Реляционные СУБД. Общая характеристика реляционной модели данных [Электронный ресурс]. URL: migku.wikidot.com/gos-db-12
Системы управления базами данных. Архив номеров [Электронный ресурс]. URL: http://www.osp.ru/dbms/
Общая структура языков программирования. [Электронный ресурс]. URL: http://physics.herzen.spb.ru/teaching/materials/gosexam/b12.htm
Основы SQL. [Электронный ресурс]. URL: http://www.intuit.ru/studies/courses/5/5/lecture/61?page=5