Разработка и реализация информационной модели предметной области в СУБД Access

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

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

1. Системныйанализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некой инфологической, например, ER-модели.

3. Даталогическое (или логическое) проектирование БД, то есть описание БД в терминах принятой даталогической модели.

4. Физическоепроектирование БД, то есть выбор способа размещения БД на внешних носителях.

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

Инфологическая модель должна выражать информацию в виде, не зависящем от используемой системы управления базами данных (далее – СУБД). Обычно эта модель отражает описание объектов, их свойства и взаимосвязи в виде схем. В настоящий момент наиболее широкое распространение получила модель Чена (Chen), которая называется «сущность-связь» или ER-модель (Entity Relationship). В ее основе лежат следующие базовые понятия.

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

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

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

Существует алгоритм преобразования ER-модели в реляционную модель данных:

1. Каждой сущности ставится в соответствие отношение реляционной модели данных.

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

3. Первичный ключ сущности становится ключевым полем соответствующего отношения.

4. В каждое отношение, соответствующее подчиненной сущности, добавляется атрибут основной сущности, и этот атрибут становится внешним ключом.

5. Для определения необязательного типа связи у атрибута, соответствующего внешнему ключу, устанавливается необязательность данного атрибута. При обязательном типе связи устанавливается его обязательность.

6. Если в ER-модели присутствуют связи «многие-ко-многим», то для перехода к реляционной модели данных (где такие связи не поддерживаются) вводится дополнительное связующее отношение. Оно связано с каждым исходным связью «один-ко-многим», а его атрибутами служат первичные ключи связываемых отношений.

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

Пример разработки БД СУД

Необходимо разработать БД СУД согласно следующему описанию предметной области.

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

При разработке БД требуется отразить следующую информацию:

для дел – номер, название, дату открытия, дату закрытия, количество томов, кто рассматривает дело;

для судей – код, фамилия, имя, отчество, место работы (районный суд), коллегия;

для районных судов – код, район, адрес;

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

1. Разработка ER-модели (модель «сущность-связь»).

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

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

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

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

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

Тогда ER-модель будет выглядеть следующим образом (рис. 7.1.):

Рис 7.1

2. Разработка даталогической модели БД.

Согласно алгоритму преобразования ER- модели в реляционную модель данных каждой сущности будет соответствовать одноименное отношение с соответствующими атрибутами. Какие поля будут полями внешнего ключа? Зачем они нужны? Атрибуты между которыми устанавливается связь должны иметь одинаковый тип и свойства. На рис 7.2. показана реляционная модель «Суд», с указанием типов данных.

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

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

Данные в таблице организованы в столбцы (называемые полями) и строки (записи). Каждому атрибуту сущности соответствует поле в таблице.