 |
Практическое задание №3. Знакомство с базой данных Access
|
|
|
|
Представление о базе данных. Принципы организации таблиц в базах данных. Основные объекты. Создание таблиц, запросов, форм, отчетов.
Эффективность функционирования любой информационной системы в юридической сфере во многом определяется уровнем разработки информационного обеспечения, ведущим направлением которого является технология создания и эксплуатации баз данных. База данных является интегрированной системой обработки информации, способствующей сокращению избыточности в хранении данных, совместному использованию информации различными пользователями, удобству доступа к данным и безопасности хранения данных.
В связи с этим актуальным является освоение принципов создания и эксплуатации баз данных. Изучение технологии баз данных дает необходимые знания в области создания и проектирования организованных массивов информации.
Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. Можно выделить следующие этапы проектирования.
1. Системный анализ и словесное описание информационных объектов предметной области.
2. Проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некой инфологической, например, ER-модели.
3. Даталогическое (или логическое) проектирование БД, то есть описание БД в терминах принятой даталогической модели.
4. Физическое проектирование БД, то есть выбор способа размещения БД на внешних носителях.
Системный анализ должен заканчиваться подробным описанием информации об объектах, формулировкой задач с кратким описанием алгоритмов их решения, описанием входных и выходных документов.
|
|
|
Инфологическая модель должна выражать информацию в виде, не зависящем от используемой системы управления базами данных (далее – СУБД). Обычно эта модель отражает описание объектов, их свойства и взаимосвязи в виде схем. В настоящий момент наиболее широкое распространение получила модель Чена (Chen), которая называется «сущность-связь» или ER-модель (Entity Relationship). В ее основе лежат следующие базовые понятия.
Сущность – это класс однотипных объектов. Сущность имеет уникальное имя. Объект имеет свой набор атрибутов – свойств объекта. Атрибут, однозначно идентифицирующий конкретный экземпляр сущности, называется ключевым.
Между сущностями могут быть установлены связи. По множественности связи делятся на три типа: один-к-одному (один экземпляр одной сущности связан только с одним экземпляром другой сущности), один-ко-многим (один экземпляр одной сущности связан с несколькими экземплярами другой сущности), многие-ко-многим (один экземпляр одной сущности связан с несколькими экземплярами другой сущности и наоборот). Связь любого типа может быть обязательной, если в данной связи должен участвовать каждый экземпляр, и необязательной. Связь может быть обязательной с одной стороны и необязательной с другой.
Для реализации проекта в конкретной СУБД следует разработать даталогическую модель. На настоящий момент для этой цели используется реляционная модель данных. Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от англ. «relation» - «отношение»).
Существует алгоритм преобразования ER-модели в реляционную модель данных:
1. Каждой сущности ставится в соответствие отношение реляционной модели данных.
|
|
|
2. Каждый атрибут сущности становится атрибутом соответствующего отношения, задается тип данных и обязательность или необязательность данного атрибута.
3. Первичный ключ сущности становится ключевым полем соответствующего отношения.
4. В каждое отношение, соответствующее подчиненной сущности, добавляется атрибут основной сущности, и этот атрибут становится внешним ключом.
5. Для определения необязательного типа связи у атрибута, соответствующего внешнему ключу, устанавливается необязательность данного атрибута. При обязательном типе связи устанавливается его обязательность.
6. Если в ER-модели присутствуют связи «многие-ко-многим», то для перехода к реляционной модели данных (где такие связи не поддерживаются) вводится дополнительное связующее отношение. Оно связано с каждым исходным связью «один-ко-многим», а его атрибутами служат первичные ключи связываемых отношений.
В результате выполнения даталогического проектирования должна быть разработана схема БД, то есть совокупность отношений, которые моделируют объекты БД и связи между ними.
Разработать БД СУД согласно следующему описанию предметной области.
Описание предметной области. В каждом районе города имеется свой районный суд. В каждом суде имеются судьи, которые занимаются рассмотрением гражданских и уголовных дел и помощники судей, которые занимаются судебным делопроизводством. Каждый судья может иметь несколько помощников, но каждый помощник может работать только с одним судьей.
При разработке БД требуется отразить следующую информацию:
для дел - номер, название, дату открытия, дату закрытия, количество томов, кто рассматривает дело;
у судей - код, фамилия, имя, отчество, место работы (районный суд), коллегия;
для районных судов – код, район, адрес;
для помощников судей – табельный номер, фамилия, контактный телефон, чьи поручения исполняет (код судьи).
1. Разработать ER-модель (модель «сущность-связь»).
Согласно описанию предметной области можно выделить следующие сущности: районные суды, судьи, дела, помощники судей.
При разработке модели «сущность – связь» каждая сущность изображается в виде прямоугольника, в верхней части которого отражается имя сущности, а в нижней – атрибуты данной сущности, ключевой атрибут подчеркнут.
|
|
|
В каждом районном суде могут работать несколько судей, но каждый судья может работать только в одном районном суде. Таким образом, между сущностями районные суды и судьи устанавливается связь один ко многим.
Каждый судья может вести несколько дел, но каждое дело ведет только один судья. Таким образом, между сущностями судьи и дела устанавливается связь один ко многим.
Каждый судья может иметь несколько помощников, но каждый помощник может работать только с одним судьей. Таким образом, между сущностями судьи и помощники судей устанавливается связь один ко многим.
Тогда ER-модель будет выглядеть следующим образом (рис. 1):
 |
Рис. 1 ER-модедь БД «Суд»
2. Согласно алгоритму преобразования ER модели в реляционную, разработать даталогическую модель БД. Согласно алгоритму преобразования ER- модели в реляционную модель данных каждой сущности будет соответствовать одноименное отношение с соответствующими атрибутами. Какие поля будут полями внешнего ключа? Зачем они нужны? Атрибуты, между которыми устанавливается связь, должны иметь одинаковый тип и свойства. На рис. 2 показана реляционная модель «Суд», с указанием типов данных.
3. Реализовать разработанную информационную модель в системе управления базами данных (СУБД) Access.
Формирование базы данных (далее - БД) в Access состоит из ряда последовательных этапов. Первый этап этого процесса – создание таблиц. Таблицы в Access являются теми первичными, исходными файлами, на основе которых в дальнейшем строится все здание БД. Каждой сущности модели соответствует своя таблица. Имя таблицы совпадает с именем сущности.
Данные в таблице организованы в столбцы (называемые полями) и строки (записи). Каждому атрибуту сущности соответствует поле в таблице.
 |
Рис. 2 Реляционная модель «Суд».
Наиболее детальным и основательным методом формирования таблиц является режим конструктора. В режиме конструктора задаются имена полей и типы данных. В зависимости от характера данных необходимо задать свойства полей.
|
|
|
Каждая таблица должна содержать одно или несколько полей, однозначно идентифицирующих каждую запись в таблице. Такое поле называется ключевым полем таблицы. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как ключевое. Ключевой атрибут сущности становится ключевым полем таблицы.
|
|
|
