44129

Построение и проверка локальной логической модели данных

Дипломная

Коммуникация, связь, радиоэлектроника и цифровые приборы

Например объект работник безусловно является сущностью потому что любой работник существует независимо от того знаем мы его имя адрес и номер телефона или нет. Сведения об атрибутах Тип сущности Атрибут Описание Тип данных длина Ограничения Допустность NULL Производный Отдел Отдел_№ Уникальный идентификатор отдела компании Целое Первичный ключ нет нет Отдел_Имя Наименование отдела Символьный до 50 символов нет нет Тел_№ Номер телефона отдела Символьный фиксированный 13 символов Альтернативный ключ нет нет Факс_№ Номер факса...

Русский

2013-11-10

524.5 KB

2 чел.

1. Описание предметной области

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

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

  1.  В компании «Реалтэкс» есть персонал, отвечающий за продажу объектов недвижимости (агенты). Весь персонал разделен на отделы, управление которыми поручено менеджерам, имеющим собственного секретаря.
  2.  Информация, описывающая отдел, включает уникальный номер отдела, номер телефона.
  3.  Информация, описывающая каждого работника, включает: личный (табельный) номер, полное имя , адрес проживания, номер телефона, пол, дату рождения, должность, номер отдела. О тех, кто работает на должности секретаря, необходимо иметь дополнительную информацию, например скорость печати.
  4.  Менеджер руководит работой отдела (от 4 до 8 человек).
  5.  Информация, описывающая каждый продаваемый объект недвижимости, включает: номер объекта, тип объекта, площадь, количество комнат, цена квадратного метра, адрес дома, номер и название владельца. Каждый объект закреплен за определенным отделом компании. Каждый объект недвижимости имеет единственного владельца.
  6.  О владельце объекта недвижимости хранятся сведения: номер владельца, название компании,  адрес, контактный телефон, контактное лицо.
  7.  В обязанности агентов входит следующее:
    •  Обеспечивать продажу объекта недвижимости.

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

  •  Проводить собеседования с клиентами, заинтересованными в покупке объекта недвижимости.

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

  •  Знакомить клиентов с продаваемыми объектами недвижимости.

О каждом просмотре объекта недвижимости сохраняется информация: номер клиента, его имя и номер телефона, дата ознакомления с объектом, номер объекта, тип, адрес, замечания клиента.

  •  Оформлять договора продажи объекта недвижимости.

Информация о договоре продажи включат: номер договора, дата договора, номер и полное имя клиента, номер и название владельца объекта, номер объекта, его адрес, тип, сведения о количестве комнат, стоимость, размер аванса, способ платежа отметку о внесении аванса, дату окончания взаиморасчетов по договору.


1.2. Требования к транзакциям.

К основным транзакциям, которые должны выполняться пользователем (Менеджер), относятся следующие:

  •  составление списка работников отдела, которым он руководит
    •  составление списка работников других отделов
    •  создание и корректировка записей, содержащих детальные сведения о предложенных на продажу объектах недвижимости и их владельцах, в разрезе каждого из отделов компании
    •  создание отчета, содержащего подробные сведения о продаваемых объектах недвижимости, в разрезе каждого отдела компании
    •  создание и корректировка записей, содержащих подробные сведения о клиентах, в разрезе каждого отдела компании
    •  составление списка клиентов, зарегистрированных в каждом из отделов компании
    •  поиск объектов, удовлетворяющих определенным требованиям
    •   создание и корректировка записей, содержащих сведения о результатах ознакомления клиентов с объектами
    •  составление отчета, содержащего комментарии клиентов, относящиеся к конкретному объекту
    •  создание и корректировка записей, содержащих сведения о помещенных в СМИ рекламных объявлениях с информацией об объекте
    •  создание списка всех рекламных объявлений для конкретного объекта
    •  создание списка всех рекламных объявлений в конкретном СМИ
    •  создание и корректировка записей, содержащих детальные сведения о заключенных договорах продаж
    •  отображение подробных сведений о договоре продажи конкретного объекта


2. Построение локальной концептуальной модели данных

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

  •  Типы сущностей
    •  Типы связей
    •  Атрибуты
    •  Домены атрибутов
    •  Потенциальные ключи
    •  Первичные ключи

2.1. Определение типов сущностей

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

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

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

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

Анализ показывает, что основными сущностями, упоминаемыми в спецификациях, являются следующие:

Отдел компании - Отдел

Работник - Работник

Секретарь - Секретарь

Менеджер - Менеджер

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

Владелец объекта недвижимости - Владелец

Рекламное объявление - Объявление

СМИ - СМИ

Собеседование с клиентом - Собеседование

Клиент - Клиент

Договор продажи – Договор

Документирование выделенных типов сущностей

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

Таблица № 2.1. Сведения о типах сущностей

Имя сущности

Описание

Особенности использования

Отдел

Место работы

   В компании может быть один и более отделов.

Работник

Общий термин, описывающий весь персонал, работающий в компании

Каждый сотрудник работает в одном из отделов компании

Менеджер

Руководит работой персонала, отвечающего за продажу объектов

В каждом отделе один менеджер. Каждый менеджер руководит группой работников (от 4 до 8 человек)

Секретарь

Выполняет функции       

секретаря, необходимые остальному персоналу

Каждый отдел компании имеет одного секретаря.

Объект

Общий термин, обозначающий все типы продаваемых объектов недвижимости

Каждый объект имеет единственного владельца. Каждый объект обслуживается одним из отделов компании. Каждый объект может быть продан одному клиенту.

Владелец

Владелец продаваемого объекта

Каждый владелец владеет одним или больше продаваемым объектом

Объявление

Объявление с описанием продаваемого объекта

Каждое опубликованное в СМИ объявление описывает отдельный продаваемый объект

СМИ

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

Объявления о продаже объектов помещаются в специализированные московские газеты и журналы

Собеседование

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

Работник проводит собеседование с клиентом, выразившим желание приобрести некоторый объект недвижимости.

Клиент

Общий термин, описывающий всех клиентов, заинтересованных в осмотре объектов с целью их покупки

Каждый клиент может приобрести один или более объектов

Договор

Содержит подробные сведения о договоре продажи, заключенным с клиентом


2.2. Определение типов связей.

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

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

Тип сущности

Тип связи

Тип сущности

Отдел

Имеет

Работник

Работник

Находится под руководством

Проводит

Оформляет

Менеджер

Собеседование

Договор

Менеджер

Руководит

Работник

Секретарь

Помогает

Работник

Объект

Закрепляется за

Принадлежит

Отдел

Владелец

Владелец

Владеет

Объект

Объявление

Описывает

Помещается в

Объект

СМИ

Собеседование

С

Клиент

Клиент  

Осматривает

Покупает

Заключает

Объект

Объект

Договор

Договор

Связан с

Объект

Проанализировав Таблицу 2.2. , можно обнаружить, что некоторые связи, по сути,  являются одними и теми же. Например, два типа связей – Работник Находится под руководством Менеджера и Менеджер Руководит Работником – фактически представляют одну и ту же связь.

2.3. Определение кардинальности и уровня участия отдельных типов связи.

Установив связи, которые будут иметь место в создаваемой модели, необходимо определить кардинальность каждой из них. Каждая связь может иметь кардинальность либо "один к одному" (1:1), либо "один ко многим" (1:М), либо "многие ко многим" (М:М). Кроме того, следует проанализировать степень участия каждой из сущностей в конкретном типе связи. Степень участия может быть либо полной (тотальной), либо частичной.

Связь Отдел Имеет Работника

Каждый отдел компании имеет несколько работников и, следовательно, кардинальность данной связи надо определить как  1:М. Поскольку любой из отделов компании имеет работников, степень участия сущности Отдел в связи Имеет является полной.

Чтобы лучше разобраться в сути данной связи, рассмотрим ее в обратном направлении – Работник Работает в Отделе. Каждый работник компании может работать только в одном отделе, и, следовательно, связь Работает в имеет кардинальность 1:1. Поскольку все работники компании работают каком-либо отделе, степень участия сущности Работник в связи Работает в будет полной.

Теперь мы можем ссылаться на связь между сущностями Отдел и Работник как на связь Отдел Имеет Работника, либо как на связь Работник Работает в Отделе. Однако при отображении некоторой связи на диаграмме сущность-связь (ER-диаграмме), всегда следует использовать вариант с более высоким уровнем кардинальности – в нашем случае это 1:М. Поэтому за данной связью целесообразно будет сохранить то имя, которое связано с кардинальностью 1:М - Отдел Имеет Работника.

Окончательный вариант кардинальности и степени участия сторон связи Отдел Имеет Работника:

                             1                                   М    

Связь Работник Находится под руководством Менеджера

Каждый работник может находиться под руководством только одного менеджера и, следовательно, кардинальность данной связи надо определить как 1:1. Работник компании не обязательно находится под руководством менеджера, поэтому степень участия сущности Работник в связи Находится под руководством является частичной.

Рассмотрим эту связь в обратном направлении – Менеджер Руководит Работником. Каждый менеджер может руководить несколькими работниками, и, следовательно, связь Руководит имеет кардинальность 1:М. Каждый менеджер компании руководит работниками, поэтому степень участия сущности Менеджер в связи  Руководит является полной. За данной связью целесообразно будет сохранить имя Менеджер Руководит Работником. 

                             1                                   М    

Связь Работник Проводит Собеседование

Каждый работник может провести много собеседований (1:М), каждое собеседование проводится одним работником (1:1). Работник не обязательно проводит собеседование (степень участия – частичная), собеседование всегда проводится работником (степень участия – полная).

                             1                                   М    

Связь Работник Оформляет Договор

Каждый работник оформляет много договоров (1:М), работник не обязательно оформляет договор (степень участия  - частичная). Каждый договор оформляет один работник (1:1), договор обязательно оформляется работником (степень участия – полная).

                             1                                   М    

Связь Секретарь Помогает Работнику

Секретарь помогает всем работникам отдела (1:М), каждый работник обращается за помощью только к секретарю своего отдела (1:1). Секретарь обязательно помогает работникам отдела (степень участия – полная), работник может обойтись без помощи секретаря (степень участия – частичная).

                             1                                   М    

Связь Объект Закрепляется за  Отделом

Каждый объект обязательно закрепляется за одним отделом (1:1), за каждым отделом может быть закреплено несколько объектов (1:М). Степень участия сущностей Объект и Отдел в связи Закрепляется полная.

За данной связью целесообразно будет сохранить имя Отдел Предлагает Объект. 

                             1                                   М    

Связь Объект Принадлежит Владельцу

Каждый объект может принадлежать одному владельцу (1:1), каждый владелец может владеть несколькими объектами (1:М). Степень участия сущностей Объект и Владелец в связи Принадлежит полная.

За данной связью целесообразно будет сохранить имя Владелец Владеет Объектом.

                           1                                   М    

Связь Объявление Описывает Объект

Каждое объявление описывает один объект (1:1), каждый объект может быть описан в нескольких объявлениях (1:М). Объявление обязательно описывает объект (степень участия – полная), не на каждый объект даются объявления (степень участия – частичная).

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

                          1                                   М    

Связь Объявление Помещается в  СМИ

Каждое объявление помещается в одном СМИ (1:1), каждое СМИ может опубликовать много объявлений (1:М). Степень участия сущностей Объявление и СМИ в связи Помещается в полная.

За данной связью целесообразно будет сохранить имя СМИ Публикует Объявление.

                           1                                   М    

Связь Собеседование С Клиентом

Каждое собеседование проводится с одним клиентом (1:1), с каждым клиентом проводится одно собеседование (1:1). Степень участия сущностей Собеседование и Клиент в связи С является полной.

                             1                                   1    

Связь Клиент Осматривает Объект

Каждый клиент может осмотреть много объектов (1:М). Каждый объект может быть осмотрен несколькими клиентами (1:М). Таким образом, кардинальность связи Осматривает устанавливается как (M:N). Степень участия обеих сущностей в связи Осматривает является частичной.

                        М                                   N    

Связь Клиент Покупает Объект

Каждый клиент может купить несколько объектов (1:М), каждый объект может быть куплен только одним клиентом (1:1). Участие обеих сущностей в связи Покупает является частичным.

                             1                                   М    

Связь Клиент Заключает Договор

Каждый клиент может заключить несколько договоров (1:М), каждый договор может быть заключен с одним клиентом (1:1). Договор обязательно заключается с клиентом (полное участие), клиент может не заключить договор (частичное участие).

                            1                                 М

                                   

Связь Договор Связан с Объектом

Каждый договор заключается на определенный объект (1:1), на каждый объект может быть заключен один договор (1:1). Степень участия сущности Договор в связи Связан с является полной, а сущности Объект – частичной.

                             1                                   1   

Документирование типов связей

В документацию следует поместить подробную информацию обо всех связях, включая сведения о кардинальности и степени участия ее членов.

Таблица 2.3 Сведения о типах связей

Тип сущности

Тип связи

Тип сущности

Кардинальность

Показатель участия

Отдел

Имеет

Предлагает

Работник

Объект

1:М

1:М

П:П

П:П

Работник

Проводит

Оформляет

Собеседование

Договор

1:М

1:М

Ч:П

Ч:П

Менеджер

Руководит

Работник

1:М

П:Ч

Секретарь

Помогает

Работник

1:М

П:Ч

Объект

Описывается в

Объявлении

1:М

Ч:П

Владелец

Владеет

Объект

1:М

П:П

СМИ

Публикует

Объявление

1:М

П:П

Собеседование

С

Клиент

1:1

П:П

Клиент  

Осматривает

Покупает

Заключает

Объект

Объект

Договор

М:N

1:М

1:М

Ч:Ч

Ч:Ч

Ч:П

Договор

Связан с

Объект

1:1

П:Ч


2.4. Определение атрибутов и связывание их с типами сущностей и связей
.

На следующем этапе необходимо выявить все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных.

Пользуемся тем же методом, который применялся нами для идентификации сущностей:

выберем все существительные и содержащие их фразы, присутствующие в спецификациях на проект. Выбранное существительное представляет атрибут в том случае, если оно описывает свойство, качество, идентификатор или характеристику некоторой сущности или связи. Самый простой метод выделения атрибутов - после идентификации очередной сущности или связи в некоторой спецификации задать себе следующий вопрос: "Какую информацию требуется хранить о...". Ответ на этот вопрос надо искать в тексте спецификациях.  Если имеющейся в спецификациях информации недостаточно, следует обратиться за необходимыми разъяснениями к пользователям.

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

  •  Выделено несколько сущностей подобного типа (например сущности Работник, Менеджер и Секретарь). На данном этапе достаточно просто отметить тот факт, что эти типы сущностей имеют общий набор атрибутов.
    •  Найдена связь между сущностями разных типов. В этом случае атрибут следует связать только с родительской сущностью и уточнить, был ли описан этот тип связи при выполнении этапа 2.2.

Таблица 2.4.1. Атрибуты, принадлежащие сущностям

Тип сущности

Атрибут

Отдел

Отдел_№ (номер отдела)

Отдел_Имя (название отдела)

Тел_№ (номер телефона)

Факс_№ (номер факса)

Работник

Раб_№ (табельный номер)

Полное_Имя (Имя, Фамилия)(имя, фамилия)

Адрес 

Тел_№

Пол

ДР (дата рождения)

Должность

Менеджер

Те же атрибуты, что и для сущности Работник

Секретарь

Те же атрибуты, что и для сущности Работник

Скорость_Печати (скорость печати на клавиатуре)

Объект

Объект_№ (номер объекта)

Площадь

Тип (тип объекта недвижимости)

Комнаты (количество комнат)

Цена (стоимость квадратного метра)

Адрес (Район, Улица, Дом, Кв)

Владелец

Владелец_№ (номер владельца)

Название (название компании)

Адрес

Тел_№

Контакт (контактное лицо/представитель)

Объявление

Объявление_№ (номер объявления)

Дата (дата выхода)

СМИ_Имя (наименование СМИ)

Цена (стоимость объявления)

СМИ

СМИ_Имя

Адрес

Тел_№

Контакт_СМИ (контактное лицо)

Собеседование

Дата

Комментарии

Клиент

Клиент_№ (номер клиента)

Полное_Имя (Имя, Фамилия)(имя, фамилия)

Адрес

Тел_Кл

Объект_Тип (требуемый тип объекта недвижимости)

Площадь_Мах (максимальная площадь объекта)

Цена_Max (максимальная стоимость объекта)

Договор

Договор_№ (номер договора)

Дата_Договор (дата подписания договора)

Цена (стоимость квадратного метра)

Аванс (сумма аванса)

Дата_Аванс (Дата внесения аванса)

Дата_окончание (Предполагаемая дата последнего платежа по договору)

Окончание (Фактическая дата окончательного платежа)

Таблица 2.4.2. Атрибуты, принадлежащие связям

Тип связи

Атрибут

Осматривает

Дата_Осмотра (Дата осмотра объекта клиентом)

Комментарии

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

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

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

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

·   Использовать потенциальный ключ с минимальным набором атрибутов.

·   Выбирать тот потенциальный ключ, который имеет минимальную вероятность потери

уникальности значений в будущем.

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

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

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

Например, сущность Договор имеет два потенциальных ключа – Договор_№ и (Объект_№, Дата_Договор). Очевидно, что потенциальным ключом с минимальным набором атрибутов является ключ Договор_№. Именно его и следует выбрать в качестве первичного ключа сущности Договор. Оставшийся потенциальный ключ этой сущности (Объект_№, Дата_Договор) мы определяем как ее альтернативный ключ.

Результаты определения первичных и альтернативных ключей для каждой сущности представлены в Таблице 2.5.1.

Таблица 2.5.1. Сущности и их первичные и альтернативные ключи

Сущность

Первичный ключ

Альтернативный ключ

Отдел

Отдел_№

Тел_№

Работник

Раб_№

Менеджер

Раб_№

Секретарь

Раб_№

Объект

Объект_№

Владелец

Владелец_№

Объявление

Объявление_№

СМИ

СМИ_Имя

Тел_№

Собеседование

Клиент

Клиент_№

Договор

Договор_№

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

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

Документирование выделенных атрибутов

В документацию необходимо поместить подробные сведения об атрибутах, перечисленных в Таблице 2.4.1. и Таблице 2.4.2. Для каждого атрибута следует указать общее описание, тип данных и длину значения, имеющиеся ограничения, псевдонимы (если таковые существуют), значение по умолчанию (если таковое имеется), а также является атрибут составным или простым и допустимо ли для него значение NULL.


Таблица 2.5.2 Сведения об атрибутах

Тип сущности

Атрибут

Описание

Тип данных, длина

Ограниче-ния

Допуст- сть NULL

Произ-водный

Отдел

Отдел_№

Уникальный идентификатор отдела компании

Целое

Первичный ключ

нет

нет

Отдел_Имя

Наименование отдела

Символь-ный, до 50 символов

нет

нет

Тел_№

Номер телефона отдела

Символь-ный, фиксирован-ный, 13 символов

Альтерна-тивный ключ

нет

нет

Факс_№

Номер факса отдела

Символь-ный, фиксирован-ный, 13 символов

нет

нет

Работник

Раб_№

Уникальный идентификатор сотрудника фирмы

Целое

Первичный  ключ

нет

нет

Полное_Имя

Имя работника (составной атрибут, включает атрибуты Имя и Фамилия)

Имя

Имя работника

Символь-ный, до 15 символов

нет

нет

Фамилия

Фамилия работника

Символь-ный, до 15 символов

нет

нет

Адрес

Полный домашний адрес работника

Символь-ный , до 50 символов

нет

нет

Тел_№

Номер домашнего телефона работника

Символь-ный, фиксирован-ный, 13 символов

да

нет

Пол

Пол работника

Символьный фиксированный, 1 символ

нет

нет

ДР

Дата рождения работника

Дата

нет

нет

Должность

Должность, занимаемая работником

Символь- ный, до 20 символов

нет

нет

Менеджер

Те же атрибуты, что и для сущности Работник

Определяет работника, занимающего должность менеджера

То же, что и для сущности Работник

То же, что и для сущности Работник

То же, что и для сущности Работник

То же, что и для сущности Работник

Секретарь

Те же атрибуты, что и для сущности Работник

Определяет работника, занимающего должность секретаря

То же, что и для сущности Работник

То же, что и для сущности Работник

То же, что и для сущности Работник

То же, что и для сущности Работник

Скорость_

Печати

Скорость печати в знаках в минуту

Целое

нет

нет

Объект

Объект_№

Уникальный идентификатор каждого объекта

Символь-ный, 6 символов

Первичный ключ

нет

нет

Тип

Тип объекта (коммерческая или жилая недвижимость)

Один символ

нет

нет

Площадь

Площадь объекта

Числовой, два знака после запятой

нет

нет

Комнаты

Количество комнат

Целое

да

нет

Цена_М

Стоимость одного квадратного метра площади объекта

Денежный

нет

нет

Адрес

Адрес (составной атрибут, включает атрибуты Район, Улица, Дом,Кв)

Район

Район в адресе объекта

Символь-ный, до 4 символов

нет

нет

Улица

Улица в адресе объекта

Символь-ный, до 25 символов

нет

нет

Дом

Номер дома в адресе объекта

Символь-ный, до 20 символов

нет

нет

Кв

Номер объекта в доме

Целое

нет

нет

Владелец

Владелец_№

Уникальный идентификатор каждого владельца

Целое

Первичный ключ

нет

нет

Название

Название фирмы владельца объекта

Символь-ный, до 50 символов

нет

нет

Адрес

Полный юридический адрес владельца

Символь-ный, до 50 символов

нет

нет

Тел_№

Телефон офиса владельца

Символь-ный, фиксирован-ный, 13 символов

нет

нет

Контакт

Контактное лицо, представитель владельца

Символь-ный, до 50 символов

нет

нет

Объявление

Объявление_№

Уникальный идентификатор каждого рекламного объявления

Символь-ный,  6 символов

Первичный ключ

нет

нет

Дата

Дата выхода объявления

Дата

нет

нет

Цена

Стоимость  одного выхода объявления

Числовой, два знака после запятой

нет

нет Символь-ный, фиксирован-ный, 13 символов

СМИ

СМИ_Имя

Название СМИ

Символь-ный, до 50 символов

Первичный ключ

нет

нет

Адрес

Полный адрес редакции

Символь-ный, до 50 символов

нет

нет

Тел_№

Телефонный номер офиса/ редакции СМИ

Символ-ный, фиксированный, 13 символов

Альтерна-тивный ключ

нет

нет

Контакт

Контактное лицо, представитель СМИ

Символь-ный, до 50 символов

нет

нет

Собеседова-ние

Дата

Дата проведения собеседования

Дата

нет

нет

Коммент-ии

Комментарии, замечания о клиенте и его требованиях

Символьный

да

нет

Клиент

Клиент_№

Уникальный идентификатор каждого клиента

Символь-ный, 6 символов

Первичный ключ

нет

да

Полное_Имя

Имя клиента (составной атрибут, включает атрибуты Имя и Фамилия)

Имя

Имя клиента

Символь-ный, до 15 символов

нет

нет

Фамилия

Фамилия клиента

Символь-ный, до 15 символов

нет

нет

Адрес

Полный адрес клиента

Символь-ный , до 50 символов

да

нет

Тел_Кл

Телефонные номера клиента (домашний, мобильный)

Символь-ный, до 50 символов

нет

нет

Объект_Тип

Требуемый тип объекта

Символь-ный, 1 символ

нет

нет

Площадь_ Мах

Максимальная площадь объекта для покупки

Числовой, два знака после запятой

нет

нет

Цена_мах

Максимальный уровень цены одного квадратного метра объекта

Денежный

нет

нет

Договор

Договор_№

Уникальный идентификатор договора продажи

Символь-ный, до 10 символов

Первичный ключ

нет

нет

Дата_ Договор

Дата заключения договора продажи

Дата

нет

нет

Цена_М

Стоимость одного квадратного метра площади объекта

Денежный

нет

нет

Аванс

Сумма аванса по договору

Денежный

нет

нет

Дата_Аванс

Дата внесения аванса

Дата

нет

нет

Дата_ Окончание

Предполагаемая дата последнего платежа по договору

Дата

нет

нет

Окончание

Фактическая дата окончательного платежа

Дата

да

нет

2.6. Определение доменов атрибутов

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

Таблица 2.6. Сведения о доменах атрибутов

Имя домена

Характеристики домена

Примеры допустимых значений

Отдел_№

Целое значение, от 1 до 99

9, 15

Отдел_Имя

Строка переменной длины, до 50 символов

Отдел элитного жилья, Отдел коммерческой недвижимости

Те_№, Факс_№

Строка, 13 символов

(095) 200-02-00

Раб_№

Целое значение, от 1 до 999

5, 13, 121

Имя

Строка переменной длины, до 15 символов

Надежда

Фамилия

Строка переменной длины, до 15 символов

Лопатникова

Адрес

Строка переменной длины, до 50 символов

Москва, ул. Молодцова, д. 8, корп. 1, кв. 28

Пол

Строка длиной в один символ (значения М или Ж)

М, Ж

ДР

Дата

31/03/1978

Должность

Строка переменной длины, до 20 символов

Агент

Скорость_Печати

Целое, до трех знаков

220

Объект_№

Строка, длиной 6 символов

01-056

Тип

Строка длиной в один символ (значения К или Ж)

К, Ж

Площадь

Число, до двух знаков после запятой

80,35; 1269, 56

Комнаты

Целое, до трех знаков

2, 4, 15

Цена_М

Денежная величина

970, 2750

Район

Строка переменной длины, до 4 символов

ЦАО, СВАО

Улица

Строка переменной длины, до 25 символов

Остоженка

Дом

Строка переменной длины, до 20 символов

д. 35, копр. 4

Кв.

Целое, до четырех знаков

28, 196

Владелец_№

Целое, до четырех знаков

15, 122

Название

Строка переменной длины, до 50 символов

ОАО «Пирс-технолоджи»

Контакт

Строка переменной длины, до 50 символов

Ларина Татьяна Анатольевна

Объявление_№

Строка, длиной 6 символов

01-225

Дата

Дата

01/02/2005

Цена

Денежная величина

526

СМИ_Имя

Строка переменной длины, до 50 символов

Мир и Дом

Комментарии

Строка переменной длины

Клиент_№

Строка, длиной в 6 символов

02-056

Тел_Кл

Строка переменной длины, до 50 символов

8-926-115-26-11, 095-121-51-29

Договор_№

Строка переменной длины, до 10 символов

02-056/01-015/1

Дата_Договор

Дата

12/12/2004

Аванс

Денежная величина

12500

Дата_Аванс

Дата

20/12/2004

Дата_Окончание

Дата

17/01/2005

Окончание

Дата

14/01/2005


2.7. Специализация/генерализация типов сущностей.

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

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

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

                                                                    

         1        1

 М      М

Рис. 2.7. Суперкласс Работник и его подклассы Секретарь и Менеджер


2.8. Создание диаграммы «сущность-связь»

С целью получения наглядного представления основных сущностей и связей, определенных в спецификациях для пользователя Менеджер, мы рисуем ER-диаграмму (рис.2.7. ). Эта ER-диаграмма и подготовленная на этапе 2 документация (в совокупности) представляют собой локальную концептуальную модель данных для пользователя Менеджер приложения Реалтэкс.

  

           1       1

    М          М

 

М   1   М    1

        1

                 1

1        М

        1     

     М   

       М

1        1

1       М        1

   М   

1

             N     1

М       

       М

      М     1

     

Рис. 2.8. Локальная концептуальная модель данных для пользователя Менеджер приложения Реалтэкс.

2.9. Обсуждение локальной концептуальной модели с пользователем

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


3. Построение и проверка локальной логической модели данных

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

3.1. Преобразование концептуальной модели данных в логическую модель

На этом этапе мы займемся преобразованием концептуальной модели данных с целью удаления из нее всех структур, реализация которых в СУБД реляционного типа затруднительна. Желаемый результат может быть достигнут посредством выполнения таких действий как:

  •  Удаление связей типа М:N
    •  Удаление сложных связей
    •  Удаление рекурсивных связей
    •  Удаление связей, имеющих атрибуты
    •  Удаление множественных атрибутов
    •  Перепроверка связей 1:1
    •  Удаление избыточных связей

3.1.1. Удаление связей типа M:N

Как следует из рисунка 2.8, связь Клиент Осматривает Объект имеет кардинальность «многие ко многим» (М:N). Поэтому необходимо преобразовать связь Осматривает в две связи типа 1:М (назовем их Выполняет и Проводится для), для чего потребуется ввести новую слабую сущность Осмотр. Поскольку вновь созданная сущность является слабой, первичный ключ сущности Осмотр будет полностью или частично определяться сущностями-владельцами, т.е. сущностями Клиент и Объект.

   1     М          М            1

Рис. 3.1.1 Удаление связи типа M:N Клиент Осматривает Объект

3.1.2. Удаление сложных связей

На этом этапе проводится удаление любых сложных (не бинарных) связей, присутствующих в концептуальной модели. Однако на ER-диаграмме, показанной на рисунке 2.8, связи подобного типа отсутствуют. Все связи в локальной концептуальной модели представления Менеджер являются бинарными. Другими словами, любая связь в этой концептуальной модели существует только между двумя сущностями.

3.1.3. Удаление рекурсивных связей.

На рисунке 2.8 показаны две рекурсивные связи – Менеджер Руководит Работником и Секретарь Помогает Работнику. Эти связи являются рекурсивными, поскольку они представляют связи между отдельными экземплярами сущности одного и того же типа. И Менеджер и Секретарь являются такими же членами коллектива, как и другие работники, но выполняют особые обязанности, определяющие их отношения с другими членами производственного персонала. Однако сущности Менеджер и Секретарь представляют только некоторых членов персонала и не могут представлять любого из работников.

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

  1          М

    1          М

           1

      1

Рис. 3.1.2. Удаление рекурсивных связей Помогает и Руководит.

3.1.4. Удаление множественных атрибутов

В локальной концептуальной модели данных представления Менеджер множественные атрибуты отсутствуют, поэтому мы просто переходим к следующему этапу.

3.1.5. Перепроверка связей типа 1:1

В некоторых случаях сущности, участвующие в связи 1:1, могут фактически представлять различные аспекты одного и того же объекта. По этой причине рекомендуется вновь проанализировать смысл всех связей типа 1:1, присутствующих  в модели данных. В нашей модели имеется две связи подобного типа: Собеседование С Клиентом и Договор Связан с Объектом, однако совершенно очевидно, что участвующие в нем сущности представляют разные объекты реального мира.

На этапе 3.1.3. была введена новая связь типа 1:1, помещенная в модель с целью удаления рекурсивных связей. Это связь Подчиненный Принадлежит к Работник, показанная на рисунке 3.1.3. В данном случае сущности Работник и Подчиненный, по сути, не являются представлением одного и того же объекта. Различие между ними состоит в том, что работники, представленные сущностью Подчиненный, имеют особые связи с сущностями Менеджер и Секретарь, а так же составляют только часть всего персонала. Исходя из этих соображений, мы принимаем решение, сохранить в модели сущности и их связи, показанные на рисунке 3.1.2.

3.1.6. Удаление избыточных связей

Показанная на рис. 2.8. связь Клиент Покупает Объект фактически уже представлена в модели в виде пути, образованного связями Клиент Заключает Договор и Договор Связан с Объектом. Поэтому связь Покупает является избыточной и не вносит какой-либо дополнительной информации, которая не представлялась бы уже через путь, включающий сущность Договор. Более того, клиент вообще не может купить какой-либо объект недвижимость, не заключив договор продажи этого объекта.

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

3.1.7. Создание диаграммы «сущность-связь»

ER-диаграмма, представляющая локальную концептуальную модель данных для представления  Менеджер приложения Реалтэкс, была показана на рис. 2.8. При выполнении этапа 3.1 эта модель была пересмотрена и модифицирована с целью устранения структур данных, реализация которых в среде реляционных СУБД затруднительна. Вид модифицированной модели данных, с учетом всех изменений показан на рис. 3.1.7. Полученную в результате внесения изменений модель данных правильнее будет называть локальной логической моделью данных представления Менеджер приложения Реалтэкс.

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


      1

           М

            1       М

  

                     1

               1

 

М   1   М    1

        1

                 1

1        М

        1     

     М   

       М

1        1

1       М        1

      

   1

                       1

       

1

   М

 М       М

      М     1

     

Рис. 3.1.7. Локальная логическая модель данных для пользователя Менеджер приложения Реалтэкс

3.2. Определение набора отношений исходя из структуры

локальной логической модели данных.

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

Для описания структуры создаваемых отношений мы воспользуемся языком DBDL (Database Definition Language), широко используемым в реляционных СУБД. Описание отношения на языке DBDL начинается с присвоенного ему имени, за которым следует помещенный в скобки список имен его простых полей. Затем указывается первичный ключ отношения и все его альтернативные и/или внешние ключи. После описания внешних ключей может указываться ссылочный первичный ключ, если таковой имеется. Все имена отношений и полей мы будем писать в английской транскрипции.

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

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

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

Otdel (Otdel_№, Otdel_Imya, Tel_№, Fax_№)

Primary Key Otdel_№

Alternate Key Tel_№

Rabotnik (Rab_№, Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№)

Primary Key Rab_№

Foreign Key Otdel_№ reference Otdel (Otdel_№)

Object (Object_№, Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec_№)

Primary Key Object_№

Foreign Key Otdel_№ reference Otdel (Otdel_№)

Foreign Key Vladelec_№ reference Vladelec (Vladelec_№)

Vladelec (Vladelec_№, Nazvanie, Adres, Tel_№, Kontakt)

Primary Key Vladelec_№

Klient (Klient_№, Imya, Familiya, Adres, Tel_Kl, Object_Tip, S_Max, Cena_Max )

Primary Key Klient_№

Dogovor (Dogovor_№, Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№ )

Primary Key Dogovor_№

Foreign Key Object_№ reference Object (Object_№)

Foreign Key Rab_№ reference Rabotnik (Rab_№)

Foreign Key Klient_№  reference Klient (Klient_№)

Objyavlenie (Objyavlenie_№, Data, Cena, Object_№, SMI_№ )

Primary Key Objyavlenie_№

Foreign Key Object_№ reference Object (Object_№)

Foreign Key SMI_№ reference SMI (SMI_№)

SMI (SMI_Imya, Adres, Tel_№, Kontakt )

Primary Key SMI_№

Alternate Key Tel_№

Osmotr (Data_Os, Kommentarii, Klient_№, Object_№ )

Primary Key Klient_№, Object_№, Data_Os

Foreign Key Object_№ reference Object (Object_№)

Foreign Key Klient_№  reference Klient (Klient_№)

Sobesedovanie (Data_Sob, Kommentarii, Rab_№, Klient_№ )

Primary Key Klient_№, Rab_№, Data_Sob

Foreign Key Rab_№ reference Rabotnik (Rab_№)

Foreign Key Klient_№  reference Klient (Klient_№)

3.3. Проверка модели с помощью правил нормализации.

Нормализация – это метод создания набора отношений с заданными свойствами на основе требований, предъявляемых к данным в организации.

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

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

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

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

Первой нормальной формой (1НФ) называется отношение, в котором на пересечении каждой строки и каждого столбца располагается одно и только одно значение.

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

Третьей нормальной формой (3НФ) называется отношение, которое находится в 2НФ, причем в нем нет атрибутов, не входящих в первичный ключ, которые транзитивно зависят от этого первичного ключа. Транзитивная зависимость означает следующее: если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А.

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

Четвертой нормальной формой (4НФ) называется отношение, которое находится в НФБК и не содержит нетривиальных многозначных зависимостей. В случае многозначной зависимости, существующей между атрибутами А, В и С некоторого отношения, для каждого значения А имеется набор значений атрибута В и набор значений атрибута С. Однако входящие в эти наборы значения атрибутов В и С не зависят друг от друга.

Пятой нормальной формой (5НФ) называется отношение, которое не содержит зависимостей соединения. Зависимость соединения – это такая ситуация при которой декомпозиция отношений может сопровождаться генерацией ложных строк при обратном соединении декомпозированных отношений посредством операции естественного соединения.

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

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

Otdel (Otdel_№, Otdel_Imya, Tel_№, Fax_№)

Primary Key Otdel_№

Alternate Key Tel_№

Otdel_№        Otdel_Imya, Tel_№, Fax_№

Tel_№         Otdel_№, Otdel_Imya, Fax_№

Rabotnik (Rab_№, Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№)

Primary Key Rab_№

Rab_№       Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№

Object (Object_№, Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec_№)

Primary Key Object_№

Object_№     Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec

Dogovor (Dogovor_№, Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№ )

Primary Key Dogovor_№

Dogovor_№   Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№

Object_№         Cena

При анализе функциональной зависимости Dogovor выясняется, что имеет место транзитивная зависимость вида Object_№         Cena для первичного ключа Dogovor_№ этого отношения. Подобная зависимость является нарушением третьей нормальной формы (ЗНФ) и, следовательно, должна быть удалена из отношения Dogovor. Однако нет необходимости создавать отдельное отношение для представления этой функциональной зависимости, поскольку она уже представлена в отношении Object. Кроме того, удаление этой аномалии не потребует изменения ER-диаграммы, достаточно будет просто внести соответствующие изменения в документацию.

3.4. Проверка модели в отношении транзакций пользователей.

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

3.5. Определение требований поддержки целостности данных.

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

3.5.1. Обязательные данные.

Необходимо установить, какие из атрибутов всегда должны содержать одно из допустимых значений. Другими словами, нас интересуют атрибуты, которые всегда должны иметь конкретные значения, отличные от NULL. Например, атрибуты Раб_№ и Полное_Имя (Имя, Фамилия) сущности Работник всегда должны иметь конкретные значения, отличные от пустого. Однако на атрибут Тел_№  этой же сущности данное требование не распространяется, и этот атрибут вполне может иметь значение NULL, означающее, что у работника либо нет телефона, либо номер его неизвестен.

Условие обязательного наличия данных реализовано практически во всех коммерческих СУБД . Это условие целостности требует, чтобы некоторые столбцы не содержали значение NULL. Пользователю предоставляется возможность самостоятельно решить вопрос о том , каким столбцам присваивать значение NULL и каким нет. Это делается при создании таблицы в инструкции CREATE TABLE . Если столбец не может содержать значение NULL , то в этой инструкции на него накладывается ограничение NOT NULL

СУБД обрабатывающая столбец с ограничением NOT NULL проверяет, чтобы ни одна инструкция INSERT или UPDATE не добавляла и не обновляла строку со значением NULL

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

3.5.2. Ограничения для доменов атрибутов

Домен атрибута устанавливает набор допустимых значений, которые могут присваиваться атрибуту. Примеры доменов атрибутов логической модели данных пользователя Менеджер были приведены при выполнении этапа 2.6 и представлены в Таблице 2.6.

3.5.3. Целостность таблицы

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

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

Особым случаем условия уникальности является значение NULL в столбце первичного ключа или в столбце объявленном уникальным. СУБД не может разобраться является ли   NULL   дубликатом уже существующего первичного ключа или нет. Правильным может оказаться и то, и другое. По этой причине любой столбец являющийся частью первичного ключа, и любой столбец на который наложено условие уникальности, должен быть объявлен с ограничением NOT NULL.

3.5.4. Ссылочная целостность

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

Существуют четыре типа изменений в базе данных, которые могут привести к нарушению ссылочной целостности отношении предок/потомок. К ним относятся:

1    Добавление новой строки потомка . При добавлении новой строки в таблицу-потомок, значение ее внешнего ключа должно быть равно одному из значении первичного ключа таблицы предка. В противном случае будет нарушена целостность базы данных, так как появится потомок без предка{«сирота»). При добавлении строки в таблицу-предок проблема с целостностью данных не возникнет, так как существование предка без потомка допустимо.

2. Обновление внешнего ключа в строке-потомке. Эта операция допустима, если новое
значение внешнего ключа таблицы-потомка будет равно одному из значений первичного
ключа таблицы-предка.

3. Удаление строки-предка. Если из таблицы-предка будет удалена строка у которой есть
хотя бы один потомок, то строки-потомки станут сиротами  (удаление же строки-потомка
не вызывает никаких проблем).

4. Обновление первичного ключа в строке-предке. Если происходит изменение первичного
ключа в таблице-предке, то все потомки, ссылающиеся на этот ключ, становятся сиротами.

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

В стандарте SQL задаются соответствующие правила удаления и обновления строк для каждого отношения предок/потомок.

Рассмотрим вначале правило удаления строк. Каковы действия СУБД при попытке пользователя удалить строку из таблицы-предка? Для ответа на этот вопрос необходимо выбрать одно из четырех возможных правил удаления:

  1.  RESTRICT - запрещает удаление строки из таблицы-предка, если строка имеет
    потомков. Применительно к нашей базе данных это правило формулируется следующим
    образом: «нельзя удалить данные об отделе, если за ним закреплен хотя бы один
    работник».
  2.  CASCADE - устанавливает, что при удалении строки-предка все строки-потомки также
    автоматически удаляются из таблицы-потомка. Например, при удалении
    данных об отделе удаляются данные обо всех работниках, закрепленных за этим
    отделом.

3.SET NULL - устанавливает, что при удалении строки-предка внешним ключам во всех ее строках-потомках присваивается значение NULL. Применительно к нашей базе данных это правило может звучать как  «при удалении данных об отделе необходимо указать, что пока неизвестно, в какой отдел переводятся его работники».

4. SET DEFAULT - устанавливает, что при удалении строки-предка, внешним ключам во всех ее строках-потомках присваивается определенное значение, установленное по умолчанию для этого столбца.

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

Когда пользователь пытается обновить значение первичного ключа в таблице-предке. то реакция СУБД на эти действия определяется правилами обновления, принятыми в соответствующей базе данных. Здесь как и в случае с правилами удаления используются четыре правила обновления:

  1.  RESTRIСТ — запрещает обновление  первичного ключа в строке таблицы-предка, если у строки есть потомки. Инструкция UPDАТЕ, пытающаяся изменить значение первичного ключа в такой строке, отбрасывается, и выдается сообщение об ошибке. В нашем случае это правило можно сформулировать как: "нельзя изменить идентификатор отдела, если имеются закрепленные за ним работники"
  2.  CASCADЕ —  определяет,  что,  при  изменении  значения  первичного  ключа  в строке-предке,  соответствующее  значение   внешнего   ключа   в  таблице-потомке автоматически  изменяется  во  всех строках-потомках таким образом чтобы соответствовать новому значению первичного ключа.
  3.   SET NULL — определяет, что, при обновлении значения  первичного ключа в строке-предке, внешним ключам во всех ее строках-потомках автоматически присваивается значение NULL.   Таким   образом,   изменение   первичного   ключа   в

таблице-предке вызывает установку значений NULL в некоторых столбцах таблицы-потомка.

  1.  SET DEFAULT — определяет, что, при обновлении значения первичного ключа в строке-предке, внешним ключам во всех ее строках-потомках по умолчанию присваивается определенное значение, установленное для данного столбца. Таким образом, изменение первичного ключа в таблице-предке вызывает выполнение "установки по умолчанию" в некоторых столбцах таблицы-потомка.

Правила удаления и обновления бывают «одноуровневые», «двухуровневые» и «многоуровневые». Так например правило RESTRIСТ являются «одноуровневым», так как в отношении предок/потомок оно затрагивает только таблицу-предок. Правила SЕТ NULL и  SЕТ DEFAULT являются  «двухуровневыми» правилами так как их влияние заканчивается на таблице-потомке, а правило САSCADE - «многоуровневым», так как оно затрагивает все таблицы участвующие в отношениях.

Otdel (Otdel_№, Otdel_Imya, Tel_№, Fax_№)

Primary Key Otdel_№

Alternate Key Tel_№

Rabotnik (Rab_№, Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№)

Primary Key Rab_№

Foreign Key Otdel_№ reference Otdel (Otdel_№) on delete SET NULL on update CASCADE

Object (Object_№, Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec_№)

Primary Key Object_№

Foreign Key Otdel_№ reference Otdel (Otdel_№) on delete SET NULL on update CASCADE

Foreign Key Vladelec_№ reference Vladelec (Vladelec_№) on delete RESTRICT on update CASCADE

Vladelec (Vladelec_№, Nazvanie, Adres, Tel_№, Kontakt)

Primary Key Vladelec_№

Klient (Klient_№, Imya, Familiya, Adres, Tel_Kl, Object_Tip, S_Max, Cena_Max )

Primary Key Klient_№

Dogovor (Dogovor_№, Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№ )

Primary Key Dogovor_№

Foreign Key Object_№ reference Object (Object_№) on delete RESTRICT on update CASCADE

Foreign Key Rab_№ reference Rabotnik (Rab_№) on delete SET NULL on update CASCADE

Foreign Key Klient_№  reference Klient (Klient_№) on delete RESTRICT on update CASCADE

Objyavlenie (Objyavlenie_№, Data, Cena, Object_№, SMI_№ )

Primary Key Objyavlenie_№

Foreign Key Object_№ reference Object (Object_№) on delete RESTRICT on update CASCADE

Foreign Key SMI_№ reference SMI (SMI_№) on delete RESTRICT on update CASCADE

SMI (SMI_Imya, Adres, Tel_№, Kontakt )

Primary Key SMI_№

Alternate Key Tel_№

Osmotr (Data_Os, Kommentarii, Klient_№, Object_№ )

Primary Key Klient_№, Object_№, Data_Os

Foreign Key Object_№ reference Object (Object_№) on delete RESTRICT on update CASCADE

Foreign Key Klient_№  reference Klient (Klient_№) on delete CASCADE on update CASCADE

Sobesedovanie (Data_Sob, Kommentarii, Rab_№, Klient_№ )

Primary Key Klient_№, Rab_№, Data_Sob

Foreign Key Rab_№ reference Rabotnik (Rab_№) on delete RESTRICT on update CASCADE

Foreign Key Klient_№  reference Klient (Klient_№) on delete CASCADE on update CASCADE

3.5.5. Требования данного предприятия

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

Бизнес-правила для представления Менеджер приложения Реалтэкс

  1.  Каждый менеджер в любой момент времени должен руководить работой не менее четырех, но и не более восьми рядовых сотрудников.
  2.  Каждый агент в любой момент времени может вести не менее 5, но не более 15 клиентов.
  3.  Период между датой заключения договора и датой внесения аванса не может быть больше 10 рабочих дней.
  4.  Период между датой заключения договора и предполагаемой датой окончания не может быть больше 6 месяцев.
  5.  Цена одного рекламного объявления не должна превышать 2800 руб.

3.5.6. Документирование всех ограничений целостности данных

Все установленные требования поддержки целостности данных для локальной модели данных пользователя Менеджер должны быть детально отображены в документации.

3.6. Обсуждение разработанных локальных логических моделей данных с конечными пользователями

Н этом этапе проводится окончательная проверка локальной логической модели данных пользователя Менеджер, осуществляемая посредством обсуждения ее с пользователями. Очень важно, чтобы модель правильно отражала то представление о реальной деловой обстановке, которое имеет тип пользователей, названный Менеджер. Основным объектом обсуждения для разработчиков и пользователей является ER-диаграмма. Однако не менее важно, чтобы пользователи внимательно ознакомились с сопроводительной документацией. Если в модели или документации будет найдено какое-либо несоответствие, все необходимые этапы должны быть пройдены еще раз.

Окончательный вариант логической модели данных для пользователя Менеджер приложения Реалтэкс включает ER-диаграмму, показанную на рис 3.1.7 и документацию, содержащую исчерпывающее описание всех компонентов данной модели.

PAGE  28


 

А также другие работы, которые могут Вас заинтересовать

76383. Основания приобретения гражданства 34.5 KB
  Основания приобретения гражданства РФ: 1 по рождению; 2 в результате приема в гражданство РФ; 3 в результате восстановления в гражданстве РФ; 4 по иным основаниям. По рождению гражданство приобретается если на день рождения ребенка: 1 оба его родителя или единственный его родитель являются гражданами РФ; 2 один из его родителей имеет гражданство РФ а другой родитель является лицом без гражданства или признан безвестно отсутствующим или место его нахождения неизвестно; 3 один из его родителей имеет гражданство РФ а другой родитель...
76384. Основаяния и порядок прекращения гражданства 35 KB
  Основания и порядок прекращения гражданства. Основания прекращения гражданства РФ: 1 выход из гражданства РФ; 2 иные основания предусмотренные федеральным законодательством или международными договорами РФ. Выход из гражданства РФ– свободное волеизъявление гражданина РФ. Выход их гражданства РФ осуществляется на основании заявления гражданина РФ если он постоянно проживает на территории.
76385. Основания прекращения полномочий Президента. Процедура отрешения его от должности 32 KB
  Основания прекращения полномочий Президента. 92 предусматривает несколько оснований прекращения полномочий Президента РФ. Полномочия Президента РФ могут быть прекращены досрочно: 1 по инициативе самого Президента РФ в случае его отставки; 2 по не зависящим от воли Президента РФ причинам в случае.стойкой неспособности Президента РФ по состоянию здоровья осуществлять принадлежащие ему полномочия; 3 по инициативе Федерального Собрания в случае принятия им решения об отрешении Президента РФ от должности.
76386. Администрация Президента РФ 38 KB
  Администрация формируется в целях: обеспечения реализации Президентом Российской Федерации полномочий главы государства; осуществления контроля за исполнением решений Президента Российской Федерации; подготовки предложений Президенту Российской Федерации о мерах направленных на охрану суверенитета Российской Федерации ее независимости и государственной целостности; разработки общей стратегии внешней политики Российской Федерации обеспечения реализации Президентом Российской Федерации его полномочий по руководству внешней политикой...
76390. Конституционный Суд РФ. Полномочия судьи Конституционного Суда Российской Федерации 57 KB
  Конституционный Суд Российской Федерации состоит из девятнадцати судей назначаемых на должность Советом Федерации по представлению Президента Российской Федерации. Конституционный Суд Российской Федерации вправе осуществлять свою деятельность при наличии в его составе не менее трех четвертей от общего числа судей. Полномочия Конституционного Суда Российской Федерации не ограничены определенным сроком. Конституционный Суд Российской Федерации рассматривает и разрешает дела в пленарных заседаниях и заседаниях палат Конституционного Суда...