Оформление, выдача, замена и учёт выданных паспортов гражданина РФ, иных документов, удостоверяющих личность гражданина РФ в пределах РФ

      четыре базовые (самоидентифицируемые) сущности: «Заполнение», «Инспектор ФМС», «Заявление», «Квитанция об оплате»;

      пять зависимых сущностей: «Свидетельство о рождении», «Документы о гражданстве», «Отметки в паспорте», «Получатель платежа», «Плательщик»;

      пять связей типа «один к одному»,  идентифицирующие сущности;

      три связи типа «один ко многим»,  идентифицирующие сущности;

      каждая сущность содержит информацию об определенных данных.

3.2.4  Функция 4 «Проверка документов».

Нормализованная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунке 3.2.6. Сведения об ограничениях целостности, приведенные на этом рисунке, поясняются ниже в подразделе 3.3, посвященном ограничениям и правилам поддержания целостности.

Рисунок 3.2.6 — Нормализованная ER-модель для функции 4 «Проверка документов».

Нормализованная модель содержит:

      две базовые (самоидентифицируемые) сущности: «Инспектор ФМС», «Принятые документы»;

      зависимая сущность «Проверка», моделирующая связи между сущностями;

      две связи типа «один к одному», идентифицирующие все сущности;

      каждая сущность содержит информацию об определенных данных.

3.3  Спецификация ограничений и правил поддержания целостности

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

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

Дополнительные ограничения и правила, не учтенные ранее, не обнаружены.

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

3.4  Вывод

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

4   ПРОЕКТИРОВАНИЕ ГЛОБАЛЬНОЙ ER-МОДЕЛИ

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

4.1  Выявление и устранение эквивалентных сущностей

В данном подразделе были выявлены и устранены эквивалентные сущности.

4.2  Выявление категорий и синтез обобщающих сущностей

В данном подразделе не выявлены категории и обобщающие сущности.

4.3  Выявление и устранение дублирования атрибутов и связей

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

4.4  Графическое представление глобальной ER-модели

В данном подразделе, в результате выявления эквивалентных сущностей и их слияния, выявления категорий и синтеза обобщающих сущностей, выявления и устранения дублирования атрибутов, была построена глобальная ER – модель, представленная на рисунке 4.1.

4.5  Спецификация ограничений и правил поддержания целостности

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

4.6  Вывод

На данном этапе была спроектирована глобальная ER-модель, соответствующая разрабатываемой информационной автоматизированной системе «Оформление, выдача, замена и учёт выданных паспортов гражданина РФ, иных документов, удостоверяющих личность гражданина РФ в пределах РФ», которая отражает деятельность территориального органа Федеральной миграционной службы по месту жительства с целью оказанию государственной услуги.

Рисунок 4.1. — Глобальная ER – модель процесса оказания государственной услуги.

5   ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ SQL-МОДЕЛИ

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

5.1  Перевод глобальной ER-модели в реляционную форму

В разработанной реляционной форме глобальной модели используется 7 таблиц:

1.      «zayva» с полями: id_zayva, id_user (первичный ключ), id_inspect (внешний ключ);

2.      «user_id» с полями: id_user (первичный ключ), fam_user, name_user, otch_user, family_position, signature_user, foto_user, id_cvid_rogd (внешний ключ), id_citizen (внешний ключ);

3.      «inspect_id» с полями: id_inspect (первичный ключ), name_inspect, fam_inspect, otch_inspect;

4.      «cvi_rogd» с полями: id_cvid_rogd (первичный ключ), dt_rogd, mesto_rogd, dt_reg, mesto_reg,, fam_parents, name_parents, otch_parents, nationality;

5.      «citizen» с полями: id_citizen (первичный ключ), vid_citizen, vid_doc_citizen;

6.      «oplata» с полями: id_oplata (первичный ключ), name_oplata, nomer_scheta, data_oplata, datetime, price, id_user (внешний ключ);

7.      «pol_oplata» с полями: id_pol_oplata (первичный ключ), name_pol_oplata, inn_pol_oplata, name_bank, id_oplata (внешний ключ);

5.2 Спецификация ограничений и правил поддержания целостности

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

5.3  SQL-код для создания реляционной модели

В данном подразделе разработан SQL-код для создания реляционной модели.

CREATE TABLE zayva

(

     id_zayva numeric(10, 0) NOT NULL,

     id_user numeric(10, 0) CONSTRAINT PK_zayva_id PRIMARY KEY NOT NULL,

     id_inspect numeric(10, 0) NULL

)

CREATE TABLE user_id

(

     id_user numeric(10, 0) CONSTRAINT PK_user_id PRIMARY KEY NOT NULL,

     fam_user varchar(30)  NOT NULL,

     name_user varchar(30)  NOT NULL,

     otch_user varchar(30)  NOT NULL,

     family_position varchar(30)  NOT NULL,

     signature_user varchar(30)  NOT NULL,

     foto_user image NOT NULL,

     id_cvid_rogd numeric(10, 0) NOT NULL,

     id_citizen numeric(10, 0) NOT NULL

)

CREATE TABLE inspect_id

(

     id_inspect numeric(10, 0) CONSTRAINT PK_inspect_id PRIMARY KEY NOT NULL,

     name_inspect varchar(30)  NOT NULL,

     fam_inspect varchar(30)  NOT NULL,

     otch_inspect varchar(30)  NOT NULL

)

CREATE TABLE cvi_rogd

(

     id_cvid_rogd numeric(10, 0) CONSTRAINT PK_cvi_rogd_id PRIMARY KEY NOT NULL,

     dt_rogd datetime NOT NULL,

     mesto_rogd varchar(30)  NOT NULL,

     dt_reg datetime NOT NULL,

     mesto_reg nchar(10)  NOT NULL,

     fam_parents varchar(30)  NOT NULL,

     name_parents varchar(30)  NOT NULL,

     otch_parents varchar(30)  NOT NULL,

     nationality varchar(30)  NOT NULL

)

CREATE TABLE citizen

(

     id_citizen numeric(10, 0) CONSTRAINT PK_citizen PRIMARY KEY NOT NULL,

     vid_citizen varchar(30)  NOT NULL,

     vid_doc_citizen varchar(30)  NOT NULL

)

CREATE TABLE oplata

(

     id_oplata numeric(10, 0) CONSTRAINT PK_oplata PRIMARY KEY NOT NULL,

     name_oplata varchar(30)  NOT NULL,

     nomer_scheta nchar(13)  NOT NULL,

     datetime NOT NULL,

     price money NOT NULL,

     id_user numeric(10, 0) NOT NULL

)

CREATE TABLE pol_oplata

(

     id_pol_oplata numeric(10, 0) CONSTRAINT PK_pol_oplata PRIMARY KEY NOT NULL,

     name_pol_oplata varchar(30)  NOT NULL,

     inn_pol_oplata nchar(13)  NOT NULL,

     name_bank varchar(30)  NOT NULL,

     id_oplata numeric(10, 0) NOT NULL

)

5.4  Вывод

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

ЗАКЛЮЧЕНИЕ

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

На первом этапе в результате анализа предположительного функционирования гипотетической автоматизированной системы «Оформление, выдача, замена и учёт выданных паспортов гражданина РФ, иных документов, удостоверяющих личность гражданина РФ в пределах РФ» выбраны четыре автоматизируемых функций, охватывающих предметную область, информационное обеспечение которых соответствует семи объектам предметной области и включает 55 атрибута, охватывающих сведения об объектах системы.

На втором этапе в результате анализа информационного обеспечения функций выявлены и сформулированы ограничения и правила поддержания целостности данных, которые были учтены при дальнейшем проектировании. Общее число ограничений на уровне атрибутов составляет 55 (в том числе динамических 2), на уровне кортежей — 52 (2), на уровне множеств кортежей — 51 (1) и на уровне базы данных — 45 (1).

На третьем этапе в результате проектирования локальных ER-моделей, соответствующих отдельным автоматизируемым функциям, были получены нормализованные локальных ER-модели, включающие от 3 до 9 сущностей в третьей нормальной форме. Разработанные на этом этапе спецификации ограничений и правил поддержания целостности включают все ограничения и правила, полученные на втором этапе и трансформированные для локальных ER-моделей.

На четвёртом этапе была спроектирована глобальная ER-модель, соответствующая разрабатываемой информационной автоматизированной системе «Оформление, выдача, замена и учёт выданных паспортов гражданина РФ, иных документов, удостоверяющих личность гражданина РФ в пределах РФ», которая отражает деятельность территориального органа Федеральной миграционной службы по месту жительства., в рамках действия которой осуществляется реализация государственной услуги по оформлению и выдачи паспортов с использованием сети Интернет.

На пятом этапе  была спроектирована реляционная SQL-модель, для чего был сделан перевод глобальной ER-модели в реляционную форму. Затем полученные таблицы  были записаны с помощью  SQL-кода.

                                СПИСОК ЛИТЕРАТУРЫ.

1.            Дейт К.Дж. Введение в системы баз данных: Пер. с англ. — 6-е изд. — Киев: Диалектика, 1998. — 784 с.

2.            Саймон А.Р. Стратегические технологии баз данных: менеджмент на 2000 год: Пер. с англ. — М.: Финансы и статистика, 1999. — 479 с.

3.            Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. — М.: Мир, 1999. — 191 с.

4.            Маклаков С.В. BPwin и Erwin. CASE-средства разработки информационных систем. — М.: ДИАЛОГ–МИФИ, 1999. — 256 с.

5.            Глушаков С. В., Ломотько Д. В. Базы данных. Москва : АСТ – 2000.

Приложения

Приложение 1

SQL запросы к базе данных passport

1.       Добавление записей в  базу даных:

INSERT INTO inspect_id(id_inspect, fam_inspect, name_inspect, otch_inspect)

VALUES ('4','Иванов','Иван','Иванович')

INSERT INTO citizen(id_citizen, vid_citizen, vid_doc_citizen)

VALUES ('1','Гражданин Российской Федерации','свидетельством о рождении')

INSERT INTO cvid_rogd(id_cvid_rogd, dt_rogd, mesto_rogd, dt_reg, mesto_reg, fam_parents, name_parents, otch_parents, nationality)

VALUES ('1','15.07.89','респ. Адыгея, Солнечный р-он, г. Николаевск','16.07.89','Отдел ЗАГС администрации МР "Солнечный район" Адыгейской респ.','Петров','Иван','Петрович','русский')

INSERT INTO user_id (id_user, fam_user, name_user, otch_user, family_position, signature_user, foto_user, id_cvid_rogd, id_citizen)