- •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. Обсуждение разработанных локальных логических моделей данных с конечными пользователями
Документирование типов связей
В документацию следует поместить подробную информацию обо всех связях, включая сведения о кардинальности и степени участия ее членов.
Таблица 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. Атрибуты, принадлежащие связям
|
Тип связи |
Атрибут |
|
Осматривает |
Дата_Осмотра(Дата осмотра объекта клиентом)
Комментарии
|