Банки и базы данных как форма организации информации (стр. 4 из 6)

владелец;

наименование объектов;

дата размещения;

дата оплаты;

сумма заказа.

О клиенте:

наименование организации;

адрес;

индекс;

телефон.

Об объекте недвижимости:

наименование объекта;

категория объекта;

физический адрес объекта;

страна;

владелец;

описание;

стоимость.

О сотрудниках:

фамилия;

имя;

отчество;

домашний адрес;

рабочий телефон.

Требования к оснащению офиса фирмы компьютерной техникой:

ПЭВМ не ниже Pentium 100/32/420 с операционной системой Windows 98 или Windows NT Workstation и пакетом программ MS Office.

лазерный или струйный принтер.

Проектирование информационной модели

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

Рис.4. Диаграмма взаимосвязей между бизнес-компонентами и бизнес-процессами (ER-диаграмма)

В практике проектирования информационных систем такие схемы получили название ER-диаграмм (Entity-relationship diagram (ERD) – диаграмма «Сущность-связь»). ER-диаграммы хорошо вписываются в методологию структурного анализа и проектирования информационных систем. Такие методологий обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем уточняется, давая возможность получить различную степень детализации объекта с различным числом уровней.

Разработка бизнес-правил

Перечень бизнес-правил:

сведения о клиентах хранятся 10 лет.

оплата ожидается 3 недели, если ее не происходит, заказ уничтожается.

подтверждение запроса о приобретении недвижимости отправляется фирме-поставщику после получения сведений об оплате заказа.

Фирма «Диалог» удерживает 5% с суммы сделки.

2.2 Проектирование базы данных

Определение объектов

Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью[10].

Атрибут — это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

В нашем случае объектами будут являться:

объекты недвижимости;

клиенты;

сотрудники;

заказы.

Список объектов и их атрибутов приведен в таблице 1.

Таблица 1

Перечень объектов и их атрибутов

Объект	Атрибуты
Объект недвижимости	Наименование
	Категория
	Адрес
	Страна
	Владелец
	Стоимость
Клиент	Организация
	Адрес
	Индекс
	Телефон
Заказ	Клиент
	Сотрудник
	Владелец
	Заказанные объекты
	Дата размещения заказа
	Дата оплаты
	Сумма заказа
Сотрудник	Фамилия
	Имя
	Отчество
	Адрес
	Телефон

Определение взаимосвязей между объектами

Исходя из задачи, выделим следующие сущности:

Владелец;

Недвижимость;

Клиент;

Продавец;

Заказ;

Продажа;

Счет.

Определим для включенных в модель сущностей взаимосвязи. Полученная после этого модель представлена на рисунке 5.

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

В рассматриваемой задаче по автоматизации управления работой дилера по продаже недвижимости, если клиент производит заказ на покупку впервые, осуществляется первичная регистрация его данных и сведений о сделанном заказе. Если же клиент производит заказ повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько раз данный клиент производил заказы, он имеет уникальный идентификационный номер (уникальный ключ клиента). Информация о каждом клиенте включает наименование организации клиента, адрес, телефон, факс и примечание. Таким образом, атрибутами объекта клиент являются «уникальный ключ клиента», «наименование клиента», «адрес клиента» и т. д.

Следующий представляющий для нас интерес объект – объект недвижимости. Этот объект имеет атрибуты «уникальный ключ объекта», «наименование объекта» и т. д.

Третий рассматриваемый объект — заказ. Его атрибутами являются «номер заказа», «ключ клиента» и «ключ объекта недвижимости».

И четвертый рассматриваемый объект — сотрудник. Его атрибутами являются «уникальный ключ сотрудника», «имя сотрудника», «фамилия» и «отчество».

Схема взаимосвязей между атрибутами в модели приведена приложении 1.

Задание атрибутов, первичных и альтернативных ключей объектов

При переходе к проектированию базы данных основные объекты будут описывать следующие атрибуты (информация, хранимая в таблицах):

Сущность «Клиенты»:

код клиента (ключевое поле);

организация;

адрес;

индекс;

телефон;

город;

регион;

страна;

описание счета;

факс.

Сущность «Объекты недвижимости»:

код объекта недвижимости (ключевое поле);

наименование;

категория;

физический адрес;

страна;

код владельца;

описание;

стоимость.

Сущность «Заказы»:

код заказа (ключевое поле);

код клиента;

наименование;

код сотрудника;

сумма заказа;

дата размещения;

дата оплаты.

Сущность «Владельцы»:

код владельца (ключевое поле);

организация;

адрес;

индекс;

телефон;

город;

регион;

страна;

описание счета;

факс.

Сущность «Сотрудники»:

код сотрудника (ключевое поле);

фамилия;

имя;

отчество;

домашний адрес;

рабочий телефон.

Нормализация модели

Приведение модели к требуемому уровню нормальной формы является основой построения реляционной БД.

В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи. Теория нормализации основана на том, что определенный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы таблиц, с помощью которых могут быть представлены те же данные. Введение нормализации отношений при разработке информационной модели обеспечивает минимальный объем физической, то есть записанной на каком-либо носителе БД и ее максимальное быстродействие, что впрямую отражается на качестве функционирования информационной системы. Нормализация информационной модели выполняется в несколько этапов[11].

Данные, представленные в виде двумерной таблицы, являются первой нормальной формой реляционной модели данных.

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.

В данном случае во избежание дублирования данных выделены две таблицы-справочника – «Категории» и «Страны». После этого, как видно из схемы взаимосвязей сущностей (рис. 6), модель находится в первой нормальной форме.