3 Выбор системы управления базой данных (субд) и других инструментальных программных средств

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

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

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

Были рассмотрены такие СУБД как: dBASE, Microsoft Access, FoxPro и Paradox [1].

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

Целостность данных обеспечивают такие СУБД как: Microsoft Access и Paradox. Однако лучшими функциональными возможностями обладает Access.

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

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

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

Для таблицы “Клиенты” наиболее удачным будет использование трехзначного числового первичного ключа – Код клиента. Значения в данном поле не повторяются, то есть являются вполне индивидуальными. Использование в качестве ключа поля ФИО Клиента могло бы привести к ситуации, когда невозможно было бы хранить сведения об однофамильцах с одинаковыми именами и отчествами.

Таблица “Ведущиеся дела” содержит поле Код дела, которое назначено ключевым полем.

Таблица “Процессы” является ассоциацией, однако содержит только первичный ключ – Код процесса.

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

Ситуация для таблицы “Прокуроры” аналогичная ситуации для таблицы “Судьи”.

Таблица “Усилитель связей” содержит исключительно внешние ключи. Составной ключ позволяет расширить возможности по количеству свидетелей и следователей в одном деле.

Таблицы “Свидетель” и “Следователь” имеют внешние ключи Код свидетеля и Код следователя соответственно.

Ниже приведена таблица адресных пространств.

Название таблицы	Предел по ключу
Ведущиеся дела	10000-19999
Клиенты	100-600
Прокуроры	10-50
Процессы	20000-29999
Свидетель	30000-39999
Следователь	600-999
Судьи	51-99
Усилитель связей	все возможные комбинации

Таблица 3

Если пользоваться ограничениями, накладываемыми таблицей 3, то мощность БД ограничится F=4 Мб. Данная цифра показывает, что даже при максимальном использовании БД пользователь не ощутить серьезных замедлений в работе.

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

Введем ограничения целостности и прочие ограничения, накладываемые на данные, хранящиеся в БД. Код клиента не может совпадать, по понятным причинам, с кодами свидетелей, прокуроров, следователей и судей. Кроме того, все они попарно различны. Поле статья в таблице “Ведущиеся дела” должно быть заполнено. Не допускается присутствие анонимов (есть Код, но нет ФИО). В таблице “Процессы” поле Дата слушания должно быть заполнено и попарно они не должны совпадать. Обязательно указание места службы следователя в одноименной таблице. В таблице “Прокуроры”, количество выигранных дел не должно превышать общего числа проведенных дел.

Конечная ER-диаграмма, полученная с использованием вышеизложенных условий, представлена на рисунке 3

Рисунок 3