Моделирование данных

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

§ требования к данным отдельных пользователей;

§ характер самих данных независимо от их физического представления;

§ использование данных в пределах области применения приложения.

Критерии оценки модели данных

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

Эффективность технологий создания ПО оценивается критериями:

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

2. качество создаваемого ПО (функциональная полнота, число дефектов и ошибок, обнаруженных в процессе эксплуатации);

3. трудоемкость разработки ПО (количество человеко-дней);

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

5. эффект от использования ПО (положительный баланс между вложенными средствами, расходами до и после внедрения);

6. срок окупаемости затрат на внедрение ПО (интервал времени от начала разработки ПО до момента полного возврата инвестиций).

Проектирование БД является наиболее трудоемким этапом построения ИС и заключается в последовательном решении следующих задач:

o разработка концептуальной модели данных;

o построение логической модели (структуры БД);

o выбор аппаратной конфигурации и программных средств;

o создание физической модели БД (для выбранной СУБД);

o разработка приложений - автоматизированных рабочих мест (АРМ).

№ этапа	Содержание этапов разработки ИС	Сроки реализации, мес.
	Анализ и проектирование системы	1-3
	Программирование и отладка функционального ядра	2-4
	Тестирование и опытная эксплуатация	1-4
	Доработка и сопровождение проекта	3-6

даны рекомендации по оптимизации БД:

1. централизованное внесение изменений в структуры данных;

2. выявление и удаление неиспользуемых объектов БД (таблиц, процедур);

3. анализ использования объектов БД в приложениях;

4. установка оптимальных размеров блоков данных;

5. уменьшение фрагментации дискового пространства;

6. группировка хранимых данных по логическим разделам БД;

7. децентрализация, распределение БД по разным физическим устройствам;

8. оптимизация хранения больших двоичных объектов (BLOB/CLOB);

9. индексирование таблиц данных и поддержание статистики БД.

9. Задачи анализа транзакций на этапе логического проектирования БД и правила его проведения на примере одной транзакции. OLTP-технология.

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

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

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

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

Оператор:

1 Ввод нового договора.

2 Поиск объекта по цене.

3 Ввод нового клиента.

4 Поиск всех договоров конкретного клиента.

Продавец:

1 Поиск товара по названию и цене «от» - «до»

2 Поиск товара по марке-производителя.

3 Формирование чека.

4 Список всех своих чеков за период.

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

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

Пример

Перечень всех договоров конкретного менеджера за конкретный месяц.

Для выполнения данной транзакции необходимо найти значение первичного ключа – номера данного менеджера в сущности «Персонал», далее найти значения всех атрибутов в сущности «Договор», где значение атрибута “менеджер” совпадает с заданным и значение атрибута “Дата_закл” попадает в границы заданного месяца. Данная транзакция может быть выполнена. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

OLTP (OnLine Transaction Processing) — онлайновая обработка транзакций. Способ организации БД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

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

Требования

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

Преимущества

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

Недостатки

OLTP-системы оптимизированы для небольших дискретных транзакций. А вот запросы на некую комплексную информацию (к примеру поквартальная динамика объемов продаж по определённой модели товара в определённом филиале), характерные для аналитических приложений (OLAP), породят сложные соединения таблиц и просмотр таблиц целиком. На один такой запрос уйдет масса времени и компьютерных ресурсов, что затормозит обработку текущих транзакций.

10. Задачи анализа транзакций на этапе физического проектирования БД и правила его проведения на примере одной транзакции. Технология оперативной обработки транзакций.

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

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

• ожидаемая частота выполнения транзакций;
• отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа (R – выборка, I – вставка, U – обновление, D – удаление);
• ограничения, устанавливаемые на время выполнения транзакций.

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

2) Определение ожидаемоего количества строк в отношениях, а также среднюю и максимальную кратности каждой связи (см. рис. 9.3). Например, ожидается, что персонал компании составит 50 человек, 4 из которых менеджеры, 40 операторов. Компания владеет 500 объектами жилья, на которые заключается 1000 договоров.

3) Анализ частоты и времени выполнения транзакций. При анализе каждой из транзакций очень важно знать не только среднее и максимальное количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда она обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота вызова некоторых транзакций может удерживаться на некотором уровне постоянно, но все же она имеет четко выраженный пик нагрузки в последний четверг месяца с 14-00 до 16-00, вызванный подготовкой отчетов. Другие транзакции вообще могут выполняться только в определенные моменты времени, например - по понедельникам с 9-00 до 10-00, что также является пиком нагрузки.

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

Тран закция	Активность	День недели	Время суток	Частота вызовов в месяц
Т2. Перечень всех договоров конкретного менеджера за конкретный месяц.	Пиковая	Последний четверг месяца	9-00 – 12-00
Средняя	-	-	-

OLTP (OnLine Transaction Processing) — онлайновая обработка транзакций. Способ организации БД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

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

Требования

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

Преимущества

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

Недостатки

OLTP-системы оптимизированы для небольших дискретных транзакций. А вот запросы на некую комплексную информацию (к примеру поквартальная динамика объемов продаж по определённой модели товара в определённом филиале), характерные для аналитических приложений (OLAP), породят сложные соединения таблиц и просмотр таблиц целиком. На один такой запрос уйдет масса времени и компьютерных ресурсов, что затормозит обработку текущих транзакций.

11. Жизненный цикл БД. Этапы проектирования БД в пользовательских приложениях. Цель и виды работ на этапе логического проектирования базы данных в пользовательских приложениях.

Жизненный цикл базы данных — это совокупность этапов, которые проходит база данных на своём пути от создания до окончания использования. Жизненный цикл базы данных состоит из шести этапов:

· начальная разработка,

· проектирование БД,

· реализация и загрузка дан­ных,

· тестирование и оценка,

· функционирование,

· обслуживание и развитие.

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

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

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

После подготовки технического задания необходимо определить технические требования.

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

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

Концептуальное проектирование базы данных.

Этапы концептуального проектирования:

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

Охват предметной области данного предприятия.

2. Определение типов сущностей.

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

3. Определение типов связей.

Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе.

4. Определение атрибутов и связывание их с типами сущностей и связей.

Связывание атрибутов с соответствующими типами сущностей или связей.

5. Определение доменов атрибутов.

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

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

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

7. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

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

8. Проверка модели на отсутствие избыточности.

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

9. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

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

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

Логическое проектирование базы данных

Второй этап проектирования базы данных называется логическим проектированием базы данных. Его цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель).

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

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

Физическое проектирование базы данных.

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

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

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

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

2 определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

3 разработка средств защиты создаваемой системы.

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

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

12. Жизненный цикл БД. Этапы проектирования БД в пользовательских приложениях. Цель и виды работ на этапе физического проектирования базы данных в пользовательских приложениях.

Вопрос 11

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

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

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

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

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

Документооборот — движение документов в организации с момента их создания или получения до завершения исполнения или отправления (ГОСТ Р 51141-98); комплекс работ с документами: приём, регистрация, рассылка, контроль исполнения, формирование дел, хранение и повторное использование документации, справочная работа.

Электронный документооборот (ЭДО) — единый механизм по работе с документами, представленными в электронном виде, с реализацией концепции «безбумажного делопроизводства».

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

Заголовочная часть содержит следующие характеристики документа и учитываемого объекта:

 наименование учитываемого объекта (предприятия, организации, работающего);

 характеристика документа (индекс, ОКУД; наименование документа;)

 зона для проставления кодов постоянных для документа реквизитов-признаков.

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

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

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

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

· выделяются реквизиты, подлежащие автоматизированной обработке и распределяются по трем зонам:

1-я зона — постоянные признаки, располагаемые в заголовочной части, в рамке для проставления кодов постоянных признаков;

2-я зона — переменные признаки, помещаемые в таблице справа или слева от наименования признаков;

3-я зона — количественно-суммовые основания, размещаемые в таблице справа.

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

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

Основные особенности электронного документооборота

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

14. Распределенные БД. Основные стандарты, технологии, организация доступа, инструментальные средства реализации. Типовые решения, экономическая эффективность и совокупная стоимость владения.

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

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

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

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

§ Имеется набор логически связанных разделяемых данных.

§ Сохраняемые данные разбиты на некоторое количество фрагментов.

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

§ Фрагменты и их копии распределяются по разным узлам.

§ Узлы связаны между собой сетевыми соединениями.

§ Доступ к данным на каждом узле происходит под управлением СУБД.

§ СУБД на каждом узле способна поддерживать автономную работу локальных приложений.

§ СУБД каждого узла поддерживает хотя бы одно глобальное приложение.

Преимущества	Недостатки
Отображение структуры организации	Повышение сложности
Разделяемость и локальная автономность	Увеличение стоимости
Повышение доступности данных	Проблемы защиты
Повышение надежности	Усложнение контроля за целостностью данных
Повышение производительности	Отсутствие стандартов
Экономические выгоды	Недостаток опыта
Модульность системы	Усложнение процедуры разработки базы данных

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

Прямые затраты.

1.1. Основные затраты: создание информационной системы; оборудование — серверы, клиентские места, периферия, сетевые компоненты; ПО, приложения, утилиты, управляющее ПО; обновление (модернизация).

1.2. Эксплуатационные затраты: управление задачами; поддержка работоспособности системы — персонал, функционирование справочной службы, обучение, закупки, подготовка контрактов на поддержку системы; разработка инфраструктуры, бизнес приложений.

1.3. Прочие затраты: создание коммуникаций — глобальные сети, взаимодействие с поставщиками сервиса, удаленный доступ, Internet, доступ клиента; управление и поддержка — аутсорсинг, сопровождение, справочная система.

Косвенные затраты

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

Говоря про TCO применительно к СУБД, можно выделить следующие составные части:

1. Стоимость самой СУБД, состоящая из первоначального платежа за приобретение лицензий и ежегодных платежей за поддержку от производителя.
2. Стоимость сопровождения СУБД, которая определяется заработной платой сотрудников, ответственных за обслуживание и администрирование баз данных.
3. Стоимость платформы для разворачивания СУБД — серверного оборудования и операционной системы. Эта стоимость также складывается из первоначального платежа за приобретение оборудования и лицензий на ОС, а также ежегодных платежей за поддержку от производителей.

Модель TCO позволяет:

1. Оптимизировать инвестиции в ИТ.

2. Объективно оценить степень удовлетворенности конечных пользователей применяемыми ИТ.

3. Оптимизировать процессы замены и модернизации ИТ.

4. Оптимизировать процессы обучения конечных пользователей и ИТ-специалистов.

5. Организовать регулярное управление ИТ-активами.

6. Выявить скрытые расходы на администрирование СЭД и поддержку в актуальном состоянии информационных ресурсов организации.

Дата добавления: 2015-11-16