Автоматизированная система регистрации вещественных доказательств

Пример реляционной модели данных представлен на рис. 3:

Рис. 3.3.

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

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

отношение, таблица, файл (для локальных баз данных)

кортеж, строка, запись

атрибут, столбец, поле.

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

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

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

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

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

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

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

Существует два подхода к удалению и изменению записей из главной таблицы:

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

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

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

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

3.2.4 Подходы к написанию программ в сетевом режиме работы

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

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

Открытие БД;

Блокирование;

Чтение данных;

Редактирование;

Запись;

Разблокирование.

Необходимо осуществлять обработку транзакций. Транзакцией называется совокупность трех действий: чтение данных, обработка данных, запись данных. При авариях необходимо обеспечивать ликвидацию (откат) незавершенных транзакций для восстановления данных.[4]

3.3 Контекстные диаграммы

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

Рис. 3.4.

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

Теперь рассмотрим более детально весь механизм регистрации и учёта вещественных доказательств. Следующая схема показывает более детальное рассмотрение регистрации и учёта вещественных доказательств (рис. 3.5). Общая система работы подразделяется на два основных этапа: регистрация нового вещественного доказательства и учёт уже имеющихся доказательств в базе данных.

Рис. 3.5.

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

 Скачать реферат