Себестоимость заводского производства продукции.

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

• анализ прямых материальных затрат;

• анализ прямых трудовых затрат;

• анализ косвенных затрат;

• анализ коммерческих расходов.

Анализ прямых материальных затрат З_м производится с учетом объема производства V, структуры товарной продукции У, удельных затрат на изделие УМ, расхода материалов на единицу продукции УР и средней цены единицы материалов.

Расчеты:

• по плану Зм = V∙УР∙Ц

• по плану, с учетом фактического объема производства Зм = V_ф∙УР∙Ц∙К_пр

• по плановым нормам и ценам на фактический выпуск про­дукции Зм = V_ф∙УР∙Ц_п

• по фактическим затратам Зм = V_ф∙УР_ф∙Ц_ф

Таким образом, затраты на материалы могут изменится:

• за счет роста объема выпуска продукции:

• за счет изменения структуры производства продукции:

• за счет увеличения удельного расхода материалов:

• за счет изменения цен на материалы:

Анализ прямых трудовых затрат производится с учетом объема производства продукции V, структуры производ­ства УП и удельной заработной платы на единицу продукции УЗ. Рассчитывается сумма прямой зарплаты:

• по плану с учетом трудоемкости продукции Т_р и почасовой оплаты труда Ч_т:

З_т = V_п∙Т_рп∙Ч_тп

• по плану, пересчитанному по факту выпуска продукции:

З_т = V_п∙Т_рп∙Ч_тп∙К_пр

• по плановому уровню затрат на фактический выпуск про­дукции:

З_т = V_ф∙Т_рп∙Ч_тп

• фактически при плановом уровне оплаты труда:

З_т = V_ф∙Т_рф∙Ч_тп

• фактически:

З_т = V_ф∙Т_ф∙Ч_ф

Изменения по прямой заработной плате могут произойти:

• за счет увеличения объема выпуска продукции

• за счет изменения структуры производства продукции

• за счет снижения трудоемкости продукции

• за счет повышения уровня оплаты труда.

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

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

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

Анализ коммерческих расходов производится по статьям:

• затраты на отгрузку материалов и продукции;

• расходы на упаковку и маркетинг.

Понятие о предметной области и ее отображение в БД. Три уровня представления данных в БД. Инфологическое проектирование. Уровни и виды моделей предметной области (модели информации). Этапы процесса проектирования БД и виды моделей.

Создание современных информационных систем (ИС) представляет собой сложную задачу, решение которой требует применения специальных методик и инструментов. В последнее время значительно вырос интерес к CASE (Computer-Aided Software/System Engineering) - технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения. В качестве примера можно привести CASE-средство ERwin фирмы PLATINUM technology, S-Designer фирмы Sybase, Rational Rose компании Rational Software.

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

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

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

CASE-средства подразделяются на логическое проектирование БД и физическое проектирование.

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

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

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

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

· повышение качества программного продукта,

· сокращение стоимости проекта,

· поставка системы в запланированные сроки.

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

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

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

Иерархические БД состоят из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

Тип дерева состоит из одного “ корневого” типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждый из которых является некоторым типом дерева). Сетевые модели создавались для мало ресурсных ЭВМ. Сетевой подход к организации данных является расширением иерархического. В этой модели потомок может иметь любое число предков. Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из наборов экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи. Тип связи определяется для двух типов записи: предка и потомка. Сегодня наиболее распространены реляционные (основанные на двумерных таблицах) модели данных. Любая система данных, не имеет значения какой сложности, может быть сведена к набору таблиц (или "отношений" в терминологии СУРБД). Каждое отношение (таблица) может быть представлено в виде прямоугольного массива со следующими свойствами:

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

· каждая таблица имеет однородные столбцы; все элементы в любом из столбцов одного и того же вида;

· каждому столбцу назначено определенное имя;

· все строки различны; дублировать строки не разрешается;

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

· каждая строка олицетворяет уникальный элемент данных, который ею и описывается;

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

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

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

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

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

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

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

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

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

Внешний уровень.Структурный уровень базы данных, определяющий пользо­вательские представления данных.

Внутренний уровеньобеспечивает физический взгляд на базу данных: дисководы, физические адреса, индексы, указатели и т.д. За этот уровень отвечают проектировщики физической базы данных, которые решают, какие физические устройства будут хранить данные, какие методы доступа будут использоваться для извлечения и обновления данных и какие меры следует принять для поддержания или повышения быстродействия системы управления базами данных. Ни один пользователь (как пользователь) не касается этого уровня. Реализация этих трех уровней требует, чтобы СУБД «преобразовывала» или переводила с одного уровня на другой. Для того чтобы представить данные пользователям на концептуальном или внешнем уровне, система должна уметь преобразовывать адреса и указатели в соответствующие логические имена и отношения. Такой перевод может происходить и в об­ратном направлении — с логического уровня на физический. Цена такого перевода состоит в большой системной задержке. Выгодой же является не­зависимость логического и физического представления данных