 |
Отчет по ошибкам Validator
|
|
|
|
Содержание
Введение. 3
1. Описание предметной области. 4
2. Описание логической модели. 5
3. Описание ограничений и значений по умолчанию.. 8
4. Нормализация таблиц. 9
5. Отчет по ошибкам Validator 12
6. Прямое проектирование модели. 13
7. Выполнение запросов. 15
8. Обратное проектирование БД.. 21
Заключение. 22
Введение
Базы данных — это совокупность структур, предназначенных для хранения больших объемов информации и программных модулей, осуществляющих управление данными, их выборку, сортировку и другие подобные действия.
Информация базы данных хранится в одной или нескольких таблицах. Любая таблица с данными состоит из набора однотипных записей, расположенных друг за другом. Они представляют собой строки таблицы, которые можно добавлять, удалять или изменять.
Каждая запись является набором именованных полей, или ячеек, которые могут хранить различную информацию.
В данной работе описывается процесс разработки банковской информационной системы по обслуживанию физических лиц. Для разработки была выбрана среда SQL Developer. Для проектирования и проверки модели использовались средства Erwin Data Modeler и Erwin Model Validator.
Описание предметной области
Предметной областью данной работы является база данных информационной системы банка. Рассматривая данную тему, необходимо выделить основные сущности, ключевые для создания модели данной системы.
Во-первых, требуется организовать хранение информации обо всех доступных операциях. Это включает в себя создание таблиц, отражающих информацию как о самих операциях, так и о каждой конкретной операции, совершенной конкретным клиентом.
Во-вторых, следует хранить информацию обо всех клиентах банка. Логично в рамках этой задачи выглядит отдельно создание таблицы для учета клиентов и отдельно – данных по банковским картам клиентов, поскольку, соответственно специфике базы данных, у одного клиента может быть несколько карт.
|
|
|
Описание логической модели
В данном разделе описывается строение модели базы данных банковской системы с учетом поставленных задач. Информация о клиентах и принадлежащих им картах отражена в таблицах «Клиент», «Клиент_карты». В число данных, хранящихся здесь, входят как личные данные клиентов, к примеру, номер паспорта, так и данные каждой принадлежащей им карты.
Операции по картам реализованы с помощью связи супертип-подтип, где супертипом является таблица «Операции_карты», а подтипами – связанные с ней таблицы с тем же ключом. Они отражают все операции, которые могут быть совершены с использованием банковской карты.
Информация о вкладах и кредитах вынесена в отдельные таблицы для уменьшения избыточности информации в базе данных. Эти таблицы связаны с таблицами, которые отражают вклады и кредиты непосредственно клиентов банка.
Наконец, обслуживание клиентов, не связанное с вышеперечисленными действиями, описано в таблице «Обслуж_филиал». Для возможности уменьшения избыточности информация о существующих филиалах также вынесена в отдельную таблицу.
Более подробно связи между сущностями и ключи, как главные, так и вторичные, представлены на логической модели (см. рисунок 2.1).
Рисунок 2.1 – Логическая модель Erwin
Описание ограничений и значений по умолчанию
В данном разделе работы описаны ограничения и значения по умолчанию таблиц, отражающих сущности данных моделей.
Чтобы избежать у неключевых атрибутов в случае неполной информации значения «null», были созданы значения по умолчанию(см. рисунок 3.2).
Рисунок 2.2 – Значения по умолчанию
|
|
|
Данные значения по умолчанию установлены для некоторых неключевых полей, не являющихся частью альтернативных ключей, поскольку использование альтернативного ключа предполагает внесение уникальной информации.
Нормализация таблиц
В данном разделе описана нормализация таблиц, при этом рассматривается нормализация с первой по пятую нормальные формы(НФ) включительно. Для удобства анализа в конце раздела приводится физическая модель Erwin с указанием атрибутов, типов данных и ключей(см. рисунок 4.1)
1) Таблица «Клиент».
1 НФ – все значения атомарны.
2 НФ – все неключевые атрибуты функционально полно зависят от ключа; так как в данной таблице всего один ключевой атрибут, таблица по определению находится во 2 НФ.
3 НФ – все неключевые атрибуты должны зависеть от главного ключа нетранзитивно; в данном случае это справедливо, поскольку неключевые атрибуты не зависят друг от друга.
НФБК – предполагает, что детерминанты всех функциональных зависимостей являются потенциальными ключами; в данном случае, поскольку нельзя выделить два/более потенциальных ключа, имеющих общий атрибут, можно говорить о том, что таблица находится в НФБК.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
2) Таблицы «Оплата», «Переводы», «Зачисление» - однотипны и могут быть рассмотрены совместно.
1 НФ – все значения атомарны.
2 НФ – атрибуты зависят от ключа нетранзитивно полно.
3 НФ – неключевые атрибуты не зависят друг от друга.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
3) Таблицы «Вклады», «Кредиты», «Филиал» - однотипны и могут быть рассмотрены совместно.
1 НФ – все значения атомарны.
2 НФ – атрибуты зависят от ключа нетранзитивно полно.
3 НФ – неключевые атрибуты не зависят друг от друга.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
4) Таблица «Клиент_вкл».
1 НФ – все значения атомарны.
2 НФ – атрибуты зависят от ключа нетранзитивно полно.
3 НФ – неключевые атрибуты не зависят друг от друга.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
|
|
|
5) Таблица «Клиент_кред».
1 НФ – все значения атомарны.
2 НФ – ключ состоит из одного атрибута, проверка не требуется.
3 НФ – неключевой атрибут всего один, проверка не требуется.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
6) Таблица «Клиент_карты».
1 НФ – все значения атомарны.
2 НФ – ключ состоит из одного атрибута, проверка не требуется.
3 НФ – неключевой атрибут всего один, проверка не требуется.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
7) Таблица «Обслуж_филиал».
1 НФ – все значения атомарны.
2 НФ – ключ состоит из одного атрибута, проверка не требуется.
3 НФ – неключевой атрибут всего один, проверка не требуется.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
8) Таблица «Операции_карта».
1 НФ – все значения атомарны.
2 НФ – ключ состоит из одного атрибута, проверка не требуется.
3 НФ – неключевой атрибут всего один, проверка не требуется.
НФБК – нельзя выделить два/более потенциальных ключа.
4, 5 НФ – ключ состоит из одного атрибута, проверка не требуется.
Рисунок 4.1 – Физическая модель Erwin
Отчет по ошибкам Validator
При проверке модели в Erwin Model Validator ошибок проектирования выявлено не было:
Рисунок 5.1 – Отчет Erwin Model Validator
|
|
|
