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

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

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

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

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

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

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

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

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

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

 

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

Этап 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Цель Обсуждение локальных концептуальных моделей данных с конечными пользователями с целью получения подтверждений, что данная модель корректно отражает представления пользователя о приложении и предприятии.

 

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

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

Процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий.

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

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

Этап 2

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

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

Этап 2.1

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

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

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

 

Этап 2.2

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

Цель - Определение набора отношений на основе локальной логической модели данных.

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

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

■ приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов;

■ приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;

■ приведение к третьей нормальной форме (ЗНФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;

■ приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.

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

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

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

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

Два подхода проверки соответствия логической модели

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

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

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

oЦель Создание окончательного варианта диаграмм "сущность-связь" (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.

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

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

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

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

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

пять типов ограничений целостности данных

■ обязательные данные;

■ ограничения для доменов атрибутов;

■ целостность сущностей;

■ ссылочная целостность;

■ требования данного предприятия

 

 

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

 

 

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

Этап 2

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

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

Действия Этапа 2.1

1. Удаление связей типа M:N.

2. Удаление сложных связей.

3. Удаление рекурсивных связей.

4. Удаление связей с атрибутами

.

5. Удаление множественных атрибутов.

6. Перепроверка связей типа 1:1.

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

Например, могли быть созданы две сущности, Преподаватель и Тьютер, которые на самом деле представляют один и тот же тип объекта. Другими словами, имя Преподаватель является синонимом имени Тьютер.

7. Удаление избыточных связей.

Этап 2.2

ГОСТ (СТ СЭВ) 19.201-78, ГОСТ (СТ СЭВ) 19.101-77, ГОСТ 19.102-77.

 

 

Стандарты комплекса ГОСТ 34

 

ГОСТ 34.602-89

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

 

Таблица 2.1. Состав и содержание технического задания (ГОСТ 34.602- 89)

 

№ п\п	Раздел	Содержание
1	Общие сведения	· полное наименование системы и ее условное обозначение · шифр темы или шифр (номер) договора; · наименование предприятий разработчика и заказчика системы, их реквизиты · перечень документов, на основании которых создается ИС · плановые сроки начала и окончания работ · сведения об источниках и порядке финансирования работ · порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств
2	Назначение и цели создания (развития) системы	· вид автоматизируемой деятельности · перечень объектов, на которых предполагается использование системы · наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС
3	Характеристика объектов автоматизации	· краткие сведения об объекте автоматизации · сведения об условиях эксплуатации и характеристиках окружающей среды
4	Требования к системе	Требования к системе в целом: · требования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централизации, способы информационного обмена, режимы функционирования, взаимодействие со смежными системами, перспективы развития системы) · требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки) · показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров) · требования к надежности, безопасности, эргономике, транспортабельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации Требования к функциям (по подсистемам): · перечень подлежащих автоматизации задач · временной регламент реализации каждой функции · требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точности, достоверности выдачи результатов · перечень и критерии отказов Требования к видам обеспечения: · математическому (состав и область применения мат. моделей и методов, типовых и разрабатываемых алгоритмов) · информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам) · лингвистическому (языки программирования, языки взаимодействия пользователей с системой, системы кодирования, языки ввода- вывода) · программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ) · техническому · метрологическому · организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала) · методическому (состав нормативно- технической документации
5	Состав и содержание работ по созданию системы	· перечень стадий и этапов работ · сроки исполнения и ожидаемые результаты  · перечень организаций‑исполнителей работ · вид и порядок экспертизы технической документации · программа обеспечения надежности · программа метрологического обеспечения
6	Порядок контроля и приемки системы	· виды, состав, объем и методы испытаний системы · общие требования к приемке работ по стадиям · статус приемной комиссии
7	Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие	· преобразование входной информации к машиночитаемому виду · изменения в объекте автоматизации · сроки и порядок комплектования и обучения персонала
8	Требования к документированию	· перечень подлежащих разработке документов · перечень документов на машинных носителях
9	Источники разработки	документы и информационные материалы, на основании которых разрабатывается ТЗ и система

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

Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.

Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

· функции ИС;

· функции подсистем, их цели и ожидаемый эффект от внедрения;

· состав комплексов задач и отдельных задач;

· концепция информационной базы и ее укрупненная структура;

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

· состав технических средств;

· функции и параметры основных программных средств.

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

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

На этом этапе осуществляется комплекс проектных и, возможно, научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы. Состав и содержание технического проекта приведены в таблице 2.2.

 

Таблица 2.2. Содержание технического проекта

 

№  п\п	Раздел	Содержание
1	Пояснительная записка	· основания для разработки системы · перечень организаций разработчиков · краткая характеристика объекта с указанием основных технико-экономических показателей его функционирования и связей с другими объектами · краткие сведения об основных проектных решениях по функциональной и обеспечивающим частям системы
2	Функциональная и организационная структура системы	· обоснование выделяемых подсистем, их перечень и назначение · перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания · схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы
3	Постановка задач и алгоритмы решения	· организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими задачами, характер использования результатов решения, в которых они используются) · экономико-математическая модель задачи (структурная и развернутая форма представления) · входная оперативная информация (характеристика показателей, диапазон изменения, формы представления) · нормативно-справочная информация (НСИ) (содержание и формы представления) · информация, хранимая для связи с другими задачами · информация, накапливаемая для последующих решений данной задачи · информация по внесению изменений (система внесения изменений и перечень информации, подвергающейся изменениям) · алгоритм решения задачи (последовательность этапов расчета, схема, расчетные формулы) · контрольный пример (набор заполненных данными форм входных документов, условные документы с накапливаемой и хранимой информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с разработанным алгоритмом расчета)
4	Организация информационной базы	· источники поступления информации и способы ее передачи · совокупность показателей, используемых в системе · состав документов, сроки и периодичность их поступления · схема базы данных · предложения по унификации документации
5	Альбом форм документов
6	Система программного обеспечения	· обоснование структуры программного обеспечения · обоснование выбора системы программирования · перечень стандартных программ и систем
7	Принцип построения комплекса технических средств	· описание и обоснование схемы технологического процесса обработки данных · обоснование и выбор структуры комплекса технических средств и его функциональных групп · обоснование требований к разработке нестандартного оборудования · комплекс мероприятий по обеспечению надежности функционирования технических средств
8	Расчет экономической эффективности системы	· сводная смета затрат, связанных с эксплуатацией систем · расчет годовой экономической эффективности
9	Мероприятия по подготовке объекта к внедрению системы	· перечень организационных мероприятий по совершенствованию бизнес-процессов · перечень работ по внедрению системы, которые необходимо выполнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц
10	Ведомость документов

 

В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.

На стадии "рабочий проект (рабочая документация)" осуществляется создание программного продукта и разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.

Разрабатываются требования к испытаниям. Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. При необходимости допускается дополнительно проведение других видов испытаний системы и ее частей.

В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных частей или для системы в целом.

Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний ". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.

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

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

Приемочные испытания проводят для определения соответствия системы техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки системы в постоянную эксплуатацию.