2. классификационный – содержащий сведения о принадлежности вещественного доказательства к тому или оному уголовному делу.
3. справочный – содержащий фамилии следователей, адреса, номера телефонов владельцев.
Были проведены консультации с лицами, непосредственно работающими в данной области.
2.4 Проектирование базы данных
2.4.1 Полное наименование системы и ее условное обозначение
Полное наименование системы – «Автоматизированная система регистрации вещественных и учёта доказательств».
2.4.2 Основание для создания
Разработка данной системы осуществлена в рамках автоматизации системы регистрации и учёта вещественных доказательств.
2.4.3 Назначение автоматизированной системы
Назначение системы заключается в автоматизации системы регистрации вещественных доказательств. Система предназначена для помощи правоохранительным органам в предоставлении оперативной информации по состоянию того или иного вещественного доказательства. Система позволит накапливать информацию и использовать ее для получения данных о вещественном доказательстве, его названии, идентификационном номере, данные о владельце, данные о следователе, ведущего дело.
2.4.4 Цель создания автоматизированной системы
Целью дипломного проектирования является создание системы, предназначенной для автоматизации регистрации вещественных доказательств и для упрощения ручных рутинных операций по их регистрации и учету.
2.5 Функции автоматизированной системы
Автоматизированная система регистрации и учёта вещественных доказательств предполагает разработку комплекса инструментальных программных средств, обеспечивающих следующие возможности:
Ввод новой и корректировка существующей информации, поиск нужных сведений, выполнение запросов, просмотр и печать результатов выполнения запросов;
Обеспечить взаимодействия интерфейса пользователя с информационной системой;
Хранение информации в базе данных;
Разграничение доступа;
Выдавать на печать ранее созданные документы;
Ведение базы данных и поддержание ее в актуальном состоянии;
Автоматизированный обмен данными между удаленными пользователями, доступ пользователей к информационным ресурсам удаленных пользователей;
Реализация электронного архива.
2.6 Пользователи автоматизированной системы
Эксперты-криминалисты.
Следователи.
Другие уполномоченные лица.
2.7 Характеристика входной и выходной информации
Входной информацией будут являться сведения о предмете, предоставляемые на хранение или приобщённого к делу в качестве вещественного доказательства:
а) полное и (в случае, если имеется) сокращенное наименование предмета;
б) К какому уголовному делу относиться;
в) адрес (место нахождения), телефон владельца;
г) Фамилия следователя, ведущего дело;
Выходными данными будет являться индивидуальный идентификационный номер, который будет присваиваться предмету после внесения его в базу данных вещественных доказательств, а также информация о месте его хранения.
2.8.1 Общие требования
К проектируемой системе предъявляются следующие общие требования:
Система должна обладать набором удобных возможностей по вводу информации в систему;
Система должна вести регистрацию и учёт вещественных доказательств, иметь удобный и достаточный набор информации;
Система должна иметь удобный интерфейс.
Система должна быть построена таким образом, чтобы возможно было ее конфигурировать, настраивать под возможные изменения в законодательстве.
2.8.2 Требования к документации
Система должна иметь достаточно детальную документацию по всем выполняемым функциям.
Глава 3. Проектирование автоматизированной системы
3.1 Понятие о базах данных, система управления базах данных
Под базой данных понимается некоторая унифицированная совокупность данных, совместно используемая персоналом/населением группы, предприятия, региона, страны, мира. Задача базы данных состоит в хранении всех представляющих интерес данных в одном или нескольких местах, причем таким способом, который заведомо исключает ненужную избыточность. В хорошо спроектированной базе данных избыточность данных исключается, и вероятность сохранения противоречивых данных минимизируется. Таким образом, создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность.
Информационные системы (ИС) служат для сбора и накопления информации с целью ее эффективного использования. На ранних этапах становления информационных технологий задачи автоматизации обработки решались так: для каждого отдельного участка писалась отдельная прикладная программа. В описание программных модулей входили описание структур данных. Однако это привело к значительному увеличению числу программ, выполняющих сходные функции, но несовместимых друг с другом по данным, используемых программой. Это служило препятствием к написанию больших программных комплексов, а также вызывала сложности в отладке и сопровождении программ. Исходя из этого была разработана концепция баз данных (БД). Основной чертой этой концепции является отделение структур данных от прикладных программ. БД – единое хранилище информации, используемое множеством прикладных программ. Структура данных хранится отдельно от программы для обработки данных. Прикладные программы становятся независимы от данных, которые они обрабатывают.
Предметная область (ПО) - часть реального мира, подлежащая изучению с целью дальнейшей автоматизации. Каждая ПО характеризуется множеством объектов и множеством процессов.
Пример: ПО – бухгалтерия; объекты – документы; процессы - расчет зар. платы, расчет плановой численности и т.д.
СУБД – система управления базами данных. Программная составляющая СУБД включает ядро и сервисные средства. Ядро - набор программных средств, необходимый для создания и поддержания БД. Сервисные средства – обеспечивают дополнительные возможности по управлению данными.
Каждая СУБД поддерживает свой обобщённый инструментарий для отображения ПО, этот инструментария называется моделью данных (МД). Поддерживаемые СУБД МД разбивают на сетевые, иерархические, реляционные.[3]
Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит (по-крупному) из стадий проектирования, реализации и эксплуатации. Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с базой данных, является стадия проектирования. От того, насколько тщательно продумана структура базы, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.
Хорошо спроектированная база данных должна удовлетворять следующим условиям:
Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
Следующие пункты представляют основные шаги проектирования базы данных:
Определить информационные потребности базы данных.
Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики (атрибуты) этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.
Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
Выработать правила, которые будут устанавливать и поддерживать целостность данных.
Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.
3.2 Модели данных: иерархическая, сетевая, реляционная
3.2.1 Сетевая модель данных
Организация МД в СУБД сетевого типа определяется в терминах: элемент, агрегат, запись, групповое отношение, БД.
Элемент - наименьшая единица структуры данных.
Агрегат - именованная совокупность элементов или других агрегатов; Адрес: (ул., дом, квартира)