Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Пис пис пис!.docx
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
1.96 Mб
Скачать
  1. Первый этап проектирования бд (характеристика подэтапов).

Этап 1. …локальной модели… каждого из типов пользователей.

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

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

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

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

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

1. извлечь существительные

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

(Альтернатива) объекты, существующие независимо от других

Документирование типов сущностей

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

Цепь - Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе

выбираются все выражения, в которых содержатся глаголы.

Подразделение имеет персонал.

Персонал занимается объектами недвижимости.

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

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

Использование средств ER-моделирования

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

Цепь - Связывание атрибутов с соответствующими типами сущностей или связей.

"Какую информацию требуется хранить о...".

Атрибуты простые и составные

Производные атрибуты (могут опускаться)

Кажется, что один атрибут принадлежит двум сущностям

Документирование аирибутов

Сведения о атрибутах

имя атрибута и его описание;

любые псевдонимы, или синонимы, имеющиеся для данного атрибута;

тип данных и размерность значения;

значение, принимаемое для атрибута по умолчанию (если таковое имеется);

является ли атрибут обязательным (т.е. может ли он отсутствовать или иметь значение NULL);

является ли атрибут составным и, если это так, из каких простых атрибутов он состоит;

является ли данный атрибут производным и, если это так, какой метод следует использовать для вычисления его значения;

является ли данный атрибут множественным.

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

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

Домены должны содержать следующие данные:

набор допустимых значений для атрибута;

сведения о размере и формате каждого из полей атрибутов.

сведения о допустимых операциях со значениями атрибута,

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

Документирование доменов атрибутов

Этап 1.5. Определение потенциальных и первичного ключей

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

Потенциальный ключ слабой сущности

Выбор первичного ключа

с минимальным набором атрибутов.

вероятность изменения значений мала.

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

значения которого имеют минимальную длину

будет проще пользователю

Документирование

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

Цель - Определение суперклассов и подклассов для типов сущностей (если это необходимо).

Этап 1.7. Создание диаграммы „сущность-связь"

Цель Разработка диаграмм "сущность-связь" (ER-диаграмм), содержащих концептуальное отражение представлений пользователя о предметной области приложения.

Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями

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