Файл: Основные структуры алгоритмов: сравнительный анализ и примеры их использования (Типы моделей и основные их классификации).pdf

- аппаратура: в соответствии с требованиями Microsoft SQL Server 2010.

3. Разработка системы алгоритмизации

3.1. Требование к программе

Для разработки функциональной модели использовалось САSЕ-средство верхнего уровня - BPWin. BPWin — это модель, поддерживающая следующие методологии:

- IDEFO (функциональная модель);

- IDEF3 (WorkFlow Diagram);

- DFD (DataFlow Diagram).

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО - ВЕ). Методология IDEFO предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEFO) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

В результате анализа предметной области была разработана функциональная модель системы автоматизации рабочего места менеджера продаж автосалона. Осуществилось на основе использования методологий IDЕF0 И DFD .

Работа осуществляется на основе устава автосалона «Стандарты продаж» («управление») менеджером продаж («механизм»).

Входными данными для системы является:

- товарно-транспортная накладная;

- инвойс на автомобиль;

- заявка на автомобиль;

- запрос на формирование отчета;

- отказ клиента от заказа.

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

Выходные данные системы:

- договор купли-продажи;

- договор заказа;

- заказ мастеру предпродажной подготовки;

- заказ поставщику;

- отчет по продажам;

- отчет по остаткам на складах;

- отчет по зарезервированным автомобилям;

- отчет по состоянию автомобилей;

- отчет по клиентам;

- отчет по рекламе.

Функциональная декомпозиция системы проводится на основе методологии DFD и приведена на рисунке А.2.

Диаграмма верхнего уровня иерархии (контекстная диаграмма) определяет основные процессы или подсистемы с внешними входами и выходами. Она детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла /2/.

В проектируемой системе используется три хранилища (накопителя) данных:

- «Сведения об автомобилях». Накопитель содержит: марка, модель, VIN, тип кузова, тип коробки переключения передач (КПП), объем двигателя, комплектация, дополнительные опции, цвет, цена, состояние, дополнительная информация, наименование поставщика.

- «Сведения о клиентах». Накопитель содержит: фамилия, имя, отчество клиента, наименование документа, удостоверяющего личность, серия и номер документа, кем выдан, адрес проживания, контактный телефон, дата покупки.

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

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

процессов:

- регистрация новых автомобилей;

- обработка заявки клиента;

- формирование отчетов;

- формирование заказа поставщику;

- формирование заказа мастеру предпродажной подготовки.

Данные товарно-транспортной накладной и инвойса на автомобиль поступают на вход процесса «Регистрация новых автомобилей». В рамках данного процесса происходит занесение сведений из накладной и инвойса в хранилища данных «Сведения об автомобилях» и «Сведения о контрагентах».

Входными потоками для процесса «Обработка заявки клиента» являются заявка на автомобиль и отказ клиента от заказа. В результате выполнения процесса формируются выходные потоки - данные о заказанном автомобиле и данные о купленном автомобиле, а также документы - договор заказа, договор купли-продажи, лист отказа. Декомпозиция данного процесса представлена на рисунке А.3 и описана в пункте 3.3.1.

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

Входными потоками для процесса «Формирование заказа мастеру предпродажной подготовки» являются сведения об автомобиле, прописанные в договоре купли-продажи. В результате выполнения процесса формируется заказ мастеру ПП.

В процессе «Формирование отчетов» анализируется входной поток «Запрос на формирование отчета». В результате выполнения процесса формируются необходимые отчеты.

Диаграмма содержит четыре процесса: «Подбор автомобиля», «Оформление договора купли-продажи», «Оформление договора заказа», «Расторжение договора заказа».

Входным потоком процесса «Подбор автомобиля» являются заявка клиента на автомобиль определенных характеристик и данные по наличию автомобилей на складах автосалона. Если автомобиль, находящийся в свободной продаже, устраивает клиента то данные выбранного автомобиля передаются на вход следующего процесса «Оформление договора купли-продажи», в результате выполнения которого формируется договор купли продажи, а выходной поток «Данные о новых клиентах» заносится в хранилище «Сведения о клиентах». Если же клиент принимает решение о заказе автомобиля, то выполняется процесс «Оформление договора заказа», на вход которого подаются данные, необходимые для заказа автомобиля. В результате выполнения процесса формируется договор заказа, а выходной поток «Данные о новых клиентах» заносится в хранилище «Сведения о клиентах».

Входными потоками для процесса «Расторжение договора заказа» является отказ клиента от заказа и данные о клиенте. Здесь выполняется расторжение договора заказа путем формирования листа отказа.

3.2. Функциональное проектирование системы

Нормализация - это набор стандартов проектирования данных, называемых нормальными формами (НФ). Общепринятыми считаются пять нормальных форм, хотя их было предложено значительно больше. Создание таблиц в соответствии с этими стандартами называется нормализацией. Нормальные формы изменяются в порядке от первой до пятой. Каждая последующая форма удовлетворяет требованиям предыдущей формы. Если следовать первому правилу нормализации, то данные будут представлены в первой нормальной форме (1НФ). Если данные удовлетворяют третьему правилу нормализации, они будут находиться в третьей нормальной форме (ЗНФ), а также в первой и второй формах.

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

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

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

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

атомарное (или единственное) значение, находится в 1НФ. При этом необходимо, чтобы отношение имело первичный ключ.

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

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

Разработанная модель находится в третьей нормальной форме т.к.:

- атрибуты сущностей являются атомарными;

- каждый неключевой атрибут функционально полно зависит от первичного ключа;

- в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

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

Первый шаг нормализации - выделение первичных ключевых атрибутов сущностей. В качестве первичного ключа в отношении «Автомобиль» включен атрибут «Код_ Автомобиль», в отношении «Марка» - атрибут «Код_Марка», в отношении «Модель» - атрибут «Код_Модель», в отношении «Доступность_опции» - атрибут «Код_Доступность», в отношении «Состояние» - атрибут «Код_Состояние», в отношении «Сотрудник» - атрибут «Код_Сотрудник», в отношении «Контрагент» - атрибут «Код_Контрагент», в отношении «Покупатель» - атрибут «Код_Покупатель», в отношении «Склад» - атрибут «Код_Склад», в отношении «Тип_Цены» - атрибут «Код_Тип_цены», в отношении «Приходная_накладная» - атрибут «Номер приходного документа», в отношении «Расходная_накладная» - атрибут «Номер расходного документа», в отношении «Перемещение» - атрибут «Номер документа перемещения», в отношении «Оприходование» - атрибут «Номер оприходования», в отношении «Резервирование» - атрибут «Номер документа», в отношении «Снятие_резерва» - атрибут «Номер документа», в отношении « Заказ_покупателя» - атрибут «Номер документа», в отношении «Опросник» - атрибут «Номер документа». В отношении «Список_опций» первичный ключ является составным и включает два атрибута: «Код_Опции», «Код_Автомобиль». Отношение «Цена» также имеет составной первичный ключ, включающий атрибуты «Код_Цена» и «Код_Автомобиль». Первичный ключ отношения «Строка_приходного_документа» включает два атрибута: «Номер приходного документа» и «Номер строки документа». В отношении «Строка_расходного_документа» первичный ключ также является составным и включает атрибуты: «Номер расходного документа» и «Номер строки документа». Первичный ключ отношения «Перемещаемый_автомобиль» включает два атрибута: «Номер документа перемещения» и «Номер строки документа». В отношении «Приходуемый_автомобиль» первичный ключ также является составным и включает атрибуты: «Номер оприходования» и «Номер строки документа». Первичный ключ отношения «Строка_резервирования» включает два атрибута: «Номер документа» и «Номер строки документа». В отношении «Строка_снятия_резерва» первичный ключ также является составным и включает атрибуты: «Номер документа» и «Номер строки документа». Первичный ключ отношения «Строка_заказа_покупателя» включает два атрибута: «Номер документа» и «Номер строки документа».

На данном этапе логическая модель удовлетворяет 1НФ. То есть в отношениях, на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение. Теперь можно связать сущности с помощью добавления внешних ключей. После этого для некоторых сущностей первичный ключ стал составным. Сущности такого типа удовлетворяют 2НФ, так как ни один атрибут таких сущностей не зависит от части ключа. То есть неключевые атрибуты функционально полно зависят от всего составного ключа. Модель базы данных удовлетворяет так же и 3НФ, так как в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.