12 Вопрос. Процесс денормализации бд: определение; характеристика способов денормализации бд.

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

Основные сведения

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

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

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

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

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

Для чего нужна денормализация

Денормализацию базы проводят обычно для повышения производительности, реже - для облегчения жизни программистам, разрабатывающим приложения, работающие с этой базой данных. Хотя часто эти цели достигаются одновременно:).

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

Большое количество соединений таблиц

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

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

Расчетные значения

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

Длинные поля

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

ID фотографии

ID автора

ID модели фотоаппарата сама фотография (blob-поле).

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

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

Как правильно проводить денормализацию

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

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

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

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

18 вопрос. Информационные системы электронного документооборота (ИСЭД). Основные задачи, решаемые при организации работы с документами и создании систем электронного документооборота. Концепция построения систем автоматизации деловых процессов.

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

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

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

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

• Гибкость управления доступом ко всему спектру документов, от электронной почты до дискуссионных баз данных, от видео клипов до формализованных документов всех типов.

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

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

• Доступность широкого спектра дополнительных технологий для повышения уровня возврата от инвестиций.

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

Например, Lotus Domino.Doc справедливо отнесен к категории корпоративных систем ЭУД, хотя в нем есть широкие возможности маршрутизации работ (workflow), особенно в сочетании с таким продуктом, как Domino Workflow. Ситуация тем более осложняется тем, что ведущие игроки этого рынка постоянно дополняют функционал своих продуктов.

Ниже перечислены категории технологий ЭУД с примерами наиболее известных поставщиков и продуктов в каждом классе (тоже по информации IDC):

• Системы ЭУД, ориентированные на бизнес-процессы (Business-process EDM): Documentum, FileNet (Panagon и Watermark), Hummingbird(PC DOCS)

• Корпоративные системы ЭУД (Enterprise-centric EDM): Lotus (Domino.Doc), дополнения к Novell GroupWise, Opent Text (LiveLink), Keyfile Corp., Oracle (Context)

• Системы управления контентом ( Content management): Adobe, Excalibur

• Системы управления информацией (порталы) ( Information Management): Excalibur, Oracle Context, PC DOCS/Fulcrum, Verity, Lotus (Domino/Notes, K-station)

• Системы управления образами (Imaging)

• Системы управления потоками работ (Workflow management): Lotus (Domino/Notes и Domino Worflow), Jetform, FileNet, Action Technologies, Staffware

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

• Обработка и хранение документов: регистрация

• Управление потоками работ (передача документов между исполнителями)

• Контроль исполнительской дисциплины

• Поиск документов по атрибутам и полнотекстовый поиск

• Работа с взаимосвязанными документами

• Регламентация прав доступа

• Списание документов "в дело"

• Интеграция с внешними системами электронной почты

• и ряд других.

Основными пользователями этих систем являются такие структурные подразделения организаций, как управление делами, секретариаты, канцелярии, общие отделы, экспедиции и т.д. Безусловно, это важные пользователи, но они составляют 5-10% сотрудников организаций, которые нуждаются в повсеместно доступной общекорпоративной системе электронного управления документами.

3вопрос. Документальные и фактографические информационные системы. Области применения информационных систем.

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

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

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

Существует ещё один вид ИС. Это так наз. Экспертные ИС. Такие системы способны дать оценку ситуации и спрогнозировать её развитие на основе заложенных в такую систему фактических данных и связывающих их общих закономерностей. Примером такой ИС может служить медицинская ИС, которая, на основе данных анализов и клинических проявлений может поставить диагноз, дать прогноз и рекомендовать схему лечения. В выборе лекарств, имеющихся на рынке, для лечения конкретного заболевания врачу может помочь фактографическая ИС, ответив ему на вопрос: «Какие лекарства наиболее эффективны при таком-то заболевании», при этом можно уточнить фирму производителя, стоимость и наличие в аптеках. Документальная ИС система поможет врачу освежить свои знания в нужной области, поскольку он может запросить, например, все статьи, в которых упоминается данная болезнь.