Файл: Разработка конфигурации «Продажи» в среде 1С:Предприятие 8.3. (Анализ предметной области и постановка задачи).pdf

2.2.1 Определение связей между сущностями

При проектировании таблиц и определении связей между ними используют способ нормализации. Этот способ позволяет разделить исходную, сплошную таблицу на ряд элементарных таблиц, между которыми устанавливаются связи. Такая совокупность связанных таблиц создает единую информационную цепь объекта. Вместе с тем, из этой цепи можно выбирать частичную информацию об объекте, хранимую в отдельной таблице. В то же время связи позволяют осуществить и обратный процесс «сборки» информации по информации одной из таблиц [10].

Существует четыре вида связей (отношений между таблицами):

• один к одному;
• один ко многим;
• многие к одному;
• многие ко многим.

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

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

Связь многие ко многим или непрямая табличная связь определяет связь одной записи первой таблицы с несколькими записями второй таблицы, в то же время как одна запись второй таблицы может быть связана с несколькими записями первой таблицы. На практике такой сложный вид связи между двумя таблицами реализуется через промежуточную (связующую) таблицу. Она позволяет заменить одну связь вида многие ко многим на две последовательные связи: многие к одному и один ко многим, которые реализуются проще [11].

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

Таблица 2 – Описание структуры связей

Продолжение таблицы 2

Таким образом, были определены связи между сущностями и их тип данных представленных связей.

2.2.2. Нормализация базы данных

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

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

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

Выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.

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

База данных считается нормализованной, если ее таблицы представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме в реальных базах данных встречается редко [12].

Первая нормальная форма(1НФ) говорит, что каждый атрибут отношения должен хранить атомарное значение, каждое отношение (строка в таблице) должно содержать одинаковое количество атрибутов (столбцов), то есть:

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

Вторая нормальная форма (2НФ) говорит, что отношение находится во второй нормальной форме, если оно находится в 1НФ, и при этом все не ключевые атрибуты зависят только от первичного ключа, то есть:

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

Отношение находится в третьей нормальной форме (3НФ), если оно находится во второй нормальной форме, и каждый не ключевой атрибут зависит только от первичного ключа и не зависят друг от друга.

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

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

Рассмотрим некоторые сущности для подтверждения данного факта:

• сущность «Состав расход» имеет ключевой атрибут «ID накладной», «ID номенклатуры» и атрибуты «Количество», «Цена», которые являются простыми и неделимыми;
• сущность «Номенклатура» имеет ключевой атрибут «ID номенклатуры» и атрибуты «Наименование», «Единица измерения», которые являются простыми и неделимыми;
• сущность «Цены номенклатуры» имеет ключевой атрибут «ID цены» и атрибуты «Дата», «Цена», «ID номенклатуры», которые являются простыми и неделимыми;
• сущность «Поставщики» имеет ключевой атрибут «ID поставщика» и атрибуты «Полное наименование», «Наименование», «Телефон»,

«Фактический адрес», «Юридический адрес», «Факс», «E-mail», «ИНН»,

«КПП», «Код по ОКПО», которые являются простыми и неделимыми;

• сущность «Состав перемещения» имеет ключевой атрибут «ID перемещения» и атрибуты «Цена», «Количество», «ID номенклатуры», которые являются простыми и неделимыми.

Остальные сущности также находятся в первой нормальной форме.

1. 2НФ требует, чтобы не ключевые атрибуты отношений зависели от первичного ключа в целом, но не от его части. Рассмотрим некоторые сущности для подтверждения данного факта.

Сущность «Состав расход» имеет составной первичный ключ, состоящий из атрибутов «ID продажи», «ID номенклатуры». Не ключевые атрибуты данного отношения зависят от первичного ключа в целом, а не от его части. Атрибуты «Количество», «Цена», зависят и от ID продажи, и от ID номенклатуры. Следовательно, можно сделать вывод, что данная сущность находится в 2НФ.

Сущность «Список номенклатуры» имеет составной первичный ключ, состоящий из атрибутов «ID номенклатуры», «ID склада». Не ключевые атрибуты данного отношения зависят от первичного ключа в целом, а не от его части. Атрибут «Количество» зависит и от ID номенклатуры, и от ID склада. Следовательно, можно сделать вывод, что данная сущность находится в 2НФ.

Сущность «Состав перемещения» имеет составной первичный ключ, состоящий из атрибутов «ID номенклатуры», «ID перемещения». Не ключевые атрибуты данного отношения зависят от первичного ключа в целом, а не от его части. Атрибуты «Количество», «Цена», «Ставка НДС» зависит от ID номенклатуры, и от ID перемещения. Следовательно, можно сделать вывод, что данная сущность находится в 2НФ.

Остальные сущности также находятся во второй нормальной форме.

1. Ни в одном из отношений логической модели не существует транзитивных зависимостей, т.е. не ключевые атрибуты не зависят

функционально друг от друга, поэтому отношения находятся в 3НФ. Рассмотрим некоторые сущности для подтверждения данного факта.

В отношении «Номенклатура» не ключевые атрибуты «Наименование»,

«Единица измерения» функционально не зависят друг от друга.

В отношении «Цены номенклатуры» не ключевые атрибуты «Дата»,

«Цена», «ID номенклатуры» функционально не зависят друг от друга.

В отношении «Розничная продажа» не ключевые атрибуты «ID договора»,

«ID склада», «ID сотрудник», «Комментарий», «Вид оплаты» функционально не зависят друг от друга.

В отношении «Поставщики» не ключевые атрибуты «Полное наименование», «Наименование», «ИНН», «КПП», «Код по ОКПО» «Телефон»,

«Фактический адрес», «Юридический адрес», «E-mail», функционально не зависят друг от друга.

В отношении «Состав сотрудников» не ключевые атрибуты «ID должности», «Начисление» функционально не зависят друг от друга.

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

2.3 Проектирование автоматизированной системы

Проектирование системы осуществляется с использованием UML- диаграмм с помощью CASE-средства ArgoUML.

Диаграмма вариантов использования.

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

Вариант использования – это независящее от реализации высокоуровневое представление конкретной функции разрабатываемой системы. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое внешним объектом (действующим лицом, актером) [13].

Список действующих лиц информационной системы представлены в таблице 3.

Таблица 3 – Действующие лица системы.