Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Государственное образовательное учреждение

высшего профессионального образования

Северо-Кавказский государственный технический университет

Кафедра АСОИУ

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту по Базам данных

на тему: Разработка базы данных "МВД"

Ставрополь 2011 г.

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

Оглавление

1. Техническое задание
Оглавление
Введение
2. Теоретические аспекты проектирования БД
2.1 Этапы проектирования БД
2.2 Описание модели данных
2.3 Основные проблемы проектирования реляционных БД
3. Инфологическое проектирование ПО
3.1 Определение сущностей
3.2 Описание атрибутов
3.3 Установление связей между типами сущностей
3.4 Нормализация БД
3.5 Построение инфологической модели предметной области
4. Выбор СУБД
5. Даталогическое проектирование
5.1 Спецификация файлов БД
5.2 Разработка даталогической модели данных
6. Описание средств обеспечения целостности данных
7. Разработка средств обеспечения безопасности данных
8. Реализация запросов на SQL
9. Описание программного средства
9.1 Требования к аппаратному и программному обеспечению
9.2 Функциональное назначение программы
9.3 Входные данные
9.4 Выходные данные
Заключение
Список литературы и информационных источников
Приложение

Введение

реляционный база данный программный

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

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

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

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

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

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

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

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

2. Теоретические аспекты проектирования БД

2.1 Этапы проектирования БД

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

Таким образом, при проектировании базы данных решаются две основные проблемы:

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

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

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

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;

сортировка данных;

отбор данных;

вывод на печать;

изменение и дополнение данных. [10]

2.2 Описание модели данных

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

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

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

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

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

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

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

Понятие реляционный (англ. relation - отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда. Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

каждый элемент таблицы - один элемент данных;

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

каждый столбец имеет уникальное имя;

одинаковые строки в таблице отсутствуют;

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

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

2.3 Основные проблемы проектирования реляционных БД

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

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

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

· Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.

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

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

3.1 Определение сущностей

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

Каждая сущность должна обладать некоторыми свойствами:

· должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;

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

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

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

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

3.2 Описание атрибутов

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

Как правило, атрибуты указываются только для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Самый простой способ определения атрибутов - после идентификации сущности или связи, задать себе вопрос "Какую информацию требуется хранить о …?". Выявленные атрибуты могут быть следующих видов:

· простой (атомарный, неделимый) - состоит из одного компонента с независимым существованием (например, "должность работника", "зарплата", "норма непогашенного ускорения", "радиус кривой" и т. д.);

· составной (псевдоатомарный) - состоит из нескольких компонентов (например, "ФИО", "адрес", и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные;

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

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

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

· ключевой - служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа);

· неключевой (описательный) - не входит в первичный ключ;

· обязательный - при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL). [7]

Перечислим все атрибуты сущностей в проектируемой базе данных МВД:

1. Сотрудники: Код сотрудника (ключевое поле), ФИО, Возраст, Пол, Адрес, Телефон, Паспортные данные, Код должности, Код звания;

2. Должности: Код должности (ключевое поле), Наименование должности, Оклад, Обязанности, Требования

3. Звания: Код звания (ключевое поле), Наименование, Надбавка, Обязанности, Требования;

4. Виды преступлений: Код вида преступления (ключевое поле), Наименование, Статья, Наказание, Срок;

5. Преступники: Номер дела (ключевое поле), ФИО, Дата рождения, Пол, Адрес, Код вида преступления, Код пострадавшего, Состояние, Код сотрудника;

6. Пострадавшие: Код пострадавшего (ключевое поле), ФИО, Дата рождения, Пол, Адрес

3.3 Установление связей между типами сущностей

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

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

Существует несколько типов связей между сущностями: "один к одному", "один ко многим" и "многие ко многим" .

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

Связь "один ко многим" - наиболее распространенный тип связей. Например, один торговый агент может выписывать много счетов и т.п.

Очень часто используется и связь "многие ко многим". Например, один покупатель может покупать товары нескольких видов, и при этом товар одного вида может "покупаться" разными покупателями.

Рисунок 3.1 - Типы связей между сущностями

Участие каждой сущности в связи может быть полным или частичным. Пример - "сотрудник - торговый агент". Со стороны торгового агента эта связь полная, потому что торговый агент не может не быть сотрудником предприятия. Со стороны сотрудника эта связь - частичная, поскольку сотрудник вполне может не быть торговым агентом. [6]

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

Связь Сотрудники - Звания один ко многим;

Связь Сотрудники - Должности один ко многим;

Связь Преступники - Сотрудники один ко многим;

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

Связь Преступники - Виды преступлений один ко многим.

3.4 Нормализация БД

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

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

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

Первая нормальная форма

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

В таблице 3.1 представлена первая нормальная форма проектируемой базы данных МВД.

Таблица 3.1 - Первая нормальная форма базы данных МВД

Название таблицы	Ключевое поле
Сотрудники Должности Звания Виды преступлений Преступники Пострадавшие	Код сотрудник Код должности Код звания Код вида преступления Номер дела Код пострадавшего

Вторая нормальная форма

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

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

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

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

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

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

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

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

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

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

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

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

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

Рисунок 3.2 - Инфологическая модель базы данных МВД

4. Выбор СУБД

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

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

Показателями, влияющими на выбор СУБД, являются:

· удобство и простота использования;

· качество средств разработки, защиты и контроля базы данных;

· уровень коммуникационных средств в случае применения ее в сетях;

· фирма-разработчик;

· стоимость.

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

При проектировании базы данных МВД выбрали реляционную базу данных Microsoft Access 2003 (далее Access).

Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase.

Работая в среде Microsoft Office, пользователь получает в своё распоряжение полностью совместимые с Access текстовые документы (Word) , электронные таблицы (Excel), презентации (PowerPoint). С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из World Wide Web и транслировать представление данных на языке HTML, обеспечивая работу с такими приложениями как Internet Explorer и Netscape Navigator.

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

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

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

Несмотря на то, что Access является мощной и сложной системой, его использование не сложно для непрофессиональных пользователей. [5]

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

5.1 Спецификация файлов БД

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

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

Основные типы данных:

· Текстовый. Текст или числа, не требующие проведения расчётов.

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

· Числовой. Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вычислений.

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

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

· Денежный. Денежные значения и числовые данные, используемые в математических вычислениях.

· Дата/Время. Дата и время хранятся в специальном фиксированном формате.

· Поле объекта OLE. Включает звукозапись, рисунок и прочие типы данных. Поле этого типа не может быть ключевым или проиндексированным.

· Гиперссылка. Содержит адреса Web-страниц.

На рисунке 5.1 представлены атрибуты каждых из сущностей с выбором их формата ввода.

Рисунок 5.1 - Типы данных всех сущностей базы данных МВД

5.2 Разработка даталогической модели данных

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



Рисунок 5.2 - Даталогическая модель базы данных МВД

6. Описание средств обеспечения целостности данных

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

К средствам обеспечения целостности данных на уровне СУБД относятся:

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

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

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

Некоторые СУБД предусматривают средства обеспечения безопасности данных. Такие средства обеспечивают выполнение следующих операций:

· шифрование прикладных программ;

· шифрование данных;

· защиту паролем;

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

Нарушение целостности данных может быть вызвано рядом причин:

· сбои оборудования, физические воздействия или стихийные бедствия;

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

· программные ошибки СУБД или ОС;

· ошибки в прикладных программах;

· совместное выполнение конфликтных запросов пользователей и др.

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

7. Разработка средств обеспечения безопасности данных

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

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

Главные аспекты информационной безопасности СУБД

· Конфиденциальность

· Целостность

· Доступность

Некоторые СУБД предусматривают средства обеспечения безопасности данных. Такие средства обеспечивают выполнение следующих операций:

· шифрование прикладных программ;

· шифрование данных;

· защита паролем;

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

Для обеспечения безопасности хранимой информации в базе данных МВД, ввели пароль 1234, с помощью системы защиты Access. [2]

8. Реализация запросов на SQL

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

Рассматриваемый непроцедурный язык SQL (Structured Query Language - структуризованный язык запросов) ориентирован на операции с данными, представленными в виде логически взаимосвязанных совокупностей таблиц. Особенность предложений этого языка состоит в том, что они ориентированы в большей степени на конечный результат обработки данных, чем на процедуру этой обработки. SQL сам определяет, где находятся данные, какие индексы и даже наиболее эффективные последовательности операций следует использовать для их получения: не надо указывать эти детали в запросе к базе данных.

Запрос: Отдел кадров

SELECT Сотрудники.[Код сотрудника], Сотрудники.ФИО, Должности.[Наименование должности], Звания.Наименование, Должности.Оклад

FROM Звания INNER JOIN (Должности INNER JOIN Сотрудники ON Должности.[Код должности]=Сотрудники.[Код должности]) ON Звания.[Код звания]=Сотрудники.[Код звания];

Запрос: Преступники

SELECT Преступники.[Номер дела], Преступники.ФИО AS Преступники_ФИО, Преступники.Состояние, [Виды преступлений].Наименование, Постадавшие.ФИО AS Постадавшие_ФИО, Сотрудники.ФИО AS Сотрудники_ФИО

FROM Сотрудники INNER JOIN (Постадавшие INNER JOIN ([Виды преступлений] INNER JOIN Преступники ON [Виды преступлений].[Код вида преступления]=Преступники.[Код вида преступления]) ON Постадавшие.[Код пострадавшего]=Преступники.[Код пострадавшего]) ON Сотрудники.[Код сотрудника]=Преступники.[Код сотрудника];

9. Описание программного средства

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

Системные требования:

* Процессор: Pentium II - 266 MHz (Pentium III рекомендуется);

* Windows 2K/XP/Vista/Windows 7

* Оперативная память: 128Mb RAM (192Mb RAM рекомендуется);

* Место на жестком диске: 136Mb.

Дисковые накопители. Для установки Access требуется устройство для чтения компакт-дисков (или совместимое с ним устройство для чтения DVD-дисков).

Монитор. Необходим монитор Super VGA с разрешением 800x600 или более высоким, отображающий 256 и более цветов.

Указывающие устройства. Необходима мышь Microsoft Mouse, Microsoft IntelliMouse или совместимое с ними указывающее устройство, клавиатура. [5]

9.2 Функциональное назначение программы

Благодаря пользовательскому интерфейсу Microsoft Office Fluent и наличию интерактивных средств, не требующих глубоких знаний в области баз данных, в Office Access 2003 теперь можно быстро отследить нужные данные и с легкостью создать отчеты на их основе. Office Access 2003 позволяет быстро начать работу со встроенными базами данных, чтобы внести в них изменения и адаптировать эти базы к меняющимся деловым потребностям пользователя. Пользователь может собирать данные с помощью форм электронной почты или импортировать данные из внешних приложений. Реализована возможность создания и редактирования подробных отчетов, содержащих отсортированные, отфильтрованные и сгруппированные данные, которые позволяют принимать более обоснованные решения. Совместный доступ к данным обеспечивается путем перемещения файлов Office Access 2003 на веб-узел Microsoft Windows SharePoint Services, где можно проверять журнал исправлений, восстанавливать удаленные данные, настраивать разрешения доступа к данным и периодически выполнять резервное копирование. [2]

9.3 Входные данные

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

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

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

Смоделированные формы ввода новых записей в базу данных МВД представлены в приложении 4. [6]

9.4 Выходные данные

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

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

Созданные отчеты базы данных МВД представлены в приложении 6.

Заключение

Современную жизнь представить без современной техники просто невозможно.

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

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

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

Главная кнопочная форма позволяет просматривать отчеты о сотрудниках МВД и преступниках.

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

Список литературы и информационных источников

1. Н.Ю. Братченко, Базы данных: учебное пособие. - Ставрополь: СевКавГТУ, 2011. - 195 с.

2. И.А. Виноградова, Е.А. Грибова, В.Г. Зубков Практикум на ЭВМ. MS Access: Учебное пособие для студентов заочной (дистанционной) формы обучения. - М.: ГИНФО, 2000. - 124 с.

3. О.Л. Голицына, Н.В. Максимов, И.И. Попов Базы данных: Учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.

4. В.В. Кириллов Основы проектирования реляционных баз данных. Учебное пособие. - СПб.: ИТМО, 1994.

5. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. - СПб.: БХВ-СПб., 2003. - 720 с.

6. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.

7. Тихомиров Ю.В. MS SQL Server 2000: разработка приложений. - СПб.: БХВ-Петербург, 2000. - 368 с.

8. http://subscribe.ru/catalog/comp.soft.db.compsoftdba2003?pos=2

9. http://www.advlab.ru/articles/article378.htm

10. http://inf.e-alekseev.ru/text/Etapy_bd.html

11. http://www.intel.com

Приложение 1

Блок-схема разработанного программного продукта

Приложение 2

Распечатка программы в Microsoft Visual Basic

Приложение 3

Главная кнопочная форма

Приложение 4

Распечатка входных форм

Приложение 5

Распечатка форм запросов

Приложение 6

Распечатка выходных форм



Размещено на Allbest.ru