Основные схемы многомерной модели
Существуют несколько схем для многомерного моделирования данных. Две из них считаются основными: схема "звезда" (star schema) и схема "снежинка"(snowflake schema). В более сложных случаях используются так называемые "многозвездочные" схемы или схема с несколькими таблицами фактов.
Схема "звезда" имеет одну таблицу фактов и несколько таблиц измерений. Таблицы измерений являются денормализованными.
Схема "снежинка" имеет одну таблицу фактов и несколько нормализованных таблиц измерений.
Схема "звезда" имеет те же самые элементы, что диаграммы "сущность-связь". Это — сущности, атрибуты, первичные и внешние ключи, взаимосвязи, кардинальность связи.
На рис. 9.7 приведен пример схемы "звезда", созданной для учета продажи бакалейных товаров. Таблица фактов "Продажи бакалеи" (учет операций продажи бакалейных товаров торговой компании) имеет один первичный ключ "Номер счета", четыре внешних ключа (по числу измерений ) и два параметра: "Количество" (проданного бакалейного товара) и "Стоимость товара".
Рис. 9.7. Схема "звезда"
Измерение " Время " является одним из критических элементов модели ХД. Если данные в OLTP-системах запросы фокусируются на текущем моменте времени, то в системах поддержки принятия решений (DSS-системах), для которых проектируются и создаются ХД, запросы фокусируются на задачах анализа данных, а именно — как данные изменялись в различные периоды времени. Например, каков был объем продаж торговой компании за последний квартал, месяц или каковы тенденции в покупках товаров в течение последнего квартала.
Измерение "Магазин" позволяет сгруппировать операции продаж по магазинам с учетом их географического положения.
Измерение "Товары" позволяет анализировать типовые схемы закупок товаров и отвечать на вопрос, какие товары, как правило, покупаются одновременно покупателями.
Измерение "Покупатели" позволяет анализировать покупки с учетом их частоты, географического положения и количества.
Таблицы измерений являются своеобразным путеводителем при выборке строк из таблицы фактов.
Таблицы фактов имеют большое количество строк. Таблицы измерений, как правило, имеют гораздо меньшее число строк. Одним из главных преимуществ использования такой схемы является то, что производительность операции СУБД соединения таблицы фактов и таких таблиц соединений будет близка к оптимальной.
Схема "снежинка" добавляет иерархию в таблицы измерений. Например, измерение "Регион" группирует магазины по географическим регионам,измерение "Категория товара" группирует товары по категориям, измерение "Категория покупателей" группирует покупателей по категориям, а измерение "Период продаж" группирует продажи по периодам времени.
Рис. 9.8. Схема "снежинка"
Таким образом, использование иерархий превращает схему "звезда" в схему "снежинка". Вы можете расширять схемы "снежинка" за счет добавления в нее новых иерархий.
Рис. 9.9. Добавление в схему "снежинка" новых иерархий
Приведен пример схемы с несколькими таблицами фактов – схемы "созвездие фактов " (Fact Constellation Schema). На схеме имеет три таблицыфактов: "Продажи бакалеи", "Учет_товара" и "Покупка_товара", у которых имеются как общие измерения ("Товары"), так и эксклюзивные (например, измерение"Склады" для таблицы фактов "Учет_товара").
Рис. 9.10. Схема "созвездие фактов"
28. Требования к организации базы данных.
Установление многосторонних связей.
Некоторые базы данных будут содержать сложные переплетения взаимосвязей. Метод организации данных должен быть таким, чтобы обеспечивалась возможность удобного представления этих взаимосвязей и быстрого согласования вносимых в них изменений.
Производительность.
Система баз данных должна обеспечивать соответствующую пропускную способность. Но в системах, рассчитанных на небольшой поток запросов, пропускная способность накладывает незначительные ограничения на структуру базы данных.
Минимальные затраты.
Для уменьшения затрат на создание и эксплуатацию базы данных выбираются такие методы организации, которые минимизируют требования к внешней памяти.
Минимальная избыточность.
Целью организации базы данных должно быть уничтожение избыточных данных там, где это выгодно, и контроль за теми противоречиями, которые вызываются наличием избыточных данных.
Возможности поиска.
Пользователь базы данных может обращаться к ней с самыми различными вопросами по поводу хранимых данных.
Целостность.
Если база данных содержит данные, используемые многими пользователями, очень важно, чтобы элементы данных и связи между ними не разрушались.
Связь с прошлым.
В том случае, когда фирма начинает использовать на вычислительной установке новое программное обеспечение управления базами данных, очень важно, чтобы при этом она могла работать с уже существующими на этой установке программами, обрабатываемые данные можно было бы соответствующим образом преобразовывать. Важно, однако, чтобы проблема связи с прошлым не сдерживала развитие средств управления базами данных.
Связь с будущим.
Особенно важной представляется связь с будущим. В будущем данные и среда их хранения изменятся по многим направлениям. Одна из самых важных задач при разработке баз данных – запланировать базу данных таким образом, чтобы изменения ее можно было выполнять без модификации прикладных программ.
Простота использования.
Средства, которые используются для представления общего логического описания данных, должны быть простыми и изящными.
Интерфейс программного обеспечения должен быть ориентирован на конечного пользователя и учитывать возможность того, что пользователь не имеет необходимой базы знаний по теории баз данных.
29. Классификация технологических процессов обработки данных в ИС.
30. Ситуации, представляющие угрозу безопасности информации.
Основными источниками угроз безопасности АС и информации (угроз интересам субъектов информационных отношений) являются:
• стихийные бедствия и аварии (наводнение, ураган, землетрясение, пожар и т.п.);
• сбои и отказы оборудования (технических средств) АС;
• ошибки проектирования и разработки компонентов АС (аппаратных средств, технологии обработки информации, программ, структур данных и т.п.);
• ошибки эксплуатации (пользователей, операторов и другого персонала);
• преднамеренные действия нарушителей и злоумышленников (обиженных лиц из числа персонала, преступников, шпионов, диверсантов и т.п.).
31. Методы обеспечения защиты хранимых данных.
Основные механизмы защиты ПК от НСД могут быть представлены следующим перечнем:
1) физическая защита ПК и носителей информации;
Содержание физической защиты общеизвестно, поэтому детально обсуждать ее здесь нет необходимости. Заметим только, что ПК лучше размещать в надежно запираемом помещении, причем, в рабочее время помещение должно быть закрыто или ПК должен быть под наблюдением законного пользователя. При обработке закрытой информации в помещении могут находиться только лица, допущенные к обрабатываемой информации. В целях повышения надежности физической защиты в нерабочее время ПК следует хранить в опечатанном сейфе.
2) опознавание (аутентификация) пользователей и используемых компонентов обработки информации;
В концептуальном плане решение данной задачи принципиально не отличается от аналогичной задачи, решаемой в любой АСОД:
система защиты должна надежно определять законность каждого обращения к ресурсам, а законный пользователь должен иметь возможность, убедиться, что ему предоставляются именно те компоненты (аппаратура, программы, массивы данных), которые ему необходимы.
Для опознавания пользователей к настоящему времени разработаны и нашли практическое применение следующие способы:
1) с использованием простого пароля;
2) в диалоговом режиме с использованием нескольких паролей и/или персональной информации пользователей;
3) по индивидуальным особенностям и физиологическим характеристикам человека (отпечатки пальцев, геометрия руки, голос, персональная роспись, структура сетчатки глаза, фотография и некоторые другие);
4) с использованием радиокодовых устройств;
5) с использованием электронных карточек.
3) разграничение доступа к элементам защищаемой информации;
Разграничение доступа к элементам защищаемой информации заключается в том, чтобы каждому зарегистрированному пользователю предоставить возможности беспрепятственного доступа к информации в пределах его полномочий и исключить возможности превышения своих полномочий. В этих целях разработаны и реализованы на практике методы и средства разграничения доступа к устройствам ЭВМ, к программам обработки информации, к полям (областям ЗУ) и к массивам (базам) данных. Само разграничение может осуществляться несколькими способами, а именно:
1) по уровням (кольцам) секретности;
2) по специальным спискам;
3) по так называемым матрицам полномочий;
4) по специальным мандатам.
4) криптографическое закрытие защищаемой информации, хранимой на носителях (архивация данных);
Данный механизм, как следует из самого названия, предназначается для обеспечения защиты информации, которая подлежит продолжительному хранению на машинных носителях. Но при разработке методов его реализации имелась в виду и еще одна весьма важная цель — уменьшение объемов ЗУ, занимаемых хранимой информацией. Указанные цели и выступают в качестве основных критериев при поиске оптимальных вариантов решения задачи архивации данных.
Для предупреждения несанкционированного доступа к хранимой информации могут и должны использоваться все три рассмотренных выше механизма. Но особенно эффективными являются методы криптографического преобразования информации, поэтому они составляют основу практически всех известных механизмов архивации. Уменьшение объемов ЗУ достигается применением так называемых методов сжатия данных, сущность которых заключается в использовании таких систем кодирования архивируемых данных, которые при сохранении содержания информации требуют меньшего объема памяти носителя. Но тогда естественной представляется идея выбора такого способа кодирования, который удовлетворял бы обоим требованиям: обеспечивал бы уменьшение объема ЗУ и обладал бы требуемой надежностью криптографической защиты.
5) криптографическое закрытие защищаемой информации в процессе непосредственной ее обработки;
Назначение указанного метода очевидно, а целесообразность применения определяется возможностями несанкционированного доступа к защищаемой информации в процессе непосредственной обработки.
Если же обработка информации осуществляется в сетевой среде, то без применения криптографических средств надежное предотвращение несанкционированного доступа к ней практически не может быть обеспечено. Этим и обусловлено то достаточно большое внимание, которое уделяется разработке криптографических средств, ориентированных на применение в ПК.
6) регистрация всех обращений к защищаемой информации. Ниже излагаются общее содержание .и способы использования перечисленных механизмов.
Регистрация обращений к защищаемой информации ПК позволяет решать ряд важных задач, способствующих существенному повышению эффективности защиты, поэтому оно непременно присутствует во всех системах защиты информации.
Основные задачи, при решении которых заметную роль играет регистрация обращений, могут быть представлены следующим перечнем:
• контроль использования защищаемой информации;
• выявление попыток несанкционированного доступа к защищаемой информации;
• накопление статистических данных 6 функционировании систем защиты.
32. Принципы объектно-ориентированного подхода к проектированию ИС.
ООП держится на трех принципах: инкапсуляции, наследовании и полиморфизме.
Наблюдаемое в объектах объединение данных и операций в одно целое было обозначено термином инкапсуляция (первый принцип ООП). Применение инкапсуляции сделало объекты похожими на маленькие программные модули и обеспечило сокрытие их внутреннего устройства. Для объектов появилось понятие интерфейса, что значительно повысило их надежность и целостность.
Второй принцип ООП — наследование. Этот простой принцип означает, что если вы хотите создать новый класс, лишь немногим отличающийся от того, что уже существует, то нет необходимости в переписывании заново всех полей, методов и свойств. Вы объявляете, что новый класс является потомком (или дочерним классом) имеющегося класса, называемого предком (или родительским классом), и добавляете к нему новые поля, методы и свойства. Иными словами добавляется то, что нужно для перехода от общего к частному. Процесс порождения новых классов на основе других классов называется наследованием. Новые классы имеют как унаследованные признаки, так и, возможно, новые. Например, класс СОБАКИ унаследовал многие свойства своих предков - ВОЛКОВ
Третий принцип — это полиморфизм. Он означает, что в производных классах вы можете изменять работу уже существующих в базовом классе методов. При этом весь программный код, управляющий объектами родительского класса, пригоден для управления объектами дочернего класса без всякой модификации. Например, вы можете породить новый класс кнопок с рельефной надписью, переопределив метод отрисовки кнопки. Новую кнопку можно «подсунуть» вместо стандартной в какую-нибудь подпрограмму, вызывающую отрисовку кнопки. При этом подпрограмма «думает», что работает со стандартной кнопкой, но на самом деле кнопка принадлежит производному классу и отображается в новом стиле.
33. Принципы структурного подхода к проектированию ИС.
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы
34. Отличия объектно-ориентированного и структурного подходов к проектированию ИС.
Первое отличие этих подходов друг от друга заключается в принципах декомпозиции и структурной организации элементов (компонентов, модулей) системы. Согласно этим принципам система представляет собой структуру, состоящую из четко выраженных модулей, связанных между собой определенными отношениями.
При использовании структурного подхода (первый вид декомпозиции) выполняется функциональная (процедурная, алгоритмическая) декомпозиция системы, т. е. она представляется в виде иерархии (дерева) взаимосвязанных функций. На высшем уровне система представляется единым целым с наивысшей степенью абстракции и по мере детализации (добавления уровней) разбивается на функциональные компоненты с более конкретным содержанием.
Второй вид декомпозиции – объектно-ориентированный. В рамках этого подхода система разбивается на набор объектов, соответствующих объектам реального мира, взаимодействующих между собой путем посылки сообщений.
Вторым отличием является объединение в объекте как атрибутивных данных (характеристики, свойства), так и поведения (функции, методы). В функционально-ориентированных системах функции и данные хранятся (существуют) отдельно.
Третье отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции (англ. part-of – часть-целое), т. е. функция состоит из подфункций, подфункция из подподфункций и т.д. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования (англ. is-a – это есть). При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры.
35. Диаграммы, используемые в объектно-ориентированном проектировании ИС (прецедентов, классов, компонентов, пакетов, деятельности, коммуникации и последовательности, развёртывания). Статическая и динамическая модель системы. Объекты диаграмм и их элементы.
Основные типы UML-диаграмм, используемые в проектировании информационных систем
Графические изображения моделей системы в UML называются диаграммами. В терминах
языка UML определены следующие их виды
· диаграмма классов(class diagram
· диаграмма вариантов использования или прецедентов(use case diagram
· диаграмма последовательности(sequence diagram
· диаграммы поведения(behavior diagrams
· диаграмма состояний(statechart diagram
· диаграмма деятельности(activity diagram
· диаграмма взаимодействия(interaction diagram
· диаграмма кооперации(collaboration diagram
· диаграммы реализации(implementation diagrams
· диаграмма компонентов(component diagram
· диаграмма развертывания(deployment diagram
Каждая из этих диаграмм конкретизирует различные представления о модели системы. При этом, диаграмма вариантов использования представляет концептуальную модель системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является логической моделью, отражающей статические аспекты структурного построения системы, а диаграммы поведения, также являющиеся разновидностями логической модели, отражают динамические аспекты её функционирования. Диаграммы реализации служат для представления компонентов системы и относятся к ее физической модели
Из перечисленных выше диаграмм некоторые служат для обозначения двух и более подвидов. В качестве же самостоятельных представлений используются следующие диаграммы: вариантов использования, классов, состояний, деятельности, последовательности, кооперации, компонентов и развертывания
Диаграмма
Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования
Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи
Диаграмма вариантов использования
Диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между 4 вариантами использования .
Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграммы вариантов использования описывают функциональное назначение системы или то, что система должна делать. Разработка диаграммы преследует следующие цели:
определить общие границы и контекст моделируемой предметной области;
сформулировать общие требования к функциональному поведению проектируемой системы;
разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
Диаграммы взаимодействия
Диаграммы последовательностей и кооперации (и те, и другие называются диаграммами взаимодействий) относятся к числу пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов системы. На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними, в том числе сообщения, которыми объекты обмениваются. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма кооперации - на структурной организации посылающих и принимающих сообщения объектов. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента. Поскольку диаграмма взаимодействий - это частный случай диаграммы, ей присущи общие для всех диаграмм свойства: имя и графическое содержание, являющееся одной из проекций модели. От других диаграмм ее отличает содержание. Как правило, диаграммы взаимодействий содержат: объекты; связи; сообщения.
Диаграмма деятельности
Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов - вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла к входам другого. Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
36. Исходные показатели, необходимые при разработке технико-экономических показателей проекта.
37. Оценка экономической эффективности проектируемой ИС.
Под понятием «оценка экономической эффективности ИС» понимается процесс, включающий в себя понимание, определение и измерение того, насколько полезным в экономическом плане является или явилось внедрение ИС для предприятия. При этом экономическая полезность рассматривается обычно как денежный эквивалент того, насколько изменились доходы/расходы предприятия в результате инвестирования в ИС.
Под методом оценки эффективности ИС подразумевается способ или набор средств проведения полной оценки ИС. Они могут состоять как из формальных, так и из неформальных процедур, при этом под неформальными понимаются не основанные на цифровых данных, быстрые, преимущественно субъективные процедуры оценки, а под формальными - более объективные, рациональные, базирующиеся на недвусмысленных данных механизмы оценки.
Как известно, внедрение современных информационных технологий - дело дорогостоящее. Функционирование компаний в рыночной среде требует как минимум анализа экономических последствий, а еще лучше - оценки экономической эффективности того или иного шага преобразования системы управления компанией.
Оценка экономической эффективности ИС - сложная и трудоемкая работа, требующая не только технических, но и экономических навыков. Только сочетание этих двух составляющих может привести к достоверному результату проводимого анализа.
Продвижение на рынке ИС в условиях современной конкуренции невозможно без предоставления результатов оценки ожидаемой эффективности системы. Кроме того, существующая статистическая оценка успешности внедрения систем управления предприятием характеризуется неудачей внедрения от 40 до 70 % случаев.
Специалисты в области разработки, внедрения и сопровождения ИС должны обладать навыками проведения предварительной экспертизы проекта. Они должны уметь вести постоянный мониторинг системы на соответствие внедряемых технологий стратегии развития предприятия. Процесс соизмерения затрат и достигаемого за их счет эффекта должен быть именно «процессом», то есть итерационной процедурой, проводимой на протяжении всего этапа разработки и внедрения проекта, результат которой способен повлиять на дальнейшее продолжение проекта.
Существуют следующие этапы оценки экономической эффективности информационной системы:
· традиционная оценка эффективности как соотношение затрат и результатов;
· расчет совокупной стоимости владения информационной системой;
· оценка внедрения ИС как инвестиционного проекта;
· разработка сбалансированной системы показателей для оценки экономического эффекта;
· оценка эффективности проектов независимо от технических, технологических, финансовых, отраслевых или региональных особенностей осуществляется на основе единых принципов. К ним относятся:
· рассмотрение проекта на протяжении всего жизненного цикла;
· моделирование денежных потоков;
· сопоставимость условий сравнения различных проектов;
· положительность и максимум эффекта;
· учет фактора времени;
· учет только предстоящих в ходе осуществления проекта затрат и поступлений;
· сравнение «с проектом» и «без проекта»;
· учет всех наиболее существенных последствий проекта;
· учет наличия разных участников проекта;
· многоэтапность оценки;
· учет влияния на эффективность инвестиционного проекта;
· учет влияния инфляции;
· учет влияния неопределенностей и рисков.
Показатели коммерческой эффективности проекта в целом отражают финансовые последствия внедрения информационной системы. В качестве основных показателей для расчета коммерческой эффективности проекта рекомендуется использовать следующие:
- чистый доход;
- чистый дисконтированный доход;
- внутренняя норма доходности;
- индексы доходности затрат и инвестиций;
- срок окупаемости.
Таким образом, исходя из всего выше сказанного, можно сделать вывод, что процесс оценки экономической эффективности информационных систем сложен и неоднозначен. Подходить следует индивидуально в каждом конкретном случае, но опираясь на предложенные схемы и методики, что позволит исключить «человеческий фактор» и снизить погрешности ввиду отсутствия каких либо данных.
Выбор и обоснование методики оценки информационной системы
Метод оценки чистого приведенного эффекта
Важнейшим показателем эффективности инвестиционного проекта является чистая текущая стоимость (Net Present Value, NPV) - накопленный дисконтированный эффект за расчетный период.
В общем случае методика расчета NPV заключается в суммировании современных (пересчитанных на текущий момент) величин чистых эффективных денежных потоков по всем интервалам планирования на всем протяжении периода исследования. При этом, как правило, учитывается и ликвидационная или остаточная стоимость проекта, формирующая дополнительный денежный поток за пределами горизонта исследования. Для пересчета всех указанных величин используются коэффициенты приведения, основанные на выбранной ставке сравнения (дисконтирования).
Классическая формула для расчета NPV выглядит следующим образом:
где:
r - ставка дисконтирования (в десятичном выражении);
n - номер года;
О степени эффективности вложения средств в данный проект говорит полученная величина NPV.
Очевидно, что если:
- NPV > 0, то проект следует принять;
- NPV < 0, то проект следует отвергнуть;
- NPV = 0, то проект ни прибыльный, ни убыточный.
Определение срока окупаемости инвестиций
Срок окупаемости относится к числу наиболее часто используемых показателей эффективности инвестиций. Достаточно сказать, что именно этот показатель, наряду с внутренней ставкой доходности, выбран в качестве основного в методике оценки инвестиционных проектов, участвующих в конкурсном распределении централизованных инвестиционных ресурсов.
Цель данного метода состоит в определении продолжительности периода, в течение которого проект будет работать, что называется, «на себя». При этом весь объем генерируемых проектом денежных средств, главными составляющими которого являются чистая прибыль и сумма амортизационных отчислений (то есть чистый эффективный денежный поток), засчитывается как возврат на первоначально инвестированный капитал.
Расчет простого срока окупаемости, в силу своей специфической наглядности, часто используется как метод оценки риска, связанного с инвестированием.
Существенным недостатком рассматриваемого показателя является то, что он ни в коей мере не учитывает результаты деятельности за пределами установленного периода исследования проекта и, следовательно, не может применяться при сопоставлении вариантов капиталовложений, различающихся по срокам жизни.
Простой срок окупаемости рассчитывается по формуле:
где:
PP - срок окупаемости, выраженный в интервалах планирования;
PV - полные инвестиционные затраты проекта;
NCF - чистый эффективный денежный поток за один интервал планирования.
Определение индекса доходности инвестиций
Рассматриваемый показатель тесно связан с показателем чистой современной ценности инвестиций, но, в отличие от последнего, позволяет определить не абсолютную, а относительную характеристику эффективности инвестиций.
Индекс доходности инвестиций PI рассчитывается по следующей формуле:
где PV - полные инвестиционные затраты проекта.
PI характеризует уровень доходов на единицу затрат, т.е. эффективность вложений - чем больше значение этого показателя, тем выше отдача с каждой единицы капитальных вложений, инвестированных в данный проект.
Метод определения внутренней нормы доходности проекта
Под внутренней нормой доходности проекта IRR (Internal Rate Of Return) понимают значение коэффициента дисконтирования (r), при которомNPV проекта равен 0.
где IC - величина исходных инвестиций.
Смысл расчета этого коэффициента при анализе эффективности результата инвестиций следующий: IRR показывает максимально допустимый относительный уровень расходов, которые могут быть вложены в данный проект. Например, если проект полностью финансируется за счет ссуды коммерческого банка, то значение IRR показывает верхнюю границу допустимого уровня банковской процентной ставки, превышение которой делает проект убыточным.
Движущие мотивы финансирования проекта существенно зависят от того, реализуется ли инвестиция за свои или привлеченные средства. Однако для большинства инвестиционных проектов в случаях финансирования и за счет собственных средств, и за счет привлеченных финансовых ресурсов в основе лежит показатель цены капитала.
Практическое применение данного метода сводится к последовательной итерации, с помощью которой находится дисконтирующий множитель, обеспечивающий равенство NPV = 0.
Ориентируясь на существующие в момент анализа процентные ставки на ссудный капитал, выбираются два значения коэффициента дисконтирования r1 < r2 , таким образом, чтобы в интервале (r1; r2) функция NPV = f(r) меняла свое значение с «+» на «-» или наоборот. Далее используем формулу:
где:
r1 - значение процентной ставки в дисконтном множителе, при котором f(i1) < 0 (f (i1 ) > 0);
r2 - значение процентной ставки в дисконтном множителе, при котором f(i2) > 0 (f (i2 ) < 0);