База данных для агентства недвижимости "Реалтэкс"

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 27.10.2017
Размер файла 769,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

63

Размещено на http://www.allbest.ru/

Содержание

  • 1. Описание предметной области. Спецификация требований
  • 1.1 Требования к данным
  • 1.2 Требования к транзакциям
  • 2. Построение локальной концептуальной модели данных
  • 2.1 Определение типов сущностей
  • 2.2 Определение типов связей
  • 2.3 Определение кардинальности и уровня участия отдельных типов связи
  • 2.4 Определение атрибутов и связывание их с типами сущностей и связей
  • 2.5 Определение атрибутов, являющихся потенциальными и первичными ключами
  • 2.6 Определение доменов атрибутов
  • 2.7 Специализация/генерализация типов сущностей
  • 2.8 Создание диаграммы "сущность-связь"
  • 2.9 Обсуждение локальной концептуальной модели с пользователем
  • 3. Построение и проверка локальной логической модели данных
  • 3.1 Преобразование концептуальной модели данных в логическую модель
  • 3.1.1 Удаление связей типа M: N
  • 3.1.2 Удаление сложных связей
  • 3.1.3 Удаление рекурсивных связей
  • 3.1.4 Удаление множественных атрибутов
  • 3.1.5 Перепроверка связей типа 1: 1
  • 3.1.6 Удаление избыточных связей
  • 3.1.7 Создание диаграммы "сущность-связь"
  • 3.2 Определение набора отношений исходя из структуры локальной логической модели данных
  • 3.3 Проверка модели с помощью правил нормализации
  • 3.4 Проверка модели в отношении транзакций пользователей
  • 3.5 Определение требований поддержки целостности данных
  • 3.5.1 Обязательные данные
  • 3.5.2 Ограничения для доменов атрибутов
  • 3.5.3 Целостность таблицы
  • 3.5.4 Ссылочная целостность
  • 3.5.5 Требования данного предприятия
  • 3.5.6 Документирование всех ограничений целостности данных
  • 3.6 Обсуждение разработанных локальных логических моделей данных с конечными пользователями

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-диаграммы посредством применения процедуры генерализации или специализации сущностей. При проведении специализации предпринимаются попытки выделить различия между сущностями. В противоположность этому при проведении генерализации осуществляется поиск общих характеристик сущностей различных типов.

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

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

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

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

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

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

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

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


Подобные документы

  • Построение концептуальной модели, процесс моделирования смыслового наполнения базы данных. Основные компоненты концептуальной модели. Построение реляционной модели. Целостность данных в реляционной базе. Нормализация. Проектирование базы данных в ACCESS.

    курсовая работа [1,8 M], добавлен 29.10.2008

  • Учет книжного фонда библиотеки. Разработка концептуальной модели данных. Составление спецификации атрибутов и связей, генерация в системе PowerDesigner физической модели по концептуальной модели. Создание скрипта создания базы данных для СУБД FireBird.

    контрольная работа [784,2 K], добавлен 10.04.2014

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

    курсовая работа [185,6 K], добавлен 08.11.2008

  • Построение концептуальной модели. Проектирование реляционной модели данных на основе принципов нормализации: процесс нормализации и глоссарий. Проектирование базы данных в Microsoft Access: построение таблиц, создание запросов в том числе SQL – запросов.

    курсовая работа [35,9 K], добавлен 08.11.2008

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

    курсовая работа [2,6 M], добавлен 12.12.2011

  • Системный анализ предметной области. Построение концептуальной и даталогичной модели базы данных. Физическое проектирование базы данных. Описание функциональной модели системы управления базами данных. Разработка экранных форм ввода-вывода и отчета.

    курсовая работа [1,1 M], добавлен 09.12.2014

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

    курсовая работа [1,5 M], добавлен 31.03.2015

  • Разработка информационно-аналитической системы агентства недвижимости. Обоснование выбора архитектуры базы данных и СУБД. Моделирование потоков данных (DFD диаграмм). Проектирование инфологической модели данных с использованием модели "сущность-связь".

    дипломная работа [5,4 M], добавлен 06.06.2013

  • Разработка концептуальной модели базы данных "Чемпионат авто": описание предметной области, каталог задач, описание таблиц, схема данных, ER-диаграмма. Проектирование реляционной модели "Спортивный комплекс". Реализация и результат работы базы данных.

    курсовая работа [3,7 M], добавлен 14.06.2011

  • Описание предметной области. Характеристика этапов разработки концептуальной модели данных для предметной области "Библиотека" с использованием CASE-средства ER Win. Методика преобразования концептуальной модели в физическую структуру базы данных (БД).

    курсовая работа [2,4 M], добавлен 23.09.2014

  • Построение инфологической (концептуальной) модели предметной области. Проектирование логической и физической структуры базы данных. Реализация проекта в среде конкретной СУБД. Организация корректировки и ввода данных в БД. Разработка интерфейса.

    курсовая работа [1,4 M], добавлен 14.01.2018

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

    курсовая работа [1,7 M], добавлен 18.01.2012

  • Проектирование базы данных для автоматизированной системы "Склад". Разработка концептуальной модели (ER-диаграмма). Преобразование в реляционную модель и ее нормализация. Разработка запросов к базе данных на языке SQL. Скрипт для создания базы данных.

    курсовая работа [161,8 K], добавлен 07.10.2013

  • Построение инфологической концептуальной модели предметной области. Структура базы данных Microsoft Office Access. Формы, запросы и отчеты. Создание форм, запросов и отчетов в базах данных. Схема данных физической и логической сущности в Erwin 4.0.

    курсовая работа [5,1 M], добавлен 13.12.2011

  • Особенности проектирования программы на языке С++ для обработки данных из таблиц базы данных. Основные функции программы, создание концептуальной модели базы данных и диаграммы классов, разработка интерфейса пользователя и запросов к базе данных.

    курсовая работа [2,1 M], добавлен 08.06.2012

  • Модели данных в управлении базами данных. Концептуальные модели данных. Роль баз данных в информационных системах. Реляционная модель данных. Определение предметной области. Построение модели базы данных для информационной системы "Домашние животные".

    курсовая работа [1,9 M], добавлен 19.04.2011

  • Функции системы управления базами данных Microsoft Access. Построение концептуальной модели. Физическая модель базы данных. Форма "Сведения о студенте". Каскадное отображение таблиц. Мастер и конструктор запросов. Результат вывода отчета "Ведомость".

    курсовая работа [2,2 M], добавлен 05.04.2015

  • Создание базы данных, где будет храниться, обрабатываться вся необходимая информация. Построение с помощью CASE-средства Microsoft Visio концептуальной модели, дающая возможность отображения всех выделенных сущностей, их атрибутов и связи между ними/

    курсовая работа [514,4 K], добавлен 29.11.2008

  • Информационная система на базе компьютера. Основное отличие системы с базой данных от традиционной файловой системы. Построение концептуальной модели, реляционной модели. Нормализация. Проектирование базы данных в ACCESS. Создание SQL запросов.

    курсовая работа [38,5 K], добавлен 06.11.2008

  • Система управления базой данных (СУБД), централизованное обеспечение безопасности и целостности данных, защита от несанкционированного доступа. Построение концептуальной и реляционной моделей. Процесс нормализации. Проектирование базы данных в ACCESS.

    курсовая работа [1,8 M], добавлен 29.10.2008

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.