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

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

2.3.2 Выбор CASE-средств

В работе необходимо использовать нотацию IDEF0. Посмотрим на существующие CASE-средства [4] для построения подобных моделей: Visio, BPWIN, Ramus.

Visio - наиболее простое и доступное средство моделирования процессов. Этот продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей. Однако для временного или стоимостного анализа требуется разработка отчетов, что значительно усложняет использование этого продукта. Типовые отчеты явно не достаточны для анализа бизнес-процессов. Несмотря на это, Visio является распространенным средством для описания бизнес-процессов как в России, так и за рубежом. Visio поддерживает IDEF и UML форматы для описания бизнес-процессов. Возможна также самостоятельная разработка форматов.

BPWIN - занимает промежуточное место, отличаясь достаточной простотой и большими возможностями анализа [5]. Функциональность BPWIN заключается не только в рисовании диаграмм, но и в проверке целостности и согласованности модели. BPWIN обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании. Кроме того, BPWIN поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу. Основным ограничением этой системы является положенный в ее основу стандарт IDEF, в котором существуют жесткие ограничения при построении моделей. Это упрощает задачу при описании простых процедур, но усложняет описание больших процессов. Схемы IDEF при описании сложных процессов начинают представлять бесчисленное множество взаимосвязанных схем, внешне очень похожих, что затрудняет понимание процесса в целом.

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

Основными возможностями Ramus являются:

· Моделирование процессов (согласно методологий IDEF0, IDEF3 и DFD);

· Разработка систем классификации и кодирования предприятия с внутренними перекрёстными связями, которая также тесно увязывается и с моделями процессов;

· Формирование отчётности по моделям и системе классификации, в том числе и отчётности в форме такой регламентирующей документации как должностные инструкции и регламенты процессов;

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

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

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

№	Возможности/ Инструментальная среда	MS Visio	Ramus	BPWin
1	Поддерживаемый стандарт	UML, IDEF0	IDEF0, IDEF3, DFD	IDEF0, IDEF3, DFD
2	Система хранения данных модели	Модели хранятся в файлах	Модели хранятся в файлах	Модели хранятся в файлах
3	Ограничение на размер базы данных	Нет. Размер базы данных ограничивается вычислительными ресурсами	Нет. Размер базы данных ограничивается вычислительными ресурсами	Нет. Размер базы данных ограничивается вычислительными ресурсами
4	Возможность групповой работы			Есть. Используется Model Mart.
5	Ограничение на количество объектов на диаграмме	В зависимости от используемого стандарта (есть в IDEF0)	В зависимости от используемого стандарта (есть в IDEF0)	От 2 до 8.
6	Возможность декомпозиции	Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе	Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе	Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе декомпозиции.
7	Формат представления моделей	Не регламентируется	Стандартный бланк IDEF с возможностью его отключения	Стандартный бланк IDEF с возможностью его отключения
8	Удобство работы по созданию моделей	Простая панель управления, есть выравнивание объектов, есть undo.	Простая панель управления, есть выравнивание объектов, есть undo.	Простая панель управления, нет выравнивания объектов, нет undo.
9	UDP - свойства объектов, определяемые пользователем	Количество UDP не ограничено. Количество типов ограничено.	Количество UDP не ограничено. Количество типов ограничено	Количество UDP не ограничено. Количество типов ограничено.
10	Возможность анализа стоимости процессов	Нет встроенных возможностей анализа	Упрощенный анализ стоимости по частоте использования в процессе	Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC.
11	Генерация отчетов	Создание отчетов по UDP с помощью Visio Report	Встроенный генератор отчетов, с гибкой структурой	RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP
12	Сложность разработки нестандартных отчетов	Сложно	Просто	Просто

На мой взгляд, удобным является Ramus. Его легко найти в интернете, есть русская версия. Интерфейс данного CASE-средства удобный и понятный.

2.3.3 Модель бизнес-процессов с учетом реинжиниринга

Рассмотрев математическую модель и проведя ее оптимизацию, мы получили готовые предложения по реинжинирингу, которые опишем с помощью методологии IDEF0. На рисунке 2.3 показана контекстная диаграмма.

Рисунок 2.3 - Контекстная IDEF0-диаграмма



Рассмотрим составляющие диаграммы:

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

Сырьё (вход) - поступающее на предприятие сырьё, из которого в дальнейшем производится бетон.

Заказ-наряды (вход) - документы, на основании которых ведется разработка оперативных планов.

ИС (механизм) - информационная система, которая будет решать задачи математического моделирования процесса производства.

Сотрудники (механизм) - лица, непосредственно осуществляющие бизнес-процессы.

Сведения о расходе сырья (выход) - данные для ОМТС для обеспечения закупки сырья.

Бетон (выход) - продукция бетонно-смесительного цеха.

Декомпозируем контекстную диаграмму, чтобы получить подробное представление о структуре бизнес-процессов (рисунок 2.4)



Рисунок 2.4 - Декомпозиция контекстной диаграммы

При декомпозиции были выявлены следующие бизнес-процессы:

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

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

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

Рассмотрим теперь то, как же происходит планирование (см. рисунок 2.5).

Рисунок 2.5 - Декомпозиция бизнес-процесса «Планирование производства»

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

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

Задание параметров расчета модели - в рамках данного бизнес-процесса информационная система наполняется данными (это делает пользователь), а затем производит расчеты оптимального плана производства на основании описанной в п. 2.2 математической модели.

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

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



ГЛАВА 3. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ ОПТИМИЗАЦИИ РАБОТЫ БЕТОННО-СМЕСИТЕЛЬНОГО ЦЕХА ЗАО «КОМБИНАТ КРУПНОПАНЕЛЬНОГО ДОМОСТРОЕНИЯ»

3.1 Обзор существующих проектных решений, выявление их достоинств и недостатков

Конфигурация "Управление производственным предприятием" является комплексным решением, охватывающим основные контуры управления и учета на производственном предприятии. Оно позволяет организовать единую информационную систему для управления различными аспектами деятельности предприятия.

· Управление производством

· Управление финансами

· Управление основными средствами и планирование ремонтов

· Управление складом (запасами)

· Управление продажами

· Управление закупками

· Управление отношениями с покупателями и поставщиками

· Управление персоналом, включая расчет заработной платы

· Мониторинг и анализ показателей деятельности предприятия

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

В системе реализован детальный оперативный учет материалов, продукции и товаров на складах, обеспечивается полный контроль запасов ТМЦ на предприятии. Все складские операции фиксируются с помощью соответствующих документов. Подсистема позволяет:

· осуществлять управление остатками ТМЦ в различных единицах измерения на множестве складов;

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

· осуществлять контроль и учет серийных номеров, сроков годности и сертификатов;

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

· задавать произвольные характеристики партии (цвет, размер и т.д.) и вести партионный учет в разрезе складов;

· учитывать ГТД и страну происхождения;

· комплектовать и разукомплектовывать ТМЦ;

· осуществлять функции ордерного учета и резервирования ТМЦ

ФОЛИО WinСклад 8.1 - многофункциональная система для автоматизации задач, возникающих на всех стадиях управления ресурсами средних и крупных предприятий. В качестве платформы управления базами данных (СУБД) система использует Microsoft SQL Server, являющийся промышленным стандартом в соответствующей отрасли информационных технологий..

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

В зависимости от задач для каждого пользователя, в рамках его должностных обязанностей, настраивается необходимое рабочее окружение. ФОЛИО WinСклад 8.1 позволяет без вмешательства программистов настроить рабочее место любой сложности и функциональности, сформировать рабочее меню, определить права доступа к объектам системы (документам, операциям, переходам и т.д.). Такая возможность выгодно отличает систему ФОЛИО WinСклад 8.1 от других систем с "жестко" настроенной модульной структурой.

Логически ее можно разделить на следующие контуры:

· Нормативно-справочная база

· Документооборот

· Бухгалтерский учет

· Складской учет

· Логистика

· Ценообразование

· Финансовое управление и планирование

Нормативно-справочная база

Система включает в себя следующие справочники и классификаторы:

· Классификатор товаров и услуг, обеспечивающий многоаспектную классификацию и параллельное кодирование.

· Классификатор контрагентов, обеспечивающий многоаспектную классификацию и параллельное кодирование.

· Справочник банков.

· Справочник подразделений.

· Справочник складов.

· Справочник сотрудников.

· Справочник материально-ответственных лиц.

· Географический справочник.

· Справочник валют и курсовые книги.

· Справочник планов счетов.

· Справочник учетных периодов.

· Справочник налогов.

· Справочники условий поставки и оплаты.

· Справочник групп и видов основных средств.

· Справочник норм амортизационных отчислений.

· Другие справочники.

· Произвольное число справочников пользователя.

Документооборот

Контур документооборота включает в себя следующие понятия:

· Диспетчер.

· Действия.

· Пользовательские процедуры.

· Интерфейс настройки.

Бухгалтерский учет

Основные функциональные возможности: Возможность вести учет по нескольким планам счетов. Поддержка вложенности учетных периодов.3 стандартных аналитических признака счета - товар, контрагент, сотрудник. До 7 уровней аналитических признаков по счету. Возможность подключения справочника или справочника пользователя в качестве уровня аналитики по счету. Создание финансово-хозяйственных операций (ФХО) по шаблонам, по шаблонам на основе документов, по шаблонам на основе ведомостей остатков и оборотов по счетам, "вручную". Интерфейс свернутых и развернутых ведомостей остатков и оборотов по счетам. Поддержка разграничения прав доступа на планы счетов и счета. Поддержка нескольких открытых учетных периодов с пересчетом остатков в рамках всех открытых периодов. Возможность вести учет по счету в национальной валюте и в валюте счета. Переоценка валютных активов и пассивов. Учет основных средств. Ведение счетов-фактур, книги покупок, книги продаж.

Складской учет

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

Логистика

Управление закупками. План-график закупок. Отслеживание выполнения плана закупок. Управление сбытом. План-график отгрузок. Отслеживание выполнения плана поставок. Управление запасами. Резервирование. Формирование заявки на пополнение склада. Анализ состояния запасов. Поддержка заявочной кампании для подразделений. Ведение договоров с поставщиками и покупателями.

Ценообразование

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

Финансовое управление и планирование

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

Определим критерии, по которым следует сравнить рассмотренные выше решения:

1) Поддерживаемые платформы СУБД и ОС.

2) Оперативное планирование производства.

3) Складской учет.

4) Поддержка математических моделей.

5) Интеграция с 1С для экспорта отчетов.

6) Масштабируемость.

7) Архитектура.

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

Таблица 3.1 - Сравнительный анализ программ-аналогов

Параметр	Программный продукт
	Проектируемая ИС	1С УПП	Фолио
Поддерживаемые платформы СУБД и ОС	ОС: MS Windows, СУБД: любая SQL-совместимая	ОС: MS Windows, СУБД: SQL-совместимые	ОС: MS Windows CУБД: SQL-совместимые,
Оперативное планирование.	Развитая система диспетчеризации	Отсутствует	В неявном виде присутствует в разных функциях
Интеграция с 1С	Встроенный модуль, расширяющий возможности интеграции с 1С	Стандартными средствами ОС Windows	Построена на одной платформе с 1С.
Складской учет	+	-	-
Поддержка математических моделей	Многокритериальная оценка требуемых ресурсов	Нет данных	отсутствует
Масштабируемость	+	+	+
Архитектура	Интернет/интранет, клиент-сервер	клиент-сервер	клиент-сервер

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

Таблица 3.2 - Относительные веса критериев

	Поддерживаемые платформы СУБД и ОС	Оперативное планирование	Складской учет	Поддержка математических моделей	Интеграция с 1С	Масштабируемость	Архитектура	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Поддерживаемые платформы СУБД и ОС	1	1/8	1/7	1/5	1/3	1/2	1/5	0,3573	0,0309	0,9582
Оперативное планирование	8	1	1	2	3	4	2	3,0000	0,2595	0,9624
Складской учет	7	1	1	2	2	3	2	2,5714	0,2224	0,8845
	Поддерживаемые платформы СУБД и ОС	Оперативное планирование	Интеграция с 1С	Складской учет	Расчет времени загрузки	Масштабируемость	Средняя стоимость внедрения	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Поддержка математических моделей	5	1/2	1/2	1	2	3	1	1,8571	0,1607	1,1300
Интеграция с 1С	3	1/3	1/2	1/2	1	2	1/3	1,0952	0,0947	1,1212
Масштабируемость	2	1/4	1/3	1/3	1/2	1	1/3	0,6786	0,0587	0,9686
Архитектура	5	1/2	1/2	1	3	3	1	2,0000	0,1730	1,1880
ИТОГО:	31,0000	3,7083	3,9762	7,0333	11,8333	16,5000	6,8667	11,5597		7,2128

Определим наибольшее значение веса критерия, см. таблицу 3.3.

Таблица 3.3 - Сравнение критериев

Критерии	Нормализованные оценки вектора приоритета
Поддерживаемые платформы СУБД и ОС	0,0309
Оперативное планирование	0,2595
Складской учет	0,2224
Расчет времени загрузки	0,1607
Интеграция с 1С	0,0947
Масштабируемость	0,0587
Архитектура	0,1730

Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что наибольшее значение придается критерию «Оперативное планирование», наименьшее - «Поддерживаемые платформы СУБД и ОС».

Определим индекс согласованности (ИС), который дает информацию о степени непротиворечивости суждений при составлении матрицы попарных сравнений критериев.

ИС = (л max - n)/(n - 1),

где л max - максимальное собственное значение матрицы (л max ? n),

n-размерность матрицы

ИС = (7,2128- 7)/ (7-1) = 0,0354

Разделив ИС на число, соответствующее случайной согласованности матрицы шестого порядка, равного 1,32, получим отношение согласованности (ОС). Величина ОС должна быть порядка 10% или менее, чтобы быть приемлемой. В некоторых случаях допускается ОС до 20%, но не более, иначе надо проверить свои суждения.

ОС = 0,0354 / 1,32 = 2,68% < 10%, т.е. пересматривать свои суждения нет нужды.

Следующим шагом является сравнение информационных систем по каждому критерию отдельно. Данные об информационных системах по перечисленным выше критериям представлены в таблице 3.1. Для этого необходимо выполнить попарные сравнения каждой системы по каждому критерию в отдельности (таблицы 3.4 - 3.10)

Таблица 3.4 - Сравнительные оценки систем по критерию «Поддерживаемые платформы СУБД и ОС»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	1/2	1/2	0,6667	0,2000	1
1С УПП	2	1	1	1,3333	0,4000	1
ФОЛИО	2	1	1	1,3333	0,4000	1
ИТОГО:	5,000	2,5000	2,5000	3,3333		3

Относительная согласованность матрицы равна 1,08%, т.е. <10%.

Таблица 3.5 - Сравнительные оценки систем по критерию «Оперативное планирование»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	5	5	3,6667	0,7143	1
1С УПП	1/5	1	1	0,7333	0,1429	1
ФОЛИО	1/5	1	1	0,7333	0,1429	1
ИТОГО:	1,400	7,0000	7,0000	5,1333		3

Относительная согласованность матрицы равна 1,28%, т.е. <10%.



Таблица 3.6 - Сравнительные оценки систем по критерию «Складской учет передвижения для транспорта»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	3	2	2,0000	0,5538	1,01538
1С УПП	1/3	1	1	0,7778	0,2154	1,07692
ФОЛИО	1/2	1	1	0,8333	0,2308	0,92307
ИТОГО:	1,8333	5,0000	4,0000	3,6111		3,01538

Относительная согласованность матрицы равна 0,32%, т.е. <10%.

Таблица 3.7 - Сравнительные оценки систем по критерию «Расчет времени загрузки»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	1	1	1,0000	0,3333	1
1С УПП	1	1	1	1,0000	0,3333	1
ФОЛИО	1	1	1	1,0000	0,3333	1
ИТОГО:	3,000	3,000	3,0000	3,0000		3

Относительная согласованность матрицы равна 0,01 %, т.е. <10%.

Таблица 3.8 - Сравнительные оценки систем по критерию «Интеграция с 1С»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	3	2	2,0000	0,5294	0,97058
1С УПП	1/3	1	1/2	0,6111	0,1618	0,97058
ФОЛИО	1/2	2	1	1,1667	0,3088	1,08088
ИТОГО:	1,8333	6,000	3,5000	3,7778		3,02205

Относительная согласованность матрицы равна 2,32%, т.е. <10%.

Таблица 3.9 - Сравнительные оценки систем по критерию «Масштабируемость»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	2	1/4	1,0833	0,1924	1,05814
1С УПП	1/2	1	1/7	0,5476	0,0973	0,97251
ФОЛИО	4	7	1	4,0000	0,7104	0,98942
ИТОГО:	5,500	10,000	1,3929	5,6310		3,02008

Относительная согласованность матрицы равна 1,56%, т.е. <10%.

Таблица 3.10 - Сравнительные оценки систем по критерию «Архитектура»

	Проектируемая ИС	1С УПП	ФОЛИО	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Проектируемая ИС	1	2	1/4	1,0833	0,1818	1
1С УПП	1/2	1	1/8	0,5417	0,0909	1
ФОЛИО	4	8	1	4,3333	0,7273	1
ИТОГО:	5,5000	11,000	1,3750	5,9583		3

Относительная согласованность матрицы равна 0%, т.е. <10%.

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

Таблица 3.11 - Сравнительные оценки систем по всем критериям

Альтернативы	Поддерживаемые платформы СУБД и ОС	Оперативное планирование	Складской учет	Расчет времени загрузки	Интеграция с 1С	Масштабируемость	архитектура	Глобальные приоритеты
	Численное значение вектора приоритета
Проектируемая ИС	0,2000	0,7143	0,5538	0,3333	0,5294	0,1924	0,1818	0,46114674
1С УПП	0,4000	0,1429	0,2154	0,3333	0,1618	0,0973	0,0909	0,18766849
ФОЛИО	0,4000	0,1429	0,2308	0,3333	0,3088	0,7104	0,7273	0,35110052

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

Таблица 3.12 - Сравнение альтернатив

Наименование информационной системы	Глобальные приоритеты
Проектируемая ИС	0,46114674
1С УПП	0,18766849
ФОЛИО	0,35110052

В данном случае проектируемая ИС имеет весомое преимущество.

3.2 Выбор архитектуры информационной системы

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

системы на основе архитектуры файл-сервер;

системы на основе архитектуры клиент-сервер;

системы на основе многоуровневой архитектуры;

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

Рассмотрим более подробно особенности вариантов построения информационных приложений.



Таблица 3.13 - Типовые функциональные компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic(логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
Обозна-чение	Наименование	Характеристика
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логики обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

Поскольку эта архитектура предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам.

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

Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность данных (нет прямого доступа к данным).

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользователей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры.

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней:

нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;

средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без использования хранимых процедур).

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной.

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

Вывод: Для решения задачи проектирования информационной системы подходит технология клиент-сервер, так как в данной системе обрабатывается малый объем данных и она является простой в реализации.

Архитектура ИС, проектируемой в моей работе, показана на рисунке 3.1.

Рисунок 3.1 - Архитектура ИС

Проектируемая мною ИС будет состоять из сервера, на котором будут храниться все данные. Главное программное обеспечение, а также клиентские программ, устанавливаются на АРМ-ы сотрудников. Сервер с установленной на нем ИС будет подключен к локальной сети предприятия.

3.4 Описание концептуальной модели информационной базы

Для хранения данных в информационной системе используется реляционная база данных под управлением СУБД Oracle 11g. Концептуальная схема структуры информационной базы приведена на рисунке 3.3.

В АИС основными объектами являются Заказ, Счет, Заказчик, План производства, Акт о выполненных работах. Рассмотрим отдельно каждый из объектов.

У сущности «Заказ» есть следующие атрибуты: Номер заказа, Дата поступления, Наименование заказа, Количество комплектов, Срок выполнения, Id заказчика, Id плана.

Сущность «Счет» имеет атрибуты: Id счета, Сумма к оплате, Id заказа.

Сущность «Заказчик» имеет атрибуты: Id заказчика, ФИО, Адрес, Телефон.

Сущность «План производства» имеет атрибуты: Id плана, Наименование.

Сущность «Акт о выполненных работах» имеет атрибуты: Id плана, Дата окончания работ, ФИО исполнителя, Id заказа.

Между объектами Акт о выполненных работах и Заказ максимальная мощность связи 1:1, т.е. одному заказу может соответствовать 1 акт о выполнении работ.

Между объектами Заказ и Счет максимальная мощность связи 1:1, т.е. заказу может соответствовать только 1 счет.

Между объектами Заказ и План производства максимальная мощность связи 1:N, т.е. в заказе может быть создано несколько планов раскроя.

Между объектами Заказ и Заказчик максимальная мощность связи 1:N, т.е. у одного заказчика может быть множество заказов.

Рисунок 3.3 - Концептуальная схема базы данных

Таблица 3.14 - Описание полей таблицы Zakaz

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_zakaz	Номер заказа	Integer	PK
Date_invite	Дата заказа	Date	-
Name_zakaza	Имя заказа	Varchar2(255)	-
quantity_komplects	Количество комплектов	Integer	-
Period_execution	Срок выполнения	Date	-
Id_zakazchik	Идентификационный номер заказчика	Integer	FK

Таблица 3.15 - Описание полей таблицы Zakazchik

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_zakazchik	Идентификационный номер заказчика	Integer	PK
FIO	ФИО заказчика	Varchar2(255)	-
Adress	Адрес заказчика	Varchar2(255)	-
Telephone	Телефон	Integer	-

Таблица 3.19 - Описание полей таблицы invoice

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_schet	Идентификационный номер счета	Integer	PK
Date_invoice	Дата оплаты	Date	-
Summ_for_pay	Сумма к оплате	Decimal(10,2)	-
Summ_work	Оплата работы	Decimal(10,2)
Summ_of_materials	Затраты на материалы	Decimal(10,2)	-
Id_zakaz	Номер заказа	Integer	FK

Таблица 3.20 - Описание полей таблицы Akt_work_perfomed

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_act	Идентификационный номер счета	Integer	PK
Data_end	Дата выполнения	Date	-
FIO_worker	ФИО исполнителя	Varchar2(255)	-
Id_zakaz	Номер заказа	Integer	FK



Таблица 3.21 - Описание полей таблицы Design

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_design	Идентификационный номер плана	Integer	PK
Name_design	Наименование плана	Varchar2(255)	-



ГЛАВА 4 РАЗРАБОТКА ИНФОРМАЦИОННЙ СИСТЕМЫ ОПТИМИЗАЦИИ РАБОТЫ БЕТОННО-СМЕСИТЕЛЬНОГО ЦЕХА ЗАО «КОМБИНАТ КРУПНОПАНЕЛЬНОГО ДОМОСТРОЕНИЯ»

4.1 Разработка модуля мониторинга складских запасов

4.1.1 Выбор языка программирования

Выдвигаемые требования к средствам разработки в общем виде можно сформулировать как: "быстрота, простота, эффективность, надежность".

В качестве языка программирования самой базы был выбран SQL. SQL (Structured Query Language) - это язык программирования, который используется при работе с реляционными базами данных в современных СУБД (ORACLE, dBASE IY, dBASE Y, Paradox, Access и др.).

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

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

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

Особо стоит обратить внимание на мощную и гибкую работу с базами данных в Delphi. Она основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine, позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный “ODBC socket”, который позволяет встраивать их.

Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi.

Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.

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

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

4.1.2 Физическое описание базы данных

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

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

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

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

4.1.3 Выбор типа базы данных

База данных организованна в формате баз данных на платформе SQL Server. Важнейшие характеристики данной СУБД - это:

· простота администрирования,

· возможность подключения к Web,

· быстродействие и функциональные возможности механизма сервера СУБД,

· наличие средств удаленного доступа,

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

4.1.4 Описание объектов базы данных

4.1.4.1 Представления

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

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

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

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

* ограничивать доступную пользователю область таблицы определенными строками и/или столбцами;

* объединять столбцы из нескольких таблиц, представляя их в виде единой таблицы;

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

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

SQL Server 2000 также поддерживает индексирование представлений. Это позволяет значительно повысить производительность сложных представлений, которые часто используются в хранилищах данных и других системах поддержки принятия решений. Результирующий набор стандартного представления, описанный логикой определяющего его оператора, не хранится в базе данных, а динамически создается в период выполнения.

Однако существуют (например, в системах поддержки принятия решений) сложные запросы, которые ссылаются на большое число строк базовых таблиц и агрегируют значительное количество данных, получая довольно сжатые сводные результаты (например, суммы средних значений). Для реализации подобных запросов SQL Server 2000 поддерживает создание кластерных индексов на представлениях. При исполнении оператора CREATE INDEX результирующий набор представления, определенного оператором SELECT, сохраняется в БД и становится постоянным. После этого операторы, ссылающиеся на представление, выполняются значительно быстрее. Модификации данных базовых таблиц автоматически отражаются представлением.

4.1.4.2 Хранимые процедуры

Хранимые процедуры позволяют повысить производительность, расширяют возможности программирования и поддерживают функции безопасности, недоступные при использовании команд Transact-SQL, отсылаемых для обработки на сервер. Повышается производительность -- за счет локального (по отношению к базе данных) хранения, перекомпиляции исходного текста и кэширования Возможности программирования расширяются благодаря применению таких распространенных средств программирования, как использование входных и выходных параметров, а также благодаря многократному использованию процедур. Функции безопасности подразумевают шифрование текста процедуры и ограничение привилегий. В результате пользователи получают ограниченный доступ к внутренней структуре базы данных, однако им разрешено запускать хранимые процедуры, выполняющие различные действия над базой данных.

При пересылке каждой команды (или пакета команд) Transact-SQL на сервер для обработки последний должен определить, есть ли у отправителя права на исполнение этих команд и допустимы ли сами команды. Проверив права доступа и синтаксис команд, SQL Server строит план исполнения запроса. Хранимые процедуры в данном случае более эффективны. При создании они сохраняются в SQL Server, поэтому при вызове хранимой процедуры ее содержимое сразу же обрабатывается сервером. Один - единственный оператор позволяет вызвать сложный сценарий Transact-SQL, который содержится в хранимой процедуре, что позволяет избежать пересылки через сеть сотен команд.

Перед созданием хранимой процедуры ее команды проходят синтаксическую проверку. Если при этом не обнаружено ни одной ошибки, имя процедуры сохраняется в таблице SysObjects, а ее текст -- в таблице SysComments. При первом запуске хранимой процедуры создается план исполнения и хранимая процедура компилируется. В дальнейшем ее обработка осуществляется быстрее, поскольку SQL Server не приходится проверять синтаксис команд, создавать план исполнения и компилировать текст процедуры. До создания нового плана в кэше проверяется наличие существующего плана исполнения.

Относительный прирост производительности, вызываемый размещением планов исполнения хранимых процедур в кэше процедур, уменьшается, поскольку планы исполнения всех операторов SQL теперь хранятся в кэше процедур. При исполнении оператора Transact-SQL по возможности предпринимается попытка использования существующего плана исполнения.

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

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

Если разработчикам удобно писать сложные программы на таких языках, как C++, то затем эти программы можно вызывать из SQL Server средствами хранимых процедур особого типа, которые называются расширенными хранимыми процедурами.

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

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

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

Системные хранимые процедуры находятся в базе данных Master. Как правило, их имена начинаются с префикса sp_. Они предназначены для поддержки функций SQL Server (в частности, процедур для работы с каталогом). К ним относится выборка данных из системных таблиц внешними приложениями, администрирование базы данных и управление безопасностью.

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

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

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