Пример проектирования БД

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

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

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

1. Требования к данным

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

1.2. Отделение компании представлено следующей информацией: уникальный номер отделения, адрес (составной атрибут), №_тел, №_факса.

1.3. Сотрудник характеризуется: №_личный, имя, фамилия, адрес, №_тел., sex, дата рождения, должность информации об отделении, в которой работает, дополнительная информация.

1.4. Инспектор руководит отдельной группой сотрудников от 10 человек, каждый сотрудник из этой группы отвечает минимум за 10 объектов.

1.5. Объект: №_объекта, адрес, тип_объекта, количество_комнат, ежемесячная_оплата, имя, адрес вдажельца объекта, размер ежемесячной платы ежегодно пересматривается.

1.6. владельцы могут быть частные и юридические лица. Если частное, то характеризуется №, ФИО, адресом и №_тел..,ридичесоке лицо: №, наименование компании, тип компании, адрес, №-тел., имя представителя. Каждый владельцу принадлежит объект.

1.7. Персонал:

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

b. Проводить собоседование с клиентами: №, ФИО, адрес, № телефона, сведения о желаемых характеристиках объекта.

c. Знакомство клиентов с создаваемыми объектами: в один день каждый из клиентов может посещать объект только один раз.

d. Оформление соглашений об аренде некоторого объекта. Соглашение может оформляться от 3 месяцев до года.

e. Проводить регулярные инспектирование состояния объекта.

2. Спецификация требований к транзакциям.

2.1. Составление списка работников для заданного инспектора.

2.2. Составление списка работников, которые обслуживаются данным секретарем.

2.3. Создание и корректировка сведений о сдаваемых объектах.

2.4. Формирование отчета об сдаваемых объектах.

2.5. Формирование списка объектов, закрепленных за конкретным сотрудником.

2.6. Сведения о клиентах.

2.7. Поиск объекта по заданным условиям создание и корректировка сведений о результатах собеседований.

2.8. Список всех объявлений.

2.9. Сведения о заключаемых соглашениях

2.10. Сведения об инспекции объектах.

Сущности обычно из спецификаций выбираются существующие и определяющие как сущности:

Отделение – Branch;

Работник – Staff;

Инспектор – Supervisor

Секретарь – Secretary;

Объект недвижимости - Property for Rent;

Владелец – частное лицо – private owner;

Владелец – юридическое лицо – Business owner;

Объявления – Advert;

Газета – New paper

Собеседование – Interview;

Клиент – client;

Договор об аренде – Lease agreement;

Инспекция – Inspection.

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

Таблица 1. Документация сущностей

Имя сущности	Описание	псевдоним	Особенность использования
Supervisor	Руководит работой персонала по сдаче в аренду объектов недвижимости		Руководит группой о 5 до 10 человек

Выделим типы связей.

Таблица 2. Основные типы связей.

Тип сущности	Тип связи	Тип сущности
Branch	Has (имеет)	Staff
Staff	Supervised by Supported by Manages Sets up Organizes carry out	Supervisor Secretary Property for Rent interview Lease agreement Inspection
Supervisor	Supervised	Staff
Secretary
Property for Rent	Is available Managed by Owner by	Branch Staff Owner
private owner	Ows	Property for Rent
Business owner	Ows	Property for Rent
Advert	Desribed Place In	Property for Rent Newspaper
New paper
Interview	With	Client
client	View Rents Holds	Property for Rent Lease agreement
Lease agreement	Attached to	Property for Rent
Inspection	Mode of	Property for Rent

Необходимо для каждой связи определить кардинальность и уровень участия каждой сущности:

1. Branch Has Staff

Поскольку каждый из отделений компании имеет несколько сотрудников кардинальность 1:N. Поскольку каждое отделение имеет персонал, то степень участия – полная.

2. Property for Rent Managed by Staff

За каждый сдаваемый в аренду объект отвечает сотрудник. Кардинальность 1:1. Степень участия – полная.

3. Staff Manages Property for Rent

Кардинальность -1:N. Степень участия – частичная, т.к. не все сотрудники – инспектора.

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

Таблица 3. Атрибуты сущностей.

Тип сущностей	Атрибуты
Branch	Branch № Address (PostCode, city, street) Tel № Fax №

Таблица 4. Атрибуты связей.

Тип связей	Атрибут
views	Date_View Commets

Следующий шаг состоит в определении доменов атрибутов, необходимо проанализировать те атрибуты, множество допустимых значений, которые имеют какие-то особенности или ограничения. Например, сущность branch имеет атрибут Branch №. Но значение накладывает следующее ограничение: длина не более 3-х символов – от «В01» до «В99».

Иногда бывают домены, которые являются множеством допустимых значений для различных сущностей. Примером такого атрибута является адрес.

Далее необходимо определить первичные или альтернативные ключи.

Таблица 5. Первичные и альтернативные ключи.

Branch	Branch №	Fax №
Supervisor	-	Т.к. сущности являются слабые, то для таких сущностей ключи определены на этапе логического проектирования
Interview	-

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

Сущности:

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

Атрибуты сущности сотрудник, включая и первичный ключ, присутствуют в сущности инспектор (Supervisor) и в сущности секретарь (Secretary). Но Secretary есть еще скорость набора. Сущности принимают участия в различных связей.

Связи, которые поддерживают суперкласс с каждым из своих подклассов являются частичными и непересекающимися.

В качестве еще одного примера можно привести сущности Владельца (Owner) – private Owner и Business Owner. Эти сущности имеют много общих атрибутов, поэтому целесообразно для этих сущностей выполнить генерацию и выделить суперкласс Owner и его подклассы.

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

Дата добавления: 2015-05-09