Гущин А.Н. Информационные технологии в экономике

Подождите немного. Документ загружается.

объём БД должен уменьшиться. Принципиальным здесь является то, что

нормализация — обратимый процесс, из группы таблиц, получившихся при

декомпозиции, всегда можно получить в точности исходную таблицу. Таким

образом, нормализация не сокращает объём информации, хранимой в БД, а лишь

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

Главная цель нормализации базы данных - устранение избыточности и

дублирования информации. В идеале при нормализации надо добиться, чтобы

любое значение хранилось в базе в одном экземпляре, причем значение это не

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

Первая нормальная форма

Таблица находится в первой нормальной форме, если каждый её атрибут

атомарен и все строки различны. Под выражением "атрибут атомарен" понимается,

что атрибут может содержать только одно значение. Таким образом, не

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

приведения таблицы к 1NF обычно требуется разбить таблицу на несколько

отдельных таблиц. Пример приведения таблицы к первой нормальной форме

Исходная, ненормализованная,

таблица

Нормализованная таблица

Сотрудник Номер телефона

Иванов И.И.

283-56-82

390-57-34

Петров П.Ю. 708-62-34

Сотрудник Номер телефона

Иванов И.И. 283-56-82

Иванов И.И. 390-57-34

Петров П.Ю. 708-62-34

Если один и тот же

атрибут присутствует

более чем в одной

сущности и не

является внешним

ключом, то этот

атрибут

рассматривается как

избыточный.

Логическая модель не

должна содержать

избыточных данных.

На рисунке

представлена модель,

приведенная к первой

нормальной форме.

Добавлен

идентификатор

навыка, который

уникально определяет

каждый навык.

Вторая нормальная форма (2NF)

Таблица находится во второй нормальной

форме, если она находится в первой

нормальной форме, и при этом любой её

атрибут, не входящий в состав первичного

ключа, функционально полно зависит от

первичного ключа. Функционально полная

зависимость означает, что атрибут

функционально зависит от всего первичного

ключа, но при этом не находится в

функциональной зависимости от какой-либо

его части. Если первичный ключ не

составной, то таблица в 1NF автоматически

находится и в 2NF. Во второй нормальной

форме повторяющаяся группа вынесена в

другую сущность. Это обеспечивает гибкость

при добавлении необходимого количества

Навыков и изменении Названия навыка или

Описания навыка в одном месте.

Третья нормальная форма (3NF)

Таблица находится в третьей нормальной форме,

если она находится во второй нормальной форме,

и при этом любой её неключевой атрибут

функционально зависит только от первичного

ключа. В третьей нормальной форме Название

школы и Географический регион перенесены в

сущность, где их значения зависят от ключа.

Нормальная форма Бойса-Кодда (BCNF)

Таблица находится в BCNF, если она находится в третьей нормальной форме,

и при этом отсутствуют функциональные зависимости атрибутов первичного ключа

от не-ключевых атрибутов. Данная нормальная форма — это модификация третьей

нормальной формы. Таблица может находиться в 3NF, но не в BCNF, только в одном

случае: если она имеет, помимо первичного ключа, ещё по крайней мере один

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

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

3NF и BCNF эквивалентны.

Четвёртая нормальная форма (4NF)

Таблица находится в 4NF,

если она находится в BCNF

и не содержит

нетривиальных

многозначных

зависимостей.

Многозначная зависимость

не является

функциональной, она

существует в том случае,

когда из факта, что в

таблице содержится

некоторая строка X,

следует, что в таблице

обязательно существует

некоторая определённая

строка Y. В четвертой

нормальной форме

отношение многие-ко-

многим между ПЕРСОНОЙ и ШКОЛОЙ разрешается за счет введения

ассоциативной сущности, в которой отводится отдельная запись для каждой

уникальной комбинации ШКОЛЫ и ПЕРСОНЫ.

Пятая нормальная форма (5NF)

Таблица находится в 5NF, если она находится в 4NF и любая многозначная

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

Завершенная логическая модель данных

Завершенная логическая модель должна удовлетворять требованиям третьей

нормальной формы и включать все сущности, атрибуты и связи, необходимые для

поддержки требований к данным и бизнес-правил, ассоциированных с данными. Все

сущности должны иметь имена, описывающие содержание и ясное, краткое, полное

описание или определение. В одной из следующих публикаций будет рассмотрен

исходный набор рекомендаций для правильного формирования имен и описаний

сущностей.

Сущности должны иметь полный набор атрибутов, так, чтобы каждый факт

относительно каждой сущности мог быть представлен ее атрибутами. Каждый

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

ясное, короткое, полное описание или определение. В одной из следующих

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

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

конструкцию, которая описывает отношение между сущностями, наравне с такими

характеристиками, как множественность, необходимость существования или

возможность отсутствия связи.

Модели сущность-связь в объектном представлении

Диаграмма классов.

Легко можно увидеть, что все окружающие нас вещи различаются по категориям

(автомобили, мебель, стиральные машины). Мы обращаемся к этим категориям, как к

классам. Класс - это категория или группа вещей, которая имеет сходные атрибуты и

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

разработки.

Диаграмма объектов.

Объект представляет собой экземпляр класса - особую сущность, которая имеет

заданные значения атрибутов и операций. Если на примере стиральной машины, то

её атрибуты могут иметь вид: компания-производитель - "Сантехника",

наименование модели - "Мойдодыр", серийный номер - "13-666-13" и ёмкость - 16

фунтов.

Расширения языка:

Примечания служат для пояснения, почему эта часть диаграммы расположена

именно здесь и как с ней работать. Стереотипы позволяют использовать

существующие элементы UML и преобразовывать. Хороший пример - концепция

интерфейса, т.е. класса не имеющего атрибутов.

Ассоциации.

Если классы концептуально взаимодействуют друг с другом, то это взаимодействие

называется ассоциацией. Ассоциации имеют ограничения(например {по очереди},

{или}), квалификатор(доп. информация в отношении "один ко многим"), классы,

кратность, может быть рефлексивной. Может быть наследованием, зависимостью.

Агрегация, композитные объекты, интерфейсы и реализации.

Иногда класс состоит из

некоторого количества классов-

компонентов. Это особый тип

взаимосвязи, называемый

агрегацией. Обозначается не

закрашенным ромбом. Можно

использовать {или} для того,

чтобы показать выбор. Агрегация

задаёт отношение "часть-целое".

Композит - это строгий тип агрегации,

характеризующийся тем, что каждый элемент может

принадлежать только одному целому. Можно выделить

набор повторно используемых операций и объединить их

в группу. Существует два вида обозначения интерфейса:

кружок и стереотип. Термин видимость применяется по

отношению к атрибутам и операциям и задаёт типы

других классов, которые могут пользоваться ими.

· Открытая область "+" - все могут использовать.

· Защищённая область "#" - используется только наследниками.

· Закрытая область "-" - только класс имеет доступ.

· Реализация предполагает открытость операций интерфейса.

Статические атрибуты и операции (присущие классу, единые для всех объектов

данного класса) подчёркиваются.

Диаграммы потоков данных

(DFD - Data Flow Diagramm) строятся из следующих элементов:

Элемент Описание Обозначение

Функция Действие, выполняемое моделируемой системой

Поток

данных

Объект, над которым выполняется действие. Может быть

информационным (логическим) или управляющим. (Управляющие

потоки обозначаются пунктирной линией со стрелкой).

Хранилище

данных

Структура для хранения информационных объектов

Внешняя

сущность

Внешний по отношению к системе объект, обменивающийся с нею

потоками данных

Такой тип обозначений элементов DFD-диаграммы получил название

"нотация Йордона - Де Марко", по именам разработавших его специалистов.

Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами,

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

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

объектов. При интерпретации DFD-диаграммы используются следующие правила:

· Функции преобразуют входящие потоки данных в выходящие

· Хранилища данных не изменяют потоки данных, а служат только для

хранения поступающих объектов

· Преобразования потоков данных во внешних сущностях игнорируется

Помимо этого, для каждого информационного потока и хранилища определяются

связанные с ними элементы данных. Каждому элементу данных присваивается имя,

также для него может быть указан тип даных и формат. Именно эта информация

является исходной на следующем этапе проектирования - построении модели

"сущность-связь". При этом, как правило, информационные хранилища

преобразуются в сущности, проектировщику остается только решить вопрос с

использованием элементов данных, не связанных с хранилищами.

Построим DFD-диаграмму для предприятия, строящего свою деятельность по

принципу "изготовление на заказ". На основании полученных заказов формируется

план выпуска продукции на определенный период. В соответствии с этим планом

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

загрузки производственного оборудования. После изготовления продукции и

проведения платежей, готовая продукция отправляется заказчику.

Эта диаграмма представляет самый верхний уровень функциональной модели.

Естественно, это весьма грубое описание предметной области. Уточнение модели

производится путем детализации необходимых функций на DFD-диаграмме

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

обеспечение материалами" на подфункции "Определение потребностей", "Поиск

поставщиков", "Заключение и анализ договоров на поставку", "Контроль платежей",

"Контроль поставок", связанные собственными потоками данных, которые будут

представлены на отдельной диаграмме. Детализация модели должна производится до

тех пор, пока она не будет содержать всю информацию, необходимую для

построения информационной системы.

Физическая модель данных

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

решения о выборе платформы реализации. Выбор платформы зависит от требований

к использованию данных и стратегических принципов формирования архитектуры

корпорации. Выбор платформы - сложная проблема, выходящая за рамки данного

курса. В MS Visio физическая модель является графическим представлением реально

реализованной базы данных. Физическая база данных будет состоять из таблиц,

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

реализации, и требований к использованию данных. Физическая модель для IMS

будет серьезно отличаться от такой же модели для Sybase. Физическая модель для

OLAP-отчетов будет выглядеть иначе, чем модель для OLTP (оперативной обработки

транзакций).

Разработчик модели данных и администратор базы данных (DBA - database

administrator) используют логическую модель, требования к использованию и

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

физической модели данных. Вы можете денормализовать физическую модель для

улучшения производительности, и создать представления для поддержки требований

к использованию.

Корпоративная модель данных (EDM - enterprise data model)

содержит сущности, атрибуты и отношения, которые представляют информационные

потребности корпорации. EDM обычно подразделяется в соответствие с

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

поддержке конкретных нужд бизнеса. Некоторые предметные области могут

покрывать такие специфические бизнес-функции, как управление контрактами,

другие - объединять сущности, описывающие продукты или услуги.

Каждая логическая модель должна соответствовать существующей

предметной области корпоративной модели данных. Если логическая модель не

соответствует данному требованию, в нее должна быть добавлена модель,

определяющая предметную область. Это сравнение гарантирует, что корпоративная

модель улучшена или скорректирована, и в рамках корпорации скоординированы все

усилия по логическому моделированию.

EDM также включает специфические сущности, которые определяют область

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

определяются как независимые. Независимые сущности часто используются для

поддержания целостности связей. Эти сущности идентифицируются несколькими

различными именами, такими как кодовые таблицы, таблицы ссылок, таблицы типов

или классификационные таблицы. Мы будем использовать термин "корпоративный

бизнес-объект". Корпоративный бизнес-объект это сущность, которая содержит

набор значений атрибутов, не зависящих ни от какой другой сущности.

Корпоративные бизнес-объекты в рамках корпорации следует использовать

единообразно.

Семинар: изучение возможностей MS Access.

Самостоятельная зачетная работа. Проектирование структуры базы данных

(результат – модель в MS Visio).

Тема 4. Понятие корпоративной информационной системы

Понятие корпоративной информационной системы

Эволюция взглядов на корпоративную информационную систему. Классификация по

типам, функциям, вариантам технической реализации.

Корпоративные системы MRP, MRPII, CSW.