Второй этап проектировании БД (задачи и подэтапы)



Логическое проектирование базы данных (для реляционной модели)

Этап 2. Построение и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей.

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

Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных.

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

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

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

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

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

Задача второго этапа

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

oудаляются нежелательные элементы, затрудняющие реализацию моделей данных в среде реляционных СУБД.

oкорректность логических моделей данных проверяется с помощью правил нормализации.

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

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

 

Третий этап проектирования БД (задачи и подэтапы)

Логическое проектирование базы данных (для реляционной модели)

Этап 3. Создание и проверка глобальной логической модели данных.

Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных.

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

Этап 3.3. Проверка возможностей расширения модели в будущем.

Этап 3.4. Создание окончательного варианта диаграммы "сущность-связь".

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

Задачей третьего этапа

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

 

Первый этап проектирования БД (характеристика подэтапов).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


Дата добавления: 2018-02-15; просмотров: 950; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!