Тема: Разработка автоматизированной системы для Бюро недвижимости «Баст-ЕТ» (стр. 6 )

В проектируемой модели использовалась логико-физическая модель, описанная далее.

ER-диаграмма системы на логическом уровне представлена на рисунке 5.

Рисунок 5 – ER-диаграмма проектируемой системы на логическом уровне

Связи между сущностями Контрагент и СторонаСделки, Сделка и СторонаСделки, Характеристика и ТипХарактерист, ТипНедвижимости и ТипХарактерист, Недвижимость и ХарактНедвиж ? идентифицирующие. Остальные связи – не идентифицирующие. В каждой не идентифицирующей связи установлено ограничение 1:N, т.е. должен быть хотя бы один экземпляр главной сущности.

Данные в БД должны обладать свойством целостности. Под целостностью данных понимается корректность данных, и их непротиворечивость в любой момент времени. Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушения (этот вопрос не относится к незаконным изменениям и разрушениям, которые являются проблемой безопасности).

Выделяют три группы правил целостности:

? целостность по сущностям. Объекту или сущности реального мира в реляционных базах данных соответствуют кортежи отношений. Требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений. Первичный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности;

? целостность по ссылкам. База данных не должна содержать несогласованных значений внешних ключей. Правило утверждает, что если В ссылается на А, тогда А должно существовать. Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в таблице, на которую ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать);

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

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

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

Нормализация – процесс проверки и реорганизации сущностей и атрибутов, т.е. разбиения таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта БД, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных.

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

Для приведения сущности к первой НФ следует:

? разделить сложные атрибуты на атомарные;

? создать новую сущность;

? перенести в нее все «повторяющиеся» атрибуты;

? выбрать возможный ключ для нового № (или создать новый номер);

? установить идентифицирующую связь от прежней сущности к новой, № прежней сущности станет внешним ключом для новой сущности.

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

Для приведения сущности ко второй НФ следует:

? выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность;

? поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность;

? установить идентифицирующую связь от прежней сущности к новой.

Сущность находится в 3-й нормальной форме, если она находится во 2НФ и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (не должно быть взаимозависимости между не ключевыми атрибута).

Для приведения сущности к третьей НФ следует:

? создать новую сущность и перенести в нее атрибуты с одной и той же зависимостью от не ключевого атрибута;

? использовать атрибуты, определяющие эту зависимость в качестве первичного ключа новой сущности;

? установить не идентифицирующую связь от новой сущности к старой.

Разработанная модель находится в 3-й нормальной форме, так как:

– все атрибуты содержат атомарные значения;

– каждый не ключевой атрибут полностью зависит от первичного ключа;

– никакой не ключевой атрибут не зависит от другого не ключевого атрибута.

2.5.2 Физическое проектирование

В качестве СУБД выбран Microsoft Access.

ER-диаграмма системы на физическом уровне представлена на рисунке 6.

Рисунок 6 – ER-диаграмма проектируемой системы на физическом уровне

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

Описание таблиц базы данных и их полей в ER-диаграмме приведено в таблицах 2-17.

Таблица 2 – Район

Наименование таблицы	Наименование поля	Тип поля	Первичный ключ	Внешний ключ
Район	ID	Long Integer	Да	Нет
Район	Text(150)	Нет	Нет

Таблица 3 – Риэлтор

Наименование таблицы	Наименование поля	Тип поля	Первичный ключ	Внешний ключ
Риэлтор	ID	Long Integer	Да	Нет
ФИО	Text(50)	Нет	Нет
Логин	Text(15)	Нет	Нет
Пароль	Text(15)	Нет	Нет

Таблица 4 – Заявка

Наименование таблицы	Наименование поля	Тип поля	Первичный ключ	Внешний ключ
Заявка	ID	Long Integer	Да	Нет
Описание	Text(255)	Нет	Нет
ТипНедвижID	Long Integer	Нет	Да
РайонID	Long Integer	Нет	Да
ТипСделкиID	Long Integer	Нет	Да

Продолжение таблицы 4

	ДатаПодачи	Date/Time	Нет	Нет
КонтрагентID	Long Integer	Нет	Да
ЦенаДо	Currency	Нет	Нет
РиэлторID	Long Integer	Нет	Да
Актуально	Yes/No	Нет	Нет

Таблица 5 – Контрагент

Наименование таблицы	Наименование поля	Тип поля	Первичный ключ	Внешний ключ
Контрагент	ID	Long Integer	Да	Нет
ТипКонтрагентаID	Long Integer	Нет	Да
ФИО_Наименование	Text(100)	Нет	Нет
Информация	Text(255)	Нет	Нет
Паспорт	Text(30)	Нет	Нет
Адрес	Text(100)	Нет	Нет
Телефоны	Text(30)	Нет	Нет
Реквизиты	Text(100)	Нет	Нет
ИНН	Text(15)	Нет	Нет
КПП	Text(15)	Нет	Нет