- •Основы бд
- •1. Основные понятия, термины.
- •2. Модели данных.
- •3. Иерархическая модель.
- •4. Сетевая модель.
- •5. Реляционная модель
- •Операции реляционной алгебры
- •Реляционное исчисление кортежей
- •Проектирование схем реляционной бд
- •1. Основные положения
- •2. Избыточность данных и аномалии обновления
- •3. Функциональная зависимость
- •4. I нормальная форма
- •5. II нормальная форма
- •7. Нормальная форма Бойса-Кодда
- •8. Обзор процесса нормализации
- •9. Многозначные зависимости
- •Методология проектирования бд
- •Основные понятия.
- •Методология концептуального проектирования.
- •Методология логического проектирования.
- •1. Основные понятия.
- •2. Методология концептуального проектирования
- •3. Методология логического проектирования
- •4. Методология физического проектирования бд
- •Пример проектирования бд
- •Пример физического проектирования бд
- •2. Управление транзакций
- •3. Обработка запросов
Пример проектирования бд
Проектирование БД основывается на конкретном представлении пользователя и формируется на основе требований, которые предъявляются к данным и транзакциям.
В данном случае фаза сборах и анализа требований к данным и транзакциям осуществляется в офисе отделения компании об объектах работы недвижимости. Будут рассматриваться представления пользователя – это сотрудник, который работает в должности инспектора.
На основе опроса сотрудника могут формироваться спецификации, требования для представления инспектора, в которых тестируются требования к данным и определяются транзакции, которые необходимы инспекторам для выполнения их служебных обязанностей.
Требования к данным
В каждом отделении компании имеется персонал, который занимается сдачей в аренду недвижимости. Весь персонал делится на группы, управление которого получено инспектором.
Отделение компании представлено следующей информацией: уникальный номер отделения, адрес (составной атрибут), №_тел, №_факса.
Сотрудник характеризуется: №_личный, имя, фамилия, адрес, №_тел., sex, дата рождения, должность информации об отделении, в которой работает, дополнительная информация.
Инспектор руководит отдельной группой сотрудников от 10 человек, каждый сотрудник из этой группы отвечает минимум за 10 объектов.
Объект: №_объекта, адрес, тип_объекта, количество_комнат, ежемесячная_оплата, имя, адрес вдажельца объекта, размер ежемесячной платы ежегодно пересматривается.
владельцы могут быть частные и юридические лица. Если частное, то характеризуется №, ФИО, адресом и №_тел.. ,ридичесоке лицо: №, наименование компании, тип компании, адрес, №-тел., имя представителя. Каждый владельцу принадлежит объект.
Персонал:
обеспечение постоянной заинтересованности каждого сдаваемого объекта в аренду. Для этого публикуются объявления: № объявления, дата публикации, название газеты, стоимость объявления, информация об объекте. Номер объявления считается уникальным в пределах всех отделениях компании. По каждому газетному изданию также надо хранить информацию: название газкты, адрес, № телефона, № факса, имя представителя. Объявления необходимо печатать, если задерживается сдача объекта в аренду.
Проводить собоседование с клиентами: №, ФИО, адрес, № телефона, сведения о желаемых характеристиках объекта.
Знакомство клиентов с создаваемыми объектами: в один день каждый из клиентов может посещать объект только один раз.
Оформление соглашений об аренде некоторого объекта. Соглашение может оформляться от 3 месяцев до года.
Проводить регулярные инспектирование состояния объекта.
Спецификация требований к транзакциям.
Составление списка работников для заданного инспектора.
Составление списка работников, которые обслуживаются данным секретарем.
Создание и корректировка сведений о сдаваемых объектах.
Формирование отчета об сдаваемых объектах.
Формирование списка объектов, закрепленных за конкретным сотрудником.
Сведения о клиентах.
Поиск объекта по заданным условиям создание и корректировка сведений о результатах собеседований.
Список всех объявлений.
Сведения о заключаемых соглашениях
Сведения об инспекции объектах.
Сущности обычно из спецификаций выбираются существующие и определяющие как сущности:
Отделение – Branch;
Работник – Staff;
Инспектор – Supervisor
Секретарь – Secretary;
Объект недвижимости - Property for Rent;
Владелец – частное лицо – private owner;
Владелец – юридическое лицо – Business owner;
Объявления – Advert;
Газета – New paper
Собеседование – Interview;
Клиент – client;
Договор об аренде – Lease agreement;
Инспекция – Inspection.
После того, как выделили сущности, необходимо выполнить документирование каждой сущности. Обычно она предоставляется в виде следующей таблицы:
Таблица 1. Документация сущностей
Имя сущности |
Описание |
псевдоним |
Особенность использования |
Supervisor |
Руководит работой персонала по сдаче в аренду объектов недвижимости |
|
Руководит группой о 5 до 10 человек |
Выделим типы связей.
Таблица 2. Основные типы связей.
Тип сущности |
Тип связи |
Тип сущности |
Branch |
Has (имеет) |
Staff |
Staff |
|
Supervisor Secretary Property for Rent interview Lease agreement Inspection |
Supervisor |
Supervised |
Staff |
Secretary |
|
|
Property for Rent |
Is available Managed by Owner by |
Branch Staff Owner |
private owner |
Ows |
Property for Rent |
Business owner |
Ows |
Property for Rent |
Advert |
Desribed Place In |
Property for Rent Newspaper |
New paper |
|
|
Interview |
With |
Client |
client |
View Rents Holds |
Property for Rent Lease agreement |
Lease agreement |
Attached to |
Property for Rent |
Inspection |
Mode of |
Property for Rent |
Необходимо для каждой связи определить кардинальность и уровень участия каждой сущности:
Branch Has Staff
Поскольку каждый из отделений компании имеет несколько сотрудников кардинальность 1:N. Поскольку каждое отделение имеет персонал, то степень участия – полная.
Property for Rent Managed by Staff
За каждый сдаваемый в аренду объект отвечает сотрудник. Кардинальность 1:1. Степень участия – полная.
Staff Manages Property for Rent
Кардинальность -1:N. Степень участия – частичная, т.к. не все сотрудники – инспектора.
После описания типов связей, кардинальности и степени участия, составляют начальный вариант ER-диаграммы. После составления ER-диаграммы, необходимо выделить атрибуты сущностей, а также атрибуты связей.
Таблица 3. Атрибуты сущностей.
Тип сущностей |
Атрибуты |
Branch |
Branch № Address ( PostCode, city, street) Tel № Fax № |
Таблица 4. Атрибуты связей.
Тип связей |
Атрибут |
views |
Date_View Commets |
Следующий шаг состоит в определении доменов атрибутов, необходимо проанализировать те атрибуты, множество допустимых значений, которые имеют какие-то особенности или ограничения. Например, сущность branch имеет атрибут Branch №. Но значение накладывает следующее ограничение: длина не более 3-х символов – от «В01» до «В99».
Иногда бывают домены, которые являются множеством допустимых значений для различных сущностей. Примером такого атрибута является адрес.
Далее необходимо определить первичные или альтернативные ключи.
Таблица 5. Первичные и альтернативные ключи.
Branch |
Branch № |
Fax № |
Supervisor |
- |
Т.к. сущности являются слабые, то для таких сущностей ключи определены на этапе логического проектирования |
Interview |
- |
Необходимо выполнить специализацию типов сущностей. На этом шаге принимаются меры по улучшению исходного варианта ER- диаграммы. При проведении спецификации применяются попытки выделить различия между сущностями. В противоположном случае, этой процедуре при генерации осуществляется поиск общих характеристик сущностей различных типов.
Сущности:
Supervisor и Secretary – представляют различные типы сущностей для них имеет смысл выполнить генерацию в подкласс суперкласса Staff, либо можно оставить их как независимые сущности.
Атрибуты сущности сотрудник, включая и первичный ключ, присутствуют в сущности инспектор (Supervisor) и в сущности секретарь (Secretary). Но Secretary есть еще скорость набора. Сущности принимают участия в различных связей.
Связи, которые поддерживают суперкласс с каждым из своих подклассов являются частичными и непересекающимися.
В качестве еще одного примера можно привести сущности Владельца (Owner) – private Owner и Business Owner. Эти сущности имеют много общих атрибутов, поэтому целесообразно для этих сущностей выполнить генерацию и выделить суперкласс Owner и его подклассы.
При проведении генерации или спецификации сущностей следует руководствоваться требованиями ясности и читаемости важной сущности и связей. Поэтому в заключении ER-диаграммы надо будет внести изменения касающиеся сущностей суперкласса и подкласса.