42
Таблица 5
Отношение «Категории мероприятий»
Наименование поля
Описание поля
Тип поля
Длина поля
Прочее
Название категории
Название
категории
мероприятия
Текстовый
50
-
Таблица 6
Отношение «Мероприятия»
Наименование поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Название мероприятия
Название
мероприятия
Текстовый
255
-
Таблица 7
Отношение «Заказчики»
Наименование поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Название заказчика
Название заказчика
Текстовый
100
-
Контактный телефон
Контактный
телефон
Текстовый
50
-
ФИО контакта
ФИО контактного
лица
Текстовый
100
-
Таблица 8
Отношение «Журнал мероприятий»
Наименование
поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Дата мероприятия
Дата
мероприятия
Дата
Краткий
формат
даты
-
Мероприятие
Название
мероприятия
Текстовый
255
-
Заказчик
Заказчик
Текстовый
100
-
Категория
мероприятия
Название
категории
мероприятия
Текстовый
50
-
43
Для поддержания базы данных в устойчивом состоянии используется
ряд механизмов, получивших обобщенное название средств поддержки
целостности. Приведение структуры базы данных в соответствие этим
ограничениям называется нормализацией.
В целом суть данных ограничений достаточно простая: каждый факт,
который хранится в БД, должен храниться в ней один-единственный раз,
так как дублирование факта может привести к несогласованности между
копиями одной и той же информации. Кроме того, следует избегать любых
неоднозначностей в данных, а также избыточности хранимой информации.
Нормализация схемы БД – это процедура, которая производится над
БД с целью удаления в ней избыточности.
Выделяют несколько нормальных форм: первая нормальная форма
(1НФ), вторая, третья нормальные формы (2НФ, 3НФ), нормальная форма
Бойса-Кодда (НФБК), четвертая и пятая нормальные формы (4НФ, 5НФ).
1НФ говорит о том, что каждый атрибут отношения должен хранить
только атомарное значение, а каждое отношение (т.е. строка в таблице)
должно содержать одинаковое количество атрибутов (т.е. столбцов).
Другими словами 1НФ:
запрещает использование повторяющихся столбцов, содержащих
одинаковую по смыслу информацию;
запрещает использование множественных столбцов, содержащих
значения типа списка и т.д.;
требует определения первичного ключа для таблицы, т.е. того
столбца или комбинации столбцов, которые однозначно определяют
каждую строку таблицы.
2НФ говорит о том, что отношение находится во второй нормальной
форме в том случае, если данное отношение находится в первой
44
нормальной форме, и при этом все его не ключевые атрибуты зависят
только от первичного ключа. Другими словами:
2НФ требует, чтобы не ключевые столбцы таблиц зависели от
первичного ключа в целом, но не от его части (для составного
ключа);
если таблица находится в 1НФ и первичный ключ у нее состоит из
одного столбца, то она автоматически находится и в 2НФ.
Отношение находится в 3НФ тогда, когда оно находится в 2НФ и
каждый не ключевой атрибут зависит только от первичного ключа и не
зависят друг от друга.
Отношения модели данных не находятся в третьей нормальной
форме. Выполним нормализацию отношений и получим (табл. 9-12).
Таблица 9
Отношение «Категории мероприятий»
Наименование поля
Описание поля
Тип поля
Длина поля
Прочее
Код категории
Уникальный
идентификатор
Счетчик
Длинное
целое
Первичный
ключ
Название категории
Название
категории
мероприятия
Текстовый
50
-
Таблица 10
Отношение «Мероприятия»
Наименование поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Код мероприятия
Уникальный
идентификатор
Счетчик
Длинное
целое
Первичный
ключ
Название мероприятия
Название
мероприятия
Текстовый
255
-
Код категории
Идентификатор
категории
мероприятия
Числовой
Длинное
целое
Внешний
ключ
45
Таблица 11
Отношение «Заказчики»
Наименование поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Код заказчика
Уникальный
идентификатор
Счетчик
Длинное
целое
Первичный
ключ
Название заказчика
Название заказчика
Текстовый
100
-
Контактный телефон
Контактный
телефон
Текстовый
50
-
ФИО контакта
ФИО контактного
лица
Текстовый
100
-
Таблица 12
Отношение «Журнал мероприятий»
Наименование
поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Код записи
Уникальный
идентификатор
Счетчик
Длинное
целое
Первичный
ключ
Дата мероприятия
Дата
мероприятия
Дата
Краткий
формат
даты
-
Код мероприятия
Идентификатор
мероприятия
Числовой
Длинное
целое
Внешний
ключ
Код заказчика
Идентификатор
заказчика
Числовой
Длинное
целое
Внешний
ключ
В табл. 9-12 приведена структура отношений (наименование поля,
тип поля, длина поля, ключ) модели данных. Каждое поле отношения
является простым, в отношениях определены первичные ключи. Каждое не
ключевое поле полностью зависит только от первичного ключа.
Далее каждому отношению ставим в соответствие таблицу, каждому
полю отношения – поле таблицы. Тип поля и его длину определяем
безотносительно целевой СУБД. На основе полученных таблиц реализуем
логическую модель данных.
Логическая модель данных, выполненная средствами ERWin,
приведена на рис. 13.
46
Рис. 13 – Логическая модель данных
Логическая модель данных, выполненная средствами ERWin,
отражает проектирование концептуальной модели данных. На основе
описания предметной области, а также моделей бизнес-процесса в ней
выделены следующие сущности и атрибуты: категории мероприятий:
название категории; заказчики: название заказчика, ФИО контакта,
контактный телефон; мероприятия: название мероприятия; журнал
мероприятий: дата мероприятия, мероприятие, заказчик, категория
мероприятия. Связи между сущностями: каждое мероприятие относится к
некоторой категории, при этом к каждой категории может относиться
несколько мероприятий (связь «один-ко-многим»); каждое мероприятие
проводится для некоторого заказчика (соответствует запись в журнале
мероприятий), при этом каждый заказчик может заказать проведение
нескольких мероприятий (связь «один-ко-многим»); каждой записи в
журнале мероприятий соответствует некоторое мероприятие, при этом
каждому мероприятию может соответствовать несколько записей в
журнале, если оно проводится несколько раз (связь «один-ко-многим»).
47
При переходе от логической модели данных к физической
необходимо типы и длину полей определить с учетом целевой СУБД.
Наименования полей должны соответствовать принятым в используемой
СУБД правилам.
Описание структуры записей таблиц базы данных для СУБД MS
SQL Server 2008 приведено в табл.13-16.
Таблица 13
Описание структуры записей таблицы «Категории мероприятий»
(CATEGORY)
Наименование поля
Идентификатор
поля
Тип поля
Длина поля
Прочее
Код категории
ID_CAT
INTEGER
IDENTITY
(1,1)
Первичный
ключ
Название категории
NAME_CAT
VARCHAR
50
Таблица 14
Описание структуры записей таблицы «Мероприятия» (MEROP)
Наименование поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Код мероприятия
ID_MEROP
INTEGER
IDENTITY
(1,1)
Первичный
ключ
Название мероприятия
NAME_MEROP
VARCHAR
255
Код категории
ID_CAT
INTEGER
Внешний
ключ
Таблица 15
Описание структуры записей таблицы «Заказчики» (CLIENT)
Наименование поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Код заказчика
ID_CLIENT
INTEGER
IDENTITY
(1,1)
Первичный
ключ
Название заказчика
NAME_CLIENT
VARCHAR
100
Контактный телефон
PHONE
VARCHAR
50
ФИО контакта
NAME_CONTACT
VARCHAR
100
48
Таблица 16
Описание структуры записей таблицы «Журнал мероприятий» (JOURNAL)
Наименование
поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Код записи
ID_REC
INTEGER
IDENTITY
(1,1)
Первичный
ключ
Дата мероприятия
DATA_MEROP
DATE
Код мероприятия
ID_MEROP
INTEGER
Внешний
ключ
Код заказчика
ID_CLIENT
INTEGER
Внешний
ключ
Примечание: INTEGER – целое, VARCHAR() – текстовое
переменной длины, DATE – дата, IDENTITY(1,1) – счетчик.
Физическая модель данных, выполненная средствами ERWin,
приведена на рис. 14.
Рис. 14 – Физическая модель данных
Далее выполним реализацию модели данных средствами целевой
СУБД, а именно СУБД MS SQL Server 2008.
Схема БД в MS SQL Server 2008 представлена на рис. 15.
49
Рис. 15 – Схема базы данных
На схеме данных отображены таблицы, поля, ключевые поля, а
также связи между таблицами:
таблицы «MEROP» и «CATEGORY»: по полю ID_CAT;
таблицы «MEROP» и «JOURNAL»: по полю ID_MEROP;
таблицы «CLIENT» и «JOURNAL»: по полю ID_CLIENT.
Структура таблиц базы данных приведена на рис. 16-19.
Рис. 16 – Структура таблицы «CATEGORY»
Рис. 17 – Структура таблицы «MEROP»
50
Рис. 18 – Структура таблицы «CLIENT»
Рис. 19 – Структура таблицы «JOURNAL»
В структуре таблиц отражены наименования полей, типы данных,
допустимость значений NULL.
В физической модели данных (рис. 14), выполненной средствами
ERWin, к которой мы перешли от логической модели данных, мы типы и
длину полей определи ли с учетом целевой СУБД. Наименования полей
соответствуют принятым в используемой СУБД правилам и отражают
проектирование концептуальной модели данных.
На основе описания предметной области, а также моделей бизнес-
процесса в ней выделены следующие атрибуты: «CATEGORY»;
«MEROP»; «JOURNAL»; «CLIENT».
Далее мы выполнили реализацию модели «Схема базы данных» на
рис. 15 средствами целевой СУБД, а именно СУБД MS SQL Server 2008.
На схеме базы данных мы отобразили таблицы, поля, ключевые поля, а
также связи между таблицами: таблицы «MEROP» и «CATEGORY»: по
полю ID_CAT; таблицы «MEROP» и «JOURNAL»: по полю ID_MEROP;
таблицы «CLIENT» и «JOURNAL»: по полю ID_CLIENT.
51
3.2. Проектирование и разработка программного обеспечения системы
В процессе автоматизации бизнес-процесса и разработки ПО
реализуются функции как управления, так и обработки данных. Можно
выделить два подмножества реализуемых функций:
служебные функции (например, проверки пароля и др.);
основные функции (ведение справочников, ввод и обработка
оперативной информации, получение результатной информации и
др.).
На рис. 20 приведена схема иерархии функций управления и
обработки данных.
Рис. 20 – Функции управления и обработки данных
Функции управления и обработки данных в схеме иерархии идет
подчинение служебных функций и основных функций, в свою очередь в