Проектирование реляционной базы данных «Электронный краевед»

КУРСОВАЯ РАБОТА по дисциплине Информационное обеспечение систем управления на тему Проектирование реляционной базы данных «Электронный краевед»

Содержание Введение

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

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

1.1.1 Назначение и возможности базы данных. Состав данных

1.1.2 Анализ круга пользователей системы

1.1.3 Базовые сущности и их атрибуты

1.1.4 Связь между сущностями и ее атрибуты

1.1.5 Построение ER-диаграммы

2. Определение требований к операционной обстановке

2.1 Объем внешней памяти занимаемый модулями СУБД

2.2 Объем памяти, отводимый под данные

3. Выбор системы управления базой данных (СУБД)

4. Логическое проектирование

4.1 Создание таблиц

4.2 Нормализация отношений

4.3 Ключи и ограничение целостности данных

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

5.1 Составление форм для администратора

5.2 Составление форм, запросов и отчетов для пользователей

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

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

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

1. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

1.1 Анализ предметной области база пользователь операционный запрос

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

· Список терминов;

· Перечень дат и происходивших событий;

· Описание знаменитых личностей Саратовского края;

· Описание основных народностей или групп населения края;

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

База данных необходима выполнять основные функции:

— ввод, редактирование или удаление всех необходимых признаков того или иного события, времени или места;

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

— предоставление информации о конкретном времени, месте или личности, которые задаются в поиске;

— вывод событий, произошедших в определенный промежуток времени, в виде отчета;

— перечень достопримечательностей в населенном пункте;

— вывод событий с подробным описанием;

— поиск событий по месту, личности и времени;

— вывод в виде отчета перечня населенных пунктов.

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

1.1.2 Анализ круга пользователей системы Для предложенной БД различаются два типа пользователей:

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

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

1.1.3 Базовые сущности и их атрибуты Опишем базовые сущности на ЯИМ:

? Время (Код времени, Дата, Год начала, Год конца, Краткое описание);

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

? Личность (Код личности, Изображение, Описание, Имена, Тип, Время жизни) — Изображение хранит файл с изображение личности, Имена — одно или несколько имен личностей, Тип — главная характеристика личности (например, «князь» или «ученый»).

? Места (Код места, Тип, Название, Населенный пункт, описание, Время) — Местом может быть как промышленный, природный объект, так и достопримечательность, это указывается в атрибуте «Тип». Атрибут «Населенный пункт» хранит код города — поле связи с сущностью «Населенные пункты», в котором находится Место.

? Населенный пункт (Код н.п., Тип, Описание, Название, Причина освоения, Время освоения, Изображение) В этой сущности хранятся данные об определенных населенных пунктах (Тип: село, город, деревня). Во «Времени освоения» хранится код времени для связи с таблицей Времена.

? Население (Код населения, Название, Описание, Место, Время) — атрибут «Место» — код места проживания этого населения (народности) для связи с сущностью Места, «Время» — время проживания населения (внешний ключ).

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

Время (Код времени, Дата, Год начала, Год конца, Краткое описание) [Населенный пункт, Население, События]

Место (Код места, Тип, Название, Населенный пункт, описание, Время) [Населенный пункт, Население, События]

Для более подробного описания сущностей, их атрибутов и полученных полей см. пункт 4.1.

1.1.4 Связь между сущностями и ее атрибуты Теперь можно осуществить связь между сущностями. Назовем эту ассоциацию «События», связи которой показана на рисунке 1.

Рисунок 1 — Связи ассоциации «События»

Опишем ассоциацию на языке ЯИМ:

События [Время, Место, Личность] (Код события, Код Времени, Код Места, Код Личности, Причина, Описание)

1.1.5 Построение ER-диаграммы Основываясь на определениях, написанных на ЯИМ, построим полученную ER-диаграмму базы данных (Рисунок 2).

Рисунок 2 — ER-диаграмма базы данных «Электронный краевед»

2. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ОПЕРАЦИОННОЙ ОБСТАНОВКЕ

2.1 Объем внешней памяти, занимаемый модулями СУБД Рассматриваемая база данных является локальной, в качестве операционной системы предлагается использовать Windows XP, как наиболее быстродействующую. Для быстрого функционирования базы данных компьютер должен иметь следующее аппаратное обеспечение: процессор Pentium 4 (1600 МГц), оперативная память — 256 Мб, жесткий диск — 40 ГБ. Но минимальные требования, предъявляемые к базе данных: Pentium 166 МГц, 60 Мб оперативной памяти.

На компьютерах, должен быть установлен пакет Microsoft Office 2003, с русской версией Microsoft Access.

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

2.2 Объем памяти, отводимый под данные Объем памяти требуемый для хранения данных, можно приближенно посчитать по формуле:

Где l_i-длина I записи;

N_i — примерное (максимально возможное) количество записей I таблице;

N_ai — количество записей в архиве I таблице. В нашем случае архива нет.

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

Получили мощность одной записи: 58 байт.

Мощность таблицы «Времена»: M=58*120=6960 байт Таблица 1 — Мощность одной записи в таблице Меню, в байтах

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

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

байт Таким образом, мощность базы данных составляет приблизительно 190кб, но также следует принять во внимание, что данные-изображения будут хранится в отдельных файлах в формате jpg, размер которых сильно меняется, в среднем это 15кб на изображение, таким образом, учитывая запас, общая мощность составит приблизительно 300кб.

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

3. Выбор системы управления базой данных В настоящее время существует большое количество программных продуктов, в которых можно реализовать спроектированную базу данных. Самыми популярными СУБД на сегодняшний день являются: «1С предприятие», «Microsoft Access», «Lotus Approach», «FoxPro», «dBase», «Paradox», «InterBase».

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

Выдвинутым требованиям соответствует СУБД, которая входит в комплект поставки пакета приложений Microsoft OfficeMicrosoft Access 2003

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

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

Так же немаловажным является поддерживаемое Access средство транзакций и откатов, благодаря которым неопытный пользователь в любое время сможет отменить все изменения, проделанные с БД.

Поэтому для физической реализации данного курсового проекта выбираем СУБД Microsoft OfficeMicrosoft Access 2003.

4. ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

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

Таблица «События» является производной от ассоциативной связи.

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

Внешними ключами для таблиц являются:

— «Места»: время, населенный пункт;

— «Населенные пункты»: время освоения;

— «Население»: место, время;

— «Личности»: годы жизни;

— «События»: место, время, личность.

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

Преобразуем таблицы по трем нормальным формам:

· Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение).

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

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

Рассмотрим преобразование таблицы «События»:

Информация по данному событию представляется простыми атрибутами, имеющими одно значение, то есть таблица находится в 1НФ:

Очевидно, что неключевые атрибуты не функционально полно зависят от первичного ключа, для этого выделяются отдельные таблицы «Время», «Место» и «Личности», в которых эти атирбуты уже функционально полно зависят от ключевых атрибутов получившихся таблиц (Код_Времени, Код_Места, Код_Личности). Получили вторую НФ. Запишем оставшиеся зависимые от первичного ключа атрибуты для таблицы «События».

Рассмотрим неключевые атрибуты. Очевидно, они друг с другом не связаны, значит таблица находится в 3 НФ.

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

4.3 Ключи и ограничение целостности данных Отношения в базе данных будут строится на основе первичных ключей представленных в виде Кода. Все связи «один-ко-многим» показаны на ER-диаграмме. (рисунок 2)

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

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

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

5. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Произведем ввод данных в таблицы отношения. Схема отношения приведена на рисунке 3.

Рисунок 3 — Схема отношений БД «Электронный краевед»

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

Рисунок 4 — таблица «Времена

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

Рисунок 5 — Главная кнопочная форма При использовании базы данных администратором используются формы для редактирования данных таблиц. Они были введены для более удобного, интуитивно понятного ввода и поиска конкретных данных о времени, событии, месте и т. д. Доступ к таким формам осуществляется путем нажатия на левые кнопки главной кнопочной формы. К примеру, ниже приведена форма для редактирования таблицы «Население».

Рисунок 6 — Форма для редактирования таблицы «Население»

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

5.2 Составление форм, запросов и отчетов для пользователей

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

Перечень событий.

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

Рисунок 7 — Пользовательская форма событий, основанных на запросе

Рисунок 8 — Запрос на события.

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

События периода

Рисунок 9 — Форма для отображения событий, произошедших за период времени.

Рисунок 10 — Отчет выведенных данных.

Рисунок 11 — Запрос для отображения событий, произошедших за период времени.

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

Private Sub Кнопка7_Click ()

Me.подчиненная_форма_Период.Requery

End Sub

Выбор события.

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

Like «*» & [Forms]![Выбор_места]![Поле] & «*»

Рисунок 12 — Форма и запрос для получения данных о событиях по заданному месту

Отчет перечня населенных пунктов

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

Рисунок 13 — Населенные пункты

Запрос «места в населенном пункте»

Выводится обработчиком событий:

DoCmd.OpenQuery «места в населенном пункте»

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

Рисунок 14 — Запрос с параметром «Места в населенном пункте»

5.3 Защита данных

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

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

MS Access обеспечивает два традиционных способа защиты базы данных: — установка пароля, требуемого при открытии базы данных;- защита на уровне определения прав пользователей, которая позволяет ограничить возможность получения или изменения той или иной информации в базе данных для конкретного пользователя. Установка пароля на открытие базы данных представляет собой простейший способ защиты. После того как пароль установлен (функция меню Сервис > Защита > Задать пароль базы данных), при каждом открытии базы данных будет появляться диалоговое окно, в котором требуется ввести пароль. Открыть базу данных и получить доступ к ее ресурсам могут получить только те пользователи, которые введут правильный пароль. Этот способ достаточно надежен (MS Access шифрует пароль, так что к нему нет прямого доступа при чтении файла базы данных). Однако проверка проводится только при открытии базы данных, после чего все ее объекты становятся полностью доступными. В результате, для данной базы данных используется второй способ защиты данных. Следующий способ организации защиты является защита на уровне пользователей. Он подобен способам, используемым в большинстве сетевых систем. Процесс задания защиты на уровне пользователей состоит из двух принципиальных этапов: — создание системы пользователей, объединенных в группы (Сервис > Защита > Пользователи и группы);- задание прав доступа различных пользователей и групп по отношению к объектам базы данных (Сервис > Защита > Разрешения). В данном случае накладывается ограничение на запись данных во все таблицы для пользователей (учеников). Информация о системе пользователей сохраняется в специальном файле, называемом файлом рабочих групп. По умолчанию это файл System.mdw. При запуске Access от пользователей требуется идентифицировать себя и ввести пароль. Отдельные пользователи могут объединяться в группы, причем один и тот же пользователь может являться членом различных групп. Такая организация системы пользователей позволяет весьма гибко манипулировать набором их прав доступа как пользователей, так и администраторов.

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1 Информатика: Учебник. — 3-е перераб. изд. /Под ред. проф. Н. В. Макаровой. — М.: Финансы и статистика, 2000

2 Голенищев Э. П., Клименко И. В. Информационное обеспечение систем управления. Ростов н/Д: «Феникс», 2003

3 Дейт К.

Введение

в системы баз данных. М.: Наука, 1980

4 Ильина О. П. Организация и технология разработки информационной базы АСУ. Учебн. пособие. — Л. 1986