Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Складской учет»

Содержание:

ВВЕДЕНИЕ

В современном мире уже ни одно предприятие не может обойтись без применения современных телекоммуникационных и информационных технологий, будь то огромный международный концерн или небольшая розничная сеть магазинов. Возможности современных технологий и программного обеспечения помогают руководству предприятия проводить эффективную управленческую политику, упрощают планирование и позволяют оперативно решать появляющиеся задачи. Рынок различных телекоммуникационных и информационных решений на сегодняшний день весьма велик, существует множество программных комплексов, изначально спроектированных под определенные отрасли, так как для разных сфер деятельности будет актуальна своя система управления, учитывающая все особенности того или иного бизнеса[1-10].

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

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

Автоматизация управления до сих пор остается достаточно дорогим и ресурсоёмким процессом, но выгода, полученная от внедрения, спустя некоторое время окупит вложенные инвестиции в IT [10-15].

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

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

Задачи курсовой работы:

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

разработать информационное обеспечение задачи

разработать программное обеспечение задачи

выполнить контрольный пример реализации и его описание.

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

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

1. ТЕХНИКО-ЭКОНОМИЧЕСКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ И ПРЕДПРИЯТИЯ

1.1 Описание предметной области. Постановка задачи.

Основное направление деятельности:

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

Проанализируем выполнение плана по себестоимости продукции в разрезе статей калькуляции выпускаемого оборудования в компании ООО «СИМПЛАСТ».

Таблица 1- Анализсебестоимостипродукциипостатьямкалькуляции

Статьи затрат	На фактический объем и структуру продукции
	по плану	фактически
1. Сырье и основные материалы	66 800	66990
2. Возвратные отходы (вычитаются)	-1 255	-1 385
3. Полуфабрикаты собственного производства	2 906	3 680
4. Топливо и энергия на технологические цели	4 259	5 744
5. Расходы на оплату труда производственных рабочих	9 800	14 910
6. Отчисления на социальные нужды	4 020	6 217
7. Расходы по эксплуатации производственных машин и оборудования	752	1 194
8. Общепроизводственные расходы	12 859	12 994
9. Общехозяйственные расходы	36 300	36 825
10. Потери от брака	135	160
11. Прочие производственные расходы	19 802	8 485
12. Коммерческие расходы	580	760
Итого производственная себестоимость продукции (работ, услуг)	156 625	156 610

Общая организационная структура предприятия проста. В ООО «Симпласт» существует линейно-функциональная организационная структура. Этот вид структуры наиболее приемлем, так как она имеет штат сотрудников, где четко разграничены полномочия и ответственность работников [23].

Структура предприятия представлена на рисунке 1.

Рисунок 1 – Организационная структура предприятия

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

1.2 Выбор средства для моделирования бизнес-процессов

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

Основным компонентом средств проектирования и реализации корпоративного ПО является репозиторий для хранения версий и компонент проекта ИС и поддержания синхронизации и контроля целостности (полноты и непротиворечивости) (мета)данных при коллективной разработке. Другими важными составляющими CASE-инструментов являются графические средства анализа и проектирования для создания и редактирования моделей программных комплексов в форме диаграмм (SADT, IDEF, UML и др.), а также средства разработки прикладных ИС, управления метаданными и проектами, документирования, тестирования и реинжиниринга.

В РФ зачастую (особенно при проектировании мелких и средних ИС) используются устаревающие CASE-средства на основе многопроходной IDEFметодологии, а также не связанные в комплексы средства CASE и RAD.

Результаты детального сравнительного анализа важнейших характеристик основных CASE-средств приведены в таблицах 2-4.

Таблица 2 - Классификация основных CASE-средств по видам проектирования ПО

Название	Производитель	BPR	Функции	Данные	События
BPWin	LogicWorks	+	+	-	-
CASE.Аналитик	Эйтэкс	-	+	+	+
CASE/4/0	MicroTOOL	-	+	+	+
DatabaseDesigner	Oracle			+	-
Design/IDEF	MetaSoftware	+	+	+	-
Designer/Developer	Oracle	+	+	+	+
EasyCASE	Evergreen CASE Tools		+	+	+
ERWin	LogicWorks		-	+	-
I-CASE Yordon	CAYENNE		+	+	+
Prokit*WORKBENCH	MDIS	-	+	+
S-Designor	Sybase/Powersoft		+	+	+
SILVERRUN	CSA		+	+	+
VisibleAnalyst	VisibleSystems		+	+	+
Workbench
ARIS	IDS Sheer AG		+	+	-
Rational	IBM	+	+	+	+
VisualStudio .NET	Microsoft	+	+	+	+

Таблица 3 - Сравнение основных CASE-средств по поддерживаемым методологиям

CASE-средство	IDEF0	IDEF1	IDEF1X	IDEF3	IDEF4	IDEF5	IDEF6	eEPC	CDM
Design/IDEF	+	+	+
Bpwin	+			+
Designer/Developer	+						+		+
Silverrun			+
PRO-IV			+
ERwin			+
S-Designor/ PowerBuilder			+
DataBaseDesigner			+						+
Rational							+
ObjectTeam
VisualStudio.NET							+
ARIS							+	+
SmartClass					+

Таблица 4 - Классификация CASE-средств по сферам применения

Тип	Назначение	Примеры
Средства анализа (upper CASE)	Построение и анализ моделей предметной области	Design/IDEF, BРwin, Visual Studio.NET, Designer/2000, IBM Rational, ARIS
Средства анализа и проектирования (middle CASE)	Создание спецификаций компонентов, интерфейсов, архитектур, алгоритмов и структур данных на основе наиболее распространенных стандартов проектирования (IDEF и др.).	Team Builder, Designer/Developer, Silverrun, PRO-IV, CASE. Аналитик, ARIS
Средства проектирования БД	Моделирование данных, генерация схем БД	ERwin, S-Designor, ORACLE DataBase Designer, Team Builder, Designer/Developer, Silverrun, PRO-IV
Средства реализации прикладного ПО	Модификация стандартных компонент прикладного ПО	4GL: Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi; Кодогенерация: Vantage Team Builder, PRO-IV, частичноSilverrun
Средства реинжиниринга ИС	Формирование моделей данных и спецификаций ПО на основе анализа программных кодов ИС и схем БД	СхемыБДи ERD: Vantage Team
Средства реинжиниринга ИС		Builder, PRO-IV, Silverrun, Designer/Developer, Erwin, S-Designor/ PowerBuilder Анализкодов: IBM Rational, Object Team (реинжиниринг на языке С++ )
Средства планирования и управления проектами	Выявление и оценка рисков, бизнес-планирование, оценка трудоемкости (трудозатраты, стоимость, ресурсы, уровень качества)	SE Companion, Visual Studio.NET, IBM Rational, KnowledgePlane, ARIS
Средства конфигурационного управления		PVCS, SCCS, IBM Rational, Visual Studio.NET, ARIS
Средства тестирования		Quality Works, Visual Studio.NET, Developer/2000

Под моделью разработки ИС обычно понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наиболее распространенными моделями, ориентированные на итеративный процесс разработки являются: RationalUnifiedProcess (RUP, MicrosoftSolutionsFramework (MSF), PersonalSoftwareProcess / TeamSoftwareProcess (PSP/TSP) и Agile (eXtremeProgramming, Crystal, FeatureDrivenDevelopment (FDD), Scrum).

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

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

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

Таблица 5 - Характеристика моделей процессов разработки ПО

Вес

модели

Модели

Достоинства

Недостатки

Тяжелый

RUP, MSF (для CMMI)

Процессы рассчитаны на среднюю квалификацию исполнителей. Невысокие требования к стабильности команды. Нет ограничений на распределение участников. Отсутствуют ограничения по объему и сложности разрабатываемых ИС. Используются для ИС с высокими рисками. Легче получить высокий уровень сертификации стандартов качества.

Требуют существенной

управленческой

надстройки.

Более длительные стадии анализа и проектирования. Более формализованные коммуникации. Большие затраты на документацию длительного процесса сопровождения ПО.

Легкий

MSF (Agile), PSP/

TSP,Agile

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

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

В начале 90-х годов прошлого столетия эксперты разработали более совершенные решения в области обеспечения качества, что привело к созданию целого ряда новых стандартов и методологий, таких как: ISO9001:2008, CapabilityMaturityModel (CMM), ISO/IEC15504(SPICE, введен как стандарт Российской федерации ГОСТ Р ИСО/МЭК 15504 «Информационные технологии. Оценка процессов» с 2010 г.) и стандарт ГОСТ, используемый на территории стран СНГ.

Стандарт ISO 9001:2008 направлен на применение «процессного подхода» при разработке, внедрении и улучшении результативности системы менеджмента качества с целью повышения удовлетворённости потребителей путём выполнения их требований.

Модель CMM разработана в качестве эталонной модели организации разработки ПО при реализации крупномасштабных ИС. Основой моделей CMM/CMMI является формализация процессов разработки.

Стандарт SPICEбыл создан Международной организацией по стандартизации, которая инициировала работу по созданию единого стандарта оценки программных процессов. 180/1ЕС является эталонной моделью, которая определяет процесс измерения и возможность измерения качества процесс.

ГОСТы в настоящее время действуют на территории России и других стран СНГ. Данные стандарты ориентирован на последовательный подход к разработке ПО. В табл. 6 указана возможность использования различных средств обеспечения качества ИС, использующих итеративный подход для разработки.

Таблица 6 -Возможность сертификации моделей итеративной разработки ПО

Модель Стандарт	RUP	MSF for CMM	MSF forAgile	PSP/TSP	Agile
ISO9000:2008	+	+	-	-	-
CMM/CMMI	3-ий уровень	2-3-ий уровень	2-3-ий уровень	5-ый уровень	-
SPICE	+	+	+	+	+
ГОСТ	-	-	-	-	-

где «-» означает невозможность сертификации; «+» - возможность сертификации.

Основная проблема использования ГОСТов и стандартов ІSО 9000:2008 - это слабая формализация процессов при использовании гибкой методологии.

Наиболее эффективными средствами обеспечения качества для ИТ, использующих итеративную разработку, являются CMM ISO/IEC 15504(SPICE),т.к. их использование не зависит от используемой модели разработки ИС.

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

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

Таблица 7- Сравнение моделей ИС

Содержание

Модели Параметры	RUP	MSF	PSP/TSP	Agile
Модели Параметры	RUP	MSF	PSP/TSP	XP	CrystalClear	FDD	Scrum
абстрактный общий процесс, на основе которого организация должна создать конкретный специализированный процесс, ориентированный на ее потребности	согласованный набор концепций, моделей и правил, описывающих управление людьми и процессами в процессе разработки решения; опирается на практический опыт Microsoft	Набор требований к компетенциям разработчика, делает ставку на самоуправляемые команды	набор практик: короткие релизы, переработки кода, разработка «тестами вперед», коллективное владение кодом, постоянное присутствие заказчика и стандарты кода	Итеративная инкрементная разработка; автоматическое регрессионное тестирование; состав документации определяется участниками разработки	функционально-ориентированная разработка, которая оперирует понятием функции или свойства системы	итеративная разработка, которая фокусируется на постоянном определении приоритетных задач, основываясь на бизнес целях
Команда	свыше 40-50 человек	группы по 3-10 человек	3-20 разработчиков	до 10-15 человек	до 6 человек	20-30 человек	5-9 человек
Вес	тяжелый	может быть и тяжелым, и легким	легкий	легкий
Используемые стандарты	CMMI, ISO, SPICE	CMMI, ISO, SPICE	CMMI, SPICE	CMMI, SPICE
Достоинства	снижение основных рисков заказчика, и разработчика; экономию ресурсов за счет автоматизации регрессионного тестирования; улучшение качества ПО за счет многократных проверок; улучшение качества тестирования за счет использования современных технологий.	систематизация и структуризация информации в форме базы знаний; нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды	лучшее планирование времени и бюджета; управление качеством продукта; уменьшение времени разработки; принципам взаимодействия внутри команды	крайне низкие накладным расходы; процесс может показать исключительную эффективность	максимально проста в использовании; требует минимальных усилий для внедрения; ориентирована на человеческие привычки;	1) дает возможность планирования и предварительного проектирования, создания детального дизайна,	1) позволяет реализовать большой объем функциональности без спецификаций момент начала разработки.
Недостатки	несогласованность решений, непродуктивные затраты ресурсов на переработку кода и на повторное решение типовых проблем в случае недостаточного уровня формализма	не описывает детально важнейшие роли заказчика и пользователя; не рассматриваются методы управления группой проектов	проблемы при учете рисков, сложности	рассчитан только на команду опытных разработчиков, не разбитую на несколько частей; проблемы разрешения нетехнологичес ких рисков	уступает XP по производительности; очень сложно заранее предсказать, какие промежуточные продукты необходимы	Недостаток документации; значительно увеличивается стоимость последующего сопровождения продукта	не задает технических практик; сложно добиться активного участия от разработчиков и вовлечь поставщика требований в активное участие

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

Реакции на возникновение различных рисков и, соответственно, методы управления рисками будут варьироваться в зависимости от выбранной модели разработки ИС. В табл. 8 предложены методы управления рисками для наиболее распространенных моделей разработки ИС с итерационным циклом разработки - RUP, MSF иAgile.

Таблица 8 -Методы для предотвращения наиболее распространенных рисков

Модель Тип риска	RUP	MSF	Agile
Нарушения календарного планирования, срыв сроков	Перерасчет сроков выполнения этапов работ	Планирование временного резерва	Выделение сверхурочных трудочасов, повышенное внимание к предварительному планированию
	Ликвидация или уменьшение данного риска возможно путем оценки длительности определенных работ или всей разработки несколькими методами: опрос экспертов - проведение интервью соответствующих квалифицированных специалистов; мозговой штурм - проведение общего собрания, на котором специалисты по очереди высказывают свои мнения о необходимых временных затратах на определенные типы работы. Споры и замечания не допускаются, все мнения записываются, группируются и оцениваются по типам и характеристикам работ; сбор данных - проведение сбора данных по нескольким ИС относительно масштабов недооценки размера разработки; имитационное моделирование - моделирование и анализ неопределенности в оценках основных показателей разработки (денежные и временные затраты).
Изменение требований	учет увеличения трудоемкости и временных затрат в случае возможного роста требований, например, на 50% (принятие риска)	переоценка сроков разработки каждый раз, когда требования добавляются/изменяются (ликвидация риска)		подписание контракта с компенсацией затрат (переадресация риска заказчику)
Текучесть кадров	определение причин, по которым люди покидают компанию. Для изучения мотивов ухода большое значение имеет сбор и анализ информации о них. В первую очередь это сведения об общем числе уволившихся, долях сотрудников различных возрастных категорий, о работниках с низкой и высокой квалификацией, а также об их стаже работы и образовании	определение общих потерь времени как число месяцев, которое потребуется новому сотруднику на достижение того же уровня производительности, который был у замененного им работника		учет в оценках трудоемкости издержек на обучение сотрудников; уменьшение потерь от текучести кадров за счет привлечения на начальном этапе избыточного числа участников
Нарушение спецификаций	Политика ликвидации риска - подписание договора между заказчиком и компанией с описанием входных и выходных условий, оценка рисков независимыми экспертами
Низкая производительность	улучшение организации производства и труда - повышение норм труда и расширения зон обслуживания; уменьшение числа сотрудников, не выполняющих нормы; упрощение структуры управления; повышение уровня специализации	структурные изменения - изменения удельных весов отдельных сотрудников в зависимости от трудоемкости выполняемой работы		повышение технического уровня производства - внедрение новых видов оборудования и ПО
Недостаточное внимание к проекту со стороны руководства компании	Проведение промежуточных отчетных собраний с приглашением заказчика	Промежуточная оценка прогресса разработки ИС руководством компании с составлением отчетности перед заказчиком		Составление договора между заказчиком и компанией с поэтапной сдачей ИС
Отсутствие мотивации Персонала компании	Проведение тренингов, корпоративных собраний, внедрение методик teambuilding	Премирование персонала в зависимости от успешности выполнения задач		Распространение акций фирмы среди персонала, выделение разработчикам % от прибыли с разработки

Анализ современных средств разработки баз данных представлен в приложении 1.

1.3 Моделирование бизнес-процессов «как есть»

Основными процессами на предприятии являются:

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

Анализ рынка проводится в следующей последовательности:

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

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

планирование кампании по продвижению;
формирование рекламной продукции по различным каналам;
рекламирование;
формирование базы клиентов.

Контекстная диаграмма и диаграммы декомпозиции представлены на рис. 2-11.

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

Рисунок 3 - Диаграмма декомпозиции (IDEF0)

Рисунок 4 - Диаграмма декомпозиции

Рисунок 5 - Диаграмма декомпозиции

Рисунок 6 - Диаграмма декомпозиции

Рисунок 7 - Диаграмма декомпозиции

Рисунок 8 - Диаграмма декомпозиции

Рисунок 9 - Диаграмма декомпозиции

Рисунок 10 – Диаграмма декомпозиции

Рисунок 11 – Дерево узлов

2. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ЗАДАЧИ

2.1 Предлагаемые мероприятия по улучшению бизнес-процессов

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

В автоматизированной системе посреднической деятельности кодированию подлежат следующие объекты:

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

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

Таблица 9 -Структура нормативно-справочной информации

№ п/п	Наименование кодируемого множества объектов	Значность кода	Система кодирования	Вид классификатора
1	2	3	4	5
1	Код материала	ХХХ	порядковая	локальный
2	Код номенклатурной группы	ХХХ	порядковая	локальный
3	Код склада	ХХ	порядковая	локальный
4	Код статьи затрат	ХХ	порядковая	локальный
5	Код подразделения	ХХ	порядковая	локальный
6	Код документа прихода	ХХХХХ	порядковая	локальный
7	Код документа списания	ХХХХХ	порядковая	локальный

Описание систем классификации и кодирования.

Код материала. Длина кода ХХ, где ХХ – порядковый номер материала.
Код номенклатурной группы. Длина кода ХХХ, где ХХХ – порядковый номер номенклатурной группы.
Код склада. Длина кода ХХ, где ХХ – порядковый номер склада.
Код статьи затрат. Длина кода ХХ, где ХХ – порядковый номер статьи затрат в классификаторе.
Код подразделения. Длина кода ХХ, где ХХ порядковый номер подразделения.
Код документа прихода. Длина кода ХХХХХ где ХХХХХ – порядковый номер документа прихода.
Код документа списания. Длина кода ХХХХХ где ХХХХХ – порядковый номер документа расхода.

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

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

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

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

Отпуск материалов на склады (в кладовые) подразделений организации и на площадки строительства рассматривается как внутреннее перемещение.

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

При отпуске материалы должны измеряться в соответствующих единицах измерений (весовых, объемных, линейных, поштучно), а также списываться со счетов учета материальных ценностей и зачисляться на соответствующие счета учета затрат на производство. При этом должны производиться следующие бухгалтерские записи: Д-т 20 «Основное производство», 23 «Вспомогательные производства», 25 «Общепроизводственные расходы», 26 «Общехозяйственные расходы»; К-т 10 «Материалы»; 10 «Материалы», субсчет «ТЗР», 16 ««Отклонение в стоимости материальных ценностей.

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

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

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

Отпуск материалов со складов организации в производство оформляется следующими первичными документами: лимитно-заборная карта (типовая межотраслевая форма N М-8), требование-накладная (типовая межотраслевая форма N М-11), накладная (типовая межотраслевая форма N М-15).

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

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

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

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

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

2.2 Моделирование бизнес-процессов «как должно быть»

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

Документ прихода включает в себя Номер, Дату прихода и склад.

Документ списания включает в себя Номер, Дату списания, Склад, Подразделение, Номенклатурную группу, Статью затрат (табл. 10-11).

Таблица 10 - Документ прихода

Наименование поля	Тип данных	Размер поля
1	2	3
Номер	Счетчик	Длинное целое
Дата	Дата
Склад	Числовой	Длинное целое

Таблица 11 - Документ списания

Наименование поля	Тип данных	Размер поля
1	2	3
Номер	Счетчик	Длинное целое
Дата	Дата	Длинное целое
Склад	Числовой	Длинное целое
Подразделение	Числовой	Длинное целое
Номенклатурная группа	Числовой	Длинное целое
Статья затрат	Числовой	Длинное целое

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

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

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

Дерево функций

Печать

Ввод первичной информации

Обработка

данных

Заполнение справочников

Просмотр и

редактирование данных

Вход в систему

Открытие Главной формы

Выбор Справочника

Хранение

данных

Заполнение БД

Просмотр и редактирование данных

Материальная ведомость

Просмотр и редактирование данных

Вычисления

Печать

Рисунок 11 – Дерево функций ИС «Учет затрат на производство»

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

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

сбор данных;
обработка данных;
генерация данных;
хранение данных;
передача данных.

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

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

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

вывод результатной информации на печать,
вывод результатной информации на экран.

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

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

Построение моделей данных в ERStudio начинается с выбора в меню File пункта создания новой модели (рис. 12).

Рисунок 12 - Создание новой модели данных

Далее переходим к созданию сущностей. Сущность в ERStudio можно создать несколькими способами: выбрав в главном меню пункт создания сущности, выбрав на панели инструментов соответствующую кнопку, с помощью браузера объектов (рис. 13).

Рисунок 13 - Создание новой сущности

Для вновь созданной сущности задаем имя и создаем атрибуты, указывая их тип и размерность (рис. 14).

Рисунок 14 - Создание атрибутов сущности

На рис. 15 показано назначение атрибута idCode первичным ключом в таблице.

Рисунок 15 - Назначение первичного ключа

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

Рисунок 16 - Логическая модель базы данных

На рис. 17 показан переход от логического представления модели БД к физическому представлению.

Рисунок 17 - Переход к физической модели

На рис. 18 представлена физическая модель данных.

Рисунок 18 - Физическая модель базы данных

Перед тем, как приступить к генерации БД, можно выбрать БД из списка предложенных в пункте меню DatabaseChange, подпункте DatabasePlatform. Далее можно приступить к генерации БД (рис. 19-20).

Рисунок 19 - Запуск на генерацию БД

Рисунок 20 - Мастер генерации БД

После того, как переключатель установлен на пункте GenerateObjectswith a DatabaseConnection, нажимаем кнопку «Cоnnect»(рис. 21)

Рисунок 21 - Установка соединения

Если нужного источника данных нет в выпадающем списке, то создаем его самостоятельно. Нажимаем на setup, а далее на кнопку «Добавить» (рис. 22-23).

Рисунок 22 - Выбор источника данных пользователя

Рисунок 23 - Создание нового источника данных

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

Рисунок 24 - Установка драйвера ODBC

Рисунок 25 - Выбор базы данных

Задаем имя новому источнику данных (рис. 26).

Рисунок 26 - Установка драйвера ODBC

Далее вновь запускается Мастер генерации (рис. 27- 28) .

Рисунок 27 - Мастер генерации

Рисунок 28 - Мастер генерации

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

Рисунок 29 - Схема базы данных

2.3 Структурная схема пакета (дерево вызова программных модулей)

Схема работы приложения представлена на рис. 30.

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

Рисунок 30 - Блок схема работы главного модуля приложения

Формы для работы с программой представлены на рис. 31-33.

.Рисунок 31 - Главная форма программы

Рисунок 32 - Форма для редактирования клиентов

Рисунок 33 - Форма для редактирования клиентов

Рисунок 34 - Форма для редактирования поставщиков

Результаты работы с запросами представлены на рис. 35-39

Рисунок 35 - Форма для поиска по товару

Рисунок 36 - Форма для поиска по клиенту

Рисунок 37 - Форма для поиска по поставщику

Рисунок 38 - Отчет «Приход товара»

Рисунок 39 - Отчет «Расход товара»

Результаты отчетов представлены на рис. 40

Рисунок 40 - Прайс-лист

2.4. Контрольный пример реализации и его описание

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

Откроем таблицу «Поставщики». Пример представлен на рис. 41.

Рисунок 41 – Результаты проверки ввода данных

Произведем на главной кнопочной форме нажатие закладки Приход товара (рис. 42). Нажав кнопку закладку мы видим открытие формы базы данных (рис. 43).

Рисунок 42 – Нажатие на главной кнопочной форме закладки Отчеты

Рисунок 43 – Результаты проверки открытия формы с отчетами

ЗАКЛЮЧЕНИЕ

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

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

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

Практическая значимость данной работы

удовлетворяет требованиям заказчика и действительно упрощает работу менеджера по продажам;
разработано руководство пользователя.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Положение по ведению бухгалтерского учета и бухгалтерской отчетности в РФ, утвержденном приказом Минфина России № 34н от 29.07.98г. (в ред. Приказов Минфина РФ от 30.12.1999 N 107н, от 24.03.2000 N 31н, от 18.09.2006 N 116н, от 26.03.2007 N 26н)
«Отраслевые особенности состава затрат, включаемых в себестоимость продукции на предприятиях лесопромышленного комплекса» (утв. Минэкономики РФ 19.10.1994) (вместе с «Методическими рекомендациями (инструкцией) по планированию, учету и калькулированию себестоимости продукции лесопромышленного комплекса», утв. Минэкономики РФ 16.07.1999) [9]
«Типовые методические рекомендации по планированию, учету и калькулированию себестоимости научно-технической продукции» (утв. Миннауки РФ 15.06.1994 N ОР-22-2-46)
«Инструкция по составу, учету и калькулированию затрат, включаемых в себестоимость перевозок (работ, услуг) предприятий автомобильного транспорта» (утв. Минтрансом РФ 29.08.1995)
Козлов ОВ Проектирование холодильников предприятий отрасли: УМК. –М.: МГУТУ, 2012. –161с.
Агальцов, В.П. Базы данных: Кн.1.Локальные базы данных:/ Агальцов В.П..- 2-е изд., перераб. - М.: ИНФРА-М, 2011.- 352 с., ил.
Баженова, И.Ю. Основы проектирования приложений баз данных [Текст] / И.Ю. Баженова. - М. : Интернет-Ун-т Информ. Технологий, 2006. - 325 с.
Барабанова И.М., Глебовский А.Ю. Проектирование информационных систем в экономике. Экономическое обоснование проектов. Учеб. пособие. – СПб.: Изд-во СПбГПУ, 2010.-302с.
Барановская Т.П., Лойко В.И. Информационные системы и технологии в экономике. М.: Финансы и статистика, 2009.- 420 с.
Божко В.П., Власов Д.В., Гаспариан М.С.Информационные технологии в экономике и управлении: Учебно-методический комплекс. – М.: Изд. центр ЕАОИ. 2010. – 120 с.
Бугорский В.Н., Соколов Р.В., – Сетевая экономика и проектирование информационных систем. – СПб.: Питер, 2011.–320с.
Вендров В.Я. Информационные системы в экономике. – М.: Инфра-М, 2012. – 240 с.
Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем. – Ростов-на-Дону: Феникс, 2010. – 512 с.
Гинзбург В.М. Проектирование информационных систем в строительстве. Информационное обеспечение. – М.: Издательство Ассоциации строительных вузов, 2010. – 368 с.
Дорохова В.Р. Курс лекций по дисциплине «Проектирование информационных систем». – Алт.гос.техн.ун-т им.И.И. Ползунова. – Барнаул: кафедра ИСЭ, АлтГТУ, 2010. – 161 с.
Емельянова Н.З., Партыка Т.Л., Попов И.И. Проектирование информационных систем. – М.: Форум, 2010. – 432 с.
Козырев А.А. Информационные технологии в экономике и управлении: Учебник. Изд-е 3-е перераб и доп. – СПб.: Изд-во Михайлова В.А., 2010. - 496 с.
Кузин, А. В. Базы данных [Текст]: учеб. пособие для вузов по направл. "Информатика и вычисл. техника" / А. В. Кузин, С. В. Левонисова. - 3-е изд., стер. - М. : Академия, 2008. - 316 с.
Липаев В.В. Управление разработкой программных средств: Методы, стандарты, технология. / В.В. Липаев. М.: Инфра-М, 2011. – 274 с.
Маклаков, С.В. Моделирование бизнес-процессов с AllFusionProcessModeler[Текст]:- М.: Диалог-МИФИ, 2008. - 236 с.
Мишенин А.И. Теория экономических информационных систем. / А.И. Мишенин. М.: Наука, 2011. – 352 с.
Мезенцев К.Н. Автоматизированные информационные системы. – М.: Академия, 2012. – 174 с.
Проектирование информационных систем. Учебное пособие для студентов / Сост. А. В. Бычков Кубан. гос. технол. ун-т. Каф. ВТ и АСУ. - Краснодар: Изд-во ГОУВПО «КубГТУ» , 2010. -82 с.
Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2009. - 528 c.
Романов А.Н., Одинцов Б.Е., – Информационные системы в экономике: 2-е издание. - М.: Вузовский учебник, 2010. – 328 с.
Саймон А.Р. Стратегические технологии баз данных: менеджмент на 2000 год. Перевод с англ./ Под ред. и с предисл. М.Р. Когаловского. – М.: Финансы и статистика, 1999. – 479 с.
Советов Б.Я., Цехановский В.В. Информационные технологии. – М.: Юрайт, 2012. – 272 с.
Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.
Юдицкий С.А. Технология проектирования архитектуры информационно-управляющих систем. / С.А. Юдицкий, А.Т. Кутанов. - М.: Наука, 2010. – 189 с.
Письмо Минфина РФ от 26.09.1996 N 83 «О методических рекомендациях по планированию, учету и калькулированию себестоимости продукции (работ, услуг) в сельском хозяйстве»
Федеральный закон «О бухгалтерском учете» № 129-ФЗ от 21.11.1996 (в ред. от 03.11.2006г.)
Приказ Минтопэнерго РФ от 17.11.1998 N 371 (ред. от 12.10.1999) «Об утверждении инструкции по планированию, учету и калькулированию себестоимости продукции на нефтеперерабатывающих и нефтехимических предприятиях»
ПБУ 10/99 «Расходы организации», утв. приказом Минфина РФ от 06.05.99г. № 33н, (в ред. от 27.11.2006)
Налоговый Кодекс РФ, часть 2 от 05.08.2000г. № 117-ФЗ (в ред. Федеральных законов от 24.07.2007 N 198-ФЗ, от 06.12.2007 N 333-ФЗ)
Приказ Минсельхоза РФ от 06.06.2003 N 792 «Об утверждении методических рекомендаций по бухгалтерскому учету затрат на производство и калькулированию себестоимости продукции (работ, услуг) в сельскохозяйственных организациях»
Приказ Минсельхоза РФ от 02.02.2004 N 73 «Об утверждении методических рекомендаций по учету затрат в животноводстве» (вместе с «Методическими рекомендациями по бухгалтерскому учету животных на выращивании и откорме в сельскохозяйственных организациях»)
Трудовой кодекс Российской Федерации (ред. от 31.12.2014) от 30.12.2001 N 197-ФЗ
ПБУ 18/02 «Учет расчетов по налогу на прибыль», утв. Приказом Минфина РФ от 19.11.02г. № 114н (в ред. от 11.02.2008)

ПРИЛОЖЕНИЕ 1. АНАЛИЗ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

Классификация СУБД по моделям данных (МД) приведена в таблице 1. Анализ моделей доступа к данным приведены в приложении А.

Таблица 1- Классификация СУБД по моделям данных и стандартам ANSI

	Модели данных
	Сетевая	Иерархическая	Независимый логический файл	Реляционная
Типичные системы БД	Supra IDMS/R IDS DMS-2 DMS-1100 VAX DBMS	System 2000 IMS	Inquire Adabas GIM family Nomad Focus Ramis CA DatacomModel 204	DB/2 CA/Ingres Oracle Sybase Informix MSSQLServer
Соответствие ANSI	ANSI NDL		ANSI SQL/99	ANSI SQL/86 ANSI SQL/89 ANSI SQL/92

Поворотным пунктом в развитии МД и СУБД стало появление в середине 90-х гг. глобально доступной среды сетевых вычислений интернет и вебсервисов для обеспечения удаленного доступа к ИС с «унаследованными» БД. Доминирующая архитектура типа клиент-сервер стала поддерживать более сложную обработку БД, что привело к быстрому росту числа интернет-БД. С развитием интернет-архитектуры клиенты (браузеры) и серверы БД были расширены мини-приложениями (апплетами) для обработки гетерогенных данных (в т.ч. мультимедиа) и их представлений для различных устройств, поддерживающих современные МД (интернет-приставки к ТВ, мобильные устройства и др.).

В конце 90-х гг. получили развитие технологии (ActiveServerPages, JavaDataBaseConnectivity, сервлетыJava, EnterpriseJavaBeans( и средства публикации и интеграции данных (MicrosoftFrontPage, AllaireColdFusion, MacromediaDreamWeaver, OracleDeveloper/2000) в глобальной среде. Широкое распространение в среде интернет получили инструментальные средства с «открытым кодом» (opensource), СУБД (Apache, MySQL) и технологии (GCC, CGI) для их применения. Данная тенденция продолжилась в последующие годы.

В настоящее время в интернет/интранет-среде традиционные средства онлайновой транзакционной (OLTP) и аналитической (OLAP) обработки данных постепенно сменяются технологией «точечных продаж» (Point-Of-Sale, POS). Расширяется сфера применения БД электронной коммерции (ecommerce), включающих решения для частных лиц «клиент-клиент» (customer-to-customer, C2C) и «бизнес-клиент» (business-to-customer, B2C), а также для корпораций типа «бизнес-бизнес» (business-to-business, B2B) и др.

В XXI веке перспективными направлениями конвергенции БД и интернет явялются интерактивные ИС для мобильных устройств, POS-транзакций, ассоциаций поставщиков продукции и др. С точки зрения интегральной оценки СУБД в аспектах МД, сетевых технологий и инструментальных средств можно выделить OracleServer с поддержкой технологии grid-вычислений, IBM DB2 и Microsoft SQL Server.

В начале 2000-х гг. возник класс постреляционных СУБД (например, InterSystemsCache’) на основе иерархических многомерных МД, ориентированных на высокопроизводительную обработку транзакций в больших и сверхбольших (терабайтных) БД и масштабируемых корпоративных ИС, в т.ч. в среде интернет. В 2010-х гг. также возник класс noSQL СУБД, не гарантирующих согласованного состояния данных (Kassandra, Hadoop, F1 и др.). Несмотря на управление весьма большими объемами данных, эти СУБД не получили широкого распространения для индустриальных КПК в силу высокой сложности МД и специфических требований к проектированию БД.

Распределенные гетерогенные аппаратно-программные комплексы федеративного уровня в глобальной среде потенциально реализуемы посредством технологии grid-инфраструктуры для доступа к высокопроизводительным вычислительным ресурсам с интегрированным увеличением мощности БД (исследовательские прототипы включают терабайтные БД CERN UKHEC GridTestbeds, NASA EOS/DIS (www.eos.nasa.gov) и др.).

Таким образом, традиционные МД не позволяют организовать формализованные процедуры поиска, ассоциирования и группировки гетерогенных (мультимедийных) ОД. Необходимость интеграции данных и процедур манипулирования ими расширяет традиционные двух- и трехуровневые архитектуры в направлениях активных сценарноориентированных БД (на основе триггеров и хранимых процедур) и потоков работ (с вычислениями по схеме «запрос-ответ»).

Развитие МД, ЯМОД семейства SQL и ОРСУБД прогнозируется по направлениям, связанным с XML, Java-технологиями, мобильными интернет-БД, распределенной обработкой транзакций и ООБД; прототипы стандартов предложены ODMG (ObjectDatabaseManagementGroup, www.odmg.org).

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

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

Значительные сложности представляет масштабируемость высоконормализованных БД (традиционное преобразование иерархии неизбыточных таблиц в плоскую таблицу приводит к существенному падению производительности при обновлениях, а также к риску нарушения целостности из-за распределенности и дублирования данных). Внедрение стандарта SQL/99 в СУБД потенциально позволяет решить проблему масштабируемости за счет проектирования БД с естественной иерархической структурой без построения III нормальной формы и последующей денормализации (побочный эффект состоит в значительной ресурсоемкости реорганизации БД). При этом наиболее легко адаптируемыми к SQL/99 потенциально оказываются СУБД на основе независимых логических файлов (Adabas, Focus, Datacom/DB и др.) и иерархические СУБД (SAS System 2000, IBM IMS и др.).

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

В отличие от реляционных баз данных, NoSQL не гарантирует соблюдения требований ACID (Atomicity, Consistency, Insulation, Durability - атомарность, согласованность, изолированность, долговечность). Однако существует отдельный набор требований к базам данных NoSQL:

базовая доступность (basicavailability) - каждый запрос гарантированно завершается (успешно или безуспешно);
гибкое состояние (softstate) - состояние системы может изменяться со временем, даже без введения новых данных, для достижения согласования данных;
согласованность в конечном итоге (eventualconsistency) - данные будут обязательно согласованы через некоторое время.

К основным видам NoSQL баз данных относятся следующие:

БД «ключ-значение»;
колоночные БД;
документоориентированные БД;
графоориентированные БД;
объектно-ориентированные БД.

БД «ключ-значение» является очень простой моделью данных. В такого типа БД ключи представлены в форме значений, как в хэш-таблице позволяющий получить гибкое построение данных. Redis является представителем такого типа БД. Она обеспечивает и предоставляет возможность выбора между надежностью и скоростью. Преимущества Redis высокая производительность, работа со списками и стеками, простой API реализован для таких языков как (PHP, Ruby, Python, Perl, Java). Также зарекомендовали себя хранилища данных по модели «ключ-значение» MemcacheDB и BerkeleyDB. Преимущества MemcacheDB высокая надежность, быстродействие доступа к информации, высокая скорость чтения/записи, поддержка транзакций. BerkeleyDB довольно быстро разрабатывается и получает новые версии преимуществами можно назвать репликации и реплики. Часто применяется в качестве платформы для построения операционной и интерфейсная части.

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

Документоориентированные базы данных характеризуются тем, что у них нет схемы организации данных. Это означает:

- сущности не должны иметь однородную структуру, то есть разные записи могут иметь разные столбцы;

- типы значений могут быть различными для каждой записи;

- колонки могут иметь несколько значений (массивы);

- записи могут иметь вложенную структуру.

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

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

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

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

Документоориентированные базы данных часто используются для:

- уплотненной информации - документы на основе хранилища данных позволяют работать с глубоко вложенными, сложными структурами данных;
- JауаScript-дружественных систем - одним из важнейших функциональных документов на основе хранилища данных способ которым они взаимодействуют с приложениями: с помощью JS-дружественного представления данных JSON.

Самыми известными документоориентированными базами данных являются:

- CouchDB - документоориентированная система управления базами данных, которая не требует описания схемы данных. Эта СУБД является свободной, открытой, написанная на языке Erlang.
- MongoDB - документоориентированная система управления базами данных с открытым исходным кодом, которая не требует описания схемы таблиц. Написана на языке C ++. СУБД оперирует наборами JSON-подобных документов, хранящихся в двоичном виде в формате BSON.

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

MongoDB - концептуально то же самое, что и обычная реляционная база. Внутри MongoDB может быть ноль или несколько баз данных, каждая из которых является контейнером для других объектов
База данных может иметь ноль или более «коллекций». Коллекция настолько похожа на традиционную «таблицу», которую можно рассматривать, как то же самое.
Коллекция состоит из нуля или более «документов». Опять же, этот документ можно рассматривать как «строка».
Документ состоит из одного или нескольких «полей», которые можно рассматривать как «столбцы».
«Индексы» в MongoDB практически идентичны индексам в реляционных базах данных.
«Курсоры» отличаются от предыдущих пяти понятий, но они очень важны (хотя иногда это игнорируется) и заслуживают отдельного обсуждения. Важно понимать, что, когда осуществляется запрос любых данных в MongoDB, возвращается указатель, с помощью которого можно сделать что-нибудь - рассчитать, пропустить определенное количество предыдущих записей - без загрузки данных.

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

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

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

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

Чаще всего графоориентированные данных используются для:

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

Самые известные графоориентированные базы данных:

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

Результаты сравнения корпоративных систем управления базами данных показано на рис. 1-14.