Сущность | ПК | Альтернативный ключ |
Подразделение | Номер | Название |
Директор службы качества | Имя пользователя | Ф.И.О. |
Работники | Имя пользователя | Ф.И.О. |
Электронный документ | Наименование документа +Номер по классификатору | |
Нормативный документ СМК | ||
Внутренний документ СМК | ||
Протокол работы | Дата-время | |
Проверки СМК | Номер проверки |
Специализация / генерализация
Преобразуем сущность «электронный документ» в суперкласс. Подклассами будут являться «нормативный документ СМК», «внутренний документ СМК». Подклассы не пересекаются, участие суперкласса полное.
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. Физическое проектирование
Директор службы качества
ФИО(*) | Имя пользователя | Дата вступления в должность |
Проверки
№ проверки(*) | Дата | Описание несоответствия | Вид несоответствия | ФИО | № подразделения |
Подразделения
Номер(*) | Названия | ФИО директора подразделения |
Работники
Номер(*) | ФИО | Имя пользователя | № подразделения |
Протокол работы
Номер(*) | Дата-время доступа | № работника | № документа |
Электронные документы
Вид документа | № по классификатору | Наименование документа | Дата принятия | Дата изменения | Статус | Тематика | Характер изменения | № документа |
Архив удаленных документов
№ по классификатору | Наименование документа | Дата принятия | Дата удаления | Тематика | Характер изменения | Вид документа | Номер (*) |
Создание вторичных индексов:
Таблица «Работники»: поле «Имя пользователя»
Таблица «Электронные документы»: поле («Наименование» + «№ по классификатору»)
Доступ:
Директор службы качества и администратор – полный доступ, а все остальные – просмотр документов в режиме чтения.