Автор работы: Пользователь скрыл имя, 12 Марта 2012 в 20:54, курсовая работа
Целью данного проекта является выработка умений и навыков проектирования структуры базы данных, предназначенной для функционирования автоматизированной информационной системы.
Для достижения этой цели в данном проекте выполняется разработка структуры реляционной базы данных для гипотетической информационной системы «Оформление, выдача, замена и учёт выданных паспортов гражданина РФ, иных документов, удостоверяющих личность гражданина РФ в пределах РФ».
Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Выбор автоматизируемых функций и информационного
обеспечения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Краткое описание предметной области . . . . . . . . . . . . . . . . . . . . . . . . . .
Выбор и описание автоматизируемых функций . . . . . . . . . . . . . . . . . . .
Первичное описание информационного обеспечения . . . . . . . . . . . . . . .
Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Выявление ограничений и правил поддержания целостности . . . .
Уровень атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Уровень кортежей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Уровень множеств кортежей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Уровень базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Проектирование локальных ER-моделей . . . . . . . . . . . . . . . . . . . . . .
Составление локальных исходных ER-моделей . . . . . . . . . . . . . . . . . . .
Нормализация локальных ER-моделей . . . . . . . . . . . . . . . . . . . . . . . . . . .
Спецификация ограничений и правил поддержания целостности . . . . .
Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Проектирование глобальной ER-модели . . . . . . . . . . . . . . . . . . . . . . .
Выявление и устранение эквивалентных сущностей . . . . . . . . . . . . . . .
Выявление категорий и синтез обобщающих сущностей . . . . . . . . . . . .
Выявление и устранение дублирования атрибутов и связей. . . . . . . . . .
Графическое представление глобальной ER-модели . . . . . . . . . . . . . . .
Спецификация ограничений и правил поддержания целостности . . . . .
Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Проектирование реляционной SQL-модели . . . . . . . . . . . . . . . . . . . .
Перевод глобальной ER-модели в реляционную форму . . . . . . . . . . . . .
Спецификация ограничений и правил поддержания целостности . . . . .
SQL-код для создания реляционной модели . . . . . . . . . . . . . . . . . . . . . .
Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Заключение. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Список литературы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Приложение. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Динамические ограничения на уровне базы данных для данной функции приведены в табл. 2.4.1.2.
Таблица 2.4.1.2. Динамические ограничения на уровне базы данных для функции 1 «Прием заявлений о предоставлении информации для физических лиц».
Атрибут | Динамическое ограничение |
2.1 Номер заявления | Целое число. Новый номер заявления получается прибавлением единицы к предыдущему номеру. |
Операционные правила на уровне базы данных для данной функции, не выявлены.
2.4.2 Функция 2 «Присвоение логина и пароля пользователю».
Статические ограничения на уровне базы данных для данной функции приведены в табл. 2.4.2.1.
Таблица 2.4.2.1. Статические ограничения на уровне базы данных для функции 2 «Присвоение логина и пароля пользователю».
№ п/п | Группа атрибутов | Множество, для которого требуется уникальность |
1 | 1.1 Фамилия инспектора 1.2 Имя инспектора 1.3 Отчество инспектора 1.4 Код инспектора | Определенному коду инспектора должны соответствовать только одни персональные данные. |
2 | 2.1 Логин пользователя 2.2 Пароль пользователя | Определенному пользователя должны соответствовать только одни логин и пароль. |
Динамические ограничения на уровне базы данных для данной функции, не выявлены.
Операционные правила на уровне базы данных для данной функции, не выявлены.
2.4.3 Функция 3 «Заполнение всех необходимых документов».
Статические ограничения на уровне базы данных для данной функции приведены в табл. 2.4.3.1.
Таблица 2.4.3.1. Статические ограничения на уровне базы данных для функции 3 «Заполнение всех необходимых документов».
№ п/п | Группа атрибутов | Множество, для которого требуется уникальность |
1 | 1.1 Фамилия инспектора 1.2 Имя инспектора 1.3 Отчество инспектора 1.4 Код инспектора | Определенному коду инспектора должны соответствовать только одни персональные данные. |
2 | 2.1 Фамилия соискателя 2.2 Имя соискателя 2.3 Отчество соискателя 2.2 Дата рождения 2.3 Место рождения 2.4 Семейное положение | Определенному соискателю должны соответствовать только одни персональные данные. |
3
| 3.1 Фамилия соискателя 3.2 Имя соискателя 3.3 Отчество соискателя 3.4 Дата рождения 3.5 Место рождения 3.6 Дата выдачи 3.7 ФИО родителей 3.8 Национальность 3.9 Место регистрации | Определенному соискателю должны соответствовать только одни персональные данные.
|
4 | 7.1 Наименование получателя платежа 7.2 ИНН получателя платежа 7.3 Номер счета получателя платежа 7.4 Наименование банка | Определенному ИНН получателя платежа должны соответствовать только одни данные. |
6 | 7.8 Фамилия плательщика 7.9 Имя плательщика 7.10 Отчество плательщика 7.11 Адрес плательщика 7.12 Электронная подпись плательщика | Определенному плательщику должны соответствовать только одни персональные данные. |
Динамические ограничения на уровне базы данных для данной функции, не выявлены.
Операционные правила на уровне базы данных для данной функции, не выявлены.
2.4.4 Функция 4 «Проверка документов».
Статические ограничения на уровне базы данных для данной функции не выявлены.
Динамические ограничения на уровне базы данных для данной функции, не выявлены.
Операционные правила на уровне базы данных для данной функции, не выявлены.
2.5 Вывод
В результате анализа информационного обеспечения функций выявлены и сформулированы ограничения и правила поддержания целостности данных, которые должны быть учтены при дальнейшем проектировании. Общее число ограничений на уровне атрибутов составляет 55 (в том числе динамических 2), на уровне кортежей — 52 (2), на уровне множеств кортежей — 51 (1) и на уровне базы данных — 45 (1).
3 ПРОЕКТИРОВАНИЕ ЛОКАЛЬНЫХ ER-МОДЕЛЕЙ
3.1 Составление локальных исходных ER-моделей
В данном подразделе на основе описательных моделей данных, полученных на предшествующих этапах проектирования, для каждой автоматизируемой функции строятся исходные концептуальные модели Entity–Relationship (ER-модели) в графической форме.
3.1.1 Функция 1 «Прием заявления о просьбе регистрации в автоматизированной системе».
Исходная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунке 3.1.1.
Рисунок 3.1.1 — Исходная ER-модель для функции 1 «Прием заявления о просьбе регистрации в автоматизированной системе».
Модель содержит единственную сущность «Прием», набор атрибутов которой имеет следующую структуру: простой агрегат «Инспектор ФМС» и простой агрегат «Пользователь», которые также имеют, в свою очередь, простой агрегат – «ФИО».
3.1.2 Функция 2 «Присвоение логина и пароля пользователю».
Исходная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунке 3.1.3.
Рисунок 3.1.3 — Исходная ER-модель для функции 2 «Присвоение логина и пароля пользователю».
Модель содержит единственную сущность «Присвоение», набор атрибутов которой имеет следующую структуру: простой агрегат «Инспектор ФМС» и агрегат «Цифровые коды». Агрегат «Инспектор ФМС» содержит, в свою очередь, простой агрегат – «ФИО».
3.1.3 Функция 3 «Заполнение всех необходимых документов».
Исходная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунке 3.1.4.
Рисунок 3.1.4 — Исходная ER-модель для функции 3 «Заполнение всех необходимых документов».
Модель содержит единственную сущность «Заполнение», набор атрибутов которой имеет следующую структуру: простой агрегат «Инспектор ФМС», простой агрегат «Заявление о выдаче паспорта», простой агрегат «Свидетельство о рождении», простой агрегат «Документы о гражданстве», простой агрегат «Отметки в паспорте», простой агрегат «Квитанция об оплате». Агрегат «Инспектор ФМС», агрегат «Свидетельство о рождении» и агрегат «Заявление о выдаче паспорта» содержат, в свою очередь, простой агрегат «ФИО». Агрегат «Квитанция об оплате» содержит следующие простые агрегаты: «Получатель платежа» и «Плательщик», который, в свою очередь, содержит простой агрегат «ФИО».
3.1.4 Функция 4 «Проверка документов».
Исходная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунке 3.1.5.
Рисунок 3.1.5 — Исходная ER-модель для функции 4 «Проверка документов».
Модель содержит единственную сущность «Предоставление итогового документа», набор атрибутов которой имеет следующую структуру: простой агрегат «Организация», простой агрегат «Руководитель», простой агрегат «Уведомление об отказе в предоставлении информации». Агрегат «Руководитель» содержит следующие агрегаты: простой агрегат «ФИО» и простой агрегат «Контактная информация».
3.2 Нормализация локальных ER-моделей
3.2.1 Функция 1 «Прием заявления о просьбе регистрации в автоматизированной системе».
Нормализованная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунке 3.2.1. Сведения об ограничениях целостности, приведенные на этом рисунке, поясняются ниже в подразделе 3.3, посвященном ограничениям и правилам поддержания целостности.
Рисунок 3.2.1 — Нормализованная ER-модель для функции 1«Прием заявления о просьбе регистрации в автоматизированной системе».
Нормализованная модель содержит:
две базовые (самоидентифицируемые) сущности: «Пользователь» и «Инспектор ФМС»;
зависимая сущность «Прием», моделирующая связи между сущностями;
две связь типа «один к одному», идентифицирующая сущности;
каждая сущность содержит информацию об определенных данных.
3.2.2 Функция 2 «Присвоение логина и пароля пользователю».
Нормализованная ER-модель для данной функции, полученная на основе описания, приведенного в предыдущих разделах, представлена на рисунках 3.2.3. Сведения об ограничениях целостности, приведенные на этом рисунке, поясняются ниже в подразделе 3.3, посвященном ограничениям и правилам поддержания целостности.
Рисунок 3.2.3 — Нормализованная ER-модель для функции 2 «Присвоение логина и пароля пользователю».
Нормализованная модель содержит:
базовая (самоидентифицируемая) сущность «Пользователь»;
две зависимые сущности: «Присвоение», «Цифровые коды», моделирующая связи между сущностями;
две связи типа «один к одному», идентифицирующие сущности;
каждая сущность содержит информацию об определенных данных.
3.2.3 Функция 3 «Заполнение всех необходимых документов».
Нормализованная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.2.5. Сведения об ограничениях целостности, приведенные на этом рисунке, поясняются ниже в подразделе 3.3, посвященном ограничениям и правилам поддержания целостности.
Рисунок 3.2.5 — Нормализованная ER-модель для функции 3 «Заполнение всех необходимых документов».