p align="left">Таблица №4 Домены атрибутов|
Домен | Атрибут | Тип данных | Ограничения | Примеры значений | | Наименование | Подразделения | Символьный(70) | | Служба качества | | | документа | | | Управление документацией | | Номер | Подразделения | Целый | | | | | документа | Символьный(7) | | 4.2.3 | | | проверки | Целый | | | | ФИО | Директора подразделения | Символьный(20) | | Иванов И.И. | | | Работника | | | | | Имя | пользователь | Символьный(20) | | SYSDBA | | Дата | Принятия электронного документа, нормативного, внутреннего | Date | Не позднее текущей | | | | Проверки | | Текущая, или раньше текущей даты | | | | | | Не раньше текущей | | | | | | | | | | Изменения электронного документа, нормативного, внутреннего | | Текущая, или раньше текущей даты | | | | Доступа в протоколе работы | | текущая | | | Описание | Характера изменений электронного документа, нормативного, внутреннего | Символьный(30) Символьный(1000) | | Изменены страницы 2,5,9 | | | Несоответствий в проверках СМК | | | Описание процессов жизненного цикла продукции не соответствует требованиям нормативной документации, пункт 7.1 | | Тематика | электронного документа, нормативного, внутреннего | Символьный (30) | | Дирекция. Планово - экономический отдел. | | Статус | электронного документа, нормативного, внутреннего | Символьный(10) | | Изменен. Удален. На коррекцию. | | Вид несоответствия | В проверках СМК | Символьный (15) | Значительное. Незначительное. | | | |
Таблица №5 Ключи |
Сущность | ПК | Альтернативный ключ | | | | | | Подразделение | Номер | Название | | | | | | Директор службы качества | Имя пользователя | Ф.И.О. | | Работники | Имя пользователя | Ф.И.О. | | | | | | Электронный документ | Наименование документа + Номер по классификатору | | | Нормативный документ СМК | | | | Внутренний документ СМК | | | | | | | | | | | | | | | Протокол работы | Дата-время | | | | | | Проверки СМК | Номер проверки | | | | | | | | | | | |
Специализация / генерализация Преобразуем сущность «электронный документ» в суперкласс. Подклассами будут являться «нормативный документ СМК», «внутренний документ СМК». Подклассы не пересекаются, участие суперкласса полное. ER - модель
3. Логическое проектирование Предполагается использование реляционной модели данных. Необходимо избавиться от структур концептуальной модели, не реализуемых в рамках реляционной модели. Удаляем связь «Директор службы качества работает с электронными документами», т.к. эта связь является транзакцией. Скорректированная ER-модель
Определение набора отношений Объединим подклассы «нормативный документ СМК» и «внутренний документ СМК» в одно отношение «Электронный документ», т.к. все экземпляры сущностей обоих подклассов имеют одинаковые атрибуты. Также для этого отношения необходимо определить новый атрибут «вид документа» для того, чтобы идентифицировать, к какому подклассу относится документ. 1. Директор службы качества (Ф.И.О., имя пользователя, дата вступления в должность) ПК : имя пользователя 2. Проверки (№ проверки, дата, описание несоответствия, вид несоответствия, Ф.И.О. , № подразделения) ПК: № проверки ВК: имя пользователя директора службы качества Директор службы качества ВК: номер подразделения Подразделения 3. Подразделения (№ подразделения, название, Ф.И.О. директора подразделения) ПК: номер 4. Работники (Ф.И.О., имя пользователя, номер подразделения) ПК: имя пользователя ВК : номер Подразделения 5. Протокол работы (наименование документа, номер по классификатору, дата-время доступа, Ф.И.О., имя пользователя) ПК: дата-время ВК: наименование док-та + номер по классификатору Электронные документы ВК: имя пользователя Работники 6. Электронные документы (наименование документа, номер по классификатору, дата принятия, дата изменения, тематика, статус, характер изменений, вид документа) ПК: наименование док-та + номер по классификатору Проверка отношений на соответствие требованиям нормализации: 2 НФ 1. Ф.И.О. дата вступления в должность Ф.И.О. имя пользователя имя пользователя Ф.И.О. имя пользователя дата вступления в должность 2. № проверки дата проверки № проверки описание несоответствия № проверки вид несоответствия 3. № название подразделения № Ф.И.О. директора подразделения название подразделения № название подразделения Ф.И.О. директора подразделения 4. Ф.И.О. имя пользователя имя пользователя Ф.И.О. 5. собственный атрибут только один - «дата-время» 6. Наименование документа + номер по классификатору дата принятия Наименование документа + номер по классификатору тематика Наименование документа + номер по классификатору статус Наименование документа + номер по классификатору характер изменений Наименование документа + номер по классификатору дата изменения 3 НФ Транзитивные зависимости отсутствуют, значит, отношения соответствуют 3НФ. НФБК В отношениях 1-5 ПК состоит из одного атрибута, а в отношении 6 отсутствуют несколько составных потенциальных ключей, пересекающихся по набору атрибутов. Следовательно, все отношения соответствуют НФБК, что гарантирует отсутствие проблем обновления. Полученная ER-модель (стр. 15) позволяет реализовать все транзакции, изложенные в постановке задачи. Требования, обеспечивающие ссылочную целостность 1) Для всех первичных ключей устанавливается значение NOT NULL. 2) Атрибуты, которые допускают NULL: Ш Отношение «Проверки» Атрибуты: описание несоответствия, вид несоответствия Ш Отношение «Протокол работы» Атрибуты, которые являются ВК: ФИО, Наименование документа + номер по классификатору Ш Отношение «Электронные документы» Атрибуты: Дата изменения, статус, тематика, характер изменения 3) Для всех ВК: ON UPDATE CASCADE ON DELETE NO ACTION Кроме ВК в отношении «Протокол работы»: ON UPDATE CASCADE ON DELETE CASCADE 4) Бизнес-правила: Директор службы качества имеет полный доступ ко всей информации в БД, все остальные работники имеют ограниченный доступ, а именно, просмотр документов в режиме чтения. 4. Физическое проектирование Директор службы качества |
ФИО(*) | Имя пользователя | Дата вступления в должность | | | | | | |
Страницы: 1, 2, 3, 4, 5
| 
