Особенности построения структуры базы данных физических лиц при проектировании информационных систем
ГОУ ВПО «Юго-Западный государственный университет» г. Курск Ядром любой информационной системы является база данных. В любой базе данных из сферы образования требуется хранить в той или иной форме ст руктурированные сведения о физических лицах: абитуриентах, студентах, преподавателях, сотрудниках и т.д. Естественно, что проектирование базы данных является творческим процессом и во многом зависит от точки зрения разработчика, поэтому в различных система х можно увидеть отличающиеся схемы реализации рассматриваемой предметной области. Структура баз данных, как правило, представляется моделью «сущность -связь» (ER) [1]. Выделив особенности существующих разработок, построим некоторый опорный вариант ER-модели для подобных систем. Для физических лиц в большинстве сфер деятельности необходимо хранить следующий набор данных: фамилию, имя, отчество, пол, дату рождения, место рождения, паспортные данные, адреса, контактные телефоны, e-mail, место работы или учебы. Для сферы образования также требуется иметь сведения о гражданстве физических лиц, их родственниках, о семейном положении, воинской обязанности, национальности. Анализ приведенных объектов приводит к выделению следующих взаимосвязанных сущностей: «Физическое лицо», «Телефон», «Адрес», «Место работы», «Гражданство», «Документ», «Вид документа», «Родственник», «Степень родства», «Военкомат», «Категория воинской обязанности», «Пол». Первая проблема – определение ключевых атрибутов для сущности «Физическое лицо». В качестве первичного ключа можно ввести автоинкрементный числовой или символьный код, но во избежание дублирования информации о физических лицах необходимо выделить вторичный ключ. Комбинация атрибутов «Фамилия», «Имя» и «Отчество» таковым не являются, так как полные однофамильцы встречаются достаточно часто. Добавление в ключ атрибута «Дата рождения» также не разрешает проблему, хотя совпадение 4-атрибутов маловероятно. Однозначно определяют физическое лицо комбинация атрибутов «Серия документа» и «Ном ер документа», но у одного физического лица может быть несколько документов, удостоверяющих личность, поэтому «Документ» вынесен в отдельную сущность (одному физическому лицу соответствует несколько документов). Таким образом, при создании информационной системы необходим о программным способом (на уровне клиента или на уровне сервера) контролировать дублирование физических лиц. При добавлении нового физического лица с существующей фамилией, именем и отчеством следует получить от пользователя подтверждение, что запись не является дублем. А вот при вводе для нового физического лица совпадающих значений серии и номера паспорта следует запретить добавление информации в базу данных. Можно рассмотреть вариант выделения ФИО в отдельную сущность или даже фамилии, им ени и отчества в соответствующие сущности. В любом случае в базе данных желательно иметь таблицы со списками имен, фамилий и отчеств для инкрементного поиска по ним при вводе новых записей о физических лицах и для сокращения типичных ошибок пользователей п ри вводе текстовой информации. К таким ошибкам относятся: простановка лишних пробелов, случайный ввод пользователем отдельных символов на другом языке. Например, русская и английская буквы «С» расположены на клавиатуре на одной кнопке и ввод первой буквы н а английском языке в слове «Сергей» означает, что поиск по русскому имени «Сергей», состоящему из кириллических символов, не даст результатов. Вторая проблема заключается в возможности изменения значений некоторых атрибутов с течением времени и необходимостью отслеживания таких изменений. К таким данным относятся: фамилия, имя и отчество (фамилия меняется, например, при заключении женщиной брака), паспортные данные, адреса, родственники, воинская обязанность, место работы, занимаемая должность. Теоретически к таким атрибутам можно отнести и пол. Важность фиксирования изменений периодических атрибутов определяется сферой применений созданной системы. Новые значения можно хранить с историей (в таком случае необходимо введение новых сущностей и связей) или просто заменять новыми значениями старые. Например, любой торговой фирме необязательно знать об изменении фамилий их клиентов, а новый телефон клиента можно записать вместо старого. В случае образовательных систем хранение истории значений вышеуказанных атрибутов необходимо. Например, для студентов важно знать момент изменения фамилии для корректного формирования различных приказов (о зачислении, о переводе с курса на курс, об отчислении и т.д.), необходимо контролировать изменения состава семьи студента, чтобы вовремя назначить обучающемуся социальные льготы, связанные со смертью одного или обоих родителей. Для решения данной проблемы в продуктах фирмы 1С используются специальные механизмы – периодические реквизиты (в версии платформы 7) и периодические регистры сведений (в версии платформы 8) [2]. По сути это дочерние таблицы базы данных, которые хранят значения атрибутов (реквизитов в терминологии 1С) и дату их актуальности. С помощью встроенных в платформу 1С методов можно получить значение таких атрибутов на любой заданный момент времени. Также стоит отметить, что новое значение ФИО человека фиксируется новым документов, удостоверяющим личность, поэтому при построении инфологической ER-модели можно использовать соответствующие связи между сущностями. Резюмируя вышесказанное, предлагается для хранения информации о физических лицах использовать структуру базы данных, представленную в виде ER-модели на рис. 1. Третья проблема обусловлена соблюдением требований Федерального закона от 27 июля 2006 г. N 152-ФЗ «О персональных данных» (с изменениями и дополнениями). Ее суть сводится к необходимости разграничения доступа к персональным данным в зависимости от полномочий (прав доступа) обрабатывающих сведения пользователей не только на уровне таблиц, но и на уровне отдельных записей. Много противоречий возникает и из -за требования закона о получении согласия от физических лиц на обработку личной информации, фиксируемой в информационной системе. Так, например, «Порядок приема граждан в имеющие государственную аккредитацию образовательные учреждения высшего профессионального образования» (утвержден приказом Министерством образования и науки от 21.10.2009 №442) требует публикации в открытом доступе (в том числе на Web-сайтах вузов) списков абитуриентов с указанием набранных ими баллов по едином у государственному экзамену (ЕГЭ) и вступительным испытаниям. В то же время фамилия, имя, отчество и результаты ЕГЭ являются конфиденциальной информацией о физическом лице, и нет однозначного ответа на вопрос, как поступить, если абитуриент не дал согласия на их распространение. Таким образом, при проектировании баз данных для информационных систем в различных сферах деятельности (в том числе в образовании), необходимо соблюдать следующие принципы: необходимость контроля дублирования информации об одном и том же физическом лице; обеспечение хранения истории значений наиболее важных атрибутов; соблюдение разграничения доступа при обработке персональных данных в соответствии с действующей законодательной базой.
Рис. 1. Вариант ER-модели предметной области «Физическое лицо» Список литературы 1. Маклаков, С. В. Создание информационных систем с AllFusion [Текст] / С. В. Маклаков. – М.: Диалог-Мифи, 2005. – 432 с. 2. Радченко, М.Г. Практическое пособие разработчика. Примеры и типовые приемы / М.Г. Радченко, Е.Ю. Хрусталева. – М.: ООО «1С-Паблишинг», 2009. – 874 с. – С. 249-265. 3. Райордан, Р. Основы реляционных баз данных [Текст] : [пер. с англ.] / Р. Райордан. – М.: Изд.-торг. дом «Русская Редакция», 2001. – 384 с. В.А. Разыграева, А.В. Лямин |
kstu.ee@gmail.com
|
