Уважаемые читатели!

Честно говоря, я не в восторге от статьи, обзор которой предлагается Вашему вниманию. Мне кажется, что ее можно было бы написать яснее и понятнее. Но с другой стороны, тема настолько актуальна, что я решил опубликовать этот дайджест. Если Вам покажется, что подобные материалы не следует размещать на нашем сайте, дайте мне знать, пожалуйста.

С уважением, Сергей Кузнецов

---

The Physics of Logical Modeling

Charles Tupper, a principal with Relational Database Architects Inc.

DataBase Programming & Design OnLine, September 1998
Оригинал статьи можно найти по адресу www.dbpg.com/9809xtra.html

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

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

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

Учет потребностей бизнеса

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

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

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

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

Повышение эффективности модели

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

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

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

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

Различение типов денормализации

Эти простые принципы позволят внести в логическую модель конкретные изменения, оказывающие небольшое влияние на дисковую подсистему и сохраняющие характеристики бизнес-модели. Денормализация диаграмм "сущность-связь" (ERD - Entity-Relationship Diagram) или денормализация уровня доступа могут быть использованы с применением или без применения CASE-средств.

Денормализация ERD

Под денормализацией ERD понимается такая форма манипулирования структурой модели, при которой сохраняется специфика проблем бизнеса. Обычно преобразования происходят в виде комбинирования или сжатия ряда логических объектов модели. Это позволяет сократить длину цепочек вызовов, требуемых приложению для навигации в пространстве объектов базы данных, при преобразовании структуры от логических к физическим объектам. Ни при каком условии нельзя производить денормализацию ERD без предварительной проверки логической модели. Устранение связей 1:1. Такие связи между типами сущности A и B означают, что для каждого экземпляра A имеется один и только один экземпляр B. Хотя ключевые атрибуты сущностей могут быть разными, равноправное участие этих сущностей в связи означает, что к ним можно относиться как к единой сущности в любой единицы работы над данными. Различается только степень использования атрибутов. Комбинирование атрибутов с различной загрузкой не изменяет бизнес-представление и уменьшает время доступа за счет наличия только одного физического объекта (таблицы) и требования меньших дополнительных накладных расходов (индексов).

Разрешение связей M:N. Для каждого экземпляра A существует много экземпляров B, и для каждого экземпляра B существует много экземпляров A. При наличии сложных взаимодействий связи M:N отражают пересечение разных вхождений ключей. При "ручной" обработке с такой связью можно обращаться с помощью создания промежуточной сущности между двумя связанными сущностями, называемой ассоциативной сущностью. Ключ этой сущности является конкатенацией первичных ключей участвующих в связи сущностей. Например, если ключ A есть 1, а ключ B - 2, то ключом ассоциативной сущности A,B будет 1,2.

CASE-средства автоматически разрешают эту проблему путем создания ассоциативной сущности в процессе преобразования модели. Однако производители этих средств генерируют нестандартные имена для ассоциативных сущностей и идентифицирующих их ключей. Для порождения стандартизованных имен многие администраторы данных разрешают связи M:N путем явного создания ассоциативных сущностей с соответствующим именованием ключей. После разработки ассоциаций при отображении процессов на сущности часто становится ясно, что реальный интерес представляют именно ассоциации. Редко бывает так, что в ассоциативной сущности отсутствуют действительно используемые атрибуты и единственным таким атрибутом является дата установления связи. Во многих случаях реализуется только ассоциативная таблица, а атрибуты сущностей-участников связи мигрируют в нее для повышения эффективности.

Разрешение рекурсивных связей. Рекурсивные связи представляют собой связи на экземпляры того же типа сущности, или "спиральные" связи. Это, хотя и может показаться сложным, означает всего лишь иерархию "предок-потомок" (возможно, многоуровневую). В случае одноуровневой рекурсии поведение аналогично связи 1:M с распространением ключа как внешнего для другого участника. Результатом является то, что рекурсивная сущность обладает внешним ключом, который на самом деле является иным образом первичного ключа. Однако некоторые CASE-средства генерируют нестандартное имя внешнего ключа. В этом случае администратору данных стоит самому произвести разрешение рекурсивной связи и произвести правильное именование внешнего ключа.

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

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

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

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

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

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

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

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

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

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

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

Разрешение дубликатов при распространении ключей. Некоторые связи можно считать идентифицирующими, поскольку для них требуется включение в их ключ ключа участвующего предка. Поскольку идентифицирующие связи распространяют ключи принимающим сущностям, а те, в свою очередь, могут идентифицировать другие сущности, ключи распространяются по всем цепочкам зависимостей. В большинстве областей бизнес-деятельности эти цепочки являются короткими и их наличие не порождает больших сложностей; в других случаях эти цепочки зависимостей могут быть достаточно длинными - до 10-12 сущностей. В последней ситуации появляются первичные ключи, включающие до 10-20 атрибутов. Когда такие длинные ключи вовлекаются в связи с другими сущностями, цепочка зависимостей может замкнуться для включения предыдущей сущности (связь циклического типа), или две зависимых цепочки можно разрешить за счет ассоциативного объекта. Идентифицирующая природа связи вызывает появление в ассоциативном объекте нескольких ключей с одним и тем же именем, т.е. ключей-дубликатов.

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

Денормализация уровня доступа

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

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

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

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

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

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

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

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

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

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

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

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

Достижение гибкости

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