Смекни!
smekni.com

Методология проектирования баз данных 2 2 (стр. 2 из 4)

Сущность ПК Альтернативный ключ
Подразделение Номер Название
Директор службы качества Имя пользователя Ф.И.О.
Работники Имя пользователя Ф.И.О.
Электронный документ Наименование документа +Номер по классификатору
Нормативный документ СМК
Внутренний документ СМК
Протокол работы Дата-время
Проверки СМК Номер проверки

Специализация / генерализация

Преобразуем сущность «электронный документ» в суперкласс. Подклассами будут являться «нормативный документ СМК», «внутренний документ СМК». Подклассы не пересекаются, участие суперкласса полное.

ER– модель

3. Логическое проектирование

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

Удаляем связь «Директор службы качества работает с электронными документами», т.к. эта связь является транзакцией.

Скорректированная ER-модель

Определение набора отношений

Объединим подклассы «нормативный документ СМК» и «внутренний документ СМК» в одно отношение «Электронный документ», т.к. все экземпляры сущностей обоих подклассов имеют одинаковые атрибуты. Также для этого отношения необходимо определить новый атрибут «вид документа» для того, чтобы идентифицировать, к какому подклассу относится документ.

1.Директор службы качества (Ф.И.О., имя пользователя, дата вступления в должность) ПК : имя пользователя

2. Проверки (№ проверки, дата, описание несоответствия, вид несоответствия, Ф.И.О. , № подразделения)

ПК: № проверки

ВК: имя пользователя директора службы качества

Директор службы качества

ВК: номер подразделения

Подразделения

3. Подразделения (№ подразделения, название, Ф.И.О. директора подразделения) ПК: номер

4. Работники (Ф.И.О., имя пользователя, номер подразделения)

ПК: имя пользователя

ВК : номер

Подразделения

5. Протокол работы (наименование документа, номер по классификатору, дата-время доступа, Ф.И.О., имя пользователя)

ПК: дата-время

ВК: наименование док-та + номер по классификатору

Электронные документы

ВК: имя пользователя

Работники

6. Электронные документы (наименование документа, номер по классификатору, дата принятия, дата изменения, тематика, статус, характер изменений, вид документа)

ПК: наименование док-та + номер по классификатору

Проверка отношений на соответствие требованиям нормализации:

2 НФ

1. Ф.И.О.

дата вступления в должность

Ф.И.О.

имя пользователя

имя пользователя

Ф.И.О.

имя пользователя

дата вступления в должность

2. № проверки

дата проверки

№ проверки

описание несоответствия

№ проверки

вид несоответствия

3. №

название подразделения

Ф.И.О. директора подразделения

название подразделения

название подразделения

Ф.И.О. директора подразделения

4. Ф.И.О.

имя пользователя

имя пользователя

Ф.И.О.

5. собственный атрибут только один – «дата-время»

6. Наименование документа + номер по классификатору

дата принятия

Наименование документа + номер по классификатору

тематика

Наименование документа + номер по классификатору

статус

Наименование документа + номер по классификатору

характер изменений

Наименование документа + номер по классификатору

дата изменения

3 НФ

Транзитивные зависимости отсутствуют, значит, отношения соответствуют 3НФ.

НФБК

В отношениях 1-5 ПК состоит из одного атрибута, а в отношении 6 отсутствуют несколько составных потенциальных ключей, пересекающихся по набору атрибутов. Следовательно, все отношения соответствуют НФБК, что гарантирует отсутствие проблем обновления.

Полученная ER-модель (стр. 15) позволяет реализовать все транзакции, изложенные в постановке задачи.

Требования, обеспечивающие ссылочную целостность

1) Для всех первичных ключей устанавливается значение NOTNULL.

2) Атрибуты, которые допускают NULL:

- Отношение «Проверки»

Атрибуты: описание несоответствия, вид несоответствия

- Отношение «Протокол работы»

Атрибуты, которые являются ВК: ФИО, Наименование документа + номер по классификатору

- Отношение «Электронные документы»

Атрибуты: Дата изменения, статус, тематика, характер изменения

3) ДлявсехВК: ON UPDATE CASCADE ON DELETE NO ACTION

Кроме ВК в отношении «Протокол работы»:

ON UPDATE CASCADE ON DELETE CASCADE

4) Бизнес-правила:

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

4. Физическое проектирование

Директор службы качества

ФИО(*) Имя пользователя Дата вступления в должность

Проверки

№ проверки(*) Дата Описание несоответствия Вид несоответствия ФИО № подразделения

Подразделения

Номер(*) Названия ФИО директора подразделения

Работники

Номер(*) ФИО Имя пользователя № подразделения

Протокол работы

Номер(*) Дата-время доступа № работника № документа

Электронные документы

Вид документа № по классификатору Наименование документа Дата принятия Дата изменения Статус Тематика Характер изменения № документа

Архив удаленных документов

№ по классификатору Наименование документа Дата принятия Дата удаления Тематика Характер изменения Вид документа Номер (*)

Создание вторичных индексов:

Таблица «Работники»: поле «Имя пользователя»

Таблица «Электронные документы»: поле («Наименование» + «№ по классификатору»)

Доступ:

Директор службы качества и администратор – полный доступ, а все остальные – просмотр документов в режиме чтения.